Some Proposed Edits from discussions (Notifications)

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

hi

From reading through different comments, these are some proposed edits
that seem straight forward. There were others proposed and then
discussed a bit more which I have not yet included in this list:

1. Section 1: Needs more discussion on motivation, requirements and
architecture.

2. Replace term 'Application Protocol' with 'Transport Protocol'

3. Consistency check
	- consistency within document, for example:
  - sect 5.1 page 25
          <event-class><configuration/><audit/></event-classes>
    is it event-class or event-classes?
    or is it eventClass as per the following on page 27:
          <eventClass><configuration/><audit/></eventClass>
  - sect 3.4.1 seems to contradict the description under "Named Profile"
    in sections 2.1.1 and 2.3.1
  - I see
      <capability>
        urn:ietf:params:xml:ns:netconf:notification:1.0
      </capability>
    and
        xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0
    and
       <rpc message-id="101"
        xmlns="urn:ietf:params:xml:ns:netconf:event:1.0">
    So there seems to be inconsistency here?

4. Create a Iana Considerations section with the following content

In order for new event classes to be allocated, the following
requirements must be met:
 
  - WG consensus

  - detailed description of its purpose in the netconf protocol

  - detailed description of all manager and agent implementation
    requirements associated with the event class

  - It must be clear to developers how to determine that this
    is the appropriate event classification for a new notification type

5. Section 2.2.1)
Mention that there might be a big chunk of user defined data here.

6. Section 3.2)
- Change name from NetconfStateSchema to netconfNotificationSchema or
something 
  similar

7. Section 7)
Better explain the dormant-active state of the call home subscription.
What is the 
real difference between them ?

8. Section 7.1)
Add text to indicate that when an event occurs and if we run the
mixed-session mode the server should first check whether there is an
already open connection to the client.

9. Section 7.1.3.1.1)
Properly define element subscriber with Attributes like IpAddress,
PortNumber etc. 

10. page 4, change NETCONF[NETCONF] --> NETCONF [NETCONF-PROTO]

11. In section 2, Add examples for each RPC operation.
There should be examples here instead of spread out
in the end of the document.

12 On page 6, In <create-subscription>, change "This command ..." to
"This operation ..."


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