Re: [Netconf] draft-ietf-netconf-monitoring-09 last call comments from js

[Juergen Schoenwaelder <j.schoenwaelder at jacobs-university.de>]

On Tue, Nov 03, 2009 at 03:38:38AM +0100, Phil Shafer wrote:
> Juergen Schoenwaelder writes:
> >:   username (string)
> >:     If present, the username contains an identifier which can be
> >:     used to uniquely identify an individual client (human or
> >:     machine).  This is likely to be implementation specific and
> >:     subject to the security requirements of the device vendor
> >:     and/or operators,  e.g., an SSH user, a host RSA fingerprint
> >:     or other identifier deemed acceptable.
> >
> >I do not want to boil the ocean, but we will likely have to work this
> >out in more detail later when access control is defined and we need a
> >deterministic way to derive a username from whatever has been used for
> >authentication. Those who follow the ISMS work will know why I have to
> >comment on this. So take this as a warning that in the future, we will
> >have to define much more precise ways to derive a username if we
> >associate access control rules with user identities.
> 
> There's also the issue of radius/tacplus users, where the "user
> name" and "login name" are distinct and both are needed.

Not sure I understand your comment - why does radius/tacplus lead to a
difference between a "user name" and a "login name"? Which AVPs are
you referring to?

> >I am badly missing description statements here. In general, it seems
> >that many description statements leave out details that are explained
> >in section 2. In SMIv2 land, it was considered good practice to have
> >all normative texts in the data model so that the text is there once
> >extracted from the RFC. I believe we should follow this practice and
> >move most of the text from section 2.1 into description clauses. This
> >also avoids any potential inconsistencies.
> 
> Amen.  Can we go further and encourage the YANG module to _be_
> the full RFC, so extracting the module gives the full normative
> text of the RFC inside the module?  So the RFC is some introductory
> text, followed by the YANG module with all the normative text as
> comments or descriptions inside that file.  Extracting the module
> gives you everything and there's not duplicate text to get out of
> sync or to add confusion.

This is pretty much what we have been doing in SMIv2 land.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>