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

[Andy Bierman <[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.

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

For any YANG content that may contain ]]>]]> unintentionally, the YANG 'binary' data type
should be used, since XML element content does not allow ]]>]]>.

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


>
>
>> -----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
>
>