Re: [Netconf] Draft Charter Proposal for NETCONF WG

[Robert Wilton <[e-mail]>]

Hi Sue,


On 21/03/2017 17:38, Susan Hares wrote:
>
> Robert:
>
> Thank you for the comments.  Please see comments below.
>
> Sue
>
> *From:*Robert Wilton [mailto:[e-mail]]
> *Sent:* Tuesday, March 21, 2017 10:33 AM
> *To:* Susan Hares
> *Cc:* 'Mehmet Ersue'; 'Benoit Claise'; 'Netconf'
> *Subject:* Re: [Netconf] Draft Charter Proposal for NETCONF WG
>
> >Hi Sue,
>
> >Some comments (as one of the revised-datastore authors, but comments 
> are my own) inline ...
>
> >>
>
> >>On 21/03/2017 13:07, Susan Hares wrote:
>
> >>Mehmet and Benoit:
>
> >>
>
> >>I’m pleased to see the I2RS suggested additions split into 3 parts: 
> notification/events, revised datastore additions,  and the ephemeral 
> state additions for the I2RS protocol.   Just a few questions on how 
> this charter item is related to the I2RS >>requirements.
>
> >> My understanding is that the control plane datastore is in the 
> revised datastore additions.   Is this correct?
>
> >The revised datastores draft defines abstractly what a control plane 
> datastore looks like (4.2. Dynamic Datastores), and how they interact 
> with the system, but doesn't currently define any actual dynamic 
> ?datastores. My expectation is that various protocols would define 
> their dynamic datastores as part of their protocol drafts (as per 5. 
> Guidelines for Defining Dynamic Datastores).
>
> If you mean the protocols drafts – does that mean I2RS as a higher 
> –level protocol reusing other protocols (e.g., NETCONF or RESTCONF), 
> or the draft that specifies in the additions in NETCONF or RESTCONF.  
> That’s a little problematic for I2RS which is a re-use protocol 
> supporting multiple protocols.   It would be better to have a common 
> datastore description.
>
I think that you could have:
1) Some text defining the I2RS datastore (or a set of datatstores) that 
documents how those datastores fit into the datastore model defined in 
the revised datastores draft.
2) Some text for I2RS related RESTCONF extensions that references the 
(1) above.
3) Some text for I2RS related NETCONF extensions that references the (1) 
above.

As to whether this need to go into separate drafts or one draft, I don't 
know.  Personally, I think that it would be easier to review and keep 
consistent if they are in one document, but I'll leave that for the I2RS 
WG to decide.

>
>
> >> Will edit-collision prevention defined in the I2RS ephemeral state be 
> part of the revised datastores work?
>
> >I think that this is still open for discussion.
>
> >I2RS needs to perform conflict resolution between the various I2RS 
> clients.
>
> > I would expect that this conflict resolution would be defined 
> entirely alongside the I2RS datastore definition, and happen 
> completely within the I2RS datastore definition.
>
> >But there also needs to be conflict resolution between a generic 
> dynamic datastore and the operational datastore.  I think that this 
> should probably be defined in the datatstores draft.
>
> Should the general mechanisms for precedence (aka which datastore wins 
> if two of the same variables are set) – be done in a common way.
>
If the resolution is between a dynamic datastore and and the static 
configuration datastores then yes I think that this should be defined in 
a common way.

>
>
> >>RESTCONF (RFC8040) Entity-Tag and timestamp could be utilized for this 
> functionality.  It seems to fit better there.
>
> >>Is the constraint restrictions for cross datastore reference that the 
> i2rs ephemeral states going to be part of the revised-datastores work? 
>  Perhaps a more general mechanism for cross-datastore would be useful.
>
> >I think that this point still needs further discussion.
>
> >It isn't clear to me that allowing cross datastore references is the 
> right solution.
>
> >E.g. in the I2RS case, I had envisaged that one possible abstraction 
> for the I2RS datastore is that it might monitor and have some of the 
> operational state data logically mirrored into the I2RS datastore.  
> This ?>would potentially allow I2RS to validate its models entirely 
> within the I2RS datastore without requiring any cross datastore 
> references.  Further, it would also allow the I2RS datastore to 
> perform config >resolution between static configuration and I2RS 
> configuration and take whatever actions are appropriate, and feed any 
> updates back into the operational datastore.
>
> >Perhaps something like this diagram:
> >+------------+
> >                      | <intended> | // subject to validation
> >                      | (ct, ro)   |
> >+------------+
> >                            |
> >                            |      // e.g., missing resources, delays
> >                            |
> >                            |
> >                            | +------ I2RS datastore(s)
> >                            | |         ^
> >                            v v         |
> >+---------------+     | // I2RS monitors a subset of
> >                    | <operational> |-----+ // operational and can update
> >                    | (ct + cf, ro) |       // via a feedback loop.
> >+---------------+
>
> It does need more discussion.  Why is cross-datastore references for 
> “reading” a problem? Or are you just looking at writes?
>
> Constraints were written for “write checks” in I2RS.
>
It seems that the model is simpler if we can avoid cross datastore 
references.

The issues that I perceive are:
  - how are these cross datastore references defined?  Would this cause 
a tight coupling between models and datastores?
  - does it cause complexity in data integrity between the datastores, 
e.g. if I2RS is referencing state in operational that is being modified 
concurrently from intended.  Would I2RS expect to see a consistent 
snapshot across operational.
  - it effectively forces the cross referencing datastores to be 
implemented in the same place since they become tightly coupled.  If the 
definition wasn't tightly coupled then this could allow for more 
flexibility in the implementation (e.g. perhaps running I2RS in a 
different VM).

Hence, I think that the model may be conceptually simpler if cross 
datastore references are avoided, and validation is logically restricted 
to happening within a datastore.  Of course an implementation could 
choose to optimise this ...

> >>Interestingly, the revised-datastore document 
> (draft-ietf-netmod-revised-datastores-01) does not include a 
> “write-data” function for datastores.  Was this an oversight?
>
> >Again, I think that would be part of the I2RS datastore definition.
>
> Really? Is this because you believe the edit-collision problem will be 
> solved in lots of different ways.
>
I'm not really aware of other dynamic datastores currently coming along, 
so it somewhat hard to generalize.

I think that we need to have some simple rules to control how data flows 
into operational and which data takes precedence, but this may be as 
simple as last write wins.

But personally I think that all of the I2RS requirements concerning 
priority resolution between different I2RS clients and also local config 
should be solved in the I2RS datastore if possible.

> We should talk more.
>
> ===========
>
OK. I'm sure that we can catch up in Chicago.

Thanks,
Rob

>
> Thanks,
> Rob
>
> Thank you for taking the time to review this draft before IETF.
>
> Sue
>
>
>
>
> ·draft-ietf-netconf-rfc6536bis-01 
> <https://datatracker.ietf.org/doc/draft-ietf-netconf-rfc6536bis/>  - 
> provides access control module update . Will this be expanded as part 
> of the datastores effort?
>
> Thank you,
>
> Sue
>
> *From:*Mehmet Ersue [mailto:[e-mail]]
> *Sent:* Monday, March 20, 2017 12:33 PM
> *To:* 'Benoit Claise'; 'Susan Hares'
> *Cc:* 'Netconf'
> *Subject:* RE: [Netconf] Draft Charter Proposal for NETCONF WG
>
> Dear All,
>
> based on the recent discussion and proposals please find below the 
> updated charter proposal for NETCONF WG.
>
> Please comment before March 24, 2017.
>
> Following Benoit’s support the I2RS-related additions have been added 
> as a separated item.
>
> Being dependent on netmod-revised-datastores point 6 and 7 have been 
> defined as a goal without a deadline.
>
> Mehmet
>
> Network Configuration (netconf)
>
> -------------------------------
>
> Charter
>
> Current Status: Active
>
> Chairs:
>
>      Mahesh Jethanandani <[e-mail] 
> <mailto:[e-mail]>>
>
> Mehmet Ersue <[e-mail] <mailto:[e-mail]>>
>
> Operations and Management Area Directors:
>
>      Benoit Claise <[e-mail] <mailto:[e-mail]>>
>
>      Joel Jaeggli <[e-mail] <mailto:[e-mail]>>
>
> Operations and Management Area Advisor:
>
>      Benoit Claise <[e-mail] <mailto:[e-mail]>>
>
> Mailing Lists:
>
>      General Discussion: [e-mail] <mailto:[e-mail]>
>
>      To Subscribe: https://www.ietf.org/mailman/listinfo/netconf
>
> Archive: https://mailarchive.ietf.org/arch/browse/netconf/
>
> Description of Working Group:
>
>   Configuration of networks of devices has become a critical requirement
>
>   for operators in today's highly interconnected networks. Large and
>
>   small operators alike have developed their own mechanisms or have used
>
>   vendor specific mechanisms to transfer configuration data to and from
>
>   a device and to examine device state information which may impact the
>
>   configuration. Each of these mechanisms may be different in various
>
>   aspects, such as session establishment, user authentication,
>
>   configuration data exchange, and error responses.
>
>   The NETCONF protocol (RFC 6241) provides mechanisms to install,
>
>   manipulate, and delete the configuration of network devices. NETCONF
>
>   is based on the secure transport (SSH is mandatory to implement while
>
>   TLS is an optional transport). The NETCONF protocol is data modeling
>
>   language independent, but YANG (RFC 7950) is the recommended NETCONF
>
>   modeling language, which introduces advanced language features for
>
>   configuration management.
>
>   NETCONF WG recently finalized the development of RESTCONF protocol
>
>   (RFC 8040) which provides an interface over HTTPs for accessing data
>
>   defined in YANG. RESTCONF is based on the capabilities and uses the
>
>   datastore concept defined in the NETCONF protocol specification. In
>
>   support of RESTCONF the YANG-Patch (RFC 8072) mechanism has been
>
>   provided for applying patches to configuration datastores. The YANG
>
>   Module Library (RFC 7895) provides information about all YANG modules
>
>   used by a network management server.
>
>   Last but not least NETCONF and RESTCONF Call Home (RFC 8071) have been
>
>   developed, which enable a server to initiate a secure connection to a
>
>   NETCONF or RESTCONF client respectively.
>
>   In the current phase of NETCONF's incremental development the
>
>   workgroup will focus on following items:
>
>   1. Finalize the YANG data module for a system-level keystore mechanism,
>
>   that can be used to hold onto asymmetric private keys and certificates
>
>   that are trusted by the system advertising support for this module.
>
>   Based on the known dependencies this draft has the highest priority
>
>   for the WG.
>
>   2. Finalize Server and Client Configuration YANG modules for both
>
>   NETCONF and RESTCONF as well as the Client and Server Models for SSH
>
>   and TLS.
>
>   3. Finalize the Zero-touch provisioning for NETCONF or RESTCONF-based
>
>   Management as a technique to establish a secure network management
>
>   relationship between a newly delivered network device configured with
>
>   just its factory default settings, and the Network Management System)
>
>   4. Provide a revised version of RFC 6536 (NETCONF Access Control
>
>   Model) by adding support for RESTCONF and the YANG 1.1. constructs
>
>   like "action" and the "notification" statements.
>
>   5. Provide a set of documents enabling advanced notification/
>
>   subscription capabilities, which gracefully co-exist in a deployment
>
>   of RFC 5277. The new capabilities include e.g. transport independence,
>
>   multiple dynamic and configured subscriptions in a transport
>
>   session. RFC 5277 will be obsoleted in parallel to the publication of
>
>   the new document set. Following specifications will be addressed:
>
>    - Protocol-neutral notification framework, i.e., explaining the
>
>      concepts of subscriptions, filters, subscription state
>
>      notifications, replay, etc. and defining the associated YANG data
>
>      model, RPCs, etc.
>
>    - Definition of notifications sent over NETCONF and how YANG
>
>      notifications are encoded in XML and JSON. Include considerations
>
>      for parallel support / implementation compatibility with RFC-5277.
>
>    - Definition of notifications sent over RESTCONF and HTTP2 and how
>
>      YANG notifications are encoded in XML and JSON. Include specifics
>
>      of call-home and heartbeat for subscriptions.
>
>    - The subscription and push mechanism for YANG datastores allowing
>
>      subscriber applications to request updates from a YANG datastore.
>
>   6. Provide a revision for the NETCONF and RESTCONF protocols and the
>
>   used datastore framework building on the datastore concept in NETMOD
>
>   revised datastores work. Bug fixing will be done and potential
>
>   extensions will be added. Provide guidance on how to adapt and use
>
>   YANG with NETCONF and RESCONF protocols. NETCONF XML Encoding Rules
>
>   from RFC 7950 will be moved to RFC6241bis.
>
>   7. Define capabilities for NETCONF and RESTCONF to support I2RS 
> protocol
>
>   and ephemeral state datastore requirements.
>
>   Based on the implementation, deployment experience and inter-
>
>   operability testing, the WG aims to produce a NETCONF status report
>
>   in a later stage. The result may be clarifications for RFC6241 and
>
>   RFC6242 and addressing any reported errata.
>
> Goals and Milestones:
>
>   Done     Submit NETCONF/RESTCONF Call Home to AD/IESG for 
> consideration as Proposed Standard
>
>   Done     Submit YANG Library to AD/IESG for consideration as 
> Proposed Standard
>
>   Done     Submit RESTCONF to AD/IESG for consideration as Proposed 
> Standard
>
>   Done     Submit YANG Patch to AD/IESG for consideration as Proposed 
> Standard
>
>   May 2017 WGLC for Zero-touch configuration mechanism
>
>   Jun 2017 Submit Zero-touch configuration to AD/IESG for 
> consideration as Proposed Standard
>
>   May 2017 WGLC for system-level keystore mechanism
>
>   Jun 2017 Submit keystore mechanism to AD/IESG for consideration as 
> Proposed Standard
>
>   May 2017 WGLC for Server and Client models for NETCONF and RESTCONF
>
>   Jun 2017 Submit Server and Client Configuration models to AD/IESG 
> for consideration as Proposed Standard
>
>   May 2017 WGLC for Client and Server Models for SSH and TLS
>
>   Jun 2017 Submit Client and Server Models for SSH and TLS to AD/IESG 
> for consideration as Proposed Standard
>
>   Jun 2017 WGLC for RFC 6536bis (NETCONF Access Control Model)
>
>   Jul 2017 Submit RFC 6536bis to AD/IESG for consideration as Proposed 
> Standard
>
>   Jun 2017 WGLC for advanced Notification/Subscription specifications
>
>   Jul 2017 Submit Notification/Subscription specifications to AD/IESG 
> for consideration as Proposed Standard
>
> *From:*Benoit Claise [mailto:[e-mail]]
> *Sent:* Friday, March 17, 2017 4:49 PM
> *To:* Kent Watsen <[e-mail] <mailto:[e-mail]>>; 
> Mehmet Ersue <[e-mail] <mailto:[e-mail]>>; 'Susan 
> Hares' <[e-mail] <mailto:[e-mail]>>; 'Andy Bierman' 
> <[e-mail] <mailto:[e-mail]>>
> *Cc:* 'Netconf' <[e-mail] <mailto:[e-mail]>>
> *Subject:* Re: [Netconf] Draft Charter Proposal for NETCONF WG
>
> On 3/8/2017 12:57 AM, Kent Watsen wrote:
>
>     I agree with Mehmet, any changes to the NC/RC protocols should be
>     done in the NETCONF WG.
>
> +1.
>
> Regards, Benoit
>
>     K.
>
>     On 3/7/17, 3:15 PM, "Netconf on behalf of Mehmet Ersue"
>     <[e-mail] <mailto:[e-mail]> on
>     behalf of [e-mail] <mailto:[e-mail]>> wrote:
>
>     Hi Sue,
>
>     I personally prefer to publish such NC/RC add-ons in NETCONF WG as
>     they belong together.
>
>     I would like to suggest to discuss on the maillist and let NETCONF
>     WG decide in Chicago.
>
>     BR,
>
>     Mehmet
>
>     *From:* Susan Hares [mailto:[e-mail]]
>     *Sent:* Tuesday, March 7, 2017 7:36 PM
>     *To:* 'Mehmet Ersue' <[e-mail]> <mailto:[e-mail]>;
>     'Andy Bierman' <[e-mail]> <mailto:[e-mail]>
>     *Cc:* 'Juergen Schoenwaelder'
>     <[e-mail]>
>     <mailto:[e-mail]>; 't.petch'
>     <[e-mail]> <mailto:[e-mail]>; 'Netconf'
>     <[e-mail]> <mailto:[e-mail]>
>     *Subject:* RE: [Netconf] Draft Charter Proposal for NETCONF WG
>
>     Mehmet:
>
>     Sounds like a good plan to do the RESTCONF additions for I2RS in
>     I2RS.
>
>     How do we make this official?   Should we do the same for NETCONF
>     additions for I2RS?
>
>     Sue
>
>     *From:* Mehmet Ersue [mailto:[e-mail]]
>     *Sent:* Tuesday, March 7, 2017 12:34 PM
>     *To:* 'Susan Hares'; 'Andy Bierman'
>     *Cc:* 'Juergen Schoenwaelder'; 't.petch'; 'Netconf'
>     *Subject:* RE: [Netconf] Draft Charter Proposal for NETCONF WG
>
>     Hi Sue,
>
>     providing add-ons which don’t require republishing of
>     RESTCONF-8040 would be indeed important.
>
>     I don’t mind if add-ons to RESTCONF specific to I2RS are done in I2RS.
>
>     However forcing serious reviews early and publishing them in
>     NETCONF would be my preference.
>
>     In any case we need I2RS people working on it.
>
>     BR,
>
>     Mehmet
>
>     *From:* Susan Hares [mailto:[e-mail]]
>     *Sent:* Tuesday, March 7, 2017 5:27 PM
>     *To:* 'Andy Bierman' <[e-mail] <mailto:[e-mail]>>
>     *Cc:* 'Mehmet Ersue' <[e-mail] <mailto:[e-mail]>>;
>     'Juergen Schoenwaelder' <[e-mail]
>     <mailto:[e-mail]>>; 't.petch'
>     <[e-mail] <mailto:[e-mail]>>; 'Netconf'
>     <[e-mail] <mailto:[e-mail]>>
>     *Subject:* RE: [Netconf] Draft Charter Proposal for NETCONF WG
>
>     Andy:
>
>     Thank you for the clarification.  Since this is an Add-on and not
>     focused on the base specification, where should the Add-on
>     specification be worked on?  I2RS WG with final cross-review in
>     NETCONF?   It seems that NETCONF has lots of other work on the list.
>
>     Sue
>
>     *From:* Andy Bierman [mailto:[e-mail]]
>     *Sent:* Tuesday, March 7, 2017 11:25 AM
>     *To:* Susan Hares
>     *Cc:* Mehmet Ersue; Juergen Schoenwaelder; t.petch; Netconf
>     *Subject:* Re: [Netconf] Draft Charter Proposal for NETCONF WG
>
>     On Tue, Mar 7, 2017 at 7:01 AM, Susan Hares <[e-mail]
>     <mailto:[e-mail]>> wrote:
>
>     Mehmet:
>
>     These are clarifying question - not requests.
>
>     Do the items #6 and #7 on the charter include revising the NETCONF and
>     RESTCONF to serve as a control plane protocol that interacts with
>     the I2RS
>     control plane data store supporting the ephemeral datastore?   If
>     so, based
>     on the WGs comments it seems key players (Andy Bierman for
>     RESTCONF and a
>     group of players for NETCONF) do not want this work to be done in the
>     NETCONF WG.   Do I understand the sense of the mail list?
>
>     My position is that I2RS features can be done in its own RFC without
>
>     republishing the RESTCONF RFC.  Since this functionality is
>
>     optional-to-implement, a new protocol version is not required.
>
>         Sue Hares
>
>     Andy
>
>
>         -----Original Message-----
>         From: Netconf [mailto:[e-mail]
>         <mailto:[e-mail]>] On Behalf Of Mehmet Ersue
>         Sent: Friday, March 3, 2017 9:34 AM
>         To: 'Juergen Schoenwaelder'; 't.petch'
>         Cc: 'Netconf'
>         Subject: Re: [Netconf] Draft Charter Proposal for NETCONF WG
>
>         > Back to your question, it seems obvious to me that YANG and
>         the XML
>         encoding rules naturally belong to NETMOD, the 'NETCONF
>         protocol details
>         that NETCONF
>         > did not define' naturally belong to NETCONF.
>
>         Basically it is our aim to make the YANG language
>         specification generally
>         applicable to all protocols and to put protocol-specific
>         details into the
>         protocol specifications.
>
>         Mehmet
>
>         > -----Original Message-----
>         > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
>         <mailto:j.schoenwaelder@jacobs->
>         > university.de <http://university.de>]
>         > Sent: Friday, March 3, 2017 2:35 PM
>         > To: t.petch <[e-mail] <mailto:[e-mail]>>
>         > Cc: Kent Watsen <[e-mail]
>         <mailto:[e-mail]>>; Mehmet Ersue
>         > <[e-mail] <mailto:[e-mail]>>; 'Netconf'
>         <[e-mail] <mailto:[e-mail]>>; 'Benoit Claise'
>         > <[e-mail] <mailto:[e-mail]>>
>         > Subject: Re: [Netconf] Draft Charter Proposal for NETCONF WG
>         >
>         > On Fri, Mar 03, 2017 at 12:24:34PM +0000, t.petch wrote:
>         > > ----- Original Message -----
>         > > From: "Kent Watsen" <[e-mail]
>         <mailto:[e-mail]>>
>         > > Sent: Wednesday, March 01, 2017 8:14 PM
>         > >
>         > > > > Kent
>         > > > >
>         > > > > 7 is a monster because of the XML encoding rules, not
>         because of
>         > > > > the revised datastore concepts.  And datastores, as
>         you say, are
>         > > > > more important - revising the XML encoding rules is
>         cosmetic,
>         > > > > not needed technically and, as I said, only make sense
>         when the
>         > > > > NETMOD WG has
>         > > done
>         > > > > its bit; and the revised charter being discussed on
>         the NETMOD
>         > > > > list makes no mention of this work.
>         > > > >
>         > > > > So scrap NETCONF XML encoding rules.
>         > > > >
>         > > > > Tom Petch
>         > > >
>         > > >
>         > > > Hi Tom,
>         > > >
>         > > > Such changes fall under the "maintaining" clauses in the
>         NETMOD
>         > > charter:
>         > > >
>         > > >   a) Maintaining the data modeling language YANG.  This
>         effort entails
>         > > >      periodically updating the specification to address new
>         > > requirements
>         > > >      as they arise.
>         > > >
>         > > >   d) Maintaining encodings for YANG modeled data.  This
>         effort entails
>         > > >      updating encodings already defined by the NETMOD
>         working group
>         > > >      (XML and JSON) to accommodate changes to the YANG
>         specification,
>         > > >      and defining new encodings that are needed, and yet
>         do not fall
>         > > >      under the charter of any other active IETF working
>         group.
>         > >
>         > > Kent
>         > >
>         > > I was going to be sarcastic but resisted the temptation:-)
>         > >
>         > > I am unable to reconcile those paragraphs with
>         > >
>         > > 'NETCONF XML Encoding Rules from RFC 7950 will be moved to
>         > > RFC6241bis.'
>         > >
>         > > To me, they are on different planets; one puts XML
>         encoding rules in
>         > > the NETCONF WG and the NETCONF RFC, the other places them
>         in the
>         > > NETMOD WG and the NETMOD RFC.
>         > >
>         >
>         > YANG today defines the language plus its data encoding rules
>         into XML
>         > plus NETCONF protocol details that NETCONF did not define
>         (and the
>         > reason is simply that YANG was done after NETCONF and
>         nothing else).
>         >
>         > I think the goal is to move the NETCONF protocol details
>         that NETCONF
>         > did not define to the NETCONF specification. Some may want
>         to factor
>         > out the XML encoding out of the YANG specification as well,
>         similar to
>         > how we have JSON as a separate document. On the hand hand
>         this makes
>         > sense, on the other hand it makes it a bit more difficult to
>         write
>         > examples down in the YANG specification (since the examples then
>         > depend on another external specification - or one would have
>         to create
>         > yet another ad-hoc notation (YAAN).
>         >
>         > Back to your question, it seems obvious to me that YANG and
>         the XML
>         > encoding rules naturally belong to NETMOD, the 'NETCONF protocol
>         > details that NETCONF did not define' naturally belong to
>         NETCONF.
>         >
>         > /js
>         >
>         > --
>         > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>         > Phone: [phone]         Campus Ring 1 | 28759 Bremen
>         | Germany
>         > Fax:   [phone]       
>          <http://www.jacobs-university.de/>
>
>         _______________________________________________
>         Netconf mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/netconf
>
>         _______________________________________________
>         Netconf mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/netconf
>
>
>
>
>     _______________________________________________
>
>     Netconf mailing list
>
>     [e-mail] <mailto:[e-mail]>
>
>     https://www.ietf.org/mailman/listinfo/netconf
>
>
>
>
> _______________________________________________
> Netconf mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/netconf
>