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

[Phil Shafer <phil at juniper.net>]

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.

>:   When the schema is available on the device this operation is
>:   used to return it via NETCONF.
>
>This conditional sentence sounds backwards. What about this:
>
>     This operation can be used to retrieve a schema form the NETCONF
>     server.

Needs to indicate that the schema form cannot always be
retrived.  My earlier suggestion was s/When/If/, but
that wasn't incorporated.

>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.

Thanks,
 Phil