Subject: [Netconf] WG Last Call for draft-ietf-netconf-system-notifications-04.txt

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Wed, 13 Jul 2011 16:53:21 +0200

Dear WG participants,

This document was published mid-June, and we have not had much comments
sofar. So we conclude it must be ready for WG Last Call.

This is a formal WG Last call for draft-ietf-netconf-system-notifications-04.txt
Please review and send any comments BEFORE August 1.
Best would be if you can send it BEFORE July 24, so that we can discuss
any open issues during our Netconf session at IETF81 in Quebec.

Bert and Mehmet

---

From: Kent Watsen <[email-masked]>
Date: Wed, 13 Jul 2011 15:32:18 -0700

Comments:

Now that we've renamed it to "NetConf Base Notifications", should we s/draft-ietf-netconf-system-notifications-04.txt/draft-ietf-netconf-base-notifications-04.txt/?  - does it matter once it becomes an RFC?

Now that 4741bis is out, we should replace references to it with "RFC 6241"

Why does the " changed-by "container have "case by-user" when it's already in a "choice" statement.  Alternatively, do we need to add a "case by-server" statement?

Why set the numerical value for the "termination-reason" and "confirm-event" enumerations?  - since the values provided are exactly the default values...

Thanks,
Kent

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bert (IETF) Wijnen
Sent: Wednesday, July 13, 2011 10:53 AM
To: netconf
Subject: [Netconf] WG Last Call for draft-ietf-netconf-system-notifications-04.txt

Dear WG participants,

Bert and Mehmet
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Andy Bierman <[email-masked]>
Date: Wed, 13 Jul 2011 15:47:25 -0700

see inline

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kent Watsen
Sent: Wednesday, July 13, 2011 3:32 PM
To: Bert (IETF) Wijnen; netconf
Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-system-notifications-04.txt

Comments:

[ab: no -- the draft stays the same until published as RFC.
The draft name is not important.]

[ab: sure]

Why does the " changed-by "container have "case by-user" when it's already in a "choice" statement.  Alternatively, do we need to add a "case by-server" statement?  The uses-stmt is not

[ab: leaf server is the by-server case.  I suppose 'uses common-session-parms' can be
the case-stmt and case by-user is redundant.  It doesn't hurt anything to have the case label.]

[ab: the enum values can be removed.]

Thanks,
Kent

Andy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bert (IETF) Wijnen
Sent: Wednesday, July 13, 2011 10:53 AM
To: netconf
Subject: [Netconf] WG Last Call for draft-ietf-netconf-system-notifications-04.txt

Dear WG participants,

Bert and Mehmet

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 14 Jul 2011 07:00:50 +0200

> Sent: Thursday, July 14, 2011 1:32 AM
> Now that we've renamed it to "NetConf Base Notifications", should we
> s/draft-ietf-netconf-system-notifications-04.txt/draft-ietf-netconf-
> base-notifications-04.txt/?  - does it matter once it becomes an RFC?
> 

[[DR]] No, it does not matter, and please do not do it as a change of
name of the document implies resetting the numbering also to 00, and
makes tracking the history more difficult. 

Regards,

Dan

---

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Fri, 15 Jul 2011 11:31:17 +0200

I did review this document. Looks pretty good to me.
I'd like to have some answers/explanations to y comments and
I think we can improve consistency a tid-bit.

Here are my comments/questions:

- replace references to 4741is with ref to rfc6241
- replace references to RFC4741 and RFC4742 with references to RFC6241 and RFC6242
    This is in the "security Considerations" section. Sounds like I need to update the template
    as well.
- RFC6242 then needs to be added to )I think normative) references list

- I see in sect 2.1:
                                                A server
    MAY report events for non-NETCONF management sessions, using the
    'session-id' value of zero.

   I tried to find how/where it "session-id" and possible contents in a notification
   are defined/specified. It seems the only place is in the YANG module, right?
   Anyways, It seems from sect 2.1 (and the YANG module) that
   for NETCONF management sessions a session-id MUST(?) be reported in the
   notification.
   So I then wonder when reading section 2.1.1:
       netconf-capability-change:
       Generated when the NETCONF server detects that the server
       capabilities have changed.  Indicates which capabilities have been
       added, deleted, and/or modified.
   How does a capability change occur? Is that though some protocol operation
   over some session (so we have a session-id), or does that happen in a different
   way, so that the session-id=0 ?? Or is there nos session-id in that case (but
   session-id has "mandarory true") ??

   MMmm maybe the text in sect 2.1 and 2.1.1 confuses me. Because when I read the
   YANG module, then I think I see that if it is a server internal event, that we do
   have the leaf "server" present and if changed by a user/session, then we
   have the common-session-parms present.
   Did I get that right?
   Were other people similarly confused?
   Is this all clear to the novice reader (we need to focus on YANG module readers, right?)

- I am somehwat surprised by:
     notification netconf-session-end {
       description
        "Generated when a NETCONF server detects that a
         NETCONF session has terminated.
         A server MAY optionally generate this event for
         non-NETCONF management sessions. Indicates the
         identity of the user that owned the session,
         and why the session was terminated.";

   Same for netconf-session-start
   How should I interpret "netconf-session-end" for a non-NETCONF session?

Consistency related notes/remarks:
- I see:
    The following terms are defined in [I-D.ietf-netconf-4741bis]:
    o  client
    o  datastore
    o  operation
    o  server
    Actually, RFC6241 defines "protocol operation" and not "operation".
    Maybe it is better to be consistent.

- I see:
   2.1.  Overview

    The YANG module defined within this document specifies a small number
    of notification event messages for use within the 'NETCONF' stream,

    in rfc5277 I see the phrases "event notification match" and "Sending Event Notifications"...
    It seems that maybe we better speak of "event notification messages"? But maybe that is just me?

Bert (speaking as technical contributor)

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 25 Jul 2011 17:13:41 -0400 (EDT)

Hi,

I have reviewed this document, and I think it is ready for
publication, with some minor edits:

As I said in the meeting, the text needs to be clearer about how
session id '0' is used.

----------

OLD:
         enum "killed" {
           value 1;
           description
             "The session was terminated by the client in abnormal
              fashion, e.g., by the NETCONF <kill-session>
              operation.";
         }

NEW:
         enum "killed" {
           value 1;
           description
             "The session was terminated in an abnormal
              fashion, e.g., by the NETCONF <kill-session>
              operation.";
         }

----------

OLD:
     leaf killed-by {
       when "../termination-reason = 'killed'";
       type nc:session-id-type;
       description
         "The session ID that issued the <kill-session>,
         if the session was terminated by this operation.
         If the session was abnormally terminated by a
         non-NETCONF client operation, the value '0' will be
         used instead.";
     }

NEW:
     leaf killed-by {
       when "../termination-reason = 'killed'";
       type nc:session-id-type-or-zero;
       description
         "The ID of the session that terminated this session, or the
          value '0' if it was terminated in some other way.";

/martin

---

From: Phil Shafer <[email-masked]>
Date: Fri, 29 Jul 2011 09:36:47 -0400

>          value '0' if it was terminated in some other way.";

Why emit the leaf at all if it doesn't have a valuable value?

Thanks,
 Phil

---

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Fri, 29 Jul 2011 12:30:30 -0400

WG participants,

Pls review BEFORE or BY August 1 if you have not already done so.
A "I read it and see no issues or have no concerns" is also very welcome!

I case you need a couple of days extra time (and commit a date for
your review), we're willing to consider a short extension.

Bert and Mehmet
-------- Original Message --------
Subject: 	[Netconf] WG Last Call for draft-ietf-netconf-system-notifications-04.txt
Date: 	Wed, 13 Jul 2011 16:53:21 +0200
From: 	Bert (IETF) Wijnen <[email-masked]>
To: 	netconf <[email-masked]>

Dear WG participants,

Bert and Mehmet