[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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/>