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

["Bert Wijnen" <bertietf@bwijnen.net>]

Suresh, is this answer acceptable?

Bert Wijnen 
document shepherd

> -----Oorspronkelijk bericht-----
> Van: owner-netconf@ops.ietf.org
> [mailto:owner-netconf@ops.ietf.org]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
> 
> 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
> > ===========
> > 
> > * 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?
> 
> This behaviour is out of scope of the document. The specification does
> not promote or preclude it. 
> 
> > 
> > * 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."
> 
> > 
> > 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.
> 
> > 
> > * 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.
> 
> > 
> > 
> > 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.
> 
> Sharon
> 
> --
> 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/>
> 

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