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

["Bert (IETF) Wijnen" <[e-mail]>]

More answers/comments from Juergen below.

Can I ask mister Harrington to participate in the discussion on the
NETCONF WG mailing list? That is the only way to get to convergence
in a reasonable amount of time. Dave, you ARE a particpant in the WG,
and I hope you can pay attention there till we reach agreement on this
DISCUSS. I hate to have to keep forarding yoru emails to the WG and
then forward any WG technical responses back to you.
That is not productive, and things may get lost in that path.

Thanks,
Bert Wijnen
Document shepherd

-------- Original Message --------
Subject: 	Re: [Netconf] FW: David Harrington's Discuss on draft-ietf-netconf-rfc4742bis-07: (withDISCUSS and COMMENT)
Date: 	Thu, 3 Mar 2011 18:07:23 +0100
From: 	Juergen Schoenwaelder <[e-mail]>
Reply-To: 	Juergen Schoenwaelder <[e-mail]>
To: 	Ersue, Mehmet (NSN - DE/Munich) <[e-mail]>
CC: 	Netconf <[e-mail]>



On Thu, Mar 03, 2011 at 05:08:01PM +0100, Ersue, Mehmet (NSN - DE/Munich) wrote:

>  Any comments? Pls also check the mail below from
>  David Harrington.

[... stuff removed I figured out is not helpful to send ...]

NETCONF is the wrong place to constraint user name. For SSH, this is
a no-brainer anyway.

/js

PS: We dealt with the uniquess questions explaining that this is an
     ACM issue and note that it is even mentioned in the Security
     Considerations section:

    [...] Second, it could be desirable to authorize based on
    mechanisms available in the secure transport layer (SSH, BEEP, etc).

PS: RFC 4252 says:

       byte      SSH_MSG_USERAUTH_REQUEST
       string    user name in ISO-10646 UTF-8 encoding [RFC3629]

     RFC 4251 says:

    string

       Arbitrary length binary string.  Strings are allowed to contain
       arbitrary binary data, including null characters and 8-bit
       characters.  They are stored as a uint32 containing its length
       (number of bytes that follow) and zero (= empty string) or more
       bytes that are the value of the string.  Terminating null
       characters are not used.

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
Fax:   [phone]<http://www.jacobs-university.de/>
______________________





On 3/2/11 12:05 AM, David Harrington wrote:
> 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.
>
>
>
>