Comments on Application Mapping I-Ds

[Andy Bierman <abierman@cisco.com>]

Hi,

Here are some more comments on the 3 application mapping drafts.
IMO they are all in good shape, and almost ready for WG Last Call.

1) General Comments

 - Titles should be consistent; every one is a different style.
   We need to decide which style is best:
    - BEEP Application Protocol Mapping for NETCONF
    - NETCONF Over SOAP
    - Using the NETCONF Configuration Protocol over Secure Shell (SSH)
  
 - The following normative sections should exist in
   all documents, and be consistent in content:
   - NETCONF Session Establishment
   - NETCONF Capabilities Exchange
   - NETCONF Session Usage
   - NETCONF Session Teardown

 - In the session tear-down section, each document must explain
   what to do when <close-session> or <kill-session> operations
   are invoked

2) draft-ietf-netconf-beep-01 comments

 - pg 4, sec 2.1, para 5

   OLD:

   ... manager now establishes an NETCONF a new <cr>
       &dquot;operational&dquot; channel for capabilitiesexchange
       and requests and responses.

   NEW:

   ... manager now establishes a new channel for NETCONF messages.

 - pg 5, sec. 2.4

   - "Operations channel" is no longer a well-understood
     term, since it's been removed from the protocol.
     "NETCONF Messages channel" seems better.

 - pg 7, sec. 2.4.2

   - Remove this section (Notification Channel Profile)

3) draft-ietf-netconf-soap-02 comments

 - I am rather concerned that the document is so specific
   to SOAP over HTTP, partly because the advert said "SOAP
   runs over anything, don't worry about the transport",
   and partly because our EMS developers are very interested in
   SOAP over BEEP, not SOAP over HTTP.

   Clearly we have to worry about the transport, and clearly
   BEEP is better than HTTP, for use with NETCONF.
   Proposal:
     - separate SOAP-generic and SOAP-over-HTTP text
       as much as possible
     - add text to support for SOAP over BEEP (RFC 3288)

 - I think Eliot raised valid issues wrt/ HTTP caching
   that should be mentioned in sec 2.4

 - Appendix A: WSDL Definitions

  I've been told our WSDL model is inferior because it
  just exposes the <rpc>, <rpc-reply> exchange, not the
  standard protocol operations underneath.   I've also
  been told this doesn't matter -- you can still get WSDL
  based tools to model the proto-op layer, not the RPC layer.
  I don't know which is true.   The WG needs to decide.

4) draft-ietf-netconf-ssh-01 comments

 - pg 3, Introduction

  OLD:
    XMLCONF

  NEW:
    NETCONF

 - general (starting on pg 5)

  Indent examples and label them Example 1, Example 2, etc.
  They blend in with the normative text.  Change "in the
  example above" to "in Example N".

 - pg 5, sec 2.1, para 1

  "(or the user's expect script)"

  This seems very implementation-dependent, and expect is
  not defined or mentioned anywhere else

 - pg 6, para 1

  OLD:
    a $lt;hello>

  NEW:
    a <hello>

 - pg 9, sec 5.1, <hello> example

  change #lock to a current NETCONF capability, like #candidate

 - pg 10, sec 5.2

   This needs to be updated to use <close-session>
   instead of <kill-session>.

   Need to note that it is an implementation-specific
   matter as to how a <close-session> or a <kill-session>
   (from one session to another) is detected.

 - pg 11, sec 6, para 3

  OLD:

  security keys.  So, NETCONF should

  NEW:
 
  security keys.  NETCONF should




 


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>