YANG Module for NETCONF Monitoring
draft-ietf-netconf-monitoring-15

[Ballot comment]
Section 3.1

Are there no other negative responses to get-schema? What about policy
failures?

---

Please think about whether the Reference clauses that cite RFC4741
should actually point to 4741bis.

[Ballot discuss]
I think [4741bis] is used normatively. Please makeit a normative
reference.

---

Aren't the RFCs cited from Reference clauses really normative
references?

(As Dave says, to avoid citation issues, you should include some text
such as...

"This module makes use of references to [1], [2], ..." )

[Ballot comment]
1) section provides an overview of data "which MUST be present". "MUST" is usually used to specify normative behavior. I suggest you specifically say that section 2 is a "non-normative overview", so that if there are errata that lead to conflicts between 2 and 5, there is no question that section 2 is non-normative, and section 5 is normative.

2) login-time. since clocks on the server and client can differ, this should say the "Time at the server at which the session was established."

3) source-host: this is the netconf client? (which could be different than, say, the SSH client or the TLS client, etc.)

4) leaf source-host
s/is likely to be implementation-specific
/is implementation-specific

[Ballot discuss]
Hmmm, my DISCUSS comments were not included in the datatracker. Saving and emailing again.

Good job. I am glad to see this work and the YANG work progressing.
I have a few thinsg i think should be addressed before this is approved as a standard.

1) username - in ISMS we had a lot of trouble determining when and if the user-name from SSH was actually available, and the SSH username can be blank (IIRC). In other transport authentication schemes, a username may not be available. But this information might be critical for use in access control decisions, which currently are implementation-specific. Security considerations does not discuss this potential problem.
In ISMS, SSHTM permitted transformations from the "username" used by the transport to a management-system specific identifier. In USM, this is also done via a user table assignment. You should be careful about locking yourself in.

2) existing security infrastructures, such as SSH, may offer features that would make doing a direct mapping between user-name and the nsm username.
  Because naming policies might differ between administrative domains,
  many SSH client software packages support a user@hostname:port
  addressing syntax that operators can use to align non-equivalent
  account names.  The SnmpSSHAddress Textual Convention echos this
  common SSH notation.
Again, you might want to avoid a direct mapping requirement.

I recommend removing the statement about how username is set from SSH, and simply state that the identity is established by the Netconf transport protocol. Let the Netconf-ssh decide how to establish a username.

3) the algorithm to derive the username is implementation-specific. The security considerations should discuss that different implementations might derive the same username for different users, so the value might not be comparable across implementatons. In ISMS, we addressed the issue that an SSH transport model might come up wth a name, and then a TLS transport model come up with the same name, even within the same management system. Given that the username might be used to identify who made an undesirable change, and to discipline that person, this is a pretty big "well, maybe this means this user, and maybe it means that user."

4) Your use of "RFC XXXX" is ambiguous. "identity YANG" and "identity yin" call for a reference to RFC XXXX (the YANG RFC), as does the "module" and "revision" statements (the monitoring RFC). These are different XXXX's.

5) container sessions has an exclusion statement that can be interpreted different ways:
"Any session not managed by the NETCONF server ... MUST be excluded" versus
"(Any session ... with session identifier 0) MUST be excluded"
versus
"(Any session not managed ... with session identifier 0) MUST be excluded" (which would exclude all non-zero sessions)
Can you tighten this?

6) To avoid unused reference warnings from idnits, in MIB modules we specify outside the module itself what normative references exist in the module and provide citations.

[Ballot comment]
1) section provides an overview of data "which MUST be present". "MUST" is usually used to specify normative behavior. I suggest you specifically say that section 2 is a "non-normative overview", so that if there are errata that lead to conflicts between 2 and 5, there is no question that section 2 is non-normative, and section 5 is normative.

2) login-time. since clocks on the server and client can differ, this should say the "Time at the server at which the session was established."

3) source-host: this is the netconf client? (which could be different than, say, the SSH client or the TLS client, etc.)

4) leaf source-host
s/is likely to be implementation-specific
/is implementation-specific

[Ballot discuss]
Good job. I ma glad to see this work and the YANG work progressing.
I have a few thinsg i think should be addressed before this is approved as a standard.

1) username - in ISMS we had a lot of trouble determining when and if the user-name from SSH was actually available, and the SSH username can be blank (IIRC). In other transport authentication schemes, a username may not be available. But this information might be critical for use in access control decisions, which currently are implementation-specific. Security considerations does not discuss this potential problem.
In ISMS, SSHTM permitted transformations from the "username" used by the transport to a management-system specific identifier. In USM, this is also done via a user table assignment. You should be careful about locking yourself in.

2) existing security infrastructures, such as SSH, may offer features that would make doing a direct mapping between user-name and the nsm username.
  Because naming policies might differ between administrative domains,
  many SSH client software packages support a user@hostname:port
  addressing syntax that operators can use to align non-equivalent
  account names.  The SnmpSSHAddress Textual Convention echos this
  common SSH notation.
Again, you might want to avoid a direct mapping requirement.

I recommend removing the statement about how username is set from SSH, and simply state that the identity is established by the Netconf transport protocol. Let the Netconf-ssh decide how to establish a username.

3) the algorithm to derive the username is implementation-specific. The security considerations should discuss that different implementations might derive the same username for different users, so the value might not be comparable across implementatons. In ISMS, we addressed the issue that an SSH transport model might come up wth a name, and then a TLS transport model come up with the same name, even within the same management system. Given that the username might be used to identify who made an undesirable change, and to discipline that person, this is a pretty big "well, maybe this means this user, and maybe it means that user."

4) Your use of "RFC XXXX" is ambiguous. "identity YANG" and "identity yin" call for a reference to RFC XXXX (the YANG RFC), as does the "module" and "revision" statements (the monitoring RFC). These are different XXXX's.

5) container sessions has an exclusion statement that can be interpreted different ways:
"Any session not managed by the NETCONF server ... MUST be excluded" versus
"(Any session ... with session identifier 0) MUST be excluded"
versus
"(Any session not managed ... with session identifier 0) MUST be excluded" (which would exclude all non-zero sessions)
Can you tighten this?

6) To avoid unused reference warnings from idnits, in MIB modules we specify outside the module itself what normative references exist in the module and provide citations.

[Ballot comment]
1) section provides an overview of data "which MUST be present". "MUST" is usually used to specify normative behavior. I suggest you specifically say that section 2 is a "non-normative overview", so that if there are errata that lead to conflicts between 2 and 5, there is no question that section 2 is non-normative, and section 5 is normative.

2) login-time. since clocks on the server and client can differ, this should say the "Time at the server at which the session was established."

3) source-host: this is the netconf client? (which could be different than, say, the SSH client or the TLS client, etc.)

4) leaf source-host
s/is likely to be implementation-specific
/is implementation-specific

[Ballot discuss]
Good job. I ma glad to see this work and the YANG work progressing.
I have a few thinsg i think should be addressed before this is approved as a standard.

1) username - in ISMS we had a lot of trouble determining when and if the user-name from SSH was actually available, and the SSH username can be blank (IIRC). In other transport authentication schemes, a username may not be available. But this information might be critical for use in access control decisions, which currently are implementation-specific. Security considerations does not discuss this potential problem.
In ISMS, SSHTM permitted transformations from the "username" used by the transport to a management-system specific identifier. In USM, this is also done via a user table assignment. You should be careful about locking yourself in.

2) existing security infrastructures, such as SSH, may offer features that would make doing a direct mapping between user-name and the nsm username.
  Because naming policies might differ between administrative domains,
  many SSH client software packages support a user@hostname:port
  addressing syntax that operators can use to align non-equivalent
  account names.  The SnmpSSHAddress Textual Convention echos this
  common SSH notation.
Again, you might want to avoid a direct mapping requirement.

I recommend removing the statement about how username is set from SSH, and simply state that the identity is established by the Netconf transport protocol. Let the Netconf-ssh decide how to establish a username.

3) the algorithm to derive the username is implementation-specific. The security considerations should discuss that different implementations might derive the same username for different users, so the value might not be comparable across implementatons. In ISMS, we addressed the issue that an SSH transport model might come up wth a name, and then a TLS transport model come up with the same name, even within the same management system. Given that the username might be used to identify who made an undesirable change, and to discipline that person, this is a pretty big "well, maybe this means this user, and maybe it means that user."

4) Your use of "RFC XXXX" is ambiguous. "identity YANG" and "identity yin" call for a reference to RFC XXXX (the YANG RFC), as does the "module" and "revision" statements (the monitoring RFC). These are different XXXX's.

5) container sessions has an exclusion statement that can be interpreted different ways:
"Any session not managed by the NETCONF server ... MUST be excluded" versus
"(Any session ... with session identifier 0) MUST be excluded"
versus
"(Any session not managed ... with session identifier 0) MUST be excluded" (which would exclude all non-zero sessions)
Can you tighten this?

6) To avoid unused reference warnings from idnits, in MIB modules we specify outside the module itself what normative references exist in the module and provide citations.

[Ballot comment]
1) section provides an overview of data "which MUST be present". "MUST" is usually used to specify normative behavior. I suggest you specifically make section 2 a "non-normative overview", so that if there are errata that lead to conflicts between 2 and 5, there is no question that section 2 is non-normative, and section 5 is normative.

2) login-time. since clocks on the server and client can differ, this should say the "Time at the server at which the session was established."

3) source-host: this is the netconf client? (which could be different than, say, the SSH client or the TLS client, etc.)

4) username - in ISMS we had a lot of trouble determining when and if the user-name from SSH was actually available, and the SSH username can be blank (IIRC).

[Ballot discuss]
1. For the /netconf-state/schemas subtree, how are multiple versions of a given schema represented? I see two options if the schema "foobar" is supported in version "0.1" and "0.2"...

a. Two entries: (i) /identifier="foobar" + /version="0.1" (ii) /identifier="foobar" + /version="0.2"

b. One entry with a structured version string (e.g., comma-separated values): /identifier="foobar" + version="0.1,0.2"

Which is it? Please specify. (I realize there is an example in Section 4.1, but that's not enough.)

2. The format attribute defines "the data modeling language the schema is written in (currently xsd, yang, yin, rng or rnc)." But these strings are not data modeling languages -- at best they are acronyms or file endings or media types. I realize that developers "know" what these strings stand for, but they are unspecified. It might also be helpful to establish a registry of these values.

3. For the /netconf-state/sessions subtree, the list of allowable transports is unspecified, and even the listed transports (e.g., "netconf-soap") are not referenced in any way. This needs to be specified more clearly. It might also be helpful to establish a registry of these values.

[Ballot comment]
1. For the /netconf-state/schemas subtree, how are multiple versions of a given schema represented? I see two options if the schema "foobar" is supported in version "0.1" and "0.2"...

a. Two entries: (i) /identifier="foobar" + /version="0.1" (ii) /identifier="foobar" + /version="0.2"

b. One entry with a structured version string (e.g., comma-separated values): /identifier="foobar" + version="0.1,0.2"

Which is it?

2. The format attribute defines "the data modeling language the schema is written in (currently xsd, yang, yin, rng or rnc)." But these strings are not data modeling languages -- at best they are acronyms or file endings or media types. I realize that developers "know" what these strings stand for, but they are unspecified.

[Ballot discuss]
This discuss is a placeholder for already agreed updates to the security considerations section.
I will clear when the new draft appears or for an RFC Editor note inserting the following at the
beginning of the security considerations:

  The YANG module defined in this memo is designed to be accessed via
  the NETCONF protocol [RFC4741]. The lowest NETCONF layer is the secure
  transport layer and the mandatory to implement secure transport is SSH
  [RFC4742].

[Ballot comment]
1. For the /netconf-state/schemas subtree, how are multiple versions of a given schema represented? I see two options if the schema "foobar" is supported in version "0.1" and "0.2"...

a. Two entries: (i) /identifier="foobar" + /version="0.1" (ii) /identifier="foobar" + /version="0.2"

b. One entry with a structured version string (e.g., comma-separated values): /identifier="foobar" + version="0.1,0.2"

Which is it?

[Ballot comment]
2.1.3.  The /netconf-state/schemas Subtree

  version (string)
    Version of the schema supported.  Multiple versions MAY be supported
    simultaneously by a NETCONF server.

Is this related to YANG revision?


2.1.4.  The /netconf-state/sessions Subtree

  transport (identityref, transport)
    Identifies transport for each session, e.g. "netconf-ssh",
    "netconf-soap", etc.

Are you planning to have a registry for these?


3.1.  The  Operation

    format (identityref, schema-format):
      The data modeling language of the schema.
      Default value is 'yang' when not specified.
      Optional parameter.

Are you planning to have a registry for these?

4.1.  Retrieving Schema List via  Operation

  The response data can be used to determine the available schema and
  their versions.  The schema itself (i.e., schema content) is not
  returned in the response.  The optional  element contains
  a URI, which can be used to retrieve the schema by another protocol
  such as ftp or http(s), or the special value 'NETCONF', which means

Informative references to documents defining HTTP and FTP are needed here.

  that the schema can be retrieved from the device via the
  operation.

IANA comments:


NOTE: We make assignments upon approval, but we won't have an RFC number
until publication. Unless the RFC Editor provides the number earlier,
we'll have to use "RFC-ietf-netconf-monitoring-12" as a temporary
placeholder in the second assignment's ID and URI string.

Upon approval of this document, IANA will make the following
assignments in the XML NS registry at
http://www.iana.org/assignments/xml-registry/ns.html

ID: ietf-netconf-monitoring
URI: urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring
Registration template: (per section 8)
Reference: [RFC-ietf-netconf-monitoring-12]

ID: ietf-netconf-monitoring:RFC-ietf-netconf-monitoring-12
URI:
urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring:RFC-ietf-netconf-monitoring-12
Registration template: (per section 8)
Reference: [RFC-ietf-netconf-monitoring-12]

(1.a) Who is the Document Shepherd for this document? Has the 
Document Shepherd personally reviewed this version of the 
document and, in particular, does he or she believe this 
version is ready for forwarding to the IESG for publication?
 
I, Mehmet Ersue, am the Document Shepard for this document.
I have personally reviewed this version of the document and I
believe it is ready for publication.

Adequate review has occurred from WG members, and it has been
reviewed especially by Bert Wijnen, Andy Bierman, Juergen
Schoenwaelder, Phil Shafer, Balazs Lengyel and Dan Romascanu.
The issues raised in these reviews have been discussed on the
mailing list and fixed in the last versions.

(1.b) Has the document had adequate review both from key WG members 
and from key non-WG members? Does the Document Shepherd have 
any concerns about the depth or breadth of the reviews that 
have been performed?     

The document has had adequate review from working group and
non-working group members, mostly from NETCONF and NETMOD WGs. 
I do not have concerns about the depth or breadth of review. 

(1.c) Does the Document Shepherd have concerns that the document 
needs more review from a particular or broader perspective, 
e.g., security, operational complexity, someone familiar with

AAA, internationalization or XML?

No.

(1.d) Does the Document Shepherd have any specific concerns or 
issues with this document that the Responsible Area Director 
and/or the IESG should be aware of? For example, perhaps he 
or she is uncomfortable with certain parts of the document, or 
has concerns whether there really is a need for it. In any 
event, if the WG has discussed those issues and has indicated 
that it still wishes to advance the document, detail those 
concerns here. Has an IPR disclosure related to this document 
been filed? If so, please include a reference to the 
disclosure and summarize the WG discussion and conclusion on 
this issue.

There are no concerns about the technical merit of the document.

(1.e) How solid is the WG consensus behind this document? Does it 
represent the strong concurrence of a few individuals, with 
others being silent, or does the WG as a whole understand and
agree with it?

There is strong consensus to publish this document.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme 
discontent? If so, please summarise the areas of conflict in 
separate email messages to the Responsible Area Director. (It 
should be in a separate email because this questionnaire is 
entered into the ID Tracker.)

No.


(1.g) Has the Document Shepherd personally verified that the 
document satisfies all ID nits? (See 
http://www.ietf.org/ID-Checklist.html and 
http://tools.ietf.org/tools/idnits/). Boilerplate checks are 
not enough; this check needs to be thorough. Has the document 
met all formal review criteria it needs to, such as the MIB 
Doctor, media type and URI type reviews?

Yes. There are no issues.

(1.h) Has the document split its references into normative and 
informative? Are there normative references to documents that 
are not ready for advancement or are otherwise in an unclear 
state? If such normative references exist, what is the 
strategy for their completion? Are there normative references 
that are downward references, as described in [RFC3967]? If 
so, list these downward references to support the Area 
Director in the Last Call procedure for them [RFC3967].

The document has split references into normative and informative.
NETCONF Monitoring draft uses the NETCONF modeling language
YANG, which is going to be published in parallel in NETMOD WG.

(1.i) Has the Document Shepherd verified that the document IANA 
consideration section exists and is consistent with the body 
of the document? If the document specifies protocol 
extensions, are reservations requested in appropriate IANA 
registries? Are the IANA registries clearly identified? If 
the document creates a new registry, does it define the 
proposed initial contents of the registry and an allocation 
procedure for future registrations? Does it suggest a 
reasonable name for the new registry? See [RFC5226]. If the 
document describes an Expert Review process has Shepherd 
conferred with the Responsible Area Director so that the IESG 
can appoint the needed Expert during the IESG Evaluation?

The document IANA section is complete and consistent with
RFC 3688.

(1.j) Has the Document Shepherd verified that sections of the 
document that are written in a formal language, such as XML 
code, BNF rules, MIB definitions, etc., validate correctly in 
an automated checker?

Yes.

(1.k) The IESG approval announcement includes a Document 
Announcement Write-Up. Please provide such a Document 
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval 
announcement contains the following sections:           

Technical Summary 

This document defines a NETCONF data model to be used to monitor
the NETCONF protocol.  The monitoring data model includes
information about NETCONF datastores, sessions, locks and statistics.  This data facilitates the management of a NETCONF server.  This document
also defines methods for NETCONF clients to discover data models
supported by a NETCONF server and defines a new NETCONF
operation to retrieve them.

Working Group Summary 

This document has been longly discussed in the Working Group,
including several WG Last Calls. The comments and reviews helped
to improve the document a lot and the current version reflects the
consensus of the Working Group.
After a long debate the WG decided to use the YANG modeling
language to model the NETCONF Monitoring Data Model. This makes
this document dependent on the YANG modeling language.

Document Quality

Are there existing implementations of the protocol? Have a
significant number of vendors indicated their plan to
implement the specification? Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a conclusion
that the document had no substantive issues? If there was a
MIB Doctor, Media Type or other expert review, what was its
course (briefly)? In the case of a Media Type review, on
what date was the request posted?

YANG experts from NETMOD WG reviewed the YANG data module
and validated with available YANG validation tools.