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

[Suresh Krishnan <suresh.krishnan@ericsson.com>]

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

Sharon Chisholm wrote:
> > Meta issues
> > ===========
> >
> > * Aggregation: Is there a way by which the client can specify the 
> > ...
> This behaviour is out of scope of the document. The specification does
> not promote or preclude it. 

OK.

> > * 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.
>
> Subscriptions cannot be modified. I propose adding a sentence to section
> 1.3 as follows:
>
>   "Note that a subscription cannot be modified once created."

This text sounds fine.

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

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."

> > * 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.
>
> 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.


> > 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?
>
> Actually, we have modified this picture to include Notifications,
> including a bypass of the RPC layer. This is new content.

OK. I missed that change.

Thanks
Suresh


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