Re: [netmod] Draft Minutes for Virtual Interim

[Jürgen Schönwälder]

Well, statements like "the WG agrees" are problematic for things that
have not been discussed on the mailing list. Perhaps it is the people
attending the interim agreed? Well, I can't tell, I have not been
there...

On Wed, Jan 31, 2024 at 02:15:56AM +, Kent Watsen wrote:
> Hi Jason,
> 
> > On Jan 30, 2024, at 11:55 AM, Jason Sterne (Nokia)  
> > wrote:
> > 
> > Hi WG,
> > (and in particular to those who attended the interim).
> >  
> > The summary below mostly matches my memory of the discussions, but I don’t 
> > really remember us concluding on this:
> >  
> >  The WG agreed to let 7950-bis "update" 8342 (NMDA) with the
> >  clarification the  alone does not have to be valid.
> >  E.g., clients may have to perform transforms to calculate
> >  , which is subject to validation.
> 
> The audio indicates Rob saying this and no one objecting.
> Are you objecting?
> 
> 
> >  (the rest of the minutes/summary below also seems to contradict that 
> > paragraph being a conclusion no?)
> 
> Your comments below are not text-edits to the minutes, so it is unclear how 
> they apply to the minutes.
> 
> Kent
> 
> 
> > I thought it was going to remain somewhat optional/indeterminate if running 
> > will be valid:
> > Servers may or may not enforce running to be valid (i.e. they may only 
> > validate intended as a proxy for validating running)
> > Clients can’t necessarily expect to be able to offline validate running, 
> > although it may work in circumstances where the operator doesn’t use 
> > templates or inactive config *or* the client reproduces the server logic 
> > for the running->intended transforms
> >  
> > Jason
> >  
> > From: netmod mailto:netmod-boun...@ietf.org>> On 
> > Behalf Of Kent Watsen
> > Sent: Monday, January 29, 2024 7:21 PM
> > To: netmod@ietf.org 
> > Subject: [netmod] Draft Minutes for Virtual Interim
> >  
> >  
> > CAUTION: This is an external email. Please be very careful when clicking 
> > links or opening attachments. See the URL nok.it/ext  
> > for additional information.
> >  
> > 
> > Link to minutes:
> > https://datatracker.ietf.org/doc/minutes-interim-2024-netmod-01-202401231400/
> >  
> > Reproduced below for convenience.
> >  
> > Please report any updates needed here.
> >  
> > Kent (and Lou)
> >  
> >  
> >  
> > This virtual interim was soley focused on the "system-config" draft.
> > Qiufang Ma presented.
> >  
> > Draft: https://datatracker.ietf.org/doc/draft-ietf-netmod-system-config
> >  
> > In the course of two hours, there was a lot of discussion.  So much so
> > that trying to capture all the points verbatim would take too long. A
> > link to the video is here: https://www.youtube.com/watch?v=sAF0fppqBGA.
> >  
> > A high-level summary is:
> >  
> >   Qiufang's presentation focused on two main questions?
> >  
> >   1) The "origin" issue.
> >  
> >  The WG agreed that  nodes copied into  should
> >  have origin "intended".  The system-config draft will "update"
> >  RFC 8342 (NMDA) to state this.
> >  
> >  The WG agreed that data-migration is 1) not -specific
> >  concern and 2) is out-of-scope for this draft.
> >  
> >   2) Validity of  alone.
> >  
> >  The WG agreed to let 7950-bis "update" 8342 (NMDA) with the
> >  clarification the  alone does not have to be valid.
> >  E.g., clients may have to perform transforms to calculate
> >  , which is subject to validation.
> >  
> >  The WG agreed on a new Option 4: this document doesn't say
> >  anything at all about the validity of .  That is,
> >  fully rely on existing 7950 and 8342 statements.
> >  
> >  This leaves it up to interpretation.
> >  
> >  Templates and inactive configuration are nice for humans, but
> >  unnecessary for machine-to-machine interfaces.  That is, the
> >  issues arounds such mechanisms are largely moot in environments
> >  using a controller.
> 

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


-- 
Jürgen Schönwälder  Constructor University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany

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

Re: [netmod] Draft Minutes for Virtual Interim

[Kent Watsen]

Hi Jason,

> On Jan 30, 2024, at 11:55 AM, Jason Sterne (Nokia)  
> wrote:
> 
> Hi WG,
> (and in particular to those who attended the interim).
>  
> The summary below mostly matches my memory of the discussions, but I don’t 
> really remember us concluding on this:
>  
>  The WG agreed to let 7950-bis "update" 8342 (NMDA) with the
>  clarification the  alone does not have to be valid.
>  E.g., clients may have to perform transforms to calculate
>  , which is subject to validation.

The audio indicates Rob saying this and no one objecting.
Are you objecting?


>  (the rest of the minutes/summary below also seems to contradict that 
> paragraph being a conclusion no?)

Your comments below are not text-edits to the minutes, so it is unclear how 
they apply to the minutes.

Kent


> I thought it was going to remain somewhat optional/indeterminate if running 
> will be valid:
> Servers may or may not enforce running to be valid (i.e. they may only 
> validate intended as a proxy for validating running)
> Clients can’t necessarily expect to be able to offline validate running, 
> although it may work in circumstances where the operator doesn’t use 
> templates or inactive config *or* the client reproduces the server logic for 
> the running->intended transforms
>  
> Jason
>  
> From: netmod mailto:netmod-boun...@ietf.org>> On 
> Behalf Of Kent Watsen
> Sent: Monday, January 29, 2024 7:21 PM
> To: netmod@ietf.org 
> Subject: [netmod] Draft Minutes for Virtual Interim
>  
>  
> CAUTION: This is an external email. Please be very careful when clicking 
> links or opening attachments. See the URL nok.it/ext  for 
> additional information.
>  
> 
> Link to minutes:
> https://datatracker.ietf.org/doc/minutes-interim-2024-netmod-01-202401231400/
>  
> Reproduced below for convenience.
>  
> Please report any updates needed here.
>  
> Kent (and Lou)
>  
>  
>  
> This virtual interim was soley focused on the "system-config" draft.
> Qiufang Ma presented.
>  
> Draft: https://datatracker.ietf.org/doc/draft-ietf-netmod-system-config
>  
> In the course of two hours, there was a lot of discussion.  So much so
> that trying to capture all the points verbatim would take too long. A
> link to the video is here: https://www.youtube.com/watch?v=sAF0fppqBGA.
>  
> A high-level summary is:
>  
>   Qiufang's presentation focused on two main questions?
>  
>   1) The "origin" issue.
>  
>  The WG agreed that  nodes copied into  should
>  have origin "intended".  The system-config draft will "update"
>  RFC 8342 (NMDA) to state this.
>  
>  The WG agreed that data-migration is 1) not -specific
>  concern and 2) is out-of-scope for this draft.
>  
>   2) Validity of  alone.
>  
>  The WG agreed to let 7950-bis "update" 8342 (NMDA) with the
>  clarification the  alone does not have to be valid.
>  E.g., clients may have to perform transforms to calculate
>  , which is subject to validation.
>  
>  The WG agreed on a new Option 4: this document doesn't say
>  anything at all about the validity of .  That is,
>  fully rely on existing 7950 and 8342 statements.
>  
>  This leaves it up to interpretation.
>  
>  Templates and inactive configuration are nice for humans, but
>  unnecessary for machine-to-machine interfaces.  That is, the
>  issues arounds such mechanisms are largely moot in environments
>  using a controller.

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

[netmod] I-D Action: draft-ietf-netmod-sub-intf-vlan-model-10.txt

[internet-drafts]

Internet-Draft draft-ietf-netmod-sub-intf-vlan-model-10.txt is now available.
It is a work item of the Network Modeling (NETMOD) WG of the IETF.

   Title:   Sub-interface VLAN YANG Data Models
   Authors: Robert Wilton
Scott Mansfield
   Name:draft-ietf-netmod-sub-intf-vlan-model-10.txt
   Pages:   34
   Dates:   2024-01-30

Abstract:

   This document defines YANG modules to add support for classifying
   traffic received on interfaces as Ethernet/VLAN framed packets to
   sub-interfaces based on the fields available in the Ethernet/VLAN
   frame headers.  These modules allow configuration of Layer 3 and
   Layer 2 sub-interfaces (e.g.  L2VPN attachment circuits) that can
   interoperate with IETF based forwarding protocols; such as IP and
   L3VPN services; or L2VPN services like VPWS, VPLS, and EVPN.  The
   sub-interfaces also interoperate with VLAN tagged traffic orignating
   from an IEEE 802.1Q compliant bridge.

   The model differs from an IEEE 802.1Q bridge model in that the
   configuration is interface/sub-interface based as opposed to being
   based on membership of an 802.1Q VLAN bridge.

   The YANG data models in this document conforms to the Network
   Management Datastore Architecture (NMDA) defined in RFC 8342.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-sub-intf-vlan-model/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-netmod-sub-intf-vlan-model-10.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-netmod-sub-intf-vlan-model-10

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


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

[netmod] I-D Action: draft-ietf-netmod-intf-ext-yang-13.txt

[internet-drafts]

Internet-Draft draft-ietf-netmod-intf-ext-yang-13.txt is now available. It is
a work item of the Network Modeling (NETMOD) WG of the IETF.

   Title:   Common Interface Extension YANG Data Models
   Authors: Robert Wilton
Scott Mansfield
   Name:draft-ietf-netmod-intf-ext-yang-13.txt
   Pages:   33
   Dates:   2024-01-30

Abstract:

   This document defines two YANG modules that augment the Interfaces
   data model defined in the "YANG Data Model for Interface Management"
   with additional configuration and operational data nodes to support
   common lower layer interface properties, such as interface MTU.

   The YANG modules in this document conform to the Network Management
   Datastore Architecture (NMDA) defined in RFC 8342.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-intf-ext-yang/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-netmod-intf-ext-yang-13.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-netmod-intf-ext-yang-13

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


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

Re: [netmod] [Editorial Errata Reported] RFC8407 (7791)

[mohamed . boucadair]

Hi Dale, all, 

I don't think filling an erratum is appropriate here given that the original 
text is not broken (including the URL). I suggest to reject it. 

However, text enhancements can be considered as part of 
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8407bis/. Let's have that 
discussion. Thanks.

Cheers,
Med

> -Message d'origine-
> De : netmod  De la part de RFC Errata System
> Envoyé : mardi 30 janvier 2024 18:01
> À : rfc-edi...@rfc-editor.org
> Cc : wor...@alum.mit.edu; netmod@ietf.org
> Objet : [netmod] [Editorial Errata Reported] RFC8407 (7791)
> 
> The following errata report has been submitted for RFC8407,
> "Guidelines for Authors and Reviewers of Documents Containing YANG
> Data Models".
> 
> --
> You may review the report below and at:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> rfc-
> editor.org%2Ferrata%2Feid7791=05%7C02%7Cmohamed.boucadair%40orang
> e.com%7C2cb3e186d23d4eac917208dc21b511f8%7C90c7a20af34b40bfbc48b9253b6
> f5d20%7C0%7C0%7C638422308774178382%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
> wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C
> data=6Qi9sKVPa44FCI8dW984szRS1EZso%2FpPr%2BRDnsGkobE%3D=0
> 
> --
> Type: Editorial
> Reported by: Dale R. Worley 
> 
> Section: GLOBAL
> 
> Original Text
> -
> There are two related items.
> 
> 1) Section 3.7.1 "Security Considerations Section Template" begins
> 
>X.  Security Considerations
> 
>The YANG module specified in this document defines a schema for
> data
>that is designed to be accessed via network management protocols
> such
>as NETCONF [RFC6241] or RESTCONF [RFC8040].  The lowest NETCONF
> layer
>is the secure transport layer, and the mandatory-to-implement
> secure
>transport is Secure Shell (SSH) [RFC6242].  The lowest RESTCONF
> layer
>is HTTPS, and the mandatory-to-implement secure transport is TLS
>[RFC8446].
> 
> 2) RFC 8470 says "the latest approved template (available at
)".  But
the template at that URL says "the latest approved template (available
at
http://trac.tools.ietf.org/area/ops/trac/wiki/yang-security-guidelines)."> 
> 
> Corrected Text
> --
> 1) It would be helpful if the beginning of the template contained a
> reference to RFC 8407 to provide a pointer back to where the templated
> section of Yang module definitions was instantiated from.  Perhaps
> starting the template with "[Instantiated from the template of
> [RFC8407] section 3.7.1.]"
> 
> 2) While the URL given in RFC 8407 works, the URL given in the online
> template only goes to a generic page, "Welcome to the IETF Community
> Wiki".  Presumably the URL in the online template should be the URL of
> that page itself.
> 
> 
> 
> Notes
> -
> Item (2) is a straightforward correction.  Item (1) is in service to
> having better pointers/references in our documents.
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". (If it is spam, it
> will be removed shortly by the RFC Production Center.) Please use
> "Reply All" to discuss whether it should be verified or rejected. When
> a decision is reached, the verifying party will log in to change the
> status and edit the report, if necessary.
> 
> --
> RFC8407 (draft-ietf-netmod-rfc6087bis-20)
> --
> Title   : Guidelines for Authors and Reviewers of
> Documents Containing YANG Data Models
> Publication Date: October 2018
> Author(s)   : A. Bierman
> Category: BEST CURRENT PRACTICE
> Source  : Network Modeling
> Area: Operations and Management
> Stream  : IETF
> Verifying Party : IESG
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fnetmod=05%7C02%7Cmohamed.boucadai
> r%40orange.com%7C2cb3e186d23d4eac917208dc21b511f8%7C90c7a20af34b40bfbc
> 48b9253b6f5d20%7C0%7C0%7C638422308774195518%7CUnknown%7CTWFpbGZsb3d8ey
> JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7
> C%7C%7C=leytvbSQ1TP9MT8wI1X5ZmoVMlpuC8k6UCRs40pfXv8%3D=
> 0

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments 

[netmod] [Editorial Errata Reported] RFC8407 (7791)

[RFC Errata System]

The following errata report has been submitted for RFC8407,
"Guidelines for Authors and Reviewers of Documents Containing YANG Data Models".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7791

--
Type: Editorial
Reported by: Dale R. Worley 

Section: GLOBAL

Original Text
-
There are two related items.

1) Section 3.7.1 "Security Considerations Section Template" begins

   X.  Security Considerations

   The YANG module specified in this document defines a schema for data
   that is designed to be accessed via network management protocols such
   as NETCONF [RFC6241] or RESTCONF [RFC8040].  The lowest NETCONF layer
   is the secure transport layer, and the mandatory-to-implement secure
   transport is Secure Shell (SSH) [RFC6242].  The lowest RESTCONF layer
   is HTTPS, and the mandatory-to-implement secure transport is TLS
   [RFC8446].

2) RFC 8470 says "the latest approved template (available at
)".  But
the template at that URL says "the latest approved template (available
at
http://trac.tools.ietf.org/area/ops/trac/wiki/yang-security-guidelines)."


Corrected Text
--
1) It would be helpful if the beginning of the template contained a
reference to RFC 8407 to provide a pointer back to where the templated
section of Yang module definitions was instantiated from.  Perhaps
starting the template with "[Instantiated from the template of
[RFC8407] section 3.7.1.]"

2) While the URL given in RFC 8407 works, the URL given in the online
template only goes to a generic page, "Welcome to the IETF Community
Wiki".  Presumably the URL in the online template should be the URL of
that page itself.



Notes
-
Item (2) is a straightforward correction.  Item (1) is in service to
having better pointers/references in our documents.

Instructions:
-
This erratum is currently posted as "Reported". (If it is spam, it 
will be removed shortly by the RFC Production Center.) Please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
will log in to change the status and edit the report, if necessary.

--
RFC8407 (draft-ietf-netmod-rfc6087bis-20)
--
Title   : Guidelines for Authors and Reviewers of Documents 
Containing YANG Data Models
Publication Date: October 2018
Author(s)   : A. Bierman
Category: BEST CURRENT PRACTICE
Source  : Network Modeling
Area: Operations and Management
Stream  : IETF
Verifying Party : IESG

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

Re: [netmod] Draft Minutes for Virtual Interim

[Jason Sterne (Nokia)]

Hi WG,
(and in particular to those who attended the interim).

The summary below mostly matches my memory of the discussions, but I don't 
really remember us concluding on this:

 The WG agreed to let 7950-bis "update" 8342 (NMDA) with the
 clarification the  alone does not have to be valid.
 E.g., clients may have to perform transforms to calculate
 , which is subject to validation.

(the rest of the minutes/summary below also seems to contradict that paragraph 
being a conclusion no?)

I thought it was going to remain somewhat optional/indeterminate if running 
will be valid:

  *   Servers may or may not enforce running to be valid (i.e. they may only 
validate intended as a proxy for validating running)
  *   Clients can't necessarily expect to be able to offline validate running, 
although it may work in circumstances where the operator doesn't use templates 
or inactive config *or* the client reproduces the server logic for the 
running->intended transforms

Jason

From: netmod  On Behalf Of Kent Watsen
Sent: Monday, January 29, 2024 7:21 PM
To: netmod@ietf.org
Subject: [netmod] Draft Minutes for Virtual Interim


CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See the URL nok.it/ext for additional information.


Link to minutes:
https://datatracker.ietf.org/doc/minutes-interim-2024-netmod-01-202401231400/

Reproduced below for convenience.

Please report any updates needed here.

Kent (and Lou)



This virtual interim was soley focused on the "system-config" draft.
Qiufang Ma presented.

Draft: https://datatracker.ietf.org/doc/draft-ietf-netmod-system-config

In the course of two hours, there was a lot of discussion.  So much so
that trying to capture all the points verbatim would take too long. A
link to the video is here: https://www.youtube.com/watch?v=sAF0fppqBGA.

A high-level summary is:

  Qiufang's presentation focused on two main questions?

  1) The "origin" issue.

 The WG agreed that  nodes copied into  should
 have origin "intended".  The system-config draft will "update"
 RFC 8342 (NMDA) to state this.

 The WG agreed that data-migration is 1) not -specific
 concern and 2) is out-of-scope for this draft.

  2) Validity of  alone.

 The WG agreed to let 7950-bis "update" 8342 (NMDA) with the
 clarification the  alone does not have to be valid.
 E.g., clients may have to perform transforms to calculate
 , which is subject to validation.

 The WG agreed on a new Option 4: this document doesn't say
 anything at all about the validity of .  That is,
 fully rely on existing 7950 and 8342 statements.

 This leaves it up to interpretation.

 Templates and inactive configuration are nice for humans, but
 unnecessary for machine-to-machine interfaces.  That is, the
 issues arounds such mechanisms are largely moot in environments
 using a controller.
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] No YANG Versioning call Feb 6

[Jason Sterne (Nokia)]

Hi all,

There is no YANG Versioning weekly call on Tuesday February 6th.

I'd encourage everyone to attend the Virtual Interim for the immutable-flag 
instead.

Jason (he/him)

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

[netmod] I-D Action: draft-ietf-netmod-acl-extensions-06.txt

[internet-drafts]

Internet-Draft draft-ietf-netmod-acl-extensions-06.txt is now available. It is
a work item of the Network Modeling (NETMOD) WG of the IETF.

   Title:   Extensions to the Access Control Lists (ACLs) YANG Model
   Authors: Oscar Gonzalez de Dios
Samier Barguil
Mohamed Boucadair
Qin Wu
   Name:draft-ietf-netmod-acl-extensions-06.txt
   Pages:   80
   Dates:   2024-01-30

Abstract:

   RFC 8519 defines a YANG data model for Access Control Lists (ACLs).
   This document discusses a set of extensions that fix many of the
   limitations of the ACL model as initially defined in RFC 8519.

   The document also defines IANA-maintained modules for ICMP types and
   IPv6 extension headers.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-extensions/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-netmod-acl-extensions-06.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-netmod-acl-extensions-06

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


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