Subject: notification-08 comments

From: Andy Bierman <[email-masked]>
Date: Fri, 13 Jul 2007 02:04:33 -0700

Hi,

I am leaving out bugs already identified in other comments...

[I am getting as picky as I know the IESG will be when they review it.]

-----------------------------------------------

1.1 Terms:

    Operation:  This term is used to refer to NETCONF protocol operations
       [NETCONF].  Specifically within this document, operation refers to
       NETCONF protocol operations defined in support of NETCONF
       notifications.

5.1, para 1:

    XML subtree filtering is not well suited for creating elaborate
    filter definitions given that it only supports equality comparisons
    and logical OR operations (e.g., in an event subtree give me all
                   ^^^^^^^^^^

6, para 4:

    It is recommended that care be taken to ensure the secure operation
    of the following commands:                                ^^^^^^^^^

The second sentence in the operation is not true, since it is
used differently in sec. 5.1 and 6.

-------------------------------------------------

1.3, para 2:

  A NETCONF server is will not read
                   ^^

extra word

-------------------------------------------------

1.4, bullet 1:

  o  Initial release should ensure it supports notification in support
       of configuration operations

Reword to something less mangled, but I'm not even sure what
this means. perhaps remove, since the contents of a stream
are internal to the agent implementation.

---------------------------------------------------

1.4, bullet 2:

   o  Data content must not preclude the use of the same data model as
       used in configuration

I have no idea what this means, please elaborate.

--------------------------------------------------

1.4, bullet 3:

    o  Solution should support a reasonable message size limit (ie, not
       too short)

NETCONF has no message size limits (except the message-id attribute),
so I'm not sure why this needs to be here.  There are no size limits
in this document either.

s/ie,/i.e.,/ (BTW)

----------------------------------------------------

1.4, all bullets:

Add period and make all bullets complete sentences.

---------------------------------------------------

2.1:

This section should clearly state that a subscription is bound
to a single stream for the lifetime of the subscription.

----------------------------------------------------

2.1.1, Negative Response:

     If a stopTime is specified in a request without having specified a
     startTime the following error is returned:

Previously, 'startTime' and 'stopTime' were single-quoted.
Be consistent throughout the draft one way or the other.

----------------------------------------------------

2.1.1, Negative Response:

       In each sub-section, clearly state which child element in the
       <create-subscription> element is associated with the parameter.

----------------------------------------------------

2.1.1, Negative Response:

        Error-info: <badElement>: startTime
                    ^^^^^^^^^^^^

Change to <bad-element>

-----------------------------------------------------

2.1.1.1:

    <netconf:rpc message-id="101"
          xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0">
        <create-subscription
            xmlns="urn:ietf:params:netconf:capability:notification:1.0">
        </create-subscription>
    </netconf:rpc>

This section needs some explanatory text, and filled in with
most or all of the parameters.

Also the 2nd namespace URI is wrong (already mentioned in a previous email).

-----------------------------------------------------

2.2.1, para 1:

    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.

Remove extra text.

------------------------------------------------------

2.2.1, para 2:

          Contains notification-specific tagged content.  The content of
          the data tag is beyond the scope of this document.

This section (on parameters) is insufficient.
This document needs to clearly explain how the child node
of the <notification> node is defined, similar to RFC 4741, sec 4.1.

-------------------------------------------------------

3.2:

Much improved text and diagram, but needs a little more text.
It should be clear that the 'central event processor' generates
events and transfers them to the correct stream(s) in an
inaccessible, internal format.

Suggest:

At some point after the 'netconf server'
receives the internal event from a stream, it is converted to XML
encoding by the agent, and a <notification> element is
ready to send to all NETCONF sessions subscribed to that stream.

After generation of the <notification> element, access control
is applied by the agent.  If a session does not have permission to
receive the <notification>, then it is discarded for that session,
and processing of the internal event is completed for that session.

If the session has permission to receive the <notification> element,
then the filter associated with its subscription is applied (if any),
except if this is a <replayComplete> notification.

-------------------------------------------------------

3.2, para 3:

    When a NETCONF client subscribes to a given event stream, user-
    defined filters, if applicable, are applied to the event stream and
    matching event notifications are forwarded to the NETCONF server for
    distribution to subscribed NETCONF clients.  For more information on
    filters, see section 3.6.

The end of the first sentence, especially 'forwarded to the NETCONF server',
is confusing.  It sounds like the 'forwarder' is the client, not
the central event processor.

This para should state somehow:

Filters are transferred from the client to the agent during
the <create-subscription> operation and applied against each <notification>
element generated by the stream.

----------------------------------------------------------

3.2.1, para 1:

   may allow event stream configuration via NETCONF protocol (i.e.,

s/via NETCONF/via the NETCONF/

-----------------------------------------------------------

3.2.1, para 1:

    established by the vendor (pre-configured) or user configurable
                                              ^ missing comma
    (e.g., part of the device's configuration) or both.
                                              ^ missing comma

Add missing commas.

-------------------------------------------------------------

3.2.2:

    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.

--------------------------------------------------------------

3.2.3:

    A NETCONF server implementation supporting the notification
    capability must support the "NETCONF" notification event stream.

Clearly state that the exact string "NETCONF" must match the
contents of the <stream> element in the <create-subscription> RPC.
Also, an <eventStream> element will be present in the agent, with
a <name> value that matches this string.

---------------------------------------------------------------

3.2.4:

    (e.g., SNMP, syslog, etc.) is outside the scope of this document.
                       ^^^^^^

Remove redundant text (use e.g., or etc, but never both).

---------------------------------------------------------------

3.2.5:

   NETCONF server using the <get> RPC request.
                                  ^^^^^^^^^^^

Use 'operation' instead to be consistent.

----------------------------------------------------------------

3.2.5.1:

This section should list each child element of the <stream> element
and explain its purpose and implementation requirements, instead
of burying these important details in the XSD.

------------------------------------------------------------------

3.2.5.1:

Element naming is inconsistent.  Plural form is <eventStreams>
and single form is <stream>.  Suggest changing <stream> to <eventStream>.

------------------------------------------------------------------

3.2.5.1, para 1:

    The returned list must only include the names of
    those event streams for which the NETCONF session has sufficient
    privileges.  The NETCONF session privileges are determined via access
    control mechanisms which are beyond the scope of this document.  An
    empty reply is returned if there are no available event streams.

This portion of the paragraph should be removed.
Access control should only be conceptually inserted after
<notification> generation by the 'netconf server',
and before any filters are applied.

------------------------------------------------------------------

Figure 5:

  <rpc message-id="101"
     xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

    <get>
     <filter type="subtree">
       <eventStreams xmlns="urn:ietf:params:xml:ns:netmod:notification"/>
     </filter>
    </get>
  </rpc>

Remove extra line before <get>

The <netconf> element is missing.
The 'xmlns' should be in that element instead.

----------------------------------------------------------------------

Figure 6:

   <rpc-reply message-id="101"
                  xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
   <data>
    <eventStreams xmlns="urn:ietf:params:xml:ns:netmod:notification">

The <netconf> element is also missing from the <rpc-reply>.

-----------------------------------------------------------------

3.2.5.2.1, para 1:

    The set of event notifications delivered in an event stream may be
    further refined by applying a user-specified filter at subscription
    creation time

s/filter at/filter supplied at/

------------------------------------------------------------------

3.3.1, para 2:

    A replay of notifications is specified by including an optional
    parameter to the subscription command that indicates the start time
    of the replay.  The end time is specified using the optional stopTime
    parameter.  If not present, notifications will continue to be sent
    until the subscription is terminated.

Use single quotes for 'startTime' and 'stopTime'.

-------------------------------------------------------------------

3.3.1, para 4:

    Control parameters for this aspect of the feature are outside the
    scope of the current document.
                 ^^^^^^^

s/current/this/

--------------------------------------------------------------------

3.3.1, para 5:

  This schema also provides the replayLogStartTime element to
  indicate the earliest available logged notification.

Add < > to replayLogStartTime.

This sentence shows why the parameter needs to be clearly defined
in sec 3.2.5.1.

Is this parameter the time the agent started collecting or
the time the first notification was added, sometime after
the agent started collecting?  The spec must be clear on which one.
(IMO, the former is the intuitive choice.)

--------------------------------------------------------------------

3.3.2, para 2:

    Note that startTime and stopTime are associated with the time an
    event was generated by the system.

Add single quotes to 'startTime' and 'stopTime'.
The phrase 'by the system' is vague.  Which component in fig. 4
is the system?

----------------------------------------------------------------------

3.3.2, para 3:

    A replayComplete notification is sent to indicate that all of the
    replay notifications have been sent.

Use 'replayComplete' or <replayComplete>.

    becomes a normal NETCONF session again.

Indicate that the agent will now accept <rpc> operations.
Any requests which have been received but not processed by
the agent will now be processed in the order they were received.

   creation will be sent followed by notifications as they arise
                        ^ missing comma

-----------------------------------------------------------------------

3.3.3, para 1:

   The replayComplete notification is the last notification sent over a
   replay subscription.

Single quote or element form of replayComplete

Sentence is confusing, since more notifications can be sent after <replayComplete>.
You mean this special notification is sent after all replayed notifications
have been sent.

------------------------------------------------------------------------

3.3.3, para 2:

    The replayComplete can not be filtered out.  It will always be sent
    on a relay subscription that specified a stop time.

s/can not/cannot/

s/relay/replay/

-------------------------------------------------------------------------

3.4, para 1:

   This Schema is used to learn about the event streams supported on the

s/Schema/schema/

   It also contains the definition of the replayComplete

s/replayComplete/<replayComplete> element/

    which
    is sent to indicate that an event replay has sent all applicable
    notifications."

Suggest removing or make the terminology consistent.

------------------------------------------------------------------------

3.4: XSD:

much improved.
Need to update some namespace URIs (use xml:ns form, not netconf:capability form).

Should also add comment above the 2nd <import> that the
"http://www.iana.org/assignments/xml-registry/schema/notification.xsd"
value is a placeholder and the actual value will be assigned by IANA.

-------------------------------------------------------------------------

3.5:

    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
    defined by their session.

This whole section is confusing, since there is no schema in the
document related to this section.  This document should only focus
on the standard, and the standard has no mechanism to retrieve
this information.

Suggest removing this section.

-----------------------------------------------------------------

3.6, para 1:

    When multiple filter elements are specified, they are applied
    collectively, so event notifications need to pass all specified
    filters in order to be sent to the subscriber.

Need to remove this sentence. There is at most one conceptual <filter>
element associated with a subscription.

    If a filter element
    is specified to look for data of a particular value, and the data
    item is not present within a particular event notification for its
    value to be checked against, the notification will be filtered out.

This is not precise enough.
For starters, subtree and Xpath filters return a subset of
conceptual 'input node set', not a boolean expression.
The output node set is returned in the <get> or <get-config> response.

What does it mean to convert this mechanism to a boolean filter?

Does it mean that any output at all from the filter means
it 'passes', and an empty output node set means the filter 'failed'?

----------------------------------------------------------------

3.6, para 2:

    The order that filter elements are applied does not matter since the
    resulting set of notifications is the intersection of the set of
    notifications that pass each filtering criteria.

This sentence is confusing and should be removed.
This document has no business discussing how filters defined in RFC 4741
are implemented within an agent.  Also, there is only one conceptual
filter per subscription.

------------------------------------------------------------------

3.6.1:

    Filters only exist as parameters to the subscription.

Remove or change to indicate there is only one filter element.

------------------------------------------------------------------

figure 8:

This figure (or another one) should support the replay mode,
and show the replayComplete notification, followed by another
<rpc>/<rpc-reply> sequence.

This section should show the conceptual 'normal mode' and 'notification mode'
transitions as well.

-------------------------------------------------------------------

3.7, para 1:

   stopTime in a replay subscription

s/stopTime/'stopTime'/

---------------------------------------------------------------

4.:

targetNamespace URI form should be 'ns' not 'capability'.

---------------------------------------------------------------

4.<filter>:

                                  <xs:documentation>
                                     An optional parameter that indicates
                                     which subset of all possible events
                                     are of interest. The format of this
                                     parameter is the same as that of the
                                     filter parameter in the NETCONF
                                     protocol operations. If not present,
                                     all events not precluded by other
                                     parameters will be sent.
                                 </xs:documentation>

See comment above on 3.6, para 1.
The precise nature of notification filtering must not
contradict, and should not duplicate, sec. 3.6.

This definition of a filter output is not at all how filtering
works for the <get> and <get-config> operations.
The WG agreed at the start we are not creating a new type
of filtering, just reusing the existing filtering.

----------------------------------------------------------------

4. (and 3.4).<schema>:

This XSD assigns the default namespace to the target namespace:

     xmlns="urn:ietf:params:netconf:capability:notification:1.0"

However, the XSD in 3.4 does not use a default namespace at all:

    xmlns:manageEvent="urn:ietf:params:xml:ns:netmod:notification"

It uses the prefix 'manageEvent' instead.

IMO, the XSD in sec. 3.4 should be changed to match sec 4.
XSD is hard enough to read as it is without electing to make
it even more verbose.  It is also customary to use short
prefixes (like 2 or 3 chars max).

------------------------------------------------------------------

4. (and 3.4).<schema>:

There are two missing attributes in this element in both schemas:

      xml:lang="en"

      version="1.0"

------------------------------------------------------------------

4.<stream>:

Only the 'replayLogStartTime' element has a <documentation> node.
All the elements in this sequence should have them.

-------------------------------------------------------------------

5.

IMO, this section needs to be moved to Appendix A, and
not be included in the normative part of the document.

Also, the description of the assumed data model needs to be
moved from 5.1 to this section, since it is used in 5.2 as well.
This data model should probably have an XSD as well.

---------------------------------------------------------------------

5.1: para 2:

  (e.g., fault,
    state, config, etc.)

s/config, etc.)/config)

  elements <eventEntry> consisting of the event class (e.g., fault,

s/<eventEntry>/<event>/

--------------------------------------------------------------------

5.2, para 1:

Should mention that the same notification data model as 5.1 is assumed.

----------------------------------------------------------------------

6., para 2:

    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?

------------------------------------------------------------------------

6., para 4:

   It is recommended that care be taken to ensure the secure operation
    of the following commands:

    o  <create-subscription> invocation

    o  read-only data models

    o  read-write data models

    o  notification content

Bullets 2 - 4 are not commands.
NETCONF has operations, not commands, BTW.

------------------------------------------------------------------------

6., para 5:

    One issue related to the notifications draft is the transport of data
    from non-netconf streams,

s/One issue related to the notifications draft is/One issue is/

s/non-netconf/non-NETCONF/

    over netconf than when being transported using the protocol normally

s/netconf/NETCONF/

    The NETCONF server is responsible for providing
    access control to stream content.

s/providing/applying/

-------------------------------------------------------------------------

6., para 6:

    If a user does not have permission to view content via other NETCONF
    operations it does not have permission to access that content via
    Notifications.  If a user is not permitted to view one element in the
    content of the notification, the notification is not sent to that
    user.

The first sentence is way out of scope and needs to be removed.
The access model in use is not defined in this document.
That model may not couple the configuration in this manner.

---------------------------------------------------------

7.:

There are 3 registrations, not 2.

1) Capability for notification support, used in <hello>

    URI: urn:ietf:params:netconf:capability:notification:1.0

2) Namespace URI for the XSD in 3.4:

    "urn:ietf:params:xml:ns:netmod:notification"

3) Namespace URI for the XSD in 4.:

    "urn:ietf:params:xml:ns:netconf:notification"

The 'targetNamespace' value currently in use in 4. is wrong:

    "urn:ietf:params:netconf:capability:notification:1.0"

------------------------------------------------------------

--
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: Fri, 13 Jul 2007 11:32:45 +0200 (CEST)

> 3.6, para 1:

[...]

> it 'passes', and an empty output node set means the filter 'failed'?

This is already defined for XPath, we should not change that.  Note
that an XPath expression does not have to return a 'node set', it can
also return a boolean, number or a string.  The XPath spec defines how
to interpret any of these as a boolean.

A subtree filter, on the other hand, can only return a node set.  The
text in 3.6 could say that a non-empty node set means that the filter
matches.

/martin

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 13 Jul 2007 12:22:13 +0200

Hello

> the agent will now be processed in the order they were received.
[BALAZS]: Buffering earlier received <rpc> operations for a potentially long time seems bad. I 
would prefere discarding all <rpc> operations before <replayComplete> and accepting only new 
<rpc> operations.

Balazs

---

From: Andy Bierman <[email-masked]>
Date: Fri, 13 Jul 2007 06:56:34 -0700

Balazs Lengyel wrote:
> [BALAZS]: Buffering earlier received <rpc> operations for a potentially 
> long time seems bad. I would prefere discarding all <rpc> operations 
> before <replayComplete> and accepting only new <rpc> operations.
> 

How does the agent know the next <rpc> just arrived or has been
in queue for an hour.  Isn't this implementation-dependent?
Wording it the other way (flush the queue) is also implementation-dependent.

But the other way, the manager would get no indication the <rpc> elements were
dropped.  It would wait for replies, and the agent would
wait for a new <rpc> -- and the session would hang.

> Balazs

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 13 Jul 2007 16:09:46 +0200

See below!
Andy Bierman wrote:
>> [BALAZS]: Buffering earlier received <rpc> operations for a 
>> potentially long time seems bad. I would prefere discarding all <rpc> 
>> operations before <replayComplete> and accepting only new <rpc> 
>> operations.
>>
> 
[BALAZS]: I think the manager should assume that anything it sent before receiving 
replayComplete will be discarded. It should not even send anything before that in the first 
place. You can still have a situation when the rpc request and replayComplete are sent at the 
same time, but if you like to live dangerously better have a timeout on the request.

On the other hand if the agent may store requests that arrived before the replayComplete was 
sent you end up with a lot of other questions:
- how long must an agent store rpc requests? 1 year?
- how many requests must it store?
- if the agent is not able to store all requests, it drops some. How will the manager know how 
many have been dropped?

As I see it discarding all requests is the best defined behavior we can prescribe.

Balazs

---

From: Andy Bierman <[email-masked]>
Date: Fri, 13 Jul 2007 07:31:05 -0700

Balazs Lengyel wrote:
> [BALAZS]: I think the manager should assume that anything it sent before 
> receiving replayComplete will be discarded. It should not even send 
> anything before that in the first place. You can still have a situation 
> when the rpc request and replayComplete are sent at the same time, but 
> if you like to live dangerously better have a timeout on the request.
> 

I think it is more useful to assume the more robust scenario than the most
fragile one.  Some agents may process RPCs during the notification replay,
and this document (right now) has no way for the manager to know that.
That means the manager cannot possibly know for sure if it should
wait for a reply or not.

> On the other hand if the agent may store requests that arrived before 
> the replayComplete was sent you end up with a lot of other questions:

This is an artifact of TCP.
The bytes will be there as long as the connection (and/or session)
has not been dropped.

> - if the agent is not able to store all requests, it drops some. How 
> will the manager know how many have been dropped?
> 

This is very implementation-biased.
Why is this the best, especially since the spec allows an agent
to process RPCs if it wants.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 13 Jul 2007 07:52:01 -0700

> to interpret any of these as a boolean.

Doesn't the draft need to say the Xpath expression needs to
be the boolean form? Or does it need to specify how the other
forms are converted to boolean? Or is this already handled in Xpath
and the draft can just say "convert to boolean"?

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 13 Jul 2007 16:41:10 +0200 (CEST)

> and the draft can just say "convert to boolean"?

The latter IMO.  (This is sort of underspecified in the base spec as
well - it just says that the filter is an XPath expression, but it is
not defined how the node-set is represented in the XML rpc-reply, and
nothing is said about boolean/number/string expressions.)

/martin

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 13 Jul 2007 19:40:08 +0200

> The bytes will be there as long as the connection (and/or session)

Sadly you can not use TCP buffer to store much data because:
- The maximum receive buffer for a socket on a linux system is usually (2*)87 kB. You may push 
that somewhat higher but a netconf manager can send you MBytes of requests. The agent's receive 
buffer will fill up, so it will not send ACK messages to the Manager. Then the manager's send 
buffer will also fill up which might block the manager program.

So in notification mode the agent better read the socket and do something with any arrived 
data, either discard it or store it in application space.

Balazs

---

From: Andy Bierman <[email-masked]>
Date: Fri, 13 Jul 2007 11:07:14 -0700

Balazs Lengyel wrote:
> - The maximum receive buffer for a socket on a linux system is usually 
> (2*)87 kB. You may push that somewhat higher but a netconf manager can 
> send you MBytes of requests. The agent's receive buffer will fill up, so 
> it will not send ACK messages to the Manager. Then the manager's send 

We are not trying to use TCP to store a lot of data for the
agent, in this weird corner-case.  There is clear WG consensus
that the agent can process these interleaved RPC requests
if it chooses, but this is not required.

> So in notification mode the agent better read the socket and do 
> something with any arrived data, either discard it or store it in 
> application space.

No, the client will eventually block, and stop sending.
This is no different than (normal mode) where the client
sends <rpc> requests faster than the agent is sending replies.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Fri, 13 Jul 2007 15:17:35 -0400

Balazs Lengyel writes:
>replayComplete will be discarded.

You can't make specs out of assumptions and living dangerously.  You
need "MUST"s and "MUST NOT"s.  Otherwise, code that works against one
conforming implementation will fail against another and no one will
be clearly at fault.

>You can still have a situation when the rpc request and replayComplete are sent at the 

A timeout won't close the timing window that you've opened, it will just
introduce another, possibly worse, one, since you have no idea how long
any RPC will take.

>As I see it discarding all requests is the best defined behavior we can prescribe.

Discarding leaves you with simlar questions:
- how will the server know when to stop discarding?
- how will the client know what was discarded?

So the facts seem to be:
(a) the client can put the connection into "notification" mode
(b) the server can put the connection into "rpc" mode 

There's no way the server can discard content from the client, since
it has no idea whether the content pre-dates the switch back into
"rpc" mode.

So is it worth _not_ allowing the server to put the connection
back into "rpc" mode?

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Fri, 13 Jul 2007 12:41:03 -0700

> So is it worth _not_ allowing the server to put the connection

You have exposed both sides of the issue:

1) What must/should/may an agent do with <rpc> input
    received while it is sending notifications?

[I agree with you that the agent must not discard this input.]

2) Should the corner-case where a stop time is given be handled
    by transitioning (silent or otherwise) from the 'sending replayed
    notifications' mode back to 'normal mode', or should it be
    handled the same way as when stop time is not provided
    (tail -f mode), by waiting for the manager to close the session?

[I share your concerns about this silent mode transition.
I would rather decide based on use cases rather than perceived
implementation complexity.  If we did as you suggest, then an
agent implementation is not forced to deal with any 'backed up' <rpc>
requests, but at some loss of functionality.  This mode
(get replays from time A to time B) could be viewed as just
another RPC operation like <get>.]

Andy

---

From: Phil Shafer <[email-masked]>
Date: Fri, 13 Jul 2007 15:50:15 -0400

Andy Bierman writes:
>This mode

Heck, all of get-notifications could be viewed as just another RPC
operation   ;^)

Thanks,
 Phil

P.s.: http://professional.juniper.net/phil/ietf/draft-shafer-netconf-syslog-00.txt

---

From: "David B Harrington" <[email-masked]>
Date: Sun, 15 Jul 2007 18:09:49 -0400

Hi,

I agree.

We could eliminate the replay attributes from the notification
operation, and a data model for logging unsent notifications could be
defined that can be accessed using a <get>. This way replay becomes a
data-model-specific thing, not an operation extension, and the
notification operation is vastly simplified.

All the extra text associated with replay that we are debating would
go away, and the netconf-equivalent of "end of table" would identify
when replay was complete.  

The SNMP community didn't define a new operation feature to provide
replay; they defined the NOTIFICATION LOG MIB. The MIB has the
following sections:

      o  Configuration -- control over how much the log can hold and
         what Notifications are to be logged.

      o  Statistics -- indications of logging activity.

      o  Log -- the Notifications themselves.

In this MIB, each log is named, and has an associated filter, and an
associated entry limit. In netconf terms, each "named" log of
notifications for replay could be considered a separate stream. So a
manager could subscribe for a replay-stream. But I like the <get>
approach.

With the MIB, a manager must explicitly ask that notifications be
logged (saved), and which notifications are of interest. The agent
does not need to save all notifications in case some manager decides
to ask for a filtered subset of the whole sometime in the future, but
is only required to save the notifications explicitly requested by a
manager when it requested the named log be maintained. And the maximum
number of entries in each log can be specified by the manager as well.

If a netconf manager was required to configure the replay log in
advance, then they could request only the notifications of interest;
this is similar to a subscribe. The MIB uses a "filter name" to
identify a filter predefined in a different table; this is similar to
the namedProfile feature of netconf-notifications. If the manager was
required to provide something akin to OwnerString, then once the
manager had accessed the notifications it had requested, then the
agent could discard the saved notifications "stream" (and a manager
could choose to delete their saved log). If no manager requests
replay, then the agent does not need to consume resources saving
notifications nobody wants. 

This seems consistent with the syslog.conf approach of allowing
operators to name logs, and specifying what they want saved into those
logs. Since notification replay is really all about replaying logs of
notifications, it would probably be a good thing to design an approach
consistent with existing widely-deployed logging mechanisms, such as
syslog, so that existing admin tools and scripts would work with the
netconf replay logs as well.

David Harrington
[email-masked]
[email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Phil Shafer
> Sent: Friday, July 13, 2007 3:50 PM
> To: Andy Bierman
> Cc: Balazs Lengyel; Netconf (E-mail)
> Subject: Re: notification-08 comments 
> 
> Andy Bierman writes:
> >This mode
> P.s.: 
> http://professional.juniper.net/phil/ietf/draft-shafer-netconf
> -syslog-00.txt
> 
> --

---

From: Andy Bierman <[email-masked]>
Date: Sun, 15 Jul 2007 16:01:53 -0700

> I agree.

Agree with what?
I don't think anybody suggested getting rid of replay.
But it was pointed out a long time ago that replay was
just a specialized <get> function.

I think the rationale is that it would be better to
design this feature like this, than force a manager to
read the log, and then transition to receiving
live notifications.  The agent has to handle that complexity
instead.

IMO, the replay feature is not a problem, but a logging DM
as you suggest is also useful.  Since the agent has to
implement filtering of some sort, why not search the
notification logs on the agent and just return items
of interest, and do it without adding a single extra
line of code or line of normative text?  Nah, too easy ;-)

(I supported just having a log as you suggest, but now
that replay is done, and the log DM is not started yet,
it is not worth changing now.)

Andy

---

From: Phil Shafer <[email-masked]>
Date: Sun, 15 Jul 2007 21:47:32 -0400

"David B Harrington" writes:
>This way replay becomes a

Isn't making replay data-model specific worse, since this will lead
to <n> different ways of doing it?

Thanks,
 Phil

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 16 Jul 2007 13:28:39 +0200

Hello,
I still feel that just letting data sent by the manager to sit in the TCP buffers is a bad 
thing to do. These buffers will fill up and this might block the manager SW. At that point the 
agent actually does not accept anything from the manager. According to the Postel principle you 
should be liberal what you accept. Accepting nothing is not liberal.

So in my view the client/agent should read the data from the connection buffers and do 
something with it. If not discard it then what?

I agree with you on one point: we need a precise definition about when Netconf connection 
enters and leaves notification mode. This should be described both for the agent and the manager.
Balazs

> introduce another, possibly worse, one, since you have no idea how long
[BALAZS]: Timeout was brought up by Andy as I remember.
> - how will the server know when to stop discarding?
[BALAZS]: start discarding after the create-subscription was replied with OK. Stop discarding 
after the replayComplete was sent.
> - how will the client know what was discarded?
[BALAZS]: It should not send anything after create-subscription until the replayComplete or 
create-subscription-error is received. If it still does send something we are in the gray area. 
The client must be prepared for lost rpc-requests.
> So is it worth _not_ allowing the server to put the connection
[BALAZS]: I can live with something like a tear_down of the connection, although an unusable 
connection left dangling is something I would not like.

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Mon, 16 Jul 2007 08:45:30 -0700

> to <n> different ways of doing it?

I think Dave means the WG would have to create a specific data model
to represent the control knobs and the data logs.  This is arguably
less work than what the WG already did for the embedded replay feature
within the <create-subscription> operation.

The feature in the spotlight here is the ability for a manager
to start listening for live notifications 'now', but after it 'catches up'
with any notifications of interest that occurred before 'now',
instead of concurrently listening for new notifications and
retrieving the missed notifications with <get>.

IMO, this is not the same feature as a notification log, it's better
(for the manager).  But a notification log would be just as interoperable.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 16 Jul 2007 09:28:44 -0700

Balazs Lengyel wrote:
> Hello,
> I still feel that just letting data sent by the manager to sit in the 
> TCP buffers is a bad thing to do. These buffers will fill up and this 
> might block the manager SW. At that point the agent actually does not 
> accept anything from the manager. According to the Postel principle you 

<co-Chair-hat-on>
We need to decide this issue based on perceived features and risks
to the operation of the network.  The implementation argument is a wash.
One implementer says it would be hard not to accept the new <rpc>.
Another says the opposite.  A third says it's the same amount
of new code either way.

The manager needs a better way to tell what the agent will do
in this case than to send an <rpc> request and wait some
unspecified time for an <rpc-reply>.

There is no technical reason that interleaving of <rpc-reply> and <notification>
elements to the manager should be forbidden, and at the same time, the
WG does not want to require the agent to support this 'interleave mode'.

However, this 'special mode' design is messy, not well documented,
and some WG members don't like it much:

    1) normal mode (<rpc> and <rpc-reply> only)
    2) normal notification mode (live <notification> only)
    3) replay notification mode (replayed notifications only, then
         transition to 'normal mode' after <replayComplete> is sent)
    4) tail-f mode (replay-then-live notifications only)
    5) interleave notification mode (any of modes (2) - (4), except
       the agent will respond if the manager sends an <rpc> request)

The deterministic and inter-operable resolution to this issue
must be part of the document.  It is OK if specific behavior
is optional, as long as the manager can easily know what to expect.
</co-Chair-hat-on>

> So in my view the client/agent should read the data from the connection 
> buffers and do something with it. If not discard it then what?
> 
> I agree with you on one point: we need a precise definition about when 
> Netconf connection enters and leaves notification mode. This should be 
> described both for the agent and the manager.

What exact edits are you proposing?

Andy

> Phil Shafer wrote:
>> Balazs Lengyel writes:
>>> [BALAZS]: I think the manager should assume that anything it sent 
>>> before receiving replayComplete will be discarded.
>>
>>> You can still have a situation when the rpc request and 
>>> replayComplete are sent at the same time, but if you like to live 
>>> dangerously better have a timeout on the request.
>>
> [BALAZS]: start discarding after the create-subscription was replied 
> with OK. Stop discarding after the replayComplete was sent.
> [BALAZS]: It should not send anything after create-subscription until 
> the replayComplete or create-subscription-error is received. If it still 
> does send something we are in the gray area. The client must be prepared 
> for lost rpc-requests.
>>
>> So the facts seem to be:
> [BALAZS]: I can live with something like a tear_down of the connection, 
> although an unusable connection left dangling is something I would not 
> like.
>>
>> Thanks,
>>  Phil
>