[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
some more interim notes
Hi,
attached are some more notes. The meaning of all this will be
explained by the chairs. ;-)
/js
--
Juergen Schoenwaelder International University Bremen
<http://www.eecs.iu-bremen.de/> P.O. Box 750 561, 28725 Bremen, Germany
1. solution should focus on notification support for configuration [AB]
=> R1: required to identify configuration changes on a device
2. solution should support structured hierarchical data [BL, SC]
=> not meaningful since we do not focus on the content of a notification
3. solution should be able to carry configuration fragments [?]
=> not meaningful since we do not focus on the content of a notification
4. solution should support a reasonable message size limit (syslog and
SNMP are rather constrained in terms of message sizes) [BL]
=> netconf does not impose message size constraints
5. solution should provide reliable delivery of notifications [BL]
=> netconf does have a reliable transport which is good enough
6. solution should support preconfigured notification destinations [AB]
=> nice to have feature if there is a solution - ISMS is investigating
whether there is a solution for SSH (seems to be easy over BEEP)
=> this is just a notification specific instantiation of the call home
feature (see below)
7. solution should support agent initiated connections [KW]
=> this is a transport issue and as such must be handled outside the
notification work
8. solution should provide a subscription mechanism [HT]
=> subscription is vague - does it mean a subscription that is bound
to the lifetime of a session or is it a more permanent subscription?
=> R2: an agent does not send notifications before asked to do so
=> R3: the manager initiates the flow of notifications
9. solution should support multiple subscriptions [RP]
=> netconf supports multiple session which means that multiple
subscription in separate different sessions is covered
=> multiple subscriptions over the same session are not required
10. solution should provide a filtering mechanism [HT]
=> R4: yes
11. solution should support notification names [BL]
=> notification names belong into the data content
=> R5: it is required to be able to filter on the data content
12. solution should support notification timestamps [BL]
=> notification timestamps belong into the data content
13. solution should support notification classes [SC]
=> notification classes belong into the data content
14. solution should support notification info [BL]
=> notification info belong into the data content
15. solution should provide the ability to specify the content of
notifications to ensure predictability [SC]
=> notifications should be formally defined, to be addressed by data
modeling language efforts
16. solution should send sufficient information in a notification so
that it can be analyzed independent of the transport mechanism [AB]
=> R6: data content fully describes a notification; protocol information
is not needed to understand a notification
17. solution should allow notifications to refer to prior configuration
change RPCs
=> belongs into the data content
18. solution should not bind subscriptions to a connection [RP]
=> sounds a bit too complex - unclear what the real use case is
19. channels for configuration change notifications should share fate
with a session that includes a configuration channel [DP]
=> R7: sessions are independent
20. solution should support replay of locally logged notifications [KW]
=> need to distinguish between retrieval of logged notifications and
replay of notifications
=> might be a capability
=> R8: yes
21. solution should support message chunking capability in cases
channels carry mixed RPCs [KW]
=> netconf does not interleave messages, no chunking/fragmentation needed
22. solution should scale to 30.000-100.000 nodes which may emit
notifications [BL]
=> the netconf transport has already been decided
23. solution should scale to order 30.000-100.000 nodes to send
notifications [BL]
=> dropped
----------------------------------------------
Consensus Points:
=> The solution will support multiple event streams
=> There will be a special named stream to carry "netconf"
notifications
=> There might be other special named streams to carry "snmp"
notifications
=> Filters are applied before a notification is shipped over a
session. Filters are established as part of the subcription (and
they share fate with the underlying session
=> An empty filter matches all notifications
=> The configuration of streams is out of scope for the current work
in this working group
----------------------------------------------
There are three potential ways to ship notifications:
a) One big (potentially never ending) reply that ships multiple
notifications
b) A subscribe RPC followed by a sequence of "linked" replies, each
one carrying a notification (but no other RPCs interleaved)
c) Same as b) but interleaved requests are allowed
S: <rpc-reply> S: <rpc-notify-reply>
S: <data> S: <data>
S: <event> S: </data>
S: </event> S: </rpc-notify-reply>
S: <event> S: ]]>]]>
S: </event> S: <rpc-notify-reply>
S: </data> S: <data>
S: </rpc-reply> S: </data>
S: ]]>]]> S: </rpc-notify-reply>
S: ]]>]]>
=> There was consensus towards b). A server is not required to process
RPC requests until the notification stream is done
=> A capability may be defined to announce that a server is capable to
process RPCs while a notification stream is active on a session
=> Every implementation should be correct
----------------------------------------------
The WG editors will rewrite the WG notification document. It was
requisted to remove all the appendices.
----------------------------------------------
Discussion of standard <get> operation vs. collections of specific
<get-xxx> operations. One point raised was that a specialized
operation might have the feature that it can pull things together from
different subtrees and namespaces, e.g. <get-vlan-info> with parameter
42 might retrieve all information related to vlan 42.
----------------------------------------------
<ns:ietf ns="urn:ietf:params:xml:ns:netconf-data:1.0">
<ns:netconf>
<ns:stream>
<ns:name>snmp</ns:name>
<!-- ... -->
</ns:stream>
</ns:netconf>
</ns:ietf>
Q: What is the granularity of a namespace?
Q: How does the granularity affect filter expressions?
----------------------------------------------
The function library of XPATH 2.0 supports regular expressions in the
function library. XPATH 1.0 does not have something like that.