more comments on notifications-03

[Martin Bjorklund <mbj@tail-f.com>]

Hi,

Here are a couple of comments on the latest notifications draft.

  o  3.2.5

    Says that <get-config> or <get> can be used to retreive the list
    of supported event streams.  But using <get-config> implies that
    this list is config data (which e.g. can be written).  The
    <get-config>s should be removed.

  o  3.2.6.2

        A NETCONF client subscribing to multiple event streams must do so by
        either establishing a new NETCONF session or opening a new channel on
        an existing NETCONF session.

    From your reply to Balazs it seems that this sentence will be
    removed.  If not, it should just say

        A NETCONF client subscribing to multiple event streams must do so by
        establishing a new NETCONF session.

    For SSH, this can be done by either opening a new SSH connection,
    or opening a new SSH channel on the existsing connection.

  o  3.4

    The schema in this section defines a "lastModified" element.
    Maybe this should be renamed to "creationTime", since
    modifications is not supported.

  o  3.4

    The element "messagesSent" should probably be of type
    xs:unsingedInt, which is 32 bits.  xs:integer is a bignum.

  o  3.6

    This text should describe that the filter is applied to the XML in
    the <data> element (which the examples seems to indicate is the
    case).

  o  4.

    The description for element "SequenceNumber" says:

        A monotonically  increasing integer. Starts at 0.
        Always increases by just one. Roll back to 0 after maximum
        value is reached.
    
    But the type is xs:integer, which doesn't have a maximum value.
    The type should probably be xs:unsingedInt.  (or even better
    smiv2:Counter32 ...).

  o  4.

    The complextType "NotificationType" is missing the "data" element.

  o 5.1

    The example in this section has some namespace errors.  It should
    probably look like this (slightly modified to be consistent with
    other examples).

        <?xml version="1.0" encoding="UTF-8"?>
        <notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
          <subscription-id>123456</subscription-id>
          <data>
            <event xmlns="http://example.com/event/1.0";>
              <severity>notice</severity>
              <eventClasses><configuration/><audit/></eventClasses>
              <sequenceNumber>2</sequenceNumber>
              <dateAndTime>2000-01-12T12:13:14Z</dateAndTime>
              <user>Fred Flinstone</user>
              <operation>
                <edit-config>
                  <target>
                    <running/>
                  </target>
                  <config>
                    <top xmlns="http://example.com/schema/1.2/config";>
                      <interface>
                        <name>Ethernet0/0</name>
                        <mtu>1500</mtu>
                      </interface>
                    </top>
                  </config>
                </edit-config>
              </operation>
            </event>
          </data>
        </notification>
        ]]>]]>

    Note that the separator was split into two lines in the document.
    
  o  6.1

    This example also has some namespace errors.  The infamous 'neb'
    element is still there also...

    I suggest something like this:

      <rpc message-id="101"
           xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
        <create-subscription 
             xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
          <filter type="subtree">
            <event xmlns="http://example.com/event/1.0";>
              <severity>critical</severity>
            </event>
            <event xmlns="http://example.com/event/1.0";>
              <severity>major</severity>
            </event>
            <event xmlns="http://example.com/event/1.0";>
              <severity>minor</severity>
            </event>
          </filter>
        </create-subscription>
      </rpc>

   NOTE: there are a few other examples throughout the document which
   have the same namespace errors on the 'rpc' and
   'create-subscription' elements.

  o  7.

    The replay capability adds a startTime parameter.  We had some
    discussion about this time in Montreal.  So - what time does this
    parameter refer to?  The time the event was generated?  The time
    it was logged by the agent?  If it is the former, this seems to
    imply that the replay mechanism can only be used when there is a
    timestamp in the event itself.  If it is the latter, this time
    should be included in each event - if not, how would a manager
    know which time to use?  I would prefer the latter.

  o  7.

    Why isn't there a symmetrical stopTime parameter?

  o  7.1

    The text says:

      If a client requests a replay of notifications that predate the
      oldest notification available, then the NETCONF server must
      return an warning message in the RPC reply and start replaying
      the notifications it does have available,
   
    Why is this warning message necessary?

    (I suspect the answer might be that if no timestamp is included in
    the event, then the client won't know...)


  o  7.1

    The text says:

      A replay subscription terminates once the it has completed replaying
      past events.

    How will a client know that the last event has been sent?

    Is the session open for new rpcs once the last event has been
    sent?


/martin

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