[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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:suresh.krishnan@ericsson.com]
> Verzonden: donderdag 7 februari 2008 23:33
> Aan: General Area Review Team; Sharon Chisholm; Hector Trevino;
> Romascanu, Dan (Dan); netconf-chairs@tools.ietf.org
> 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 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/>