Subject: RE: Gen-ART review of draft-ietf-netconf-notification-11.txt

From: "Bert Wijnen" <[email-masked]>
Date: Fri, 8 Feb 2008 15:57:06 +0100

I have copied the WG mailing list, so they are aware of the comments.

Thanks for your review and comments Suresh.
I will study them, but I do expect that Sharon and/or Hector
come up first with answers to your questions.

Bert Wijnen 
document shepherd.

> -----Oorspronkelijk bericht-----
> Van: Suresh Krishnan [mailto:[email-masked]]
> Verzonden: donderdag 7 februari 2008 23:33
> Aan: General Area Review Team; Sharon Chisholm; Hector Trevino;
> Romascanu, Dan (Dan); [email-masked]
> Onderwerp: Gen-ART review of draft-ietf-netconf-notification-11.txt
> 
> 
> I am the assigned Gen-ART reviewer for 
> draft-ietf-netconf-notification-11.txt
> 
> 
> For background on Gen-ART, please see the FAQ at
> <http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.
> 
> Please resolve these comments along with any other Last Call comments
> you may receive.
> 
> Summary: This draft is well written and is almost ready for publication, 
> but I have a couple of issues.
> 
> 
> Meta issues
> ===========
> 
> * Aggregation: Is there a way by which the client can specify the 
> granularity with which it receives the notifications. i.e. Can the 
> client request merging of multiple internal events into a single 
> notification message? The following text in Section 3.2
> 
> "At some point after the NETCONF server receives the internal event
>   from a stream, it is converted to an appropriate XML encoding ..."
> 
> make me think that this should be possible. Is this in the scope of this 
> spec?
> 
> * Modification: How can a client modify a subscription? Section 6.5 
> talks about how it cannot be done, but there is no mention of whether 
> this is even possible to do. If not this must be clearly specified.
> 
> Minor
> =====
> 
> * Section 2.1.1
> 
> What happens if a stopTime is specified and a startTime is not? Does the 
> replay begin starting now or is the request rejected? This needs to be 
> clarified.
> 
> * Section 3.2.1
> 
> The term "Event Stream Definition" is used in Section 3.2 before it is 
> defined here. Is it possible to move this somewhere further up.
> 
> 
> Editorial
> =========
> 
> * Introduction
> 
> The text starting with "[NETCONF] can be conceptually..." and the 
> following diagram are copied verbatim from RFC4741, which is listed as a 
> normative reference. Is it necessary to keep it here?
> 
> 
> Cheers
> Suresh
> 
> 
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: "Sharon Chisholm" <[email-masked]>
Date: Sun, 10 Feb 2008 14:36:36 -0500

Hi

Yes, thanks Suresh for the review. Comments inline:

> 
> Summary: This draft is well written and is almost ready for 
> publication, but I have a couple of issues.
> 
> 
> Meta issues
> ===========
> 
> make me think that this should be possible. Is this in the scope of 
> this spec?

This behaviour is out of scope of the document. The specification does
not promote or preclude it. 

> this is even possible to do. If not this must be clearly specified.

Subscriptions cannot be modified. I propose adding a sentence to section
1.3 as follows:

  "Note that a subscription cannot be modified once created."

> 
> Minor
> =====
> 
> * Section 2.1.1
> 
> What happens if a stopTime is specified and a startTime is not? Does 
> the replay begin starting now or is the request rejected? This needs 
> to be clarified.

This results in an error. I think this is implicit with the current text
in section 2.1.1.

 "Must be used with and be later than <startTime>." 

I'm not sure further clarification is required.

> defined here. Is it possible to move this somewhere further up.

The term 'Stream' is defined in section 1.1 so I think we are OK.

> following diagram are copied verbatim from RFC4741, which is listed as

> a normative reference. Is it necessary to keep it here?

Actually, we have modified this picture to include Notifications,
including a bypass of the RPC layer. This is new content.

Sharon

---

From: "Bert Wijnen" <[email-masked]>
Date: Mon, 11 Feb 2008 11:36:46 +0100

Suresh, is this answer acceptable?

Bert Wijnen 
document shepherd

> Van: [email-masked]
> [mailto:[email-masked]]Namens Sharon Chisholm
> Verzonden: zondag 10 februari 2008 20:37
> Aan: Bert Wijnen; Suresh Krishnan; General Area Review Team; Hector
> Trevino; Romascanu, Dan (Dan)
> CC: Netconf
> Onderwerp: RE: Gen-ART review of draft-ietf-netconf-notification-11.txt
> 
> 
> Hi
>

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 11 Feb 2008 11:35:14 -0500

Hi Sharon,
   Thanks for the quick response. Please find comments inline.

Sharon Chisholm wrote:
>> ...

OK.

>   "Note that a subscription cannot be modified once created."

This text sounds fine.

> I'm not sure further clarification is required.

Then why do we have the following error case explicitly listed?

"     If a <stopTime> is requested which is earlier then the specified
       <startTime>, the following error is returned:

          Tag: bad-element

          Error-type: protocol

          Severity: error

          Error-info: <bad-element>: stopTime

          Description: An element value is not correct; e.g., wrong type,
          out of range, pattern mismatch."

> The term 'Stream' is defined in section 1.1 so I think we are OK.

The following text occurs in Section 3.2

"The central component inspects each event notification and matches
  the event notification against the set of stream definitions."

At this point I was not aware what a "stream definition" meant and 
how/where it was defined. Personally I would like to push the "Event 
Stream Definition" or a subset of it to Section 1.1 but I do not have a 
strong position on this.

> including a bypass of the RPC layer. This is new content.

OK. I missed that change.

Thanks
Suresh

---

From: "Sharon Chisholm" <[email-masked]>
Date: Sat, 16 Feb 2008 18:20:01 -0500

hi
 
<Suresh>
> This results in an error. I think this is implicit with the current 
> text in section 2.1.1.
> 

          Tag: bad-element

          Error-type: protocol

          Severity: error

          Description: An element value is not correct; e.g., wrong
type,
          out of range, pattern mismatch."

</Suresh>

The text in section 2.1.1 says that stopTime must be later then
startTime and there is an error message defined later when this isn't
the case. I'm not sure what the issue is. Can you clarify?

<Suresh>

</Suresh>

My personal view is that since it is defined in the definition section I
think we are ok.

Thanks,

Sharon

---

From: "Hector Trevino (htrevino)" <[email-masked]>
Date: Mon, 18 Feb 2008 08:59:15 -0800

Hi Suresh,

Your comment from below:

I enquired what would happen if stopTime would be specified without a
startTime. You mentioned it was implicit in this sentence ""Must be used
with and  be later than <startTime>.". My question is why the other half
of the sentence "later that <startTime>" explicitly handled as an error
case while the "must be used with" not explicitly handled.

Response:

The definitions in the document included below. Start time is a
mandatory parameter for replay. Stop time is an optional parameter for
replay. If Start Time is not present then Stop time should not be
present, if it is, then it is an error. Maybe the Start Time and Stop
Time descriptions do not explicitely state this but I think the Negative
response text does. Does this satisfy you comment?

The Negative Response says:

     If a <stopTime> is specified in a request without having specified
      a <startTime>, the following error is returned:

         Tag: missing-element

         Error-type: protocol

         Severity: error

         Error-info: <bad-element>: startTime

         Description: An expected element is missing.

      Start Time:

         A parameter, <startTime>, used to trigger the replay feature
         and indicate that the replay should start at the time
         specified.  If <startTime> is not present, this is not a replay
         subscription.  It is not valid to specify start times that are
         later than the current time.  If the <startTime> specified is
         earlier than the log can support, the replay will begin with
         the earliest available notification.  This parameter is of type
         dateTime.

      Stop Time:

         An optional parameter, <stopTime>, used with the optional
         replay feature to indicate the newest notifications of
         interest.  If stop time is not present, the notifications will
         continue until the subscription is terminated.  Must be used
         with and be later than <startTime>.  Values of <stopTime> in
         the future are valid.  This parameter is of type dateTime.

-----Original Message-----
From: Suresh Krishnan [mailto:[email-masked]] 
Sent: Sunday, February 17, 2008 9:57 PM
To: Sharon Chisholm
Cc: Bert Wijnen; General Area Review Team; Hector Trevino (htrevino);
Romascanu, Dan (Dan); Netconf
Subject: Re: Gen-ART review of draft-ietf-netconf-notification-11.txt

Hi Sharon,
   Please find comments inline.

> the case. I'm not sure what the issue is. Can you clarify?

I enquired what would happen if stopTime would be specified without a
startTime. You mentioned it was implicit in this sentence ""Must be used
with and be later than <startTime>.". My question is why the other half
of the sentence "later that <startTime>" explicitly handled as an error
case while the "must be used with" not explicitly handled.

> 
> <Suresh>
>>> * Section 3.2.1
>>>
>>> The term "Event Stream Definition" is used in Section 3.2 before it 
>>> is defined here. Is it possible to move this somewhere further up.
> Stream Definition" or a subset of it to Section 1.1 but I do not have 
> a strong position on this.
> </Suresh>
> 
> My personal view is that since it is defined in the definition section

> I think we are ok.

OK. I am fine with this.

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 18 Feb 2008 17:03:49 -0500

Hi Hector and Sharon,

> response text does. Does this satisfy you comment?

Yes, it does. I did not read this error message correctly the first time 
around. I expected the message to say something like this

Error-info: <bad-element>: stopTime
Description: An expected element <startTime> is missing.

instead of the current text. I am fine with leaving the text as is.

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Sun, 17 Feb 2008 23:56:46 -0500

Hi Sharon,

>>> is

OK. I am fine with this.

Thanks
Suresh

---

From: "Sharon Chisholm" <[email-masked]>
Date: Sun, 24 Feb 2008 17:22:58 -0500

Hi

Ah. That makes more sense. I think that same error can be used in both
cases and I will clarify the text of the message to indicate that it
gets sent in both cases.

Thanks,

Sharon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Suresh Krishnan
Sent: Sunday, February 17, 2008 11:57 PM
To: Chisholm, Sharon (CAR:ZZ00)
Cc: Bert Wijnen; General Area Review Team; Hector Trevino; Romascanu,
Dan (Dan); Netconf
Subject: Re: Gen-ART review of draft-ietf-netconf-notification-11.txt

Hi Sharon,

OK. I am fine with this.

Thanks
Suresh

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: "Sharon Chisholm" <[email-masked]>
Date: Sun, 24 Feb 2008 18:12:18 -0500

Hi

Actually, we already do have an error message for that:

         Tag: missing-element

         Error-type: protocol

         Severity: error

Sharon 

-----Original Message-----
From: Chisholm, Sharon (CAR:ZZ00) 
Sent: Sunday, February 24, 2008 5:23 PM
To: 'Suresh Krishnan'
Cc: Bert Wijnen; General Area Review Team; Hector Trevino; Romascanu,
Dan (Dan); Netconf
Subject: RE: Gen-ART review of draft-ietf-netconf-notification-11.txt

Hi

Thanks,

Sharon

-----Original Message-----

Hi Sharon,

OK. I am fine with this.

Thanks
Suresh