Suresh, is this answer acceptable? Bert Wijnen document shepherd
> -----Oorspronkelijk bericht----- > Van: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] 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 [EMAIL PROTECTED] with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/netconf/> > _______________________________________________ Gen-art mailing list [email protected] http://www.ietf.org/mailman/listinfo/gen-art
