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 _______________________________________________ Gen-art mailing list [email protected] http://www.ietf.org/mailman/listinfo/gen-art
