Notifications: Proposed edits not included and why

["Sharon Chisholm" <schishol@nortel.com>]

Hi

The following are suggested edits that I did not execute and my
reasoning.

1. Misc. changes that got overwritten by subsequent changes or wg
agreement.

2. Chapter 4) Why do we need a streamNameType? It is just a string.

A-> People wanted everything to be a type in order to enable
extensibility.

3. In section 3.2.2 it says:

    The contents of all event streams made available to a NETCONF client
    (i.e., the notification sent by the NETCONF server) must be encoded
    in XML.

"This is a round-about way to state the obvious -- the contents of the
<notification> element must be encoded in XML."

A-> I think the current text is fine.

4. Didn't s/Schema/schema/ since it seems appropriate to capitalize.

5. There was a suggestion that since filtering was explained in the base
protocol specification, we don't need to explain it again in the
notification context. I don't agree. I think saying it is the same and
then confirming what that means in this context will ensure better
interoperability.

6. Didn't move section 5 to an appendix. This has been discussed before,
and I believe there is agreement to keep it where it is.

7. In section 6., para 2 it says:

    The access control framework and the choice of transport will have a
    major impact on the security of the solution.

"What impact would that be exactly?"

A-> I think the current text, while vague is fine for the security
considerations section. Can we access the impact without making
assumptions about the access control framework?

8. @@ -410,12 +410,12 @@
    Negative Response:
 
       An <rpc-error> element is included within the <rpc-reply> if the
-      request cannot be completed for any reason.  Subscription
requests
+      request cannot be completed for some reason.  Subscription
requests
       will fail if a filter with invalid syntax is provided or if the
       name of a non-existent profile or stream is provided.

A-> I believe the original text is better.

9. @@ -473,12 +473,12 @@
 
    Description:
 
-      An event notification is sent to the client who initiated a
-      <create-subscription> command asynchronously when an event of
-      interest (i.e., meeting the specified filtering criteria) to them
-      has occurred.  An event notification is a complete and
well-formed
+      When an event of interest occurs (i.e., matches the specified
+      filtering criteria), an event notification is sent asynchronously

+      to client(s) that initiated a <create-subscription> command
+      for the event.  An event notification is a complete and
well-formed
       XML document.  Note that <notification> is not an RPC method but

A->I believe the original text is better.

10. @@ -490,7 +490,7 @@
 
    Response:
 
-      No response.  Not applicable.
+      This is not applicable as there is no response.

A-> I believe the original text is better. Note that this text is not in
a paragraph.

11. -   XPATH support for the Notification capability is advertised as
part
+   XPATH support for the notification capability is advertised as part

A-> Again, I believe capitalization is appropriate.

12.     A replayComplete notification is sent to indicate that all of
the
    replay notifications have been sent.  If this subscription has a
stop
-   time, then this session becomes a normal NETCONF session again.  In
-   the case of a subscription without a stop time, after the
-   replayComplete notification has been sent, it can be expected that
-   any notifications generated since the start of the subscription
-   creation will be sent followed by notifications as they arise
-   naturally within the system.
+   time, then this session becomes a normal NETCONF session again.  If
+   the subscription has no stop time, it can be expected that any
+   notifications generated since the start of the subscription creation
+   will be sent after the replayComplete notification has been sent,
+   followed by notifications as they arise naturally within the system.

A-> I added the comma, but I believe the original text was better
otherwise.

13. @@ -1012,7 +1011,7 @@
 
    While it may be possible to retrieve information about subscriptions
    via a get operation, subscriptions are not stored configuration.
-   They are non-persistent state information and their lifetime is
+   They are non-persistent state information, and their lifetime is
    defined by their session.

A-> I don't actually think there is suppose to be a comma there, or at
least one is not required.

Sharon Chisholm
Nortel 
Ottawa, Ontario
Canada

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