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

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Sun, 3 Oct 2010 19:15:52 +0200

Dear NETCONF Members,

I hope this mail motivates the Netconf community to 
comment or raises at least some discussion on the 
content of 4741bis. 

As you know 4741bis is the base protocol document 
for NETCONF. Please comment on the 4741bis draft.
It would be actually sufficient to say: "I read it 
and it is ready to ship."

[Co-chair hat off]

I had read the document but read again. 
I couldn't find any serious issues and I think it is 
ready for publication though I have a few suggestions
to make it more consistent and to improve the clarity 
as a standard-track document.

Section 1.1. Terminology

I would suggest to bring the terms client/manager/
application vs. agent/server/device as early as 
possible into relation. The document mainly avoids 
the usage of the terms manager and agent though 
there are some leftovers.

OLD: 
   client: A client invokes protocol operations on a server.
NEW: 
   client: A client (manager, application) invokes 
   protocol operations on a server (agent, device).

OLD: 
   server: A server executes protocol operations invoked by a client.
NEW: 
   server: A server (agent, device) executes protocol 
   operations invoked by a client (manager, application).

Section 1.2. Protocol Overview

To get it consistent with the rest of the document it would 
be good to use only singular for layer titles.

s/Operations/Operation/
s/Messages/Message/
s/Secure Transports/Secure Transport/
s/The Messages layer/The Message layer/
s/The Operations layer/The Operation layer/

Section 1.4. Separation of Configuration and State Data

OLD:
   For example, if a local database of user authentication data is
   stored on the device, it is an implementation-dependent matter
   whether it is included in configuration data.
NEW:
   For example, if a local database of user authentication data is
   stored on the device, it is implementation-dependent, whether 
   it is included in configuration data.

Section 3. XML Considerations

Concerning the mail-thread on "how to handle XML parse 
errors" I agree with the last proposed text.

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

NEW:
   All NETCONF messages MUST be well-formed XML, encoded in UTF-8.  
   If a server receives a message that is not well-formed XML, it MUST
   reply with an 'operation-failed' error.

A few sentences on this issue should be added to 
the security considerations section (see below).

Section 3.2. No Document Type Declarations

The title sounds like a command.
Change to "Document Type Declarations".

Section 4.3. <rpc-error> Element

s/layer: Messages/layer: Message/
s/layer: Operations/layer: Operation/

Section 5.2. Data Modeling

"Devices and managers may support multiple data models, ..."

s/managers/applications/

Section 7.5. <lock>

To differentiate from Partial Lock RFC clearly, I would 
underline that the operation is on the entire configuration 
datastore.

OLD: 
   The lock operation allows the client to lock the configuration
   system of a device.
NEW:
   The lock operation allows the client to lock an entire configuration
   datastore of a server.

I also would suggest to keep using the term "configuration 
datastore" instead of "configuration", which is used in other 
parts of the document to mean a specific part of the 
configuration of a datastore.

E.g.
"An attempt to lock the configuration datastore MUST..."
"The target configuration datastore is <candidate>,..."
"The target parameter names the configuration datastore that will be
locked."

Sec. 1.1. says: 
"session: Client and server exchange messages using a secure, 
connection-oriented session."

Sec. 2.1. Connection-Oriented Operation says: 
"For example, when a lock is acquired by a client, the lock 
persists until either it is explicitly released or the server 
determines that the connection has been terminated."

Sec. 2.3. Authentication says: 
"The access permissions of a given client, identified by its 
NETCONF username, are part of the configuration of the NETCONF 
server. These permissions MUST be enforced during the remainder 
of the NETCONF session."

Sec. 7.5 says:
"The <kill-session> operation can be used to force the 
release of a lock owned by another NETCONF session."

How a client can release a lock which is owned by another 
session needs to be elaborated. E.g. Partial Lock RFC says: 
"If needed, the returned session-id may be used to <kill-session> the
NETCONF session holding the lock."

I actually would suggest to delete this sentence in section 7.5. 
and stick to the statement in section 2.1. 

Section 7.7. <get>

"filter:
   This parameter specifies the portion of the system
   configuration and state data to retrieve.  If this parameter is
   not present, all the device configuration and state information
   is returned."

For the sake of completeness I would add what happens 
if the filter parameter is available but empty.

Section 8.4.1. Description

s/configuration, /configuration. /

Section 8.4.1. Description and 8.6.1. Description

OLD:
   The current version is 1.1, and is defined in this document. It
extends...
NEW:
   The version 1.1 is defined in this document and extends...

Section 12.2. Informative References

Add draft-ietf-netmod-yang-usage-11 as informative reference.

Section 9. Security Considerations

I would suggest to add a few sentences for the EOM handling 
and the possible thread concerning section 3. It would be 
interesting to recommend a possible reaction if this happens 
frequently, e.g. to drop the NETCONF session.

Appendix B. XML Schema for NETCONF Messages Layer

s/XML Schema for NETCONF Messages Layer/
XML Schema for NETCONF Message Layer/

Cheers,
Mehmet

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of ext Bert (IETF) Wijnen
> Sent: Thursday, September 23, 2010 1:48 PM
> To: Netconf
> Subject: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft-
> ietf-netconf-4741bis-04.txt
> 
> 
>   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:<[email-masked]>
> > To:<[email-masked]>
> > Cc:<[email-masked]>
> > 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
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/netconf
> >
> 
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 3 Oct 2010 19:24:55 +0200

>    operations invoked by a client (manager, application).

I am against this change. The terminology is client and server; if
there are any leftovers of other terms, we should remove them. There
is a huge difference between a device and a NETCONF server, same for
an application and a NETCONF client.
 
> frequently, e.g. to drop the NETCONF session.

4741bis does not have an EOM marker - so how can we discuss it in
the security considerations?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Andy Bierman <[email-masked]>
Date: Sun, 3 Oct 2010 10:53:08 -0700

Hi,

I agree with Juergen that we should stick with client/server terminology.

Andy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Sunday, October 03, 2010 10:25 AM
To: Ersue, Mehmet (NSN - DE/Munich)
Cc: Netconf
Subject: Re: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft-ietf-netconf-4741bis-04.txt

 

/js

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Sun, 3 Oct 2010 21:33:06 +0200

> I agree with Juergen that we should stick with client/server

This is also what I want. As this is the Terminology section
the description of client (server) could also contain the 
relation to other terms.

Mehmet

> Behalf Of Juergen Schoenwaelder
> Subject: Re: [Netconf] We NEED RESPONSES: WG Last Call ended
for:draft-

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Sun, 3 Oct 2010 21:42:25 +0200

> the security considerations?

EOM handling is for sure not part of NETCONF but the possible 
thread concerning EOM handling is. I think security considerations 
section should discuss the related security thread, as we did on 
NETCONF ML with a long mail thread.

Cheers,
Mehmet

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 3 Oct 2010 22:55:40 +0200

> NETCONF ML with a long mail thread.

There is no EOM issue if you run NETCONF over BEEP. We should stick to
modularity and discuss things where they belong. Perhaps you want
different text than the one I currently image you want...

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 06 Oct 2010 11:42:03 +0200

> different text than the one I currently image you want...

SSH is the *mandatory* transport, so any appearance of ']]>]]>' in the
Messages, Operation or Content layer necessarily has an impact on
operation and is a potential security hole. So I agree with Mehmet that
4741bis should not dismiss this issue completely. The protocol
modularity has been damaged by the unfortunate EOM choice.

Apart from Security Considerations, text in Sec. 3 should be changed as
follows:

OLD

NEW

  All NETCONF messages MUST be well-formed XML, encoded in UTF-8, and
  MUST NOT contain the character sequence ']]>]]>'.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 6 Oct 2010 12:35:33 +0200

>   MUST NOT contain the character sequence ']]>]]>'.

Still I believe it is the transport that has to deal with this. If a
message contains ']]>]]>', a transport that can not handle this should
either not accept to transport that message or have a mechanism to
deal with it by quoting it or whatever. Pushing this issue up to the
content layer just on the ground that the mandatory SSH transport is
not totally robust seems odd from an architectural point of view.

/js

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 6 Oct 2010 13:04:29 +0200

> not totally robust seems odd from an architectural point of view.

It is true that NETCONF does not have any awareness of EOM character
sequence. NETCONF is aware of "well-formed XML" messages. The proposed 
text by Martin defines what NETCONF should do (on its level) if the XML 
message is not well-formed.

: NEW:
:    All NETCONF messages MUST be well-formed XML, encoded in UTF-8.  
:    If a server receives a message that is not well-formed XML, it MUST
:    reply with an 'operation-failed' error.

However, although EOM handling is not an issue on NETCONF level NETCONF 
has a concrete security thread if XML messages are not well-formed 
frequently. I proposed to discuss the security thread in the security
considerations section.

Mehmet

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 06 Oct 2010 13:37:30 +0200 (CEST)

Hi,

>    operations invoked by a client (manager, application).

I agree with my co-editors that we should stick to the client/server
terminology.  There are a couple of places in the document where we
should change the terminology from e.g. application to client.

> s/The Operations layer/The Operation layer/

I agree that singular makes more sense.  I support this change.  What
do others think?

>    it is included in configuration data.

Why is the new text better?

>    reply with an 'operation-failed' error.

The chairs must tell us what to do with this issue.

> Change to "Document Type Declarations".

Ok.

> s/layer: Operations/layer: Operation/

See above.

> "Devices and managers may support multiple data models, ..."

I'd prefer "Clients and servers may support...".

>    The lock operation allows the client to lock an entire configuration

Ok.

> configuration of a datastore.

Ok.

> and stick to the statement in section 2.1. 

I think the text in 7.5 gives useful information.  I am not sure why
you think it needs to be removed.

> if the filter parameter is available but empty.

If the filter parameter is present, the 'type' attribute specifies if
it is a subtree filter or xpath filter.  If no 'type' attribute is
present, it defaults to subtree filtering.  Section 6 describes this
algorithm, and specificially 6.4.2 specifies how an empty subtree
filter works.  I don't think we should say anything about special
filter values in 7.7.

> s/configuration, /configuration. /

OK.

>    The version 1.1 is defined in this document and extends...

Ok, I did:  Version 1.1. is defined in this document and extends...

> Add draft-ietf-netmod-yang-usage-11 as informative reference.

Why?  That document is intended for YANG module writers.

> frequently, e.g. to drop the NETCONF session.

I'll await the current ML discussion...

> XML Schema for NETCONF Message Layer/

See above.

/martin

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 6 Oct 2010 14:24:23 +0200

Hi Martin,

> should change the terminology from e.g. application to client.

The text I proposed may be a bit misleading but this is 
what I want too. 

I just propose to bring the terms into relation as early 
as possible in the terminology section. Then we can use 
only client/server.
 
> Why is the new text better?

Clear and direct? Anyway, I can go with both.
 
> I'd prefer "Clients and servers may support...".

Fine.
 
> you think it needs to be removed.

I agree that the text in quotations marks above gives useful 
information.  However it is not self-explaining. The questions
coming up are: How and whether a client is allowed to kill "any" 
session. 
 
> filter works.  I don't think we should say anything about special

Agree.

> Why?  That document is intended for YANG module writers.

Appendix C includes a normative YANG module and IANA considerations 
include namespace registration, etc., which follow the guidelines 
in draft-ietf-netmod-yang-usage. 
I think people who read the YANG module in 4741bis should be also
pointed to the guidelines document.

> /martin

Mehmet/>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 6 Oct 2010 14:51:10 +0200

> pointed to the guidelines document.

Why? The guidelines are for module writers / reviewers not module
readers. You want to have them cited in each and every module we
publish? We do not do this for MIB modules.

/js

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 6 Oct 2010 15:33:59 +0200

> publish? We do not do this for MIB modules.

It is actually the same reason why we have the informative 
reference on:

[13]  Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for the
      Use of Extensible Markup Language (XML) within IETF Protocols",
      BCP 70, RFC 3470, January 2003.
 
> /js

me/>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 6 Oct 2010 15:43:29 +0200

>       BCP 70, RFC 3470, January 2003.

Since the document in question defines a protocol that carries XML,
having this reference may seem different from requiring a reference to
the YANG guidelines how to write a YANG proper module in every YANG
module. At least in the SMIv2 space, we managed to live without it.

But then, if you feel strongly about this, lets just add it instead of
debating this long.

Lets hope the guidelines document gives the guideline that the
guidelines document select-one-of(must|MUST|should|SHOULD) be
cited. ;-)

/js

---

From: Phil Shafer <[email-masked]>
Date: Wed, 6 Oct 2010 09:30:01 -0400

>module. At least in the SMIv2 space, we managed to live without it.

Are we talking about putting a reference to yang-usage in the
netconf-bis just to say that the new yang module follows those
guidelines?

Thanks,
 Phil

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 6 Oct 2010 15:54:48 +0200

> netconf-bis just to say that the new yang module follows those

That is my understanding.

/js

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 6 Oct 2010 16:16:59 +0200

> From: ext Phil Shafer [mailto:[email-masked]]

draft-ietf-netmod-yang-usage-11 has important guideline on 
namespace registration, YANG module registration, etc., which 
are used in 4741bis.

Mehmet

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 06 Oct 2010 20:37:51 +0200

> not totally robust seems odd from an architectural point of view.

OK, but according to section 2.4 the mandatory transport protocol is RFC
4742, which does not handle the EOM issue properly. So sec. 2.4 in fact
says that every compliant implementation MUST have that security hole.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 7 Oct 2010 00:45:35 +0200

> says that every compliant implementation MUST have that security hole.

I am willing to accept an addition to the security considerations that
says that readers should consult the security considerations of the
NETCONF transports in addition to the 4741bis security considerations
section since the 4741bis security considerations only covers the base
message layer and the base operations of NETCONF. A first quick
attempt:

	This section provides security considerations for the base
	NETCONF message layer and the base operations of the NETCONF
	protocol. Security considerations for the NETCONF transports
	are provided in the transport documents and security
	considerations for the content manipulated by NETCONF can be
	found in the document defining data models.

We could add this right at the beginning of section 9 and then it
should be clear even to the causal reader that just reading section 9
of 4741bis is not sufficient to understand all security aspects of
NETCONF.

Note that this approach allows to add/fix security problems in all our
transports without causing any text in 4741bis to become obsolete or
incomplete.

/js

---

From: Andy Bierman <[email-masked]>
Date: Wed, 6 Oct 2010 16:12:44 -0700

I agree with this solution proposal from Juergen.

Andy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Wednesday, October 06, 2010 3:46 PM
To: Ladislav Lhotka
Cc: Netconf
Subject: Re: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft-ietf-netconf-4741bis-04.txt

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 7 Oct 2010 01:28:35 +0200

> I agree with this solution proposal from Juergen.

I will mark that in my calendar.

/js

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 7 Oct 2010 12:48:33 +0200

I agree and can go with this proposal too.

(You don't need a calendar mark ;)

Cheers,
Mehmet

> Behalf Of ext Andy Bierman
> Sent: Thursday, October 07, 2010 1:13 AM
> To: Juergen Schoenwaelder; LadislavLhotka
> Cc: Netconf
for:draft-
for:draft-
> > > > On Sun, 3 Oct 2010 22:55:40 +0200, Juergen Schoenwaelder
> <[email-masked]> wrote:
> > > > > > > 4741bis does not have an EOM marker - so how can we
discuss
> it in
> > > > > > section should discuss the related security thread, as we
did
> on
> > > >   All NETCONF messages MUST be well-formed XML, encoded in
UTF-8,
> and

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 07 Oct 2010 13:03:06 +0200

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" <[email-masked]> wrote:
>   It was pointed out to me that we did not get ANY comments to this WGLC.
> 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
> > WG participants, this email starts a formal WG Last Call for revision 4
> > of the 4741bis document. The document is targeted as Proposed Standard
> > This draft is a work item of the Network Configuration Working Group of the
> > IETF.
> >
> >
> > The Network Configuration Protocol (NETCONF) defined in this document
> > Language (XML)-based data encoding for the configuration data as well

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 7 Oct 2010 13:43:15 +0200

Hi Lada,

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

Cheers,
Mehmet

> Behalf Of ext Ladislav Lhotka
> Sent: Thursday, October 07, 2010 1:03 PM
> To: Bert (IETF) Wijnen; Netconf
for:draft-
> revision 4

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 07 Oct 2010 14:00:24 +0200

> restlessly. However, this would cause a V2.0 and it'll be 

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

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Thu, 07 Oct 2010 08:11:32 -0700

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

Andy

>>     "If additional attributes are present in an<rpc>  element, a
> NETCONF
>>     peer MUST return them unmodified in the<rpc-reply>  element.  This
>>     XML elements or attributes, if there is any, e.g.<nc:config>
> rather
>>     than<config>. This is especially important for attribute names
>>     of the first interface or change<name>  of the other.
>>
>> 8. Sec. 7.5, p. 49:
>>
>>     "Each peer sends its<hello>  element simultaneously ..."
>>
>>     "A<commit>  operation may be performed at any time that causes the
>>     <hello>  with different content model: server's<hello>  must have
>>     exactly one session-id attribute whereas client's<hello>  must not

---

From: Andrew Stone <[email-masked]>
Date: Thu, 7 Oct 2010 11:45:58 -0400

"A NETCONF message MAY begin with an XML declaration (see section 2.8
of [1 <http://tools.ietf.org/html/draft-ietf-netconf-4741bis-04#ref-1>])."

Since the XML declaration is optional, shall we clarify which version of XML
must be used if the declaration is NOT included?

And perhaps require that servers handle all XML versions (1.0 and 1.1)
following the protocol design philosophy that "receivers" should be generous
in what they accept?  If we do not require this, we could get clients that
can't communicate with servers because the client sends XML ver 1.1 (say)
and the server only accepts 1.0.

Or just keep it simple and require that all NETCONF messages be XML version
1.1.

Regards,
Andrew

---

From: Andy Bierman <[email-masked]>
Date: Thu, 07 Oct 2010 09:12:45 -0700

On 10/07/2010 08:45 AM, Andrew Stone wrote:
> "A NETCONF message MAY begin with an XML declaration (see section 2.8 of [1  <http://tools.ietf.org/html/draft-ietf-netconf-4741bis-04#ref-1>])."
>
>
> Since the XML declaration is optional, shall we clarify which version of
> XML must be used if the declaration is NOT included?
>
> following the protocol design philosophy that "receivers" should be
> generous in what they accept?  If we do not require this, we could get
> clients that can't communicate with servers because the client sends XML
> ver 1.1 (say) and the server only accepts 1.0.
>
> Or just keep it simple and require that all NETCONF messages be XML
> version 1.1.

I sort of object to this change. (3/4 objection?)

It would be OK to say a server MUST support 1.0 and SHOULD or MAY support 1.1.
It seems like the version MUST be present if a server is required to support
multiple versions of XML.

Andy

>
>
> On Sun, Oct 3, 2010 at 1:15 PM, Ersue, Mehmet (NSN - DE/Munich)
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Dear NETCONF Members,
>
>      > From: [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>] On
>      > > From:<[email-masked] <mailto:[email-masked]>>
>      > > To:<[email-masked] <mailto:[email-masked]>>
>      > > Cc:<[email-masked] <mailto:[email-masked]>>
>      > > [email-masked] <mailto:[email-masked]>
>      > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 7 Oct 2010 18:17:32 +0200

> From: ext Andy Bierman [mailto:[email-masked]]

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

This is clearly stated in 4742bis.
 
> 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.
 
> in 4742bis (MUST NOT send ]]>]]>) is sufficient to solve the problem.

ME/>
 
> >>     I think it would be better to indicate the namespace in the
> names
> > of
> >>     I don't understand what this means. Is it that the subtree
> pointed
> >> to

---

From: Andrew Stone <[email-masked]>
Date: Thu, 7 Oct 2010 13:15:26 -0400

I'm not really advocating right now.  Just pointing out a "hole" or
"ambiguity" that could cause client/server communications issues and some
possible solutions.

And trying to raise awareness; if we want cross-vendor client/server
compatibility this issue needs to be clarified.

There does not seem to be a good way for the client/server to negotiate XML
versions since the capabilities in the <hello> message is itself XML.  Nor
is there a good way to return an "XML version unsupported" error, both
because there is no general catchall "error" message and also because the
returned error would be in some version of XML itself and therefore
potentially unreadable by the receiver.

Note as a corollary, what to do with malformed XML seems undefined.

So it seems like to achieve cross vendor compatibility we must either
require that servers (or clients actually) handle all XML versions, or pick
one version and REQUIRE it, or add some version negotiation messages.

Some specific ideas.

1. Require that certain messages be XML 1.0 (hello with another
"capabilities" tag describing the support XML versions), so can be
understood by all servers.  This is sort of a pain from a software
perspective because a lot of XML 1.1 libraries automatically optimize
<a></a> to <a/>.

2. Require that servers try to parse using both formats (if it gets a parse
error, try the other format) if the XML header is not there.  But it would
require analysis to show that this would result in provably correct behavior
(i.e. no possible XML 1.1 string could be successfully parsed by XML 1.0 in
a semantically different way, and vice versa).  It also puts a computational
and code size burden on servers, pushing NETCONF away from highly embedded
devices -- XML is already very expensive to parse why make it worse?  Of
course a smart server could "learn" what the client is likely using.  Is XML
1.1 a superset of XML 1.0 (I'm not positive but its definitely pretty
close)?

3. Require that the "hello" message contain the XML declaration (containing
the version), and assume that as the default for this session.  Of course
this also means that servers must be required to speak both XML versions (or
we have to add an unsupported XML version error message), but at least the
client is free to use whatever is convenient.

4. Drop the connection on parse error -- client side could then reconnect
with a different XML version.  But establishing connections is expensive and
just dropping the connection is an ambiguous response -- the connection
could be closed for many reasons, like server overload or idle timeout, or
any other transport level issue.  So I think this solution is not so good.

Regards,
Andrew

On Thu, Oct 7, 2010 at 12:12 PM, Andy Bierman <[email-masked]> wrote:

>> "A NETCONF message MAY begin with an XML declaration (see section 2.8 of
>> [1  <http://tools.ietf.org/html/draft-ietf-netconf-4741bis-04#ref-1>])."
>>
>>
>>