RE: requirement: notification content self-containment

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

<Andy>

It should be a requirement that the notification message
will contain enough header data to fully decode the notification.  Info
from the session, connection, or other notifications must not be
required for an application to decode the notification contents.

This has 2 important implications:

1) There is no real reason the notifications need to come back
   on the same session that RPC operations occurred  which
   possibly caused the notifications.
</Andy>

This doesn't really follow from the requirement, but are you suggesting
a design alternative that when I create a subscription, I specify which
Netconf session to send things to? That could be a fun attack to 

<Andy>
2) Session parameters such as the subscription-id need to be
   replaced with parameters that have meaning to a general
   application.  This is important if the notifications are
   being logged or centrally processed by a 3rd party application.
<Andy>

If I have the subscription id, why do I need the session ID? I also
wouldn't think a third party would use either the session Id or the
subscription id in their log. They are both transient and only unique
within the context of an NE. It would prefer identifiers like device
name (or IP) and perhaps some other fields.

Sharon


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


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