Subject: [Netconf] FW: DISCUSS and COMMENT: draft-ietf-netconf-monitoring

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 17 Jun 2010 10:50:49 +0200

I-D Editors,

Please address the issues raised by David Harrington. 

Thanks and Regards,

Dan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
David Harrington
Sent: Thursday, June 17, 2010 3:02 AM
To: [email-masked]
Cc: [email-masked];
[email-masked]
Subject: DISCUSS and COMMENT: draft-ietf-netconf-monitoring 

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.

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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 17 Jun 2010 13:53:21 +0200

A new DISCUSS - please address the issues raised by Adrian. 

Thanks and Regards,

Dan

-----Original Message-----
Adrian Farrel
Sent: Thursday, June 17, 2010 2:36 PM

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], ..." )

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.