Subject: [Netconf] Fwd: David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT)

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Wed, 02 Mar 2011 09:15:08 +0100

Can the editors/authors of the document take a look at the below
please.

Bert

-------- Original Message --------
Subject: 	David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT)
Date: 	Tue, 01 Mar 2011 15:05:55 -0800
From: 	David Harrington <[email-masked]>
To: 	The IESG <[email-masked]>
CC: 	[email-masked], [email-masked]

David Harrington has entered the following ballot position for
draft-ietf-netconf-4741bis-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

1) should there be constraints on the basic format of username? if it is expected to be specified by an operator in config files or databases, should it be human-readable? ascii? utf-8?

2) should the format be predictable, so the operator can determine what the NC username will be, given a knowledge of the corresponding identifier in the secure transport protocol?

3) commit MUST revert at 600 secs, but timeout is configurable., what if somebody sets it to 700 seconds? MUST it still revert at 600? Can a low timeout cause a denial of service?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

1) copyright in yang module needs updating.

2) appendix F doesn't mention dropping the local file requirement for URLs,

3) terminology should probably define username, not user. It is doubtful username is commonly referred, since it did not exist in 1.0.

4) I found the use of RFC2119 laniguage rather inconsistent. Some uses of "can" probbaly should have been MAY. Some uses of "are" probbaly should have been MUST, to ensure interoperability.

5) I support Lars' Discuss. There is no requirement to use a transport protocol that provides congestion control. If a transport is used that does not already provide congestion control, then the NC transport should provide congestion control. It is RECOMMENDED to use an existing transprt standard that provides congestion control.