Subject: comments on notification-05

From: Martin Bjorklund <[email-masked]>
Date: Thu, 28 Dec 2006 09:46:37 +0100 (CET)

A couple of comments:

  o  3.2.5.1

    The second paragraph seems to be redundant (same info as in the
    first paragraph).

  o  3.4
   
    The text says:

       Note that when multiple filters are specified, they are
       applied collectively,

    I suspect this text is no longer correct, since named profiles and
    filters are mutually exclusive (for some reason).

  o  6.2

    It is not obvious if a start-time-too-early error will create the
    subscription or not.  If create-subscription fails with a
    start-time-too-early, it will be very difficult for a manager to
    get all logged notifications (and practically impossible to know
    when he got them all).

    If start-time-too-early does not fail the create-subscription
    request, how does start-stop-time-mismatch work?

    Also, is start-stop-time-mismatch really needed?  Can't we just
    re-use 'invalid-value' (or 'bad-element') from rfc4741?

  o  6.2

    The text says:

      Note that while a notification has three potential times
      associated it - the time it was generated, the time it was
      logged and the time it was sent out by the NETCONF server - the
      startTime and stopTime parameters are related to generation
      time.

    I still think it will be difficult for an implementation to
    conform to this -- it means that the logging subsystem must either
    be given the generation time along with the notification itself,
    or be able to extract the time from the notification content.
    This might not always be possible.

  o  6.3

    The text should probably state that the replayCompleteNotification
    is not affected by any filters on the subscription.

    Are eventClass, timeGenerated and numberEventsReplayed really
    needed?  Can't we just use:

    <notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
      <data>
        <replayCompleteNotification
           xmlns="urn:ietf:params:xml:ns:netconf:replayNotification:1.0"/>
      </data>
    </notification>

And a few XML errors:

  o  3.2.5.1 

    The namespace of eventStreams is wrong:

      <eventStreams xmlns="urn:ietf:params:xml:ns:netmod:base:1.0"/>
                                                  ^^^^^^^^^^^
    both in the request and the reply.

  o  3.2.5.2

    The schema should define a targetNamespace.

    The prefix 'nm' is not declared.  (But maybe the 'nm'-elements
    should be removed).
    
  o  5.1 & 5.2

    The prefix 'netconf' is undeclared in all examples.

        <netconf:filter type="subtree">
         ^^^^^^^

  o  5.2

    Here's 'neb' again, now transformed into an undeclared prefix!
    If "neb:" is removed from the xpath expressions, it will be ok.

/martin

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 28 Dec 2006 22:25:15 +0100 (CET)

I forgot one comment.

The schema for Named Profiles has been removed.  It seems a bit odd
that this mechanism is defined as configuration data, but no schema
(data model) exists for manipulating these Named Profiles.

/martin