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

[Martin Bjorklund <[e-mail]>]

Hi,

"Ersue, Mehmet (NSN - DE/Munich)" <[e-mail]> 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