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

From: "Andy Bierman" <[email-masked]>
Date: Wed, 06 Oct 2010 08:00:40 -0700

No.
Netconf uses XML.  There is no requirement that YANG be used at all.
It certainly does not factor into protocol conformance.

Andy

----- Reply message -----
From: "Phil Shafer" <[email-masked]>
Date: Wed, Oct 6, 2010 06:30
Subject: [Netconf] We NEED RESPONSES: WG Last Call ended	for:draft-ietf-netconf-4741bis-04.txt
To: "Juergen Schoenwaelder" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>

Juergen Schoenwaelder writes:
>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.

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

---

From: "Andy Bierman" <[email-masked]>
Date: Wed, 06 Oct 2010 08:09:17 -0700

I think this WG needs to make decisions and stick to them.
Changing error handling for malformed XML is not an editorial change.   The WG did not reach consensus and the chairs declared the issue closed.  Why is it open again?

Andy

----- Reply message -----
From: "Martin Bjorklund" <[email-masked]>
Date: Wed, Oct 6, 2010 04:37
Subject: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft-ietf-netconf-4741bis-04.txt
To: <[email-masked]>
Cc: <[email-masked]>

Hi,

"Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]> wrote:
> [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).

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.

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

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

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

Why is the new text better?

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

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

> Section 3.2. No Document Type Declarations
> 
> The title sounds like a command.
> Change to "Document Type Declarations".

Ok.

> Section 4.3. <rpc-error> Element
> 
> s/layer: Messages/layer: Message/
> s/layer: Operations/layer: Operation/

See above.

> Section 5.2. Data Modeling
> 
> "Devices and managers may support multiple data models, ..."
> 
> s/managers/applications/

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

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

Ok.

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

Ok.

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

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

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

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.

> Section 8.4.1. Description
> 
> s/configuration, /configuration. /

OK.

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

Ok, I did:  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.

Why?  That document is intended for YANG module writers.

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

I'll await the current ML discussion...

> Appendix B. XML Schema for NETCONF Messages Layer
> 
> s/XML Schema for NETCONF Messages Layer/
> XML Schema for NETCONF Message Layer/

See above.

/martin