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

[Ladislav Lhotka <[e-mail]>]

On Čt, 2010-10-07 at 13:43 +0200, Ersue, Mehmet (NSN - DE/Munich) wrote:
> Hi Lada,
> 
> > 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.
> 
> We discussed this several times and came several times to the 
> same conclusion. 
> A comprehensive solution would be needed to address the issue 
> restlessly. However, this would cause a V2.0 and it'll be 
> incompatible with V1.0.

Then my second alternative applies. I would find it very strange if the
NETCONF protocol standard mandated the support of a transport protocol
that's arguably broken, even though people differ in the assessment of
how serious the flaw is.

Lada
 
> 
> By our charter 4741bis and 4742bis do not have the mandate for 
> V2.0(!).
> Therefore we decided to keep the current solution and describe 
> the possible security thread unmistakably.
> 
> Good or bad, IIRC this is the factual report of the situation.
> 
> Cheers,
> Mehmet
> 
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On
> > Behalf Of ext Ladislav Lhotka
> > Sent: Thursday, October 07, 2010 1:03 PM
> > To: Bert (IETF) Wijnen; Netconf
> > Subject: Re: [Netconf] We NEED RESPONSES: WG Last Call ended
> for:draft-
> > ietf-netconf-4741bis-04.txt
> > 
> > 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
> > _______________________________________________
> > Netconf mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netconf

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C