Subject: [Netconf] AD review of draft-ietf-netconf-system-notifications-06

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 7 Nov 2011 16:30:31 +0100

I have performed the AD review of
draft-ietf-netconf-system-notifications-06.

There are no show-stoppers in this document, so I am sending it to IETF
Last Call. However, because of the timing conflict with the IETF meeting
which will keep busy many IETF contributors I will ask for the Last Call
period to be one week longer than usual (three weeks instead of the
usual two weeks). 

Please consider the questions and comments below together with the other
Last Call comments. The Technical comments are marked T and the
Editorial comments are marked E.

T1. In section 2.1: 

   netconf-session-start:
      Generated when a NETCONF server detects that a NETCONF session has
      started.  A server MAY generate this event for non-NETCONF
      management sessions.  Indicates the identity of the user that
      started the session.

I am not sure that I understand why a server needs to generate a
netconf-session-start notification for a non-NETCONF management session.
Maybe an example / use case could help. 

Same question for netconf-session-end:

T2. This may be more like a YANG question, but as I encountered it here
I will ask it now. In the MIB world we do not encourage the inclusion of
capitalized keywords in DESCRIPTION clauses of the MIB objects. Here I
see them used frequently. Did the NETCONF / NETMOD community discuss
this practice? 

E1. Page 7: 

        Generated when the NETCONF server detects that the
        <running> or <startup> configuration datastore
        has changed by a management session.

s/has changed/has been changed/

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 7 Nov 2011 16:56:51 +0100

> see them used frequently. Did the NETCONF / NETMOD community discuss

Interesting, I did not know this. Is this covered anywhere in RFC
4181? I guess the only reason for this is to please broken MIB
parsers. I hope YANG does not need such rules since we do not have to
cater for broken YANG parsers...

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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 7 Nov 2011 17:09:48 +0100

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
> university.de]
> Sent: Monday, November 07, 2011 5:57 PM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]
> Subject: Re: [Netconf] AD review of draft-ietf-netconf-system-
> notifications-06
> 
> > I will ask it now. In the MIB world we do not encourage the
inclusion
> of

[[DR]] Am I mistaken? The reason was not related to broken MIB parsers
(sure, YANG tools never broke :-)) but more to avoid including normative
text in a clause that is targeting documentation, or so I thought. 

Dan

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 07 Nov 2011 20:44:22 +0100 (CET)

> text in a clause that is targeting documentation, or so I thought. 

Isn't the description text allowed to define the normative behavior of
the objects?  I hope it is ok, because otherwise we would have to
write all normative text in the RFC outside of the YANG module (or MIB
module), and that means that the standalone module is less useful, and
readers must also check the RFC to find the normative text.

It seems e.g. MUST is used in some MIBs as well,
e.g. INET-ADDRESS-MIB.

In libsmi/mibs/ietf:
$ grep MUST * | wc -l
1039

/martin

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 7 Nov 2011 12:07:02 -0800

Hi -

> From: "Martin Bjorklund" <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>
> Sent: Monday, November 07, 2011 11:44 AM
> Subject: Re: [Netconf] AD review of draft-ietf-netconf-system-notifications-06
...
> readers must also check the RFC to find the normative text.

Agreed.  To me the MIB module DESCRIPTION clauses seem like
the logical place to put normative text describing the behaviour of
those management interfaces.

> It seems e.g. MUST is used in some MIBs as well,

I do not find this surprising.  :-)

Randy

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Mon, 07 Nov 2011 21:12:22 +0100

inline

> cater for broken YANG parsers...

I am also not aware of this.
What I do know is that we do not want thing in DESCRIPTION clauses that
can easily be expressed in MODULE-COMPLIANCE.
As far as I know, several MIB modules do use RFC2119 language in
DESCRIPTION clauses. I need to dig in my archives if I have to
provide examples.

Bert

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 7 Nov 2011 21:45:29 +0100

> text in a clause that is targeting documentation, or so I thought. 

Sorry, I did not equate "capitalized keywords" with RFC 2119 key words
(I was thinking about keywords of the language a module is written in,
hence my comment on broken MIB parsers). But even with the confusion
resolved, I must say that I strongly prefer to find the normative text
describing managed objects where the objects are defined. (Of course,
the normative text should be restricted to the managed object
definition itself and not express normative behaviour of the protocol
mechanism being instrumented.)

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 8 Nov 2011 11:08:17 +0100

Fine with me - you can ignore this comment. 

Dan

> From: Bert Wijnen (IETF) [mailto:[email-masked]]
> Sent: Monday, November 07, 2011 10:12 PM
> To: Romascanu, Dan (Dan); [email-masked]
> inclusion of
> >> capitalized keywords in DESCRIPTION clauses of the MIB objects.
Here
> I