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

["Ersue, Mehmet (NSN - DE/Munich)" <[e-mail]>]

> From: ext Andy Bierman [mailto:[e-mail]]
> On 10/07/2010 04:43 AM, 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.
> >
> > 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.
> >
> 
> thanks.
> Since ]]>]]> is not special in BEEP (for example), text about it does
> not
> belong in 4741bis.

Yes.
 
> It is fine to say that a NETCONF client that sends ]]>]]> as content
is
> broken.

This is clearly stated in 4742bis.
 
> For any YANG content that may contain ]]>]]> unintentionally, the YANG
> 'binary' data type
> should be used, since XML element content does not allow ]]>]]>.

I am not sure whether this belongs to 4742bis but this can be 
added as appropriate.
 
> We have NACM in the works to control what a session can do once it is
> authenticated,
> to address most data injection attacks.
> 
> The only real exposure in the standard are the client-provided XML
> attributes that
> the server must return in the <rpc-reply>. Since the client controls
> this, the rule
> in 4742bis (MUST NOT send ]]>]]>) is sufficient to solve the problem.
> 
> > Cheers,
> > Mehmet
> 
> Andy

ME/>
 
> 
> >
> >
> >> -----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
> > _______________________________________________
> > Netconf mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netconf
> >
> >