[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Netconf Notifications P-WG LC: Issues & Proposed Resolutions
Hi
Here are proposed resolutions for comments received just after the last
call.
(PLC1) The subscription metaphor is unnecessary and confusing. There's
no win from introducing it, since the subscription isn't a visible
protocol element, nor is it visible to the client application.
Use something like <start-notifications> instead. (source Phil)
Proposed resolution: This issue has been discussed and the current draft
reflects working group consensus. Propose no change.
(PLC 2) The <notification> element shouldn't be a top-level tag. The
first netconf add-on should not require modification to the simple
RPC protocol we put in netconf. It's both a bad precedent and
unnecessary. The content can live inside a normal <rpc-reply>.
(source Phil)
This draft introduces a modality into the netconf session which is
both subtle and disturbing. When a request for notification is
issued, the session moves from netconf-rpc mode into
netconf-notification mode. When the notifications are complete,
the session silently reverts back to rpc mode. The transition is
not signalled by any top-level operation.
Proposed solution: A lot of this was discussed in the Montreal meeting.
This modality goes away if you define an optional capability that can
process requests while sending notifications. We have also previously
discussed the layering issues around not having an RPC-layer wrapper.
What is in the document reflects working group consensus. Propose no
change.
(PLC 3) The draft as written does not provide a solution to the
notification problem. It is a wrapper. The meat is in the
notifications themselves, and the draft does nothing to define a
standard way of carrying the common notification formats. In
particular, a syslog and an SNMP trap mapping are needed. (source
Phil)
Proposed Resolution: While I agree it is unfortunate that we don't
define notification content (not SNMP or syslog, but rather Netconf
stuff), the lack of it reflects working group consensus. Propose no
changes.
(PLC 4) Other editorial issues with the draft. In general, the draft is
poorly organized, with numerous forward references to content that
has not been discussed, often in vague terms without a concrete
reference. (source Phil)
Proposed Resolution: Are there specific forward references that are
causing issue? The document is currently organized to introduce concepts
and then explain them. I find this much more readable then here are some
Lego blocks and now let's build them into the thing we are talking
about. But, if this is causing confusion, it would be good to identify
those items which are confusing readers and resolve them either via a
reference or via reorganizing the text. In resolving another issue, some
definitions are being added to the terminology section, so I imagine
this will help. Propose no further change.
(PLC 5) I'd also like to re-address the <foo-bar> .vs. <fooBar>
inconsistency, hoping for a better interest than the handful of people
that voted in the working group meeting. (source Phil)
Proposed Resolution: We don't seem to have consensus to change things.
Propose no change.
(PLC 6) I was originally quite confused about why this picture was
included in this draft, since I missed the <notification> addition.
Looking at the new picture, the layer violation becomes more obvious. I
find it particularly disturbing when I think that this draft modifies
all four of these layers.
My preference is for something that lives within the netconf framework,
without requiring changes throughout it. (source Phil)
Proposed Resolution: While the original proposal did not require a layer
violation, the current picture reflects working group consensus. Propose
no change.
(PLC 7) > Managed Object: A collection of one of more Elements that
define an
> abstract thing of interest.
This term is never referenced. (source Phil)
Proposed Resolution: This is a duplicate of issue number 1
(PLC 8)
> Subscription: A concept related to the delivery of notifications
(if
> any to send) involving destination and selection of
notifications.
> It is bound to the lifetime of a session.
This definition is very weak. See above comments re: subscriptions.
(source Phil)
Proposed Resolutions: Were these some specific edits or issues?
(PLC 9) This definition is very weak. See above comments re:
subscriptions.
> Operation: This term is used to refer to NETCONF protocol
> operations. Specifically within this document, operation refers
> to NETCONF protocol operations defined in support of NETCONF
> notifications.
Can we include terms from the base spec implicitly?
There are _many_ terms missing here, including replay, streams,
profiles, and filters (maybe?). (source Phil)
Proposed Resolution: Add definition of replay, stream and profile.
Filter and filter elements can be defined implicitly from the Netconf
base specification.
Replay: Ability to send/re-send previously logged notifications upon
request. These notifications are sent asynchronously. This feature is
implemented by the NETCONF server and invoked by the NETCONF client.
Stream: An event stream is a set of event notifications matching some
forwarding criteria and it is available to NETCONF clients for
subscription.
Named Profile: A pre-defined set of filtering criteria residing in the
Network Element which may be applied to a notification session at
subscription creation time.
(PLC 10)
> An event is something that happens which may be of interest - a
> configuration change, a fault, a change in status, crossing a
> threshold, or an external input to the system, for example. Often
> this results in an asynchronous message, sometimes referred to as a
> notification or event notification, being sent out to interested
> parties to notify them that this event has occurred.
s/sent out/sent/
s/ to notify them that this event has occurred// (source Phil)
Proposed Resolution: In section 1.1, where the definition of event is
being moved as a result of another edit, s/sent out/sent/. Propose no
change from second proposed edit as the current text seems fine.
(PLC 11)
> This memo defines a mechanism whereby the NETCONF client indicates
> interest in receiving event notifications from a NETCONF server by
> creating a subscription to receive event notifications. The NETCONF
> server replies to indicate whether the subscription request was
> successful and, if it was successful, begins sending the event
> notifications to the NETCONF client as the events occur within the
> system. These event notifications will continue to be sent until
> either the NETCONF session is terminated or the subscription to
> terminate for some other reason. The event notification
subscription
> allows a number of options to enable the NETCONF client to specify
> which events are of interest. These are specified when the
> subscription is created.
s/subscription to/subscription/ (source Phil)
Proposed Resolution: In section 1.2, second paragraph (first after
definition of event is moved) s/subscription to terminate/subscription
terminates/
(PLC 12)
> An NETCONF server is not required to process RPC requests on the
> session associated with the subscription until the notification
> subscription is done and may silently discard these requests. A
> capability may be advertised to announce that a server is able to
> process RPCs while a notification stream is active on a session.
s/An NETCONF/A NETCONF/ (source Phil)
Proposed Resolution: There are apparently two camps on this question of
grammar. http://www.gpuss.co.uk/english_usage/a_or_an.htm For
consistency with the base protocol ;-) propose changing to "A NETCONF"
(PLC 13)
>1.3. Motivation
>
> The motivation for this work is to enable the sending of
asynchronous
> messages that are consistent with the data model (content) and
> security model used within a NETCONF implementation.
This section seems odd, since the more detailed model given in 1.2.
(source Phil)
Proposed Resolution: Move section 1.3 above section 1.2
(PLC 14) > o solution should provide a subscription mechanism (A
NETCONF server
> does not send notifications before being asked to do so and the
> NETCONF client initiates the flow of notifications)
Use of subscriptions isn't the requirement; the parenthetical sentence
is the real requirement. (source Phil)
Proposed Resolution: And collectively they define the requirement.
Propose no change.
(PLC 15)
>2. Notification-Related Operations
The underlaying model from Section 3 (Supporting concepts) should appear
before this section. Diving straight into operations without giving the
reader a framework into which those operations fit puts syntax over
semantics. (source Phil)
Proposed Resolution: This is a duplication of 27.
(PLC 16)
>2.1.1. <create-subscription>
> Description:
> This operation initiates an event notification subscription which
> will send asynchronous event notifications to the initiator of
the
> command until the subscription to terminates.
s/to terminates/is terminated/ or /terminates/
Can this description be improved? The subscription doesn't send
notifications, but instructs the server to initiate sending
notifications for events that match the given criteria. (source Phil)
Proposed Resolution: In section 2.1.1, s/to terminates/terminates/. The
second point seems to be splitting hairs. The subscription is what makes
the server send the notifications.
(PLC 17) > Stream:
> An optional parameter that indicates which stream of events is
> of interest. If not present, then events in the default
> NETCONF stream will be sent.
Streams are not defined at the point in the draft. (source Phil)
Proposed Resolution: As specified in (PLC 9), we shall add this
definition to the terminology section.
(PLC 18)
> Filter:
> 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. This is mutually exclusive
> with the named profile parameter.
Include a reference to the section on filters. (source Phil)
Proposed Resolution: Add text "See section 3.5 for more information on
filers.\
(PLC 19)
> Named Profile:
> An optional parameter that points to a separately defined
> filter profile. If not present, no additional filtering will
> be applied. Note that changes to the profile after the
> subscription has been created will have no effect. This is
> mutually exclusive with the filter parameter
This needs a forward reference also.
Changes "points to" to "refers to".
Missing period on last sentence. (source Phil)
Proposed Resolution: In section 2.1.1 in the section on Named profile,
add a period to the last sentence. Change "points to" to "refers to".
Add text at the end which says "For more information on named profiles,
see section 3.5.1.
(PLC 20)
> Start Time:
> A parameter used to trigger the replay feature and indicates
> that the replay should start at the time specified. If start
> time is not present, this is not a replay subscription.
Why not refer to parameters by their real names, like start-time?
Talk about the acceptable formats for this parameter. (source Phil)
Proposed Resolution: In section 2.1.1, in the section on start time,
replace "If start time" with "If startTime". Add text that says "This
parameter is of type dateTime."
(PLC 21)
>2.2. Sending Event Notifications
> Once the subscription has been set up, the NETCONF server sends the
> event notifications asynchronously along the connection.
s/along/over/ (source Phil)
Proposed resolution: In section 2.2, replace "the NETCONF server sends
the event notifications asynchronously along the connection" with "the
NETCONF server sends the event notifications asynchronously over the
connection"
(PLC 22) >2.2.1. <notification>
>
> Description:
>
> An event notification is sent to the initiator of a <create-
> subscription> command asynchronously when an event of interest
> (i.e. meeting the specified filtering criteria) to them has
> occurred. An event notification is a complete and well-formed
XML
> document. Note that <notification> is not an RPC method but
> rather the top level element identifying the one way message as a
> notification.
It should mention that the encoding of this element is transport
specific, which I guess means we need to rev all the transport RFCs.
Use ""client" instead of "initiator". It's confusing.
It's not clear that "filtering criteria" refers to more than <filter>.
The contents of the <data> element are never discussed. It should at
least say that the draft is not concerned with content. (source Phil)
Proposed Resolution: I don't think we actually need to say anything
about the encoding for transport beyond what was said in the base
protocol. Propose no change.
In section 2.2.1, in the description, replace "sent to the initiator of
a <create-subscription>" with "sent to the client who initiated the
<create-subscription>"
Filtering criteria just reads better in the sentence. I don't think it
will cause confusion. Propose no change.
In section 2.2.1, in the "Data" section, add the text that says "The
content of the data tag is beyond the scope of this document."
(PLC 23)
>2.3. Terminating the Subscription
> Closing of the event notification subscription can be done by
> terminating the NETCONF session ( <kill-session> ) or the underlying
> transport session. If a stop time is provided when the subscription
> is created, then the subscription will terminate after the stop time
> is reached. In this case, the Netconf session will still be an
> active session.
This introduces a modality into netconf sessions that I dislike,
especially since the triggers that switch the modes are buried inside
the content. There's nothing at the <rpc> layer to tell you that you've
moved from <rpc> mode to <notification> mode.
The reference to <kill-session> is odd, since I can't see this being
used in any real way. Are we expecting people to open a second session
to kill their first session? This is the way the text reads but I can't
imagine that's the intention. (source Phil)
Proposed Resolution: Yes, this is one method that people could use to
terminate the session. We also mention terminating the underlying
transport session. Propose no change.
(PLC 24)
>3. Supporting Concepts
Supporting concepts (semantics) should appear before syntactic content.
Otherwise the reader is lost. (source Phil)
Proposed Resolution: This is a duplicate of issue (PLC 4).
(PLC 25)
>3.2. Event Streams
> An event stream is defined herein as a set of event notifications
> matching some forwarding criteria.
s/herein// since all definitions are specific to this document.
s/forwarding// since it doesn't make sense. (source Phil)
Proposed Resolution: In section 3.2, replace "An event stream is defined
herein" with "An event stream is defined". I believe though that the
term forwarding is used to indicate that they are forwarded from the
general event system within the box to the Netconf event system. The
fact that the stream exists outside of the context of Netconf is
important from my understanding.
(PLC 26)
> +----+
> | c1 |---+ available streams
> +----+ | +---------+
> +----+ | |central |-> stream 1
> | c2 | +--->|event |-> stream 2 filter +-------+
> +----+ | |processor|-> netconf stream --->|netconf|
> ... | | |-> stream n |server | see
> System | +---------+ +-------+ below
> Components| | //
> ... | | //
> +----+ | | (------------)
> | cn |---+ | (notification)
> +----+ +-----> ( logging )
> ( service )
> (------------)
What are the "//" marks for? The "see below" is confusing, since the
"below" boxes look like orphans. (source Phil)
Proposed Resolution: In section 3.2, in the figure, remove the "//"
characters on line lines 9 and 10, replace with line-arrow from
"notification logging service" to "netconf server". This shows that
logged notifications are sent to the netconf server (replay feature).
Also remove the text "see below".
(PLC 27)
>3.2.1. Event Stream Definition
>
> Event streams are predefined on the managed device. The
> configuration of event streams is outside the scope of this
document.
> However, it is envisioned that event streams are either pre-
> established by the vendor (pre-configured) or user configurable
(e.g.
> part of the device's configuration) or both. Device vendors may
> allow event stream configuration via NETCONF protocol (i.e. edit-
> config operation)
3.2 starts with the definition of event streams.
This section doesn't read well. It would be better to start with the
event model, add event streams, add netconf, and then draw a picture of
the final world view. (source Phil)
Proposed Resolution: I'm not sure what is specifically being requested.
Propose no change.
(PLC 28)
>3.2.2. Event Stream Content Format
> 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.
XML, but what sort? Can I just put a string under <data>? Do I need my
own container tag? Can I put multiple elements in a <data>? Are there
any rules? (source Phil)
Proposed Resolution: I believe working group consensus was not to
specify much here. I suppose <data> is the wrapper. Propose no change.
(PLC 29)
>3.2.3. Default Event Stream
> A NETCONF server implementation supporting the notification
> capability must support the "NETCONF" notification event stream.
> This stream contains all NETCONF XML event notifications supported
by
> the NETCONF server. The definition of the event notification and
> their contents for this event stream is outside the scope of this
> document.
We define a stream without a notification data model? How does this
work? What possible purpose could it serve? Clients spontaneously
"know" how to interpret these events?
s/event notification/event notifications/ ? (source Phil)
Proposed Resolution: This reflects working group consensus. I will
confess to not fully getting the appeal of streams, but, again, this is
working group consensus.
In section 3.2.3 replace "The definition of the event notification and
their contents" with "The definition of the event notifications and
their contents".
(PLC 30) >3.2.4. Event Stream Sources
> With the exception of the default event stream (NETCONF
> notifications) specification of additional event stream sources
(e.g.
> SNMP, syslog, etc.) is outside the scope of this document. NETCONF
> server implementations may leverage any desired event stream source
> in the creation of supported event streams.
I don't understand this section. Is it placing any sort of limitation
on an NETCONF implementation? What should be NETCONF implementor read
into it? Just that they can do what they want? Do we need to tell them
that explicitly? (source Phil)
Proposed Resolution: Working group consensus was that we were not going
to talk about the content. As a technical contributor, I'm not pleased
with that, but it is what it is. Give that, I don't know what sort of
restrictions we can place on implementers. Propose no changes.
(PLC 31)
>3.2.5.1. Name Retrieval using <get> operation
>
> The list of available event streams is retrieved by requesting the
> <eventStreams> subtree via a <get>operation. Available event
streams
> for the requesting session are returned in the reply containing the
> <name> and <description> elements, where <name> element is mandatory
> and its value is unique. 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. The information is retrieved by requesting the
> <eventStreams> subtree via a <get> operation.
s/<get>operation/<get> operation/ (source Phil)
Proposed Resolution: This is a duplicate of (23)
(PLC 32)
> <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:base:1.0"/>
> </filter>
> </get>
> </rpc>
What is "netmod"? Should this be under ":netconf:notification:1.0"?
Are we intentionally making "netmod" .vs. "netconf" distinctions? Can
you explain the distinction? (source Phil)
Proposed Resolution: Netmod is the de facto name people have been using
for Netconf content. (NETconf MODel). Based on other issues, we assume
here a separate namespace for the content. The urn matches the pattern
used by other things in
http://www.iana.org/assignments/xmlregistry/ns.html. In general the
naming of the content URN has been an issue in every update. Propose
changing from netmod:base to netmod:notifications since this brings us
closer to where we need to be.
(PLC 33)
>3.2.5.2. Event Stream Subscription
> A NETCONF client may request from the NETCONF server the list of
> available event streams to this session and then issue a <create-
> subscription> request with the desired event stream name. Omitting
> the event stream name from the <create-subscription> request results
> in subscription to the default NETCONF event stream.
Why is this a feature, rather than a bug in the client code? Are we
expecting an overwhelming use of the NETCONF stream that it makes sense
to use it as the default? (source Phil)
Proposed Resolution: Yes, I expect that sending Netconf content over the
Netconf Notification interface will be common. It's also the simplest
thing to talk about in a Netconf protocol specification. Implementations
sending content from other streams just need to specify those other
streams. Propose no change.
(PLC 34) Section 3.3
I skipped the schema, but will note that there normative text in the
schema that is not in the real text. I don't know if this is
intentional or not, but it's a bit confusing, especially given that
people don't tend to read the schemas. <xs:documentation> elements are
a poor source of specification. Better to move these discussion into
the text.
In particular, the bits about profiledata imply that it's configuration
data, but there's no data model to go with it.
For example, how to I change the <name> of a named-profile?
Also there are some odd rules about timestamps, and the interaction
between fielded requests and the profiles. IMHO, this is best left to
the implementation because (a) it's a corner case and (b) it's expensive
to treat corner cases in ways that your implementation considered
unnatural. If you force rigid behavior, you're likely to be ignored
anyway. Best to leave it undefined. (source Phil)
Proposed Resolution: Actually, we found in SNMP that the descriptions
were very important; more important then the text in the rest of the
document. I agree for the protocol definitions the opposite might be
true, but we are talking content definitions here.
The name object in the named profile is modifiable so to change it, you
would just change it. We have not discussed what happens if that named
profile is currently in use. There are some options we could take here
to fix this ambiguity. I would suggest adding additional text to
lastModified to clarify things. "Note there is no guarantee that the
profile named in the subscription will be found at all."
I assume for the last point you are talking about the lastModified
field, except that this does not describe any behaviour on the server,
rather tell the client how to interpret the information. Propose no
change.
(PLC 35) >3.4. Subscriptions not Configuration Data
s/not/are not/
>While it may be possible to retrieve information about subscriptions
>via a get operation, subscriptions are not stored configuration.
This makes it sound like you can get configuration via <get>, which is
not true. Better to just explain that subscriptions are not
configuration data, and their lifetime is defined by their session.
> Named profiles, if used, are considered configuration data.
Profiles may also be built into the device, right? (source Phil)
Proposed resolution: The first bit is a duplicate of (7)
The description of the <get> operation in RFC 4741 Is "Retrieve running
configuration and device state information", but I do like the
clarifying text you have suggested. In section 3.4, replace "They are
non-persistent state information" with "They are non-persistent state
information and their lifetime is defined by their session".
By built into the device I assume you mean configured in the default
configuration. If so, the answer is yes.
(PLC 36) >3.5. Filter Dependencies
s/Dependencies/Mechanics/?
>3.5.1. Named Profiles
> A named profile is a filter that is created ahead of time and
applied
> at the time an event notification subscription is created . Note
> that changes to the profile after the subscription has been created
> will have no effect on the subscription. Since named profiles exist
> outside of the subscription, they persist after the subscription has
> been torn down.
s/created ./created./
Again, the "changes" part is better seen as implementation-specific
behavior. (source Phil)
Proposed Resolution: Rename the title of section 3.5 from "Filter
Dependencies" to "Filter Mechanics". In section 3.5.1, delete the extra
space after 'created' and before the period.
The behaviour around what happens when named profile is modified is
necessary for predictability and is working group consensus. Propose no
changes.
(PLC 37) >4. XML Schema for Event Notifications
Why are some imports documented and other not? (source Phil)
Proposed Resolution: The documents required to pass validation have been
imported while those not required or not. In another issue we determined
that netconf:notification is not actually used in this schema so its
important statement will therefore be deleted.
(PLC 38)
>6.1. Overview
>
> Replay is the ability to create an event subscription that will
> resend recently sent notifications. These notifications are sent
the
> same way as normal notifications.
s/recently sent/recently generated/ since they may not have been sent
anywhere.
> The actual number of stored notifications available for retrieval at
> any given time is an NETCONF server implementation specific matter.
> Control parameters for this aspect of the feature are outside the
> scope of the current work.
s/the current work/this document/
> This feature is dependent on a notification stream supporting some
> form of notification logging, although it puts no restrictions on
the
> size or form of the log, nor where it resides within the device.
s/This feature/Replay/ (source Phil)
Proposed Resolution: In section 6.1, first paragraph, replace "resend
recently sent notifications" with "resend recently generated
notifications". In the fourth paragraph, replace "scope of the current
work" with "scope of this document". In the fifth paragraph, replace
"This feature is dependent" with "This feature is dependent".
(PLC 39)
>6.2. Creating a Subscription with Replay
> This feature uses optional parameters to the <create-subscription>
> command called 'startTime' and 'stopTime'. 'startTime' identifies
the
> earliest date and time of interest for event notifications being
> replayed and also indicates that a subscription will be providing
> replay of notifications. Events generated before this time are not
> matched. 'stopTime' specifies the latest date and time of interest
> for event notifications being replayed. If it is not present, then
> notifications will continue to be sent until the subscription is
> terminated.
Talk about the transition to live events.(source Phil)
Proposed Resolution: In section 6.2, add text that says "A replay
complete notification is sent to trigger that all of the replay
notifications have been sent. If this subscription has a stop time, then
this session becomes a normal NETCONF session again. In the case of a
subscription without a stop time, after the replay complete notification
has been sent, it can be expected that any notifications generated since
the start of the subscription creation will be sent followed by
notifications as they arise naturally within the system."
(PLC 40)
> 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.
This paragraph should just say event time should be relative to the time
the event occurred and the notification was generated.
Discussing the other times is confusing.
Is there a way to say <stop-time>now</stop-time> to avoid waiting for
live events? (source Phil)
Proposed Resolution: In section 6.2, replace "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." with startTime and stopTime are associated with the
time an event was generated by the system."
Replay is optional, so not specifying it means you get the real-time
notifications right away. I agree that having to wait for the replay to
continue to get real-time notifications is unfortunate, but I'm not sure
how it address it given previous working group consensus. Note that, as
currently defined, stopTime is implicitly defined to be now.
(PLC 41)
> Thanks to Gilbert Gagnon, Greg Wilbur and Kim Curran for providing
> their input into the early work on this document. In addition, the
> editors would like to acknowledge input at the Vancouver editing
> session from the following people: Orly Nicklass, James Balestriere,
> Yoshifumi Atarashi, Glenn Waters, Alexander Clemm, Dave Harrington,
> Dave Partain, Ray Atarashi and Dave Perkins and the following
> additional people from the Montreal editing session: Balazs Lengyel,
> Phil Shafer, Rob Ennes, Andy Bierman, Dan Romascanu, Bert Wijnen,
> Simon Leinen, Juergen Schoenwaelder, Hideki Okita, Vincent Cridlig,
> Martin Bjorklund, Olivier Festor, Radu State, Brian Trammell,
William
> Chow.
s/Ennes/Enns/ (source Phil)
Proposed Resolution: In section 8, s/Ennes/Enns/
Sharon Chisholm
Nortel
Ottawa, Ontario
Canada
--
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/>