Re: [Netconf] We NEED RESPONSES: WG Last Call ended for: draft-ietf-netconf-4741bis-04.txt

[Ladislav Lhotka <[e-mail]>]

Hi,

I hope it's not too late:

I re-read again 4741bis-04 and I think it's fine with one exception:
Either the EOM issue must be fixed in 4742bis or 4741bis should not
require it as the mandatory transport protocol.

Other comments:

1. Sec. 1.2: List item 2 refers to [8], which is the partial lock
   RFC. Instead, it should refer to RFC 5277 (notifications).

2. Sec. 1.3: The base NETCONF specification also corresponds to a
capability, namely :base. 

   OLD

   A NETCONF capability is a set of functionality that supplements the
   base NETCONF specification.

   NEW

   A NETCONF capability is an identified set of functionality.

3. Sec. 3:

   "All NETCONF messages MUST be well-formed XML, encoded in UTF-8."

   It should be clarified what this requirement means. My understanding
   is that PDUs exchanged between the client and server MUST contain
   well-formed messages.

4. Sec. 4.1:

   "If additional attributes are present in an <rpc> element, a NETCONF
   peer MUST return them unmodified in the <rpc-reply> element.  This
   includes any "xmlns" attributes."

   I think the requirement on "xmlns" attributes is quite
   problematic. These attributes have a very specific function, so if
   the server uses another prefixes or another default namespace, why
   should it send the "xmlns" attributes received in the RPC request?

   The client could thus pre-empt a prefix the server normally uses,
   e.g. by sending xmlns:nc="http://example.com/foo".

5. Sec. 5.2, 7.2 and elsewhere:

   I think it would be better to indicate the namespace in the names of
   XML elements or attributes, if there is any, e.g. <nc:config> rather
   than <config>. This is especially important for attribute names
   because attributes with a non-null namespace URI are not common.

6. Sec. 6.2.5, fourth bullet on p. 26:

   "If any sibling nodes of the selection node are instance identifier
   components for a conceptual data structure (e.g., list key leaf),
   then they MAY also be included in the filter output."

   I don't understand what this means. Is it that the subtree pointed to
   by the instance indentifier may be included?

7. Sec. 7.2: Without the notion of (mandatory) list keys, the merge
   operation may be ambiguous. In the example on p. 43, if the "running"
   datastore contained two interfaces

     <interface>
       <name>Ethernet0/0</name>
       <mtu>9216</mtu>
     </interface>
     <interface>
        <name>Ethernet0/1</name>
        <mtu>1500</mtu>
     </interface>

   the edit-config operation could mean two things: either change <mtu>
   of the first interface or change <name> of the other.

8. Sec. 7.5, p. 49:

   s/A lock MUST not/A lock MUST NOT/

9. Sec. 8.1:

   "Each peer sends its <hello> element simultaneously ..."

   Why "simultaneously"? Should it be removed or changed to
   "asynchronously"? 

10. Sec. 8.3.1:

   "A <commit> operation may be performed at any time that causes the
   device's running configuration to be set to the value of the
   candidate configuration."

   What is the "value" of the candidate configuration? The first
   sentence in the next paragraph explains the operation correctly so
   this sentence could be removed.

11. Now that Appendix B declares itself as normative, I am wondering
   what object is supposed to be validated against the XSD schema. For
   example, the schema doesn't take into account the two variants of
   <hello> with different content model: server's <hello> must have
   exactly one session-id attribute whereas client's <hello> must not
   have it at all. The XSD has a content model that is correct neither
   for the server nor for the client:

     <xs:element name="session-id"
        type="SessionId" minOccurs="0"/>

Lada

On Thu, 23 Sep 2010 13:47:44 +0200, "Bert (IETF) Wijnen" <[e-mail]> wrote:
>   It was pointed out to me that we did not get ANY comments to this WGLC.
> Well, there was continued discussion on XML parse errors (which is
> related partly to this document) on which we will come back tomorrow.
> 
> But no other comments, Also not any " I read it, go ahead to the next step".
> 
> Can the WG chairs assume that people have indeed read the latest version
> of this document and are OK with it?
> 
> Can you please ASAP tell us: I read the doc and I am fine with it!!!
> 
> PLEASE
> 
> Bert and Mehmet
> 
> On 9/3/10 12:08 AM, Bert Wijnen (IETF) wrote:
> > WG participants, this email starts a formal WG Last Call for revision 4
> > of the 4741bis document. The document is targeted as Proposed Standard
> > to replace the current rfc4741.
> >
> > Please do review and tell us your position and comments.
> > Please do so BEFORE 20 September 2010.
> >
> > Bert and Mehmet
> >
> > ----- Original Message -----
> > From:<[e-mail]>
> > To:<[e-mail]>
> > Cc:<[e-mail]>
> > Sent: Monday, August 23, 2010 7:00 PM
> > Subject: [Netconf] I-D Action:draft-ietf-netconf-4741bis-04.txt
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> > This draft is a work item of the Network Configuration Working Group of the
> > IETF.
> >
> >
> > Title           : Network Configuration Protocol (NETCONF)
> > Author(s)       : R. Enns, et al.
> > Filename        : draft-ietf-netconf-4741bis-04.txt
> > Pages           : 121
> > Date            : 2010-08-23
> >
> > The Network Configuration Protocol (NETCONF) defined in this document
> > provides mechanisms to install, manipulate, and delete the
> > configuration of network devices.  It uses an Extensible Markup
> > Language (XML)-based data encoding for the configuration data as well
> > as the protocol messages.  The NETCONF protocol operations are
> > realized as Remote Procedure Calls (RPC).
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-netconf-4741bis-04.txt
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > Netconf mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netconf
> >
> 
> _______________________________________________
> Netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C