Re: [netmod] [i2rs] RFC 8340 to 8346 published

[Susan Hares]

Benoit:

 

A Big Thank you to you and Alia Atlas!   I’m thrilled to see the I2RS topology 
RFCs happen. 

 

Sue Hares 

 

From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Benoit Claise
Sent: Saturday, March 17, 2018 6:36 PM
To: NETMOD Working Group; NETCONF; i...@ietf.org
Subject: [i2rs] RFC 8340 to 8346 published

 

Dear all,

RFC8340  | 
draft-ietf-netmod-yang-tree-diagrams-06.txt

RFC8341  | 
draft-ietf-netconf-rfc6536bis-09.txt
RFC8342  | 
draft-ietf-netmod-revised-datastores-10.txt
RFC8343  | 
draft-ietf-netmod-rfc7223bis-03.txt
RFC8344  | 
draft-ietf-netmod-rfc7277bis-03.txt
RFC8345  | 
draft-ietf-i2rs-yang-network-topo-20.txt
RFC8346  | 
draft-ietf-i2rs-yang-l3-topology-16.txt

Congratulations to all persons involved.

Regards, Benoit

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] schema mount situation and next steps

[Benoit Claise]

Dear all,

In the last two weeks, I've been multiplying the schema mount discussions.
It's now time to draw the conclusions and to move on.

I'm sad that schema-mount is not NMDA compliant. We approved RFC6087bis 
with the NMDA transition guidelines.
I'm sad that progression to IETF-LC has not been completed on the 
schema-mount document since the WGLC in November.


As discussed with the document shepherd Joel, there is not a strong 
support position for the schema mount document (version 08), but rough 
consensus. The interaction with YANG library bis has been noted during 
the WGLC. What happened since that WGLC closure on Nov6th is that the 
people position became tougher and that multiple possible tracks have 
been investigated. I believe we heard the arguments from everybody.


Taking my AD responsibilities, what's next?

1. We have been losing so much time (which I regret) since the WGLC that 
publishing 08 now makes sense, solving one aspect of the problem: the 
situation where the set of YANG modules is the same in all datastores. 
Is this perfect solution? Certainly not.
The LNE and NI documents, in the RFC editor queue, depend on the version 
8 of schema mount.

So let's pursue that publication path.

2. The document 08 should be edited before requesting the publication.
- The draft should be clearly specified that this solution is not fully 
NMDA complaint. For example, in the abstract
- The draft should mention an applicability statement, such as the one 
the chairs proposed:


   This work was produced during the period when NMDA solutions were being
   developed in parallel. While the model defined in this document can be
   used with both NMDA and non-NMDA supporting implementations, there are
   limitations in its NMDA applicability. When used with Yang Library
   [RFC7895] only non-NMDA implementations can be supported. When used with
   the revised Yang Library defined in [I.D.ietf-netconf-rfc7895bis], NMDA
   implementations can be supported with certain limitations. Specifically,
   this document requires use of the now deprecated module-list grouping,
   and the same schema represented in schema list of ietf-schema-mount MUST
   be used in all datastores. Inline type mount points, which don't use the
   schema list, don't have this limitation as they  can support different
   schema in different datastores by instantiating the
   [I.D.ietf-netconf-rfc7895bis] version of YANG library under the inline
   mount point. A future revision of this work is expected to provide for
   full NMDA support.

- Some edits are needed: the nits from the YD review
https://www.ietf.org/mail-archive/web/netmod/current/msg19443.html
Another one, addressing one of Lada's important complaints.

   The use of mount points does not impact the nature of the mounted data
   or in which datastore information is made available. For example, the
   datastore from which YANG Library module information may be obtained is
   not impacted by the use of schema mount.  This is case for both the top
   level YANG Library module and any YANG Library modules included under a
   mount point. The Schema Mount module itself MUST be present in the same
   datastore as the YANG Library module.

Next, we want to work on a NMDA solution, based on the pre-09 version 
 I guess.
This solution will obsolete the current 08 document and reference the 
YANG library bis.


Let's dedicate the full second NETMOD session (on Wednesday) to schema 
mount and let's use our energy to focus on the best solution.


Regards, Benoit (as OPS AD)


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] RFC 8340 to 8346 published

[Benoit Claise]

Dear all,

RFC8340 | 
draft-ietf-netmod-yang-tree-diagrams-06.txt
RFC8341 | 
draft-ietf-netconf-rfc6536bis-09.txt
RFC8342 | 
draft-ietf-netmod-revised-datastores-10.txt
RFC8343 | 
draft-ietf-netmod-rfc7223bis-03.txt
RFC8344 | 
draft-ietf-netmod-rfc7277bis-03.txt
RFC8345 | 
draft-ietf-i2rs-yang-network-topo-20.txt
RFC8346 | 
draft-ietf-i2rs-yang-l3-topology-16.txt


Congratulations to all persons involved.

Regards, Benoit
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Protocol Action: 'A YANG Data Model for Syslog Configuration' to Proposed Standard (draft-ietf-netmod-syslog-model-26.txt)

[The IESG]

The IESG has approved the following document:
- 'A YANG Data Model for Syslog Configuration'
  (draft-ietf-netmod-syslog-model-26.txt) as Proposed Standard

This document is the product of the Network Modeling Working Group.

The IESG contact persons are Warren Kumari and Benoit Claise.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/





Technical Summary

This document defines a YANG data model for the configuration of a
syslog process.  It is intended this model be used by vendors who
implement syslog in their systems.

Working Group Summary

  Was there anything in WG process that is worth noting? For 
  example, was there controversy about particular points or 
  were there decisions where the consensus was particularly 
  rough?

Yes, the model initially had defined support for configuring
Syslog over TPC (RFC 6587).  However, after reviewing the
reasoning for why RFC 6587 was made HISTORIC, as decided to
remove the support.  Some stated that their companies support
Syslog over TCP and now they would have to augment this model
with a vendor-specific extension.  There may be a subtle
distinction between IETF defining an insecure protocol versus
defining a data model to configure, amongst other things, an
insecure protocol.  We believe we did the right thing, from
an IETF perspective, but please double-check this.

Document Quality
  Are there existing implementations of the protocol? Have a 
  significant number of vendors indicated their plan to 
  implement the specification? Are there any reviewers that 
  merit special mention as having done a thorough review, 
  e.g., one that resulted in important changes or a 
  conclusion that the document had no substantive issues? If 
  there was a MIB Doctor, Media Type or other expert review, 
  what was its course (briefly)? In the case of a Media Type 
  review, on what date was the request posted?

This draft defines a data model (not a protocol).  So far,
two vendors have indicated that they're interested in
implementing this data model.  There was a YANG Doctor
review on the -17 that was successful:


https://datatracker.ietf.org/doc/review-ietf-netmod-syslog-model-17-yangdoctors-lc-watsen-2017-09-12/

Personnel

  The Shepherd is Kent Watsen.  The AD is Benoit Claise.

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod