[netmod] Re: IPR call on immutable-flag-02

[maqiufang (A)]

Hi, Kent, all,

No, I'm not aware of any IPR that applies to this draft.

Best Regards,
Qiufang
From: Kent Watsen [mailto:kent+i...@watsen.net]
Sent: Thursday, February 27, 2025 6:25 AM
To: draft-ietf-netmod-immutable-f...@ietf.org
Cc: netmod@ietf.org
Subject: Re: IPR call on immutable-flag-02

[sorry for the noise]

Responses needed from the listed authors:

- Qiufang Ma
- Qin Wu
- Balazs Lengyel
- Hongwei Li

Kent




On Feb 26, 2025, at 5:19 PM, Kent Watsen 
mailto:kent+i...@watsen.net>> wrote:

Authors, Contributors, WG,

As a prerequisite for the WGLC on this document:

YANG Metadata Annotation for Immutable Flag

https://datatracker.ietf.org/doc/html/draft-ietf-netmod-immutable-flag-02

Are you aware of any IPR that applies to draft identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft”
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules”
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate.

If you are listed as a document author or contributor please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author.

Also please send the response to the list above, and not unicast it.

FWIW, no IPR was declared when the draft was adopted 
(https://mailarchive.ietf.org/arch/msg/netmod/5zI7gGWucJ-AZm52X_B7p_H1uP0/)
 nor currently filed for this draft: 
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ma-netmod-immutable-flag

Thanks.
Kent (and Lou)


___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org

[netmod] Re: I-D Action: draft-ietf-netmod-schedule-yang-04.txt

[maqiufang (A)]

Hi, chairs, all, 

The authors have published this version for several weeks, yet no follow-up 
received from the WG. We believe this version has addressed all comments 
received during the WGLC. Considering the fact that several other documents 
from other WGs are dependent on this work, we kindly request the chairs to 
close the WGLC and move it forward. Thanks a lot!

Best Regards,
Qiufang // on behalf of authors

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: Saturday, February 8, 2025 2:23 PM
To: i-d-annou...@ietf.org
Cc: netmod@ietf.org
Subject: [netmod] I-D Action: draft-ietf-netmod-schedule-yang-04.txt

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

   Title:   A Common YANG Data Model for Scheduling
   Authors: Qiufang Ma
Qin Wu
Mohamed Boucadair
Daniel King
   Name:draft-ietf-netmod-schedule-yang-04.txt
   Pages:   64
   Dates:   2025-02-07

Abstract:

   This document defines a common schedule YANG module which is designed
   to be applicable for scheduling purposes such as event, policy,
   services, or resources based on date and time.  For the sake of
   better modularity, the module includes a set of recurrence related
   groupings with varying levels of representation (i.e., from basic to
   advanced) to accommodate a variety of requirements.  It also defines
   groupings for validating requested schedules and reporting scheduling
   status.

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

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

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

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


___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org
___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org

[netmod] Re: I-D Action: draft-ietf-netmod-system-config-12.txt

[maqiufang (A)]

Hi, all,

This version incorporates some follow-up comments from Rob (thanks a lot Rob!) 
The authors believe we are ready to move forward now.

Best Regards,
Qiufang //co-author

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: Thursday, February 13, 2025 2:09 PM
To: i-d-annou...@ietf.org
Cc: netmod@ietf.org
Subject: [netmod] I-D Action: draft-ietf-netmod-system-config-12.txt

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

   Title:   System-defined Configuration
   Authors: Qiufang Ma
Qin Wu
Chong Feng
   Name:draft-ietf-netmod-system-config-12.txt
   Pages:   32
   Dates:   2025-02-12

Abstract:

   The Network Management Datastore Architecture (NMDA) in RFC 8342
   defines several configuration datastores holding configuration.  The
   contents of these configuration datastores are controlled by clients.
   This document introduces the concept of system configuration
   datastore holding configuration controlled by the system on which a
   server is running.  The system configuration can be referenced (e.g.,
   leafref) by configuration explicitly created by clients.

   This document updates RFC 8342.

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

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-system-config-12

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

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


___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org
___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org

[netmod] Re: WG Last Call - A Common YANG Data Model for Scheduling

[maqiufang (A)]

Hi, Rob,

Thanks a lot for the review, apologize for the delay.
The authors have submitted -04 
(https://datatracker.ietf.org/doc/html/draft-ietf-netmod-schedule-yang-04, diff 
is available at 
https://author-tools.ietf.org/iddiff?url2=draft-ietf-netmod-schedule-yang-04) 
which incorporates some of your concerns/comments below, please also see my 
reply below inline. My co-authors may want to comment more if they want.

From: Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
Sent: Tuesday, February 4, 2025 6:28 PM
To: James Cumming (Nokia) ; 
draft-ietf-netmod-schedule-y...@ietf.org
Cc: NETMOD WG Chairs ; netmod@ietf.org
Subject: Re: WG Last Call - A Common YANG Data Model for Scheduling

Hi authors, WG,

Sorry for a late WGLC review.  I would like to thank the authors working on 
this document.  Like Adrian, I also think that this document will be useful, 
but I do have a few concerns/comments.

Moderate level comments:

(1) p 4, sec 3.1.  Features

   Refer to Section 3.4 for the use of these features.

I'm not sure that these YANG features are really useful/helpful.  Given this 
module only defines groupings, then if modules using these groupings are also
predicated by these features then the same constraint on basic-recurrence or 
icalendar-recurrence will affect all modules.

Will it always be the case that they will want a shared fate, or would it be 
better for the modules using these groupings to define their own module 
specific feature statements?  I.e., this draft could suggest that uses of the 
groupings define their own features if needed, or just say nothing at all and 
assume that they will do the right thing.
I am unsure about this, currently we have different complex levels of 
recurrence representation, features are defined to allow implementations to 
declare which one they support (e.g., through YANG-library). You are right that 
consumer modules can define their own specific feature statement, but the 
initial consideration for defining features here is for better usage 
consistency. Does the clarification help?


(2) p 7, sec 3.3.1.  The "generic-schedule-params" Grouping

 grouping generic-schedule-params:
   +-- description?string

Most of the definitions include a description, but I would have thought that in 
many instances the description would likely be superfluous to requirements.  Of 
course, when the groupings are used the description statement could be 
deviated, but I think that it may be better to elide the description from the 
groupings and then it could be augmented in during the uses statements, if 
needed by the uses of these groupings.
The description parameter could be useful to record any other comments and 
details that cannot be available in the structure. The authors had some 
internal discussion and we incline to keep this in -04, but would also welcome 
any other feedback from the WG.

(3) p 7, sec 3.3.1.  The "generic-schedule-params" Grouping

   +-- time-zone-identifier?   sys:timezone-name
   +-- validity?   yang:date-and-time
   +-- max-allowed-start?  yang:date-and-time
   +-- min-allowed-start?  yang:date-and-time
   +-- max-allowed-end?yang:date-and-time

Quite a few of the definitions include both a time-zone-identifier and also 
various leaves using the yang:date-and-time.  I think that the text description 
of these leaves needs to be very explicit regarding what time-offset should be 
used, what valid values are, etc.  E.g., if I say that the time-zone is PST but 
then use data-and-time values at +01:00, then what does that mean?

Possibly, you might want to consider introducing a date-and-time-no-zone type 
to avoid the ambiguity.
Good point, I agree we fail to make it clear. Some usage requirements of this 
parameter have been added in -04 in the section where this parameter is 
defined. For example:
"The "time-zone-identifier" parameter, if provided, specifies the time zone 
reference [RFC7317] of the local date and time values. This parameter MUST be 
specified if any of the date and time values are in the format of local time. 
It MUST NOT be applied to date and time values which are specified in the 
format of UTC or time zone offset to UTC."

Note we did not define a type for date-and-time-no-zone as we still want some 
flexibility here to also allow other formats to be used inside this grouping.
(4) p 14, sec 3.3.6.  The "recurrence-utc-with-date-times" Grouping

 grouping generic-schedule-params:
   ...
 grouping period-of-time:
   ...
 grouping recurrence-basic:
   ...
 grouping recurrence-utc:
   ...
 grouping recurrence-with-time-zone:
   ...
 grouping recurrence-utc-with-date-times:
   +-- recurrence-first
   |  +-- start-time-utc?   yang:date-and-time
   |  +-- duration? uint32
   +-- (recurrence-end)?
   |  +--:(until)
   |  |  +-- utc-until?  yang:date-and-time
   |  +--:(count)
  

[netmod] Re: WG Last Call - A Common YANG Data Model for Scheduling

[maqiufang (A)]

Hi, Adrian,

Thanks a lot for the thorough review, apologize for being late on this response.
The authors have submitted -04 
(https://datatracker.ietf.org/doc/html/draft-ietf-netmod-schedule-yang-04, diff 
is available at 
https://author-tools.ietf.org/iddiff?url2=draft-ietf-netmod-schedule-yang-04) 
to address your comments, please also see my reply below inline.

From: Adrian Farrel [mailto:adr...@olddog.co.uk]
Sent: Sunday, January 26, 2025 6:12 AM
To: 'James Cumming (Nokia)' ; 
draft-ietf-netmod-schedule-y...@ietf.org
Cc: 'NETMOD WG Chairs' ; netmod@ietf.org
Subject: RE: [netmod] WG Last Call - A Common YANG Data Model for Scheduling

Hi,

Let me start by thanking the authors because I believe this YANG model
will be a useful building block for a number of operational features
that rely on the ability to schedule functions within the network.

I'd like to see this document progress through WGLC, but I did find a
lot of (relatively small) comments during my review. I'm sorry, but I
did not check my comments for duplication of Reshad's review.
No worries. I actually did not see any duplication;-)
I did not review the examples, but congratulations on not having any
wrapping lines!

Cheers,
Adrian

= Comments =

I note some tension between "scheduling" which is a planning process,
and "reporting" which makes a statement about what has happened in the
past.

The document sems to mainly live up to its title (i.e., scheduling), but
I find text such as (in A.9):

   At the time of 12:15 PM, 2025-12-01 (UTC), the recurring event
   occurred at (note that occurrence at 10:20 AM is excluded): 9:00,
   9:20, 9:40, 10:00, 10:40, 11:00, 11:20, 11:40, 12:00.  The last
   occurrence was at 12:00, the upcoming one is at 12:20.

It seems a very small step from reporting what scheduled things happened
to reporting what unscheduled things happened. I'm not sure that there
is anything to be done here, but it is possible that the Abstract and
Introduction need to call out more specifically the fact that the module
can also report what has happened as well as what is to happen.
Make sense to me. The Abstract and Introduction have included the following 
sentence:
"It also defines groupings for validating requested schedules and reporting 
scheduling status."
---

The Abstract says that the granularity levels vary from basic to
advanced. Is that true? Or is it, as stated in 3.1, the representation
of the recurrence rule that varies from basic to advanced?
The authors have made the following update:
OLD: For the sake of better modularity, the module includes a set of recurrence 
related groupings with varying granularity levels (i.e., from basic to 
advanced).
NEW: For the sake of better modularity, the module includes a set of recurrence 
related groupings with varying levels of representation (i.e., from basic to 
advanced) to accommodate a variety of requirements.
Feel free to propose text if you prefer.
---

Introduction has:

   Section 5 discusses relationship with the managed objects defined in
   [RFC3231].

Very good, but a little hint would be helpful. Such as:

   Section 5 discusses the relationship with the Management Information
   Base (MIB) managed objects for scheduling management operations
   defined in [RFC3231].
Fixed.
---

Instead of Section 3 being called "Groupings" it might be more helpfully
named "Scheduling Groupings".

Similarly, Appendix A might be better as "Examples of Scheduling Format
Representation"
Fixed.
---

I hate that 5545 used "SECONDLY" and "MINUTELY". It makes me twitch
every time I read them. But you are right to use the terms defined
there. I do wonder whether using upper case, as in 5545, might make the
normal reader less ill.
Sure, we use the upper case as value in the normative text, but also add the 
note that frequency values defined as identities in the YANG module are used in 
lowercase.
Note that in 3.2 you use "per second, per minute, etc.". Perhaps this
should be "secondly, minutely, etc.".
Fixed.
---

3.1 says:

   Refer to Section 3.4 for the use of these features.

But I think these features are discussed in subsections of 3.3.  It's
true that 3.4 is on "Feature Use" but it only contains 8 lines of text.
Features are related to the groupings defined in sec3.3. fixed as:
Refer to Sections 3.4 and B.1 for the use of these features.
---

I think maybe re-order "frequency-type" and  "schedule-type" because
frequency is only relevant for recurring schedules.

This could also apply in the module, itself.
That's fair. Fixed.
---

As I understand "schedule-state" it is used to read the current state
of a schedule, but also to control it. I really think you should not
overload and confuse this. Just as we would have done in SMI, you should
have two objects: intended-schedule-state and current-schedule-state.
I am less sure about this. By leveraging NMDA, the device could define 
 to hold configuration that the system attempts to apply, and also 
 to hold the configuration that i

[netmod] Re: Yangdoctors last call review of draft-ietf-netmod-schedule-yang-03

[maqiufang (A)]

Hi, Reshad,



Thanks a lot for the comments, the authors has made some updates which is 
available at: 
https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-netmod-schedule-yang&url_2=https://netmod-wg.github.io/schedule-yang/draft-ietf-netmod-schedule-yang.txt,
 feel free to share your feedback. Please also see my reply below inline with 
[Qiufang].



-Original Message-
From: Reshad Rahman via Datatracker [mailto:nore...@ietf.org]
Sent: Wednesday, January 22, 2025 7:02 AM
To: yang-doct...@ietf.org
Cc: draft-ietf-netmod-schedule-yang@ietf.org; netmod@ietf.org
Subject: Yangdoctors last call review of draft-ietf-netmod-schedule-yang-03



Reviewer: Reshad Rahman

Review result: Ready with Issues



Thanks for addressing my review comments which were discussed at

https://mailarchive.ietf.org/arch/msg/netmod/AO7wvBa0gJbC-Egt_UuZHKCML70



I believe there are a couple of issues remaining, however it should be easy to 
address/close them.



Issues



==



For "leaf interval", the description mentions a default value but there is no 
default statement.

[Qiufang] Right, but this is intentional. The authors had some discussion 
related to the default statement in the grouping, and we incline not to impact 
how the groupings would be reused, and give the consumers choice of deciding 
whether this should be a default or mandatory. For more context, you may find 
some internal discussion at https://github.com/netmod-wg/schedule-yang/pull/8. 
Make sense?



I believe we need more mandatory statements, or default statement if 
appropriate, otherwise the behaviour is unknown. For example:

[Qiufang] See my comment above, as the intention is to try not to define 
mandatory/default statements in the groupings, we would like to add more 
description to clarify cases where the node is unspecified.



- In "container recurrence-first", should "start-time-utc" and "duration" be 
mandatory?

[Qiufang] No, they are allowed to be unspecified. The following changes are 
made to the description statement of container "recurrence-first":

OLD:

   description

"Specifies the first instance of the recurrence."

NEW:

 description

"Specifies the first instance of the recurrence. If

 unspecified, the recurrence is considered to start from the

 date and time when the recurrence pattern is first

 satisfied.";



- In "choice period-type", if no choice is made does that mean there is no end 
to the period? If so, please add that to the description. If not, add a 
mandatory statement.

[Qiufang] Sure, the following changes are made to the description:

OLD:

description

"Indicates the type of the time period. Two types are

 supported."

NEW:

description

"Indicates the type of the time period. Two types are

 supported. If no choice is indicated, the period is

 considered to last forever or as a one-shot schedule.";



Nit: the term "recurrence rule" is used a lot in the document, but it is not 
explained anywhere. In the terminology section, add a reference to 3.8.5.3 of 
RFC5545?

[Qiufang] Good suggestion. The following is defined in the terminology section:

Recurrence Rule:

Refers to a rule or repeating pattern for recurring events. See also Section 
3.8.5.3 of [RFC5545] for a comprehensive iCalendar recurrence rule 
specification.



Regards,

Reshad.



Best Regards,

Qiufang


___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org

[netmod] Re: I-D Action: draft-ietf-netmod-rfc8407bis-22.txt

[maqiufang (A)]

Hi, Kent,


I raised the similar comment in the shepherd review, Med enlightened me that it 
is not an error to have a normative reference to RFC 8792, as it is listed in 
the Downref registry (https://datatracker.ietf.org/doc/downref). Perhaps I 
should update the write-up to reflect this explicitly (I will do that). Other 
warnings/comments are either innocuous or intentional, But I will let Med to 
reconfirm this as well.

Best Regards,
Qiufang
From: Kent Watsen [mailto:kent+i...@watsen.net]
Sent: Tuesday, January 21, 2025 7:00 AM
To: Med Boucadair ; maqiufang (A) 

Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc8407bis-22.txt

Hi Med,

ID-NITs reports:

Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 5 comments (—).

The error must be fixed.  Please looks at the rest as well.


Hi Qiufang (as Shepherd)

Can you update the write-up question #14 to reflect the fix when it comes out?




Kent and Lou




On Jan 14, 2025, at 11:53 AM, 
mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> wrote:

Hi all,

Given a comment raised by Kent, updated the commentary text in the sec template 
to avoid citing a specific regional law + split a long sentence. This revision 
also update the RPC part to also cite action per a comment received from Rob.

Hope this version is ready to be handed to the IESG.

Cheers,
Med


-Message d'origine-
De : internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> 
mailto:internet-dra...@ietf.org>>
Envoyé : mardi 14 janvier 2025 17:35
À : i-d-annou...@ietf.org<mailto:i-d-annou...@ietf.org>
Cc : netmod@ietf.org<mailto:netmod@ietf.org>
Objet : [netmod] I-D Action: draft-ietf-netmod-rfc8407bis-22.txt


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

  Title:   Guidelines for Authors and Reviewers of Documents
Containing YANG Data Models
  Authors: Andy Bierman
   Mohamed Boucadair
   Qin Wu
  Name:draft-ietf-netmod-rfc8407bis-22.txt
  Pages:   93
  Dates:   2025-01-14

Abstract:

  This memo provides guidelines for authors and reviewers of
  specifications containing YANG modules, including IANA-
maintained
  modules.  Recommendations and procedures are defined, which
are
  intended to increase interoperability and usability of Network
  Configuration Protocol (NETCONF) and RESTCONF protocol
  implementations that utilize YANG modules.  This document
obsoletes
  RFC 8407.

  Also, this document updates RFC 8126 by providing additional
  guidelines for writing the IANA considerations for RFCs that
specify
  IANA-maintained modules.  The document also updates RFC 6020
by
  clarifying how modules and their revisions are handled by
IANA.

The IETF datatracker status page for this Internet-Draft is:
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%252>
Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-netmod-
rfc8407bis%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C7e6
59b4cb6414b99322808dd34ba00f7%7C90c7a20af34b40bfbc48b9253b6f5d20%
7C0%7C0%7C638724695700955574%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1h
cGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsI
ldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2FnU5ZheLsMz1%2FuO7JTqL%2B7Bi
xXBEEiGqXouS0505T2w%3D&reserved=0

There is also an HTML version available at:
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%252>
Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-netmod-rfc8407bis-
22.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C7e659b4cb
6414b99322808dd34ba00f7%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C
0%7C638724695700973089%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn
RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjo
yfQ%3D%3D%7C0%7C%7C%7C&sdata=0dE%2F6EQyr5Logd5dTBrOdDo79KgZRHHH0v
IG4km6euA%3D&reserved=0

A diff from the previous version is available at:
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%252>
Fauthor-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-netmod-
rfc8407bis-
22&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C7e659b4cb6414b
99322808dd34ba00f7%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6
38724695700982004%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWU
sIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3
D%3D%7C0%7C%7C%7C&sdata=vYCcGp5H2Bv3n0%2BZI3oBVXiXWAdbVZVXeLgdHgV
GglE%3D&reserved=0

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


___
netmod mailing list -- netmod@ietf.org<mailto:netmod@ietf.org>
To unsubscribe send an email to 
netmod-le...@ietf.org<mailto:netmod-le...@ietf.org>

[netmod] Re: IPR call prior to WGLC - A Common YANG Data Model for Scheduling

[maqiufang (A)]

Hi, James, all,

No, I'm not aware of any IPR that applies to this draft. Thanks.

Best Regards,
Qiufang
From: James Cumming (Nokia) [mailto:james.cumm...@nokia.com]
Sent: Monday, January 6, 2025 10:12 PM
To: maqiufang (A) ; Qin Wu ; 
mohamed.boucad...@orange.com; d.k...@lancaster.ac.uk
Cc: netmod@ietf.org; NETMOD WG Chairs 
Subject: IPR call prior to WGLC - A Common YANG Data Model for Scheduling

Authors, Contributors, WG,

As a prerequisite for the WGLC on this document:

A Common YANG Data Model for Scheduling
https://datatracker.ietf.org/doc/draft-ietf-netmod-schedule-yang/03/

Are you aware of any IPR that applies to draft identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate.

If you are listed as a document author or contributor please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author.

Also please send the response to the list above, and not unicast it.

FWIW, currently, no IPR is filed for this draft:  
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-netmod-schedule-yang

Thanks.

James  (Shepherd for this document)
___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org

[netmod] Re: 2nd WGLC on system-config-10

[maqiufang (A)]

Hi, Rob,

Thanks for the valuable comments, all good points. I've produced a new revision 
to incorporate your inputs, and the diff is available at:
https://author-tools.ietf.org/diff?url_1=https://raw.githubusercontent.com/QiufangMa/system-config/refs/heads/main/draft-ietf-netmod-system-config-11.txt

Please also see inline...
From: Rob Wilton (rwilton) [mailto:rwilton=40cisco@dmarc.ietf.org]
Sent: Tuesday, December 17, 2024 1:49 AM
To: Kent Watsen ; netmod@ietf.org
Subject: [netmod] Re: 2nd WGLC on system-config-10

Hi all,

I've reviewed this document.  Overall, I think that this document is pretty 
close, and it has significantly improved (and been simplified) during the WG 
process.  There are still a couple of issues that I would like to see addressed 
- in particular, that the default of the "system" origin should always mean 
"system configuration" (which can be overridden by running, but not the other 
way around).
Suppose there is no other objections from the WG, I've made the update that 
follows the way you suggested.

(2) p 3, sec 1.1.  Terminology

   system configuration:  Configuration that is provided by the system
  itself.  System configuration is present in the system
  configuration datastore (regardless of whether it is applied or
  referenced).  It is a different and separate concept from factory
  default configuration defined in [RFC8808] (which represents a
  preset initial configuration that is used to initialize the
  configuration of a server).  System configuration may also be
  referred to as "system-defined configuration" or "system-provided
  configuration" throughout this document.

Note that RFC 8342 already defines "system configuration".  Hence you probably 
should be explicit that this document expands on the definition of "system 
configuration" from RFC 8342.

I don't think that you need the third sentence at all, and I would delete it, 
i.e., I would delete the "It is different ..." sentence.  Otherwise, there are 
other datastores that system also is not, and should not be confused with, 
e.g., running, intended, operational, ...
Sure. Please review the proposed new definition:
system configuration:
RFC 
8342
 defines it as "Configuration that is supplied by the device itself." The 
current definition expands on the definition from 
[RFC8342]
 that system configuration is present in the system configuration datastore 
(regardless of whether it is applied or referenced). It may also be referred to 
as "system-defined configuration" or "system-provided configuration" throughout 
this document.

(3) p 4, sec 1.3.  Updates to RFC 8342

   This document also updates the definition of "intended" origin
   metadata annotation identity defined in Section 5.3.4 of [RFC8342].
   The "intended" identity of origin value defined in [RFC8342]
   represents the origin of configuration provided by , this
   document updates its definition as the origin source of configuration
   explicitly provided by clients, and allows a subset of configuration
   in  that flows from  yet is not configured or
   overridden explicitly in  to use "system" as its origin
   value.

I think that there should be a statement that all data nodes in operational 
that are annotated with an origin "system" MUST appear in the system datastore. 
 I.e., I explicitly do not want the "system" origin to identify two different 
types of data nodes, with only a subset of them appearing in the  
datastore.
The following statement has been added as the last sentence:
Note all configuration nodes in  with origin "system" MUST 
originate from .

(4) p 4, sec 2.1.  Immediately-Present

   Immediately-present refers to system configuration which is generated
   in  when the device is powered on, irrespective of physical
   resource present or not, a special functionality enabled or not.  An
   example of immediately-present system configuration is an always-
   existing loopback interface.

I think that "always-present" is a better and simpler name than 
"immediately-present".
Agree! Fixed with "always-present".

(5) p 8, sec 5.2.  No Impact to 

   This work has no impact to .  Notably, it does not
   define any new origin identity as it is able to use the existing
   "system" identity defined in Section 5.3.4 of [RFC8342].  This
   document does not assert that all configuration nodes in
with origin "system" originate from ,
   especially in cases where it is ambiguous which origin should be
   used.

As per my previous comment in (3), I strongly disagree with this part of the 
paragraph.  I think that the there should only be one meaning of system 
configuration and the syste

[netmod] Re: 3rd WGLC on system-config-10 (was "2nd")

[maqiufang (A)]

Hi, Rob,

Thanks for getting back to me, please see below inline...

My concern is related to the statement in RFC 8342:  MUST always be a 
valid configuration data tree.
If a client references an interface eth0 in  which is afterwards 
physically removed and thus disappears from , we end up with dangling 
reference in .

This one is a bit more concerning.  RFC 8342's answer to this problem was for 
the client to put the referenced interface into  so that regardless of 
whether the interface is present in the hardware or not, the configuration is 
valid.  But I think for that solution to really be robust the client needs to 
also configure the interface type, or the system needs to be able to infer what 
the interface type is, since the when statements for other configuration is 
predicated on that interface type.

But there seems to be four choices here:
(1)   Don't allow the forward reference into  in the first place, i.e., 
require the interface (and perhaps interface type) to always be in .  
I.e., as per RFC 8342.
(2)   Modify the running configuration if the hardware is removed.  E.g., 
remove the configuration that is referencing, or inject the referenced system 
configuration.
(3)   Allow the configuration to become invalid.
(4)   Keep interfaces in system, even for removed hardware, if that interface 
is referenced by any running configuration.  This is arguably similar to 2,but 
avoids actually modifying running.  My assumption is that the interface would 
still be removed from operational because it can no longer be instantiated.
[Qiufang] I prefer your solution #2, solution #3 seems require the NMDA-bis 
work. Maybe declare it as out-of-scope is good enough? Setting require-instance 
to false may resolve this as well, and perhaps a best solution since you rely 
on some configuration that is dynamic with less control of clients. But I do 
understand we cannot expect this for all YANG designers.


Similarly, If the upgrade/downgrade happens before keeping the configuration 
consistent, the invalidity of configuration between t1 (the upgrade/downgrade) 
and t2 (the first operation to make configuration consistent) seems also a 
violation of that statement.

This one worries me less.  Ultimately if the previous configuration is no 
longer valid with the new version of software then the configuration has to be 
changed, or the software change prevented (or reversed).  Forcing the client to 
create a configuration that MUST be valid both in the old and new configuration 
seems like creating extra work for the client, probably for little benefit.
[Qiufang] Agree this is less concerning. We used to have some similar 
discussion, configuration invalidity caused due to device upgrade/downgrade is 
non-specific to system configuration, there could be simply a mandatory-false 
node become mandatory-true and it fails to appear in  thus causes 
 invalid.

I kind of agree that we should say less rather than more, especially when this 
is beyond the scope of the document. The examples here are used only to 
enlighten some possible solutions, we can remove these, but I am really unsure 
we should relax MUST to SHOULD here.

But if you don't relax the MUST then how to handle the upgrade/downgrade case?  
Regardless of what the RFC states, what do implementations actually do here?  
For the OS that I'm familiar with, I think that we will remove parts of 
configuration from running after the software change, if that configuration is 
no longer valid.
[Qiufang] Yes, I can see your point. How about the following new text:
If system configuration changes,  SHOULD remain accurate and 
consistent with .
However, any mechanism for handling these circumstances is outside the scope of 
this document.

And get rid of the examples in -10, note I avoid using "valid", trying to avoid 
an obvious violation with existing RFCs, and I think if system configuration 
changes, the real intent of clients would be to keep their configuration 
accurate and consistent.

A side comment: I will propose some updates as well to incorporate your other 
comments in a separate email. Thanks a lot.

Best Regards,
Qiufang
___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org

[netmod] Re: 3rd WGLC on system-config-10 (was "2nd")

[maqiufang (A)]

Hi, Rob, Kent,

(6) p 9, sec 6.1.  May Change via Software Upgrades or Resource Changes

   *  Servers reject the operation to change system configuration (e.g.,
  software upgrade fails) and needs the client to update the
  configuration in  as a prerequisite.  Servers are
  RECOMMENDED to include some hints in error responses to help
  clients understand how  should be updated.

I think that the "MUST" is probably too strong, and perhaps would be better as 
"SHOULD".  I think that there are certain actions, e.g., software upgrade where 
systems may struggle to guarantee that  always stays valid, and one 
valid option for handling this is to allow it to become invalid, and then 
require the first edit-config/edit-data operation to get / 
back to being a valid datastore again.

I'm not entirely sure whether we should be providing examples here.  If you do 
provide any examples then I think that you should definitely strip any RFC 2119 
language, but I would probably strip the text about alerting clients or 
returning errors responses.  Since, handling this is out of scope, the less 
that is said the better, IMO.

Juergen that stated that it must not be possible for a change in  to 
invalidate .

For me, I have a slightly looser requirement.  I don't think that the device 
should be modifying and making the configuration invalid on its own.

E.g., for interface entries that are tied to hardware existence, then that 
configuration can become unapplied if the hardware is missing.

If the configuration is changing (or being broken) due to some client 
instructed management operation (e.g., upgrade or downgrade the software), then 
I agree that it is better for the client to warn and encourage the 
configuration to be fixed before the operation is performed, but I'm sure that 
corner cases exist where this simply doesn't happen, or the client may want to 
force the upgrade/downgrade to happen because that is more important than 
keeping the configuration consistent.  In that scenario, I think that the 
pragmatic solution is that the device forces the configuration to become valid 
again on the next write config operation.

Another example would be a license that expires, such that a subset of the 
configuration is no longer valid.  Choices could be:
-  Configuration is left as it is, but the configuration is no longer 
valid, and the configuration becomes unapplied.  Attempts to configure the 
feature without a valid license would be rejected with an error during 
validation.
-  Configuration is automatically removed from running by the device 
(but I don't like this option).  I prefer if the client *always* controls the 
contents of running.
-  Always allow the configuration, even if there is no valid license 
present) but just don't apply it if there isn't a valid license (this seems 
like generally less helpful behaviour to me).

So, in summary, perhaps not as clean as a MUST, but maybe more 
pragmatic/realistic?



And he's right for automations to succeed.  That said, if there a 
human-in-the-loop, it seems possible that the system could offer your idea as 
an option.  Maybe a sentence could be added to say that?

I'm not sure - I'm sort of after less words/examples rather than more ...
For me, I interpret this as:

(1)   SHOULD always stay consistent.
(2)   If, for any reason, it becomes inconsistent then SHOULD* be made 
consistent on the first operation taken.

(*) I was going to write this as MUST, but I know of cases where customers are 
unhappy of systems not letting them shutdown an interface because of an 
another, entirely separate, part of the configuration is not valid.  Hence, I 
think that some systems at least, have a "force" mode to force the 
configuration change to made (perhaps still with some level of constraints).
My concern is related to the statement in RFC 8342:  MUST always be a 
valid configuration data tree.
If a client references an interface eth0 in  which is afterwards 
physically removed and thus disappears from , we end up with dangling 
reference in . Similarly, If the upgrade/downgrade happens before 
keeping the configuration consistent, the invalidity of configuration between 
t1 (the upgrade/downgrade) and t2 (the first operation to make configuration 
consistent) seems also a violation of that statement.

I kind of agree that we should say less rather than more, especially when this 
is beyond the scope of the document. The examples here are used only to 
enlighten some possible solutions, we can remove these, but I am really unsure 
we should relax MUST to SHOULD here.

Regards,
Rob
Best Regards,
Qiufang


___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org

[netmod] Re: I-D Action: draft-ietf-netmod-system-config-10.txt

[maqiufang (A)]

Hi, all,

This version incorporates some recent input from the discussion on the list. 
Thanks.

Best Regards,
Qiufang

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: Friday, December 6, 2024 5:22 PM
To: i-d-annou...@ietf.org
Cc: netmod@ietf.org
Subject: [netmod] I-D Action: draft-ietf-netmod-system-config-10.txt

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

   Title:   System-defined Configuration
   Authors: Qiufang Ma
Qin Wu
Chong Feng
   Name:draft-ietf-netmod-system-config-10.txt
   Pages:   32
   Dates:   2024-12-06

Abstract:

   The Network Management Datastore Architecture (NMDA) in RFC 8342
   defines several configuration datastores holding configuration.  The
   contents of these configuration datastores are controlled by clients.
   This document introduces the concept of system configuration
   datastore holding configuration controlled by the system on which a
   server is running.  The system configuration can be referenced (e.g.,
   leafref) by configuration explicitly created by clients.

   This document updates RFC 8342.

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

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-system-config-10

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

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


___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org
___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org

[netmod] Re: origin "system" in system-config-09

[maqiufang (A)]

Hi, Andy,

From: Andy Bierman [mailto:a...@yumaworks.com]
Sent: Monday, December 2, 2024 3:59 AM
To: Kent Watsen 
Cc: netmod@ietf.org
Subject: [netmod] Re: origin "system" in system-config-09



On Sun, Dec 1, 2024 at 11:34 AM Kent Watsen 
mailto:kent%2bi...@watsen.net>> wrote:

> I do not understand how  references .
> How does a config leafref in  validate correctly unless the 
> pointed-at leaf is also in ?
> The same issue applies to templates if the incomplete list entry in  
> has any pointed-at leafs.

This statement assumes that  is subject to validation.

 +  = 


Seems like some fundamental changes to NMDA., but maybe not, since now

 + proprietary-magic = .

My concern is for offline validation.
RFC 7950 and 8342 both say  MUST be valid.

There is a desire for a client to
  (1) retrieve a representation of the entire  datastore and
  (2) perform the YANG validation tests on the retrieved data
If  contains configuration that requires further transformation (cases 
defined in NMDA) and the client has the awareness that  alone is not 
valid (e.g., because the template needs expansion to populate the mandatory 
fields), the client then understands the magic must be done on its side before 
the YANG validation can be performed. That is also the reason I understand why 
Kent is proposing the standardization of configuration templates and inactive 
nodes.

Similarly, the client can offline merge  and  and validate the 
merging results if it has the knowledge that  alone contains dangling 
references to system config.

This won’t break legacy clients which still rely on the offline validation of 
 alone, as it’s only applicable to NMDA clients that has such an 
awareness.

There is no problem on the server because the  datastore is valid
if the server says so (e.g. return  for edit-config or validate operations).


Kent // contributor
Andy
Best Regards,
Qiufang


___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org

[netmod] Re: origin "system" in system-config-09

[maqiufang (A)]

Hi, Jürgen,



Although RFC 8342 avoids it, the problem remains in the real world:

The client has the desire to reference system defined nodes, Must the 
referenced system configuration always be copied to ?  Does the entire 
system-generated list entry need to be copied, or it is just the list with at 
least the key? What if the system configuration changes and a stale copy ends 
up in ?

How does the client overwrite a system-provided value? Or how to configure the 
descendant nodes of system configuration? Is the copy needed?



Some system configurations are defined solely as a convenience (e.g., some 
system provided policies), one of the objectives is to avoid re-creating system 
configuration in .

I think the current design makes the interplay between system configuration and 
client-provided configuration clear (e.g., allows  references system 
config without requiring it to be copied into ).



Best Regards,

Qiufang



-Original Message-
From: Jürgen Schönwälder [mailto:jschoenwaelder@constructor.university]
Sent: Monday, December 2, 2024 5:22 PM
To: Kent Watsen 
Cc: maqiufang (A) ; Jason Sterne 
; netmod@ietf.org
Subject: Re: [netmod] origin "system" in system-config-09



On Sun, Dec 01, 2024 at 06:25:34PM +, Kent Watsen wrote:

>

> > Another option that comes to mind is that the system datastore does

> > not feed into anything. Instead, it just exposes the (current)

> > system configuration and if someone wants to use it, that someone

> > can copy it into running and then takes responsibility for it.

>

> I do not favor this because it leads to stale definitions.

>



How can something that is not feeding into anything lead to stale definitions?



The argument was that the system may change and such a change my cause 
 to become invalid if  is merged into .

This was the reason why  in RFC 8342 is _not_ feeding into . 
Hence, I proposed that if people want to expose system, they do it in a way 
such that  is accessible but not automatically used. To use it, 
"something" taking over responsiblity has to make definitions explicit config 
in .



/js



--

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
To unsubscribe send an email to netmod-le...@ietf.org

[netmod] Re: origin "system" in system-config-09

[maqiufang (A)]

Hi, Juergen,



I agree that if system configuration changes, any reference to it might cause 
 to become invalid. As Kent suggested, how about we add some 
following text in section 6.1 to clarify:

Server MUST ensure that any updates of  do not render  
invalid. However, any mechanism for handling these circumstances is outside the 
scope of this document.



Or even go one step further, although out of scope, we can gives some examples 
to show how to ensure  remains valid:

· Servers internally marked any invalid configuration in  
caused due to  changes as “inactive”

· Servers migrate system configuration update in , e.g., by 
updating configuration data that references stale system nodes

· What else?



Thoughts?



Best Regards,

Qiufang



-Original Message-
From: Jürgen Schönwälder [mailto:jschoenwaelder@constructor.university]
Sent: Friday, November 22, 2024 6:06 AM
To: Jason Sterne (Nokia) 
Cc: Kent Watsen ; maqiufang (A) ; 
netmod@ietf.org
Subject: Re: [netmod] origin "system" in system-config-09



On Thu, Nov 21, 2024 at 08:20:18PM +, Jason Sterne (Nokia) wrote:

> I don't think we can just say to get rid of leafrefs and use name bindings 
> instead (or require-instance false). In many situations, the "built in" 
> system objects were talking about in the draft are in a list that can also 
> contain user-configured entries, and it is useful in many data models to have 
> hard leafrefs (require instance true) to those entries (e.g. avoid misconfig 
> with dangling references).

>



But when the referenced leaf disappears since it is controlled by the system, 
you do what? Accept invalid config? Reboot? Send an SMS to tell a human network 
operator to please put the linecard back or to ask the finance department to 
extend the software license that just expired?



/js



--

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
To unsubscribe send an email to netmod-le...@ietf.org

[netmod] Re: origin "system" in system-config-09

[maqiufang (A)]

Hi, Kent, Jason,

Please see inline.

From: Kent Watsen [mailto:kent+i...@watsen.net]
Sent: Friday, November 22, 2024 5:27 AM
To: Jason Sterne (Nokia) 
Cc: Jürgen Schönwälder ; netmod@ietf.org
Subject: [netmod] Re: origin "system" in system-config-09

Hi Jason,

[>>JTS:] It may indeed be OK to consider origin identities as not necessarily 
tied to a DS, but 8342 does say this:
intended: represents configuration provided by 
So I’m not sure if having some config that shows up in  can then show 
up in  with an origin besides or:intended without considering that 
an update (change) to 8342?

Fair.  We didn’t consider the possibility of a  datastore when RFC8342. 
 In that case, I recommend this draft *update* RFC8342 to clarify that.  Agreed?

The definition of “or: intended” is updated in Section 
1.3
 as configuration provided by . If it is not going to tie the origin 
value to any datastore, maybe we can fix this as configuration explicitly 
provided by clients. The latter seems better to me, but please feel free to 
suggest.

As long as:
1.  We’re ok that some data (i.e. from the  DS) that appears in 
 doesn’t need to have origin or:intended in , and
2.  We don’t really feel it is important to differentiate the origin of 
data that came from the  DS from data that comes from “the system” 
(running code, items added by the system but not present in the  DS
3.  We agree that not all data in  with origin or:system must 
also be present in the  DS
then we can just use or:system and not have any new sys:system identity.

Sounds right to me.


RFC8342 shows “system  configuration” merging *after* intended. In that case it 
is a little easier to see how the origin would be or:system.

But even if we put that issue aside (and just allow some config in  
to have origin = or:system when it comes from the  DS), I’m not certain 
I agree that all elements that appear in the  DS with origin = 
or:system must necessarily also show up in the  DS.

It is not expected that 100% of the "or:system” nodes in  will be 
in .  [>>JTS:] I think we should put this sentence right in the draft.

That sounds like a useful clarification.
I will update the draft and add this sentence. I learned the case Jason 
provided below, which I tend to agree, but I do not like to impose restrictions 
on the scenarios in which the system configuration should or should not be 
present in , I would treat its contents as implementation-specific. 
Even though some may think system configuration that is not constantly changing 
are suitable for , because otherwise it might end up with validity of 
config that references  depending on certain resources or operational 
state. But there may be other cases where  is just there for visibility.
Maybe admitting that not all “or: system” configuration in  are 
from  and allowing that flexibility are good enough.

Best Regards,
Qiufang

That sets the bar unrealistically high.  I assume that  will be both 
incomplete and sometimes not exact (like in your ‘pir' example below).  The 
real system (running code) will always have the final say, regardless what is 
in  datastore.




For built-in referenceable list entries (e.g. qos polices, system interface) I 
can see how they are 1:1 between the  DS and or:system in the 
 DS.

But I’m less certain that we’ve considered all potential types of elements or 
scenarios where reading something from the  DS can return 
or:system. For example:
· User configures pir = 1022   (e.g. some QoS policing parameter)
· Server accepts pir = 1022, but rounds/maps it to a value that is 
actually supported on that particular hardware platform, so the system is 
actually using pir = 1024
· Reading  should return pir = 1024, but could the origin 
be or:system in this case?
· I think it would be odd for pir to suddenly show up in the  
DS in this situation (and I don’t think we should mandate that)

Agreed, that would be weird.[>>JTS:] Glad we’re on the same page on that. I may 
also be incorrect that the origin in this case is supposed to be or:system but 
it isn’t obvious to me what else to use. Or:intended isn’t quite right although 
maybe it could also be “good enough” since the source of the value is from user 
configuration (even if we didn’t use the exact value).

I admit that I also struggle with some of the origin identities.  Sometimes I 
feel that we made it too complicated.  Maybe there should've been only two 
identities “intended” and “system”.  For instance, one could argue that a 
client not setting a value to allow a “default” value to be used is 
intentional.  Similarly, it seems that anything that comes from a “dynamic" 
datastore is also intentional, and anything that is *learned* is from the 
system...

Should we start an NMDA-next tracker...

Kent // contributor


___
netmod mailing list -- netmo

[netmod] Re: Mandatory/default statements and templates (was: Yang Template Proposals)

[maqiufang (A)]

Hi, Shiya,

Please see my reply inline.

From: Shiya Ashraf (Nokia) [mailto:shiya.ashraf=40nokia@dmarc.ietf.org]
Sent: Thursday, November 14, 2024 9:02 AM
To: Kent Watsen 
Cc: netmod@ietf.org
Subject: [netmod] Re: Mandatory/default statements and templates (was: Yang 
Template Proposals)


Thanks Kent, Andy for your responses and the interesting discussion.
Its getting very late here, so I will have to stop with this email for today. 😉

RFC 8342 says in section 5.1.3 for running DS
  “ It MAY include configuration that requires further transformation before it
   can be applied, e.g., inactive configuration, or template-mechanism-
   oriented configuration that needs further expansion. “

And in section 5.1.4 for intended DS
“It represents the configuration after all
   configuration transformations to  are performed (e.g.,
   template expansion, removal of inactive configuration) and is the
   configuration that the system attempts to apply.
“

 For me, these two explicit statements about templates gave me an 
understanding that  stores the unexpanded data while  stores 
the expanded.
[Qiufang] Yes, that’s my understanding as well. And I believe that’s also the 
intention of authors after extensively discussion on the list.
And if the RFC is open on storing either the unexpanded or expanded one in 
, there must have been a capability defined to expose how the server 
actually stores these data (transformed or not) isn’t it? Otherwise, how will 
the client know what response he get for a get-config response, isn’t this 
important? Also if some one need to fetch the un expanded data from the device, 
shouldn’t there already be a way defined for this as well?
[Qiufang] I don’t think the RFC is open on storing either the unexpanded or 
expanded one in , RFC 8342 is clear on this point. Maybe you are 
referring to non-NMDA? I guess that is because config template has never been 
standardized in IETF. If we are going to work on this, I think this is 
something we need to make it clear.
Also, as I noted earlier, memory gain is a major motivation for using templates 
(especially in Fiber network devices).
[Qiufang] Maybe, but it always needs to be expanded in the datastore (e.g., 
). I also think other motiviations like configuration reuse and 
consistency assurance to reduce errors and misconfigurations.
I hope this expansion of templates in running DS doesn’t mean we loose such 
gains.
[Qiufang] If it is expanded in  (which I hope not), I assume  
needs the same memory space as not using the template. But still, use of 
templates simplifies the configuration delivery.
Thanks,
Shiya

Best Regards,
Qiufang
From: Kent Watsen mailto:kent+i...@watsen.net>>
Sent: Thursday, November 14, 2024 1:05 AM
To: Shiya Ashraf (Nokia) mailto:shiya.ash...@nokia.com>>
Cc: netmod@ietf.org
Subject: Re: [netmod] Mandatory/default statements and templates (was: Yang 
Template Proposals)



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.



Hi Shiya,

Where does it say  contains only data provided by the client in 
 operations?
(Nowhere)

To put a finer point on this, it is a long-standing desire that changes to 
 happen only with the client’s knowledge.  That said,  could 
contain config that was *generated* due to a client-instruction.  For instance, 
the “resolve-system” flag that was recently removed from the “system-config” 
draft or, in Yuma’s case, an instruction that causes a template-expansion to 
occur at time of the .

Kent // contributor

___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org

[netmod] Re: Mandatory/default statements and templates (was: Yang Template Proposals)

[maqiufang (A)]

Hi, Andy, all,

While I agree that the client should have complete control over , and 
the read back of  should return exactly what was sent by the client 
(we’ve discussed this a lot in the system-config thread), I also understand 
there are some proprietary implementations that would evolve configuration in 
 beyond client initialization. I prefer to consider  in this 
situation as a “intended-like” datastore (it is , but quite like 
 in the design of NMDA).

In any case, I think the template solution should be able to return 
configuration with both unexpanded and expanded views of templates. An 
unexpanded view, without any transformations, can be useful for the client to 
check which nodes has applied which configuration templates, and it may further 
decide how they want to modify the current application or delete/override some 
nodes provided by the template, and maybe also useful for a simple and 
consistent view of configuration. An expanded view is needed for configuration 
transformation and validity check. This seems easy to achieve in NMDA (i.e., 
RFC8342 already states that template is unexpanded in  and expanded in 
),  but I am unsure whether we need to work out a solution for 
non-NMDA as well.

Best Regards,
Qiufang
From: Andy Bierman [mailto:a...@yumaworks.com]
Sent: Thursday, November 14, 2024 9:16 AM
To: Kent Watsen 
Cc: Shiya Ashraf (Nokia) ; netmod@ietf.org
Subject: [netmod] Re: Mandatory/default statements and templates (was: Yang 
Template Proposals)



On Wed, Nov 13, 2024 at 4:05 PM Kent Watsen 
mailto:kent%2bi...@watsen.net>> wrote:
Hi Shiya,


Where does it say  contains only data provided by the client in 
 operations?
(Nowhere)

To put a finer point on this, it is a long-standing desire that changes to 
 happen only with the client’s knowledge.  That said,  could 
contain config that was *generated* due to a client-instruction.  For instance, 
the “resolve-system” flag that was recently removed from the “system-config” 
draft or, in Yuma’s case, an instruction that causes a template-expansion to 
occur at time of the .


RFC 4741 was way before YANG existed.
Even in RFC 6241, the WG was careful about leaving the datastore details
to the implementation.  The metadata in the edit-config operation are
processing instructions.  They do not get added to the datastore.
The template or loop instructions are no different.

I do not agree with your strict interpretation of client-initiated.
A client may set a CLI parameter or otherwise direct the server to use some 
feature or behavior.
In this template case all the data is client-provided, but even when system 
data is provided,
it is due to the configuration settings from the operator.


Kent // contributor



Andy

___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to 
netmod-le...@ietf.org
___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org

[netmod] Re: origin "system" in system-config-09

[maqiufang (A)]

The document tries to update the definition of or:intended in NMDA, you may 
want to refer to the last paragraph of section 1.3 
(https://datatracker.ietf.org/doc/html/draft-ietf-netmod-system-config-09#section-1.3),
 which says:
"This document also updates the definition of "intended" origin metadata 
annotation identity defined in Section 5.3.4 of [RFC8342]. The "intended" 
identity of origin value defined in [RFC8342] represents the origin of 
configuration provided by , this document updates its definition as 
the origin source of configuration explicitly provided by , and allows 
a subset of configuration in  that flows from  yet is not 
configured or overridden explicitly in  to use "system" as its origin 
value."

Best Regards,
Qiufang

-Original Message-
From: Jürgen Schönwälder  
Sent: Friday, November 8, 2024 10:23 PM
To: maqiufang (A) 
Cc: Jason Sterne ; Kent Watsen ; 
netmod@ietf.org
Subject: Re: [netmod] Re: origin "system" in system-config-09

This then likely makes sense but if system is merged into intended, then values 
should have or:intended, no?

/js

On Fri, Nov 08, 2024 at 01:42:45PM +, maqiufang (A) wrote:
> Hi, Jürgen,
> 
> It is, but the identity defined in the I-D is only derived from 
> ds:conventional. To use sysds:system as the origin value, I think it needs to 
> be derived from or:origin, which I am unsure if possible, since the identical 
> identity (i.e., system derived from origin) is already defined in RFC8342.
> 
> Best Regards,
> Qiufang
> 
> -Original Message-
> From: Jürgen Schönwälder 
> Sent: Friday, November 8, 2024 8:10 PM
> To: maqiufang (A) 
> Cc: Jason Sterne ; Kent Watsen 
> ; netmod@ietf.org
> Subject: Re: [netmod] Re: origin "system" in system-config-09
> 
> On Fri, Nov 08, 2024 at 12:08:05PM +, maqiufang (A) wrote:
> > Hi, Jason, all,
> > 
> > I think all system configuration that is non-deletable should be defined in 
> > , if things differ from case to case, I have concern that it is 
> > hard to enumerate all cases. The draft already states that  may 
> > change dynamically. Deletable system configuration should be present in 
> > , otherwise how is it possible for the client to delete it? If it 
> > is in , doesn't it have an origin value "intended"? If we make a 
> > distinction this way, is it safe to infer that all nodes using or:system 
> > are originating from ? Am I missing something?
> > 
> > Jürgen has suggested to use sysds:system to report configuration 
> > originating from , but I am unsure if that is possible to define 
> > another identical identity also derived from "origin" identity?
> 
> It is defined in your ID...
> 
> /js
> 
> -- 
> Jürgen Schönwälder  Constructor University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> 

-- 
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
To unsubscribe send an email to netmod-le...@ietf.org

[netmod] Re: origin "system" in system-config-09

[maqiufang (A)]

Hi, Jürgen,

It is, but the identity defined in the I-D is only derived from 
ds:conventional. To use sysds:system as the origin value, I think it needs to 
be derived from or:origin, which I am unsure if possible, since the identical 
identity (i.e., system derived from origin) is already defined in RFC8342.

Best Regards,
Qiufang

-Original Message-
From: Jürgen Schönwälder  
Sent: Friday, November 8, 2024 8:10 PM
To: maqiufang (A) 
Cc: Jason Sterne ; Kent Watsen ; 
netmod@ietf.org
Subject: Re: [netmod] Re: origin "system" in system-config-09

On Fri, Nov 08, 2024 at 12:08:05PM +, maqiufang (A) wrote:
> Hi, Jason, all,
> 
> I think all system configuration that is non-deletable should be defined in 
> , if things differ from case to case, I have concern that it is hard 
> to enumerate all cases. The draft already states that  may change 
> dynamically. Deletable system configuration should be present in , 
> otherwise how is it possible for the client to delete it? If it is in 
> , doesn't it have an origin value "intended"? If we make a 
> distinction this way, is it safe to infer that all nodes using or:system are 
> originating from ? Am I missing something?
> 
> Jürgen has suggested to use sysds:system to report configuration originating 
> from , but I am unsure if that is possible to define another 
> identical identity also derived from "origin" identity?

It is defined in your ID...

/js

-- 
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
To unsubscribe send an email to netmod-le...@ietf.org

[netmod] Re: origin "system" in system-config-09

[maqiufang (A)]

Hi, Jason, all,

I think all system configuration that is non-deletable should be defined in 
, if things differ from case to case, I have concern that it is hard to 
enumerate all cases. The draft already states that  may change 
dynamically. Deletable system configuration should be present in , 
otherwise how is it possible for the client to delete it? If it is in 
, doesn't it have an origin value "intended"? If we make a distinction 
this way, is it safe to infer that all nodes using or:system are originating 
from ? Am I missing something?

Jürgen has suggested to use sysds:system to report configuration originating 
from , but I am unsure if that is possible to define another identical 
identity also derived from "origin" identity?

Andy raised the case of dynamic default, I think another choice is to report 
dynamic default as origin: default, e.g., the BGP example 
(https://datatracker.ietf.org/doc/html/rfc8342#appendix-C.2.2.1) given in 
RFC8342 also have the origin of local-as and peer-as being reported as or: 
default.

Best Regards,
Qiufang

-Original Message-
From: Jason Sterne (Nokia)  
Sent: Friday, November 8, 2024 4:24 AM
To: Jürgen Schönwälder ; Kent Watsen 

Cc: netmod@ietf.org
Subject: [netmod] Re: origin "system" in system-config-09

One note: we do need to be careful to distinguish system config (in the system 
DS) from factory defaults RFC8088. If that administrator account is deletable 
(and probably is or should be for security reasons) I'd call that factory 
default (not system DS) and it would be visible in .

> -Original Message-
> From: Jürgen Schönwälder 
> Sent: Thursday, November 7, 2024 2:54 PM
> To: Kent Watsen 
> Cc: Jason Sterne (Nokia) ; netmod@ietf.org
> Subject: Re: [netmod] origin "system" in system-config-09
> 
> 
> 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.
> 
> 
> 
> On Thu, Nov 07, 2024 at 02:33:09PM +, Kent Watsen wrote:
> >
> > Indeed.  It might help to think about the use-case that  
> > intends to
> support.  My understanding is that it’s trying to reveal more about 
> what the buried program logic does, so that the network’s functioning 
> can be better understood, e.g., to implement a digital twin.
> >
> 
> I guess I understand the system datastore differently. Perhaps some 
> examples help:
> 
> 1) Consider an interface generating link-local IPv6 addresses. I
>expect that these address has or:system, I do not expect to find
>them in the system datastore.
> 
> 2) Consider a system that has a default administrative user account.
>I expect that this account has sysds:system, I consider this hard
>wired configuration.
> 
> 3) I consider a list of applications or preconfigured ACL rules as
>sysds:system content. This is also the example given in the I-D.
> 
> I do not find where the document says that all system generated 
> applied config should be reflected in sysds:system. This would turn 
> sysds:system into a constantly changing dynamic configuration 
> datastore. And if system is merged into intended, I start wondering 
> whether values would not have or:intended. Or if your model applies, 
> then why would we even need a new identity since we have already 
> or:system?
> 
> /js
> 
> --
> 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
To unsubscribe send an email to netmod-le...@ietf.org
___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org

[netmod] Re: FW: New Version Notification for draft-ietf-netmod-system-config-09.txt

[maqiufang (A)]

Thank you Kent for your feedback, much appreciated. For those who were also 
actively participating in the WGLC discussion, could you please review the 
update and let the authors know if it works for you?


Best Regards,
Qiufang

From: Kent Watsen [mailto:kent+i...@watsen.net]
Sent: Monday, September 30, 2024 8:22 PM
To: maqiufang (A) 
Cc: netmod@ietf.org
Subject: Re: [netmod] FW: New Version Notification for 
draft-ietf-netmod-system-config-09.txt


Hi Qiufang,

Thank you for this update.

I believe this fully addresses the issue raised by Juergen.

I appreciate the simplicity and robustness of this approach.

I hope that NETCONF-next and RESTCONF-next will assert the use of NMDA.

Kent



On Sep 29, 2024, at 10:36 PM, maqiufang (A) 
mailto:maqiufang1=40huawei@dmarc.ietf.org>>
 wrote:


Hi, all,



This version incorporates some WGLC comments. The most notable change is that 
the entire 'copy' requirements, including the definition of the 
'resolve-system' parameter, have been removed from this version (note that this 
still does not prevent clients from copying system data into , but it 
is not necessarily needed now). Instead, the following statement has been added 
in the last paragraph of the introduction section:

" The solution defined in this document requires the use of NMDA for both 
clients and servers. "



This implies that this document can only be used in the context of NMDA and 
thus does not impact legacy clients that rely on the validity of  
alone. If both clients and servers support NMDA and there could be unexpanded 
templates and inactive configuration defined in  as per RFC 8342, 
 could be validated by effectively validating . Therefore no 
need to always copy the referenced system configuration into  with 
 being merged into . Make sense?



Best Regards,

Qiufang



-Original Message-
From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> 
[mailto:internet-dra...@ietf.org]
Sent: Monday, September 30, 2024 10:14 AM
To: Chong Feng mailto:fengchongl...@gmail.com>>; Qin 
Wu mailto:bill...@huawei.com>>; Qin Wu 
mailto:bill...@huawei.com>>; maqiufang (A) 
mailto:maqiufa...@huawei.com>>
Subject: New Version Notification for draft-ietf-netmod-system-config-09.txt



A new version of Internet-Draft draft-ietf-netmod-system-config-09.txt has been 
successfully submitted by Qiufang Ma and posted to the IETF repository.



Name: draft-ietf-netmod-system-config

Revision: 09

Title:System-defined Configuration

Date: 2024-09-29

Group:netmod

Pages:32

URL:  https://www.ietf.org/archive/id/draft-ietf-netmod-system-config-09.txt

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

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

Diff: 
https://author-tools.ietf.org/iddiff?url2=draft-ietf-netmod-system-config-09



Abstract:



   The Network Management Datastore Architecture (NMDA) in RFC 8342

   defines several configuration datastores holding configuration.  The

   contents of these configuration datastores are controlled by clients.

   This document introduces the concept of system configuration

   datastore holding configuration controlled by the system on which a

   server is running.  The system configuration can be referenced (e.g.,

   leafref) by configuration explicitly created by clients.



   This document updates RFC 8342.







The IETF Secretariat




___
netmod mailing list -- netmod@ietf.org<mailto:netmod@ietf.org>
To unsubscribe send an email to 
netmod-le...@ietf.org<mailto:netmod-le...@ietf.org>
___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org

[netmod] Re: shepherd review for draft-ietf-netmod-rfc8407bis

[maqiufang (A)]

Hi, Kent, Med, all,

AFAIK, the “description” statement is never required in RFC 7950, i.e., the 
cardinality is always 0..1.Notably, see how it’s defined for the “anyxml” 
statement: https://datatracker.ietf.org/doc/html/rfc7950#section-7.11.1

You raise a good point about legacy modules.   It might be good for pyang to 
only flag modules with revision dates after this document’s publication date.
Perhaps not a very big issue about legacy modules, e.g., just checked the 
IETF-published modules [1] with anydata definition, there are 8 of them [2], 
and all have the “description” as its substatement, which is not surprising to 
me, you should always provide the detailed description information about an 
unknown set of nodes defined as “anydata”.

[1] https://github.com/YangModels/yang/tree/main/standard/ietf/RFC
[2] 
https://github.com/search?q=repo%3AYangModels%2Fyang%20path%3A%2F%5Estandard%5C%2Fietf%5C%2FRFC%5C%2F%2F%20anydata&type=code

Best Regards,
Qiufang
On Sep 27, 2024, at 10:30 AM, 
mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> wrote:

Re-,

I was concerned more with breaking existing models (I don’t know how many are 
out there with anydata use).

Formally speaking, RFC 7950 does not say that it must be present per the 
following in 7.10.1:

 +--+-+-+
 | substatement | section | cardinality |
 +--+-+-+
 | description  | 7.21.3  | 0..1|

If you still think we need to make the change, I’d like we formally ask for WG 
consensus on the way to proceed here. A 1-week call would be OK. Thanks.

Cheers,
Med

De : Kent Watsen mailto:k...@watsen.net>>
Envoyé : vendredi 27 septembre 2024 16:01
À : BOUCADAIR Mohamed INNOV/NET 
mailto:mohamed.boucad...@orange.com>>; maqiufang 
(A) mailto:maqiufa...@huawei.com>>
Cc : 
draft-ietf-netmod-rfc8407...@ietf.org<mailto:draft-ietf-netmod-rfc8407...@ietf.org>;
 netmod@ietf.org<mailto:netmod@ietf.org>
Objet : Re: [netmod] shepherd review for draft-ietf-netmod-rfc8407bis


Hi Med et. al.,



On Sep 27, 2024, at 5:34 AM, 
mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> wrote:

Section 4.14 specifies a set of YANG statements that MUST have a description 
substatement, but I don’t think anydata should be omitted here. Thoughts?
[Med] This list is inherited from 8407, which in its turn was inherited from 
6087. anydata wasn’t in 6087 because it wasn’t defined at the time in 6020. I 
don’t have the context whether this was considered by the WG in the past, but 
I’m afraid that adding this mandatory will break existing models. For example, 
pyang does not make that check for anydata, while it is in place for anyxml. I 
suggest we leave the list as it is.
That seems like a valid concern for this NBC update, I am okay with keeping 
this as it is, if there is no objections from others.

Wait, `anydata` should have a description (just like `anyxml`).  It clearly 
seems to be an omission from before that should be rectified now.

FWIW, it doesn’t matter what the tools do, or what tools folks use, if any at 
all.  Also, the tools follow the specifications, not the other way around.

I recommend adding `anydata` and filing a ticket on the `pyang` issue tracker.

Kent / contributor




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 may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

Thank you.
___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org

[netmod] FW: New Version Notification for draft-ietf-netmod-system-config-09.txt

[maqiufang (A)]

Hi, all,



This version incorporates some WGLC comments. The most notable change is that 
the entire 'copy' requirements, including the definition of the 
'resolve-system' parameter, have been removed from this version (note that this 
still does not prevent clients from copying system data into , but it 
is not necessarily needed now). Instead, the following statement has been added 
in the last paragraph of the introduction section:

" The solution defined in this document requires the use of NMDA for both 
clients and servers. "



This implies that this document can only be used in the context of NMDA and 
thus does not impact legacy clients that rely on the validity of  
alone. If both clients and servers support NMDA and there could be unexpanded 
templates and inactive configuration defined in  as per RFC 8342, 
 could be validated by effectively validating . Therefore no 
need to always copy the referenced system configuration into  with 
 being merged into . Make sense?



Best Regards,

Qiufang



-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
Sent: Monday, September 30, 2024 10:14 AM
To: Chong Feng ; Qin Wu ; Qin Wu 
; maqiufang (A) 
Subject: New Version Notification for draft-ietf-netmod-system-config-09.txt



A new version of Internet-Draft draft-ietf-netmod-system-config-09.txt has been 
successfully submitted by Qiufang Ma and posted to the IETF repository.



Name: draft-ietf-netmod-system-config

Revision: 09

Title:System-defined Configuration

Date: 2024-09-29

Group:netmod

Pages:32

URL:  https://www.ietf.org/archive/id/draft-ietf-netmod-system-config-09.txt

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

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

Diff: 
https://author-tools.ietf.org/iddiff?url2=draft-ietf-netmod-system-config-09



Abstract:



   The Network Management Datastore Architecture (NMDA) in RFC 8342

   defines several configuration datastores holding configuration.  The

   contents of these configuration datastores are controlled by clients.

   This document introduces the concept of system configuration

   datastore holding configuration controlled by the system on which a

   server is running.  The system configuration can be referenced (e.g.,

   leafref) by configuration explicitly created by clients.



   This document updates RFC 8342.







The IETF Secretariat




___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org

[netmod] FW: I-D Action: draft-ietf-netmod-immutable-flag-02.txt

[maqiufang (A)]

Hi, all,

This version has made some editorial changes from the previous one.  At the 
moment the authors believe this draft doesn't have any open issues, i.e., ready 
for WGLC.

We would also like the WG to take the time to review this draft, would 
appreciate any comments and suggestions. Thanks a lot.

Best Regards,
Qiufang

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: Friday, September 27, 2024 5:08 PM
To: i-d-annou...@ietf.org
Cc: netmod@ietf.org
Subject: [netmod] I-D Action: draft-ietf-netmod-immutable-flag-02.txt

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

   Title:   YANG Metadata Annotation for Immutable Flag
   Authors: Qiufang Ma
Qin Wu
Balazs Lengyel
Hongwei Li
   Name:draft-ietf-netmod-immutable-flag-02.txt
   Pages:   19
   Dates:   2024-09-27

Abstract:

   This document defines a way to formally document an existing
   behavior, implemented by servers in production, on the immutability
   of some system-provided nodes, using a YANG metadata annotation
   called "immutable" to flag which nodes are immutable.

   Clients may use "immutable" annotations provided by the server, to
   know beforehand why certain otherwise valid configuration requests
   will cause the server to return an error.

   The immutable flag is descriptive, documenting an existing behavior,
   not proscriptive, dictating server behaviors.

   This document updates [RFC6241], [RFC8040], and [RFC8526].

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

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-netmod-immutable-flag-02.html

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

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


___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org
___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org

[netmod] Re: shepherd review for draft-ietf-netmod-rfc8407bis

[maqiufang (A)]

Thanks Med, the update looks good to me, could you please go ahead with 
submission? I will then update and submit my write-up on Datatracker.

Best Regards,
Qiufang
From: mohamed.boucad...@orange.com [mailto:mohamed.boucad...@orange.com]
Sent: Friday, September 27, 2024 4:55 PM
To: maqiufang (A) ; draft-ietf-netmod-rfc8407...@ietf.org
Cc: netmod@ietf.org
Subject: RE: shepherd review for draft-ietf-netmod-rfc8407bis

Re-,

Good points. Updated the text accordingly. Please check Diff: 
draft-ietf-netmod-rfc8407bis.txt - 
draft-ietf-netmod-rfc8407bis.txt<https://author-tools.ietf.org/api/iddiff?url_1=https://netmod-wg.github.io/rfc8407bis/draft-ietf-netmod-rfc8407bis.txt&url_2=https://netmod-wg.github.io/rfc8407bis/quifang-review/draft-ietf-netmod-rfc8407bis.txt>
 and let me know if this is OK with you. Thanks.

Cheers,
Med

De : maqiufang (A) 
mailto:maqiufang1=40huawei@dmarc.ietf.org>>
Envoyé : vendredi 27 septembre 2024 10:38
À : BOUCADAIR Mohamed INNOV/NET 
mailto:mohamed.boucad...@orange.com>>; 
draft-ietf-netmod-rfc8407...@ietf.org<mailto:draft-ietf-netmod-rfc8407...@ietf.org>
Cc : netmod@ietf.org<mailto:netmod@ietf.org>
Objet : RE: shepherd review for draft-ietf-netmod-rfc8407bis

Hi, Med,

Thanks for resolving my comments, please also find my responses below inline.

Besides, if this draft is referenced somewhere by other documents because of, 
e.g., quotation of  the tree diagram generation text in sec.3.4, use the 
Security Considerations Section template in sec.3.7.1, should this draft be 
listed as an informative or normative reference? Should this be stated in 
sec.3.4 and sec.3.7.1 where a reference exists (or somewhere else)?

Best Regards,
Qiufang

From: mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> 
[mailto:mohamed.boucad...@orange.com]
Sent: Friday, September 27, 2024 3:49 PM
To: maqiufang (A) mailto:maqiufa...@huawei.com>>; 
draft-ietf-netmod-rfc8407...@ietf.org<mailto:draft-ietf-netmod-rfc8407...@ietf.org>
Cc: netmod@ietf.org<mailto:netmod@ietf.org>
Subject: RE: shepherd review for draft-ietf-netmod-rfc8407bis

Hi Qiufang,

Thank you for the careful review.

The diff to track the changes can be found here: Diff: 
draft-ietf-netmod-rfc8407bis.txt - 
draft-ietf-netmod-rfc8407bis.txt<https://author-tools.ietf.org/api/iddiff?url_1=https://netmod-wg.github.io/rfc8407bis/draft-ietf-netmod-rfc8407bis.txt&url_2=https://netmod-wg.github.io/rfc8407bis/quifang-review/draft-ietf-netmod-rfc8407bis.txt>

Please see inline for more context.

Cheers,
Med

De : maqiufang (A) 
mailto:maqiufang1=40huawei@dmarc.ietf.org>>
Envoyé : vendredi 27 septembre 2024 08:07
À : 
draft-ietf-netmod-rfc8407...@ietf.org<mailto:draft-ietf-netmod-rfc8407...@ietf.org>
Cc : netmod@ietf.org<mailto:netmod@ietf.org>
Objet : shepherd review for draft-ietf-netmod-rfc8407bis

Hi, authors, WG,


As part of my shepherd write-up for draft-ietf-netmod-rfc8407bis, I've reviewed 
the latest version of the draft and have got some editorial comments (most of 
which are nits), hopefully they could be fixed before progressing the document.

The 
Idnits<https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-netmod-rfc8407bis-16.txt>
 complains of some errors and warnings, some of which I think are valid and 
need to be fixed before publication :
· There is 1 instance of too long lines in the document, the longest 
one being 2 characters in excess of 72.

The line where the when expression is located in sec.4..6.4: when 
'derived-from-or-self(rt:address-family, "v4ur:ipv4-unicast")' {



[Med] Fixed. Thanks.


· Downref: Normative reference to an Informational RFC: RFC 8792

Could this be fixed as informative reference?

[Med] This one is normative. Please note that 8792 is already listed in 
https://datatracker.ietf.org/doc/downref.
Thanks for the information, well noted.
·   -- Obsolete informational reference (is this intentional?): RFC 
7223 (Obsoleted by RFC 8343)

Better to fix the reference to RFC 7223 with 8343 (which also defines the 
identical example) in section 4.19.1?

[Med] The citation of 7223 is intentional. See, e.g.,

=
For example, the "ietf-interfaces" model in 
[RFC7223<https://netmod-wg.github.io/rfc8407bis/draft-ietf-netmod-rfc8407bis.html#RFC7223>]
 has been restructured as an NMDA-compatible model in 
[RFC8343<https://netmod-wg.github.io/rfc8407bis/draft-ietf-netmod-rfc8407bis.html#RFC8343>].
=
The reference above is good for me, what I am referring to is another reference 
of 7223 in sec4.19.1(see below), which I think might be better to be replaced 
with RFC 8343 (RFC 8343 defines that example as well). Agreed?
The following example from [RFC7223] shows how a conditional
   container called "ethernet" is added to the "interface" list only for
   entries of th

[netmod] Re: shepherd review for draft-ietf-netmod-rfc8407bis

[maqiufang (A)]

Hi, Med,

Thanks for resolving my comments, please also find my responses below inline.

Besides, if this draft is referenced somewhere by other documents because of, 
e.g., quotation of  the tree diagram generation text in sec.3.4, use the 
Security Considerations Section template in sec.3.7.1, should this draft be 
listed as an informative or normative reference? Should this be stated in 
sec.3.4 and sec.3.7.1 where a reference exists (or somewhere else)?

Best Regards,
Qiufang

From: mohamed.boucad...@orange.com [mailto:mohamed.boucad...@orange.com]
Sent: Friday, September 27, 2024 3:49 PM
To: maqiufang (A) ; draft-ietf-netmod-rfc8407...@ietf.org
Cc: netmod@ietf.org
Subject: RE: shepherd review for draft-ietf-netmod-rfc8407bis

Hi Qiufang,

Thank you for the careful review.

The diff to track the changes can be found here: Diff: 
draft-ietf-netmod-rfc8407bis.txt - 
draft-ietf-netmod-rfc8407bis.txt<https://author-tools.ietf.org/api/iddiff?url_1=https://netmod-wg.github.io/rfc8407bis/draft-ietf-netmod-rfc8407bis.txt&url_2=https://netmod-wg.github.io/rfc8407bis/quifang-review/draft-ietf-netmod-rfc8407bis.txt>

Please see inline for more context.

Cheers,
Med

De : maqiufang (A) 
mailto:maqiufang1=40huawei@dmarc.ietf.org>>
Envoyé : vendredi 27 septembre 2024 08:07
À : 
draft-ietf-netmod-rfc8407...@ietf.org<mailto:draft-ietf-netmod-rfc8407...@ietf.org>
Cc : netmod@ietf.org<mailto:netmod@ietf.org>
Objet : shepherd review for draft-ietf-netmod-rfc8407bis

Hi, authors, WG,


As part of my shepherd write-up for draft-ietf-netmod-rfc8407bis, I've reviewed 
the latest version of the draft and have got some editorial comments (most of 
which are nits), hopefully they could be fixed before progressing the document.

The 
Idnits<https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-netmod-rfc8407bis-16.txt>
 complains of some errors and warnings, some of which I think are valid and 
need to be fixed before publication :
· There is 1 instance of too long lines in the document, the longest 
one being 2 characters in excess of 72.

The line where the when expression is located in sec.4..6.4: when 
'derived-from-or-self(rt:address-family, "v4ur:ipv4-unicast")' {



[Med] Fixed. Thanks.


· Downref: Normative reference to an Informational RFC: RFC 8792

Could this be fixed as informative reference?

[Med] This one is normative. Please note that 8792 is already listed in 
https://datatracker.ietf.org/doc/downref.
Thanks for the information, well noted.
·   -- Obsolete informational reference (is this intentional?): RFC 
7223 (Obsoleted by RFC 8343)

Better to fix the reference to RFC 7223 with 8343 (which also defines the 
identical example) in section 4.19.1?

[Med] The citation of 7223 is intentional. See, e.g.,

=
For example, the "ietf-interfaces" model in 
[RFC7223<https://netmod-wg.github.io/rfc8407bis/draft-ietf-netmod-rfc8407bis.html#RFC7223>]
 has been restructured as an NMDA-compatible model in 
[RFC8343<https://netmod-wg.github.io/rfc8407bis/draft-ietf-netmod-rfc8407bis.html#RFC8343>].
=
The reference above is good for me, what I am referring to is another reference 
of 7223 in sec4.19.1(see below), which I think might be better to be replaced 
with RFC 8343 (RFC 8343 defines that example as well). Agreed?
The following example from [RFC7223] shows how a conditional
   container called "ethernet" is added to the "interface" list only for
   entries of the type "ethernetCsmacd".
augment "/if:interfaces/if:interface" {
when "if:type = 'ianaift:ethernetCsmacd'";

container ethernet {
leaf duplex {
...
}
}
}

Section 4.14 specifies a set of YANG statements that MUST have a description 
substatement, but I don't think anydata should be omitted here. Thoughts?
[Med] This list is inherited from 8407, which in its turn was inherited from 
6087. anydata wasn't in 6087 because it wasn't defined at the time in 6020. I 
don't have the context whether this was considered by the WG in the past, but 
I'm afraid that adding this mandatory will break existing models. For example, 
pyang does not make that check for anydata, while it is in place for anyxml. I 
suggest we leave the list as it is.
That seems like a valid concern for this NBC update, I am okay with keeping 
this as it is, if there is no objections from others.
Other nits:
· Section 4.5
OLD:  presence "When present, indicates type foo"
NEW: presence "When present, indicates type foo"; (missing the 
semicolon)
[Med] ACK.

OLD:  presence "When present, indicates type bar"
NEW: presence "When present, indicates type bar"; (

[netmod] shepherd review for draft-ietf-netmod-rfc8407bis

[maqiufang (A)]

Hi, authors, WG,


As part of my shepherd write-up for draft-ietf-netmod-rfc8407bis, I've reviewed 
the latest version of the draft and have got some editorial comments (most of 
which are nits), hopefully they could be fixed before progressing the document.

The 
Idnits
 complains of some errors and warnings, some of which I think are valid and 
need to be fixed before publication :

* There is 1 instance of too long lines in the document, the longest 
one being 2 characters in excess of 72.

The line where the when expression is located in sec.4..6.4: when 
'derived-from-or-self(rt:address-family, "v4ur:ipv4-unicast")' {



* Downref: Normative reference to an Informational RFC: RFC 8792

Could this be fixed as informative reference?


*   -- Obsolete informational reference (is this intentional?): RFC 
7223 (Obsoleted by RFC 8343)

Better to fix the reference to RFC 7223 with 8343 (which also defines the 
identical example) in section 4.19.1?

Section 4.14 specifies a set of YANG statements that MUST have a description 
substatement, but I don't think anydata should be omitted here. Thoughts?

Other nits:

* Section 4.5
OLD:  presence "When present, indicates type foo"
NEW: presence "When present, indicates type foo"; (missing the 
semicolon)

OLD:  presence "When present, indicates type bar"
NEW: presence "When present, indicates type bar"; (missing the 
semicolon)

OLD:
 Section 8.1 of [RFC7950] includes a provision for defining 
a
   constraint on state data and specifies that the constraint 
must be
   true in a valid state data.
NEW:
 Section 8.1 of [RFC7950] includes a provision for defining
   constraints on state data and specifies that the constraint 
must be
   true in a valid state data tree.


* Section 4.20

OLD:  max-elements  10;

NEW: max-elements 10;
Please consider indenting a space here.


* Section 4.24

s/ min-entries/min-elements

s/max-entries/max-elements



* Section 5.1

OLD:

  Name:  iana-template

  Maintained by IANA?  N

  Namespace:  urn:ietf:params:xml:ns:yang:iana-template

  Prefix:  iana-foo

  Reference:  RFC 

NEW:

  Name:  iana-template

  Maintained by IANA?  Y

  Namespace:  urn:ietf:params:xml:ns:yang:iana-template

  Prefix:  iana-foo

  Reference:  RFC 



* Appendix A

OLD: "IETF NETMOD (NETCONF Data Modeling Language) Working Group";

NEW: "IETF NETMOD (Network Modeling) Working Group";

Or, "IETF your-wg-name (expansion) Working Group", to be consistent with the 
info in contact statement.



* Appendix C

The IETF Trust Copyright statement for the iana-template module doesn't seem to 
be correct.

s/Simplified/Revised/?

Best Regards,
Qiufang

___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org

[netmod] Re: comments on system-config-08 draft

[maqiufang (A)]

Hi, Andy,


Changing the running config so it is split into 2 datastores makes operations 
more complicated.
It doesn't actually work since YANG is hierarchical and has cross-references.

IMO the only improvement needed is to add metadata to  so a client can
better understand the system config and make edit requests that will not fail.

Most deployment (90%?) is non-NMDA and it will probably stay that way.
The developer focus is on data model deployment, not redoing the foundation. 
IMO people want YANG to
be simpler and faster. I don't see how splitting config up into 2 datastores 
helps.

I am not sure I agree this draft is “changing the running config so it is split 
into 2 datastores”.

I think it is already the case that NMDA never puts system configuration into 
, it’s only in . So has NMDA already made NBC changes to 
the behavior of non-NMDA servers? If you know any existing standards that say 
system configuration is defined in , I would appreciate that if you 
could help navigate, as I’ve always thought putting system configuration into 
 is just one of the existing various proprietary implementations, our 
implementation used to be this way, but not now, after some customers 
complained that they don’t want to see some system config magically appeared 
when they write some config into  and then read back, and there are 
other reasons like performance.


Best Regards,
Qiufang


___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org

[netmod] Re: 2nd WGLC on system-config-08

[maqiufang (A)]

Hi, Kent, Jan, all,

Sorry for being late in replying, thanks Jan and Jürgen for the review, I will 
see how to address the comments once we reach agreement on this “copy or merge” 
issue… please find more reply inline…

From: Kent Watsen [mailto:kent+i...@watsen.net]
Sent: Wednesday, August 21, 2024 1:06 AM
To: Jan Lindblad (jlindbla) 
Cc: netmod@ietf.org
Subject: [netmod] Re: 2nd WGLC on system-config-08

Hi Jan,


After us all now having investigated this line of reasoning, my conclusion is 
that we have to choose one of two approaches:

The primary open-question is if it is *needed* for a client to copy  
nodes into .  IMO, to understand the requirements, this question must 
be answered first.

The draft highlights three reasons:
  1. so running-alone can be valid (e.g., 5.5.1 and 5.5.2)
  2. so system-defined values can be changed (e.g., section 5.5.3)
  3. so descendents can be added to system-defined nodes (e.g., 5.5.4)

Each are discussed below.

Regarding #1, I’m sympathetic to not flipping an established client-contract 
without warning.  My proposal is to version the protocols (i.e. NETCONF 1.2 and 
RESTCONF 1.1) to indicate this change in behavior.  That is, a server 
implementing the  datastore would have to implement the updated 
protocol versions.  So, for this item, it seems that it is not *needed* for a 
client to copy nodes into , if the protocols are versioned.
If we move towards this way, does this mean the draft needs to be pending until 
new versions of protocols are published?
But even if  alone doesn’t have to be valid, no one would stop a 
client keep copying referenced system nodes into , e.g., if no 
template used in  and the client wants to do offline validation of 
. The current draft simply allows the client to do that, it no longer 
states the client MUST copy any referenced system nodes into .

I kind of feel like we are back where we started, after around 4 years’ 
discussion. I think the agreement at the interim in January was to effectively 
say nothing in the draft and fully rely on existing statements in RFCs. I think 
this approach gives flexibility and allows the server to behave the way they do 
today. And then when we comes to the discussion of NC/RC-next, we may decide 
whether there are benefits to relax the rule and make further clarifications. 
Any issue we see now with this handling?
Regarding #2, I am firstly unclear how this is needed, when we’re only just 
now, for the first time, exposing system-defined configuration.  Up to now, 
system-defined configuration only appeared in , with no ability to 
tweak it, right?  Secondly, the example is not compelling, e.g., why would a 
client care what the MTU is on the loopback interface?  But, if this is 
important, how do vendors enable it to be changed today?
In our implementation, there are non-modifiable/immutable and modifiable system 
configuration. the server allows the client to directly write the desired value 
into  which overrides the value provided by the system, such examples 
could be, e.g., to modify some log levels generated by the running systems, or 
system-provided threshold values.
Regarding #3, same as #2: how is this needed?  The example is not compelling.  
If this is important, how do vendors enable such extensions today?
But isn’t the following example common?
System configures a physical interface instance with only name and type leaf 
specified, and the client can further configures other descendant nodes, e.g., 
ip-address.

I feel that #2 and #3 are not really the “copy” things, they are about editing 
some parts of system configuration.
But speaking about copy, the authors are considering removing the 
“resolve-system” parameter, for the following reasons:

· It is complex and expensive to implement properly (see the last 
paragraph in 
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-system-config-05#section-5.3)

· It is optional to implement, and there is workaround (i.e., explicit 
copy)
Given reasons above, I doubt if it will be implemented in real world;-) Any 
objections to removing this “resolve-system” parameter?


Kent // as a contributor
Best Regards,
Qiufang
___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org

[netmod] Re: comments on system-config-08 draft

[maqiufang (A)]

Hi, Andy,

Thanks for the comments, please see reply inline…

From: Andy Bierman [mailto:a...@yumaworks.com]
Sent: Wednesday, August 21, 2024 12:34 AM
To: NetMod WG 
Subject: [netmod] comments on system-config-08 draft

Hi,

I do not think this draft is ready.

1) Behavior changes to conventional datastores

There seem to be NBC changes being made to the
behavior of the conventional non-NMDA datastores, particularly .

I disagree that it is a problem that  contains some system 
configuration
mixed in with the client configuration.  The only problem is that the data is 
not
editable by clients.  The "immutable" flag draft provides clients
with enough information to avoid 'access-denied' errors when editing system 
config.
Changing the behavior of  seems to break old non-NMDA clients
that expect the combined config.
There are various implementations about system configuration, and some do put 
system configuration into , but the vision has always been to give the 
client full control over , right? System configuration comes and goes, 
which is beyond the control of operators, while I think  should be 
controlled with more predictability.

2) NBC Changes to XPath

Changing the XPath evaluation procedures is an NBC change.
In this case, also quite complicated to implement XPath across
multiple datastores.

System config could be visible in  using the immutable flag.
Leafrefs and XPath are allowed to point at config=true in the same data tree.
This does not require any changes to XPath processing.

Referencing a special read-only datastore is no different than simply
allowing the XPath to reference config=false.  It is the same NBC change.
I am confused by this comment, as no one has ever proposed to change the XPath 
evaluation procedures.
If the intention is to make  alone valid, the proposed approach is to 
either copy the referenced system nodes into  or use the 
“resolve-system” parameter to allow the server do the copy thing.
If  alone doesn’t have to be valid and only  is subject to 
validation, then simply merge  with  to be referentially 
complete for .
Neither case has proposed a direct cross-datastore reference.
3) resolve-system

I am confused why a client would not resolve the system, since
the  datastore needs these nodes so the client nodes can exist.
Of course the client can resolve the reference and explicitly copy the missing 
parts from  into  (see sec 5.2), “resolve-system” is just an 
alternative for the clients that don’t wish a manual copy. It is optional to 
implement and clients *may* use.


Andy
Best Regards,
Qiufang
___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org

[netmod] Re: Yang Scalability

[maqiufang (A)]

Hi, Deepak,

Thanks a lot for bring this to IETF, I’d like to comment on the #3 requirement 
you mentioned below, regarding the use of templates, I believe this is related 
to your slides from #11 to #14.

First, I think the default and mandatory statements defined in the YANG modules 
should follow the way it is supposed to be, it doesn’t make a lot of sense to 
me to remove them simply because we have issues when using them in template 
mechanism. Slide #13 (e.g., “Hence solving these issues requires new modules 
without mandatories and defaults”) seems to indicate that you’re finding ways 
to remove the default and mandatory statements in published modules, but I feel 
this should not be right way to go.

I guess I don’t really understand the issues you are describing here, I fully 
agree that the results should be a merge of the template and values explicitly 
provided, with the latter ones taking precedence over the template. But for the 
default configuration, the slides mentioned “A default statement will (silently 
!) overrule a different value coming from the template if not explicitly 
configured to repeat the template value.” To me, this is not the always the 
case, and it would probably depend on the with-defaults basic mode defined in 
RFC 6243 which defines how a server handles the default data. For example, if 
it is “report-all” basic mode, the server would consider every data node with a 
schedule default value to exist, and then it would probably override a template 
value silently; but if the server uses a “explicit” basic mode,  it won’t 
consider the default data to exist until it is explicitly provided by the 
client, so it feels to me that what is configured in the template should become 
the final merged result.

For mandatory node, could you please clarify a little bit on why “A mandatory 
statement forces an ONU instance to repeat a data node already configured in 
the template”? For validation purpose? But I think it is the merged results 
that should be subject to validation.

I am sorry if I have any misunderstandings, I would wait for your I-D and see 
if that helps understand it better. Thanks.

Best Regards,
Qiufang
From: Deepak Rajaram (Nokia) 
Sent: Tuesday, July 23, 2024 4:52 PM
To: netmod@ietf.org
Subject: [netmod] Yang Scalability

Dear all

Thanks for the opportunity to present on yang scalability, this is a follow-up 
after having briefly introduced the real-life YANG scalability and performance 
challenges layed out in the Broadband Forum liaison.

I would encourage NETMOD participants to go over the slides in the meeting 
materials section of ietf-120/netmod. 
slides-120-netmod-10-bbf-liaison-on-management-at-scale-projects

Short summary:

Based on studies conducted by several Broadband Forum meeting participants, it 
is found that existing standard YANG implementations do not scale up to 
configurations that contain a very high number of interfaces; for instance in a 
Passive Optical Network, a single Optical Line Termination (OLT) can easily 
surpass 30.000 interfaces (i.e. a few per Optical Network Unit). This is a real 
challenge for network deployments. We are seeing scaling challenges in terms of 
datastore sizes and datastore manipulations (slow configuration, slow data 
retrieval).

While a PON network is taken as an example, it’s more than likely this scaling 
challenge will find its way to other parts of networks as products and industry 
evolves.

We believe this is something NETMOD needs to address with urgency.

As a result of the study, to address such scalability issues, few salient 
points were analyzed and translated into following requirements:


  1.  “Clustering” data nodes
  2.  Reducing datastore size by using shared profiles
  3.  Reducing datastore size by using “templates”

Existing ietf-schema-mount (RFC8528) 
and the new draft of full: 
embed 
definitely prove to be useful for certain aspects, including reusability of 
modules as-is. Still, in their current form they fall short for overcoming the 
scalability issues, which we believe can be mitigated using “templates” and 
profiles.

I expect a more detailed ID will be brought forward explaining the proposal of 
templates/profiles. In anticipation of this ID, I would welcome the group to go 
over the slides for more details on the concepts. Any feedback/suggestions are 
more than welcome 😊

Regards
Deepak

___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org

[netmod] Re: I-D Action: draft-ietf-netmod-immutable-flag-01.txt

[maqiufang (A)]

Hi, all,



-01 is available now, this version incorporates inputs received at the interim 
(minutes available at : 
https://datatracker.ietf.org/doc/minutes-interim-2024-netmod-02-202402061400/):

· State that “Servers may suppress the annotation if it is inherited 
from its parent node or uses the default value as the top-level node, but are 
not precluded from returning the annotation on every single element.”

· State that “Servers MUST ignore any immutable annotations sent from 
the client.”

· For list/leaf-list, highlight that immutable annotation has no 
bearing on the entry ordering

And there are some other updates:

· Add RESTCONF protocol for immutable flag, as it should be protocol 
agnostic;

· Formally update RFCs 6241, 8040 and 8526, as this document extends 
existing protocol operations  with a new query parameter;

· Use security consideration template in rfc8407bis



Happy to receive any other comments and suggestions from the WG.



Best Regards,

Qiufang



-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
Sent: Saturday, June 29, 2024 10:11 AM
To: i-d-annou...@ietf.org
Cc: netmod@ietf.org
Subject: [netmod] I-D Action: draft-ietf-netmod-immutable-flag-01.txt



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



   Title:   YANG Metadata Annotation for Immutable Flag

   Authors: Qiufang Ma

Qin Wu

Balazs Lengyel

Hongwei Li

   Name:draft-ietf-netmod-immutable-flag-01.txt

   Pages:   19

   Dates:   2024-06-28



Abstract:



   This document defines a way to formally document existing behavior,

   implemented by servers in production, on the immutability of some

   system-provided nodes, using a YANG metadata annotation called

   "immutable" to flag which nodes are immutable.



   Clients may use "immutable" annotations provided by the server, to

   know beforehand why certain otherwise valid configuration requests

   will cause the server to return an error.



   The immutable flag is descriptive, documenting existing behavior, not

   proscriptive, dictating server behavior.



The IETF datatracker status page for this Internet-Draft is:

https://datatracker.ietf.org/doc/draft-ietf-netmod-immutable-flag/



There is also an HTML version available at:

https://www.ietf.org/archive/id/draft-ietf-netmod-immutable-flag-01.html



A diff from the previous version is available at:

https://author-tools.ietf.org/iddiff?url2=draft-ietf-netmod-immutable-flag-01



Internet-Drafts are also available by rsync at:

rsync.ietf.org::internet-drafts





___

netmod mailing list -- netmod@ietf.org

To unsubscribe send an email to 
netmod-le...@ietf.org
___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org

[netmod] Re: Yangdoctors last call review of draft-ietf-netmod-system-config-06

[maqiufang (A)]

Thanks a lot Med. I have submitted a new version to incorporate your fixes. You 
might want to review it at 
https://author-tools.ietf.org/iddiff?url2=draft-ietf-netmod-system-config-08.

Best Regards,
Qiufang

-Original Message-
From: mohamed.boucad...@orange.com [mailto:mohamed.boucad...@orange.com] 
Sent: Tuesday, June 18, 2024 3:30 PM
To: maqiufang (A) ; Michal Vaško ; 
yang-doct...@ietf.org
Cc: draft-ietf-netmod-system-config@ietf.org; last-c...@ietf.org; 
netmod@ietf.org
Subject: RE: [netmod] Yangdoctors last call review of 
draft-ietf-netmod-system-config-06

Hi Qiufang, 

Thanks for taking care of this. 

I submitted right now a PR with some minor fixes (e.g., align with 8407bis 
reco): https://github.com/netmod-wg/system-config/pull/38

Other than that, this looks good to me.

Cheers,
Med

> -Message d'origine-
> De : maqiufang (A)  Envoyé : lundi 17 juin 2024 
> 14:28 À : BOUCADAIR Mohamed INNOV/NET ; 
> Michal Vaško ; yang-doct...@ietf.org Cc : 
> draft-ietf-netmod-system-config@ietf.org; last- c...@ietf.org; 
> netmod@ietf.org Objet : RE: [netmod] Yangdoctors last call review of 
> draft-ietf-
> netmod-system-config-06
> 
> 
> Hi, Med and Michal,
> 
> Thanks for your review, the authors have submitted a new version 
> (https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%
> 2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-netmod-system-
> config-
> 07&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C1a59a213597040
> 741c9708dc8ec8ee94%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6
> 38542240852698598%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ
> QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=am
> rvfTAx%2Fh2IvNtkbpBjGC8gInnlriPP9bGfYYACvKQ%3D&reserved=0)  to resolve 
> the nits you raised below, together with some other updates received 
> from the WG. Please review the diff 
> (https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%
> 2Fauthor-tools.ietf.org%2Fiddiff%3Furl1%3Ddraft-ietf-netmod-
> system-config-06%26url2%3Ddraft-ietf-netmod-system-config-
> 07%26difftype%3D--
> html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C1a59a2135970
> 40741c9708dc8ec8ee94%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7
> C638542240852716505%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL
> CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=
> 8N0szV%2FeKhtq3zkood1OXjcfl1uwBL1wbdO1%2FVSAq1o%3D&reserved=0)
> and let us know if you have further comments. Thanks a lot!
> 
> Best Regards,
> Qiufang
> 
> -Original Message-
> From: mohamed.boucad...@orange.com
> [mailto:mohamed.boucad...@orange.com]
> Sent: Thursday, June 13, 2024 7:25 PM
> To: Michal Vaško ; yang-doct...@ietf.org
> Cc: draft-ietf-netmod-system-config@ietf.org; last- c...@ietf.org; 
> netmod@ietf.org
> Subject: RE: [netmod] Yangdoctors last call review of draft-ietf-
> netmod-system-config-06
> 
> Hi all,
> 
> On this one:
> 
> > - all 'local-as' and 'peer-as' nodes are uint32, so in JSON
> encoding
> > numbers should be used instead of strings
> 
> Even if this an example, the authors may consider using "inet:as- 
> number" rather than uint32.
> 
> As I'm there,
> 
> (1)
> 
>  the name of this leaf is weird:
> 
>leaf name {
>  type inet:ip-address;
>}
> 
> I would change the name.
> 
> (2) I would delete from the description of the ietf-system- datastore 
> module:
> 
> The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
> 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
> 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
> are to be interpreted as described in BCP 14 (RFC 2119)
> (RFC 8174) when, and only when, they appear in all
> capitals, as shown here.";
> 
> (3) Please fix this part in the IANA cons:
> 
> OLD:
>   name: ietf-system-datastore
>   prefix: sys
> 
> NEW:
>   name: ietf-system-datastore
>   prefix: sysds
> 
> (4) Security cons: Please use the sec template in both subsections
> 
> For example,
> 
> CURRENT:
>The Network Configuration Access Control Model (NACM) [RFC8341]
>provides the means to restrict access for particular NETCONF users 
> to
>a preconfigured subset of all available NETCONF protocol operations
>and content.
> 
> Does not mention RESTCONF.
> 
> I think other para of the template should make it to these sections.
> 
> Also, you may start each subsection by indicating the name of the 
> module instead of "The

[netmod] Re: Yangdoctors last call review of draft-ietf-netmod-system-config-06

[maqiufang (A)]

Hi, Med and Michal, 

Thanks for your review, the authors have submitted a new version 
(https://datatracker.ietf.org/doc/html/draft-ietf-netmod-system-config-07)  to 
resolve the nits you raised below, together with some other updates received 
from the WG. Please review the diff 
(https://author-tools.ietf.org/iddiff?url1=draft-ietf-netmod-system-config-06&url2=draft-ietf-netmod-system-config-07&difftype=--html)
 and let us know if you have further comments. Thanks a lot!

Best Regards,
Qiufang

-Original Message-
From: mohamed.boucad...@orange.com [mailto:mohamed.boucad...@orange.com] 
Sent: Thursday, June 13, 2024 7:25 PM
To: Michal Vaško ; yang-doct...@ietf.org
Cc: draft-ietf-netmod-system-config@ietf.org; last-c...@ietf.org; 
netmod@ietf.org
Subject: RE: [netmod] Yangdoctors last call review of 
draft-ietf-netmod-system-config-06

Hi all,

On this one: 

> - all 'local-as' and 'peer-as' nodes are uint32, so in JSON encoding 
> numbers should be used instead of strings

Even if this an example, the authors may consider using "inet:as-number" rather 
than uint32.

As I'm there,

(1)

 the name of this leaf is weird:

   leaf name {
 type inet:ip-address;
   }

I would change the name. 

(2) I would delete from the description of the ietf-system-datastore module:

The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
are to be interpreted as described in BCP 14 (RFC 2119)
(RFC 8174) when, and only when, they appear in all
capitals, as shown here.";

(3) Please fix this part in the IANA cons:

OLD: 
  name: ietf-system-datastore
  prefix: sys

NEW:
  name: ietf-system-datastore
  prefix: sysds

(4) Security cons: Please use the sec template in both subsections

For example, 

CURRENT:
   The Network Configuration Access Control Model (NACM) [RFC8341]
   provides the means to restrict access for particular NETCONF users to
   a preconfigured subset of all available NETCONF protocol operations
   and content.

Does not mention RESTCONF.

I think other para of the template should make it to these sections.

Also, you may start each subsection by indicating the name of the module 
instead of "The YANG module defined in this document" because two modules are 
defined in the doc.

Hope this helps.

Cheers,
Med

> -Message d'origine-
> De : Michal Vaško via Datatracker  Envoyé : jeudi 13 
> juin 2024 12:25 À : yang-doct...@ietf.org Cc : 
> draft-ietf-netmod-system-config@ietf.org; last- c...@ietf.org; 
> netmod@ietf.org Objet : [netmod] Yangdoctors last call review of 
> draft-ietf-
> netmod-system-config-06
> 
> 
> Reviewer: Michal Vaško
> Review result: Ready with Nits
> 
> This is my yang-doctor review of draft-ietf-netmod-system-config, 
> which includes 2 small YANG modules, in addition to a few example 
> modules.
> 
> ietf-system-datastore:
> - small module with a single identity, no issues
> 
> ietf-netconf-resolve-system:
> - module with similar simple augments to standard ietf-netconf and 
> ietf-netconf-nmda modules, no issues
> 
> As for the example YANG modules and data, there are a few nits:
> 
> example-acl:
> - leaf-list application - path is not indented
> 
> Section 8.2 BGP examples:
> - 'inet:port' type does not exist in the latest ietf-inet-types
> (2013) YANG module, only 'port-number' - all 'local-as' and 'peer-as' 
> nodes are uint32, so in JSON encoding numbers should be used instead 
> of strings - 'local-port' is using uint16 type so in JSON encoding 
> numbers should be used instead of strings
> 
> Finally, the examples and their data are using YANG snippets and data 
> without namespaces or module names, which may be fine for illustration 
> purposes but possibly confusing.
> 
> 
> ___
> netmod mailing list -- netmod@ietf.org To unsubscribe send an email to 
> netmod-le...@ietf.org

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 may contain confidential or privileged 
information that may be protected by law; they should not be distributed, used 
or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsi

[netmod] Re: I-D Action: draft-ietf-netmod-system-config-06.txt

[maqiufang (A)]

Hi, Jan,

Thanks a lot for taking the time to review the update! Apologies for being late 
on this response. The authors have submitted a new version 
(https://datatracker.ietf.org/doc/html/draft-ietf-netmod-system-config-07) to 
resolve your comments, please also find my reply below.

From: Jan Lindblad (jlindbla) [mailto:jlindbla=40cisco@dmarc.ietf.org]
Sent: Wednesday, June 5, 2024 12:14 AM
To: maqiufang (A) mailto:maqiufa...@huawei.com>>; 
netmod@ietf.org<mailto:netmod@ietf.org>
Subject: Re: [netmod] Re: I-D Action: draft-ietf-netmod-system-config-06.txt

Qiufang, WG,

Thank you for the effort you put into working out all the wrinkles of system 
config. I read the updated version, and I think it is a significant 
improvement. As usual, I have some comments, questions and suggestions. 😊 In 
order of appearance.

#1 Somewhat unclear conceptual model

Section 5.1 has a nice drawing of how the datastores relate to each other, and 
an introductory text that explains the interactions. The following sections 
explain how data can be copied from system to running, or can be filled in 
automatically using the resolve-system parameter. But the first sentence of 
section 5.1 is

Clients MAY reference nodes defined in , override system-provided 
values, and configure descendant nodes of system-defined configuration in 
.

In my mind, this is only true when the client uses the resolve-system 
parameter. Otherwise, a client cannot reference  directly, but needs to 
copy from  to . So maybe the introductory sentences could be 
reworded?
I think this sentence mentioned clients could reference system configuration 
(i.e., configure some nodes referring to system provided instance), but doesn’t 
specify how that could be achieved to make  valid (i.e., explicit 
declaration vs. using “resolve-system” parameter).
But to avoid any misunderstanding, how about the following update in sec.5.1?
Clients MAY reference nodes defined in , override system-provided 
values, and configure descendant nodes of system-defined configuration in 
, as detailed in Section 5.2, Section 5.3, and Section 5.4.
Please let me know if you have better suggestions.

#2 No way to squelch system config from intended

The software on a device decides what config from  that show up in 
 (i.e. is considered “referenced”). If the client would like 
something not to flow through to , there is no mechanism for that.

Let’s say some device always creates a loopback0 interface in . The 
client can change the loopback0 mtu by configuring it in running, but there is 
no way to entirely remove loopback0. Maybe a stupid example, but let’s say the 
client wants the loopback0 to be called lo0 instead. The same situation would 
arise for anything else in , e.g. some system TPM security credential, 
system traffic classification rule or whatever else people may throw into 
.

Is this a problem? Is this something that should be mentioned so that people 
leveraging  are aware of this limitation?
Just want to make sure that I fully understand this comment, when you say the 
problem/limitation, are you referring to the fact that system-defined list 
entry is non-deletable to clients?
Because when it comes to updating the list key, RFC7950 already doesn’t allow 
key value to be changed (if I understand it correctly), we can only create or 
remove the entire list instance.
I agree that the client can define a new entry in  called lo0, but 
loopback0 would always be present.
Please see if the following update works for you:
OLD: Configuration in  is non-deletable to clients, even though a 
client may delete a copied system node from .
NEW: Configuration in  is non-deletable to clients (e.g., a 
system-defined list entry can never be removed), even though a client may 
override or delete a copied system node from .
Or please feel free to propose any text;-)
#3 Still unclear what needs to be copied

In section 5.2 it is explained how a client can copy data from system to 
running. The introduction in section 1 has some bullets about conditions that 
require copying to happen. Section 6 was added with some language about leafs 
with default values that need to be copied. The same need probably also applies 
to presence containers (which are not mentioned anywhere in -06).

All in all, I think the design work around the rules for what needs to be 
copied is hard to grasp in the current version, and is probably incomplete.

Similarly, section 5.3, which deals with what is being copied by resolve-system 
parameter should probably also refer to the same rules, once established.
Please review the update of section 
5.2<https://datatracker.ietf.org/doc/html/draft-ietf-netmod-system-config-07#section-5.2>
 and section 
5.3<https://datatracker.ietf.org/doc/html/draft-ietf-netmod-system-config-07#section-5.3>,
 and let us know if you still think it unclear, or even better, feel free to 
propose any text.
Note that the contents of copy in both sections ha

[netmod] Re: copy-minimum vs. copy-all of "resolve-system" parameter// I-D Action: draft-ietf-netmod-system-config-06.txt

[maqiufang (A)]

Hi, all,

There is a comment received during the WGLC of this draft, which is about the 
copy scope of "resolve-system" parameter, i.e., should the server only 
auto-copy the minimum to make configuration valid or the entire contents of a 
referenced list entry?

Like any value provided by the server that is not the schema default value 
needs to be copied into  
(https://www.ietf.org/archive/id/draft-ietf-netmod-system-config-06.html#section-6),
 should the server also copy other system nodes that is not provided in 
 when triggered by "resolve-system" parameter? Personally I don’t 
think this is needed for -aware clients which can always read  
to discover system-provided values, and read  to get a merged view of 
 and . This is mainly the consideration for non-NMDA clients 
that has no way to discover system configuration and thus any data missing from 
 will result in the client having the wrong impression. On the other 
hand, copy-all might be easier to implement for the server than to calculate 
the minimum.

Any thoughts? Should this be addressed in this document? 

Best Regards,
Qiufang //co-author

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: Friday, May 31, 2024 3:06 PM
To: i-d-annou...@ietf.org
Cc: netmod@ietf.org
Subject: [netmod] I-D Action: draft-ietf-netmod-system-config-06.txt

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

   Title:   System-defined Configuration
   Authors: Qiufang Ma
Qin Wu
Chong Feng
   Name:draft-ietf-netmod-system-config-06.txt
   Pages:   39
   Dates:   2024-05-31

Abstract:

   This document defines how a management client and server handle YANG-
   modeled configuration data that is instantiated by the server itself.
   The system-defined configuration can be referenced (e.g., leafref) by
   configuration explicitly created by a client.

   The Network Management Datastore Architecture (NMDA) defined in RFC
   8342 is updated with a read-only conventional configuration datastore
   called "system" to expose system-defined configuration.

   This document updates RFC 8342, RFC 6241, RFC 8526 and RFC 8040.

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

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-system-config-06

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

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


___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org
___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org

[netmod] Re: I-D Action: draft-ietf-netmod-system-config-06.txt

[maqiufang (A)]

Hi, all

-06 tries to address comments received during WGLC, thanks a lot to Jan, Rob 
and Jason for your valuable inputs.
Major updates are following:
1. remove the definition of  inactive-until-referenced system config, -06 only 
defines two kinds of system config now: immediately-present vs. 
conditionally-present;
2. add a new section (see sec.6) to clarify the interplay between system config 
and defaults;
3. add a new section (see sec.7) to clarify relation to other datastores, which 
includes  and /;
4. leave the merge behavior of  and  unspecified, as we think 
this is not specific to this document;
5. update figure 1 (architectural model of datastores) to make the arrows of 
 and  merge at a common point  flowing into ;
6. augment  and  PRC operation to also support 
"resolve-system" parameter;
7. remove the implementation specifics related to "resolve-system" parameter;
8. other editorial fix as suggested by Jan and Rob;

There is one issue highlighted during WGLC, which will be posted in a separate 
thread for further discussion. The authors would like to request the WG to 
review the update and provide your feedback, any comments and suggestions would 
be much appreciated. Thanks!

Best Regards,
Qiufang //co-author

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: Friday, May 31, 2024 3:06 PM
To: i-d-annou...@ietf.org
Cc: netmod@ietf.org
Subject: [netmod] I-D Action: draft-ietf-netmod-system-config-06.txt

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

   Title:   System-defined Configuration
   Authors: Qiufang Ma
Qin Wu
Chong Feng
   Name:draft-ietf-netmod-system-config-06.txt
   Pages:   39
   Dates:   2024-05-31

Abstract:

   This document defines how a management client and server handle YANG-
   modeled configuration data that is instantiated by the server itself.
   The system-defined configuration can be referenced (e.g., leafref) by
   configuration explicitly created by a client.

   The Network Management Datastore Architecture (NMDA) defined in RFC
   8342 is updated with a read-only conventional configuration datastore
   called "system" to expose system-defined configuration.

   This document updates RFC 8342, RFC 6241, RFC 8526 and RFC 8040.

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

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-system-config-06

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

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


___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org
___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org

[netmod] Re: WG Last Call: draft-ietf-netmod-acl-extensions-06

[maqiufang (A)]

Thank you Med for taking care of my comments, the update looks good to me.

Best Regards,
Qiufang

-Original Message-
From: mohamed.boucad...@orange.com [mailto:mohamed.boucad...@orange.com] 
Sent: Wednesday, May 15, 2024 2:38 AM
To: maqiufang (A) ; Lou Berger 
Cc: netmod@ietf.org
Subject: RE: [netmod] WG Last Call: draft-ietf-netmod-acl-extensions-06

Hi Qiufang, 

Thank you for the review. 

https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-extensions/07/ takes 
these comments into account. Please see some clarifications below.

Cheers,
Med

> -Message d'origine-
> De : netmod  De la part de maqiufang (A) 
> Envoyé : lundi 6 mai 2024 11:22 À : Lou Berger  Cc : 
> netmod@ietf.org Objet : Re: [netmod] WG Last Call: 
> draft-ietf-netmod-acl-
> extensions-06
> 
> 
> Hi, Lou, all,
> 
> I've reviewed this document and believe it is ready for publication. 
> Some comments/nits that should be fixed before
> publication:
> 
> - Sec.1.1 Why are the IANA-Maintained Modules provided in A.2,
> B.2 and C.2 being asked to be removed from the final RFC?

[Med] Yes, only the templates will be maintained. 

 Should
> the editor then also remove the second paragraph of abstract (The 
> document also defines IANA-maintained modules for ICMP types and
> IPv6 extension headers)?

[Med] No.

 Did I miss something?

[Med] This approach is compliant with what is documented in the 8407bis. You 
may see, e.g., RFC 9108.

> 
> - Sec.3.4 "The augmented ACL structure (Figure 1) includes a new leaf 
> 'flags-bitmask' to better handle TCP flags [RFC9293]."
> The "flags-bitmask" is defined as container, rather than leaf.
> 

[Med] ACK

> - Sec.3.5 " The augmented ACL structure (Figure 1) includes a new leaf 
> 'fragment' to better handle fragments."
> I cannot find a leaf node named "fragment", maybe you are referring to 
> "ipv4-fragment" and "ipv6-fragment"? Likewise, they are defined as 
> containers.

[Med] ACK.

> 
> - Sec.4, the YANG module
>   - copyright years should be 2024
>   - s/Top-levl/Top-level/
>   - Following the guidelines in rfc8407bis, leaf-list/list identifier 
> SHOULD be singular. Inside the icmpv4/6-type-set list, the list 
> identifier "types" may need to rename as "type", and then change the 
> name of the key.
> 

[Med] Good catches. Fixed.

> - Appendix A.2 title: s/Initial Version of the The  ICMPv4 Types 
> IANA-Maintained Module/Initial Version of the ICMPv4 Types IANA- 
> Maintained Module/ (remove "The")

[Med] ACK

> 
> - Appendix B.2 title: s/Initial Version of the The ICMPv6  Types 
> IANA-Maintained Module/Initial Version of the ICMPv6  Types IANA- 
> Maintained/ (remove "The")

[Med] ACK

> 
> - Appendix C.2 file "iana-ipv6-ext-ty...@2023-04-28.yang " name 
> doesn't match the revision-date 2023-09-29
> 

[Med] Fixed.

> - Appendix E. the JSON examples don't seem valid, e.g.,
>   - s/ "acl-enh:flags-bitmask":{/ "ietf-acl-enh:flags-bitmask":{/
>   - s/ "ietf-acces-control-list:acls":{/ "ietf-access-control-
> list:acls":{/(typo "acces")
>   - s/ "forwarding":"ietf-acces-control-list:accept"/
> "forwarding":"ietf-access-control-list:accept"/   (typo "acces")
> 

[Med] Fixed, thanks.

> Best Regards,
> Qiufang
> 
> -Original Message-
> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Lou Berger
> Sent: Tuesday, April 30, 2024 5:42 AM
> To: NETMOD Group 
> Cc: NetMod WG Chairs 
> Subject: [netmod] WG Last Call: draft-ietf-netmod-acl-extensions-
> 06
> 
> All,
> 
> This starts working group last call on
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-netmod-acl-
> extensions%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C62e
> 327e2dc7041160e8608dc6dae0c47%7C90c7a20af34b40bfbc48b9253b6f5d20%
> 7C0%7C0%7C638505841511444084%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w
> LjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%
> 7C&sdata=KW1HJMujcV%2BqRmUifCIngY7s8O5PKtVK3Q2HO7supZY%3D&reserve
> d=0
> 
> The working group last call ends on May 13th.
> Please send your comments to the working group mailing list.
> 
> Positive comments, e.g., "I've reviewed this document and believe it 
> is ready for publication", are welcome!
> This is useful and important, even from authors.
> 
> Thank you,
> Lou (Co-Chair & doc Shepherd)
> 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://eur03.safelinks.p

[netmod] Re: WGLC on system-config-05

[maqiufang (A)]

Hi, Jason,



Thanks for getting back to me. Please also find my response below inline...



-Original Message-

From: Jason Sterne (Nokia) [mailto:jason.ste...@nokia.com]

Sent: Tuesday, May 14, 2024 2:57 AM

To: maqiufang (A) ; Rob Wilton (rwilton) 
; kent+i...@watsen.net; NETMOD Group ; 
draft-ietf-netmod-system-con...@ietf.org

Subject: RE: [netmod] Re: WGLC on system-config-05



Thx Qiufang. Please see inline.

Jason



From: maqiufang (A) 
<mailto:<maqiufa...@huawei.com>;>

Sent: Monday, May 13, 2024 3:47 AM

To: Jason Sterne (Nokia) 
<mailto:<jason.ste...@nokia.com>;>; Rob Wilton 
(rwilton) <mailto:<rwil...@cisco.com>;>; 
kent+i...@watsen.net<mailto:kent+i...@watsen.net>; NETMOD Group 
<mailto:<netmod@ietf.org>;>; 
draft-ietf-netmod-system-con...@ietf.org<mailto:draft-ietf-netmod-system-con...@ietf.org>

Subject: RE: [netmod] Re: WGLC on system-config-05



Hi, Jason and Rob,



Thanks you both for your valuable comments, all good points, much appreciated. 
Please also find my reply below inline...



-Original Message-

From: Jason Sterne (Nokia) [mailto:jason.ste...@nokia.com]

Sent: Saturday, May 11, 2024 12:29 AM

To: Rob Wilton (rwilton) 
mailto:rwilton=40cisco@dmarc.ietf.org>>;
 Kent Watsen mailto:kent+i...@watsen.net>>; 
netmod@ietf.org<mailto:netmod@ietf.org>; 
draft-ietf-netmod-system-con...@ietf.org<mailto:draft-ietf-netmod-system-con...@ietf.org>

Subject: RE: [netmod] Re: WGLC on system-config-05



Please see inline for comments on the "moderate level comments".  I'll try to 
reply later with more feedback on further items below.



Jason



From: Rob Wilton (rwilton) 
mailto:rwilton=40cisco@dmarc.ietf.org>>

Sent: Thursday, May 9, 2024 9:55 AM

To: Kent Watsen mailto:kent+i...@watsen.net>>; 
netmod@ietf.org<mailto:netmod@ietf.org>; 
draft-ietf-netmod-system-con...@ietf.org<mailto:draft-ietf-netmod-system-con...@ietf.org>

Subject: [netmod] Re: WGLC on system-config-05



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.



[Resending due to mailer issues.]

[Qiufang] Thanks, I see it's been accurately archived now.



Hi authors, chairs, WG,



I'm generally supportive of this work, but I think that there are still some 
potential corner cases that are not covered, or it isn't entirely obvious how 
they are handled.



Comments below.



Moderate level comments:



(1) p 7, sec 2.3.  Inactive-Until-Referenced



   There are some system configuration predefined (e.g., application

   ids, anti-x signatures, trust anchor certs, etc.) as a convenience

   for the clients, which must be referenced to be active.  The clients

   can also define their own configurations for their unique

   requirements.  Inactive-until-referenced system configuration is

   generated in  immediately when the device is powered on, but

   it is not active until being referenced.



I'm not sure whether Inactive-Until-Referenced actually needs to be defined, or 
to put it another way, I'm not sure whether this type of configuration is 
special to system datastores at all.  If a configuration (either explicitly in 
 or implicitly from ) defines a QoS policy that is not 
referenced from anywhere, (e.g., not applied to any interfaces) then I think 
that it up to the server to decide whether that unreferenced QoS policy is 
reported in operational or not, depending on server implementation.



[>>JTS:] I agree. I think section 2 may be mixing up two concepts:

  1.  Data dynamically being populated/removed from the system datastore, and

  2.  For data that is in the system datastore, whether it is "active" and 
present in the operational datastore



[Qiufang] Yes, it's actually from 2 dimensions to differentiate different kinds 
of system config: 1. Time of being generated; 2. Time of being applied.



For #2 I don't think there should be anything special. We could say something 
like: As with the running datastore, data present in the system datastore may 
or may not be present in the operational datastore depending on whether it is 
considered as active configuration or not by the server.



[Qiufang] I am personally okay to remove the third kind of definition to keep 
the definition dimension consistent, and maybe for system configuration being 
generated at both different times (immediately vs. conditional), they may be 
either applied by the server immediately or only after being referenced. I also 
think it's worth adding some text as Jason suggested, the client would benefit 
from the knowledge that there might be some system configuration that is 
defined there but not actually in use.



[>>JTS:] I think it is more than just removing the 3rd type defined in section 
2. We probably need t

[netmod] Re: WGLC on system-config-05

[maqiufang (A)]

Hi, Jason,

Thanks for getting back to me. Please see my reply inline...

I think there are a couple of important fundamental issues raised below:

Only auto-copy things missing to make  valid vs auto-copy the entire 
contents of a referenced list entry from system->running.
[Qiufang] Please see more of my comments below, I am not sure the latter choice 
makes sense to me.
When to auto-copy: at edit time or at validation time.
[Qiufang] Maybe another issue: interplay between  and default value.

Jason


#1 Running MAY become invalid

Section 4.2, which discusses software upgrades etc., has some wording that is 
new in -05:

   If system configuration changes (e.g., due to device upgrade),
MAY become invalid.  The server behaviors of migrating
   updated system data into  is beyond the scope of this
   document.  That said, the following gives a list of examples of
   server implementations that might be possible:

I think this is unacceptable and a direct violation of RFC 7950 section 8.1. 
Prior to this document, I am not aware of any RFC that allows running to become 
invalid under any circumstances. I think the always valid running is a very 
important part of the contract between servers and clients.
[>>JTS:] I can see Jan's concern here. Perhaps we should could replace the "If 
system configuration changes..." paragraph with the following:

The behavior of the server when system configuration changes (e.g. due to 
device upgrade) is outside the scope of this document. That said, , the 
following gives a list of examples of
   server implementations that might be possible:
[Qiufang] Thank you Jason for the proposed text, regarding the first sentence 
(starting with "The behavior of the server..."), I am thinking whether we need 
to document it more specific to software upgrade scenario given the statement 
in sec5.3 that If the "resolve-system" parameter is not given by the client, 
the server should not modify  in any way otherwise not specified by 
the client.
OLD: The behavior of the server when system configuration changes (e.g. due to 
device upgrade) is outside the scope of this document.
NEW: The behavior of the server when software is upgraded is not specific to 
system configuration and outside the scope of this document.
Better?
[>>JTS:] I don't think we should restrict the statement to only being about the 
software upgrade scenario. This section 4.2 is about changes to  no 
matter how they happen (upgrade, but also other reasons mentioned in the 
draft). The server behavior when those changes occur can vary whether system 
changed because of upgrade or those other reasons. I also think 5.3 is a 
somewhat different issue. That 5.3 statement you quote is more general (and not 
specifically related to changes to  that could trigger changes to 
, e.g. during an upgrade).
[Qiufang] What I am thinking is, if we don't restrict this statement to 
software upgrade only, combined with the examples of possible behaviors listed, 
it seems to imply that any system configuration update (e.g., interface config 
being cleared from  due to removal of an interface card) would need the 
server to do something to ensure validity of . Is this true (and 
acceptable)?
IMO if interface is removed physically, and related config disappears from 
, / would become invalid only if the interface is 
referenced but not copied in . Or maybe add back about the choice that 
server does nothing and client decides whether some fix needs to be done in 
?


#3 Defaults vs system config

[>>JTS:] I suppose we have two options here:
1)  Say that the system values override defaults in the running, or
2)  Say that any leaf with a non-default value in system also needs to be 
copied into running? Of course then this no longer becomes purely about 
*validity* anymore...
[Qiufang] I think Jan is raising a good point, the WG should not miss the 
interplay between defaults and system config.
I am not sure I like option 1) . If it is the client's intention to enable 
interface "lo0" and explicitly write a default value (true) into , it 
should override the value in .
[>>JTS:] You mention "explicitly write". I'm not positive what you meant here, 
but I was talking about the case where the operator creates lo0 in running but 
does *not* explicitly configure the 'enable' leaf in running. So in option #1:
-  reading the 'enable' leaf from running will return nothing
[Qiufang] My understanding is it would return "true" or nothing, depending on 
the with-defaults basic-mode or retrieval parameter being used.
-  the client may assume that the value being used by the router for 
'enable' is 'true' (default in the YANG)
[Qiufang] maybe and maybe not, depending on if the client has also read 
 or .
-  actual value being used by the router is 'false'
[Qiufang] In your option1, system values override defaults in , I have 
concern that this goes against with our definition that  takes 
precedence over .
But this is

[netmod] Re: WGLC on system-config-05

[maqiufang (A)]

[resending due to mailarchive issues]
From: maqiufang (A)
Sent: Saturday, May 11, 2024 3:38 PM
To: Jan Lindblad (jlindbla) mailto:jlind...@cisco.com>>; 
Jason Sterne mailto:jason.ste...@nokia.com>>
Cc: Qin Wu mailto:bill...@huawei.com>>; chong feng 
mailto:fengchongl...@gmail.com>>; 'Kent Watsen' 
mailto:k...@watsen.net>>; NETMOD Group 
mailto:netmod@ietf.org>>
Subject: RE: [netmod] Re: WGLC on system-config-05

Hi, Jason and Jan,

Thank you both for your valuable comments, all goods points, much appreciated. 
Please also find my reply below inline...
From: Jason Sterne (Nokia) [mailto:jason.ste...@nokia.com]
Sent: Saturday, May 11, 2024 12:09 AM
To: Jan Lindblad (jlindbla) 
mailto:jlindbla=40cisco@dmarc.ietf.org>>;
 maqiufang (A) mailto:maqiufa...@huawei.com>>; Qin Wu 
mailto:bill...@huawei.com>>; 
fengchong...@gmail.com<mailto:fengchong...@gmail.com>
Cc: Kent Watsen mailto:k...@watsen.net>>; 
netmod@ietf.org<mailto:netmod@ietf.org>
Subject: RE: [netmod] Re: WGLC on system-config-05

Hi all,
Please see inline.
(Note: I haven't read Rob's review yet)
[Qiufang] I am working on it now;-)
Jason

From: Jan Lindblad (jlindbla) 
mailto:jlindbla=40cisco@dmarc.ietf.org>>
Sent: Tuesday, May 7, 2024 8:57 AM
To: maqiufang (A) mailto:maqiufa...@huawei.com>>; Qin Wu 
mailto:bill...@huawei.com>>; 
fengchong...@gmail.com<mailto:fengchong...@gmail.com>
Cc: Kent Watsen mailto:k...@watsen.net>>; 
netmod@ietf.org<mailto:netmod@ietf.org>
Subject: [netmod] Re: WGLC on system-config-05



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.



Authors, WG,

I have taken a good read of the -05 version of the system-config document now 
(thanks for the reminder to review, btw!). I think this is a well written and 
important document. It is touching some of the foundational aspects of the 
entire NETCONF/YANG cluster of documents, which I see as much needed 
maintenance. Just as when priceless paintings are being restored, however, 
extreme care is needed. As we have seen with previous revisions of this 
document, there will be strong opinons about specific wording in some cases, 
even when we are very close in our views.
[Qiufang] Thanks. I also agree that this document might need careful review 
from the WG, a lot of good discussion around this work happened, but the 
authors sometimes feel it not easy to document the outcome accurately or 
reflects the real WG intention, we appreciate your review and comments.
Here are some points I noted while reading, in order of appearance, and of 
greatly varying significance. Only point #1, in my opinion, is a major problem.


#1 Running MAY become invalid

Section 4.2, which discusses software upgrades etc., has some wording that is 
new in -05:

   If system configuration changes (e.g., due to device upgrade),
MAY become invalid.  The server behaviors of migrating
   updated system data into  is beyond the scope of this
   document.  That said, the following gives a list of examples of
   server implementations that might be possible:

I think this is unacceptable and a direct violation of RFC 7950 section 8.1. 
Prior to this document, I am not aware of any RFC that allows running to become 
invalid under any circumstances. I think the always valid running is a very 
important part of the contract between servers and clients.
[Qiufang] The authors added this in -05 trying to document some outcome at the 
interim, but you are making a good point, Jan. I agree to remove this first 
sentence and say nothing about the validity of  in this draft, what is 
stated in 7950 is still the case that way.
The client's ability to validate a configuration may not be very important in 
itself, but client's ability to *reason* about the server's configuration is, 
and by allowing invalid configurations (contradiction in terms?), this gets 
very hard.

[>>JTS:] I can see Jan's concern here. Perhaps we should could replace the "If 
system configuration changes..." paragraph with the following:

The behavior of the server when system configuration changes (e.g. due to 
device upgrade) is outside the scope of this document. That said, , the 
following gives a list of examples of
   server implementations that might be possible:
[Qiufang] Thank you Jason for the proposed text, regarding the first sentence 
(starting with "The behavior of the server..."), I am thinking whether we need 
to document it more specific to software upgrade scenario given the statement 
in sec5.3 that If the "resolve-system" parameter is not given by the client, 
the server should not modify  in any way otherwise not specified by 
the client.
OLD: The behavior of the server when system configuration changes (e.g. due to 
device upgrade) 

Re: [netmod] WG Last Call: draft-ietf-netmod-acl-extensions-06

[maqiufang (A)]

Hi, Lou, all,

I've reviewed this document and believe it is ready for publication. Some 
comments/nits that should be fixed before publication:

- Sec.1.1 Why are the IANA-Maintained Modules provided in A.2, B.2 and C.2 
being asked to be removed from the final RFC? Should the editor then also 
remove the second paragraph of abstract (The document also defines 
IANA-maintained modules for ICMP types and IPv6 extension headers)? Did I miss 
something?

- Sec.3.4 "The augmented ACL structure (Figure 1) includes a new leaf 
'flags-bitmask' to better handle TCP flags [RFC9293]."
The "flags-bitmask" is defined as container, rather than leaf.

- Sec.3.5 " The augmented ACL structure (Figure 1) includes a new leaf 
'fragment' to better handle fragments."
I cannot find a leaf node named "fragment", maybe you are referring to 
"ipv4-fragment" and "ipv6-fragment"? Likewise, they are defined as containers.

- Sec.4, the YANG module
  - copyright years should be 2024
  - s/Top-levl/Top-level/
  - Following the guidelines in rfc8407bis, leaf-list/list identifier SHOULD be 
singular. Inside the icmpv4/6-type-set list, the list identifier "types" may 
need to rename as "type", and then change the name of the key.

- Appendix A.2 title: s/Initial Version of the The  ICMPv4 Types 
IANA-Maintained Module/Initial Version of the ICMPv4 Types IANA-Maintained 
Module/ (remove "The")

- Appendix B.2 title: s/Initial Version of the The ICMPv6  Types 
IANA-Maintained Module/Initial Version of the ICMPv6  Types IANA-Maintained/ 
(remove "The")

- Appendix C.2 file "iana-ipv6-ext-ty...@2023-04-28.yang " name doesn't match 
the revision-date 2023-09-29

- Appendix E. the JSON examples don't seem valid, e.g., 
  - s/ "acl-enh:flags-bitmask":{/ "ietf-acl-enh:flags-bitmask":{/ 
  - s/ "ietf-acces-control-list:acls":{/ "ietf-access-control-list:acls":{/
(typo "acces")
  - s/ "forwarding":"ietf-acces-control-list:accept"/ 
"forwarding":"ietf-access-control-list:accept"/   (typo "acces")

Best Regards,
Qiufang

-Original Message-
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Lou Berger
Sent: Tuesday, April 30, 2024 5:42 AM
To: NETMOD Group 
Cc: NetMod WG Chairs 
Subject: [netmod] WG Last Call: draft-ietf-netmod-acl-extensions-06

All,

This starts working group last call on
https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-extensions/

The working group last call ends on May 13th.
Please send your comments to the working group mailing list.

Positive comments, e.g., "I've reviewed this document and believe it is ready 
for publication", are welcome!
This is useful and important, even from authors.

Thank you,
Lou (Co-Chair & doc Shepherd)


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

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

Re: [netmod] I-D Action: draft-ietf-netmod-schedule-yang-01.txt

[maqiufang (A)]

Hi, all,

This version resolves comments from Dhruv during the WG adoption call. It also 
reflects some comments and suggestions we received from the authors of 
draft-ietf-tvr-schedule-yang at IETF 119: some recurrence with UTC time format 
related groupings are defined separately without the time zone identifier to 
facilitate machine readability. Examples are updated accordingly. 

Any further comments and suggestions are welcome.

Best Regards,
Qiufang

-Original Message-
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of 
internet-dra...@ietf.org
Sent: Sunday, April 28, 2024 11:59 AM
To: i-d-annou...@ietf.org
Cc: netmod@ietf.org
Subject: [netmod] I-D Action: draft-ietf-netmod-schedule-yang-01.txt

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

   Title:   A Common YANG Data Model for Scheduling
   Authors: Qiufang Ma
Qin Wu
Mohamed Boucadair
Daniel King
   Name:draft-ietf-netmod-schedule-yang-01.txt
   Pages:   48
   Dates:   2024-04-27

Abstract:

   This document defines a common schedule YANG module which is designed
   to be applicable for scheduling purposes such as event, policy,
   services, or resources based on date and time.  For the sake of
   better modularity, the module includes basic, intermediate, and
   advanced versions of recurrence related groupings.

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

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-schedule-yang-01

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

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 mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Adoption call for draft-ma-opsawg-schedule-yang-04

[maqiufang (A)]

Hi, Dhruv,


Thanks a lot for your comments, the authors have submitted a new version to 
address them: 
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-schedule-yang-01.
 Please also see my reply inline…

From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Dhruv Dhody
Sent: Friday, April 12, 2024 6:20 PM
To: Kent Watsen 
Cc: netmod@ietf.org
Subject: Re: [netmod] Adoption call for draft-ma-opsawg-schedule-yang-04

Hi Kent,

Support adoption!

A few comments/nits for the authors to consider...

- In the abstract, I was not sure how to parse "..scheduling information such 
as event, policy, services, or resources..", are these examples well known and 
established as scheduling information?
[Qiufang]Actually, the schedule YANG module is intended to serve as common 
building blocks for any scheduling context based on date and time, which should 
have broad applicability without limiting to scheduled events, policies, 
services, resources, etc. The word “information” might be vague, the authors 
have used “purposes”, i.e., “This document defines a common schedule YANG 
module which is designed to be applicable for scheduling purposes such as 
event, policy, services, or resources based on date and time.” Would this be 
better? Otherwise, please feel free to propose text at 
https://github.com/netmod-wg/schedule-yang.
- The introduction made sense as a motivation for the document initially, but 
it should be rephrased esp that the referenced modules are expected to be 
updated to use this common module going forward. You may create an appendix 
with this historical context if needed.
[Qiufang] Agree.  The authors have rephrased the introduction section. Some of 
the relevant description now as follows:
“This document defines a common schedule YANG module ("ietf-schedule") that can 
be used in several scheduling contexts, e.g., (but not limited to) 
[I-D.ietf-opsawg-ucl-acl],
 
[I-D.contreras-opsawg-scheduling-oam-tests],
 and 
[I-D.ietf-tvr-schedule-yang].”
Would this be okay for you?
  - Section 3.1, the description is a bit sparse; also there are no 
examples that use this grouping. Please expand.
[Qiufang] The description is now expanded in section 3.1, and the example that 
uses this grouping is now added as appendix A.1.
- The description inside the YANG module is old and incorrect, it says 2 
groupings and focused only on iCalendar.
[Qiufang] Fixed now. thanks.
- s/RFC : A YANG Data Model for Scheduling/RFC : A Common YANG Data 
Model for Scheduling/
[Qiufang] Fixed.
- for discard-action, is there a possibility for creating new actions in future 
or these two are the only ones? I am asking to make sure that the choice of 
modeling this as enum is correct or not.
[Qiufang] The latest version has used identityref to not restrict any future 
actions being defined. Thanks.
- In these lists "leaf-list date-times" and "leaf-list dates", is there any 
ordering constraint that should be added explicitly in text?
[Qiufang] Note that we simplify the definition now and remove the leaf-list 
date-times and dates definition, but we do have the list period and 
period-timeticks, once valid entries are added, they will work as repeating 
occurrences, regardless of ordering. Make sense?
- Section 3.4 needs more descriptive text for period and timeticks. The yang 
module has a long must statement for verification that should be explained here 
in text.
[Qiufang] The period and timeticks are now defined in 2 groupings to facilitate 
human readability and machine readability in section 3.6 and section 3.7, 
respectively. Some explanations are also added. Please review it and let us 
know if you still think it unclear.
- Section 3.5 needs more descriptive text for by* leaves -> "An array of the 
"bysecond" (or "byminut", "byhour") specifies a list of seconds within a minute 
(or minutes within an hour, hours of the day)." The examples in the appendix 
gave some hints but the description should be clearer.
[Qiufang] Sure, some examples have been given in the descriptive text to help 
understand the parameters, which is now in Section 3.8. Please let us know if 
you still think it unclear.
- s/byminut/byminute/
[Qiufang] Fixed.
  - Appendix A.1, the text says end date is Dec 31, 2027 but the JSON 
says 1st Dec - "2027-12-01T18:00:00Z"
[Qiufang] Good catch! Fixed now.
  - Appendix A.2, the text says Dec 1, 2025 but the example says 1st 
Nov - "2025-11-01T15:00:00"
[Qiufang] Fixed! Thanks a lot.

Thanks!
Dhruv

Best Regards,
Qiufang

On Tue, Mar 26, 2024 at 9:20 PM Kent Watsen 
mailto

Re: [netmod] Adoption call for draft-ma-opsawg-schedule-yang-04

[maqiufang (A)]

Hi, all,

As a co-author, I support the adoption of this work. It is separated from 
another WG item in OPSAWG because of its wide applicability.

The groupings defined in this draft now has a couple of consumers, the authors 
believe different work related to scheduling contexts can benefit from such a 
common basic definition.

Best Regards,
Qiufang

-Original Message-
From: netmod  On Behalf Of Kent Watsen
Sent: Tuesday, March 26, 2024 11:50 PM
To: netmod@ietf.org
Subject: [netmod] Adoption call for draft-ma-opsawg-schedule-yang-04

NETMOD WG,

This email begins a 2-week adoption poll for: 

A Common YANG Data Model for Scheduling
https://datatracker.ietf.org/doc/draft-ma-opsawg-schedule-yang

PS: This draft moved from OPSAWG to NETMOD

There is no known IPR on this draft:


https://mailarchive.ietf.org/arch/msg/netmod/mg1KP3m6bCSXh-3N-YKLvEb_udk/

Please voice your support or technical objections to adoption on the list by 
the end of the day Apr 10 (any time zone).

Thank you,
Kent (as co-chair)

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

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

Re: [netmod] IPR Call on draft-ietf-netmod-system-config-05

[maqiufang (A)]

Hi, Kent,

No, I'm not aware of any IPR that applies to this draft.

Best Regards,
Qiufang
From: Kent Watsen [mailto:kent+i...@watsen.net]
Sent: Tuesday, March 26, 2024 9:31 AM
To: maqiufang (A) ; Qin Wu ; 
Chongfeng Xie 
Cc: netmod@ietf.org
Subject: IPR Call on draft-ietf-netmod-system-config-05

Authors, Contributors, WG,

As a prerequisite for the WGLC on this document:

System-defined Configuration
https://datatracker.ietf.org/doc/draft-ietf-netmod-system-config/

Are you aware of any IPR that applies to draft identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft”
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules”
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate.

If you are listed as a document author or contributor please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author.

Also please send the response to the list above, and not unicast it.

PS: Currently no IPR is filed for this draft:
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-netmod-system-config.


Thanks.
Kent Watsen (as co-chair)


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

Re: [netmod] IPR Call on draft-ma-opsawg-schedule-yang-04

[maqiufang (A)]

Hi, Kent,

No, I'm not aware of any IPR that applies to this draft.

Best Regards,
Qiufang
From: Kent Watsen [mailto:kent+i...@watsen.net]
Sent: Tuesday, March 26, 2024 7:45 AM
To: maqiufang (A) ; Qin Wu ; Mohamed 
Boucadair ; Daniel King 
Cc: netmod@ietf.org
Subject: IPR Call on draft-ma-opsawg-schedule-yang-04

[This draft moved from OPSAWG to NETMOD]


Authors, Contributors, WG,

As a prerequisite for the adoption on this document:

A Common YANG Data Model for Scheduling
https://datatracker.ietf.org/doc/draft-ma-opsawg-schedule-yang/

Are you aware of any IPR that applies to draft identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft”
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules”
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate.

If you are listed as a document author or contributor please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author.

Also please send the response to the list above, and not unicast it.

PS: Currently no IPR is filed for this draft: 
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ma-opsawg-schedule-yang


Thanks.
Kent Watsen (as co-chair)

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

Re: [netmod] Draft IETF 119 NETMOD Agenda posted

[maqiufang (A)]

Hi, Jan, all

It seems that we need to revisit what we have agreed at the interim. Please see 
my reply below inline.
From: Jan Lindblad (jlindbla) [mailto:jlind...@cisco.com]
Sent: Wednesday, March 13, 2024 1:03 AM
To: Kent Watsen 
Cc: maqiufang (A) ; netmod@ietf.org
Subject: Re: [netmod] Draft IETF 119 NETMOD Agenda posted

Kent,

Hi Jan, you attended the Interim on Jan 23, and didn’t object to the Minutes 
[1] that say:

 The consensus in the room was a new "Option 4" - i.e., 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.

Has something changed since then?

[1] 
https://datatracker.ietf.org/doc/minutes-interim-2024-netmod-01-202401231400/

Thanks for keeping me honest :-) Nothing has changed, and if everyone agrees 
that 7950 and 8342 language prevail (i.e. running always valid as well as 
intended always valid), I'm probably ok. I wasn't sure that was the case? But 
if we all agree with this, maybe stating just that wouldn't be a bad thing? 
Just so that this is perfectly clear now and in the future.
[Qiufang] I think what has already been stated in 7950 and 8342 is still the 
case now, and this draft is not going to change it or make any updates about 
this point. So we won’t repeat what has already been said in other RFCs, and 
thus rely on 7950 and 8342 at this point. Is there any issue you see with this 
handling?
I am not sure what is stated in 8342 now is perfectly clear, at the interim we 
had on Jan 23, I (and also other folks) suggested we may need to update 8342 to 
make some clarifications on the point of validity of  alone, and we 
agreed to hold this as a YANG-next issue and discuss it till later. This makes 
sense to me, as I think it is a fundamental but separate issue and really not 
specific to system config. Thoughts?
I'm not against discussing changes in this area, as long as the fundamental 
values of YANG are preserved and our mechanisms are clearly defined.
[Qiufang] Sure, see my comments above. I am not sure what the discussion would 
end up with when we come to yang-next, but I absolutely agree with you 
fundamental values of NC/YANG should never be broken.

Best Regards,
/jan

Best Regards,
Qiufang
On Mar 12, 2024, at 12:15 PM, Jan Lindblad (jlindbla) 
mailto:jlindbla=40cisco@dmarc.ietf.org>>
 wrote:

Qiufang,

I'm sorry to say I'm strongly against WGLC at this time because of point #2 
below.

One of the great contributions to network automation that YANG has brought is 
that clients now have a fair chance at computing a desired configuration change 
for a network element. Maybe we need to develop a more elaborate model for 
configuration consistency relative today's "The running configuration datastore 
MUST always be valid", but have I trouble with us stirring up multiple 
interpretations and then staying silent. That's not the way to build 
interoperability.

   IMO we need to sort out what the rules are before we come close to 
WGLC, or else the grief outweighs the gain.

Best Regards,
/jan


On 12 Mar 2024, at 03:44, maqiufang (A) 
mailto:maqiufang1=40huawei@dmarc.ietf.org>>
 wrote:

Hi, chairs,

For system-config draft 
(https://datatracker.ietf.org/doc/draft-ietf-netmod-system-config/), the 
authors have submitted a new version to reflect the outcome of the interim, the 
main updates are following:
1.  Address the "origin" issue
a.   The current document explicitly states that system configuration 
copied from  into  have its origin value being reported as 
"intended" and update the examples accordingly
b.  Also, update the definition of "intended" origin identity in 8342 to 
allow a subset of configuration in  to use "system" as origin value
c.   The current document states data migration is out-of-scope except that 
gives a couple of implementation examples in section 4.2 (please feel free to 
propose text if you have better suggestion)
2.  validity of  alone
a.   The current document is silent on this point. Related statements which 
requires referenced system nodes must be copied into  are removed.
3.  Other updates
a.   Usage examples refinement, e.g., fix validation errors, remove 
redundancy for conciseness

There is currently no open issues, thus the authors believe this draft is ready 
for WGLC, but this might be worth a broad review on the mailing list.

Best Regards,
Qiufang
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Lou Berger
Sent: Friday, March 8, 2024 9:44 PM
To: NETMOD WG mailto:netmod@ietf.org>>
Cc: netmod-cha...@ietf.org<mailto:netmod-cha...@ietf.org>
Subject: Re: [netmod] Draft IETF 119 NETMOD Agenda posted


**IMPORTANT**

Authors of WG documents,

If your document has not yet been submitted to the IESG for publication *and* 

Re: [netmod] Draft IETF 119 NETMOD Agenda posted

[maqiufang (A)]

Hi, chairs,

For system-config draft 
(https://datatracker.ietf.org/doc/draft-ietf-netmod-system-config/), the 
authors have submitted a new version to reflect the outcome of the interim, the 
main updates are following:

1.  Address the "origin" issue

a.   The current document explicitly states that system configuration 
copied from  into  have its origin value being reported as 
"intended" and update the examples accordingly

b.  Also, update the definition of "intended" origin identity in 8342 to 
allow a subset of configuration in  to use "system" as origin value

c.   The current document states data migration is out-of-scope except that 
gives a couple of implementation examples in section 4.2 (please feel free to 
propose text if you have better suggestion)

2.  validity of  alone

a.   The current document is silent on this point. Related statements which 
requires referenced system nodes must be copied into  are removed.

3.  Other updates

a.   Usage examples refinement, e.g., fix validation errors, remove 
redundancy for conciseness

There is currently no open issues, thus the authors believe this draft is ready 
for WGLC, but this might be worth a broad review on the mailing list.

Best Regards,
Qiufang
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Lou Berger
Sent: Friday, March 8, 2024 9:44 PM
To: NETMOD WG 
Cc: netmod-cha...@ietf.org
Subject: Re: [netmod] Draft IETF 119 NETMOD Agenda posted


**IMPORTANT**

Authors of WG documents,

If your document has not yet been submitted to the IESG for publication *and* 
your draft is not on the agenda, please either:
(a) request to present status or
(b) send email to the list summarizing status by end of day (any TZ) Friday, 
March 15.

In either case, please include recent changes, open issues, plan to resolve 
open issues/complete the document.

Thank you!

Lou (and Kent)
On 3/7/2024 3:53 PM, Jason Sterne (Nokia) wrote:

Hello NETMOD WG,



A draft NETMOD agenda for IETF 119 has been published. Please review and let 
the chairs know if any changes are needed or additional topics should be 
covered.



The agenda is pasted below, but here's the link to the always-current version: 
https://datatracker.ietf.org/meeting/119/materials/agenda-119-netmod



Presenters: please provide slides to 
netmod-cha...@ietf.org no later than Sunday 
March 17 (any time zone).

Thanks,
Jason (+ chairs Kent and Lou)

Draft Agenda for the NETMOD 119 WG Session

https://datatracker.ietf.org/meeting/119/materials/agenda-119-netmod
https://datatracker.ietf.org/meeting/119/session/netmod

Session:

Thursday, March 21, 2024
13:00-15:00 Brisbane (Australia - Eastern Time)
03:00-05:00 UTC
23:00-01:00 Wednesday March 20 America - Eastern Time
https://www.timeanddate.com/worldclock/converter.html?iso=20240321T03&p1=47

Room: M2 https://datatracker.ietf.org/meeting/119/floor-plan?room=m2

WG Chairs:

Lou Berger (lberger at labs dot net)
Kent Watsen (kent plus ietf at watsen dot net)

WG Secretary

Jason Sterne (jason dot sterne at nokia dot com)

Available During Session:

MeetEcho: https://meetings.conf.meetecho.com/ietf119/?session=31987
Onsite tool: https://meetings.conf.meetecho.com/onsite119/?session=31987
Audio Only: https://mp3.conf.meetecho.com/ietf119/31987.m3u

Available During and After Session:

Notes: https://notes.ietf.org/notes-ietf-119-netmod?both
Slides: https://datatracker.ietf.org/meeting/119/session/netmod
Zulip (chat): https://zulip.ietf.org/#narrow/stream/126-netmod/topic/ietf-119
Drafts (TGZ): https://datatracker.ietf.org/meeting/119/agenda/netmod-drafts.tgz
Drafts (PDF): https://datatracker.ietf.org/meeting/119/agenda/netmod-drafts.pdf
Datatracker: https://datatracker.ietf.org/group/netmod/about/
ICS: https://datatracker.ietf.org/meeting/119/session/31987.ics

Available After Session:

Recording: http://www.meetecho.com/ietf119/recordings#NETMOD
Jabber Logs: https://www.ietf.org/jabber/logs/netmod

1) Session Intro & WG Status (10 min)

Presenter: Chairs

Chartered items:
2) YANG Versioning Update (40 min)

Presenter: Rob Wilton and Joe Clarke
Draft: 
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-module-versioning-11
Draft: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-semver-14

Non-Chartered items:
3) Validating anydata in YANG Library context (10 min)

Presenter: Ahmed Elhassany
Draft: https://datatracker.ietf.org/doc/draft-aelhassany-anydata-validation-00

4) Philatelist and YANG time-series db (10 min)

Presenter: Jan Lindblad
Draft: https://datatracker.ietf.org/doc/draft-lindblad-tlm-philatelist-00
Draft: https://datatracker.ietf.org/doc/draft-kll-yang-label-tsdb-00

5) A YANG model for Device Power Management (10 min)

Presenter: Tony Li
Draft: https://datatracker.ietf.org/doc/draft-li-ivy-power-01

6) YANG Full Embed (10 min)

Presenter: Jean Quilbeuf or Benoir Claise
Draft: https://datatracker.ietf.org/doc/draft-jouqui-netmod-yang-full-include-01

7)

Re: [netmod] Adoption call for draft-ma-netmod-immutable-flag-09

[maqiufang (A)]

Thanks chairs. We will upload the renamed draft when the submission window is 
reopened. Thanks all for your support and valuable comments, the authors will 
address them in a new version (as well as comments received from the interim 
discussion).

Best Regards,
Qiufang //co-author

From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Kent Watsen
Sent: Tuesday, March 12, 2024 6:24 AM
To: netmod@ietf.org
Subject: Re: [netmod] Adoption call for draft-ma-netmod-immutable-flag-09

WG,

This adoption poll succeeded.Following the unanimous-results from the 
interim 
(https://mailarchive.ietf.org/arch/msg/netmod/SqzLjhKcjT4dfdSLGdyuycPpiEE/), 
all responses were favorable and, importantly, there were no objections.


Authors,

Please rename this draft (the -09 version) to 
"draft-ietf-netmod-immutable-flag-00" and upload to data tracker.  Any 
adoption-comments should be addressed in a -01 version.


No IPR was reported:  
https://mailarchive.ietf.org/arch/msg/netmod/g_Rh24gXHZcfTUXDo0xZ-sXK-vU/


Thanks,
Kent and Lou




On Feb 22, 2024, at 12:41 PM, Kent Watsen 
mailto:kent+i...@watsen.net>> wrote:

NETMOD WG,

This email begins a 2-week adoption poll for:

YANG Metadata Annotation for Immutable Flag

https://datatracker.ietf.org/doc/html/draft-ma-netmod-immutable-flag-09

There is no known IPR on this draft:


https://mailarchive.ietf.org/arch/msg/netmod/g_Rh24gXHZcfTUXDo0xZ-sXK-vU/

Please voice your support or technical objections to adoption on the list by 
the end of the day Mar 7 (any time zone).

PS: This draft was discussed in our recent Interim, where a show-of-hands hands 
showed unanimous support for adoption.

Thank you,
Kent (as co-chair)

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

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

Re: [netmod] Next steps for draft-ietf-netmod-rfc8407bis

[maqiufang (A)]

Hi, Med, Kent, all


2) In the Security Considerations section, the template should be amended to 
have the following paragraph:

 Please be aware that this YANG module uses groupings from other 
YANG
 modules that define nodes that may be considered sensitive or 
vulnerable
 in network environments. Please review the Security Considerations 
for
 dependent YANG modules for information as to which nodes may be
 considered sensitive or vulnerable in network environments.

[Med] We need to be careful for this one as the document that defines the 
grouping may not include that analysis (because those are not used as data 
nodes). Here is a proposal for discussion:

NEW:

==
   -- if your YANG module reuses groupings from other modules and
   -- the document that specifies these groupings also
   -- includes those as data nodes, then add this text to remind
   -- the specific sensitivity or vulnerability of reused nodes.

This YANG module uses groupings from other YANG modules that
define nodes that may be considered sensitive or vulnerable
in network environments. Refer to the Security Considerations
of  for information as to which nodes may
be considered sensitive or vulnerable in network environments.

  -- if your YANG module does not define any data nodes, then
  -- add the following text

The YANG module defines a set of identities, types, and
groupings. These nodes are intended to be reused by other YANG
modules. The module by itself does not expose any data nodes that
are writable, data nodes that contain read-only state, or RPCs.
As such, there are no additional security issues related to
the YANG module that need to be considered.

Modules that use the groupings that are defined in this document
should identify the corresponding security considerations. For
example, reusing some of these groupings will expose privacy-related
information (e.g., 'node-example').
===
[Qiufang]
In addition to the cases above, for YANG modules that reuse groupings from 
other modules
and expose data nodes that have security considerations as a result, probably 
it’s also
worth mentioning that “
  This YANG module uses groupings from other YANG modules that
   define nodes that may be considered sensitive or vulnerable
  in network environments.” and followed by a list of data nodes exposed 
and identified as sensitive,
those nodes are defined in the grouping, thus it might be slightly different 
from what the
template has stated in the current version.


Best Regards,
Qiufang

On Feb 28, 2024, at 4:51 AM, 
mohamed.boucad...@orange.com wrote:

Hi all,

I think that this version is ready for the WGLC.

The document fully covers the items promised when requesting adoption [1]. As 
listed in the ACK section, we also solicited and integrated feedback from many 
yangdoctors, solicited SAAG WG to review the security text, etc. Refer to 1.1 
for a comprehensive list of the changes.

Cheers,
Med

[1] Slide#7 of 
https://datatracker.ietf.org/meeting/117/materials/slides-117-netmod-7-guidelines-for-authors-and-reviewers-of-documents-containing-yang-data-models-00

-Message d'origine-
De : I-D-Announce 
mailto:i-d-announce-boun...@ietf.org>> De la 
part de
internet-dra...@ietf.org
Envoyé : mercredi 28 février 2024 10:01
À : i-d-annou...@ietf.org
Cc : netmod@ietf.org
Objet : I-D Action: draft-ietf-netmod-rfc8407bis-09.txt

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

  Title:   Guidelines for Authors and Reviewers of Documents
Containing YANG Data Models
  Authors: Andy Bierman
   Mohamed Boucadair
   Qin Wu
  Name:draft-ietf-netmod-rfc8407bis-09.txt
  Pages:   84
  Dates:   2024-02-28

Abstract:

  This memo provides guidelines for authors and reviewers of
  specifications containing YANG modules, including IANA-maintained
  modules.  Recommendations and procedures are defined, which are
  intended to increase interoperability and usability of Network
  Configuration Protocol (NETCONF) and RESTCONF protocol
  implementations that utilize YANG modules.  This document obsoletes
  RFC 8407.

  Also, this document updates RFC 8126 by providing additional
  guidelines for writing the IANA considerations for RFCs that
specify
  IANA-maintained modules.

The IETF datatracker status page for this Internet-Draft is:
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
tracker.ietf.org%2Fdoc%2Fdraft-ietf-netmod-
rfc8407bis%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C51672231
30c943a5a4c608dc383bce6b%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C
638447076716455966%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo
iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=s5VX9Hb%2Fl
P9v5QurysF

Re: [netmod] Adoption call for draft-ma-netmod-immutable-flag-09

[maqiufang (A)]

Hi, Chair, all

As a co-author, I support the adoption of this work. This proposal is 
complementary to the system-config work, the discussion (which the authors will 
incorporate in a future version) at the interim allows it to be better 
accomplished.

I believe this document has great maturity now to move forward.

Best Regards,
Qiufang

From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Kent Watsen
Sent: Friday, February 23, 2024 1:42 AM
To: netmod@ietf.org
Subject: [netmod] Adoption call for draft-ma-netmod-immutable-flag-09

NETMOD WG,

This email begins a 2-week adoption poll for:

YANG Metadata Annotation for Immutable Flag

https://datatracker.ietf.org/doc/html/draft-ma-netmod-immutable-flag-09

There is no known IPR on this draft:


https://mailarchive.ietf.org/arch/msg/netmod/g_Rh24gXHZcfTUXDo0xZ-sXK-vU/

Please voice your support or technical objections to adoption on the list by 
the end of the day Mar 7 (any time zone).

PS: This draft was discussed in our recent Interim, where a show-of-hands hands 
showed unanimous support for adoption.

Thank you,
Kent (as co-chair)

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

[netmod] FW: I-D Action: draft-ietf-netmod-system-config-05.txt

[maqiufang (A)]

Hi, all



This version reflects the outcome of the interim we had last month:

1.   the "origin" issue

* The current document explicitly states that system configuration 
copied from  into  have its origin value being reported as 
"intended" and update the examples accordingly

* Also, update the definition of "intended" origin identity in 8342 to 
allow a subset of configuration in  to use "system" as origin value

* The current document states data migration is out-of-scope except 
that gives a couple of implementation examples in section 4.2 (please feel free 
to propose text if you have better suggestion)

2.   validity of  alone

* The current document is silent on this point. Related statements 
which requires referenced system nodes must be copied into  are 
removed.

3.   Other updates

* Usage examples refinement, e.g., fix validation errors, remove 
redundancy for conciseness



The authors believe all open issues have been resolved now and thus ready for 
WGLC, but would really also appreciate any review and feedback from the WG.

Thanks a lot!



Best Regards,

Qiufang



-Original Message-
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of 
internet-dra...@ietf.org
Sent: Wednesday, February 21, 2024 4:35 PM
To: i-d-annou...@ietf.org
Cc: netmod@ietf.org
Subject: [netmod] I-D Action: draft-ietf-netmod-system-config-05.txt



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



   Title:   System-defined Configuration

   Authors: Qiufang Ma

Qin Wu

Feng Chong

   Name:draft-ietf-netmod-system-config-05.txt

   Pages:   41

   Dates:   2024-02-21



Abstract:



   This document defines how a management client and server handle YANG-

   modeled configuration data that is defined by the server itself.  The

   system-defined configuration can be referenced (e.g. leafref) by

   configuration explicitly created by a client.



   The Network Management Datastore Architecture (NMDA) defined in RFC

   8342 is updated with a read-only conventional configuration datastore

   called "system" to hold system-defined configuration.



   As an alternative to clients explicitly copying referenced system-

   defined configuration into the target configuration datastore (e.g.,

   ) so that the datastore is valid, a "resolve-system"

   parameter is defined to allow the server acting as a "system client"

   to copy referenced system nodes automatically.  This solution enables

   clients manipulating the target configuration datastore (e.g.,

   ) to reference nodes defined in , override system-

   provided values, and configure descendant nodes of system-defined

   configuration.



   This document updates RFC 8342, RFC 6241, RFC 8526 and RFC 8040.



The IETF datatracker status page for this Internet-Draft is:

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



There is also an HTMLized version available at:

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



A diff from the previous version is available at:

https://author-tools.ietf.org/iddiff?url2=draft-ietf-netmod-system-config-05



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 mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] IPR poll for draft-ma-netmod-immutable-flag-09

[maqiufang (A)]

Hi, chairs, all

No, I am not aware of any IPR that applies to this draft.

Best Regards,
Qiufang



发件人：Kent Watsen mailto:kent+i...@watsen.net>>
收件人：maqiufang (A) mailto:maqiufa...@huawei.com>>;Qin Wu 
mailto:bill...@huawei.com>>;Balazs Lengyel 
mailto:balazs.leng...@ericsson.com>>;Hongwei Li 
mailto:flycool...@gmail.com>>
抄 送：netmod mailto:netmod@ietf.org>>
时 间：2024-02-13 06:50:35
主 题：IPR poll for draft-ma-netmod-immutable-flag-09

Authors, Contributors, WG,

As a prerequisite for the adoption on this document:

YANG Metadata Annotation for Immutable Flag
https://datatracker.ietf.org/doc/html/draft-ma-netmod-immutable-flag-09

Are you aware of any IPR that applies to draft identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft”
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules”
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate.

If you are listed as a document author or contributor please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author.

Also please send the response to the list above, and not unicast it.

FWIW, currently, no IPR is filed for this draft: 
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ma-netmod-immutable-flag

Thanks.
Kent (and Lou)
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] MUST offline-validation of alone be required? possible solution and further discussion

[maqiufang (A)]

Hi, all

I want to bring up a key issue that has been discussed before but hasn't really 
been agreed upon: MUST offline-validation of  alone be required?

The question behind this issue is about: must referenced system config always 
be copied into  to satisfy referential integrity constraints, or 
 is implicitly valid if  is valid by merging  and 
 (after config transformation like removal of inactive config and 
expansion of templates) to create its contents,  alone doesn't have to 
be offline valid.

It feels like the WG has a mixed viewpoints, and I would like to find a 
solution and seek convergence here. Actually I am thinking, instead of directly 
stating in the draft that any referenced system config must be contained in 
, we can point to RFC 7950 and RFC 8342 and state that  MUST 
always be a valid configuration data tree. So that we just leave it there and 
interpretations may vary. Anyway, the client can always explicitly copy 
referenced system config into  or use the "resolve-system" parameter 
if an offline-validation of  is needed.

If we can reach an agreement on this handling, I believe then we can move on.

One the other side, I also understand that we should not shy away from this 
issue and need effectively work it out. Below are some thoughts and inputs from 
the WG:


* Yes,  alone must be offline valid

o   Pros

?  Clients can easily offline validate  without offline merging 
 and  (which would bring extra complexity to clients)

o   Cons:

?  Painful copy is needed.

?  Need to deal with the scenario where the system config has updated and a 
stale copy is still in 

* No, Offline validation of  MAY consider other datastores as 
well, two options:

o   Treat it as a bug-fix in existing RFCs

?  Cons: might break legacy clients and existing tool chains

o   Wait for a new version of YANG/NC/RC

?  Cons: might incur delay

Any further thoughts on this? Comments and suggestions would be much 
appreciated.


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

Re: [netmod] Adoption poll for draft-ma-netmod-immutable-flag-08

[maqiufang (A)]

Hi, Jürgen

Thanks a lot for the thorough review, please see my reply inline...

-Original Message-
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Jürgen Sch?nw?lder
Sent: Saturday, September 9, 2023 5:09 AM
To: Jan Lindblad 
Cc: netmod@ietf.org
Subject: Re: [netmod] Adoption poll for draft-ma-netmod-immutable-flag-08

I have read draft-ma-netmod-immutable-flag-08 and my concerns remain. While I 
do see some valid use cases for this, I am concerned that this mechanism will 
be abused. The writing suggests that the server can dynamically decide what it 
considers immutable. If true, its a small step to have the server's decision 
depend directly or indirectly on other edits done by a client or on the 
operational state (the later is even described in the draft).
[Qiufang] I am sorry, but could you please give me more hints about how this 
mechanism could be abused? Is this related to the UC A.3? Because I think in 
-08, the authors have made an effort to make immutability to be independent of 
other edits done by a client or the operational state, we want immutability to 
be quite static based on the similar comments made by other folks, and this is 
already indicated in the document, e.g., sec 1.2:
" The immutability and configured value of an
   existing node must only change by software upgrade or hardware
   resource/license change. "
I am not sure which part of the draft has resulted in the understanding of "the 
server can dynamically decide what it considers immutable", could you point it 
out so that the authors can make further progress?

Thinking loud: If we can work out an immutable mechanism and we can then drop 
the system datastore, perhaps this is worth it. I do not see why we need a 
system datastore if we allow servers to add immutable data to . 
[Qiufang] We are kind of touching system-config draft here, which defines a 
dedicated configuration datastore to hold system configuration which is either 
modifiable or non-modifiable (see 
https://www.ietf.org/archive/id/draft-ietf-netmod-system-config-02.html#name-modifying-overriding-system).
 While immutable mechanism makes it possible for the client to understand which 
system configuration can be overridden and which is not. Yes, we do allow 
servers to add system configuration to  but this is based on the 
premise: 1) the system configuration is referenced in  and all 
referential integrity constraints are need to be satisfied in ;2) the 
client has used a flag (we define it as "resolve-system" parameter) in the 
 request so that servers populating configuration into  
won’t be surprising for the client. 
System configuration will not be copied into  unless being referenced, 
this is regardless of the immutability of it. The system datastore and 
immutable mechanism can complement each other, but I think there is no function 
overlap. 

On the other hand,  was originally designed to be fully client 
controlled. The notion of server supplied immutable data nodes in  
breaks this model. The other model is to have immutable data only in something 
like  and then that data gets merged into  somehow. It seems 
the WG needs to settle what the right model is, for me the documents are still 
confusing and I am concerned about increasing client complexity and lowering 
interoperability. 
[Qiufang] I totally agree with you that  should be fully controlled by 
the client, actually, that is the reason why we'd like to define a 
"resolve-system" parameter to resolve references and the server should never 
write configuration into  unless this parameter is used. And there is 
indeed still a key issue in the system-config draft regarding whether we want 
 to always be valid, i.e., must all the referenced system 
configuration always be copied into , and we can discuss it in a 
separate thread.
But I don’t think this draft will increase client complexity and lower 
interoperability, as we emphasize in the draft, it is already the case that 
immutable configuration exists in the real world, here we define some mechanism 
to improve its visibility to the clients. The client even without the knowledge 
of immutable extension/metadata annotation, can still send requests attempting 
to modify immutable configuration as it did before, and the server can still 
reject the request. Things just don’t get any worse, no extra complexity is 
introduced.

If the  datastore and immutable flags are designed to work tightly 
together, then we should be explicit about this and depending on how close they 
are tied together, perhaps even throw them into a single document.
[Qiufang] I am not sure we can put it like "they two are designed to work 
tightly together", because I'd rather to see immutable flag can even work 
without  datastore. If there is not a system datastore, immutable 
system configuration could also be present in  or somewhere else. 
Maybe another reason we would like to document these two separately to keep 
each clean and concise. Tha

Re: [netmod] Regarding IPR on draft-ma-netmod-immutable-flag-08

[maqiufang (A)]

Hi, chair, all

No, I'm not aware of any IPR that applies to this draft.

Best Regards,
Qiufang

From: Kent Watsen [mailto:kent+i...@watsen.net]
Sent: Tuesday, August 22, 2023 9:47 PM
To: maqiufang (A) ; Qin Wu ; Balazs 
Lengyel ; Hongwei Li 
Cc: netmod@ietf.org
Subject: Regarding IPR on draft-ma-netmod-immutable-flag-08

Authors, Contributors, WG,

As a prerequisite for the adoption on this document:

Are you aware of any IPR that applies to draft identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft”
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules”
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate.

If you are listed as a document author or contributor please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author.

Also please send the response to the list above, and not unicast it.

Thanks.
Kent (as co-chair)


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

Re: [netmod] New Version Notification for draft-ma-netmod-immutable-flag-07.txt

[maqiufang (A)]

Hi, Kent


Cherry picking a few items below.


[Rob Wilton (rwilton)]
I think that the document is unclear about how it interplays with the system 
datastore, e.g., I find very few references to the system datastore, so I think 
that it would be helpful for that to be clarified.
[Qiufang] Sure. That’s true, most of the references to system datastore 
document only appear in the use case appendix, I agree that this should be more 
explicit, to point out that only the server can create immutable configuration, 
and thus immutable data appears in (if exists). A client may create a 
same value of immutable node as in  (e.g., to fulfil leafref 
constraints), but is not allowed to modify or override 
(https://www.ietf.org/archive/id/draft-ietf-netmod-system-config-01.html#section-5.4)
 immutable node with different values. Will clarify in the next version.
But I think we don’t necessarily want immutable flag to be coupled with system 
datastore, that is to say, even a server doesn’t implement a  
datastore, it could still be possible to have non-modifiable system 
configuration somewhere (e.g., in ), and thus an immutable flag 
could be helpful in this case. Make sense?

The WG extracted the immutable-flag idea out of, at that time, the 
“with-system” draft, for this reason.
Exactly. When we were discussing the “with-system” draft (about 2 years ago), 
we were trying to identify all categories of system configuration, like 
resource-dependent vs. resource-independent, applied-immediately vs. 
applied-after-referenced, deletable system config vs. non-deletable system 
config, modifiable system config vs. non-modifiable system config…
However, I only recall one case used for justification (see below).  It would 
be good to identify others cases.
Yes, your case provided blow is one of them, others I can recall are like, the 
well-known "interface problem" : The system configures an interface when it’s 
physically present with its name, ip-address, type, enabled, etc., the user is 
allowed to add, modify, and delete all descendant nodes but except the "name" 
and "type" leaf; the hidden and immutable junos-default group which contains 
system predefined system configuration for comment use; the immutable system 
capability related configuration (e.g., case in 
https://www.ietf.org/archive/id/draft-ma-netmod-immutable-flag-07.html#appendix-A.1).
The one case I recall, is when a device implements the concept of sub-devices, 
whereby NETCONF-clients connect to the sub-device, and have the illusion of 
being connected to a real device, using the same YANG and everything, just with 
lesser access.  For instance, the parent/host device may be able to set, e.g., 
the MTU on an interface shared with a sub-device, but the MTU value is 
immutable to sub-device NC-clients.

This validity of this case is questionable.  Specifically, that it is a case 
independent of system configuration at all.  It seems reasonable to opine that 
the MTU is, in fact, system configuration from the POV of the NC-client.



If this is the case, then I’m not sure that I understand the value of the 
“extension immutable”, can you give examples of where this would be useful 
please?
[Qiufang] The “extension immutable” is considered to be used if a particular 
data node is always considered to be immutable independent of any its 
instance(s).
A YANG extension makes immutability even visible for the client at 
implementation time (not just runtime), Therefore, the client has the 
opportunity to avoid error response in its NMS design/development time due to 
attempts to override immutable configuration.

We do have an open issue regarding should the "immutable" metadata annotation 
also be returned for nodes described as “extension immutable” so that there is 
a single source of truth.

Regarding the open-issue.  Food for thought.

Assuming a client supports servers implementing this YANG module, how often do 
we expect the client to request configuration (get-config) with the immutable 
annotation included?  Would it be all the time, or only when a server returns a 
write-access error?
I assume it won’t be too often, since the immutability must only change by 
software upgrade or license change?
Each time when above factors occur, a client may include a "with-immutable" 
parameter in its request to query the contents of  or , 
then understand what system configuration cannot be overridden.
Or simply do nothing, but query the immutability of certain system nodes until 
an RPC error returned.
What’s the overhead and does it matter?  Recall, the flag is hierarchal, so if 
returned for immutable nodes also set in the YANG module, via the extension 
statement, there’s a compression that occurs that may result in the overhead 
not being so bad.
By “compression”, you mean omission?
Indeed, the metadata annotation of immutability doesn’t have to be explicitly 
declared for every node, since most can be omitted by default inheriting the 
immutability of its par

[netmod] FW: I-D Action: draft-ietf-netmod-system-config-02.txt

[maqiufang (A)]

Hi, all



v-02 is available now, most of the update reflects comments raised by Jason 
(thank you Jason!), as well as some recent discussion happened on the list.

A diff compared from the previous version is available at:

https://author-tools.ietf.org/iddiff?url2=draft-ietf-netmod-system-config-02.





With the ongoing discussion of the issue "should referenced system 
configuration always be copied into ", there are some other notable 
issues which have already been touched on or recognized by other folks, the 
authors feel we might need more discussion:



* What if the system configuration is updated, and the stale copy 
is still present in ? What's the consequence?



The current document does not allow the configuration copied from  into 
 to be updated automatically if the configuration in  is 
updated. The intent is still not to surprise client with unexpected changes.



Notice that Kent was suggesting two options:"



1)  The system-draft says non-necessary fields MUST NOT be copied into 
.  This may be difficult to enforce, but I believe it's viable.


2)  The system-draft says that it is the server's responsibility to migrate 
the data in running/startup/candidate during a software update"

And also maybe option 3): the server updates the configuration in 
 to ensure consistence with what is in .






* Should the origin="system" be required for system configuration 
copied into ?



This affects the XML snippets example in sec.5.5.1 , the origin value of the 
key name of application "ftp" and "tftp" which is copied into  to 
fulfil leafref constraints.



There was a proposal to use origin="intended". But after think about it, 
basically when  is merged with  to become , 
configuration in  takes precedence over  if the node allows to 
be modified.

So origin="intended" seems no issue in this case.

But suppose the system defined node is immutable, a client writing a same value 
of that node in  will still cause it to appear in  with 
origin="intended"? that doesn't seem true since it's not really about 
"override".

I personally feel it better to use origin="system" for consistence, but would 
also welcome different opinions.

Thoughts?

Best Regards,
Qiufang





-Original Message-
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of 
internet-dra...@ietf.org
Sent: Tuesday, July 4, 2023 7:05 PM
To: i-d-annou...@ietf.org
Cc: netmod@ietf.org
Subject: [netmod] I-D Action: draft-ietf-netmod-system-config-02.txt





A New Internet-Draft is available from the on-line Internet-Drafts directories. 
This Internet-Draft is a work item of the Network Modeling

(NETMOD) WG of the IETF.



   Title   : System-defined Configuration

   Authors : Qiufang Ma

 Qin Wu

 Feng Chong

   Filename: draft-ietf-netmod-system-config-02.txt

   Pages   : 46

   Date: 2023-07-04



Abstract:

   This document describes how a management client and server handle

   YANG-modeled configuration data that is defined by the server itself.

   The system-defined configuration can be referenced (e.g. leafref) by

   configuration explicitly created by a client.



   The Network Management Datastore Architecture (NMDA) defined in RFC

   8342 is updated with a read-only conventional configuration datastore

   called "system" to hold system-defined configuration.  As an

   alternative to clients explicitly copying referenced system-defined

   configuration into the target configuration datastore (e.g.,

   ) so that the datastore is valid, a "resolve-system"

   parameter is defined to allow the server acting as a "system client"

   to copy referenced system-defined nodes automatically.  This solution

   enables clients manipulating the target configuration datastore

   (e.g., ) to overlay (e.g., copy system configuration using

   the same key value as in ) and reference nodes defined in

   , override values of configurations defined in , and

   configure descendant nodes of system-defined nodes.



   This document updates RFC 8342, RFC 6241, RFC 8526 and RFC 8040.



The IETF datatracker status page for this Internet-Draft is:

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



There is also an htmlized version available at:

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



A diff from the previous version is available at:

https://author-tools.ietf.org/iddiff?url2=draft-ietf-netmod-system-config-02



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 mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] New Version Notification for draft-ma-netmod-immutable-flag-07.txt

[maqiufang (A)]

Hi, Rob

Thanks for getting back to me,  please also see inline.
From: Rob Wilton (rwilton) mailto:rwil...@cisco.com>>
Sent: Saturday, July 1, 2023 1:09 AM
To: maqiufang (A) mailto:maqiufa...@huawei.com>>
Cc: Kent Watsen mailto:kent+i...@watsen.net>>; Jan 
Lindblad (jlindbla) mailto:jlind...@cisco.com>>; Jürgen 
Schönwälder 
mailto:jschoenwaelder@constructor.university>>;
 Andy Bierman mailto:a...@yumaworks.com>>; 
netmod@ietf.org<mailto:netmod@ietf.org>
Subject: RE: [netmod] New Version Notification for 
draft-ma-netmod-immutable-flag-07.txt

Hi Qiufang,

It may be the WG understanding has moved on, but the latest version of the 
document hasn’t quite caught up, or otherwise I don’t find it clear, or seem to 
take very different interpretation of it.
[Qiufang] I do think that the WG understanding has moved on, at least I assume 
now there is WG consensus to not support non-transactional APIs, yet I also 
understand it cannot just be the tacit understanding, but also need to be 
stated very clearly in the document. Sorry if it has caused any 
misunderstanding or confusion.
Please see inline … (this is all with reference to -07).


From: maqiufang (A) mailto:maqiufa...@huawei.com>>
Sent: 09 June 2023 16:39
To: Rob Wilton (rwilton) mailto:rwil...@cisco.com>>
Cc: Kent Watsen mailto:kent+i...@watsen.net>>; Jan 
Lindblad (jlindbla) mailto:jlind...@cisco.com>>; Jürgen 
Schönwälder 
mailto:jschoenwaelder@constructor.university>>;
 Andy Bierman mailto:a...@yumaworks.com>>; 
netmod@ietf.org<mailto:netmod@ietf.org>
Subject: RE: [netmod] New Version Notification for 
draft-ma-netmod-immutable-flag-07.txt

Hi, Rob

Thanks for sharing your concerns, but I think there might be some 
misunderstanding that needs to be clarified, please see my reply inline.

From: Rob Wilton (rwilton) [mailto:rwilton=40cisco@dmarc.ietf.org]
Sent: Friday, June 2, 2023 7:01 PM
To: Kent Watsen mailto:kent+i...@watsen.net>>; Jan 
Lindblad (jlindbla) mailto:jlind...@cisco.com>>; Jürgen 
Schönwälder 
mailto:jschoenwaelder@constructor.university>>;
 Andy Bierman mailto:a...@yumaworks.com>>
Cc: maqiufang (A) mailto:maqiufa...@huawei.com>>; 
netmod@ietf.org<mailto:netmod@ietf.org>
Subject: RE: [netmod] New Version Notification for 
draft-ma-netmod-immutable-flag-07.txt

Hi Kent, all,

Writing as a contributor, I still have strong concerns with this draft.

From a YANG architecture perspective, I believe that the contents of the 
running datastore should be entirely under the client’s control, and servers 
should accept any valid configuration, and be able to move from any valid 
configuration to any other valid configuration.  We also already have the 
server datastore draft that I think should be the mechanism to allow a server 
to include server-controlled configuration before it is merged with running and 
validated as intended, that is somewhat outside the client’s control.  I.e., I 
think that having a clean split of ownership and responsibilities between a 
running datastore (managed by the client) and other datastores (e.g., intended 
and system-controlled) managed by the server is a good clean architecture.
I agree with you that the client should have fully control over the contents of 
the running datasore, but I don't see this draft(-07) conflicting with that 
goal. Maybe we should make it more explicit in the document, but it is already 
the case the immutable configuration can only be created by the system (and 
present in )
[Rob Wilton (rwilton)]
I think that the document is unclear about how it interplays with the system 
datastore, e.g., I find very few references to the system datastore, so I think 
that it would be helpful for that to be clarified.
[Qiufang] Sure. That’s true, most of the references to system datastore 
document only appear in the use case appendix, I agree that this should be more 
explicit, to point out that only the server can create immutable configuration, 
and thus immutable data appears in (if exists). A client may create a 
same value of immutable node as in  (e.g., to fulfil leafref 
constraints), but is not allowed to modify or override 
(https://www.ietf.org/archive/id/draft-ietf-netmod-system-config-01.html#section-5.4)
 immutable node with different values. Will clarify in the next version.
But I think we don’t necessarily want immutable flag to be coupled with system 
datastore, that is to say, even a server doesn’t implement a  
datastore, it could still be possible to have non-modifiable system 
configuration somewhere (e.g., in ), and thus an immutable flag 
could be helpful in this case. Make sense?



E.g., section 1.2, starts with: “ The "immutable" concept defined in this 
document only documents existing write access restrictions to writable 
datastores.”, which I read as saying that the immutable flag is purely about 
// datastores because  and  are 
not

Re: [netmod] New Version Notification for draft-ma-netmod-immutable-flag-07.txt

[maqiufang (A)]

Hi, Jan

Thanks for supporting this work! Please see inline.
From: Jan Lindblad (jlindbla) [mailto:jlindbla=40cisco@dmarc.ietf.org]
Sent: Friday, June 2, 2023 10:23 PM
To: Kent Watsen mailto:kent+i...@watsen.net>>; maqiufang 
(A) mailto:maqiufa...@huawei.com>>
Cc: Jürgen Schönwälder 
mailto:jschoenwaelder@constructor.university>>;
 Andy Bierman mailto:a...@yumaworks.com>>; Rob Wilton 
(rwilton) mailto:rwil...@cisco.com>>; 
netmod@ietf.org<mailto:netmod@ietf.org>
Subject: Re: [netmod] New Version Notification for 
draft-ma-netmod-immutable-flag-07.txt

Kent, Quifang,

I support adoption of this work. It is an architecturally deep and important 
topic. I think a good amount of work remains before we reach consensus, and 
that it is important to get the details just right since this is going deep 
towards the roots of our vision.
Glad to know that;-)
I have some detailed comments below, but nothing that affects the adoption call.


On 1 Jun 2023, at 22:55, Kent Watsen 
mailto:kent+i...@watsen.net>> wrote:

Hi Quifang,

The latest update looks very good to me - IMO, ready for adoption.

Jan, Jurgen, Andy, Rob - can you confirm that your concerns have been addressed?

Thanks,
Kent

Quifang,

Thank you for the updated draft. I think each version is getting better :-) but 
I still have some comments.
Sure.
+ Section 1, Introduction

   Immutability is an existing model handling practice.  While in some

   cases it is needed, it also has disadvantages, therefore it MUST be

   avoided wherever possible.
While I strongly agree with the view stated here, I don't think we can have a 
MUST requirement on something so nebulous as "whenever possible". Change to 
SHOULD?
Happy to change to SHOULD.
+ Section 1.2, Applicability

   The immutability of data nodes

   is protocol and user independent.
I agree fully that the immutability concept should be protocol and user 
independent (i.e. works the same for both NC/RC/xC and all users). I would also 
like to add that immutability needs to be independent of operational state, 
i.e. that immutable nodes are immutable from time of creation and remain so for 
as long as they exist.
Thank you Jan for pointing this out. But I am unsure if the “operational state” 
here has the same meaning as in NMDA spec. My understanding is that you would 
like to mention immutability is unchanged in the node instance’s lifecycle, I 
think I agree with you. Do you think would it be okay to add the following 
sentence:
“It is also independent of the lifecycle of a node from time of creation to 
deletion.”
The immutability property and configured value of an existing node must only 
change by software update.
Sure, but would the configured value of an immutable node also changes by other 
conditions like license or hardware capability/resource changes?

+ Section 2, Solution overview

   However, the following operations SHOULD be allowed for immutable

   nodes:



   *  Use a create, update, delete/remove operation on an immutable node

  if the effective change is null.  E.g., if a leaf has a current

  value of "5" it should be allowed to replace it with a value of

  "5"



   *  Create an immutable data node with a same value that already

  exists in  or  (if exists) in order to e.g.,

  configure a mutable descendant or reference it in a "when", "must"

  or "leafref" expression.



   *  Delete an immutable data node from read-write configuration

  datastores (i.e., ,  and ) which do

  not prevent the data node still appearing in  or

   (if exists)
By the already established rules of 7950, I think the above statements are 
already MUST requirements. It may be good to clarify/restate that expectation 
here, but if so, I find it essential not to weaken the requirement to SHOULD 
(in the first cited line above) , but keep it MUST.
Okay, but it is not the intention to weaken the rules in the existing RFCs. Do 
you have any suggestions to rephrase these above statements?

+ Section 6.1, Definition

   Note that "immutable" metadata annotation is used to annotate data

   node instances.  A list may have multiple entries/instances in the

   data tree, "immutable" can annotate some of the instances as read-

   only, while others are read-write.
I think the immutable annotation on individual instances is useful, meaning 
those list instances would always have to be present. This is however getting 
very close to the edge for some of the deep no-nos for me. Let's say there is a 
management interface that always has to exist for the configuration to be 
valid. Annotating that with immutable seems ok. But if someone suggests that 
some of these must-exist list elements can vary over time, i.e. sometimes have 
to exist, sometimes not, then I'm out. Not supportive.
Let’s state in the document that “the existence of i

Re: [netmod] New Version Notification for draft-ma-netmod-immutable-flag-07.txt

[maqiufang (A)]

Hi, Rob

Thanks for sharing your concerns, but I think there might be some 
misunderstanding that needs to be clarified, please see my reply inline.

From: Rob Wilton (rwilton) [mailto:rwilton=40cisco@dmarc.ietf.org]
Sent: Friday, June 2, 2023 7:01 PM
To: Kent Watsen mailto:kent+i...@watsen.net>>; Jan 
Lindblad (jlindbla) mailto:jlind...@cisco.com>>; Jürgen 
Schönwälder 
mailto:jschoenwaelder@constructor.university>>;
 Andy Bierman mailto:a...@yumaworks.com>>
Cc: maqiufang (A) mailto:maqiufa...@huawei.com>>; 
netmod@ietf.org<mailto:netmod@ietf.org>
Subject: RE: [netmod] New Version Notification for 
draft-ma-netmod-immutable-flag-07.txt

Hi Kent, all,

Writing as a contributor, I still have strong concerns with this draft.

From a YANG architecture perspective, I believe that the contents of the 
running datastore should be entirely under the client’s control, and servers 
should accept any valid configuration, and be able to move from any valid 
configuration to any other valid configuration.  We also already have the 
server datastore draft that I think should be the mechanism to allow a server 
to include server-controlled configuration before it is merged with running and 
validated as intended, that is somewhat outside the client’s control.  I.e., I 
think that having a clean split of ownership and responsibilities between a 
running datastore (managed by the client) and other datastores (e.g., intended 
and system-controlled) managed by the server is a good clean architecture.
I agree with you that the client should have fully control over the contents of 
the running datasore, but I don't see this draft(-07) conflicting with that 
goal. Maybe we should make it more explicit in the document, but it is already 
the case the immutable configuration can only be created by the system (and 
present in ), other cases like the client creates a node instance but 
cannot modify that afterwards is the non-transactional behaviour we’ve 
discussed before and should be avoided. That said, only the server can 
create/update/delete immutable configuration, this has no impact to clients and 
 datastore by default. Only when the client would like to reference 
the immutable system configuration, will that configuration be copied and thus 
appears in . But by default, immutable configuration is only seen in 
 (if implements) and . Hopefully this clarifies.
I appreciate that not all servers allow clients to fully control their running 
configuration, but I think that a better solution (for management clients) so 
to encourage servers to migrate towards the goal of giving full ownership over 
running to the clients.  Hence, I’m particularly concerned about standardizing 
a YANG meta-data annotation that allows, and arguably even encourages, vendors 
or other SDOs to build immutable properties into their management models that 
breaks this goal.  I think that we need to be really careful here that we are 
not creating yet another fork of NETCONF/YANG with a fairly fundamentally 
different architecture to what we are currently aiming for.

As I mentioned above, I think it’s not our intention to break the goal of 
giving full ownership over running to the clients. It is still about the 
system-controlled configuration immutability declaration. This does not 
necessarily mean that we are encouraging such behaviour, the introduction 
section has also states that:

” Immutability is an existing model handling practice.  While in some
  cases it is needed, it also has disadvantages, therefore it MUST be
  avoided wherever possible.”
Would this be sufficient from your perspective?

I am somewhat more amenable to an annotation that indicates that if a 
particular leaf is modified it will potentially cause a more impactful change, 
by effectively causing a delete and re-add of the parent list/container 
(changing interface type could be an example of this).  But I don’t think that 
this stop clients from modifying the leaf to a new valid state, instead, the 
server should perform any necessary orchestration steps to apply the 
configuration rather than pushing that as extra orchestrations steps onto the 
client.  There is also part of me that questions how useful such an annotation 
or metadata would really be given that there are many other data nodes that 
have wide impact if they are modified.  So, from this perspective, I think that 
“immutable” is perhaps the wrong name.
After the previous discussion on the list, we were trying to avoid the 
non-transactional APIs, and now we are only targeting immutable configuration 
with the lifecycle totally driven by the system. So I tend to agree with your 
proposal to define a flag to indicate a leaf is modified will potentially cause 
the server to delete it and recreate with its parent node. And I also agree 
this should not be called “immutable” anymore. But that is not we are trying to 
achieve in the document now, and is not in the sc

Re: [netmod] New Version Notification for draft-ma-netmod-immutable-flag-07.txt

[maqiufang (A)]

Hi, Andy

Thanks for your feedback, please see my reply inline.

From: Andy Bierman [mailto:a...@yumaworks.com]
Sent: Friday, June 2, 2023 6:00 AM
To: Kent Watsen mailto:kent+i...@watsen.net>>
Cc: Jan Lindblad (jlindbla) mailto:jlind...@cisco.com>>; 
Jürgen Schönwälder 
mailto:jschoenwaelder@constructor.university>>;
 Rob Wilton (rwilton) mailto:rwil...@cisco.com>>; maqiufang 
(A) mailto:maqiufa...@huawei.com>>; 
netmod@ietf.org<mailto:netmod@ietf.org>
Subject: Re: [netmod] New Version Notification for 
draft-ma-netmod-immutable-flag-07.txt



On Thu, Jun 1, 2023 at 1:55 PM Kent Watsen 
mailto:kent%2bi...@watsen.net>> wrote:
Hi Quifang,

The latest update looks very good to me - IMO, ready for adoption.

Jan, Jurgen, Andy, Rob - can you confirm that your concerns have been addressed?



IMO the problem statement and solution are still rough and unclear.
The different behavior for each type of node made it even more unclear.
Could you please explain where you think is not clear enough? that would be 
much appreciated.
There is a useful improvement to configuration automation here, but it needs 
more work.
Thank you Andy, but beyond your comments below, please let us know what you 
think is left.
The problem is that sometimes the server does not allow certain 
edits to config=true nodes.
This can cause automated (or manual) edit requests to be rejected by the 
server, with no way
for the client to fix the edit request.
It seems that we are in agreement! I see no conflict or inconsistency between 
us.
For your information, the document already states:
   Clients may use "immutable" statements in the YANG, and annotations
   provided by the server, to know beforehand when certain otherwise
   valid configuration requests will cause the server to return an
   error.
I think you problem statement is another different way to express the 
motivation.
The edit operations 'add', 'modify', and 'delete' need more clarification.
I am not sure which part you are referring to. but I suppose you are targeting 
Sec.3.
If that’s the case, I am thinking maybe we can rephrase section 3.3~section3.6 
for clarity, e.g.,
Sec.3.3. the “container” statement:
OLD:
   When a container data node is immutable, its instance can neither be
   created nor removed.  Additionally, as with all interior nodes,
   immutability is recursively applied to descendants (see Section 4).
NEW:
When a container data node is immutable, its instance cannot change, unless the
descendant nodes override the inherited immutability property (see Section 4).

And explain above Sec.3.1 that “change” refers to the operations create, 
update, and delete.

If it is needed, maybe also explain the three operations like the following:
Create: the client adds a new data node instance to a configuration datastore
update: the client updates an existing data node instance in a configuration 
datastore
delete:  the client deletes a data node instance from a configuration datastore

Would this be suitable from your perspective?
There seem to be 3 usage modes that must be supported

-  The server provides the value, and the client does not provide it
-  The client provides a server-approved value that can not change
-  The client picks a value that cannot change

In the example in A.2, any of the 3 modes could apply to a client creating a 
new interface entry.
Could you please provide some detailed JSON or XML snippets about the example? 
I am not sure I’ve fully understand you all three usage modes.
Regarding the first usage mode, I assume you mean system-defined configuration, 
but if there is a reference to that system-provided node, it would still be 
needed to copy into .

In all cases it seems the intent is to allow the client to create an immutable 
node,
but not modify it.  It can only be deleted if a mutable ancestor is being 
deleted.
This is something we talked about on the mailing list before, there was a big 
discussion about the non-transactional cases.
Configuration that cannot change once created by the client and needs to be 
deleted first with its ancestor node and then recreate by the client, requires 
a transaction to be split into two transactions, thus lost the desire to move 
from one valid configuration to another in a single transaction. There was some 
concern thus the WG decides that this is something that this draft should not 
support.
It is not clear how inherited immutable flag values work, especially in 
conjunction with NACM.
Could you please expand on this comment? To me, I think immutable flag should 
work independently of NACM.
YumaPro has supported the "user-write" extension for many years for this 
purpose.
https://docs.yumaworks.com/en/latest/yangauto/builtin-yang-extensions.html#ncx-user-write
Yes, and a lot of vendors/SDOs has defined the similar but proprietary concept, 
the objective is to define a standard solution for 

[netmod] FW: New Version Notification for draft-ma-netmod-immutable-flag-07.txt

[maqiufang (A)]

Hi, all

This version reflects the input we've received from the mailing list.



Thank you everyone(Jan, Rob, Kent, Jürgen, Andy, Frank et al.) for your great 
comments and suggestions!

Please see if the following updates are good for you:

   *  Use a Boolean type for the immutable value in YANG extension and

  metadata annotation

   *  Define a "with-immutable" parameter and state that immutable

  metadata annotation is not included in a response unless a client

  explicitly requests them with a "with-immutable" parameter

   *  reword the abstract and related introduction section to highlight

  immutable flag is descriptive

   *  Add a new section to define immutability of interior nodes, and

  merge with "Inheritance of Immutable configuration" section

   *  Add a new section to define what the immutable flag means for each

  YANG data node

   *  Define the "immutable flag" term.

   *  Add an item in the open issues tracking: Should the "immutable"

  metadata annotation also be returned for nodes described as

  immutable in the YANG schema so that there is a single source of

  truth.



Thanks a lot.



Best Regards,

Qiufang



-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
Sent: Thursday, May 25, 2023 4:52 PM
To: Balazs Lengyel ; Hongwei Li 
; Qin Wu ; Qin Wu 
; maqiufang (A) 
Subject: New Version Notification for draft-ma-netmod-immutable-flag-07.txt





A new version of I-D, draft-ma-netmod-immutable-flag-07.txt

has been successfully submitted by Qiufang Ma and posted to the IETF repository.



Name:  draft-ma-netmod-immutable-flag

Revision:  07

Title:  YANG Extension and Metadata Annotation for 
Immutable Flag

Document date:   2023-05-25

Group:  Individual Submission

Pages:   24

URL:
https://www.ietf.org/archive/id/draft-ma-netmod-immutable-flag-07.txt

Status: https://datatracker.ietf.org/doc/draft-ma-netmod-immutable-flag/

Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ma-netmod-immutable-flag

Diff:   
https://author-tools.ietf.org/iddiff?url2=draft-ma-netmod-immutable-flag-07



Abstract:

   This document defines a way to formally document existing behavior,

   implemented by servers in production, on the immutability of some

   configuration nodes, using a YANG "extension" and a YANG metadata

   annotation, both called "immutable", which are collectively used to

   flag which data nodes are immutable.



   Clients may use "immutable" statements in the YANG, and annotations

   provided by the server, to know beforehand when certain otherwise

   valid configuration requests will cause the server to return an

   error.



   The immutable flag is descriptive, documenting existing behavior, not

   proscriptive, dictating server behavior.









The IETF Secretariat






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

Re: [netmod] Comments on draft-ma-netmod-immutable-flag-06

[maqiufang (A)]

Hi, Kent

I support ensuring XC/Y remains transactional, such that a client can always 
move from valid config-A to valid config-B in a single update.  I also support 
requiring a "with-immutable" flag in client-requests in order for the 
"immutable" annotations to be returned (like "with-defaults").
Using an explicit parameter (e.g., with-immutable) avoids the case the client 
receives an "immutable" annotation yet doesn’t really understand that(clients 
don’t understand this annotation doesn’t even explicitly ask the server to 
return this). I agree that could be useful and should be added in the next 
version. I think this "with-immutable" flag should be supported even when a 
client retrieves a read-only target datastore (e.g.,  or 
), though immutability only refers to restrictions on read-write 
datastores.

I think that it is undesirable to support the "with-immutable" request 
parameter on non-configuration datastores.  The reason why is that I believe 
the "with-origin" flag is more useful.  If the "origin" is "system", then 
immutability is "true".
Is this true: If the “origin” is “system”, then immutability is “true”?
What if a system-defined node present in  is actually modifiable, 
i.e., allowing a client to write a different value in  that overrides 
the one defined in ?

The reason why I am thinking it might be useful for non-configuration 
datastores to return immutable flag is that, I think a client may want to know 
if it has the ability to change a value before it actually changes it (writes 
into configuration datastore). If that immutable flag doesn’t return until it 
is copied into configuration datastores(e.g., ), that would be awkward.
PS: there's an open-question as to if "with-immutable" also returns the 
"immutable" flag for nodes described as immutable in the YANG schema.  I think 
that the flags should be returned for all nodes regardless by default so that 
there is single source of truth.  That said, I'm open to the idea of the 
"with-immutable" parameter taking an argument specifying how much to return.
Yes, agree that this should be an open question. The current document doesn’t 
ask the server to return immutable flag for immutable nodes specified at 
schema-level, but that would cause the client to query both schema and instance 
data to obtain its real immutability.

Any issues with the following statements?

1) Only the server can create/change/delete `immutable` data, which is seen in 
the  and  datastores by default.  Clients are merely 
making immutable nodes visible/invisible in .  If the 
client does not make a system-defined node visible in , the node still 
exists in  and .
Among the common cases we see now are immutable data that is generated by 
system, and cannot be changed by the client. So the statement seems true for me.
I am unsure if there would be a case like a client creates a node instance but 
cannot modify that afterwards. That way it will not be present in  and 
the client may also be allowed to delete that. We used to have a BGP AS number 
case for that in previous version 
(https://datatracker.ietf.org/doc/html/draft-ma-netmod-immutable-flag-05#appendix-A.5)
  but that is not a good practice and it was removed.

The "client creates a node instance but cannot modify that afterwards" (unless 
the parent is deleted?) case seems to be exactly the non-transactional example 
we are trying to avoid, agreed?   This definition (#1) essentially guarantees 
transactionality, since there is nothing clients can do to alter what the 
system considers immutable.   A node is immutable if and only if system-defined.
I guess I don’t agree your last sentence. I don’t think all system-defined 
nodes are immutable, they do have a distinction between modifiable system 
configuration and non-modifiable system configuration.
FWIW, it may be possible for NACM to be non-transaction.  For instance, a 
client-removing their own access to NACM, which would be irreversible by that 
client.  But this is a corner-case, and one a server should guard against 
occurring.
Noted.



2) The "immutable" YANG extension statement (not the metadata annotation) 
designates, at the schema-level, config=true nodes that, when present in 
, are system-defined and hence immutable.
Note that NMDA does allow clients to create an interface entry with an 
interface-type value which is not yet physically present. Only when the 
interface physically appears, the type cannot be modified with another value 
not matching the real value the device is actually in use.

A temporal nature is at play here.

1) when the client sets the config when the card is installed, the system can 
fail the request if it affects any "immutable" nodes (non-matching values).   
[PS: it is assumed that, for this case, the metadata annotation (not the YANG 
extension), would be used.]

2) However, if the card is not installed, the client could put non-matching 
values for the "immutable" parts, and the server would have no wa

Re: [netmod] Comments on draft-ma-netmod-immutable-flag-06

[maqiufang (A)]

by user"
   is invalid, because reordering changes the value.
My understanding is that,

· if a leaf-list node is specified “immutable” at the schema-level, any 
leaf-list entries can neither be created or deleted. That means totally 
read-only to clients/users and I also agree that “ordered-by user” is invalid 
in this case.

· if a specific leaf-list entry is specified “immutable” at the 
instance-level, only that specific entry cannot be deleted. Metadata annotation 
is only applied to existing instance, so the client can add/insert new entries; 
other entries without immutable flag can also be deleted.
Is this consistent with what you have in mind?
When a "container" or "list" node is immutable:

  - all of its recursive descendants are "immutable=true"
unless toggled back to "immutable=false" by a
descendent node.
Yes, unless otherwise specified, immutability is inherited downwards towards 
the terminal leaves.
  - for lists, it is not possible to designate the list as a
whole as immutable, because the list itself doesn't
exist as a node in the data-tree.

  - If it is desired to communicate that list-entries
cannot be added/removed by clients, it is sufficient
for the list's `key` node(s) to be immutable=true.
I would rather see immutability of list the same way as leaf-list. That is, we 
do allow the list data node to be immutable at schema-level and it conveys that 
any list entry cannot be created and deleted, and likewise, “ordered-by user” 
is invalid in this case. I understand that list node may exist in multiple 
instances in the data tree but any issue you see with that?
  - if it is desired to communicate that a list-entries cannot
by reordered, the list must be "ordered-by system".
Corollary: an "ordered-by user" list is never immutable.
By the way, if a specific list instance is specified as immutable at 
instance-level, can a user create a descendant node instance inside that list 
instance?
When a "anydata" or "anyxml" node is immutable


  - the node, and all of its recursive descendants, if any, is/are
"immutable=true", unless toggled back to "immutable=false"
by a descendent node.
Agree, I see it similar to a “container” node is immutable.
Thoughts?


Kent // contributor

Best Regards,
Qiufang




On Apr 17, 2023, at 5:29 AM, maqiufang (A) 
mailto:maqiufa...@huawei.com>> wrote:

Hi, Jan

Thank you so much for the follow-up, please see my reply inline.

From: Jan Lindblad (jlindbla) [mailto:jlindbla=40cisco@dmarc.ietf.org]
Sent: Tuesday, April 11, 2023 10:05 PM
To: maqiufang (A) mailto:maqiufa...@huawei.com>>
Cc: Kent Watsen mailto:kent+i...@watsen.net>>; Rob Wilton 
(rwilton) mailto:rwil...@cisco.com>>; 
netmod@ietf.org<mailto:netmod@ietf.org>
Subject: Re: [netmod] Comments on draft-ma-netmod-immutable-flag-06

Qiufang,

Thank you for your continued work on this. I think the critical point to decide 
now is which use cases are in and which are out.
Sure, agree.

If we decide that only the five or six use cases listed currently in -06 are 
included, I'm quite happy about standardizing some YANG extension and metadata 
keywords for them. As I mentioned earlier, I think a slightly simpler solution 
would be sufficient and preferable for the current, rather small and simple set 
of use cases. If someone prefers the solution proposed in -06 because it better 
caters for some not yet listed use case, please share that use case so we can 
see the whole picture and discuss.
The cases described in the current document now have covered the ones the 
authors would like to provide, so from the author’s perspective, I think I have 
no objections to your proposed simpler solution; and I honestly don’t have a 
plan to incorporate the invariant case into the draft.


I think that regarding the isInvariant concept in the liaison, 3GPP is asking 
to model the object which cannot be modified once created. While it's just a 
natural workaround for the clients to first delete it and then recreate with 
the really desired value, but not requiring that clients must do that.

Objects that cannot be modified once created cannot exist in a transactional 
protocol. If we introduce such objects, that would seriously detract from the 
value of NETCONF/YANG (XC/Y). Rather than watering down XC/Y to match the 
expectations by legacy management protocols, I'd suggest we ask servers that 
want to advertise themselves as XC/Y servers to add the missing functionality 
to their implementation. This is not unreasonable, as many, many server 
implementors have already done so across many industries.

If a particular vendor is unable or unwilling to implemen

Re: [netmod] J. Sterne comments on draft-ietf-netmod-system-config-00

[maqiufang (A)]

Hi, Jason

Apologies for replying so late, there are a lot to chew on;-) And many thanks 
for the detailed comments, all good points.
I try to respond here and also welcome others to join the discussion if there 
are any other different points of view.
Please see my reply inline.

From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Jason Sterne (Nokia)
Sent: Thursday, March 23, 2023 7:54 AM
To: netmod@ietf.org
Subject: [netmod] J. Sterne comments on draft-ietf-netmod-system-config-00

Hello authors and WG,

Here are a few comments and questions on draft-ietf-netmod-system-config-00. 
I've labelled them for easier reference/separation.

The first few are general items. The rest are from specific sections of the doc.

##
(J1)
General
Likewise Generally, I think the following regarding resolve-system parameter 
are very good questions, I gave my answers here but I think all these could 
also be open for more discussion.
We may need to have a more detailed discussion (virtual interim call?) about 
the concept of resolve-system (i.e. the automatic copying). It may get 
complicated to make it fully usable for an operator.
-  If resolve-system is used to have some objects copied into the 
, is a client/user allowed to delete it?
Yes, a client/user can always delete configuration copied from  into 
, I think this is independent of whether it is copied by the 
client/user explicitly or copied by the system automatically. If some objects 
is copied from  into , then it should be treated as 
client/user defined configuration. But note that if deleting that copied 
configuration would cause the configuration invalid, the  
operation might not be performed successfully; or it might be copied into 
 again if a "resolve-system" parameter is carried in the operation.
-  What happens to the system object running when all references to it 
are deleted by the client/user? Does the system remove it?
No, if a data object is copied from  into , that data object 
will not be automatically removed or updated. There is no difference between a 
data object is copied into  automatically or manually. Generally we 
don't want system making changes to configuration in  which the client 
doesn't know that. So I don't expect the system could remove that automatically.
-  What happens if some system config that was auto-copied disappears 
from the system DS (e.g. conditionally active, i.e. turning off the qos 
function)? It may be odd that it stays around in running.
Per my last comment, I think it should stays around in , and merged 
into . But if that configuration is actually not in use by the 
device, it may not be present in . For example, the interface 
configuration in  which is not physically present doesn't appear in 
 but only in . There might be some other implementation 
which may also annotate these configuration as inactive/down.
-  What is copied? Only the referenced leafs (e.g. the list key), or 
also the other siblings (other descendants of the list entry that aren't 
directly referenced)?
Only the referenced leafs and the required configuration (e.g., mandatory true) 
sufficient to make the configuration valid are necessarily needed to copy into 
. Sec 5.2 (Explicit Declaration of System Configuration) states that 
"The client does not necessarily need to declare all the contents of the list 
entry (i.e., the descendant nodes), only the parts that are required to make 
the  appear valid." But I find sec 5.3 (Servers Auto-configuring 
Referenced System Configuration) failed to mention that. This should be clearly 
stated in the next version.
-  What if a must statement refers to a leaf in the system DS, and the 
presence of that leaf is required in running to make the running valid. Is that 
copied as well? (We've mostly been talking about objects, aka list entries, and 
their keys being the target of a leafref)
I had the similar question as raised in the IETF 116 NETMOD session, not only 
for when statement, but also cases like must statement, mandatory true data 
node, exactly satisfy the min-element constraints, I personally think that 
absence of any of these cases would make resolve-system parameter a partial 
solution.
-  Section 3.2 mentions that config auto-copied into running isn't 
updated when that same config in system changes (during s/w upgrade). I think 
maybe servers that convert configuration during upgrade (a common approach) 
would want to convert/upgrade system config as well as any copied system config 
that exists in running.
That requirement can be understood. But I don't have a solution yet. Maybe 
define an RPC operation to interlink configuration both in  and 
 and use that to convert/upgrade system configuration defined in 
? Thoughts?
-  When a client deletes an override (e.g. of a mandatory leaf), does 
"resolve-system" populate the copy of the leaf again from system?
My understanding is that

Re: [netmod] Comments on draft-ma-netmod-immutable-flag-06

[maqiufang (A)]

Hi, Jan

Thank you so much for the follow-up, please see my reply inline.

From: Jan Lindblad (jlindbla) [mailto:jlindbla=40cisco@dmarc.ietf.org]
Sent: Tuesday, April 11, 2023 10:05 PM
To: maqiufang (A) mailto:maqiufa...@huawei.com>>
Cc: Kent Watsen mailto:kent+i...@watsen.net>>; Rob Wilton 
(rwilton) mailto:rwil...@cisco.com>>; 
netmod@ietf.org<mailto:netmod@ietf.org>
Subject: Re: [netmod] Comments on draft-ma-netmod-immutable-flag-06

Qiufang,

Thank you for your continued work on this. I think the critical point to decide 
now is which use cases are in and which are out.
Sure, agree.

If we decide that only the five or six use cases listed currently in -06 are 
included, I'm quite happy about standardizing some YANG extension and metadata 
keywords for them. As I mentioned earlier, I think a slightly simpler solution 
would be sufficient and preferable for the current, rather small and simple set 
of use cases. If someone prefers the solution proposed in -06 because it better 
caters for some not yet listed use case, please share that use case so we can 
see the whole picture and discuss.
The cases described in the current document now have covered the ones the 
authors would like to provide, so from the author’s perspective, I think I have 
no objections to your proposed simpler solution; and I honestly don’t have a 
plan to incorporate the invariant case into the draft.


I think that regarding the isInvariant concept in the liaison, 3GPP is asking 
to model the object which cannot be modified once created. While it's just a 
natural workaround for the clients to first delete it and then recreate with 
the really desired value, but not requiring that clients must do that.

Objects that cannot be modified once created cannot exist in a transactional 
protocol. If we introduce such objects, that would seriously detract from the 
value of NETCONF/YANG (XC/Y). Rather than watering down XC/Y to match the 
expectations by legacy management protocols, I'd suggest we ask servers that 
want to advertise themselves as XC/Y servers to add the missing functionality 
to their implementation. This is not unreasonable, as many, many server 
implementors have already done so across many industries.

If a particular vendor is unable or unwilling to implement a server to industry 
expectations, there is no way for me or anyone to prevent that vendor from 
releasing a YANG module with some proprietary extensions to describe that 
behavior. In fact, several already have, and that's probably fine. I just don't 
understand why IETF should spend valuable time to confuse he market and 
standardize such backward things. If 3GPP thinks the create-no-modify concept 
is valuable in the world of automation interfaces, they could release a 3GPP 
YANG module with such extensions.
Though I don’t have a very strong disagreement to the invariant behavior 
myself, if the WG thinks it as a really backward practice, I am pretty happy 
not to even mention that and keep the advancement of XC/Y.

As Jan pointed out, all the use cases written in the current document now are 
targeting configuration cannot be updated or deleted. I also feel it better to 
define identities to only support our current use cases now, and leave the door 
open to allow other implementation to extend more if needed.

While I like the flexibility with identities, they would really remove most of 
the value of standardization in this case. YANG already allows any vendor to 
invent their own extension keywords. If we standardize a new extension that 
relies on identities specified by vendors, we have not really gained much.
YANG extensions that would have an impact to the interoperability are good to 
be standardized IMO. Using identities is more like a compromise to me, 
providing an extensible solution to 3GPP without having to define that in IETF. 
But we can discuss more. This determines how we respond to the liaison. I 
assume we don’t really discuss a lot regarding the solution part.
Again, as mentioned, the objective is to document existing server behaviors, if 
the server already internally considers some configuration immutable for valid 
reasons. It doesn't apply to servers which don't have any immutable 
configuration, much less to encourage servers to add more such restrictions. 
The document should be updated if it failed to make that clear.

I'm fine with marking some parts of the configuration as immutable/impossible 
to change. This may cause some operational trouble in the field, but not as 
much as non-transactionality. It is the non-transactional behavior I find 
really hard to live with. Let's first decide which use cases we are addressing, 
then find the least intrusive solution to that set.
Operational trouble already exists today, immutable-flag tries to make some of 
that visible to client. See my comments above, I think no one is trying to 
introduce non-transactionali

Re: [netmod] Comments on draft-ma-netmod-immutable-flag-06

[maqiufang (A)]

Hi, Kent, Rob, Jan

Apologies for reacting to this thread late.

I think that regarding the isInvariant concept in the liaison, 3GPP is asking 
to model the object which cannot be modified once created. While it's just a 
natural workaround for the clients to first delete it and then recreate with 
the really desired value, but not requiring that clients must do that.

As Jan pointed out, all the use cases written in the current document now are 
targeting configuration cannot be updated or deleted. I also feel it better to 
define identities to only support our current use cases now, and leave the door 
open to allow other implementation to extend more if needed.

Again, as mentioned, the objective is to document existing server behaviors, if 
the server already internally considers some configuration immutable for valid 
reasons. It doesn't apply to servers which don't have any immutable 
configuration, much less to encourage servers to add more such restrictions. 
The document should be updated if it failed to make that clear.

Best Regards,
Qiufang

From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Kent Watsen
Sent: Thursday, April 6, 2023 12:12 AM
To: Rob Wilton (rwilton) mailto:rwil...@cisco.com>>
Cc: Jan Lindblad (jlindbla) 
mailto:jlindbla=40cisco@dmarc.ietf.org>>;
 netmod@ietf.org
Subject: Re: [netmod] Comments on draft-ma-netmod-immutable-flag-06

Hi Rob,

My prior response to you focused on what the draft specifies (not the liaison), 
since you wrote:

"Fundamentally, I generally interpret this draft as saying:  NETCONF/YANG 
doesn't really match the existing management model/API in 3GPP and hence we 
want to make non-backwards compatible changes to NETCONF/YANG to match the 3GPP 
semantics."

Which isn't the draft's proposition.  Maybe you meant s/draft/liaison/?


I just re-read the liaison and I fail to see how the immutable-flag draft's 
goal of describing existing server behavior isn't aligned with the liaison.  At 
the end of the day, it doesn't really matter what extensions exist in the YANG, 
or annotations in the data, the client can send any request it wants to the 
server and, ultimately, the server must enforce whatever it wants to enforce.

It effectively comes down to a quality-assurance effort to determine if the 
YANG accurately describes the server's existing behavior.  To the extent that 
XC/Y tools might someday grok the YANG-extensions and/or data-annotations (to 
do some of the heavy-lifting) is out of scope, IMO.

I'm unsure if the set of the extensions and annotations in the current draft 
are robust enough to sufficiently support every use-case.  The WG could create 
taxonomies and the like to prove this out.  But a possibly better solution is 
for the immutable-flag draft to define behaviors using identities (instead of 
bits/boolean), so that 1) we don't have to define a perfect set of flags 
upfront and 2) applications (3GPP) can define additional flags if desired.

Whilst I agree that it is best for servers to be completely transactional, 
avoiding the need to delete a parent container in order to recreate a 
previously-immutable child, 3GPP has already decided to do this.  I see no 
issue in providing them an ability to capture this semantic using identities 
they defined themselves.

Kent





On Apr 5, 2023, at 6:49 AM, Rob Wilton (rwilton) 
mailto:rwil...@cisco.com>> wrote:

Hi Kent,

Some of my concern stems from the fact that during the NMDA architecture 
discussions there was a strong desire to make the configuration data stored in 
 to be owned by the client.  I.e., the server has the right to accept 
or reject a particular configuration but ultimately it is the client that 
should control what is in .  Related to this, is the goal of ensuring 
the validation of the configuration is based on the state that the 
configuration represents, not the particular config edit that is being made to 
transition the configuration into that state.  I.e., it should be possible for 
a client to change the configuration from any valid state A to any valid state 
B, without requiring extra client orchestration steps to keep the server happy 
(e.g., you can transition from A to B, but must go via C, D and E on the way).  
Or to put it another way, if such steps are required, then it is much simpler 
(for an automation client) to do those transitional steps on the server than it 
is to expose and force them on to the client.

As you point out, existing implementations don’t always follow these rules 
above, but I regard these as warts in the implementations relative to following 
the ideal architecture above.  As such, I have little issue with a YANG 
extension or metadata annotation to programmatically indicate to clients where 
these aberrations occur for this use case.

But this isn’t what the 3GPP liaison is asking for.  They are requesting to 
bake the edit-config constraints directly into the management APIs defined in 
YANG because thi

Re: [netmod] system configuration/datastore and the keystore/truststore drafts

[maqiufang (A)]

Hi, Jan 

In the second case you've described below, " servers accept references to 
pieces of hardware that are currently missing, and just mark them as 
operationally down." Is this missing hardware related configuration also not 
present in ? Would a server treat this configuration as invalid if 
not? NMDA does allow a user to configure an interface which is not physically 
inserted, but my understanding is that the interface configuration needs to 
first be present in  in order to be leaf-refed by other configuration 
(if the require-instance is true). 

Any misunderstanding?

Best Regards,
Qiufang

-Original Message-
From: Jürgen Schönwälder  
Sent: Monday, March 27, 2023 2:13 PM
To: Jan Lindblad 
Cc: Rob Wilton (rwilton) ; 
draft-ietf-netmod-system-con...@ietf.org; Kent Watsen ; 
netmod@ietf.org
Subject: Re: [netmod] system configuration/datastore and the 
keystore/truststore drafts

On Mon, Mar 27, 2023 at 04:04:34AM +0200, Jan Lindblad wrote:
> Rob, Jürgen, Kent, WG,
> 
> I am strongly opposed to giving up the idea that running must always be 
> valid. This is one of the landmark properties that has made NETCONF the most 
> useful management interface for network  automation ever. For anyone not up 
> to that, we already have SNMP and there is also a wide assortment of 
> REST-based APIs out there.
> 
> I'm slightly appalled :-) that dropping this tenet is even discussed. In 
> particular, I find it strange that such a small stone in one shoe would make 
> us consider abandoning the whole trip.

During the development of NMDA, it became clear that implementations often 
validate intended and not running when ask them to validate running. It is all 
a question of how much do we execpt/allow to happen on the transition running 
to intended. Some say 'nothing', some say 'a little bit of expansion', some say 
... Yes, its a slippery slope, but we started it with NMDA, not with the system 
datastore or crypto types.
 
> I'm no crypto expert and know little about how TPM modules work, but I was 
> under the impression that part of the beauty with TPMs was that you would 
> *not* copy keys around in the rest of the system. Instead you'd just refer to 
> the keys in the TPM. This is similar to how you'd typically refer to hardware 
> in slots.
> 
> So if we treat TPM keys like they were hardware, we are back to our usual 
> discussion about how to treat validity of running with respect to hardware. 
> Either servers reject references in running to pieces of hardware that 
> happens to be missing at this point in time (which may make it hard to 
> install backups taken earlier, if the hardware setup has changed since), or 
> servers accept references to pieces of hardware that are currently missing, 
> and just mark them as operationally down. No need to change any RFCs to go 
> with either of these approaches, I believe, and certainly not break 
> fundamentals.
> 
> Does this make sense, or is there a crypto angle here that I am missing?

Yes, ideally no copying would be needed since there is just a lazy reference by 
name. I do not recall the details why this is not the way the crypto models 
work.

/js

-- 
Jürgen Schönwälder  Constructor University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] system configuration/datastore and the keystore/truststore drafts

[maqiufang (A)]

Hi, Rob
It seems that we are getting back to the discussion about whether  
must always be valid 
(https://mailarchive.ietf.org/arch/msg/netmod/t6qgW7c-RiaioejjYWWb9jbOpR0/). 

Comments from the WG on this issue are quite split. I fully agree things would 
become much easier if we don't always ask  to contain any referenced 
system objects, but not only NMDA RFC, but also section 8.1 in RFC7950 states 
that "The running configuration datastore MUST always be valid." I am not sure 
if it's time for us to break this now.

But either way, I think it always make sense to have "resolve-system" 
parameter, in cases where a client intends to validate  alone. The 
sticking point is that whether referenced system configuration should always be 
present in .

Best Regards,
Qiufang

-Original Message-
From: Rob Wilton (rwilton)  
Sent: Monday, March 27, 2023 8:01 AM
To: Jürgen Schönwälder ; 
draft-ietf-netmod-system-con...@ietf.org; Kent Watsen 
Cc: netmod@ietf.org
Subject: RE: [netmod] system configuration/datastore and the 
keystore/truststore drafts

Hi Jürgen, Kent,

If we can take that interpretation (and I agree I think that was the spirit of 
how I thought that NMDA works, particularly for templating and inactive 
configuration).

However, my concern comes from the MUST in this paragraph of RFC 8342 (and RFC 
7950 also states that  must always be valid):

5.1.3.  The Running Configuration Datastore ()

   The running configuration datastore () is a configuration
   datastore that holds the current configuration of the device.  It MAY
   include configuration that requires further transformation before it
   can be applied, e.g., inactive configuration, or template-mechanism-
   oriented configuration that needs further expansion.  However,
MUST always be a valid configuration data tree, as defined
   in Section 8.1 of [RFC7950].

And the current version of the system datastore draft 
(https://datatracker.ietf.org/doc/draft-ietf-netmod-system-config/), 5.1.  
Conceptual Model of Datastores, has text like:

   All above three types of system configurations will appear in
   .  Clients MAY reference nodes defined in , override
   values of configurations defined in , and configure
   descendant nodes of system-defined nodes, by copying or writing
   intended configurations into the target configuration datastore
   (e.g., ).

   Servers MUST enforce that configuration references in  are
   resolved within the  datastore and ensure that 
   contains any referenced system configuration.  Clients MUST either
   explicitly copy system-defined nodes into  or use the
   "resolve-system" parameter.  The server MUST enforce that the
   referenced system nodes configured into  by the client is
   consistent with .  Note that  aware clients know how
   to discover what nodes exist in .  How clients unaware of the
datastore can find appropriate configurations is beyond the
   scope of this document.

But, if the WG agrees that for NMDA, the actual validation happens on 
 and not  then I understand that to mean that  on 
its own may not be valid, and it is only "implicitly valid" after doing the 
processing between  and  and  must always be valid.
 
Further, I think that this means that there isn't any requirement (from a 
validation correctness point of view) to require system configuration to be 
copied into .  Of course, there may be other reasons why a client may 
want system configuration to be copied into , e.g., so that it can be 
returned in a get request of .

If the WG agrees that this is the right direction then I think that it would be 
helpful for the system configuration datastore to perhaps update (or clarify) 
section 5.1.3 of RFC 8342, and perhaps provide an updated diagram with how the 
system datastore fits into the picture.  I think that there would be further 
updates required to the system configuration datastore draft to clarify the 
expected behaviour, and we should also think carefully about the text and 
perhaps examples in the truststore/keystore drafts (since they currently state 
that the keys/certificates must be copied into , and I think that we 
are saying with NMDA that this is not required).

Thanks,
Rob


> -Original Message-
> From: Jürgen Schönwälder 
> Sent: 26 March 2023 13:24
> To: Rob Wilton (rwilton) 
> Cc: netmod@ietf.org
> Subject: Re: [netmod] system configuration/datastore and the 
> keystore/truststore drafts
> 
> Rob,
> 
> my reading of Figure 2 of RFC 8342 is that validation happens on 
> intended and not on running. I assume the system config is folded in 
> between running and intended. This seems to be inline with the 
> approach taken by the system config draft. This, of course, leaves is 
> open what actually happens if keys are removed and cause a subsequent 
> validation error. Ideally, such a transaction key removal transaction 
> should fail, but whether this will be enforced if the transaction 
> takes place outside the configuration managemen

Re: [netmod] WG adoption call: draft-dbb-netmod-acl-03

[maqiufang (A)]

Hi, all



I've read this draft and support the adoption of it.

Just mention that we are also working on the ACL extension targeting the 
enterprise network scenario 
(https://datatracker.ietf.org/doc/draft-ma-opsawg-ucl-acl/), will see how to 
coordinate with this work.



Nits:

· Sec. 3.1 s/confirguration/configuration

· Sec. 3.2   s/introduing/introducing

· The text below Figure 1 is confusing, it seems that the same symbol 
should be used for sentences start with both network controllers and devices.



Best Regards,

Qiufang





-Original Message-
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of 
mohamed.boucad...@orange.com
Sent: Wednesday, January 4, 2023 4:08 PM
To: Lou Berger ; NETMOD Group 
Cc: NetMod WG Chairs 
Subject: Re: [netmod] WG adoption call: draft-dbb-netmod-acl-03



Hi all,



I support adoption, obviously.



Cheers,

Med



> -Message d'origine-

> De : netmod mailto:netmod-boun...@ietf.org>> De la 
> part de Lou Berger Envoyé

> : mardi 20 décembre 2022 00:01 À : NETMOD Group 
> mailto:netmod@ietf.org>> Cc :

> NetMod WG Chairs mailto:netmod-cha...@ietf.org>> 
> Objet : [netmod] WG adoption

> call: draft-dbb-netmod-acl-03

>

> Hello,

>

> This email begins a 3-week adoption poll for:

> https://datatracker.ietf.org/doc/draft-dbb-netmod-acl/

>

> Please voice your support or technical objections to adoption on the

> list by the end of the day (any time zone) January 9.

>

> This is an extended call due to the holiday/New Year.

>

> Thank you,

> Lou (as Co-chair)

>

> ___

> netmod mailing list

> netmod@ietf.org

> https://www.ietf.org/mailman/listinfo/netmod



_



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 may contain confidential or privileged 
information that may be protected by law; they should not be distributed, used 
or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

Thank you.



___

netmod mailing list

netmod@ietf.org

https://www.ietf.org/mailman/listinfo/netmod


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

Re: [netmod] Balazs comments on draft-ietf-netmod-system-config-00

[maqiufang (A)]

Hi, Balazs,

Thanks for the comments, much appreciated! I am trying to prepare a new version 
resolving your comments, please also see my reply below.

From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Balázs Lengyel
Sent: Friday, December 2, 2022 11:01 PM
To: netmod@ietf.org
Subject: [netmod] Balazs comments on draft-ietf-netmod-system-config-00

Hello,
Some comment on draft-ietf-netmod-system-config-00.

General:
I support this work, I see it as important.
Thanks, Balazs. I see it both important and interesting. Since there is a broad 
implementation among multiple vendors, the authors would always welcome 
contributions from the WG.
I think this draft should be dependent on the immutable draft. I see limited 
value of system-configuration if there is no way to protect It from client 
modification.
While I agree that a lot of system configuration need to be protected from 
client modification, this work tries to define a standard mechanism to :1) 
allow the client to see what system configuration is available (includes 
inactive system configuration which is not present in ) ;2) enable 
the client to reference system configuration without having to copy it into 
 explicitly; 3) support a better configuration of descendant nodes of 
system configuration.
Ch 1)
Why is explicit copying bad?  Why do we need resolve-system parameter?  the You 
should motivate that.
I think the reason is that we always want the life easier and more convenient 
for clients. The device exists a lot of system configuration, the client would 
like to leafref system configuration (or put system configuration in when/must 
statement) directly in , without having to declaring the referenced 
item in  manually. Sure, we will try to state it clearly in the 
Introduction section.

Ch 1.4)
edit-config and edit-data cannot be used towards the startup datastore. 
Copy-config can.
Agree that edit-config and edit-data cannot be used towards . This 
sentence that might cause confusion can be traced from RFC7950 Sec.8.3.3 "If 
the datastore is 'running' or 'startup', these constraints MUST be enforced at 
the end of the  or  operation." Given the next 
comment that you made, see my proposed changes below.


" If the target
   datastore of the / or  is
   "candidate", the server's copy referenced nodes from  to the
   target datastore is delayed until a  or  operation
   takes place."
This means that  the device has to remember that resolve-system was used. Is 
this fact visible for other clients? What if someone overrides items that were 
planned for resolve-system?
Other clients (not the one that used the resolve-system) will be confused.
What happens if I have a must statement including a "count () <= max" on list 
items. Another client might create max number of list entries. This could 
prevent the device from adding new list-entries based on resolve-system.
IMHO delaying the copy is a bad idea.
Thanks for pointing this out. I think your arguments are valid to me. The 
server having to remember that there is a resolve-system parameter used before 
just complicates the implementation. Since this parameter is carried with the 
RPC operation, it makes sense the copy operation should always be finished at 
the end of RPC operation itself.  Proposed update:

OLD:" According to the NETCONF constraint enforcement model defined in the
section 8.3 of [RFC7950], if the target datastore of the / or  is "running" or "startup", the
server's copy referenced nodes from  to the target datastore
MUST be enforced at the end of the / or
 operations during the validation.  If the target
datastore of the / or  is
"candidate", the server's copy referenced nodes from  to the
target datastore is delayed until a  or  operation
takes place."
NEW: "The server's copy referenced nodes from  to the target datastore 
MUST be enforced at the end of the / or  
operations. This is regardless of which target datastore it is."

1.5.2)  IMHO we should have the same capability in Netconf too.
I am thinking that a client can discover if the server supports the 
resolve-system parameter by reading the YANG library information in 
 and checking if the server supports the 
"ietf-netconf-resolve-system" YANG module. Given that, there is no need to 
define a resolve-system capability identifier for NETCONF. Thoughts?

2) Define what does it mean if a part of system configuration is not active/ 
not applied? In which datastore is it visible? If I explicitly copy a 
conditionally-active item into  (while its condition is still not met) 
does it become active?
If system configuration is inactive, it means this configuration is not "in 
use" and does not actually impact the current running configuration of the 
device. According to the definition of the Operational datastore in NMDA draft, 
such configurations are not present in  but also depends on the 
server interpretation of "in use" and server implementation.  While it is for 
sure that, inactive sy

[netmod] FW: New Version Notification for draft-ma-netmod-immutable-flag-04.txt

[maqiufang (A)]

Hi, all

As mentioned in the previous email 
(https://mailarchive.ietf.org/arch/msg/netmod/ukhXsex5jbTL9JLWZ-Dz9E4rvPo/),  
this version clarifies the interaction between immutable flag and NACM 
mechanism.
Comments and suggestions are greatly appreciated. Thanks!

Best Regards,
Qiufang

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: Thursday, October 20, 2022 4:19 PM
To: Balazs Lengyel ; Hongwei Li 
; Qin Wu ; Qin Wu 
; maqiufang (A) 
Subject: New Version Notification for draft-ma-netmod-immutable-flag-04.txt


A new version of I-D, draft-ma-netmod-immutable-flag-04.txt
has been successfully submitted by Qiufang Ma and posted to the IETF repository.

Name:   draft-ma-netmod-immutable-flag
Revision:   04
Title:  YANG Extension and Metadata Annotation for Immutable Flag
Document date:  2022-10-20
Group:  Individual Submission
Pages:  20
URL:
https://www.ietf.org/archive/id/draft-ma-netmod-immutable-flag-04.txt
Status: https://datatracker.ietf.org/doc/draft-ma-netmod-immutable-flag/
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ma-netmod-immutable-flag
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ma-netmod-immutable-flag-04

Abstract:
   This document defines a YANG extension named "immutable" to indicate
   that specific "config true" data nodes are not allowed to be
   created/deleted/updated.  To indicate that specific entries of a
   list/leaf-list node or instances inside list entries cannot be
   updated/deleted after initialization, a metadata annotation with the
   same name is also defined.  Any data node or instance marked as
   immutable is read-only to the clients of YANG-driven management
   protocols, such as NETCONF, RESTCONF and other management operations
   (e.g., SNMP and CLI requests).

   This document aims to provide more visibility into immutability
   characteristic of particular schema or instance nodes by defining a
   standard mechanism to allow the server to document the existing
   immutable configuration data, while this doesn't mean attaching such
   restrictions is encouraged.


  


The IETF Secretariat



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

[netmod] should the immutable-flag solution be an update to NACM?

[maqiufang (A)]

Hi, all

The current immutable-flag draft 
(https://www.ietf.org/archive/id/draft-ma-netmod-immutable-flag-03.txt) defines 
both a YANG extension and a metadata annotation to indicate the immutability of 
data nodes and instances, respectively.

An alternative approach discussed on the list is to update NACM and define a 
"nacm: static-data" YANG extension besides nacm:default-deny-write and 
nacm:default-deny-all.
Authors' considerations on this proposal are following:
* Immutability is a property of YANG data nodes or instances, while 
NACM is a security feature
* NACM can be switched off by setting the /nacm/enable-nacm leaf to 
"false"
* Emergency recovery session will bypass access control enforcement
* A single YANG extension cannot express instance-level immutability

In the current draft, YANG extension we defined doesn't depend on NACM module, 
but this draft doesn't clarify one point well related to the relation between 
this YANG extension and NACM, i.e., whether using such YANG extension causes 
NACM rule not take effect.
To address ambiguity when both an immutable-flag and "a user-provided NAC rule 
to allow write access" are used, the draft can add the following explicit text:
"When a specific data node or instance is marked as "immutable", NACM
cannot override this to allow create/delete/update access. Servers will
 ignore such NACM rule. For example, if a particular data node is marked
 as 'im:immutable' without the 'exceptions' argument for update, the server
will ignore any user-defined NACM rule to allow update access operation to
 that specific data node."

We plan to integrate this on Oct 19 if there is no objection to this change.
Any thoughts or feedback on this?

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

Re: [netmod] IPR Poll on draft-ietf-netmod-with-system

[maqiufang (A)]

No, I'm not aware of any IPR that applies to this draft.

Best Regards,
Qiufang

-Original Message-
From: Kent Watsen [mailto:kent+i...@watsen.net] 
Sent: Thursday, October 13, 2022 9:24 AM
To: maqiufang (A) ; Qin Wu ; 
Fengchong (frank) ; Kent Watsen 
; Jan Lindblad (jlindbla) ; Chongfeng 
Xie ; Sterne, Jason (Nokia - CA/Ottawa) 

Cc: netmod@ietf.org
Subject: IPR Poll on draft-ietf-netmod-with-system

[NOTE: A response is needed from all listed in this message's "To" line, the 
authors and contributors listed in the draft]


Authors, Contributors, WG,

In preparation for a WG Adoption Call:

Are you aware of any IPR that applies to drafts identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 
3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think appropriate. 
If you are listed as a document author or contributor please answer the above 
by responding to this email regardless of whether or not you are aware of any 
relevant IPR. This document will not advance to the next stage until a response 
has been received from each author.

If you are on the WG email list or attend WG meetings but are not listed as an 
author or contributor, we remind you of your obligations under the IETF IPR 
rules which encourages you to notify the IETF if you are aware of IPR of others 
on an IETF contribution, or to refrain from participating in any contribution 
or discussion related to your undisclosed IPR. For more information, please see 
the RFCs listed above and 
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.

Thank you,
Kent (Co-Chair)

PS Please include all listed in the headers of this message in your response.

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

[netmod] FW: New Version Notification for draft-ma-netmod-immutable-flag-03.txt

[maqiufang (A)]

Hi, all
This version has made the following changes:

   *  Avoid using and rephrase "server MUST reject" statement, and try
  to clarify that this documents aims to provide visibility into
  existing immutable behavior;

   *  Add a new section to discuss the inheritance of immutability;

   *  Clarify that deletion to an immutable node in  which is
  instantiated in  and copied into  should always
  be allowed;

   *  Clarify that write access restriction due to general YANG rules
  has no need to be marked as immutable.

More details are provided in the I-D, any comments and suggestions are much 
appreciated.

Best Regards,
Qiufang

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: Thursday, August 11, 2022 5:45 PM
To: Balazs Lengyel ; Hongwei Li 
; Qin Wu ; Qin Wu 
; maqiufang (A) 
Subject: New Version Notification for draft-ma-netmod-immutable-flag-03.txt


A new version of I-D, draft-ma-netmod-immutable-flag-03.txt
has been successfully submitted by Qiufang Ma and posted to the IETF repository.

Name:   draft-ma-netmod-immutable-flag
Revision:   03
Title:  YANG Extension and Metadata Annotation for Immutable Flag
Document date:  2022-08-11
Group:  Individual Submission
Pages:  20
URL:
https://www.ietf.org/archive/id/draft-ma-netmod-immutable-flag-03.txt
Status: https://datatracker.ietf.org/doc/draft-ma-netmod-immutable-flag/
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ma-netmod-immutable-flag
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ma-netmod-immutable-flag-03

Abstract:
   This document defines a YANG extension named "immutable" to indicate
   that specific "config true" data nodes are not allowed to be
   created/deleted/updated.  To indicate that specific entries of a
   list/leaf-list node or instances inside list entries cannot be
   updated/deleted after initialization, a metadata annotation with the
   same name is also defined.  Any data node or instance marked as
   immutable is read-only to the clients of YANG-driven management
   protocols, such as NETCONF, RESTCONF and other management operations
   (e.g., SNMP and CLI requests).

   This document aims to provide more visibility into immutability
   characteristic of particular schema or instance nodes by defining a
   standard mechanism to allow the server to document the existing
   immutable configuration data, while this doesn't mean attaching such
   restrictions is encouraged.


  


The IETF Secretariat


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

[netmod] FW: New Version Notification for draft-ma-netmod-with-system-04.txt

[maqiufang (A)]

Hi, all

v-04 is available at:

URL:
https://www.ietf.org/archive/id/draft-ma-netmod-with-system-04.txt

Status: https://datatracker.ietf.org/doc/draft-ma-netmod-with-system/

Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ma-netmod-with-system

Diff:   https://www.ietf.org/rfcdiff?url2=draft-ma-netmod-with-system-04



Based on the WG discussion in IETF 114, the major update is following:

instead of simply saying

"If the 'resolve-system' parameter is not given by the client, the

server should not modify  in any way otherwise not specified

by the client",



v-04 has clarified that

"  If the 'resolve-system' parameter is not given by the client, the

   server should not modify  in any way otherwise not specified

   by the client.  Not using capitalized 'SHOULD NOT' in the previous

   sentence is intentional.  The intention is bring awareness to the

   general need to not surprise clients with unexpected changes.  It is

   desirable for clients to always opt into using mechanisms having

   server-side changes.  This document enables a client to opt into this

   behavior using the "resolve-system" parameter.  RFC 7317 enables a

   client to opt into its behavior using a "$0$" prefix."



Comments and suggestions are appreciated.



Best Regards,

Qiufang



-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
Sent: Tuesday, August 9, 2022 7:25 PM
To: Fengchong (frank) ; Fengchong (frank) 
; Jan Lindblad ; Kent Watsen 
; Qin Wu ; Qin Wu 
; maqiufang (A) 
Subject: New Version Notification for draft-ma-netmod-with-system-04.txt





A new version of I-D, draft-ma-netmod-with-system-04.txt

has been successfully submitted by Qiufang Ma and posted to the IETF repository.



Name:  draft-ma-netmod-with-system

Revision:  04

Title:  System-defined Configuration

Document date:   2022-08-09

Group:  Individual Submission

Pages:   43

URL:
https://www.ietf.org/archive/id/draft-ma-netmod-with-system-04.txt

Status: https://datatracker.ietf.org/doc/draft-ma-netmod-with-system/

Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ma-netmod-with-system

Diff:   https://www.ietf.org/rfcdiff?url2=draft-ma-netmod-with-system-04



Abstract:

   This document updates NMDA to define a read-only conventional

   configuration datastore called "system" to hold system-defined

   configurations.  To avoid clients' explicit copy/paste of referenced

   system-defined configuration into the target configuration datastore

   (e.g., ), a "resolve-system" parameter has been defined to

   allow the server acting as a "system client" to copy referenced

   system-defined nodes automatically.  The solution enables clients

   manipulating the target configuration datastore (e.g., ) to

   overlay and reference nodes defined in , override values of

   configurations defined in , and configure descendant nodes of

   system-defined nodes.









The IETF Secretariat




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

Re: [netmod] Balazs Review of draft-ma-netmod-with-system-02

[maqiufang (A)]

Hi, all

From: Kent Watsen [mailto:kent+i...@watsen.net]
Sent: Friday, April 15, 2022 8:18 AM
To: maqiufang (A) 
Cc: Balázs Lengyel ; Jan Lindblad 
; netmod@ietf.org
Subject: Re: [netmod] Balazs Review of draft-ma-netmod-with-system-02




JANL: I could accept watering down MUST NOT to SHOULD NOT.
BALAZS3: Sorry, I know system-set data has its problems, but my arguments still 
stand.
[Qiufang] SHOULD NOT is fine from my perspective.


SHOULD NOT is fine from my perspective also.  Clearly best practice.

The focus should be on the "in any way not specified by the client" fragment.  
This part is key because we want the client to be aware of and explicitly ask 
for server-side functions.
Yes, I believe that this is what we have proposed in the current updated 
draft(https://mailarchive.ietf.org/arch/msg/netmod/J9GxqrRtQfTcjNp3nvE1gWtFC7M/).
Balazs, could you please have a review of the update and let the authors know 
if all of your comments were addressed? Thanks.

Best Regards,
Qiufang
RFC 7317 did the same thing with its definition of the "crypt-hash" typedef 
allowing for a special '0' value for the "id" field that causes the server to 
store a hashed value instead.

Kent  // contributor




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

Re: [netmod] WGLC on draft-ietf-netmod-node-tags-06

[maqiufang (A)]

Hi, Juergen, Qin
How about defining a more general mechanism to cover your proposal:
  module: ietf-data-node-tags
  augment /tags:module-tags/tags:module:
+--rw data-object-tags
   +--rw data-node* [ni-id]
  +--rw ni-id  nacm:node-instance-identifier
  +--rw tag-list* [tag]
  |  +--rw tagtags:tag
  |  +--rw value?  enumeration
  +--rw masked-tag*   tags:tag
So that the users can define any tag(e.g., corresponding-mib-oid, 
related-node...) they’re interested in and the corresponding value(if any).

Best Regards,
Qiufang

-Original Message-
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Jürgen Sch?nw?lder
Sent: Wednesday, April 13, 2022 2:37 PM
To: Qin Wu 
Cc: netmod@ietf.org
Subject: Re: [netmod] WGLC on draft-ietf-netmod-node-tags-06

Hi,

I believe the NETMOD WG should work out a single mechanism to convey metadata. 
I see no value in developing N use case specific mechanisms spread over several 
WGs. If this document is not aiming to provide a generic solution, then I 
believe it should not be published.

/js

On Tue, Apr 12, 2022 at 03:27:03PM +, Qin Wu wrote:
> Hi, Jurgen:
> I understand your comment, is to investigate more use cases and see how one 
> mechanism can be generalized to cover more use cases.
> But the idea of this draft is to capture characteristics data (e.g., KPI data 
> ) using data node tag. Data node tag module can only convey enumerated tag 
> valued defined in section 9.2, that is why Balazs clarify the essence of data 
> nod tag are not metadata based on RFC7950 but data properties.
> 
> I did investigate meta-data-collection draft. I think meta-data 
> collection draft extends from ietf-system-capabilities module defined in 
> RFC9196 while draft-ietf-netmod-node-tags-06 extends from ietf-module-tags 
> defined in RFC8819 I believe observable-period related parameter in 
> metadata-collection module is not suited to be redefined in Data node tag 
> module since they are really system capability related parameters.
> For three other parameters such as corresponding-mib-oid, related-node, 
> optimized-measurement-point, not every data node has these three parameters, 
> the value of corresponding-mib-oid, related-node can be any value it is hard 
> to be listed as tag values, for optimized-measutement-point, it is empty 
> type, it seem to fine, but add corresponding-mib-oid, related-node make data 
> node tag module design very ugly, also the value of corresponding-mib-oid, 
> related-node are read only value and can not be configured by the user.
> module: ietf-data-node-tags
> augment /tags:module-tags/tags:module:
>   +--rw data-node-tags
>  +--rw data-node* [ni-id]
> +--rw ni-id  nacm:node-instance-identifier
> +--rw tag* tags:tag
> +--rw masked-tag*  tags:tag  
> +--rw corresponding-mib-oid? yang:object-identifier-128
> +--rw related-node? yang:node-instance-identifier
> In addition, we may need to introduce new yang extension for these two 
> parameters and consider to use when statement to decide when 
> corresponding-mib-oid or related-node should not appear or otherwise, I feel 
> designing this kind of model is not generic. Please correct me if I am wrong.
> 
> -Qin
> -邮件原件-
> 发件人: Jürgen Schönwälder [mailto:j.schoenwael...@jacobs-university.de]
> 发送时间: 2022年4月11日 21:32
> 收件人: Qin Wu 
> 抄送: Kent Watsen ; netmod@ietf.org
> 主题: Re: [netmod] WGLC on draft-ietf-netmod-node-tags-06
> 
> It seems like we confuse use cases with mechanisms. We should IMHO focus on 
> defining one mechanism to convey metadata and ideally that mechanism than 
> supports multiple use cases.
> 
> /js
> 
> On Mon, Apr 11, 2022 at 01:14:08PM +, Qin Wu wrote:
> > Hi, Jurgen:
> > Thank for bringing this issue up.
> > Generally, I feel two drafts are orthogonal to each other. 
> > Draft-ietf-netmod-node-tags-06 focuses on YANG modelled data 
> > classification while draft-claise-netconf-metadata-for-collection-03 
> > focuses on telemetry related server capability exposure, e.g., how frequent 
> > you can use YANG push mechanism to send the telemetry data, from where to 
> > collect the specific interested data, how to inform the client or collector 
> > when the server compute a new observable period, in other words, 
> > draft-claise-netconf-metadata-for-collection-03 more focuses on data 
> > collection protocol (e.g., yang push) related metadata.
> > 
> > In addition, draft-ietf-netmod-node-tags-06 doesn't need to depend on 
> > notification capability defined in RFC9196 since ietf-data-object-tags in 
> > draft-ietf-netmod-node-tags-06 defines data objects list under 
> > /tags:module-tags/tags:module. Therefore the client can look for these tags 
> > from the ,  also can be used since yang extension 
> > is defined for these tags in the ietf-data-object-tags.
> > 
> > Please correct me if I am wrong. 
> > 
> > -Qin
> > -邮件原件---

[netmod] FW: New Version Notification for draft-ma-netmod-with-system-03.txt

[maqiufang (A)]

Hi, all

V-03 is available now: 
https://www.ietf.org/archive/id/draft-ma-netmod-with-system-03.txt.

This version addresses comments raised by Balazs (thank you Balazs for your 
valuable comments).

The main changes are following:

• Define a RESTCONF capability URI for “resolve-system” RESTCONF 
query parameter;

• Augment  RPC operation to support "resolve-system" 
as input parameter;

• Editorial changes for clarification and explanation, which 
includes:

o More clear definition of system configuration

o Make it clear in the draft that  must always be valid

o Make it clear that any update of  will not cause the 
automatic update of 

o Make it clear the relationship between “read-only to clients” and 
“modifying system configuration”

o Try to clarify non-deletable system configuration;



Best Regards,

Qiufang



-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
Sent: Monday, April 11, 2022 10:40 AM
To: Fengchong (frank) ; Fengchong (frank) 
; Jan Lindblad ; Kent Watsen 
; Qin Wu ; Qin Wu 
; maqiufang (A) 
Subject: New Version Notification for draft-ma-netmod-with-system-03.txt





A new version of I-D, draft-ma-netmod-with-system-03.txt

has been successfully submitted by Qiufang Ma and posted to the IETF repository.



Name:  draft-ma-netmod-with-system

Revision:  03

Title:  System-defined Configuration

Document date:   2022-04-10

Group:  Individual Submission

Pages:   43

URL:
https://www.ietf.org/archive/id/draft-ma-netmod-with-system-03.txt

Status: https://datatracker.ietf.org/doc/draft-ma-netmod-with-system/

Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ma-netmod-with-system

Diff:   https://www.ietf.org/rfcdiff?url2=draft-ma-netmod-with-system-03



Abstract:

   This document updates NMDA [RFC8342] to define a read-only

   conventional configuration datastore called "system" to hold system-

   defined configurations.  To avoid clients' explicit copy/paste of

   referenced system-defined configuration into the target configuration

   datastore (e.g., ), a "resolve-system" parameter has been

   defined to allow the server acting as a "system client" to copy

   referenced system-defined nodes automatically.  The solution enables

   clients manipulating the target configuration datastore (e.g.,

   ) to overlay and reference nodes defined in ,

   override values of configurations defined in , and configure

   descendant nodes of system-defined nodes.









The IETF Secretariat




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

Re: [netmod] Balazs Review of draft-ma-netmod-with-system-02

[maqiufang (A)]

Hi, Balazs,

Please see my reply inline.
From: Balázs Lengyel [mailto:balazs.leng...@ericsson.com]
Sent: Friday, April 1, 2022 1:22 AM
To: maqiufang (A) ; Jan Lindblad 
Cc: 'netmod@ietf.org' 
Subject: RE: [netmod] Balazs Review of draft-ma-netmod-with-system-02

Hello Qiufang,
While it is possible to understand the draft in a correct way, I still believe 
that a few things should be much more explicit, would require strong straight 
statements:
- Definition of what is system configuration
- Update of  datastore has no effect on the  datastore even if 
some of it  has been copied over to  earlier.
- Contents of  are modifiable or not following the general YANG and 
NACM rules even if some of it  has been copied over to  
earlier. Any further restriction will be defined in a separate “immutable” 
draft.
Etc.
Sure, the authors will update the draft to reflect the latest discussion and 
thoughts.

I understand that the immutable draft can work without the system draft, but I  
don’t know if the system draft can work without the immutable draft. What is 
your opinion?

Yes, the immutable draft can work without the system draft.
Without immutable draft, the client may encounter some errors if it attempts to 
update a non-modifiable system-defined node. But the server today could reject 
any unreasonable request (more than just attempts to modify read-only data 
nodes) in the real world.
While immutable draft tries to make immutability information transparent, it’s 
hard to say that it can avoid all potential error responses but only help 
identify and understand why *some* of the edit requests are denied.
So I think it is okay for system draft to work without the immutable draft. But 
immutable draft does help complete the with-system solution.

Regards Balazs

Best Regards,
Qiufang

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

Re: [netmod] Balazs Review of draft-ma-netmod-with-system-02

[maqiufang (A)]

Hi, Balazs,
Thanks for your thorough review and valuable comments!
To be brief, I will incorporate some of them to the update, but I think there 
are still a couple of comments that need further discussion, like:

· Terminology to differentiate between the same(-path) data nodes in 
different datastores(e.g., system and running).

· Should "copy-config" operation also be augmented to support 
"resolve-system" parameter?

· The potential NBC issue behind this principle: If the 
"resolve-system" parameter is not given by the client, the server MUST NOT 
modify  in any way not specified by the client.

· Will the update of  be reflected into ? If not, will 
this cause an invalid  datastore?


Please also see my detailed reply inline.

Best Regards,
Qiufang
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Balázs Lengyel
Sent: Thursday, March 24, 2022 2:47 AM
To: 'netmod@ietf.org' mailto:netmod@ietf.org>>
Subject: [netmod] Balazs Review of draft-ma-netmod-with-system-02

Hello,
I did a detailed review of the system draft. My comments questions are below.
Regards Balazs

===

General)
I think this work is important and valuable, but it needs quite a lot 
improvements.

The term system-configuration is used confusingly. Does
system-configuration reside in the  datastore only or can it
reside in the  datastore too? If system-configuration is copied by
the client (+) into the  datastore is it
still system-configuration? It is set by the client this time not the system.
[Qiufang] Yes, I agree.
System configuration is provided by the device in  datastore, though I 
think it may also be present in  with origin="system".
If it is copied/pasted into , the copied configuration in  
should not be called as "system configuration".
But I think it's okay to say something like "copy system configuration into 
", the object to be copied is system configuration which is defined in 
.
I will see how to make this clearer in the next version.
Some terminology is needed to indicate that you mean a specific data node
IN A SPECIFIC DATASTORE. The same data node (according to the path in the
data tree) in different datastores need to be referenced separately.
[Qiufang]Cross-datastores references is not the intention here.
Any suggestions to make it clear or what does the terminology looks like in 
your mind?

Does the solution allow conditional system configuration?
(E.g.,  if the client creates an OSPF interface the system inserts a child leaf 
into it)
[Qiufang] Yes, it does. System configurations which are provided and activated 
based on specific conditions being met in a system, it is defined as 
"Conditionally-Active system configuration".
https://datatracker.ietf.org/doc/html/draft-ma-netmod-with-system-02.txt#section-2.2
 describes this kind of system configuration.

1.1) If system shares the same schema as running that would force it to
populate mandatory nodes.  That might be a problem.
State that mandatory or min-elements might not be enforced in .
[Qiufang] I think that mandatory or min/max-elements nodes should be enforced 
in . There should be no exceptions.
What's the problem that you think might happen?
1.3) "client may overwrite values of configurations defined in "
However it also states: The contents of  datastore are read-only
These seem to contradict. Please clarify.
[Qiufang]It is confusing, indeed. When it says the contents of  
datastore are read-only, I mean  is a read-only datastore, e.g., an 
 operation towards  should be refused.  But the client can 
overwrite values of configurations defined in  by writing new values in 
, which will take precedence over initial values set by the system.
How about this:
OLD:" client may overwrite values of configurations defined in "
NEW:"client may overwrite values of configurations defined in  by 
configuring the intended values in ."

1.4) Shoudn't copy-config also be effected? Copy-config
might also need system configured items. It should be mentioned that the same
"resolution" is also needed after a node-restart.
[Qiufang] Are you suggesting to augment copy-config with "resolve-system" 
parameter also?
This operation is used to replace the target configuration, so you also want 
the server to write missing referenced system nodes automatically after the 
full replacement.
But is this still a "copy-config"? Copy usually means the same to me. Do you 
have any use cases in your mind?
I think we need further discussion, or let's see if anyone has any other 
comments on this.

What does populate mean? Is it the same as "copy from system to running" ? If
yes please use that terminology. Populate is not as specific.
[Qiufang] Sure, thanks. I will reword it.

2) In the subchapters (and later) you use the terms provided, activated, 
applied. I am not
sure what this means. Is a not yet applied item present in the 
datastore or only when it is applied? If I do a get-data on 
will I 

Re: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00

[maqiufang (A)]

Hi, Andy, Balazs,

I can see your points in some of the use cases.
But as Kent mentioned, the motivation of this work is that we have some 
system-defined instance which are read-only to clients.
And there may be some cases where a list/leaf-list data node may exist in 
multiple instances with different control rules.

To be specific, An instance-level annotation could be useful in following use 
cases:

a)   The system generates some QoS templates when QoS functionality is 
enabled, and some of the generated templates are read-only, while others are 
free to be updated by the clients.

b)   The system predefines some list/leaf-list instances which are 
read-only for clients(the clients cannot update or delete them, like predefined 
NACM rules), but the clients is free to add/update/delete their own defined 
instances.

While YANG-extension can be useful for a schema-level immutability.
I am thinking that, maybe we need both to complete the solution?

Best Regards,
Qiufang

From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Andy Bierman
Sent: Thursday, March 24, 2022 7:14 AM
To: Balázs Lengyel 
Cc: NetMod WG 
Subject: Re: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00



On Wed, Mar 23, 2022 at 3:06 PM Balázs Lengyel 
mailto:balazs.leng...@ericsson.com>> wrote:


From: Andy Bierman mailto:a...@yumaworks.com>>
Sent: Wednesday, 23 March, 2022 22:32
To: Balázs Lengyel 
mailto:balazs.leng...@ericsson.com>>
Cc: NetMod WG mailto:netmod@ietf.org>>
Subject: Re: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00



On Wed, Mar 23, 2022 at 2:16 PM Balázs Lengyel 
mailto:balazs.leng...@ericsson.com>> wrote:
Hello Andy,
I also propose an extension. (see my mail Review of 
draft-ma-netmod-immutable-flag-00)
In Ericsson we saw no need for exceptions, but do see the need for applying it 
to descendant nodes. Typically we need to protect a full subtree.

Why do you need the exceptions? Could you provide some use-case examples ?

I think create/delete-only and modify-only access modes are used the most, 
after no-access.
BALAZS: How is a modify-only data-node different from a mandatory data-node? It 
must be there but can be changed. It get’s an initial value somehow.

Mandatory=true requires the system to provide a value.
Modify-only allows the system to decide when an instance is created.


BALAZS: Any examples when would a create/delete only data node be used?

Sometimes developers do not want to write complex instrumentation that supports
modification of resources.  Instead a user has to delete the old entry and 
create a new
one with (potentially) different parameters.



Applying to descendant nodes may be better, or may require more work to
undo the extension used in an ancestor node. This impacts the extension usage 
within a grouping.

BALAZS2: I did not include it in my mail, but we actually have one more rule:
“Top level statements in augment or groupings do NOT inherit
   the static-data value from containing nodes, they default to
   static-data false.”


This seems complicated to users and developers to track how the final schema 
tree was derived.

The 'static-data' extension seems fine to me.
We have to support 'user-write' anyways, so it is better if it is not too close 
to this extension.
Things that seem the same, but are NOT the same cause the most support tickets.


Regards Balazs

Andy

Andy




From: netmod mailto:netmod-boun...@ietf.org>> On 
Behalf Of Andy Bierman
Sent: Wednesday, 23 March, 2022 21:10
To: NetMod WG mailto:netmod@ietf.org>>
Subject: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00

Hi,

IMO the problem should be viewed as a refinement to the
access control policy of the device.  A standard mechanism
such as a YANG extension would be better than a growing
mix of proprietary solutions.

We have such a YANG extension called "user-write" that is widely deployed.
A simple boolean is not fine enough granularity, so a bits type is
needed instead to allow control of create, update, and delete access operations.


https://www.yumaworks.com/pub/latest/yangauto/yumapro-yangauto-guide.html#ncx-user-write


Andy

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

Re: [netmod] WGLC on draft-ietf-netmod-rfc6991-bis-11

[maqiufang (A)]

Hi, all
I have read the document and support the publication of this work.
I have only one comment: It seems that Table 2 doesn’t list all the types 
defined in “ietf-inet-types” YANG module, e.g., protocol-number, 
ip-address-link-local, ip-address-and-prefix… Should this be fixed?

Best Regards,
Qiufang

From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Kent Watsen
Sent: Tuesday, February 15, 2022 6:43 AM
To: Reshad Rahman 
Cc: netmod@ietf.org
Subject: Re: [netmod] WGLC on draft-ietf-netmod-rfc6991-bis-11

Thank you Reshad for your reply.

All, the WGLC is set to close in three days, but first there needs to be more 
responses…can others provide comments too?   Especially authors of other drafts 
in progress ;)

Thanks,
Kent  (and Lou)



On Feb 14, 2022, at 9:05 AM, Reshad Rahman 
mailto:res...@yahoo.com>> wrote:

I have reviewed this document, no concerns. I believe it is ready for 
publication.

Regards,
Reshad.

On Thursday, February 3, 2022, 09:54:23 PM EST, Kent Watsen 
mailto:kent+i...@watsen.net>> wrote:


Dear NETMOD WG,

This message begins a two-week WGLC for draft-ietf-netmod-rfc6991-bis-11 ending 
on Friday, February 18th.  Here is a direct link to the HTML version of the 
draft:

https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc6991-bis-11.html

Positive comments, e.g., "I've reviewed this document and believe it is ready 
for publication", are welcome!  This is useful and important, even from 
authors.  Objections, concerns, and suggestions are also welcomed at this time.

Thank you,
Kent (as co-chair)

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

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

[netmod] FW: New Version Notification for draft-ma-netmod-with-system-01.txt

[maqiufang (A)]

Hi, all
V-01 is available now: 
https://www.ietf.org/archive/id/draft-ma-netmod-with-system-01.txt. 
According the discussion around system configuration on the list, especially 
the thread "MUST offline-validation of  alone be required" (thank you 
all for being involved in the discussion and sharing your valuable ideas) , the 
authors tried to seek convergence and updated the draft based on some folks' 
comments.
The most significant changes compared to the previous version are to remove the 
"with-system" query parameter and define a new parameter named "resolve-system" 
to allow the server to copy referenced system configuration automatically in 
order to make  valid.
Clients unware of this parameter can explicitly declare the referenced system 
configuration on their own to satisfy the referential integrity of .

For more details, please review the draft, comments and suggestions are welcome!

Best Regards,
Qiufang


-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: Friday, February 11, 2022 6:43 PM
To: Fengchong (frank) ; Fengchong (frank) 
; Jan Lindblad ; Qin Wu 
; Qin Wu ; maqiufang (A) 

Subject: New Version Notification for draft-ma-netmod-with-system-01.txt


A new version of I-D, draft-ma-netmod-with-system-01.txt
has been successfully submitted by Qiufang Ma and posted to the IETF repository.

Name:   draft-ma-netmod-with-system
Revision:   01
Title:  System-defined Configuration
Document date:  2022-02-11
Group:  Individual Submission
Pages:  40
URL:
https://www.ietf.org/archive/id/draft-ma-netmod-with-system-01.txt
Status: https://datatracker.ietf.org/doc/draft-ma-netmod-with-system/
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ma-netmod-with-system
Diff:   https://www.ietf.org/rfcdiff?url2=draft-ma-netmod-with-system-01

Abstract:
   This document updates NMDA [RFC8342] to define a read-only
   conventional configuration datastore called "system" to hold system-
   defined configurations.  To avoid clients' explicit copy/paste of
   referenced system-defined configuration, a "resolve-system" parameter
   has been defined to allow the server acting as a "system client" to
   populate referenced system-defined nodes automatically.  The solution
   enables clients to reference nodes defined in , overwrite
   values of configurations defined in , and configure
   descendant nodes of system-defined nodes.


  


The IETF Secretariat


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

[netmod] FW: New Version Notification for draft-ma-netmod-immutable-flag-00.txt

[maqiufang (A)]

Hi, all



This "immutable metadata annotation" document is derived from 
draft-ma-netmod-with-system.

It can be used to decorate the data node instances which are "config true" but 
cannot be changed by configuration operations.



There are some ongoing discussion around this work:

https://mailarchive.ietf.org/arch/msg/netmod/lk5BuvPCbLcVui5bFKxgNFSWOCw/



Please feel free to review and comment.



Best Regards,

Qiufang Ma



-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
Sent: Thursday, February 10, 2022 7:23 PM
To: Hongwei Li ; Qin Wu ; Qin Wu 
; maqiufang (A) 
Subject: New Version Notification for draft-ma-netmod-immutable-flag-00.txt





A new version of I-D, draft-ma-netmod-immutable-flag-00.txt

has been successfully submitted by Qiufang Ma and posted to the IETF repository.



Name:  draft-ma-netmod-immutable-flag

Revision:  00

Title:  Immutable Metadata Annotation

Document date:   2022-02-10

Group:  Individual Submission

Pages:   15

URL:
https://www.ietf.org/archive/id/draft-ma-netmod-immutable-flag-00.txt

Status: https://datatracker.ietf.org/doc/draft-ma-netmod-immutable-flag/

Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ma-netmod-immutable-flag





Abstract:

   This document defines a metadata annotation [RFC7952] named

   "immutable" to indicate the immutability of a particular instantiated

   data node.  Any instantiated data node annotated with

   immutable="true" by the server is read-only to the clients of YANG-

   driven management protocols, such as NETCONF, RESTCONF and other

   management operations (e.g., SNMP and CLI requests).









The IETF Secretariat




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

Re: [netmod] system DS polluting intended and operational

[maqiufang (A)]

Hi, Jason,
Please see my reply inline.

-Original Message-
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Sterne, Jason (Nokia 
- CA/Ottawa)
Sent: Monday, January 10, 2022 11:14 PM
To: Juergen Schoenwaelder 
Cc: maqiufang (A) ; netmod@ietf.org
Subject: Re: [netmod] system DS polluting intended and operational

Please see inline.

> -Original Message-
> From: Jürgen Schönwälder 
> Sent: Thursday, December 9, 2021 1:19 PM
> To: Sterne, Jason (Nokia - CA/Ottawa) 
> Cc: maqiufang (A) ;
> netmod@ietf.org
> Subject: Re: [netmod] system DS polluting intended and operational
> 
> On Thu, Dec 09, 2021 at 05:51:48PM +, Sterne, Jason (Nokia - 
> CA/Ottawa)
> wrote:
> > I wonder if having all the system config appear in intended and 
> > operational
> may be annoying. We didn't want to pollute running with 100s/1000s of 
> lines of unreferenced system config. So maybe putting all that in 
> intended & operational is also ugly ?
> >
> 
> The applied config, part of operational, is the config that is 
> actually used by the device. RFC 8342 has the details.

[>>JTS: ] RFC 8342 (rightly) leaves a lot of grey zone around what is 
considered used/active and what an implementation is allowed to return in 
.  But I'm also concerned about polluting intended.
[Qiufang Ma] I never think that all the system configuration will appear in 
. E.g., I don’t think inactive-until-referenced( which is defined 
in 
https://datatracker.ietf.org/doc/html/draft-ma-netmod-with-system-00.txt#section-2.3)
  system configuration will present in  before it’s referenced.
The presence of system configuration in  only dependents on 
whether it plays a role in current operational functionality of the device. 
Going against the definition of  is not the intention.
IMHO there is no such thing as "pollute /", if a 
particular system-defined node is actually in use, it should be present in 
, otherwise it is not.
As defined in  NMDA,  holds the configuration that the device 
attempts to apply. I think we all agree that referenced system configuration 
should appear in . 
But unreferenced system configuration(including expansion of system-defined 
template) is also what is intended to be used by the device and should be 
subject to validation. Once it is applied successfully, it will appear in 
.

> 
> > We should have *some* way that a client can retrieve system
> configuration though.
> >
> > Some potential options (without system flowing 100% of its contents 
> > into
> intended):
> > a)  DS that can be read (but doesn't flow into intended or
> operational)
> > b) a "with-system" extension (like "with-defaults"). Returns a merge 
> > of
> running+system (or candidate+system, or intended+system).
> 
> You want to rewrite RFC 8342?

[>>JTS: ] I think we're already discussing potential changes to "system" config 
in this draft (i.e. having system config flow into intended instead of 
operational). Maybe we won't do that in the end, but while we're discussing it 
I wanted to raise other options for consideration to avoid the potential 
pollution.
[Qiufang Ma] Happy to discuss other options without breaking the definition of 
/.:-)

> 
> > Maybe we'd also want (or maybe want instead) is a way to see
> *referenced* system config (either on its own, or merged with another DS).
> 
> The 'referenced system config' has to be in running since otherwise it 
> can't be referenced.

[>>JTS: ] That's a big part of the debate going on around this draft. I'm 
leaning the same way as you on this point (for system config), but there 
doesn't seem to be agreement in the working group. Having the referenced config 
(at least the list key) explicitly configured by the user in running is a 
solution I like for this system config problem, but I don't see how we'll 
handle config templates if running must be valid.  (we should continue that 
debate on the thread "Must offline-validation of  alone be valid?" 
though).
[Qiufang Ma] On the heavy debate on "MUST offline-validation of  alone 
be valid", the authors are trying to make a compromise to define that all the 
referenced system configuration MUST be present in  and allow the 
system to auto-populate referenced system configuration into  if the 
client isn’t willing to explicitly configure by themselves.
But I also agree with you that, even we define that the referenced system 
configuration should be in , the problem may still exist if the 
validation against the configuration dependents on the template expansion (to 
populate mandatory fields, satisfy constraints on leafref or when/must 
statement, etc).
> 
> /js
> 
> --
> Juergen S

Re: [netmod] Must offline-validation of alone be valid?

[maqiufang (A)]

Hi, Andy, all

From: Andy Bierman [mailto:a...@yumaworks.com]
Sent: Saturday, December 18, 2021 2:06 AM
To: Kent Watsen 
Cc: maqiufang (A) ; netmod@ietf.org
Subject: Re: [netmod] Must offline-validation of  alone be valid?



On Fri, Dec 17, 2021 at 7:11 AM Kent Watsen 
mailto:kent%2bi...@watsen.net>> wrote:
Andy, et. al.,


I cannot find any RFC text that says  has only nodes created by a 
client.

Really?  Interesting.   Still, I know it’s a mantra we’ve held closely for many 
year, right?

No. Quite the opposite.  
[Qiufang Ma] Kent and Jason said that the “shared objects” is the primary 
 configuration use cases. I do agree. In Huawei’s implementation, The 
server also generates hundreds of system data objects(service templates, 
predefined policies, etc). Physical resource related configuration is really 
only a small part of that.
And as you mentioned, there is no RFC text says  have only nodes 
created by a client. Actually, in our implementation, we do allow system 
configuration to be populated into  automatically when it is 
generated, because copy/paste for reference is painful. That is, all the system 
configuration is really a part of . But our customers do complain that 
when retrieving  they usually find a large number of configuration 
data objects not defined by themselves, most of which are irrelevant to their 
own configurations and they have no idea where they are come from.
I also tried to bring this idea to the 
IETF(https://datatracker.ietf.org/doc/html/draft-ma-netconf-with-system-02#section-3.1)
 and would like to collect some more feedback, it seems that the WG thinks we 
want the client to fully own the running datastore, the server should never 
auto-populates  unless asked by the clients.

Best Regards,
Qiufang Ma

There was a brouhaha back when I proposed the "keystore” draft have an “action” 
called “generate-private-key” that would insert the generated key into 
.  Claims were made by prominent members of this list that it’s bad 
form for anything but a client to edit .

As a result, extensive effort was spent defining a mechanism enabling the 
generated key to be returned in the RPC-reply in an encrypted form (such that 
only the server that generated the key could decrypt it), all so the client 
could immediately return it to the server via a config push in order to 
preserve the sanctity of client read-backs.

If current claims were true then, why didn’t someone just say it’s okay since 
the server is acting like a client under the hood?

Maybe not a lot of non-security people were following the thread.
IMO a better design would have been to introduce a "secure-NV-storage" concept.
The keys are never exposed. Only labels are exposed and the client can store a 
reference to the key in .
Maybe Juergen proposed this idea.

YANG-based management assumes that the conceptual API for a YANG device
can be described by all the [module, revision, features, deviations] tuples 
(YANG library).
There was an original assumption that  could contain all the 
information to
describe this "real API".

The original design was too simplistic so NMDA introduced  and 
 datastores.
Now  no longer represents the "real API". It now contains some or all 
of the information required
to produce the real API, which is now deemed to be .

Not one of the mechanisms to transform  into  is 
standardized.
Now  + ??? is a combination of the real API and the "proprietary setup 
API".

It has never been true that  is always valid. In hindsight, that MUST 
is really a SHOULD, post-NMDA.
Inactive nodes cannot be counted against constraints (e.g. must, 
min/max-elements, unique).
Constraints on config templates do not address the needed constraints on the 
expanded data.

IMO it is too late "fix"  by placing any restrictions on the contents 
or who can edit it.
NMDA (wisely) did not do it.  A "system edit" is difficult to describe,
especially in a controller-driven bootstrap framework.  The immuable issue
is just hidden access control, so tag data nodes with new metadata to expose 
that.



K.


Andy

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

Re: [netmod] Must offline-validation of alone be valid?

[maqiufang (A)]

Hi, all

I agree that option #1 will overwhelm a client severely.

Avoid-copying and client-control over  written in the introduction of 
draft-ma-netmod-with-system-00 are actually two competing objectives, if the WG 
thinks offline-validation of  alone IS required,
I think we need to make a compromise. Option #2 may provide a good starting 
point.

Regarding open #3, it is natural for the clients to believe that what they read 
back from the server is exactly what they sent to the server.
If there is a "system client" playing a role, this would require some extra 
handling for the other remote clients and bring them surprise and inconvenience.

Best Regards,
Qiufang Ma

From: Andy Bierman [mailto:a...@yumaworks.com]
Sent: Thursday, December 9, 2021 6:50 AM
To: Sterne, Jason (Nokia - CA/Ottawa) 
Cc: Juergen Schoenwaelder ; Jan Lindblad 
; Kent Watsen ; maqiufang (A) 
; netmod@ietf.org
Subject: Re: [netmod] Must offline-validation of  alone be valid?



On Wed, Dec 8, 2021 at 2:31 PM Sterne, Jason (Nokia - CA/Ottawa) 
mailto:jason.ste...@nokia.com>> wrote:
Hi guys,

Andy - about use cases.  Here is a problem we're trying to address:

There are at least several major router implementations that have this concept 
of "hidden config" (i.e. list entries that can be referenced in a leafref by 
explicit user config, but those list entries are not returned in a 
).



Clearly not in compliance with RFC 7950.

IMO the "enable flag" approach to the general problem, presented by Kent a 
couple years ago,
is a much simpler and better solution than a new  datastore.
The full set of nodes is in .
A generalized "enable" mechanism causes the resource to be used or not,
where it shows up in  and  if enabled=true.

IMO this fits the original intent of NMDA and does so in a way that requires
the least disruption to current compliant implementations.

Andy


The server accepts these configurations (i.e. a validate or commit succeeds), 
but if you actually validate (e.g. with yangLint) the running datastore 
contents (e.g. fetched using ) to the YANG model it is not valid. 
That is against several RFCs referenced in the discussions below.

IMO there isn't any "offline" vs" online" validation that is different. The 
contents of the running must be valid against the YANG model.  A  
returns the contents of the running.  The server can validate it, or some other 
entity can validate it, but it must be valid.

In Jan's option #1 the running config could be polluted with 100s or 1000s of 
lines of unreferenced/unused config. A  of a system without much 
config would instead return 100s/1000s of lines. I think that would be very 
annoying from a usability perspective.

I'm in favor of this aspect of Jan's option #2:  " + Clients unaware of the 
system datastore would have to include (copy) information from the system 
datastore to running in order to reference them."

-> Only the list keys of referenced system objects would have to be copied 
(configured) into the running DS (to resolve leafrefs).  We wouldn't need to 
copy all the descendant elements inside the referenced object.
-> This copying would only need to be done by operators with a workflow that 
requires offline validation

Some of this approach is already described in draft-ma-netmod-with-system-01:

"   In all cases, the clients should have control over the configurations
   ,i.e., read-back of  should contain only what was explicitly
   set by clients."


"4.3.  Explicit declaration of system configuration

   In addition to modifying system configuration, and adding nodes to
   lists in system configuration as described above, a client can also
   explicitly declare system configuration nodes in  with the
   same values as in .  When a client configures a node (list
   entry, leaf, etc) in  that matches the same node & value in
   , then that node becomes part of .  A read of
returns those explicitly configured nodes.

   This explicit configuration of system configuration in  can
   be useful, for example, when an operator's workflow requires a client
   or offline tool to see the  configuration as valid.  The
   client can explicitly declare (i.e.  configure in ) the list
   entries (with at least the keys) for any system configuration list
   entries that are referenced elsewhere in .  The client does
   not necessarily need to declare all the contents of the list entry
   (i.e. the descendant nodes) - only the parts that are required to
   make the  appear valid offline.  "

I'm not a fan of option #3. It doesn't allow a mode of operating where a 
client/OSS has full control over the contents of the .  Some operators 
will want the master config to be owned up in their client/OSS and push it 
down. The server should just accept it and the client should be able to do a 
"read-back" and see exactly w

Re: [netmod] "immutable" flag

[maqiufang (A)]

Hi, Jason,

Thanks for your comments, please see my reply inline.

From: Sterne, Jason (Nokia - CA/Ottawa) [mailto:jason.ste...@nokia.com]
Sent: Thursday, December 9, 2021 6:42 AM
To: maqiufang (A) ; netmod@ietf.org
Subject: RE: [netmod] "immutable" flag

Hi Qiufang,

I think there are use-cases for "immutable" even outside of system config so we 
may not want to restrict it to system config.
[Qiufang Ma] Agree that we can just define such an "immutable" flag without 
restricting it to decorating system configuration. In that way, maybe we can 
discuss whether we should define this annotation in an independent I-D.
Regarding this "immutable" flag  there may be a question to answer: what if 
legacy clients receive some annotations they do not understand? Should they 
just ignore it silently?

I'm not sure it would be as simple as erroring when a write is attempted to 
that value.

Are you talking about an error at edit time, or at commit/validation time ?
[Qiufang Ma] My assumption is an error at edit time, static checks are 
sufficient for the server to detect the problem. But I think it's also okay to 
report an error at commit/validation time.
What if the value configured is the same as the current value ?
[Qiufang Ma] I have the same question. Some implementations do allow the client 
to configure a same value(e.g., for the purpose of offline validation of 
). But I feel that it may depend on the discussion of another thread 
"should the origin='system' be required for system configurations copied/pasted 
into '" which I posted to the WG. If the origin="intended" , it 
actually means overwrite.

It is probably best if this is a validation/commit time check.

If the immutable leaf is inside a list entry, then it should probably be 
acceptable for the server to allow a change to the leaf by destroying and 
re-creating the list entry under the hood.  i.e. allow a change to the 
immutable item (which is in line with configurations being "declarative" - just 
get me there if possible).
[Qiufang Ma] Are you suggesting a server should allow a client to delete/create 
the "immutable" data item in ? Wouldn't that be a little strange if a 
client can delete a particular data item but has no right to change its value?  
Theoretically, the deletable is modifiable.

Best Regards,
Qiufang Ma

Jason

From: netmod mailto:netmod-boun...@ietf.org>> On 
Behalf Of maqiufang (A)
Sent: Monday, November 22, 2021 7:12 AM
To: netmod@ietf.org<mailto:netmod@ietf.org>
Subject: [netmod] "immutable" flag

Hi, all

There are some system configuration which may not be modifiable for 
clients(e.g., interface "name" and "type"). Should we define an "immutable" 
flag to indicate to the clients which system configuration is read-only or 
which is not?

The server will return an error if the clients attempt to configure a value for 
a system defined data node with an "immutable" flag.

My assumption is that this annotation should be carried only when the clients 
retrieve  with "with-system" parameter to get  a merged view.

Suggestions, comments and concerns about this issue?


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

Re: [netmod] Should the "with-origin" parameter be supported for ?

[maqiufang (A)]

Hi, Jason
Thanks for kicking off some discussion around this question.
Please see my reply inline.

From: Sterne, Jason (Nokia - CA/Ottawa) [mailto:jason.ste...@nokia.com]
Sent: Thursday, December 9, 2021 6:51 AM
To: maqiufang (A) ; netmod@ietf.org
Subject: RE: [netmod] Should the "with-origin" parameter be supported for 
?

Hi Qiufang,

In your first option, did you mean "understand a certain data node is from 
 or from " ?
[Qiufang Ma] Yes, you're correct. We already define that a data node which is 
present in  and not overwritten by  will appear in 
 with "origin=system" as always when applied successfully. So the 
server needs to remember whether a particular data node in  is from 
 or from . The question is should the server expose this 
source information to the client.

It is an interesting question about whether the origin annotation could/should 
be available in a read from , and what values that origin could take.

We should consider other transformations between  and  
(besides the merging of ):
- active/inactive config
- configuration templates

Inactive config would simply be stripped and not appear in  at all. 
So nothing to discuss for that.

But would elements provided from within config templates have an 'origin' that 
indicates what template it came from ?
[Qiufang Ma] I am not quite sure what do you mean by "what template it came 
from". But for the client-defined template in , elements provided from 
within the config template will exist in  and finally have an 
origin="intended" when present in . I believe that this is already 
well defined in NMDA work.

I suppose the same question could apply to 'origin' in the  DS.

Having origin purely available in the operational DS may not be complete 
enough. Some config nodes may not be present in operational because they are 
not "applied". So you wouldn't necessarily be able to get the full picture of 
the origin of all intended config by just checking the origin in the 
 DS. Maybe that's an argument to have an origin in  ?
[Qiufang Ma] That is a good point.  only contains those are 
actually used by the system. It might be useful if a client can fetch 
 can understand the origin of some data nodes which is after 
configuration transformation(e.g., client-defined/system-defined templates 
expansion) but may not be successfully applied by the device.

Best Regards,
Qiufang Ma

Jason

From: netmod mailto:netmod-boun...@ietf.org>> On 
Behalf Of maqiufang (A)
Sent: Monday, November 22, 2021 7:11 AM
To: netmod@ietf.org<mailto:netmod@ietf.org>
Subject: [netmod] Should the "with-origin" parameter be supported for 
?

Hi, all

In the "system-defined configuration(draft-ma-netmod-with-system)" work, an 
optional datastore named "system" is introduced to hold non-deletable system 
configurations.
We define that if a server implements ,  MUST be merged into 
.  So there is the cases that the clients can fetch  and 
 contains merged .
The question is should we extend the "with-origin" parameter to support 
? The possible considerations for following two choices:
o  "with-origin" parameter should be supported for 
?  It may be helpful for a client to fetch  to understand a certain 
data node is from  or from 
o  There is no need for  to support "with-origin"
?  We already have  to provide the origin for a particular data 
node
Any thoughts on this?


Best Regards,
Qiufang Ma

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

Re: [netmod] Should the origin="system" be required for system configurations copied/pasted into ?

[maqiufang (A)]

Hi, Jurgen, Martin,

-Original Message-
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Martin Bj?rklund
Sent: Thursday, November 25, 2021 8:02 PM
To: j.schoenwael...@jacobs-university.de
Cc: maqiufang1=40huawei@dmarc.ietf.org; netmod@ietf.org
Subject: Re: [netmod] Should the origin="system" be required for system 
configurations copied/pasted into ?

Jürgen Schönwälder  wrote:
> I personally believe this notion of a system datastore is actually a 
> bad idea. A loopback interface, for example, is system generated and 
> it exists in operational but usually not in intended. I think it is 
> wrong to think that a system datastore feeds into intended. After all, 
> system config also comes and goes at the will of the system. I am not 
> following this in detail but I fear this work likely creates more 
> damage than that is solves serious real-world problems.
[Qiufang Ma] There is often a desire to reference a system configuration or 
configure a descendant node of system configuration. How to keep 
/ valid when leaf-ref a system configuration which is only 
present in ?   Or do we think that explicitly configuration in 
 should always be the case?

I strongly agree.  I didn't understand that part of the proposal.  I guess the 
discussion about origin system confused me; if system feeds into intended then 
the origin will be intended.
[Qiufang Ma] If  feeds into , the server MUST remember a 
particular data node is from system or from intended, those previously present 
in  with origin=system will keep the origin unchanged. This work 
does not change that behavior. 

Best Regards,
Qiufang Ma


/martin



> 
> /js
> 
> On Thu, Nov 25, 2021 at 09:45:56AM +, Rob Wilton (rwilton) wrote:
> > Hi Martin,
> > 
> > I think that the proposal is that  should feed into  
> > rather than directly into .  The reasoning for this is to 
> > allow configuration to depend on system defined configuration during 
> > validation without requiring that configuration to be copied into 
> > .  Clients would still be allowed to explicitly express the system 
> > configuration is running as well - e.g., if they wanted a full 
> > configuration that they can validate off box.
> >  
> > In your example below, I would probably mark the origin of the lo 
> > interface, the name leaf, and description leaf as "intended", but the type 
> > is "system".  I think that this would be similar to how I would expect a 
> > default value to be reported.  I.e., if the running config explicitly sets 
> > a leaf to its default value, I think that it is more informative to report 
> > that as origin "intended" rather than "origin" default.  But I don't think 
> > that RFC 8342 proscribes what is be used in these cases.
> > 
> > Regards,
> > Rob
> > 
> > // As a contributor
> > 
> > 
> > > -Original Message-
> > > From: netmod  On Behalf Of Martin 
> > > Björklund
> > > Sent: 24 November 2021 10:44
> > > To: j.schoenwael...@jacobs-university.de
> > > Cc: maqiufang1=40huawei@dmarc.ietf.org; netmod@ietf.org
> > > Subject: Re: [netmod] Should the origin="system" be required for 
> > > system configurations copied/pasted into ?
> > > 
> > > Jürgen Schönwälder  wrote:
> > > > On Wed, Nov 24, 2021 at 03:21:14AM +, maqiufang (A) wrote:
> > > > >
> > > > > But suppose the node is a list entry (e.g., an interface) or a 
> > > > > leaf with the
> > > same value.  In this case, it is not clear which origin should be 
> > > used.  I think it would be ok to use "system" in this case.
> > > >
> > > > For me,  is explicit config and hence it has 
> > > > precedence. The precedence must be a function of how the 
> > > > datastores related, it should not depend on which values a config leaf 
> > > > has.
> > > 
> > > Here's a simple example.
> > > 
> > > Suppose  has:
> > > 
> > >
> > >  lo
> > >  loopback
> > >  added by system
> > >
> > > 
> > > and  has:
> > > 
> > >
> > >  lo
> > >  set by a client
> > >
> > > 
> > > Now we follow the picture in RFC 8342:
> > > 
> > >   ++
> > >   |  | // subject to validation
> > >   | (ct, ro)   |
> > >   ++
> > > |  

Re: [netmod] Must offline-validation of alone be valid?

[maqiufang (A)]

Hi, Jan,

I do remember that. You mentioned it to me after the interim but I was trying 
to document the discussion in the interim meeting at that time.
I am very glad to bring your proposal to the WG, if the WG thinks it is the 
case that offline validation of  alone is required.

If my understanding is correct, you suggest there is a new flag(we can call it 
“with-system-auto”) added to the “edit-config” operation for the clients 
expected to be lazy.
When this flag is carried, it indicates to the sever to auto-populate 
referenced but missed system data node into  for the operation to be 
valid.
For the client expected not to be lazy, it’s also the cases that they could 
explicitly copy/paste system config in  without “with-system-auto” 
flag.

What I am not sure is whether this goes against our goal of 
“client-control(i.e., a read-back of  should contain only what was 
explicitly set by the clients)”, or it is a compromise that had to be made.

Best Regards,
Qiufang Ma
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Jan Lindblad
Sent: Wednesday, November 24, 2021 1:57 AM
To: Belotti, Sergio (Nokia - IT/Vimercate) 
mailto:sergio.belo...@nokia.com>>
Cc: maqiufang (A) 
mailto:maqiufang1=40huawei@dmarc.ietf.org>>;
 netmod@ietf.org<mailto:netmod@ietf.org>
Subject: Re: [netmod] Must offline-validation of  alone be valid?

Sergio, Qiufang,

Hi Jan,
You correctly wrote:

Then the choices become:
oOffline validation of  alone is NOT required
§  Servers internally validate  via validating 
§
SB> but in fact this is what declared, for my understanding, in RFC 8342, for 
which “validation” is done on “intended” by the server , as also shown in 
figure 2 of the RFC. Is it needed to change also RFC?

According to RFC 8342, *both* running and intended have to be valid at all 
times. Section 5.1.3 says:


5.1.3<https://datatracker.ietf.org/doc/html/rfc8342#section-5.1.3>.  The 
Running Configuration Datastore ()

...

 However,

MUST always be a valid configuration data tree, as defined

   in Section 8.1 of 
[RFC7950]<https://datatracker.ietf.org/doc/html/rfc7950#section-8.1>.

Section 8.1 of RFC 7950 was the section I referred to in my previous comment. 
Section 5.1.4 says:


5.1.4<https://datatracker.ietf.org/doc/html/rfc8342#section-5.1.4>.  The 
Intended Configuration Datastore ()

...

is tightly coupled to .  Whenever data is written

   to , the server MUST also immediately update and validate

   .

In my judgement, changing the fundaments of RFC 7950 and 8342 is not going to 
happen any time soon (for good reason), and there are other (better) options.

oOffline validation of  alone IS required
§  Options:
1.   Clients MUST copy/paste any referenced system configuration into 
, even though it goes against our objective of avoiding-copy when 
possible.
2.   Defer work to be a YANG-next effort.

In order to move forward, I would propose working out some more options in this 
list. I have suggested a few to the authors that I think are better than the 
two above, but I will leave it to the authors make the call for what they want 
to bring up for discussion.

Best Regards,
/jan

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

Re: [netmod] Should the origin="system" be required for system configurations copied/pasted into ?

[maqiufang (A)]

Hi, Martin,

Please see my reply inline.

-Original Message-
From: Martin Björklund [mailto:mbj+i...@4668.se] 
Sent: Tuesday, November 23, 2021 3:39 PM
To: maqiufang (A) 
Cc: netmod@ietf.org
Subject: Re: [netmod] Should the origin="system" be required for system 
configurations copied/pasted into ?

Hi,

"maqiufang \(A\)"  wrote:
> Hi, all
> 
> There is still another issue which is about origin metadata
> annotation: should the origin="system" be required for system 
> configurations copied/pasted into ?

I think the question is "if a node is present both in  and in 
, which origin does it have in "?

(NOTE: it doesn't matter if the value was "copy & pasted" from  or 
entered in some other way.)
[Qiufang Ma] Noted, thanks.

Obviously, if a leaf node is present in both, but its value differ, the origin 
must indicate which datastore had precedence.
[Qiufang Ma] Yes, exactly. If a client tries to modify a system-defined data 
node(with a different value),  what has been defined in  should take 
precedence over system predefined nodes if the system configuration is 
modifiable. Thus the origin should be indicated as "intended", there is no 
question about that. 

But suppose the node is a list entry (e.g., an interface) or a leaf with the 
same value.  In this case, it is not clear which origin should be used.  I 
think it would be ok to use "system" in this case.
(But also perhaps it doesn't matter much).
[Qiufang Ma] "Copy&paste" just refers to this case(a leaf with a same value or 
an ancestor node like "interface"). IMO, it should not be "intended" if the 
system configuration is non-modifiable(e.g., interface type or name).


> Currently any system configuration explicitly declared in  in 
> order to configure its descendant nodes or maintain  
> offline-valid will show up in  with origin=intended.
> The question behind this issue is whether we want a copied/pasted 
> system defined data node to override and take precedence over 
> .
> 
> The choices and some considerations of this issue received so far:
> o Origin=system IS required for system configuration copied/pasted 
> into  ?  I believe that "system" reflects the most accurate 
> source in this case. And only in this way, a server can allow a 
> read-only system configuration to be declared in (e.g., in 
> order to valid
> ) by the clients.

What do you mean with "a read-only system configuration [...] be declared in 
"?   is a separate datastore that clients can read, right?
[Qiufang Ma] Yes, it's related to an ongoing work 
(https://datatracker.ietf.org/doc/html/draft-ma-netmod-with-system-00.txt). 
There is a read-only "system" datastore which contains system configuration 
non-modifiable or not.
I think that non-modifiable system configuration should be allowed to write 
into (with a same value), as far as the origin is "system". Writing a 
different value for non-modifiable system config in  should return an 
error.


Best Regards,
Qiufang Ma



/martin



> ?  The challenge for this choice is on the server side. It MUST be 
> able to recognize a particular data node which explicitly defined in 
>  is actually a mirror of what is in .
> o Origin=system is NOT required for system configuration copied/pasted 
> into  ?  Good consistency. For all configurations explicitly 
> defined in , if they appear in , the origin 
> value is "intended" with no exceptions.
> o Define a system-mode which is similar to with-defaults basic mode 
> and allow a server to advertise a particular behavior ?  Does it mean 
> we could get the Pros from both choices?
> Any other thoughts?

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

[netmod] Should the origin="system" be required for system configurations copied/pasted into ?

[maqiufang (A)]

Hi, all

There is still another issue which is about origin metadata annotation: should 
the origin="system" be required for system configurations copied/pasted into 
?

Currently any system configuration explicitly declared in  in order to 
configure its descendant nodes or maintain  offline-valid will show up 
in  with origin=intended.
The question behind this issue is whether we want a copied/pasted system 
defined data node to override and take precedence over .

The choices and some considerations of this issue received so far:
oOrigin=system IS required for system configuration copied/pasted into 

?  I believe that "system" reflects the most accurate source in this case. And 
only in this way, a server can allow a read-only system configuration to be 
declared in (e.g., in order to valid ) by the clients.
?  The challenge for this choice is on the server side. It MUST be able to 
recognize a particular data node which explicitly defined in  is 
actually a mirror of what is in .
oOrigin=system is NOT required for system configuration copied/pasted into 

?  Good consistency. For all configurations explicitly defined in , if 
they appear in , the origin value is "intended" with no exceptions.
oDefine a system-mode which is similar to with-defaults basic mode and 
allow a server to advertise a particular behavior
?  Does it mean we could get the Pros from both choices?
Any other thoughts?
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] "immutable" flag

[maqiufang (A)]

Hi, all

There are some system configuration which may not be modifiable for 
clients(e.g., interface "name" and "type"). Should we define an "immutable" 
flag to indicate to the clients which system configuration is read-only or 
which is not?

The server will return an error if the clients attempt to configure a value for 
a system defined data node with an "immutable" flag.

My assumption is that this annotation should be carried only when the clients 
retrieve  with "with-system" parameter to get  a merged view.

Suggestions, comments and concerns about this issue?


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

[netmod] Should the "with-origin" parameter be supported for ?

[maqiufang (A)]

Hi, all

In the "system-defined configuration(draft-ma-netmod-with-system)" work, an 
optional datastore named "system" is introduced to hold non-deletable system 
configurations.
We define that if a server implements ,  MUST be merged into 
.  So there is the cases that the clients can fetch  and 
 contains merged .
The question is should we extend the "with-origin" parameter to support 
? The possible considerations for following two choices:

 *   "with-origin" parameter should be supported for 
*   It may be helpful for a client to fetch  to understand a 
certain data node is from  or from 
 *   There is no need for  to support "with-origin"
*   We already have  to provide the origin for a 
particular data node
Any thoughts on this?


Best Regards,
Qiufang Ma

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

[netmod] Must offline-validation of alone be valid?

[maqiufang (A)]

Hi, all
Regarding the presentation of "system-defined 
configuration(draft-ma-netmod-with-system)" in IETF 112, I would like to 
initiate a separate thread to discuss "MUST offline-validation of  
alone be valid".
This is unknown if any RFC requires offline validation of . Then the 
choices become:

 *   Offline validation of  alone is NOT required
*   Servers internally validate  via validating 
 *   Offline validation of  alone IS required
*   Options:
   *   Clients MUST copy/paste any referenced system configuration into 
, even though it goes against our objective of avoiding-copy when 
possible.
   *   Defer work to be a YANG-next effort.
Any thoughts on this?

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