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

" Andy Bierman " <ietf@andybierman.com> Wed, 06 October 2010 15:08 UTC

Return-Path: <ietf@andybierman.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99B043A7115 for <netconf@core3.amsl.com>; Wed, 6 Oct 2010 08:08:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.725
X-Spam-Level:
X-Spam-Status: No, score=0.725 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, FROM_EXCESS_BASE64=1.456, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, SARE_SUB_ENC_UTF8=0.152]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ays7nNaAz6sG for <netconf@core3.amsl.com>; Wed, 6 Oct 2010 08:08:09 -0700 (PDT)
Received: from omr12.networksolutionsemail.com (omr12.networksolutionsemail.com [205.178.146.62]) by core3.amsl.com (Postfix) with ESMTP id E79E73A70CF for <netconf@ietf.org>; Wed, 6 Oct 2010 08:08:07 -0700 (PDT)
Received: from cm-omr7 (mail.networksolutionsemail.com [205.178.149.5] (may be forged)) by omr12.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id o96F97A6031826 for <netconf@ietf.org>; Wed, 6 Oct 2010 11:09:07 -0400
Authentication-Results: cm-omr7 smtp.user=ietf@andybierman.com; auth=pass (LOGIN)
X-Authenticated-UID: ietf@andybierman.com
Received: from [173.126.165.113] ([173.126.165.113:34311] helo=[173.126.165.113]) by cm-omr7 (envelope-from <ietf@andybierman.com>) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 2B/91-03446-D019CAC4; Wed, 06 Oct 2010 11:09:07 -0400
To: Martin Bjorklund <mbj@tail-f.com>, mehmet.ersue@nsn.com
Message-ID: <2B.91.03446.D019CAC4@cm-omr7>
From: Andy Bierman <ietf@andybierman.com>
Date: Wed, 06 Oct 2010 08:09:17 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_3_1286377757401"
Cc: netconf@ietf.org
Subject: Re: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft-ietf-netconf-4741bis-04.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Oct 2010 15:08:10 -0000

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" <mbj@tail-f.com>
Date: Wed, Oct 6, 2010 04:37
Subject: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft-ietf-netconf-4741bis-04.txt
To: <mehmet.ersue@nsn.com>
Cc: <netconf@ietf.org>


Hi,

"Ersue, Mehmet (NSN - DE/Munich)" <mehmet.ersue@nsn.com> 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
_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf