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

[Kent Watsen]

This draft is successfully adopted as a NETMOD WG chartered document.

Authors, please resubmit "draft-ma-opsawg-schedule-yang-04" as 
"draft-ieft-netmod-schedule-yang-00”.  Also note that the NETMOD WG prefers to 
have all WG documents hosted on its GitHub account, on which the following repo 
has been created for you: https://github.com/netmod-wg/schedule-yang.

Kent and Lou



> On Mar 26, 2024, at 11:49 AM, Kent Watsen  wrote:
> 
> 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] YANG Versioning: filename recommendations for YANG Semver

[Kent Watsen]

> This can never happen since the '#' char is not allowed in a YANG module name.
> YANG 1.1 tools look for MODNAME[@DATE].EXT.
> If the YANG module name is not in this format the tool will not find the 
> module.

https://datatracker.ietf.org/doc/html/rfc7950#section-5.2 says:

The name of the file SHOULD be of the form:

 module-or-submodule-name ['@' revision-date] ( '.yang' / '.yin' )

The “SHOULD” (I believe) leaves open (process-wise) the possibility for an 
“update” to RFC 7950 to define an alternate file naming possibility.  Whether 
or how doing so is wise is a different conversation.

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

[netmod] WGLC on system-config-05

[Kent Watsen]

This email begins a two-week WGLC on:

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

Please take time to review this draft and post comments by April 12.  Favorable 
comments are especially welcomed.  

There is no known IPR for this document:
https://mailarchive.ietf.org/arch/msg/netmod/IpzWIAbgifXoKaNfLhEDmYbyXkY/

Kent  // co-chair 

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

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

[Kent Watsen]

All authors and contributors have responded indicating no awareness of IPR 
applying to this draft.

The Last Call call may proceed now.

Kent // chair


> On Mar 29, 2024, at 9:18 AM, Chongfeng Xie  wrote:
> 
> 
> No, I'm not aware of any IPR that applies to this draft.
> 
> Chongfeng
> 
> 发件人: Kent Watsen [mailto:kent+i...@watsen.net]
> 发送时间: 2024年3月26日 9:31
> 收件人: maqiufang (A) ; Qin Wu ; 
> Chongfeng Xie 
> 抄送: netmod@ietf.org
> 主题: 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=draft-ietf-netmod-system-config.
>  
>  
> Thanks.
> Kent Watsen (as co-chair)

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

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

[Kent Watsen]

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

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

[Kent Watsen]

All authors and contributors have responded indicating no awareness of IPR 
applying to this draft.

The adoption call may proceed now.

Kent // chair


> On Mar 25, 2024, at 7:44 PM, Kent Watsen  wrote:
> 
> [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=draft-ma-opsawg-schedule-yang
> 
> 
> Thanks.
> Kent Watsen (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

[Kent Watsen]

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

Kent // contributor



> On Mar 26, 2024, at 11:40 AM, Kent Watsen  wrote:
> 
> My last message didn’t tag all authors and contributors.
> 
> This message adds to the “To” line the following additional authors and 
> contributors:
>   - Chong Feng
>   - Kent Watsen
>   - Jan Linblad
>   - Jason Stern
> 
> Kent // chair
> 
> 
>> On Mar 25, 2024, at 9:30 PM, Kent Watsen  wrote:
>> 
>> 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=draft-ietf-netmod-system-config.
>> 
>> 
>> Thanks.
>> Kent Watsen (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

[Kent Watsen]

My last message didn’t tag all authors and contributors.

This message adds to the “To” line the following additional authors and 
contributors:
- Chong Feng
- Kent Watsen
- Jan Linblad
- Jason Stern

Kent // chair


> On Mar 25, 2024, at 9:30 PM, Kent Watsen  wrote:
> 
> 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=draft-ietf-netmod-system-config.
> 
> 
> Thanks.
> Kent Watsen (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] IPR Call on draft-ietf-netmod-system-config-05

[Kent Watsen]

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=draft-ietf-netmod-system-config.


Thanks.
Kent Watsen (as co-chair)


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

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

[Kent Watsen]

[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=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

[Kent Watsen]

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/

Kent



> On Mar 12, 2024, at 12:15 PM, Jan Lindblad (jlindbla) 
>  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) 
>>  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 
>> 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 
>> <mailto: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.time

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

[Kent Watsen]

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  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] Long trees RE: Next steps for draft-ietf-netmod-rfc8407bis

[Kent Watsen]

In addition to improving IETF-published artifacts, it would be nice if there 
were a module-browser that acted a little bit like an IDE, jumping to where in 
other modules imported bits are defined.  Perhaps in NetconfCentral or YANG 
Catalog.  This jumping behavior could exist in both the text and tree-diagram 
views.

K.


> On Mar 5, 2024, at 11:21 AM, Italo Busi 
>  wrote:
> 
> I like the idea of relying on tooling with hyperlinks
>  
> For txt and pdf, I agree that a link is the best option since these formats 
> are not optimized for including YANG trees
> 
> Italo
>  
> From: Kent Watsen  
> Sent: martedì 5 marzo 2024 16:02
> To: mohamed.boucad...@orange.com
> Cc: Italo Busi ; Qin Wu ; Mahesh 
> Jethanandani ; netmod@ietf.org
> Subject: Re: [netmod] Long trees RE: Next steps for 
> draft-ietf-netmod-rfc8407bis
>  
>  
> It seems that there are two camps:
>  
> 1) those that want the tree-diagrams to be as DRY as possible
> 2) those that want the tree-diagrams to be as WET as possible
> 
> 
>   DRY = Don't Repeat Yourself
>   WET = Write Every Time
>  
> Tooling can help both cases.
>  
> For (1), the tree-diagrams are unexpanded, but surrounding text should point 
> to where each used-grouping is defined.   The better tooling-assisted 
> approach, is for the used groupings *inside the tree-diagram” to become 
> hyperlinks (only possible in supporting formats).   Extending this idea 
> further, hyperlinks could be provided for typedefs and identities too.
>  
> For (2), for plain-text and PDF formats, a link to where the image can be 
> accessed would be nice.  For the HTML format, inlining the complete 
> (unfolded) tree-diagram with horizontal-scrolling would be ideal.
>  
> Kent
>  
> 
> 
> On Mar 5, 2024, at 3:01 AM, mohamed.boucad...@orange.com 
> <mailto:mohamed.boucad...@orange.com> wrote:
>  
> Hi Italo,
>  
> Thanks for sharing your thoughts.
>  
> Please see inline.
>  
> Cheers,
> Med
>  
> De : Italo Busi mailto:italo.b...@huawei.com>>
> Envoyé : lundi 4 mars 2024 19:38
> À : Qin Wu mailto:bill...@huawei.com>>; Mahesh 
> Jethanandani mailto:mjethanand...@gmail.com>>; 
> BOUCADAIR Mohamed INNOV/NET  <mailto:mohamed.boucad...@orange.com>>
> Cc : netmod@ietf.org <mailto:netmod@ietf.org>
> Objet : RE: [netmod] Long trees RE: Next steps for 
> draft-ietf-netmod-rfc8407bis
>  
> Hi Med,
>  
> In my personal experience, I have found the YANG tree included in the IETF 
> RFCs/I-Ds useful only when they are complete, even if they are too long
> [Med] I agree that having readily available full trees is useful, however the 
> question is whether it should be embedded in the RFC text or would having 
> stable links to access such trees be much more convenient? Note also that 
> when the tree is too long, there are better places to display them for better 
> user experience (control views, etc.), which we don’t have with the txt 
> version.
>  
> In RFC8795 you can find an example of a too-long YANG tree which I am using 
> quite often
>  
> [Med] If the Datatracker includes a link to the tree or 8795 includes a 
> stable pointer to the full tree without the editing limitations of IETF docs, 
> the experience would be the same, if not better. No?
>  
>  
> I have found YANG trees with unexpanded grouping almost impossible to use. In 
> draft-ietf-teas-yang-te you can find an example of a YANG tree with 
> unexpanded grouping which I am not using at all. In this case, I refer to the 
> YANG catalog to get the complete tree
>  
> [Med] ACK.
>  
> I have also found the YANG tree pieces almost useless (even if much better 
> than the YANG trees with unexpanded grouping) without some overview.
>  
> [Med] Not having an overview to describe the overall structure and help 
> readers navigate among all the various levels is a bug of these specs, IMO. 
> The narrative part of the spec is supposed to help readers digest the 
> structure and zoom in/out when diving into specifics. I think that we need 
> collectively to better explain the rationale of a module design and 
> articulating the various parts of a module. The use of subtrees for too long 
> trees is a means to help structure the description sections.
>  
> RFC8348 is an example of YANG tree pieces which I am using very rarely. In 
> most of the cases, I refer to the YANG catalog to get the complete tree
> [Med] ACK.
>  
> I am wondering whether the issue of YANG tree too-long could be resolved by 
> updating the IETF tooling. For example, I have noted that the html-ized 
> version of the I-Ds is now working well wit

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

[Kent Watsen]

It seems that there are two camps:

1) those that want the tree-diagrams to be as DRY as possible
2) those that want the tree-diagrams to be as WET as possible

DRY = Don't Repeat Yourself
WET = Write Every Time

Tooling can help both cases.

For (1), the tree-diagrams are unexpanded, but surrounding text should point to 
where each used-grouping is defined.   The better tooling-assisted approach, is 
for the used groupings *inside the tree-diagram” to become hyperlinks (only 
possible in supporting formats).   Extending this idea further, hyperlinks 
could be provided for typedefs and identities too.

For (2), for plain-text and PDF formats, a link to where the image can be 
accessed would be nice.  For the HTML format, inlining the complete (unfolded) 
tree-diagram with horizontal-scrolling would be ideal.

Kent


> On Mar 5, 2024, at 3:01 AM, mohamed.boucad...@orange.com wrote:
> 
> Hi Italo,
>  
> Thanks for sharing your thoughts.
>  
> Please see inline.
>  
> Cheers,
> Med
>  
> De : Italo Busi mailto:italo.b...@huawei.com>>
> Envoyé : lundi 4 mars 2024 19:38
> À : Qin Wu mailto:bill...@huawei.com>>; Mahesh 
> Jethanandani mailto:mjethanand...@gmail.com>>; 
> BOUCADAIR Mohamed INNOV/NET  >
> Cc : netmod@ietf.org 
> Objet : RE: [netmod] Long trees RE: Next steps for 
> draft-ietf-netmod-rfc8407bis
>  
> Hi Med,
>  
> In my personal experience, I have found the YANG tree included in the IETF 
> RFCs/I-Ds useful only when they are complete, even if they are too long
> [Med] I agree that having readily available full trees is useful, however the 
> question is whether it should be embedded in the RFC text or would having 
> stable links to access such trees be much more convenient? Note also that 
> when the tree is too long, there are better places to display them for better 
> user experience (control views, etc.), which we don’t have with the txt 
> version.
>  
> In RFC8795 you can find an example of a too-long YANG tree which I am using 
> quite often
>  
> [Med] If the Datatracker includes a link to the tree or 8795 includes a 
> stable pointer to the full tree without the editing limitations of IETF docs, 
> the experience would be the same, if not better. No?
>  
>  
> I have found YANG trees with unexpanded grouping almost impossible to use. In 
> draft-ietf-teas-yang-te you can find an example of a YANG tree with 
> unexpanded grouping which I am not using at all. In this case, I refer to the 
> YANG catalog to get the complete tree
>  
> [Med] ACK.
>  
> I have also found the YANG tree pieces almost useless (even if much better 
> than the YANG trees with unexpanded grouping) without some overview.
>  
> [Med] Not having an overview to describe the overall structure and help 
> readers navigate among all the various levels is a bug of these specs, IMO. 
> The narrative part of the spec is supposed to help readers digest the 
> structure and zoom in/out when diving into specifics. I think that we need 
> collectively to better explain the rationale of a module design and 
> articulating the various parts of a module. The use of subtrees for too long 
> trees is a means to help structure the description sections.
>  
> RFC8348 is an example of YANG tree pieces which I am using very rarely. In 
> most of the cases, I refer to the YANG catalog to get the complete tree
> [Med] ACK.
>  
> I am wondering whether the issue of YANG tree too-long could be resolved by 
> updating the IETF tooling. For example, I have noted that the html-ized 
> version of the I-Ds is now working well with artwork exceeding the 72 
> characters limit …
>  
> Maybe the html or html-ized version of the I-D/RFC might include the jstree 
> pyang output instead of the tree pyang output
>  
> [Med] Fully agree that tooling is the way to go here. Having a stable pointer 
> to the tree (including displaying it from the Datatracker metadata) would 
> achieve that objective.
>  
> Back to the txt version, here is an updated version of the reco (for further 
> discussion):
>  
> ==
> NEW:
>YANG tree diagrams provide a concise representation of a YANG module
>and SHOULD be included to help readers understand YANG module
>structure.  If the complete tree diagram for a module becomes long
>(more than 2 pages, typically), the diagram SHOULD be split into
>several smaller diagrams (a.k.a subtrees).  For the reader's
>convenience, a subtree should fit within a page.  If the complete
>tree diagram is too long (more than 5 pages, typically) even with
>groupings unexpanded (Section 2.2 of [RFC8340]), the authors SHOULD
>NOT include it in the document.  A stable pointer to retrieve the
>full tree MAY be included.
>  
>The document SHOULD include the following note if the full tree is
>not included:
>  
>   -- If no stable pointer to retrieve the tree is included
>  
>   The full 

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

[Kent Watsen]

Hi Italo,

> On Mar 4, 2024, at 1:38 PM, Italo Busi 
>  wrote:
> 
> I am wondering whether the issue of YANG tree too-long could be resolved by 
> updating the IETF tooling. For example, I have noted that the html-ized 
> version of the I-Ds is now working well with artwork exceeding the 72 
> characters limit …
>  
> Maybe the html or html-ized version of the I-D/RFC might include the jstree 
> pyang output instead of the tree pyang output

This is what I’ve been saying for awhile now.

Datatracker should unfold folded-artwork for formats like HTML that can provide 
horizontal scrollbars.

That said, the desire to break tree-diagrams into pieces won’t be resolved, as 
authors still need to support plain-text output…  grrr


Personally, I prefer whole-trees (if not folded), which are much easier to 
place into a document, but many in the WG push for tree-diagram snippets.   
Hope we can reach a consensus on this…

K


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

[netmod] WGLC on node-tags-11

[Kent Watsen]

This email begins a two-week WGLC on:

https://datatracker.ietf.org/doc/html/draft-ietf-netmod-node-tags-11

Please take time to review this draft and post comments by March 14.  Favorable 
comments are especially welcomed.  

Aside: this draft went through a WGLC six months ago, to which there were some 
objections.  The authors addressed the concerns here [1].  Andy removed his 
objection here [2].

[1] https://mailarchive.ietf.org/arch/msg/netmod/qbB0Z-cMq_zmbNOjYT6ritZ7wxY/
[2] https://mailarchive.ietf.org/arch/msg/netmod/7hD9fgGGMyN_VeWyLEYGw98JA1E/


Kent  // co-chair ___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Kent Watsen]

Hi Jan,

> On Feb 28, 2024, at 9:21 AM, Jan Lindblad  wrote:
> 
> Med, author team,
> 
> Thank you for taking the time to get this work done, and well done! This is 
> one of those fundamental bricks that saves time and improves quality for the 
> entire YANG community.
> 
> I read the -09 version and like what I see. I have a couple of minor 
> suggestions you might consider.
> 
> + In section 3.4 about tree diagrams, the section text is already advocating 
> intermixing smaller tree snippets with explanations (which is great), but I 
> wish we could say that 
> tree diagrams of entire modules SHOULD NOT be included. Just a waste of 
> forest and attention span, imho.

The client-server suite of drafts takes this idea a step further, by many times 
using unexpanded tree-diagrams, along with associated hyperlinks to where the 
grouping was defined.  

For instance: 
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-tls-client-server#section-4.1.2.1


> + In section 4.2 about choice of prefixes, it is said that "Prefix values 
> SHOULD be short but are also likely to be unique." I used to say the same 
> thing. In recent years, however, I have started to stress the importance of 
> uniqueness much more. I'd say something like "Prefix values SHOULD be 
> selected carefully to be unique, and ideally not too long." The reason for my 
> change is I have met several engineers who have been deeply confused (to the 
> point of costing real money) when the same prefix has shown up in multiple 
> places. It's just an unnecessary part of the learning curve associated with 
> YANG.
> 
> In fact, I have started to recommend people to set the prefix to equal the 
> module name. This also solves another problem, which is that the "prefixes" 
> you see in RESTCONF are module names, and the confusion of what to use where 
> is sometimes suffocating. I understand if many think I'm going overboard 
> here, but when we pretend that modules don't have prefixes, only module 
> names, there is a lot less friction in learning the ropes.

In my private modules, I’ve taken to setting the prefix to be the same as the 
module name.

The clarity is great, and I don’t see an issue with the verbosity.  Something 
to consider?


Kent


> + In section 4.6.2 regarding useless (in YANG Context) functions in the XPath 
> function library, it is said that the "YANG compiler" should return false, 
> etc. Better wording might be that the XPath execution environment (or 
> something) should return false, etc. The YANG compiler is not even running 
> when the calls to those functions are happening.
> 
> + In section 4.11.5 regarding booleans, it is said that booleans can take 
> values true and false. This is true in mathematics :-) but in YANG a boolean 
> leaf can additionally take the "value" of "not set". Actually, "not set" is a 
> possibility for leafs in general, unless it is declared mandatory true, or 
> has a default. In my experience, one of the most common YANG modeling issues 
> is when people model a leaf foo, which isn't mandatory, has no default and 
> the description statement does not say what happens if the leaf is not set. 
> In many cases, there is a sort of natural meaning, but with booleans leafs in 
> particular, the absence of the leaf is typically highly ambiguous. I think 
> this hole merits a recommendation clause in the I-D.
> 
> Best Regards,
> /jan
> 
> 
> 
>> On 28 Feb 2024, at 10:51, 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  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 

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

[Kent Watsen]

Hi Med,

I’ve been slow to provide follow-up responses to you regarding the "Adherence 
to the NMDA" and "Security Considerations" sections, which I have refined even 
more since our last interactions here.

1) In the Adherence to the NMDA section, I know that I pushed before to invert 
the recommendation from before, along with a promise to then eliminate the 
section from all my drafts.  But then I looked at all my drafts and found that 
I was saying some pretty meaningly things.  I think that my current position is 
now “neutral” - that is, don’t say how it is NMDA-compliant (as all YANG 
modules SHOULD be now) nor say how it is not compliant (as none SHOULD be), but 
rather say what might be useful to say.  This may be unique to these drafts, as 
they partially depend on the existence of an  datastore, which is 
define by NMDA.  To get a feel for what I mean, check out these sections:


https://datatracker.ietf.org/doc/html/draft-ietf-netconf-crypto-types#section-1.3

https://datatracker.ietf.org/doc/html/draft-ietf-netconf-trust-anchors#section-1.3

https://datatracker.ietf.org/doc/html/draft-ietf-netconf-keystore#section-1.4

https://datatracker.ietf.org/doc/html/draft-ietf-netconf-tcp-client-server#section-1.3

https://datatracker.ietf.org/doc/html/draft-ietf-netconf-ssh-client-server#section-1.4

https://datatracker.ietf.org/doc/html/draft-ietf-netconf-tls-client-server#section-1.4

https://datatracker.ietf.org/doc/html/draft-ietf-netconf-http-client-server#section-1.3

https://datatracker.ietf.org/doc/html/draft-ietf-netconf-netconf-client-server#section-1.3

https://datatracker.ietf.org/doc/html/draft-ietf-netconf-restconf-client-server#section-1.3



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.


Below is top of mind, but I invite/encourage you to read said sections (and the 
IANA Considerations section too) in, e.g., 
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-ssh-client-server to 
see if I missed anything.

Kent


> 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  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=05%7C02%7Cmohamed.boucadair%40orange.com%7C51672231
>> 30c943a5a4c608dc383bce6b%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C
>> 638447076716455966%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo
>> iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=s5VX9Hb%2Fl
>> P9v5QurysF69syyEyba9yYss7xd7K5E2FE%3D=0
>> 
>> There is also an HTML version available at:
>> 

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

[Kent Watsen]

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

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

[Kent Watsen]

Thank you authors and contributors for your responses.
No IPR is being declared at this time.

Kent (and Lou)


> On Feb 12, 2024, at 5:50 PM, Kent Watsen  wrote:
> 
> 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=draft-ma-netmod-immutable-flag
> 
> Thanks.
> Kent (and Lou)
> ___
> 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] RE I-D Action: draft-ietf-netmod-node-tags-11.txt

[Kent Watsen]

Juergen, Tom, Andy,

Gentle reminder.

Kent // shepherd


> On Nov 14, 2023, at 4:49 PM, Kent Watsen  wrote:
> 
> Juergen, Tom, Andy,
> 
> The previous WGLC for this draft didn’t succeed due to your comments.
> Qin’s update (1) below removes all the (metric) specific node-tags.  
> All that is left now is the generic mechanism for tagging nodes.
> Can you confirm that this update (-11) addresses your concerns?
> 
> Thanks,
> Kent
> 
> 
>> On Oct 23, 2023, at 6:28 AM, Qin Wu  
>> wrote:
>> 
>> v-11 addresses comments during WGLC, the main changes include:
>> 1. Remove all specific metrics from both terminology section and section 9.2 
>> on IETF YANG Data Node Tags Registry based on WGLC discussion.
>> 2. Align with Open Telemetry and Open Metrics open source implementation 
>> specification, introduce traces, log for data nodes classification.
>> 3.Fix normative reference issues in section 9.2.
>> 
>> -Qin
>> -邮件原件-
>> 发件人: I-D-Announce [mailto:i-d-announce-boun...@ietf.org] 代表 
>> internet-dra...@ietf.org
>> 发送时间: 2023年10月21日 17:56
>> 收件人: i-d-annou...@ietf.org
>> 抄送: netmod@ietf.org
>> 主题: I-D Action: draft-ietf-netmod-node-tags-11.txt
>> 
>> Internet-Draft draft-ietf-netmod-node-tags-11.txt is now available. It is a 
>> work item of the Network Modeling (NETMOD) WG of the IETF.
>> 
>>  Title:   Node Tags in YANG Modules
>>  Authors:  Qin Wu
>>   Benoit Claise
>>   Mohamed Boucadair
>>   Peng Liu
>>   Zongpeng Du
>>  Name:draft-ietf-netmod-node-tags-11.txt
>>  Pages:   30
>>  Dates:   2023-10-21
>> 
>> Abstract:
>> 
>>  This document defines a method to tag nodes that are associated with
>>  the operation and management data in YANG modules.  This method for
>>  tagging YANG nodes is meant to be used for classifying either data
>>  nodes or instances of data nodes from different YANG modules and
>>  identifying their characteristic data.  Tags may be registered as
>>  well as assigned during the definition of the module, assigned by
>>  implementations, or dynamically defined and set by users.
>> 
>>  This document also provides guidance to future YANG data model
>>  writers; as such, this document updates RFC 8407.
>> 
>> The IETF datatracker status page for this Internet-Draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-netmod-node-tags/
>> 
>> There is also an HTMLized version available at:
>> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-node-tags-11
>> 
>> A diff from the previous version is available at:
>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-netmod-node-tags-11
>> 
>> Internet-Drafts are also available by rsync at:
>> rsync.ietf.org::internet-drafts
>> 
>> 
>> ___
>> I-D-Announce mailing list
>> i-d-annou...@ietf.org
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> 
>> ___
>> 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 mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Rfc8407 - what does this text mean?

[Kent Watsen]

Hi Med,

> On Feb 19, 2024, at 3:29 AM, mohamed.boucad...@orange.com wrote:
> 
> Hi Kent, all,
>  
> I also think that highlighting the exceptions + motivate them makes sense 
> here. A PR to fix that can be seen at [1].

Thank you.  

I hope folks express objections now, before WGLC, as an expeditious resolution 
helps me close off an IESG review comment in NETCONF.


> FWIW, the OLD text was added draft-ietf-netmod-rfc6087bis-17 as per a comment 
> in the AD review [2].

That’s a great find!


> Cheers,
> Med

K.


>  
> [1] 
> https://author-tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/rfc8407bis/draft-ietf-netmod-rfc8407bis.txt_2=https://boucadair.github.io/rfc8407bis/nmda-exceptions/draft-ietf-netmod-rfc8407bis.txt
>  
> [2] https://mailarchive.ietf.org/arch/msg/netmod/B4TUQZf7jud5wqrBwzEqEND6-rw/
>  
>  
> De : netmod mailto:netmod-boun...@ietf.org>> De la 
> part de Kent Watsen
> Envoyé : vendredi 16 février 2024 21:55
> À : Andy Bierman mailto:a...@yumaworks.com>>
> Cc : netmod@ietf.org <mailto:netmod@ietf.org>
> Objet : Re: [netmod] Rfc8407 - what does this text mean?
>  
> Hi Andy,
>  
> Thanks for the speedy reply.
>  
> This guidance seems inverted, at least within the IETF (where SHOULDs are 
> interpreted as MUSTs), and likely outside the IETF also, assuming rfc8407 is 
> read.  See the first paragraph of 
> https://datatracker.ietf.org/doc/html/rfc8407#section-4.23.3 
>  
> I doubt any module would get past the IETF-publication process now if it 
> defined a non-NMDA compliant structure (i.e., CF nodes that provide the 
> opstate value for CT nodes), unless it was a “temporary non-NMDA module” 
> (https://datatracker.ietf.org/doc/html/rfc8407#section-4.23.3.1).
>  
> Since this, for awhile now, is the normal thing to do, the text highlighted 
> in my OP seems to have little to no value.  That said, an “inverted” 
> statement would have some value, that is, to explicitly highlight if the 
> document defines any “temporary non-NMDA modules”.  This would be akin to 
> highlighting when a document defines any IANA-maintained modules.
> 
> 
> I am proposing to update the text in rfc8407bis accordingly (to invert the 
> guidance).  Thoughts?
> 
> 
> If there is agreement to update this text accordingly, I will delete the 
> "Adherence to the NMDA” section in all my drafts, since none of them define a 
> “temporary non-NMDA module”.
>  
> PS: top-posting for simplicity
>  
> K.
>  
>  
> 
> 
> On Feb 16, 2024, at 3:25 PM, Andy Bierman  <mailto:a...@yumaworks.com>> wrote:
>  
>  
>  
> On Fri, Feb 16, 2024 at 12:07 PM Kent Watsen  <mailto:kent%2bi...@watsen.net>> wrote:
> NETMOD,
>  
> An IESG member reviewing one of my drafts flagged a section I had written to 
> satisfy this text from 
> https://datatracker.ietf.org/doc/html/rfc8407#section-3.5:
>  
>If the document contains a YANG module(s) that is compliant with NMDA
>[RFC8342], then the Introduction section should mention this fact.
>  
>Example:
>  
>  The YANG data model in this document conforms to the Network
>  Management Datastore Architecture defined in  RFC 8342.
>  
>  
> What does "compliant with NMDA” actually mean?   Are not all modules 
> “compliant”, even if they unnecessarily define some opstate nodes?
>  
>  
> I do not recall the discussions that led to that text.
>  
> Does this sentence actually point to if the document publishes any so called 
> “-state” modules, defined only to support legacy “non-NMDA” servers?
>  
>  
> I think the state modules are optional, so it is still unclear what NMDA 
> conformance means for a YANG module. 
>  
>  
> Does it make sense to clarify this text, since rfc8407bis is an open WG 
> document at the moment?
>  
> maybe it means to follow all the guidelines in 4.23.3
> https://datatracker.ietf.org/doc/html/rfc8407#section-4.23.3
>  
> maybe remove this other text you cite.
>  
>  
>  
> Thanks,
> Kent
>  
>  
> Andy
>  
> ___
> netmod mailing list
> netmod@ietf.org <mailto: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 e

Re: [netmod] Rfc8407 - what does this text mean?

[Kent Watsen]

Hi Andy,

Thanks for the speedy reply.

This guidance seems inverted, at least within the IETF (where SHOULDs are 
interpreted as MUSTs), and likely outside the IETF also, assuming rfc8407 is 
read.  See the first paragraph of 
https://datatracker.ietf.org/doc/html/rfc8407#section-4.23.3 

I doubt any module would get past the IETF-publication process now if it 
defined a non-NMDA compliant structure (i.e., CF nodes that provide the opstate 
value for CT nodes), unless it was a “temporary non-NMDA module” 
(https://datatracker.ietf.org/doc/html/rfc8407#section-4.23.3.1).

Since this, for awhile now, is the normal thing to do, the text highlighted in 
my OP seems to have little to no value.  That said, an “inverted” statement 
would have some value, that is, to explicitly highlight if the document defines 
any “temporary non-NMDA modules”.  This would be akin to highlighting when a 
document defines any IANA-maintained modules.

I am proposing to update the text in rfc8407bis accordingly (to invert the 
guidance).  Thoughts?

If there is agreement to update this text accordingly, I will delete the 
"Adherence to the NMDA” section in all my drafts, since none of them define a 
“temporary non-NMDA module”.

PS: top-posting for simplicity

K.



> On Feb 16, 2024, at 3:25 PM, Andy Bierman  wrote:
> 
> 
> 
> On Fri, Feb 16, 2024 at 12:07 PM Kent Watsen  <mailto:kent%2bi...@watsen.net>> wrote:
>> NETMOD,
>> 
>> An IESG member reviewing one of my drafts flagged a section I had written to 
>> satisfy this text from 
>> https://datatracker.ietf.org/doc/html/rfc8407#section-3.5:
>> 
>>If the document contains a YANG module(s) that is compliant with NMDA
>>[RFC8342], then the Introduction section should mention this fact.
>> 
>>Example:
>> 
>>  The YANG data model in this document conforms to the Network
>>  Management Datastore Architecture defined in  RFC 8342.
>> 
>> 
>> What does "compliant with NMDA” actually mean?   Are not all modules 
>> “compliant”, even if they unnecessarily define some opstate nodes?
>> 
> 
> I do not recall the discussions that led to that text.
>  
>> Does this sentence actually point to if the document publishes any so called 
>> “-state” modules, defined only to support legacy “non-NMDA” servers?
>> 
> 
> I think the state modules are optional, so it is still unclear what NMDA 
> conformance means for a YANG module. 
> 
> 
>> Does it make sense to clarify this text, since rfc8407bis is an open WG 
>> document at the moment?
> 
> maybe it means to follow all the guidelines in 4.23.3
> https://datatracker.ietf.org/doc/html/rfc8407#section-4.23.3
> 
> maybe remove this other text you cite.
> 
> 
>> 
>> Thanks,
>> Kent
>> 
> 
> Andy
>  
>> ___
>> netmod mailing list
>> netmod@ietf.org <mailto:netmod@ietf.org>
>> https://www.ietf.org/mailman/listinfo/netmod

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

[netmod] Rfc8407 - what does this text mean?

[Kent Watsen]

NETMOD,

An IESG member reviewing one of my drafts flagged a section I had written to 
satisfy this text from 
https://datatracker.ietf.org/doc/html/rfc8407#section-3.5:

   If the document contains a YANG module(s) that is compliant with NMDA
   [RFC8342], then the Introduction section should mention this fact.

   Example:

 The YANG data model in this document conforms to the Network
 Management Datastore Architecture defined in  RFC 8342.


What does "compliant with NMDA” actually mean?   Are not all modules 
“compliant”, even if they unnecessarily define some opstate nodes?

Does this sentence actually point to if the document publishes any so called 
“-state” modules, defined only to support legacy “non-NMDA” servers?

Does it make sense to clarify this text, since rfc8407bis is an open WG 
document at the moment?

Thanks,
Kent

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

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

[Kent Watsen]

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=draft-ma-netmod-immutable-flag

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

Re: [netmod] rfc8407bis IANA guidance (enums vs identities)

[Kent Watsen]

Hi Mohamad,

Thanks for the response.
Some thoughts below.

K


> On Feb 8, 2024, at 3:36 AM, mohamed.boucad...@orange.com wrote:
> 
> Hi Kent, all,
>  
> Let’s me also provide some background and explain why we are not using any 
> normative language for enum vs identities. We used to have this text in early 
> versions:
>  
>This recommendation takes precedence over the behavior in
>Section 4.11.1 of [RFC8407] for IANA-maintained modules because the
>extensibility concern is not applicable for such modules.
>  
> The reco that the text refers to is the following one (RFC8407):
>  
>If extensibility of enumerated values is required, then the
>"identityref" data type SHOULD be used instead of an enumeration or
>other built-in type.
>  
> However, Juergen convinced me that we don’t need an update as we do already 
> have the following:
>  
>If the set of values is fixed and the data type contents are
>controlled by a single naming authority, then an enumeration data
>type SHOULD be used.
>  
> I think that we need to better convey this in the draft, while avoiding 
> redundant normative language.

+1


> (1)
>  
> OLD:
>If the set of values is fixed and the data type contents are
>controlled by a single naming authority, then an enumeration data
>type SHOULD be used.
>  
> NEW:
>If the set of values is fixed and the data type contents are
>controlled by a single naming authority (e.g., IANA), then an enumeration 
> data
>type SHOULD be used.

Good.


> (2)
>  
> OLD:
>An IANA-maintained module may use identities (e.g., [RFC8675]) or
>enumerations (e.g., [RFC9108]).  The decision about which type to use
>is left to the module designers and should be made based upon
>specifics related to the intended use of the IANA-maintained module.
>For example, identities are useful if the registry entries are
>organized hierarchically, possibly including multiple inheritances.
>It is RECOMMENDED that the reasoning for the design choice is
>documented in the companion specification that registers an IANA-
>maintained module.
>  
> NEW:
>An IANA-maintained module may use the "identityref" data type (e.g.,
>[RFC8675]) or an enumeration data type (e.g., [RFC9108]).  Consistent
>with Section 4.11.1, the default recommendation is to use an
>enumeration data type.  The decision about which type to use is left
>to the module designers and should be made based upon specifics
>related to the intended use of the IANA-maintained module.  For
>example, identities are useful if the registry entries are organized
>hierarchically, possibly including multiple inheritances.  It is
>RECOMMENDED that the reasoning for the design choice is documented in
>the companion specification that registers an IANA-maintained module.

Should both the RFC8675 and RFC9108 refs point to sections in RFC 7950?


Regarding new text:

   Consistent with Section 4.11.1, the default recommendation
   is to use an enumeration data type.

Might it be better to say something like the following?

   Please see Section 4.11.1 for guidance on which data type to use.



Regarding existing text:

   The decision about which type to use is left
   to the module designers and should be made based upon specifics
   related to the intended use of the IANA-maintained module.  For
   example, identities are useful if the registry entries are organized
   hierarchically, possibly including multiple inheritances.

I think that this introduces redundant normative language.  I believe that this 
text can be removed, if the following change is made to Section 4.11.1:

OLD:
   If extensibility of enumerated values is required, then the
   "identityref" data type SHOULD be used instead of an enumeration or
   other built-in type.

NEW:
   If extensibility or hierarchical organization of the enumerated values is 
required, then the
   "identityref" data type SHOULD be used instead of an enumeration or
   other built-in type.



>  
> The full changes can be better tracker here: 
> https://author-tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/rfc8407bis/draft-ietf-netmod-rfc8407bis.txt_2=https://boucadair.github.io/rfc8407bis/enum-vs-identities/draft-ietf-netmod-rfc8407bis.txt
>  
>  
> Cheers,
> Med


Thanks,
Kent


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

Re: [netmod] rfc8407bis IANA guidance (enums vs identities)

[Kent Watsen]

Hi Mohamad,

Thanks for the response.
Some thoughts below.

K


> On Feb 8, 2024, at 3:36 AM, mohamed.boucad...@orange.com wrote:
> 
> Hi Kent, all,
>  
> Let’s me also provide some background and explain why we are not using any 
> normative language for enum vs identities. We used to have this text in early 
> versions:
>  
>This recommendation takes precedence over the behavior in
>Section 4.11.1 of [RFC8407] for IANA-maintained modules because the
>extensibility concern is not applicable for such modules.
>  
> The reco that the text refers to is the following one (RFC8407):
>  
>If extensibility of enumerated values is required, then the
>"identityref" data type SHOULD be used instead of an enumeration or
>other built-in type.
>  
> However, Juergen convinced me that we don’t need an update as we do already 
> have the following:
>  
>If the set of values is fixed and the data type contents are
>controlled by a single naming authority, then an enumeration data
>type SHOULD be used.
>  
> I think that we need to better convey this in the draft, while avoiding 
> redundant normative language.

+1


> (1)
>  
> OLD:
>If the set of values is fixed and the data type contents are
>controlled by a single naming authority, then an enumeration data
>type SHOULD be used.
>  
> NEW:
>If the set of values is fixed and the data type contents are
>controlled by a single naming authority (e.g., IANA), then an enumeration 
> data
>type SHOULD be used.

Good.


> (2)
>  
> OLD:
>An IANA-maintained module may use identities (e.g., [RFC8675]) or
>enumerations (e.g., [RFC9108]).  The decision about which type to use
>is left to the module designers and should be made based upon
>specifics related to the intended use of the IANA-maintained module.
>For example, identities are useful if the registry entries are
>organized hierarchically, possibly including multiple inheritances.
>It is RECOMMENDED that the reasoning for the design choice is
>documented in the companion specification that registers an IANA-
>maintained module.
>  
> NEW:
>An IANA-maintained module may use the "identityref" data type (e.g.,
>[RFC8675]) or an enumeration data type (e.g., [RFC9108]).  Consistent
>with Section 4.11.1, the default recommendation is to use an
>enumeration data type.  The decision about which type to use is left
>to the module designers and should be made based upon specifics
>related to the intended use of the IANA-maintained module.  For
>example, identities are useful if the registry entries are organized
>hierarchically, possibly including multiple inheritances.  It is
>RECOMMENDED that the reasoning for the design choice is documented in
>the companion specification that registers an IANA-maintained module.

Should both the RFC8675 and RFC9108 refs point to sections in RFC 7950?


Regarding new text:

   Consistent with Section 4.11.1, the default recommendation
   is to use an enumeration data type.

Might it be better to say something like the following?

   Please see Section 4.11.1 for guidance on which data type to use.



Regarding existing text:

   The decision about which type to use is left
   to the module designers and should be made based upon specifics
   related to the intended use of the IANA-maintained module.  For
   example, identities are useful if the registry entries are organized
   hierarchically, possibly including multiple inheritances.

I think that this introduces redundant normative language.  I believe that this 
text can be removed, if the following change is made to Section 4.11.1:

OLD:
   If extensibility of enumerated values is required, then the
   "identityref" data type SHOULD be used instead of an enumeration or
   other built-in type.

NEW:
   If extensibility or hierarchical organization of the enumerated values is 
required, then the
   "identityref" data type SHOULD be used instead of an enumeration or
   other built-in type.



>  
> The full changes can be better tracker here: 
> https://author-tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/rfc8407bis/draft-ietf-netmod-rfc8407bis.txt_2=https://boucadair.github.io/rfc8407bis/enum-vs-identities/draft-ietf-netmod-rfc8407bis.txt
>  
>  
> Cheers,
> Med


Thanks,
Kent


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

[netmod] rfc8407bis IANA guidance (enums vs identities)

[Kent Watsen]

Authors, WG,

Following is a comment on Section 4.30.2.
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-06#section-4.30.2

The text says:

START
An IANA-maintained module may use identities (e.g., [RFC8675]) or enumerations 
(e.g., [RFC9108]). The decision about which type to use is left to the module 
designers and should be made based upon specifics related to the intended use 
of the IANA-maintained module. For example, identities are useful if the 
registry entries are organized hierarchically, possibly including multiple 
inheritances. It is RECOMMENDED that the reasoning for the design choice is 
documented in the companion specification that registers an IANA-maintained 
module. For example, [RFC9244] defines an IANA-maintained module that uses 
enumerations for the following reason:

 "The DOTS telemetry module (Section 10.1) uses "enumerations" rather
 than "identities" to define units, samples, and intervals because
 otherwise the namespace identifier "ietf-dots-telemetry" must be
 included when a telemetry attribute is included (e.g., in a
 mitigation efficacy update).  The use of "identities" is thus
 suboptimal from a message compactness standpoint; one of the key
 requirements for DOTS messages."
STOP

I’m wondering if the guidance here cannot be stronger but, first, let me 
explain how I got here…

The "ssh-client-server" and the "tls-client-server” drafts both register 
IANA-maintained modules for IANA-registries (for crypto algorithms).  All of 
these IANA-modules use *identities* (not enums).

As I’m in the process of updating the two drafts to follow this template, I’m 
struggling with the above quoted text.  The reason for the struggle is because 
I’m having a hard time justifying these draft’s current use of identities 
(yikes!)
  
The impetus for using identities in the first place was to enable new 
identities to be added by future modules (and nothing to do with multiple 
inheritances).   But when moving to the modules being IANA-maintained, it seems 
that we’re simultaneously saying that new values should NOT be definable any 
other way.  That is, IETF would NOT publish new algorithms via new RFCs, when 
IANA is already publishing said algorithms via revisions of the base-module).

Perhaps it is theoretically possible that "proprietary” algorithms could be 
used in private deployments, but such would not foster the interoperability 
that IETF seeks.

Thus I am wondering if the guidance in this section should be stronger.  Should 
it actually say something like “Enumerations SHOULD be used unless the 
multiple-inheritance property of identities is needed.”?

Thoughts?

Kent // contributor





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

[netmod] rfc8407bis IANA module identifier name

[Kent Watsen]

Authors, WG,

Following is a comment on Section 4.30.3.1.
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-06#section-4.30.3.1

The text says: "The name of the "identity" is the lower-case of the name 
provided in the registry.”

Yet Section 4.3.1. (Identifier Naming Conventions) says:  "Uppercase 
characters, the period character, and the underscore character MAY be used if 
the identifier represents a well-known value that uses these characters.”

In the case of IANA registries, names are not limited to lowercase.  Would it 
not be best for IANA module identifier names to match the name provided in the 
registry?  It seems that they meet the "well-known” criteria, e.g., as strings 
used in code...

For instance, a name from the TLS cipher suites registry: 
“TLS_KRB5_WITH_RC4_128_MD5”  [note that it’s both uppercase and also underscore 
characters.

That said, it is not 100% possible, because sometimes the name provided in the 
registry is an illegal YANG identifier.  E.g., the SSH Encryption alg registry 
contains the name "3des-cbc”, which is illegal because it begins with a number. 
 From 7950:

 identifier  = (ALPHA / "_")
 *(ALPHA / DIGIT / "_" / "-" / ".")

My solution for this was/is two-fold:

1) to spell out the number, that is, “3des” -->  “triple-des”.
- could spelling out the number be a recommendation?
2) to have the original name “3des” in the “description field.
- could ensuring search ability this way be a recommendation?


Thanks,
Kent // contributor

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

Re: [netmod] Draft Minutes for Virtual Interim

[Kent Watsen]

The draft interim minutes have been updated.

Thank you Jason, Jurgen, and Carsten for your valuable comments.

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

The minutes are reproduced below for convenience.

Please report any updates needed here.

Kent (and Lou)


= START =

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

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

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

A high-level summary is:

  Qiufang's presentation focused on two main questions?

  1) The "origin" issue.

 The consensus in the room was that  nodes copied into
  should have origin "intended".  The system-config
 draft may "update" RFC 8342 (NMDA) to state this.

 The consensus in the room was that data-migration is 1) not
 -specific concern and 2) is out-of-scope for this draft.

  2) Validity of  alone.

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

 The 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.

 Templates and inactive configuration are nice for humans, but
 unnecessary for machine-to-machine interfaces.  That is, the
 issues arounds such mechanisms are largely moot in environments
 using a controller.

= STOP =


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

Re: [netmod] Network Modeling (netmod) WG Virtual Meeting: 2024-02-06

[Kent Watsen]

Reminder that NETMID is having another Virtual Interim a week from today.

Kent


> On Jan 22, 2024, at 10:22 AM, IESG Secretary  wrote:
> 
> The Network Modeling (netmod) WG will hold a virtual interim meeting on
> 2024-02-06 from 09:00 to 11:00 America/New_York (14:00 to 16:00 UTC).
> 
> Agenda:
> To discuss the "immutable-flag" draft.
> 
> https://datatracker.ietf.org/doc/html/draft-ma-netmod-immutable-flag
> 
> 
> Information about remote participation:
> https://meetings.conf.meetecho.com/interim/?group=46cfea50-b516-4504-ad3a-67b04dd82ff2
> 
> 
> 
> --
> A calendar subscription for all netmod meetings is available at
> https://datatracker.ietf.org/meeting/upcoming.ics?show=netmod
> 
> ___
> 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] Fwd: Draft Minutes for Virtual Interim

[Kent Watsen]

Hi Juergen,

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

Maybe but…
  - it was an official Interim meeting (not just a design team)
  - the subject of this email indicates “Draft Minutes”.
  - the body of the email says "Please report any updates needed here."

Clearly the email is the “confirmation" on the list, and hence it didn't
seem wrong to predictively say "the WG agrees”.

That said, I wonder who all constitute the “working group”.  Does it make
sense to extend that label to folks who don’t participate?  The “netmod”
mailing list has 410 members, but it’s hard to imagine the “working group”
being anywhere close to that.

Kent


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

Re: [netmod] Draft Minutes for Virtual Interim

[Kent Watsen]

Hi Jason,

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

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


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

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

Kent


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

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

[netmod] Draft Minutes for Virtual Interim

[Kent Watsen]

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

Reproduced below for convenience.

Please report any updates needed here.

Kent (and Lou)



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

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

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

A high-level summary is:

  Qiufang's presentation focused on two main questions?

  1) The "origin" issue.

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

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

  2) Validity of  alone.

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

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

 This leaves it up to interpretation.

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

Re: [netmod] Proposed date for Interim on immutable-flag-09

[Kent Watsen]

I’m going to schedule this Interim now but, please be advised that, per Jan’s 
comment on for the "system-config” interim, the “CET” label should’ve been 
“UTC” instead.

Kent


> On Jan 11, 2024, at 6:18 PM, Kent Watsen  wrote:
> 
> Dear NETMOD WG,
> 
> The chairs would like to schedule an Interim meeting to discuss 
> draft-ietf-netmod-immutable-flag.
>   - note that this is in addition to the Interim on Jan 23 for the 
> system-config draft.
> 
> Considering various time-options with Qiufang, as author, with Chinese Lunar 
> New Year approaching, 
> the following 2-hour slot was deemed best for all (see table at bottom for 
> details):
> 
>   Tue, Feb 6, 2024:
>   - PST:  6am-8am
>   - EST:  9am-11am
>   - CET:  2pm-4pm
>   - CST:  10pm-12am   (should’ve been “UTC”)
> 
> Please let us know by mid-next week if there is a conflict.   
> 
> Kent and Lou
> 
> 
> 
>   UTC
>   CET EST PST CST
>   === === === ===
>   10pm5pm 2pm 6am <— maybe okay?
>   11pm6pm 3pm 7am <— a little too 
> late CET
>   12am7pm 4pm 8am <— way too late 
> CET
>   1am 8pm 5pm 9am <— way 
> too late CET
>   2am 9pm 6pm 10am<— way too late 
> CET
>   3am 10pm7pm 11am<— way too late CET
>   4am 11pm8pm 12pm<— way too early CET, a 
> little too late EST
>   5am 12am9pm 1pm <— too early 
> CET, too late EST
>   6am 1am 10pm2pm <— way too late 
> EST
>   7am 2am 11pm3pm <— way too late 
> EST
>   8am 3am 12am4pm <— way too late 
> EST, too late PST
>   9am 4am 1am 5pm <— way 
> too late EST, way too late PST
>   10am5am 2am 6pm <— a little too 
> early EST, way too late PST
>   11am6am 3am 7pm <— way too 
> early PST
>   12pm7am 4am 8pm <— way too 
> early PST
>   1pm 8am 5am 9pm <— a 
> little too early PST
>   2pm 9am 6am 10pm<— maybe okay?
> 
> ___
> 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] Proposed date for Interim on immutable-flag-09

[Kent Watsen]

Dear NETMOD WG,

The chairs would like to schedule an Interim meeting to discuss 
draft-ietf-netmod-immutable-flag.
- note that this is in addition to the Interim on Jan 23 for the 
system-config draft.

Considering various time-options with Qiufang, as author, with Chinese Lunar 
New Year approaching, 
the following 2-hour slot was deemed best for all (see table at bottom for 
details):

Tue, Feb 6, 2024:
- PST:  6am-8am
- EST:  9am-11am
- CET:  2pm-4pm
- CST:  10pm-12am

Please let us know by mid-next week if there is a conflict.   

Kent and Lou




CET EST PST CST
=== === === ===
10pm5pm 2pm 6am <— maybe okay?
11pm6pm 3pm 7am <— a little too 
late CET
12am7pm 4pm 8am <— way too late 
CET
1am 8pm 5pm 9am <— way 
too late CET
2am 9pm 6pm 10am<— way too late 
CET
3am 10pm7pm 11am<— way too late CET
4am 11pm8pm 12pm<— way too early CET, a 
little too late EST
5am 12am9pm 1pm <— too early 
CET, too late EST
6am 1am 10pm2pm <— way too late 
EST
7am 2am 11pm3pm <— way too late 
EST
8am 3am 12am4pm <— way too late 
EST, too late PST
9am 4am 1am 5pm <— way 
too late EST, way too late PST
10am5am 2am 6pm <— a little too 
early EST, way too late PST
11am6am 3am 7pm <— way too 
early PST
12pm7am 4am 8pm <— way too 
early PST
1pm 8am 5am 9pm <— a 
little too early PST
2pm 9am 6am 10pm<— maybe okay?

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

Re: [netmod] YANG to TypeScript?

[Kent Watsen]

> On Jan 3, 2024, at 4:58 AM, Ladislav Lhotka  wrote:
> 
> Kent Watsen mailto:kent+i...@watsen.net>> writes:
> 
>> Thanks Lada!
>> 
>> 
>>> On Jan 2, 2024, at 6:50 AM, Ladislav Lhotka  wrote:
>>> 
>>> Hi Kent,
>>> 
>>> it's not exactly what you are asking for but FWIW Yangson has a method 
>>> DataModel.schema_digest [1]
>>> that returns a “schema digest” - a JS object that contains all information 
>>> that is necessary for such a client-side web app - data tree structure, 
>>> types, restrictions and more. I used it successfully for writing a RESTCONF 
>>> client app in AngularJS.
>>> 
>> 
>>> [1] 
>>> https://yangson.labs.nic.cz/datamodel.html#yangson.datamodel.DataModel.schema_digest
>> 
>> I can’t believe I didn’t know the importance of this method before.
>>  - an opportunity to improve the docs?
> 
> Do you have any suggestions?

Sure.  Something along these lines?

OLD: Generate digest of the data model schema. This information is primarily 
intended to aid client applications.

NEW: Generate a digest of the data model schema.  The digest is a flattened and 
compressed view intended to enable processing the data model without a full 
YANG processing stack, e.g., a single-page application written in Javascript 
running in a web browser.



>> You’re right that it isn’t what was asked for, but it may very well be 
>> sufficient…
>>  - especially given that you said your AngularJS project was successful.
> 
> YANG schema info is also needed in other parts of such an app, e.g. in HTML 
> templates.

Can you say a bit more here?  By “YANG schema”, do you mean the schema digest 
in particular?  Why would there be HTML templates if dynamically-generating the 
layout?



>>> I discussed this once with Martin Björklund and I think he mentioned that 
>>> tail-f used something similar. Perhaps this could be an idea for 
>>> standardizing - apart from web apps there are other restricted environments 
>>> not well suited for dealing with all the complexity and modularity of YANG 
>>> data models. 
>> 
>> I welcome opening a discussion into supporting SPAs on top of RESTCONF.
>> 
>> One issue I foresee is folks thinking server-rendered UI is good enough.
>> I’d like to counter with three comments:
>>  1. Server-rendered takes more server-processing
>>- it is better to offload to client, right?
>>  2. RESTCONF is moving into the realm of applications (not network devices)
>>- several NMS/Controller systems have RESTCONF-based NBIs
>>- such apps want/need SPA UI to meet market-demand
>>  3. JS tooling to process YANG is nearly non-existent (but see [A] and [B]
>>- this sets a high-bar for every application
>>- also suggests a market-opportunity...
> 
> 4. A server-side app is kinda "man in the middle", so you typically have to 
> store credentials for accessing the devices on that web server. In contrast, 
> a client-side app authenticates directly with the RESTCONF server.

Indeed, that too.


> Lada

K.


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

Re: [netmod] YANG to TypeScript?

[Kent Watsen]

Thanks Lada!


> On Jan 2, 2024, at 6:50 AM, Ladislav Lhotka  wrote:
> 
> Hi Kent,
> 
> it's not exactly what you are asking for but FWIW Yangson has a method 
> DataModel.schema_digest [1]
> that returns a “schema digest” - a JS object that contains all information 
> that is necessary for such a client-side web app - data tree structure, 
> types, restrictions and more. I used it successfully for writing a RESTCONF 
> client app in AngularJS.
> 

> [1] 
> https://yangson.labs.nic.cz/datamodel.html#yangson.datamodel.DataModel.schema_digest

I can’t believe I didn’t know the importance of this method before.
  - an opportunity to improve the docs?

You’re right that it isn’t what was asked for, but it may very well be 
sufficient…
  - especially given that you said your AngularJS project was successful.


> I discussed this once with Martin Björklund and I think he mentioned that 
> tail-f used something similar. Perhaps this could be an idea for 
> standardizing - apart from web apps there are other restricted environments 
> not well suited for dealing with all the complexity and modularity of YANG 
> data models. 

I welcome opening a discussion into supporting SPAs on top of RESTCONF.

One issue I foresee is folks thinking server-rendered UI is good enough.
I’d like to counter with three comments:
  1. Server-rendered takes more server-processing
- it is better to offload to client, right?
  2. RESTCONF is moving into the realm of applications (not network devices)
- several NMS/Controller systems have RESTCONF-based NBIs
- such apps want/need SPA UI to meet market-demand
  3. JS tooling to process YANG is nearly non-existent (but see [A] and [B]
- this sets a high-bar for every application
- also suggests a market-opportunity...

[A] https://github.com/corenova/yang-js
[B] https://github.com/corenova/yang-swagger


> Happy New Year to everyone,
> 
> Lada

Cheers,
Kent


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

[netmod] YANG to TypeScript?

[Kent Watsen]

In the “here’s something different” category…

I’m interested in creating an SPA (single page application) on top of a 
RESTCONF server.  

Popular SPA frameworks include AngularJS, Ember.js, ExtJS, Knockout.js, 
Meteor.js, React, Vue.js, and Svelte.  TypeScript is a used by these frameworks 
to “type” the data (since JavaScript is natively untyped).  In this case, the 
data is defined in YANG, so it seems that tooling could create a hierarchy of 
TypeScript types.  But searching didn’t find any such thing...

I’m sure folks are creating SPAs on top of RESTCONF.   Can anyone share a 
toolchain that works?

Happy and safe New Year’s Eve!

Kent

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

Re: [netmod] Operational State usage of YANG choices and constraints

[Kent Watsen]

With limited experience wrt the impact on servers, as a client, it’s always 
best for the opstate data to be modeled as accurately as possible, for better 
processing and user experience.

K.


> On Dec 22, 2023, at 1:37 PM, Acee Lindem  wrote:
> 
> We’ve had some discussions as to whether YANG models should put constraints 
> or use choices for ‘config false’ data nodes. For example, if you have a two 
> mutually exclusive containers, should the YANG model reflect this for ‘config 
> false’ data? Or, if you have a leaf that would only make sense to return if 
> the value of a preceding leaf has a certain value, should the ‘when’ clause 
> be included in modeling? 
> 
> My thought was that it was better to reflect this in the model even for 
> ‘config false’ data. 
> 
> Thanks,
> Acee
> ___
> 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] Proposed date for Interim on system-config-04

[Kent Watsen]

Thank you Per for raising the concern, and Jason for dismissing it.
Since no objections are standing, we will schedule the Interim at the proposed 
time.

Thanks again,
Kent (and Lou)


> On Dec 5, 2023, at 10:51 AM, Jason Sterne (Nokia)  
> wrote:
> 
> Hi all,
> 
> After a quick poll of some weekly YANG versioning call members we think it 
> would be fine to leave that Jan 23rd slot to the system config interim. We 
> can skip our YANG Ver meeting that week.
> 
> Jason
> 
>> -Original Message-
>> From: netmod  On Behalf Of Per Andersson
>> (perander)
>> Sent: Monday, December 4, 2023 7:05 PM
>> To: Kent Watsen ; netmod@ietf.org
>> Subject: Re: [netmod] Proposed date for Interim on system-config-04
>> 
>> 
>> 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!
>> 
>> Tuesdays 3pm-4pm CET conflicts with the module versioning meetings.
>> 
>> 
>> --
>> Per
>> 
>> 
>> From: netmod  on behalf of Kent Watsen
>> 
>> Sent: Tuesday, December 5, 2023 00:18
>> To: netmod@ietf.org
>> Subject: [netmod] Proposed date for Interim on system-config-04
>> 
>> Dear NETMOD WG,
>> 
>> Following up on an action from the 118 session, the chairs would like to 
>> schedule
>> an Interim meeting to discuss draft-ietf-netmod-system-config.
>> 
>> Considering various time-options with Qiufang, as author, it seemed that the
>> following 2-hour slot was best for all (see table at bottom for details):
>> 
>> Tue, Jan 23, 2024:
>>- PST: 6am-8am
>>- EST: 9am-11am
>>- CET: 2pm-4pm
>>- CST: 10pm-12am
>> 
>> Please let us know this week if there is a conflict.
>> 
>> Kent and Lou
>> 
>> 
>> 
>> CET EST PST CST
>> === === === ===
>> 10pm 5pm 2pm 6am <- maybe okay?
>> 11pm 6pm 3pm 7am <- a little too late CET
>> 12am 7pm 4pm 8am <- way too late CET
>> 1am 8pm 5pm 9am <- way too late CET
>> 2am 9pm 6pm 10am <- way too late CET
>> 3am 10pm 7pm 11am <- way too late CET
>> 4am 11pm 8pm 12pm <- way too early CET, a little too late EST
>> 5am 12am 9pm 1pm <- too early CET, too late EST
>> 6am 1am 10pm 2pm <- way too late EST
>> 7am 2am 11pm 3pm <- way too late EST
>> 8am 3am 12am 4pm <- way too late EST, too late PST
>> 9am 4am 1am 5pm <- way too late EST, way too late PST
>> 10am 5am 2am 6pm <- a little too early EST, way too late PST
>> 11am 6am 3am 7pm <- way too early PST
>> 12pm 7am 4am 8pm <- way too early PST
>> 1pm 8am 5am 9pm <- a little too early PST
>> 2pm 9am 6am 10pm <- maybe okay?
>> 
>> ___
>> 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] Proposed date for Interim on system-config-04

[Kent Watsen]

Dear NETMOD WG,

Following up on an action from the 118 session, the chairs would like to 
schedule an Interim meeting to discuss draft-ietf-netmod-system-config.

Considering various time-options with Qiufang, as author, it seemed that the 
following 2-hour slot was best for all (see table at bottom for details):

Tue, Jan 23, 2024:
- PST:  6am-8am
- EST:  9am-11am
- CET:  2pm-4pm
- CST:  10pm-12am

Please let us know this week if there is a conflict.   

Kent and Lou



CET EST PST CST
=== === === ===
10pm5pm 2pm 6am <— maybe okay?
11pm6pm 3pm 7am <— a little too 
late CET
12am7pm 4pm 8am <— way too late 
CET
1am 8pm 5pm 9am <— way 
too late CET
2am 9pm 6pm 10am<— way too late 
CET
3am 10pm7pm 11am<— way too late CET
4am 11pm8pm 12pm<— way too early CET, a 
little too late EST
5am 12am9pm 1pm <— too early 
CET, too late EST
6am 1am 10pm2pm <— way too late 
EST
7am 2am 11pm3pm <— way too late 
EST
8am 3am 12am4pm <— way too late 
EST, too late PST
9am 4am 1am 5pm <— way 
too late EST, way too late PST
10am5am 2am 6pm <— a little too 
early EST, way too late PST
11am6am 3am 7pm <— way too 
early PST
12pm7am 4am 8pm <— way too 
early PST
1pm 8am 5am 9pm <— a 
little too early PST
2pm 9am 6am 10pm<— maybe okay?

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

Re: [netmod] RE I-D Action: draft-ietf-netmod-node-tags-11.txt

[Kent Watsen]

Juergen, Tom, Andy,

The previous WGLC for this draft didn’t succeed due to your comments.
Qin’s update (1) below removes all the (metric) specific node-tags.  
All that is left now is the generic mechanism for tagging nodes.
Can you confirm that this update (-11) addresses your concerns?

Thanks,
Kent


> On Oct 23, 2023, at 6:28 AM, Qin Wu  
> wrote:
> 
> v-11 addresses comments during WGLC, the main changes include:
> 1. Remove all specific metrics from both terminology section and section 9.2 
> on IETF YANG Data Node Tags Registry based on WGLC discussion.
> 2. Align with Open Telemetry and Open Metrics open source implementation 
> specification, introduce traces, log for data nodes classification.
> 3.Fix normative reference issues in section 9.2.
> 
> -Qin
> -邮件原件-
> 发件人: I-D-Announce [mailto:i-d-announce-boun...@ietf.org] 代表 
> internet-dra...@ietf.org
> 发送时间: 2023年10月21日 17:56
> 收件人: i-d-annou...@ietf.org
> 抄送: netmod@ietf.org
> 主题: I-D Action: draft-ietf-netmod-node-tags-11.txt
> 
> Internet-Draft draft-ietf-netmod-node-tags-11.txt is now available. It is a 
> work item of the Network Modeling (NETMOD) WG of the IETF.
> 
>   Title:   Node Tags in YANG Modules
>   Authors:  Qin Wu
>Benoit Claise
>Mohamed Boucadair
>Peng Liu
>Zongpeng Du
>   Name:draft-ietf-netmod-node-tags-11.txt
>   Pages:   30
>   Dates:   2023-10-21
> 
> Abstract:
> 
>   This document defines a method to tag nodes that are associated with
>   the operation and management data in YANG modules.  This method for
>   tagging YANG nodes is meant to be used for classifying either data
>   nodes or instances of data nodes from different YANG modules and
>   identifying their characteristic data.  Tags may be registered as
>   well as assigned during the definition of the module, assigned by
>   implementations, or dynamically defined and set by users.
> 
>   This document also provides guidance to future YANG data model
>   writers; as such, this document updates RFC 8407.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-node-tags/
> 
> There is also an HTMLized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-node-tags-11
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-netmod-node-tags-11
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 
> 
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> 
> ___
> 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] draft-ietf-netmod-rfc8407bis: must + error-message for "config false"

[Kent Watsen]

My confusion, sorry, I was thinking “mandatory”.

Must statements on opstate are useful, but less important.

Kent


> On Nov 6, 2023, at 5:26 PM, Kent Watsen  wrote:
> 
> “Must” statements on opstate usefully helps clients know when certain values 
> will always appear, enabling better optimization and usability.
> 
> E.g., for Syslog messages, there must always be a timestamp, severity, and a 
> message.  It would be unhelpful for the server to not declare its intention 
> to always send these fields.
> 
> Kent
> 
> 
>> On Nov 6, 2023, at 10:49 AM, Jason Sterne (Nokia)  
>> wrote:
>> 
>> +1 on what Jurgen and Rob are pointing out here.
>> 
>> I'm not sure it makes a ton of sense to actually have a lot of "must" 
>> statements in state models. We could consider discouraging them?  (but we 
>> need to continue *allowing* them).
>> 
>> Jason
>> 
>>> -Original Message-
>>> From: netmod  On Behalf Of Rob Wilton
>>> (rwilton)
>>> Sent: Thursday, November 2, 2023 5:17 AM
>>> To: Jürgen Schönwälder ;
>>> mohamed.boucad...@orange.com
>>> Cc: netmod@ietf.org
>>> Subject: Re: [netmod] draft-ietf-netmod-rfc8407bis: must + error-message
>>> for "config false"
>>> 
>>> 
>>> 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.
>>> 
>>> 
>>> 
>>> Specifically regarding MUST statements on state date, RFC 8342 section 5.3,
>>> also has this statement (which effectively aligns to Jürgen's last 
>>> paragraph):
>>> 
>>>   SHOULD conform to any constraints specified in the data
>>>  model, but given the principal aim of returning "in use" values, it
>>>  is possible that constraints MAY be violated under some circumstances
>>>  (e.g., an abnormal value is "in use", the structure of a list is
>>>  being modified, or remnant configuration (see Section 5.3.1) still
>>>  exists).  Note that deviations SHOULD be used when it is known in
>>>  advance that a device does not fully conform to the 
>>>  schema.
>>> 
>>>  Only semantic constraints MAY be violated.  These are the YANG
>>>  "when", "must", "mandatory", "unique", "min-elements", and
>>>  "max-elements" statements; and the uniqueness of key values.
>>> 
>>>  Syntactic constraints MUST NOT be violated, including hierarchical
>>>  organization, identifiers, and type-based constraints.  If a node in
>>>   does not meet the syntactic constraints, then it
>>>  MUST NOT be returned, and some other mechanism should be used to
>>> flag
>>>  the error.
>>> 
>>> Regards,
>>> Rob
>>> 
>>> 
>>> -Original Message-
>>> From: netmod  On Behalf Of Jürgen
>>> Schönwälder
>>> Sent: Wednesday, November 1, 2023 7:46 AM
>>> To: mohamed.boucad...@orange.com
>>> Cc: netmod@ietf.org
>>> Subject: Re: [netmod] draft-ietf-netmod-rfc8407bis: must + error-message
>>> for "config false"
>>> 
>>> Here is what RFC 7950 says:
>>> 
>>> 7.5.4.1.  The "error-message" Statement
>>> 
>>>The "error-message" statement, which is optional, takes a string as
>>>an argument.  If the constraint evaluates to "false", the string is
>>>passed as  in the  in NETCONF.
>>> 
>>> Since state data is not (directly) modified by processing RPCs, which
>>>  would carry the ? If the answer is 'none',
>>> then why define an  for state data?
>>> 
>>> My take has always been that operational state data should report as
>>> much as possible the true state of the device - even if the current
>>> state violates certain constraints. The entity to check constraints
>>> would be a managing system, not the managed system. That said, the
>>> wording in section 7.5.4.1 indicates that the designers had servers
>>> processing RPCs in mind.
>>> 
>>> /js
>>> 
>>> On Tue, Oct 31, 2023 at 10:40:15AM +,
>>> mohamed.boucad...@orange.com wrote:
>>>> Hi all,
>>>> 
>>>> In the context of 
>>>> https://datatracker.ietf.org/doc/dr

Re: [netmod] draft-ietf-netmod-rfc8407bis: must + error-message for "config false"

[Kent Watsen]

“Must” statements on opstate usefully helps clients know when certain values 
will always appear, enabling better optimization and usability.

E.g., for Syslog messages, there must always be a timestamp, severity, and a 
message.  It would be unhelpful for the server to not declare its intention to 
always send these fields.

Kent


> On Nov 6, 2023, at 10:49 AM, Jason Sterne (Nokia)  
> wrote:
> 
> +1 on what Jurgen and Rob are pointing out here.
> 
> I'm not sure it makes a ton of sense to actually have a lot of "must" 
> statements in state models. We could consider discouraging them?  (but we 
> need to continue *allowing* them).
> 
> Jason
> 
>> -Original Message-
>> From: netmod  On Behalf Of Rob Wilton
>> (rwilton)
>> Sent: Thursday, November 2, 2023 5:17 AM
>> To: Jürgen Schönwälder ;
>> mohamed.boucad...@orange.com
>> Cc: netmod@ietf.org
>> Subject: Re: [netmod] draft-ietf-netmod-rfc8407bis: must + error-message
>> for "config false"
>> 
>> 
>> 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.
>> 
>> 
>> 
>> Specifically regarding MUST statements on state date, RFC 8342 section 5.3,
>> also has this statement (which effectively aligns to Jürgen's last 
>> paragraph):
>> 
>>SHOULD conform to any constraints specified in the data
>>   model, but given the principal aim of returning "in use" values, it
>>   is possible that constraints MAY be violated under some circumstances
>>   (e.g., an abnormal value is "in use", the structure of a list is
>>   being modified, or remnant configuration (see Section 5.3.1) still
>>   exists).  Note that deviations SHOULD be used when it is known in
>>   advance that a device does not fully conform to the 
>>   schema.
>> 
>>   Only semantic constraints MAY be violated.  These are the YANG
>>   "when", "must", "mandatory", "unique", "min-elements", and
>>   "max-elements" statements; and the uniqueness of key values.
>> 
>>   Syntactic constraints MUST NOT be violated, including hierarchical
>>   organization, identifiers, and type-based constraints.  If a node in
>>does not meet the syntactic constraints, then it
>>   MUST NOT be returned, and some other mechanism should be used to
>> flag
>>   the error.
>> 
>> Regards,
>> Rob
>> 
>> 
>> -Original Message-
>> From: netmod  On Behalf Of Jürgen
>> Schönwälder
>> Sent: Wednesday, November 1, 2023 7:46 AM
>> To: mohamed.boucad...@orange.com
>> Cc: netmod@ietf.org
>> Subject: Re: [netmod] draft-ietf-netmod-rfc8407bis: must + error-message
>> for "config false"
>> 
>> Here is what RFC 7950 says:
>> 
>>  7.5.4.1.  The "error-message" Statement
>> 
>> The "error-message" statement, which is optional, takes a string as
>> an argument.  If the constraint evaluates to "false", the string is
>> passed as  in the  in NETCONF.
>> 
>> Since state data is not (directly) modified by processing RPCs, which
>>  would carry the ? If the answer is 'none',
>> then why define an  for state data?
>> 
>> My take has always been that operational state data should report as
>> much as possible the true state of the device - even if the current
>> state violates certain constraints. The entity to check constraints
>> would be a managing system, not the managed system. That said, the
>> wording in section 7.5.4.1 indicates that the designers had servers
>> processing RPCs in mind.
>> 
>> /js
>> 
>> On Tue, Oct 31, 2023 at 10:40:15AM +,
>> mohamed.boucad...@orange.com wrote:
>>> Hi all,
>>> 
>>> In the context of 
>>> https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-yang/,
>> Dhruv has received in the past a comment about the use of "must + error-
>> message" for "config false" data nodes. He reported that comment at
>> https://mailarchive.ietf.org/arch/msg/yang-
>> doctors/gWnXnyNHPVv_nZB1PQjThAwP1JY/, but without any follow-up.
>>> 
>>> rfc7950#section-8.1 includes a provision for the use of "must" for state
>> data, but silent about the use of error-message. Some guidance for authors
>> may be useful here.
>>> 
>>> The following options are being considered:
>>> 
>>> (1) Remove both must and error-message for config false data nodes
>>> (2) Remove error-message but keep the must
>>> (3) keep both
>>> 
>>> I think that (3) is OK as this is a formal way to detect anomalies in state
>> data, but I'm open to hear what the WG thinks.
>>> 
>>> Opinions whether we need to include a mention about this in draft-ietf-
>> netmod-rfc8407bis are welcome.
>>> 
>>> Thank you.
>>> 
>>> Cheers,
>>> Med
>>> 
>>> 
>> __
>> __
>>> 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 

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

[Kent Watsen]

Hi Jan,

RFC 8342 defines the ability for "configuration transformations” to map 
 to , which is "subject to validation”.Section 5.1.4 
describes cross-cutting features, such as deactivating nodes and templating, 
that can result in an invalid , when  is considered alone.  
However, clients can "offline-validate ", when such features are in 
use, by groking and applying the processing-logic behind the features 
(mimicking that which the server does to produce ), and then 
YANG-validate the result (same as the server).  All this is well understood, 
expected, and good - right?

FWIW, these features have been implemented in Junos for as long as I know.  And 
yes, the Juniper NMS systems I worked on offline-validated “” before 
 by mimicking the processing logic locally, as described above.

What Qiufang proposes now adds to this.  It is one more thing for clients 
wishing to offline-validate  to mimic.   In this case, they need to 
mimic the merging of  and , which entails the clients also 
fetching  from the server, in case they don’t have it already.

None of this takes away from transactional interfaces, machine readable 
constraints, high automation levels, or the ability for clients to express 
intent.

With regards to owner and consumer value, I see each of these three features 
(deactivating nodes, templating, and ) as providing clients 
greater/better flexibility/control/insight.  Agreed?

Kent



> On Oct 26, 2023, at 10:42 AM, Jan Lindblad (jlindbla) 
>  wrote:
> 
> Qiufang,
> 
> While we have tools that actually do offline validation a lot, I am not 
> against discussing removing that possibility from YANG (in a multi-year 
> plan), if there are strong benefits with this idea. So far I haven't seen 
> them.
> 
> In the old SNMP world, we had MIB models. They described what you could read 
> and write, but not when you could do so or how things interacted. Now we have 
> YANG-based interfaces that are transactional (sequencing no longer a client 
> concern) and with machine readable constraints. I don't see any way to reach 
> the high automation levels we are enjoying today without this. These 
> principles are bringing a lot of very tangible owner and consumer value $€¥ 
> every day.
> 
> Running reflects the client's intent. If an upcoming intent can no longer be 
> validated by anybody else than the system being managed, and the rules by 
> which it validates running depends on a black box, then it becomes very hard 
> for the client to express its intent. Sounds like we'd be going back to the 
> SNMP age.
> 
> If anyone can explain a) how a client should go about expressing its intent 
> in a world where running no longer needs to be valid, and b) what the strong 
> benefits of this model would be, I'd be happy to discuss.
> 
> Best Regards,
> /jan
> 
> 
> 
>> 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
>> 

Re: [netmod] YANG Versioning: discussion around 7950 bis or errata (from Key Issue #1)

[Kent Watsen]

This was my thought as well, that it would be best to have the 
smallest-possible draft update 6020/7950.  That way, when someone follows the 
“Updated” links, they’re not overloaded with material that could’ve been left 
out.

Jason was saying that just doing MUST/SHOULD by alone isn’t great, that at 
least the "rev:non-backwards-compatible” extension statement should be included 
and, by extension I suppose, the rules for editing the revision history.  
Presumably revision labels could be left out.  IDK what minimal is possible.

K. // contributor



> On Sep 27, 2023, at 7:06 PM, Rodney Cummings 
>  wrote:
> 
>> It is easy to write a short RFC updating RFC 7950, changing one sentence 
>> from MUST to SHOULD.
> 
> I agree. I found that I cannot enter a response to the poll, because I 
> disagree with both Option 1 and Option 2.
> 
> My concern is that there are many people out there who are implementing YANG, 
> but who do not follow discussions on this mailing list. I'm concerned that 
> there is a serious risk that those people will interpret the change from MUST 
> to SHOULD as "backward compatibility is irrelevant for YANG". We all know 
> that the concern is about bug fixes and so on, but without explaining that in 
> a short and focused manner (i.e., the short RFC described above), that will 
> be lost in the noise of the larger draft-ietf-netmod-yang-module-versioning 
> change.
> 
> draft-ietf-netmod-yang-module-versioning is a great draft, but I think it 
> should move forward as an independent RFC, distinct from the MUST/SHOULD 
> change.
> 
> Rodney Cummings
> 
> -Original Message-
> From: netmod mailto:netmod-boun...@ietf.org>> On 
> Behalf Of Jürgen Schönwälder
> Sent: Tuesday, September 26, 2023 5:24 PM
> To: Jason Sterne (Nokia)  >
> Cc: netmod@ietf.org 
> Subject: Re: [netmod] YANG Versioning: discussion around 7950 bis or errata 
> (from Key Issue #1)
> 
> It is easy to write a short RFC updating RFC 7950, changing one sentence from 
> MUST to SHOULD. This is inline with the goal to not change the language, 
> i.e., to keep the version numbers.
> 
> /js
> 
> On Tue, Sep 26, 2023 at 03:00:19PM +, Jason Sterne (Nokia) wrote:
>> Hello NETMOD WG,
>> 
>> We've had a poll going for a few weeks to determine if we require YANG 1.2 
>> for allowing ("SHOULD NOT") NBC changes (see "Poll on YANG Versioning NBC 
>> Approach").
>> 
>> As part of that, some discussion has happened on the list around
>> potentially doing an errata for RFC7950/6020 or a bis of 7950/6020 (if
>> rough consensus is reached for option 1 of the poll)
>> 
>> 7-8 of us discussed this in the YANG Versioning weekly call group today.
>> 
>> First of all: this question of mechanics (errata vs bis vs Module Versioning 
>> draft) is orthogonal to the poll. Let's first and separately resolve the 
>> poll and confirm if we need YANG 1.2 or not (that's the fundamental question 
>> the poll is resolving - everything else is a subsequent issue to be 
>> discussed). We'll let the chairs confirm when/if rough consensus on the poll 
>> has been reached.
>> 
>> But *if* the answer to the poll is option 1, then the weekly call group was 
>> unanimous that we should not do an errata for RFC7950/6020 and we should not 
>> do a 7950/6020 bis. We should just continue with the Module Versioning draft 
>> which will update 7950 and 6020.
>> 
>> The primary reason is that we shouldn't just change MUST NOT to SHOULD NOT 
>> without also tying it together with the mandatory top level 
>> rev:non-backwards-compatible extension when an NBC change is done. Changing 
>> the NBC rule to SHOULD NOT needs to be in the same RFC as the mandatory 
>> rev:non-backwards-compatible tag.
>> 
>> Other reasons:
>> 
>>  *   an errata probably isn't correct since this isn't fixing an intent that 
>> was present back when 7950 was written (it was clearly the intent at the 
>> time to block NBC changes)
>>  *   a bis would be odd without actually introducing other changes to YANG 
>> and changing the version (this discussion is all based on "if the answer to 
>> the poll is option 1")
>> 
>> Jason (he/him)
>> 
> 
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.i/
>> etf.org 
>> %2Fmailman%2Flistinfo%2Fnetmod=05%7C01%7C%7C22464d2aa09441
>> f1b1bd08dbbedf65ad%7C84df9e7fe9f640afb435%7C1%7C0%7C638313
>> 638956186415%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
>> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=DgsZVlBTQtqJjR
>> tVXs%2Bze%2BrOanijgDEuCn93gbN9Jyw%3D=0
> 
> 
> --
> 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
> 

Re: [netmod] Poll on YANG Versioning NBC Approach

[Kent Watsen]

[All, don’t forget to vote, discussion here doesn’t count!  
https://notes.ietf.org/netmod-2023-sept-poll]


> On Sep 12, 2023, at 12:06 PM, Andy Bierman  wrote:
> 
> So there is choice between:
> 
>   (A) YANG 1.1 and SHOULD NOT
>   (B) YANG 1.2 and SHOULD NOT

Thanks Andy, this is a succinct way to frame it.

  
> (A) is acceptable.
> YANG 1.2 would create a false expectation in the user community that the IETF
> had improved the YANG language somehow.

Agreed.


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

[netmod] Poll on YANG Versioning NBC Approach

[Kent Watsen]

WG,

Please help the YANG-versioning effort move forward by participating in the 
following poll:

  - https://notes.ietf.org/netmod-2023-sept-poll  (Datatracker login required)

Kent and Lou

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

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

[Kent Watsen]

NETMOD WG,

This email begins a 2-week adoption poll for: 
https://datatracker.ietf.org/doc/draft-ma-netmod-immutable-flag/08

There is no known IPR on this draft (IPR call 
).

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

Thank you,
Kent (as co-chair)

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

Re: [netmod] Adoption poll for draft-haas-netmod-unknown-bits-02

[Kent Watsen]

Thank you everyone that participated in the poll.
Based on the results, there isn’t sufficient support to adopt the draft at this 
time.

Kent and Lou


> On Aug 3, 2023, at 2:02 PM, Kent Watsen  wrote:
> 
> NETMOD WG,
> 
> This email begins a 2-week adoption poll for: 
> https://datatracker.ietf.org/doc/draft-haas-netmod-unknown-bits/02
> 
> There is no known IPR on this draft (IPR call 
> <https://mailarchive.ietf.org/arch/msg/netmod/zJPEgqyi9yXzRqPO6NPJklQsBcU/>).
> 
> Please voice your support or technical objections to adoption on the list by 
> the end of the day (any time zone) Aug 17.
> 
> PS: I was hoping that Jeff would update the draft to reflect comments 
> received on-list (e.g., here 
> <https://mailarchive.ietf.org/arch/msg/netmod/8vk2TU2yaT8kLc1N7sbxiVs27UY/>) 
> before starting this poll, but he is going on PTO shortly and wouldn’t be 
> able to get to it for awhile, though he’s happy to do so upon returning.
> 
> 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] Regarding IPR on draft-ma-netmod-immutable-flag-08

[Kent Watsen]

Hi Balazs,

Can you response to this IPR poll please?

FWIW, your response to this poll is not indicative of your support for the 
draft, which is what the adoption poll is for.

Kent


> On Aug 22, 2023, at 9:46 AM, Kent Watsen  wrote:
> 
> 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

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

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

[Kent Watsen]

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

[netmod] Adoption poll for draft-haas-netmod-unknown-bits-02

[Kent Watsen]

NETMOD WG,

This email begins a 2-week adoption poll for: 
https://datatracker.ietf.org/doc/draft-haas-netmod-unknown-bits/02

There is no known IPR on this draft (IPR call 
).

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

PS: I was hoping that Jeff would update the draft to reflect comments received 
on-list (e.g., here 
) 
before starting this poll, but he is going on PTO shortly and wouldn’t be able 
to get to it for awhile, though he’s happy to do so upon returning.

Thank you,
Kent (as Co-chair)

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

Re: [netmod] Lines too long in YANG tree diagrams

[Kent Watsen]

> But what I do for readability and to avoid lint issues is use rfcfold on 
> trees or examples that have long lines.  For the examples that are xml or 
> json based, the consumer of the RFC needs to reverse the fold so that the 
> example works in yanglint or other tools.

It would be ideal for Datatracker to unfold folded-artwork for other output 
formats, specifically HTML, where a horizontal scrollbar could be used.


> I could editorialize about how in 2023 we are still hindered by a limit 
> imposed by a VT100 from 1978, but I have said enough.

No kidding, this is what I was thinking when I wrote `rfcfold`.


> Regards,
> -scott.

K.


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

Re: [netmod] Lines too long in YANG tree diagrams

[Kent Watsen]

Hi Italo,

> On Jul 5, 2023, at 5:58 PM, Italo Busi 
>  wrote:
> 
> RFC8340 suggests to use the "--tree-line-length 69" option to produce YANG 
> tree diagrams to be included into an Internet-Draft or RFC.
>  
> Although this option works well in many cases, there are few cases where 
> pyang produces YANG tree diagram with lines too long even with the 
> "--tree-line-length 69" option and in this case it is not fully clear what 
> could be done when including those YANG tree diagram into Internet-Drafts or 
> RFCs
>  
> Section 5.2 of RFC8792 says:
>  
> It is RECOMMENDED that authors do as much as possible within the selected 
> format to avoid long lines.
>  
> My interpretation of the RECOMMENDED key word and of “as much as possible” is 
> that we MUST always use the "--tree-line-length 69" option to generate the 
> YANG tree diagrams to be included into Internet-Drafts or RFCs and that we 
> MAY use RFC8792 tool to fold the YANG tree diagrams when they contain lines 
> too long
>  
> Is my interpretation correct?

Sounds right to me, and is what my automation scripts do.

Pro-tip: `rfcfold` won’t fold a file that doesn’t need folding, i.e., the 
output file will equal the input file.

> Thanks, Italo

K.


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

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

[Kent Watsen]

WG,

The chairs want to follow up on this Last Call. 

We had some excellent discussion and wanted to ensure that that discussion had 
time to play out.  We think think that there is still a path forward for "rough 
consensus" on the these drafts.  To help move the discussion to closure and aid 
in judging overall WG consensus (beyond just those who have already voiced an 
opinion on the list), we have asked the draft authors to put together a summary 
of key open issues/questions, to send their summary  to the list, and then to 
lead a discussion on these issues during our meeting at IETF 117.  Please do 
feel free to continue the discussion on the list. We are particularly 
interested in hearing from those who have not yet voiced their opinions - both 
on list, and in the meeting.

We appreciate all who have contributed over this extended effort - notably 
those who have spent many hours in the regular working meetings.

Thank you,
Lou and Kent




> On May 8, 2023, at 6:49 PM, Kent Watsen  wrote:
> 
> Dear NETMOD WG,
> 
> This message begins a joint two-week WGLC for 
> draft-ietf-netmod-yang-semver-11 and 
> draft-ietf-netmod-yang-module-versioning-09
> ending on Monday, May 22nd.  Neither draft has IPR declared.  Here are the 
> direct links to the HTML version for these drafts:
> 
>   - https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-semver-11
>   - 
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning-09
> 
> 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 and Lou (chairs)
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> 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

[Kent Watsen]

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.

However, I only recall one case used for justification (see below).  It would 
be good to identify others cases.

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?  

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.



> Possibly, if the WG decides to adopt this work, it might be worth considering 
> whether this would be better documented as part of the system datastore draft?
> [Qiufang] Since we have decided to limit the scope of immutable flag to 
> system configuration and not support non-transactional APIs, it makes sense 
> to me for it to be documented in the system datastore draft.
> But as I mentioned above, we would like the immutable flag to work even when 
> the system datastore is not implemented.
> Even that said, I'm open to this, and okay to document it as part of system 
> datastore draft if the WG thinks it's a good idea.

Currently the “system-config” draft has an Informative reference to this draft. 
 Should it be a Normative reference, and the “system-config” draft state 
definitively that system data is marked as such per the “immutable-flag” draft?

Or do you mean to fold the “immutable-flag” draft back into the “system-config” 
draft (merge two drafts into one).  I personally do not wish for this.  Even if 
another immutable-flag use is never found.


> Regards,
> Rob
>  
> Best Regards,
> Qiufang

Kent

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

Re: [netmod] Unknown bits - backwards compatibility

[Kent Watsen]

H Jeff,

> I hadn’t realized that your intent was to skip directly to WGLC, unless this 
> was a typo.  Most WG process I deal with goes through at least a thin 
> adoption stage even if the intent is to move forward swiftly to last call.

I meant “adoption”.  No process skipping here!


>>  Specifically, I’m wondering if it makes sense to add a new section to 
>> provide guidance to implementors?   I’m unsure myself, as the concerns 
>> raised seem to be addressed by YANG Library, in that clients should use it 
>> to detect if the server is using a newer revision of modules than the client 
>> groks.
> 
> As Jason notes in his reply, I’m unclear what YANG library may do to help 
> this situation.

As Martin points out, a revision of a module using this typedef is backwards 
compatible (both the old and new modules define the same “unknown-flags” leaf 
with the same meaning, and adding new bits to the “flags” leaf is allowed per 
RFC 7950, Section 11.  The concern isn’t that the module revision is NBC, but 
that the data changed and that, a client coded to look-for/act-on the presence 
of an unknown bit would break, which could be construed as NBC at the *data* 
level.  My point with regards to YL is that this is nothing new.  New revisions 
of modules can always come out with new nodes and clients always need to update 
themselves to understand the module versions used by the server.

In this case, the debate is particularly shallow.  Firstly, I think that it is 
bad form for a client to be coded to look-for/act-on the “unknown bits”.  So 
the "NBC at the data level” case shouldn’t occur in practice.  Next, as my edit 
below alludes, when a bit goes from being unknown to known, a new revision of 
the module will be defined and implemented by the server, meaning the server 
will start sending the new bit in the, e.g., “flags” leaf.  That the server 
stopped sending the bit in the “unknown-flags” leaf is secondary to that 
started sending it in the “flags” leaf.   A client that “breaks" because an 
unknown-bit isn’t sent will more surely break  because a new known bit is sent. 
 Again, one purpose of YL is for clients to ensure they’re up to date wrt to 
the servers it connects to.


> I’m certainly fine adding an additional section to the draft discussing that 
> unknown bits may “disappear” during maintenance as previously unknown bits 
> become defined.

Something that captures some of what I wrote above?  


>> One new comment: the "unknown-bits” typedef's description statement seems 
>> unclear in terms of the expected reconciliation process.
>> 
>> Current:
>>   "Typedef describing 64 bits worth of unknown bits.  This can be
>>used to model operational state that would normally be modeled
>>using the YANG 'bits' type, but no registered bit has been
>>created.”;
>> 
>> Proposed:
>> 
>>   "Typedef describing 64 bits worth of unknown bits.  This can be
>>used to model operational state that would normally be modeled
>>using the YANG 'bits' type, but no registered bit has been
>>defined in the YANG module implemented by the server.”;
>> 
> 
> I’m fine making this change.

I refrained from expanding the description statement even more, but leave it to 
you to consider.  I was thinking to also add something like:

This typedef is intended to be used to model a “catch all” leaf for when, e.g., 
over-the-wire protocol data contains bits not representable by the module 
implemented by the server.  The “unknown-bits” data should be considered 
short-lived, as the bits will be known as soon as the server updates to a 
module revision defining them.   Implementations should not look for or act on 
the presence of unknown bits.


And then, for implementations that disregard that advice, they can always 
update themselves:

OLD

if unknown-flags.bit-3:
foo

NEW

if unknown-flags.bit-3 or known-flags.my-foo-bit:
foo

I don’t see the reason to force servers to carry-forwards (forever) the 
reporting of previously unknown bits.


> — Jeff

K.


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

Re: [netmod] Unknown bits - backwards compatibility

[Kent Watsen]

Hi Jeff,

I’ve been hoping you would reply to some of the comments here before kicking 
off the WGLC.  Specifically, I’m wondering if it makes sense to add a new 
section to provide guidance to implementors?   I’m unsure myself, as the 
concerns raised seem to be addressed by YANG Library, in that clients should 
use it to detect if the server is using a newer revision of modules than the 
client groks.

One new comment: the "unknown-bits” typedef's description statement seems 
unclear in terms of the expected reconciliation process.

Current:

  "Typedef describing 64 bits worth of unknown bits.  This can be
   used to model operational state that would normally be modeled
   using the YANG 'bits' type, but no registered bit has been
   created.”;

Proposed:

  "Typedef describing 64 bits worth of unknown bits.  This can be
   used to model operational state that would normally be modeled
   using the YANG 'bits' type, but no registered bit has been
   defined in the YANG module implemented by the server.”;

Thoughts?

K.



> On May 23, 2023, at 11:59 AM, Rob Wilton (rwilton) 
>  wrote:
> 
> I was looking at this draft again, and since I had read the -02 version of 
> the draft I thought that I would send the comments here.
> 
> My no hats view here (looking at the latest draft) is:
> documenting something here is probably helpful because this is an issue that 
> folks are experiencing and providing written guidance on how to handle it 
> helpful to the YANG modelling community.
> having such a document update RFC 8407 would probably be helpful (to help 
> YANG authors find it),
> but I’m concerned that the proposed solution is not backwards compatible at 
> the instance data level.  E.g., an old client talking to a new server would 
> still hit a problem if the server changed from sending an unknown "bit-" 
> to a known bit (defined in a backards-compatible module update), and if the 
> old client doesn't know/understand the now known bit (because they are still 
> coded against the older module version), then the client may break.  This 
> makes me think that there is going to be some subtleties around when it is 
> safe to not send an unknown bit, hence my suggestion was to call it just 
> “bits” (which is already in -02) and *always sending* this leaf may be a more 
> backwards compatible choice.  It isn’t clear to me, for the “all bits” leaf, 
> whether sending this as a raw uint8 – uint64, or binary, and doing the decode 
> on the client side (if required) might be a better choice than sending them 
> as a generic bits type.
> 
> Regards,
> Rob
>  
> From: netmod mailto:netmod-boun...@ietf.org>> On 
> Behalf Of Italo Busi
> Sent: 14 April 2023 09:05
> To: Jason Sterne (Nokia)  >; Jeffrey Haas  >; netmod@ietf.org 
> Subject: Re: [netmod] Unknown bits - backwards compatibility
>  
> Jason, Jeffrey,
>  
> If the need is to report the value of a received protocol field for 
> debugging/troubleshooting purposes, I am wondering why not using a binary 
> type instead of a bits type or, better, a YANG leaf of bits type for the 
> known bits and another YANG leaf of binary type for all known/unknown bits
>  
> Trailing zeros can be added when the protocol field is not an integer number 
> of octets
>  
> In this way there will be no backward compatibility issues when unknown bits 
> are assigned and becomes known
>  
> My 2 cents
>  
> Italo
>  
> From: Jason Sterne (Nokia)  > 
> Sent: mercoledì 12 aprile 2023 23:26
> To: Jason Sterne (Nokia)  >; Jeffrey Haas  >; netmod@ietf.org 
> Subject: Re: [netmod] Unknown bits - backwards compatibility
>  
> It just occurred to me that to avoid the NBC change we could also consider 
> just calling this new typedef “raw-bits” and always outputting all the bits 
> in the second leaf (whether they are known or not)?  I suspect this was 
> already considered though…
>  
> Jason
>  
> From: netmod mailto:netmod-boun...@ietf.org>> On 
> Behalf Of Jason Sterne (Nokia)
> Sent: Wednesday, April 12, 2023 5:24 PM
> To: Jeffrey Haas mailto:jh...@pfrc.org>>; netmod@ietf.org 
> 
> Subject: [netmod] Unknown bits - backwards compatibility
>  
> Hi Jeff,
>  
> One topic that came up during the IETF 116 NETMOD meeting was backwards 
> compatibility.
>  
> From what I understand, a leaf (e.g. unknown-flags) that uses the 
> unknown-bits typedef would never change its definition in YANG. It would 
> always be defined as unknown-bits with all 64 bit definitions even as more 
> and more bits become “known”.  *But* the system would suddenly stop reporting 
> bit-0, then bit-1 in that unknown-flags leaf as those bits become known.
>  
> Strictly speaking, that should probably be considered an NBC change although 
> it is a bit of a grey zone - the NBC 

[netmod] Call for IETF 117 Slot Requests

[Kent Watsen]

NETMOD WG,

The *draft* agenda for IETF117 has been posted
- https://datatracker.ietf.org/meeting/117/agenda

The NETMOD session information is scheduled to be held:

Wednesday, July 26, 2023
09:30-11:30 Tuesday Session I
Room: Continental 6
https://datatracker.ietf.org/meeting/117/sessions/netmod.ics

This will be an in-person meeting with remote participation access.

Please send slot requests to netmod-cha...@ietf.org 
 (CC-ed) before the end of the day Monday July 
10 (any TZ, but earlier is appreciated).  Please include draft names(s), 
presenter, desired slot length.  Also, please let us know if you think the 
topic would be better covered in a Virtual Interim to be held at a future date.

Thank you!

Kent (and Lou)



Important dates  (https://datatracker.ietf.org/meeting/important-dates):

2023-06-30  Fri Final agenda to be published.
2023-07-10  Mon Internet-Draft submission cut-off (for all 
Internet-Drafts, including -00) by UTC 23:59. Upload using the I-D Submission 
Tool.
2023-07-12  Wed Draft Working Group agendas due by UTC 23:59. 
Upload using the Meeting Materials Management Tool.
2023-07-17  Mon Revised Working Group agendas due by UTC 23:59. 
Upload using the Meeting Materials Management Tool.

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

[netmod] IPR Poll on draft-haas-netmod-unknown-bits-02

[Kent Watsen]

[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 an 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 and Lou

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

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

[Kent Watsen]

Hi Martin!


> I think you meant https://github.com/netmod-wg/yang-next/issues/49.

Yes but, in spirit of the idea, I suppose both would be in play, if at all.


>> IMO the parsing of YANG files to produce a conceptual data model
>> is a critical component of the language itself.  Any statements that
>> affect this conversion step MUST be regular statements.
>> An extension is (by definition) an external statement that is not part of
>> the YANG language.
>> Critical extensions are not a good design choice.
> 
> I strongly agree.  Allowing the language to drastically change (like
> in this example) by just defining a critical extension is not a good
> idea.  Basically, anyone can define their own extension that changes
> YANG to whatever, and still claim conformance.

I also agree, for this issue (versioning), but there may be other places where 
a "critical" flag would help (wit the conversation that issue generated).  That 
said, for a limited-scope rfc7950-bis, it would be fine to not pick up either 
of these issues.


>> Just add real statements
>> instead.
>> 
>> IMO most of the yang-next issues are not interesting or valuable,
>> so a long WG process to go through this entire list is a non-starter.
>> 
> 
> The problem is that everyone will have their own pet-issues that they
> think are critical...
> 
> 
>> There are 3 critical changes that need to be made.
>>  - change "status" so deprecated and obsolete definitions are
>>correct
> 
> ... for example I don't think this is critical ...
> 
>>  - introduce new instance-identifier data type based on RFC 7951 definition
>>  - introduce new identityref data type based on RFC 7951 definition
> 
> ... but I do agree with these!
> 
> 
> /martin


Whilst the chairs haven't closed this WGLC yet, I propose a YANG-next design 
team, asked to produce a limited-scope I-D they think best.  WG-objections of 
the form "my pet-issue isn't picked-up" should not be used to fail adoption 
(or, later, the WGLC).  Of course, objections to how the specific-issues 
picked-up were resolved are valid.  The goal being to most expediently (<1yr) 
forward the versioning work in a correct (contract-compliant) manner.  Support?

Kent




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

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

[Kent Watsen]

As an individual contributor and faithful YANG custodian, I cannot support work 
that changes YANG-semantics without versioning YANG itself.  As Andy wrote 
before:

The only correct way to remove MUST/MUST NOT from the "YANG contract" 
is to introduce a new YANG language version (1.2), and make a new contract.

I want this work to move forward in the form of a quick (limited-scope) 
rfc7950-bis.  One idea would to support just this YANG-next issue 
<https://github.com/netmod-wg/yang-next/issues/70> and then mark the versioning 
extension as "critical".  That said, I believe that an even better 
versioning-solution can be had if integrated into the YANG-language directly.   

Kent


> On May 22, 2023, at 6:20 PM, Kent Watsen  wrote:
> 
> NETMOD WG,
> 
> The chairs are extending this WGLC by two weeks (now ending June 5) in order 
> to ensure adequate review, since this is important work, and a solid 
> consensus is needed.
> 
> Kent and Lou
> 
> 
> 
>> On May 8, 2023, at 6:49 PM, Kent Watsen  wrote:
>> 
>> Dear NETMOD WG,
>> 
>> This message begins a joint two-week WGLC for 
>> draft-ietf-netmod-yang-semver-11 and 
>> draft-ietf-netmod-yang-module-versioning-09
>> ending on Monday, May 22nd.  Neither draft has IPR declared.  Here are the 
>> direct links to the HTML version for these drafts:
>> 
>>  - https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-semver-11
>>  - 
>> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning-09
>> 
>> 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 and Lou (chairs)
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> ___
>> 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 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

[Kent Watsen]

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



> On May 25, 2023, at 8:16 AM, maqiufang (A) 
>  wrote:
> 
> 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

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

Re: [netmod] Query RFC-8348 hardware model

[Kent Watsen]

Forwarding to the authors of the RFC.

K.


> On May 30, 2023, at 3:47 AM, Vanapatla Ramana (Nokia) 
>  wrote:
> 
> Hello Team,
>  
> Gentle remainder on the below query.
>  
> Regards,
> Ramana
>  
> From: Vanapatla Ramana (Nokia) 
> Sent: Friday, May 5, 2023 8:05 PM
> To: draft-ietf-netmod-ent...@ietf.org; netmod@ietf.org
> Cc: Bart Bogaert (Nokia) ; Ludwig Pauwels (Nokia) 
> ; Yves Beauville (Nokia) 
> Subject: Query RFC-8348 hardware model
>  
> Hello
>  
> notification ‘hardware-state-oper-enabled’, notification 
> ‘hardware-state-oper-disabled’ contains leaf admin-state, alarm-state  
> referring to path "/hardware/component/state/admin-state" , 
> "/hardware/component/state/alarm-state" but not specifying instance of 
> hardware component
> Should this be changed to "/hardware/component[name = 
> current()/../name]/state/admin-state","/hardware/component[name = 
> current()/../name]/state/alarm-state" so that it is in-line with the notation 
> shown in  RFC7950 examples?
>  
> RFC-8348   Example
> notification hardware-state-oper-disabled {
> leaf name {
> type leafref {
>   path "/hardware/component/name";
> }
> leaf admin-state {
> type leafref {
>   path "/hardware/component/state/admin-state";
> }
> leaf alarm-state {
> type leafref {
>   path "/hardware/component/state/alarm-state";
> }
> }
> RFC7950 indicates to refer instance in page 162, 160
> Page 162
> The following notification defines two leafrefs to refer to an existing 
> admin-status:
>  notification link-failure {
>leaf if-name {
>  type leafref {
>path "/interface/name";
>  }
>}
>leaf admin-status {
>  type leafref {
>path "/interface[name = current()/../if-name]"
>   + "/admin-status";
>  }
>}
>  
> Page 160
> The following leafrefs refer to an existing address of an interface:
> container default-address {
>leaf ifname {
>  type leafref {
>path "../../interface/name";
>  }
>}
>leaf address {
>  type leafref {
>path "../../interface[name = current()/../ifname]"
>   + "/address/ip";
>  }
>}
> }
>  
> Regards,
> Ramana
> ___
> 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] Query RFC-8348 hardware model

[Kent Watsen]

Forwarding to the authors of the RFC.

K.


> On May 30, 2023, at 3:47 AM, Vanapatla Ramana (Nokia) 
>  wrote:
> 
> Hello Team,
>  
> Gentle remainder on the below query.
>  
> Regards,
> Ramana
>  
> From: Vanapatla Ramana (Nokia) 
> Sent: Friday, May 5, 2023 8:05 PM
> To: draft-ietf-netmod-ent...@ietf.org; netmod@ietf.org
> Cc: Bart Bogaert (Nokia) ; Ludwig Pauwels (Nokia) 
> ; Yves Beauville (Nokia) 
> Subject: Query RFC-8348 hardware model
>  
> Hello
>  
> notification ‘hardware-state-oper-enabled’, notification 
> ‘hardware-state-oper-disabled’ contains leaf admin-state, alarm-state  
> referring to path "/hardware/component/state/admin-state" , 
> "/hardware/component/state/alarm-state" but not specifying instance of 
> hardware component
> Should this be changed to "/hardware/component[name = 
> current()/../name]/state/admin-state","/hardware/component[name = 
> current()/../name]/state/alarm-state" so that it is in-line with the notation 
> shown in  RFC7950 examples?
>  
> RFC-8348   Example
> notification hardware-state-oper-disabled {
> leaf name {
> type leafref {
>   path "/hardware/component/name";
> }
> leaf admin-state {
> type leafref {
>   path "/hardware/component/state/admin-state";
> }
> leaf alarm-state {
> type leafref {
>   path "/hardware/component/state/alarm-state";
> }
> }
> RFC7950 indicates to refer instance in page 162, 160
> Page 162
> The following notification defines two leafrefs to refer to an existing 
> admin-status:
>  notification link-failure {
>leaf if-name {
>  type leafref {
>path "/interface/name";
>  }
>}
>leaf admin-status {
>  type leafref {
>path "/interface[name = current()/../if-name]"
>   + "/admin-status";
>  }
>}
>  
> Page 160
> The following leafrefs refer to an existing address of an interface:
> container default-address {
>leaf ifname {
>  type leafref {
>path "../../interface/name";
>  }
>}
>leaf address {
>  type leafref {
>path "../../interface[name = current()/../ifname]"
>   + "/address/ip";
>  }
>}
> }
>  
> Regards,
> Ramana
> ___
> 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] Joint WGLC on "semver" and "module-versioning" drafts

[Kent Watsen]

NETMOD WG,

The chairs are extending this WGLC by two weeks (now ending June 5) in order to 
ensure adequate review, since this is important work, and a solid consensus is 
needed.

Kent and Lou



> On May 8, 2023, at 6:49 PM, Kent Watsen  wrote:
> 
> Dear NETMOD WG,
> 
> This message begins a joint two-week WGLC for 
> draft-ietf-netmod-yang-semver-11 and 
> draft-ietf-netmod-yang-module-versioning-09
> ending on Monday, May 22nd.  Neither draft has IPR declared.  Here are the 
> direct links to the HTML version for these drafts:
> 
>   - https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-semver-11
>   - 
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning-09
> 
> 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 and Lou (chairs)
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> 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] Joint WGLC on "semver" and "module-versioning" drafts

[Kent Watsen]

Dear NETMOD WG,

This message begins a joint two-week WGLC for draft-ietf-netmod-yang-semver-11 
and draft-ietf-netmod-yang-module-versioning-09
 ending on Monday, May 22nd.  Neither draft has IPR declared.  Here are the 
direct links to the HTML version for these drafts:

   - https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-semver-11
   - 
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning-09

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 and Lou (chairs)








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

Re: [netmod] WGLC on draft-ietf-netmod-syslog-model-28

[Kent Watsen]

All, thank you for the responses, especially the fresh review by Jeff Hartley.

The WGLC has successfully closed.  The draft's state is now "WG Consensus: 
Waiting for Write-Up".  I will begin the Shepherd write-up now.

Kent  // as co-chair and shepherd 


> On Mar 6, 2023, at 9:21 AM, Kent Watsen  wrote:
> 
> NETMOD WG,
> 
> We started a WGLC on the Syslog model ~7 weeks ago, to which Reshad voiced a 
> concern which was addressed in last week's update, per Joe's email here: 
> https://mailarchive.ietf.org/arch/msg/netmod/uML_a4oCZU7FdH95A6LENmCd1VI/.
> 
> Given that this draft has been a work-in-progress for some time, with 
> numerous reviews, I (as Shepherd and co-Chair) am thinking to progress it 
> now, even though the most recent WGLC solicited only one response, being 
> Reshad's.
> 
> Are there any objections to this proposal?
> 
> Thanks,
> Kent
> 
> 
>> On Jan 13, 2023, at 8:04 AM, Kent Watsen  wrote:
>> 
>> Dear NETMOD WG,
>> 
>> This message begins a two-week WGLC for draft-ietf-netmod-syslog-model-28 
>> ending on Friday, January 27th.  Here is a direct link to the HTML version 
>> of the draft:
>> 
>>  https://datatracker.ietf.org/doc/html/draft-ietf-netmod-syslog-model-28
>> 
>> 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 mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Comments on draft-ma-netmod-immutable-flag-06

[Kent Watsen]

Hi Qiufang,

> 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 ?

If the "node present in  is actually modifiable", then I surmise 
that it is NOT "immutable".  I believe that what you are describing is a normal 
(not immutable) "config true" node that happens to have an initial value set by 
the system, which could be seen in  using NMDA, perhaps having 
origin equal to "default", "learned", or "system".

Hmmm, I may need to backtrack on the `If the "origin" is "system", then 
immutability is "true"` statement.  Or rather, we may want to revisit the 
contents of .   I understand wanting  defining fixed interfaces 
(e.g., loopback), but maybe  *should not* define dynamically-generated 
configuration that is already visible in .  AFAICT, there isn't a 
need for  to contain *all* origin=system data, just the subset that is 
"config true" and, even then, maybe less.  Thoughts?

I guess I don't understand this example in the "system-config" draft: 
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-system-config#section-6.2.



> 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.

Understood.  It is indeed the goal for clients to use the "immutable" 
information to avoid knowably-invalid configurations.



> 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.

Thanks for tracking it.

 
> 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.

I didn't write that all system-defined nodes are immutable.  I wrote that all 
immutable-nodes are system-defined. There's a difference.  

I'm very much trying to assert that "immutable" data is life-cycled 
(created/changed/deleted) only by the server; a client can never 
create/change/delete immutable data.  At best a client can make immutable-data 
visible in , but they would only do that in order to, e.g, configure a 
mutable descendant (e.g., an interface's "description" or MTU) or, e.g., to 
reference it in a "must" or "when" expression.

That said, I do agree with your statement "I don’t think all system-defined 
nodes are immutable".  But, as I wrote at top above, the nodes should not be 
flagged as "immutable" (nor show up in ).  For such "config true" nodes 
that are given an initial (perhaps "default") value, it seems that the existing 
practice of reading the operational value from  prevails.


>  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 way to 
> validate it, and hence the server would, presumably, allow the update to 
> .  When the card is later installed, the interface would appear in 
> , and  if supported.  At that time the non-matching 
> value would be discovered.  Presumably the system would 1) ignore 

Re: [netmod] Comments on draft-ma-netmod-immutable-flag-06

[Kent Watsen]

> Where in the NC or YANG RFCs do we talk about immutable data? Where in
> the interfaces data model do we define that the type leaf becomes
> immutable once a line card has been plugged into a slot?

Following is from RFC 7223.  Note that the description statement almost says 
that the value is immutable:

 leaf type {
   type identityref {
 base interface-type;
   }
   mandatory true;
   description
 "The type of the interface.

  When an interface entry is created, a server MAY
  initialize the type leaf with a valid value, e.g., if it
  is possible to derive the type from the name of the
  interface.

  If a client tries to set the type of an interface to a
  value that can never be used by the system, e.g., if the
  type is not supported or if the type does not match the
  name of the interface, the server MUST reject the request.
  A NETCONF server MUST reply with an rpc-error with the
  error-tag 'invalid-value' in this case.";
   reference
 "RFC 2863: The Interfaces Group MIB - ifType";
 }

Also from RFC 7223, note that the value is used in a "when" expression:

 augment "/if:interfaces/if:interface" {
 when "if:type = 'ianaift:ethernetCsmacd'";

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


My assumption (not knowing the true history) is that the "type" node is 
historically "config false" and, in , might have origin "learned", 
or maybe "system".  For some reason that I'm unaware of, it was desirable for 
the "type" node to appear in , so that it can be, e.g., referenced in 
"must" and/or "when" statements.  That is, the "type" node in the YANG module 
was made to be "config true", but the "description" statement says that it is 
always expected to have the value that is (or will be, for a pluggable card) 
seen in .  Presumably, existing server behavior would reject (or 
ignore) a client's attempt to set the interface's "type" to anything other than 
it actually is.  If this is all true then all this draft does, for this 
specific example, is codify the "description" statement text to an "immutable" 
extension statement, so the behavior can be understood programmatically.

K.

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

Re: [netmod] Comments on draft-ma-netmod-immutable-flag-06

[Kent Watsen]

Hi Jürgen,

> I am not sure I follow. If I replace the line card, I may have to
> update the type of the interface config. Why would this be disallowed?

Nothing is being disallowed, by this proposal.  There is no new server 
behavior.  The proposal only enables a server to programmatically describe to a 
client what data it considers immutable.


> In the NC world, config is applied to resources. Validation is against
> the data model, not against the resources currently present on a
> system. See for example RFC 6241 section 8.6.1. with starts with:
> 
>   Validation consists of checking a complete configuration for
>   syntactical and semantic errors before applying the configuration to
>   the device.
> 
> This is why we have the notion of  ->  ->
> .  Initially, we did not expose  but operationally
> the possible difference between  and  is important
> enough that we started to expose it. But the point here is that the
> resources available do not influence whether  is valid. A
> valid configuration satisfies the data model constraints, it does not
> necessarily satisfy the resource constraints.

Agreed.

> 
> /js

K.


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

Re: [netmod] Comments on draft-ma-netmod-immutable-flag-06

[Kent Watsen]

Hi Frank,


> On Apr 25, 2023, at 9:36 PM, Fengchong (frank)  
> wrote:
> 
> Hi Kent,
>  Some nodes that are originally read-only have to appear in running because 
> they are referenced by other configurations.
>  For example, the type of interface, many other configurations may reference 
> it.
>  Just as:
>  container Ethernet-related {
>when ../type = 'ethernet'
>
>  }
>  So the leaf 'type' have to act as a configuration node to make the running 
> datastore valid. But in fact, the value of leaf 'type' should not be changed. 
>  So it's marked with 'immutable' is reasonable. If someone try to modify it, 
> reporting error from server should be acceptable.

I take this as an agreement to the below discussion.

Thanks,
Kent




> 
> 
> 
> -----邮件原件-
> 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Kent Watsen
> 发送时间: 2023年4月25日 19:53
> 收件人: Jürgen Schönwälder 
> 抄送: maqiufang (A) ; netmod@ietf.org; 
> Jan Lindblad (jlindbla) 
> 主题: Re: [netmod] Comments on draft-ma-netmod-immutable-flag-06
> 
> 
> Hi Jürgen,
> 
>> My assumption so far is that an interface configuration is matched 
>> against hardware and it is applied if there is matching hardware. In 
>> other words, if an edit makes the interface configuration not match 
>> the hardware anymore, then the config is simply not applied anymore 
>> and the interface is left unconfigured. (The same would happen if you 
>> replace an interface with another that does not match the current
>> config.) The idea that an interface configuration becomes partly 
>> immutable once it is applied to a matching physical interface is not 
>> really reflecting how I understand the design of N/Y.
> 
> My understanding is the same, so I assume there's a nuance in the detail.
> Let's use this example:
> 
>  list interface {
>key name;
>immutable true;  // the whole 'interface' object is immutable
>leaf name {
>  ...
>}
>leaf description {
>  Immutable false;  // client may provide a description
>  ...
>}
>leaf mac-addr {  // H/W provided.  Normally CF, but for some reason is
>  mandatory true;   // promoted to CT (for a 'must' or 'when' expression?)
>  ... // Please don't nitpick the validity of the 
> example, I could 
>} // construct a similar example using 
> built-in certs or keys.
>  }
> 
> Now say the client preconfigures:
> 
>  {
>"name": "sd3"
>"description": "uplink to closet-3",
>"mac-addr": "00" // real address unknown, so a fake one used
>  }
> 
> Now the card is inserted and "sd3" appears as:
> 
>  {
>"name": "sd3"
>"mac-addr": "1234567"
>  }
> 
> The merge fails because the client's mac-addr doesn't match the real one?
> 
> Ideally the immutable nodes (other than the keys) would NOT have to appear in 
> , but they do because "mandatory true"?
> 
> 
>> Also the notion
>> of immutable data in candidate, which is rather a scratchpad to 
>> assemble bigger changes, seems odd to me.
> 
> I had a similar reaction but, if  can be validated, doesn't it 
> follow that the immutable nodes need to be copied into it as well?
> 
> 
>> /js
> 
> K.
> 
> 
> ___
> 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] Comments on draft-ma-netmod-immutable-flag-06

[Kent Watsen]

Hi Andy,

> I hope the immutable flag will work with non-NMDA as well as the current NMDA.

Yes. 

A non-NMDA server can still:

Present YANG modules having the "immutable" extension statements.  It's up to 
the clients if they understand it and, if not, then nothing changes.

Return the "immutable" metadata annotation, if the client sends the 
`with-immutable` parameter in a get request.

The only thing "missing" is the ability for the client to get the  
datastore.  The ability to get  is desirable to discover, e.g., 
vendor-defined reference-able "shared" objects.   The same information could be 
supplied via another way, e.g., vendor documentation.

K.


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

Re: [netmod] Comments on draft-ma-netmod-immutable-flag-06

[Kent Watsen]

> Which merge fails?

 +  = 

> If the mac-addr in running does not match the
> hardware (and it has to match according to the model), then the
> interface config simply will not be applied.

Maybe that’s the answer.   I was thinking that just the ‘key’ fields were used 
to “match the hardware”. 


> One of the nice properties of the original NC design was that it
> exposes an API that hides certain complexities from the clients.  We
> now see proposals to expose data nodes controlled by "the system" and
> data nodes that can only modified if certain conditions are true etc.
> We are heading back to the SNMP world where you had to send sequences
> of set-requests in the order expected by the agent in order to get a
> job done.

Non-transactional API must be avoided.  I’m not promoting it.  I’m trying to 
find a way around it. 

> /js

K.


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

Re: [netmod] Comments on draft-ma-netmod-immutable-flag-06

[Kent Watsen]

Hi Jürgen,

> My assumption so far is that an interface configuration is matched
> against hardware and it is applied if there is matching hardware. In
> other words, if an edit makes the interface configuration not match
> the hardware anymore, then the config is simply not applied anymore
> and the interface is left unconfigured. (The same would happen if you
> replace an interface with another that does not match the current
> config.) The idea that an interface configuration becomes partly
> immutable once it is applied to a matching physical interface is not
> really reflecting how I understand the design of N/Y.

My understanding is the same, so I assume there's a nuance in the detail.
Let's use this example:

  list interface {
key name;
immutable true;  // the whole 'interface' object is immutable
leaf name {
  ...
}
leaf description {
  Immutable false;  // client may provide a description
  ...
}
leaf mac-addr {  // H/W provided.  Normally CF, but for some reason is
  mandatory true;   // promoted to CT (for a 'must' or 'when' expression?)
  ... // Please don't nitpick the validity of the 
example, I could 
} // construct a similar example using built-in 
certs or keys.
  }

Now say the client preconfigures:

  {
"name": "sd3"
"description": "uplink to closet-3",
"mac-addr": "00" // real address unknown, so a fake one used
  }

Now the card is inserted and "sd3" appears as:

  {
"name": "sd3"
"mac-addr": "1234567"
  }

The merge fails because the client's mac-addr doesn't match the real one?

Ideally the immutable nodes (other than the keys) would NOT have to appear
in , but they do because "mandatory true"?


> Also the notion
> of immutable data in candidate, which is rather a scratchpad to
> assemble bigger changes, seems odd to me.

I had a similar reaction but, if  can be validated, doesn't it follow
that the immutable nodes need to be copied into it as well?


> /js

K.


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

Re: [netmod] IPR Poll on draft-ietf-netmod-yang-semver-09

[Kent Watsen]

Bo and Jan (CC-ed),

Please reply-all to this email with your response to the original IPR call here:
https://mailarchive.ietf.org/arch/msg/netmod/xHDWFr5e2ykRBEseq-99PhRENGM/


Jason, thank you for highlighting this issue to the chairs.

Kent // as chair


> On Apr 24, 2023, at 5:48 PM, Jason Sterne (Nokia)  
> wrote:
> 
> Hello chairs and WG,
> 
> (as an author)
> 
> We've updated both drafts to refactor Acknowledgements vs Contributors:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-module-versioning/09/
> https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-semver/11/
> 
> The IPR call for Module Versioning is complete. It already included all 
> authors + contributors.
> 
> For YANG Semver, we're missing IPR declarations from the following people (we 
> didn't include them in the original IPR call):
>  Bo Wu
>  lana.w...@huawei.com
> 
>  Jan Lindblad
>  jlind...@cisco.com
> 
> Rgds,
> Jason
> 
>> -Original Message-
>> From: netmod  On Behalf Of Kent Watsen
>> Sent: Monday, March 13, 2023 7:35 PM
>> To: netmod@ietf.org
>> Cc: Rob Wilton (rwilton) 
>> Subject: Re: [netmod] IPR Poll on draft-ietf-netmod-yang-semver-09
>> 
>> 
>> CAUTION: This is an external email. Please be very careful when clicking 
>> links or
>> opening attachments. See http://nok.it/ext for additional information.
>> 
>> 
>> 
>> Authors/All,
>> 
>> One of the authors pointed out that the list of contributors was incomplete, 
>> and
>> specifically didn't include all listed in the paragraph of the contributors 
>> section.
>> We had mistakenly read this paragraph as Acknowledgments versus
>> Contributors.  It does appear that some of those listed may be Contributors, 
>> i.e.,
>> materially contributed to the technical solution or the text (excluding 
>> editorial
>> changes),  while others may in fact belong in an Acknowledgement section.
>> Given this, we'd like to ask the authors to refactor the Contributors 
>> section into
>> separate Acknowledgement and Contributor sections before moving forward on
>> this document.  Once we have the new version, we can then judge if there are
>> any missing IPR statements.
>> 
>> Thank you,
>> 
>> Kent and Lou
>> 
>> 
>>> On Jan 16, 2023, at 5:59 PM, Kent Watsen  wrote:
>>> 
>>> [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 WGLC 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 and Lou
>>> 
>>> 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 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 mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Comments on draft-ma-netmod-immutable-flag-06

[Kent Watsen]

Hi Qiufang,

> 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".

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.


> 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.

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. 



> 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 way to validate 
it, and hence the server would, presumably, allow the update to .  
When the card is later installed, the interface would appear in , 
and  if supported.  At that time the non-matching value would be 
discovered.  Presumably the system would 1) ignore the non-matching config from 
, 2) send an alert that  is invalid, and 3) force the next 
commit to  to correct the non-matching values.

Is this what you are focusing on?


> 3) The "immutable" metadata annotation (not the YANG extension) designates, 
> at the instance-level, config=true nodes that, when present in 
> , are system-defined and hence immutable.The 
> metadata annotation is only needed to support config=true YANG lists that can 
> contain a mix of client- and system- defined entries.
> There is no such a case like a client creates several instances some of which 
> are immutable while others are mutable. Generally I agree that “The metadata 
> annotation is only needed to support config=true YANG lists that can contain 

Re: [netmod] Comments on draft-ma-netmod-immutable-flag-06

[Kent Watsen]

I've just re-read the draft and this thread and have comments.

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").

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 .

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.  

3) The "immutable" metadata annotation (not the YANG extension) designates, at 
the instance-level, config=true nodes that, when present in 
, are system-defined and hence immutable.The 
metadata annotation is only needed to support config=true YANG lists that can 
contain a mix of client- and system- defined entries.

4) The definition for "immutable" flag means is identical whether it is 
specified via the YANG extension or the metadata annotation.   Corollary: the 
"immutable" flag can only be used on data-nodes (e.g., not on "choice", "case", 
or "grouping").



A couple more musings:

1) I wonder if the "immutable" should be a boolean that is "false" by default, 
but can be explicitly set to "false" if a descendent of a "immutable=true" 
node.  That is, to let immutability be recursive but toggle-able.

2) I wonder is *what* the "immutable" flag means should be defined per 
data-type.  For instance:

When a "leaf" node is immutable:

  - its value cannot change.

When a "leaf-list" node is immutable:

 - its value cannot change.

 - If specified at the schema-level, "ordered-by user"
   is invalid, because reordering changes the value.

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.

  - 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.

  - 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.

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.

Thoughts?

Kent // contributor




> On Apr 17, 2023, at 5:29 AM, maqiufang (A)  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 h

[netmod] WGLC on node-tags-09

[Kent Watsen]

This email begins a two-week WGLC on:

https://datatracker.ietf.org/doc/html/draft-ietf-netmod-node-tags-09

Please take time to review this draft and post comments by May 2nd.  Favorable 
comments are especially welcomed.  

This draft went through a WGLC a year ago.  The authors addressed the comments 
received and have been were waiting for feedback.   In essence, this draft is 
presumed to reflect WG consensus and thusly, if no objection is received, the 
draft will move to the next step in the publication process.

Ref: https://mailarchive.ietf.org/arch/msg/netmod/n2P9yohA-X-xSIt6FlMr4wOqmuI/

Kent  // co-chair 

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

Re: [netmod] Request for WG adoption, draft-haas-netmod-unknown-bits-01.txt

[Kent Watsen]

> I agree.  If we end up with "yang-next" as I've heard it called, this would 
> be a useful case to resolve.
> 
> If we ended up with such a thing, it'd be nice to simply deprecate the 
> "unknown" leaves, upgrade the type from "bits" to "bits-with-unknown" (or 
> similar) and work from there.
> 

Hi Jeff, 

Can you add to this issue?

https://github.com/netmod-wg/yang-next/issues/90

K.

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

Re: [netmod] I-D Action: draft-ietf-netmod-node-tags-09.txt

[Kent Watsen]

I received a warning today that this draft will expire in 6 days.
IIRC, the authors are waiting for a response from Juergen (see below).
Juergen, if you can respond, that would be best.
Otherwise, I'll start another round of WGLC and IPR calls tomorrow.

Kent // chair


> On Oct 17, 2022, at 9:14 PM, Qin Wu  
> wrote:
> 
> Hi, Jurgen :
> Would you like to check the latest version and see whether your comments have 
> been addressed,
> Thank in advance.
> 
> -Qin
> -邮件原件-
> 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Qin Wu
> 发送时间: 2022年10月13日 21:09
> 收件人: netmod@ietf.org
> 主题: Re: [netmod] I-D Action: draft-ietf-netmod-node-tags-09.txt
> 
> Hi, All:
> v-09 is submitted, the main changes are editorial changes and include:
>   *  Clarification on the relation with metadata annotation in section 1.
>   *  Clarification on how masked-tag is used in section 5.3, i.e., use normal 
>  operation to add user configured tag into  and use mask-tag 
> to remove both
>  system tag and user configured tag from .
>   *  Other editorial changes.
> The diff is:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-node-tags-09
> Further comments and suggestions are welcome!
> 
> -Qin
> -邮件原件-
> 发件人: I-D-Announce [mailto:i-d-announce-boun...@ietf.org] 代表 
> internet-dra...@ietf.org
> 发送时间: 2022年10月13日 20:45
> 收件人: i-d-annou...@ietf.org
> 抄送: netmod@ietf.org
> 主题: I-D Action: draft-ietf-netmod-node-tags-09.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Network Modeling WG of the IETF.
> 
>Title   : Node Tags in YANG Modules
>Authors : Qin Wu
>  Benoit Claise
>  Peng Liu
>  Zongpeng Du
>  Mohamed Boucadair
>  Filename: draft-ietf-netmod-node-tags-09.txt
>  Pages   : 32
>  Date: 2022-10-13
> 
> Abstract:
>   This document defines a method to tag nodes that are associated with
>   operation and management data in YANG modules.  This method for
>   tagging YANG nodes is meant to be used for classifying either data
>   nodes or instances of data nodes from different YANG modules and
>   identifying their characteristic data.  Tags may be registered as
>   well as assigned during the definition of the module, assigned by
>   implementations, or dynamically defined and set by users.
> 
>   This document also provides guidance to future YANG data model
>   writers; as such, this document updates RFC 8407.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-node-tags/
> 
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-node-tags-09
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-node-tags-09
> 
> 
> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
> 
> 
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> ___
> 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 mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Comments on draft-ma-netmod-immutable-flag-06

[Kent Watsen]

t; still provide the necessary visibility and awareness to the client, whilst 
> avoiding additional orchestration complexity for clients.  After all, there 
> are many properties in the network configuration models standardized in the 
> IETF (and OpenConfig) that are similarly service impacting if changed, that 
> don’t seemingly require any protection.
>  
> It also feels that we are on the path of fracturing the definition of the 
> NETCONF/YANG management protocols, which is somewhat like how OpenConfig 
> decided to interpret the pattern statement regex language differently (which 
> they have now backtracked on) or their recent statement that servers are not 
> generally expected/required to validate leaf ref constraints in the running 
> configuration.  Each of these little cuts, whilst innocent and good 
> intentioned on their own, risk gradually devaluing the common standards by 
> creating many incompatible subvariants of the language and protocols.
>  
> Hence, this is why I think Jan’s approach of looking at the individual 
> problems that are being solved and having a discussion as to what is the best 
> way of solving these individual problems may result in a better overall 
> solution.  Specifically, is there a compromise that can meet 3GPP’s and ITU’s 
> goals without eroding the underlying NETCONF/YANG architecture?
>  
> Regards,
> Rob
>  
> // Still no hats.
>  
> From: netmod mailto:netmod-boun...@ietf.org>> On 
> Behalf Of Kent Watsen
> Sent: 03 April 2023 22:23
> To: Rob Wilton (rwilton)  <mailto:rwilton=40cisco@dmarc.ietf.org>>
> Cc: Jan Lindblad (jlindbla)  <mailto:jlindbla=40cisco@dmarc.ietf.org>>; netmod@ietf.org 
> <mailto:netmod@ietf.org>
> Subject: Re: [netmod] Comments on draft-ma-netmod-immutable-flag-06
>  
> Hi Rob,
> 
> 
> - In terms of properties that cannot be changed once written, I would rather 
> see this issue framed more in the direction of it just being extra 
> documentation written in a machine-readable way.  Specifically, using the 
> annotation to give an indication that servers MAY reject requests to 
> create/delete, or change, the configuration, but not requiring that they do 
> so.  I.e., at the data model level, I don't think that we should preclude 
> servers being able to handle this is in a more client friendly way (e.g., by 
> breaking a single client transaction up into multiple internal transactional 
> changes where needed).
>  
> I agree that the document does not make it clear enough, but this is already 
> the case.   As I said at the end of this document's presentation on Friday's 
> NETMOD, session, this document has no runtime-impact on servers (other than 
> them needing to return annotated YANG and/or metadata).  There is also no 
> runtime-impact on clients, as they as free to ignore all the annotations and 
> metadata.   All this document does is define a mechanism for servers to 
> describe the behavior they already implement.   The text in the document is 
> confusing because the normative statements make it sound like the server 
> needs to implement behavior to reject certain updates *because 
> annotations/metadata said so*, but actually it's the other way around, as the 
> server was already implemented to reject the changes.
>  
> 1st paragraph in the Introduction:
>  
> This document defines a way to formally document as a YANG extension or YANG 
> metadata an existing model handling behavior that is already allowed in YANG 
> and which has been used by multiple standard organizations and vendors. It is 
> the aim to create one single standard solution for documenting modification 
> restrictions on data declared as configuration, instead of the multiple 
> existing vendor and organization specific solutions. See Appendix B 
> <https://datatracker.ietf.org/doc/html/draft-ma-netmod-immutable-flag#Existing_implementations>
>  for existing implementations.¶ 
> <https://datatracker.ietf.org/doc/html/draft-ma-netmod-immutable-flag#section-1-1>
>  
>  
>  
> 
> 
> - For any immutable related metadata annotations, I think that this 
> additional metadata should only be returned to clients when explicit 
> requested via a separate RPC parameter, and I think that the draft needs to 
> add text for protocol capabilities used to indicate whether this new option 
> is supported (e.g., along the lines of RFC 6243, with-defaults).
>  
> Somewhat agree (Principle of Least Astonishment), though it's neither 
> illegal, would cause client problems, or cause excessive network utilization 
> (unlike with-defaults).
>  
> K.

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

Re: [netmod] Comments on draft-ma-netmod-immutable-flag-06

[Kent Watsen]

Hi Rob,

> - In terms of properties that cannot be changed once written, I would rather 
> see this issue framed more in the direction of it just being extra 
> documentation written in a machine-readable way.  Specifically, using the 
> annotation to give an indication that servers MAY reject requests to 
> create/delete, or change, the configuration, but not requiring that they do 
> so.  I.e., at the data model level, I don't think that we should preclude 
> servers being able to handle this is in a more client friendly way (e.g., by 
> breaking a single client transaction up into multiple internal transactional 
> changes where needed).

I agree that the document does not make it clear enough, but this is already 
the case.   As I said at the end of this document's presentation on Friday's 
NETMOD, session, this document has no runtime-impact on servers (other than 
them needing to return annotated YANG and/or metadata).  There is also no 
runtime-impact on clients, as they as free to ignore all the annotations and 
metadata.   All this document does is define a mechanism for servers to 
describe the behavior they already implement.   The text in the document is 
confusing because the normative statements make it sound like the server needs 
to implement behavior to reject certain updates *because annotations/metadata 
said so*, but actually it's the other way around, as the server was already 
implemented to reject the changes.

1st paragraph in the Introduction:

This document defines a way to formally document as a YANG extension or YANG 
metadata an existing model handling behavior that is already allowed in YANG 
and which has been used by multiple standard organizations and vendors. It is 
the aim to create one single standard solution for documenting modification 
restrictions on data declared as configuration, instead of the multiple 
existing vendor and organization specific solutions. See Appendix B 

 for existing implementations.¶ 





> - For any immutable related metadata annotations, I think that this 
> additional metadata should only be returned to clients when explicit 
> requested via a separate RPC parameter, and I think that the draft needs to 
> add text for protocol capabilities used to indicate whether this new option 
> is supported (e.g., along the lines of RFC 6243, with-defaults).

Somewhat agree (Principle of Least Astonishment), though it's neither illegal, 
would cause client problems, or cause excessive network utilization (unlike 
with-defaults).

K.



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

Re: [netmod] system configuration/datastore and the keystore/truststore drafts

[Kent Watsen]

> The fact that a draft has been adopted by a WG does not mean it will
> get finished and published as a standard. I have seen documents dying,
> I have seen entire WGs dying.

Sure, okay, and funny.


> So do the client/server/crypto/... configuration modules need any
> special handling by the server or not? If the answer is no, we can
> close this specific discussion thread.

Yes, as described in the current drafts.


> /js

K.


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

Re: [netmod] system configuration/datastore and the keystore/truststore drafts

[Kent Watsen]

> Perhaps Kent can help us by summarizing why he believes copying is
> needed, i.e., why lazy references by name do not work for credentials
> stored in TPMs.

The truststore and keystore use-case entails the following concepts from
the system-config draft:

  - Inactive Until Referenced

https://datatracker.ietf.org/doc/html/draft-ietf-netmod-system-config-01#name-inactive-until-referenced

  - Configuring Descendant Nodes of a System-defined Node (keystore draft only)

https://datatracker.ietf.org/doc/html/draft-ietf-netmod-system-config-01#name-configuring-descendant-node

There is no inherent desire to copy these system-defined nodes into
 (nor in their entirety).  The *published* version of those two
drafts only say to do so now because 1) that text was written before
system-config's originating I-D existed, 2) to ensure, e.g., "mandatory
true" nodes in  would exist, and 3) because that text hasn't
been updated since the system-config draft was adopted.

Rob raised a very good point in his recent AD-review that these
sections should not say that system-defined nodes have to be
copied into , so as to leave the door open for lazy
referenced to the  defined nodes.

Additionally, these sections define behaviors & mechanics about the
immutability nature of the data, when really such should be defined
only in the system-config and immutable-flag drafts.  That said, I 
don't want to introduce a normative reference to those drafts that
would result in a MISREF.

Kent


> Concerning the larger discussion about validation of running vs
> validation of intended: During NMDA developed, it became clear that
> some not quite relevant NETCONF implementations do actually validate
> intended when you asked them to validate running. And what happens
> between running and intended is not covered by any standards as of
> today. Is this bad? In a way yes and no. It is bad because some
> vcendors may read this as an invitation to do things that really mess
> up a client's expectations but it is perhaps also good since the
> distinction acknowledges reality.
> 
> The discussion around system config is old (much older than the I-D)
> and this is a grey area and I assume that every bigger server has some
> places somewhere where it "cheats" a bit to deal with the problem.
> There is the option to just leave it like that, i.e., to trust that
> vendors will understand to not go over board with magic system config
> "cheats" or to work out solutions that may introduce another datastore
> or solutions to tag config in running that is not really under the
> control of a client (immutable flags play in here and perhaps the WG
> needs to discuss whether really both a system datastore and immutable
> flags are needed - at the end immutable config is coming from
> somewhere).
> 
> The only lazy binding mechanism we have is to refer to resources by
> name. If the name resolution does not work out, the relevant config is
> not applied. This kind of works if data models are designed for it but
> this adds complexity to the modeling process.
> 
> /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

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

Re: [netmod] system configuration/datastore and the keystore/truststore drafts

[Kent Watsen]

Hi Andy,

> No customer would ever let us take away this tenet, no matter what RFC comes 
> out.

What tenet?  That  is valid or that the representation returned to 
clients is valid?

No one is talking about  (on the server) not being valid, the only 
nuance is
in *how* the server validates , which is being discussed.

RFC 8342 shows that some transformations (like template expansions and removing
inactive config) must occur *prior* to YANG-validation.  Wouldn't it be nice to 
implement
 such features someday?

Regarding "no customers", in case it helps, Juniper devices validate  
vis-a-vis
validating  (after template expansion and removing inactive config), 
and their
customers are happy.


> There are corner cases where a server is executing with a  datastore 
> that does
> not pass all YANG constraints and all description-stmt semantics.
> 
> For example, there are data models with top-level mandatory NP-containers.
> Loading the empty YANG module causes the datastore validation to fail.

Modules should not have mandatory nodes when first set as "implemented".  Such 
is bad API design IMO.  This should be captured in RFC 8407...and, ideally, be
tested for during publication process.


> Our server has a mode where it will start with a bad  datastore
> and allow an operator to fix the config. No edit-config to running or commit 
> will
> succeed unless all validation passes (that is specified in 6241).

Yep, my server does the same.


> There are lots of complex implementation-specific ways to get the server 
> datastores loaded at runtime.
> Code runs and then  is setup somehow.  The idea that  must 
> be totally empty
> unless a client has set the data seems to be an NMDA thing. 
> IMO it is not a good idea to make NMDA even more complicated to handle minor 
> corner-cases.

AFAICT , nothing changes to the logic you described.  Also, these are not minor
corner-cases.


> Andy

K. // contributor


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

Re: [netmod] system configuration/datastore and the keystore/truststore drafts

[Kent Watsen]

This is my reading as well.  Despite being published 5 years ago, the pushback 
comes because there’s no *programmatic* way to prevent client breakage.  There 
is a need to have a mechanism, like the “critical” flag (1), to signal when new 
behavior is required. 

 (1) https://github.com/netmod-wg/yang-next/issues/70

K. 

> On Mar 26, 2023, at 1:24 PM, Jürgen Schönwälder 
>  wrote:
> 
> 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 management system may be a bit
> wishful thinking.
> 
> /js
> 
>> On Sun, Mar 26, 2023 at 04:28:46PM +, Rob Wilton (rwilton) wrote:
>> Hi,
>> 
>> I'm in the process of AD reviewing Kent's keystore and truststore drafts in 
>> NETCONF.
>> 
>> In both of these drafts, there is a desire to be able to use keys or 
>> certificates that are managed on the device, potentially as part of a TPM, 
>> and yet be able to reference those keys/certificates from the device 
>> configuration.  There is also some reference to how this configuration may 
>> work with the system datastore.
>> 
>> https://www.ietf.org/archive/id/draft-ietf-netconf-keystore-27.html#name-support-for-built-in-keys
>>  gives an example.
>> 
>> Looking at the current version of the system datastore, 
>> https://datatracker.ietf.org/doc/draft-ietf-netmod-system-config/01/, my 
>> understanding is that this draft reinforces the requirement that  
>> is always valid. Hence any data nodes in the  datastore, that are 
>> referenced from the configuration in the  datastore, MUST also be 
>> copied into , so that it validates.  Unreferenced descendant 
>> configuration (that won't stop  from validating) can be left in 
>> system, which is then merged with , and validated as part of 
>> .
>> 
>> This is the approach that the keystore/truststore explains.  However, there 
>> is separately the issue that the build in keys and certificates may be 
>> updated via an out of band process, such that the current keys/certificates 
>> are stored on the device, and a stale copy of the keys/certificates ends up 
>> in the running configuration.  The keystore/truststore draft mitigates this 
>> by stating that if the key/certificate config differs between  and 
>> , then the values in  are ignored and the values in 
>>  take priority.  However, my understanding is that this behaviour is 
>> the reverse of what we normally expect when merging configuration in the 
>>  and  datastores, where configuration in  
>> overrides configuration in .  Ultimately, I think that this means 
>> that we would need special handling for key/truststore configuration rather 
>> than just following the normal behaviour.
>> 
>> Hence, I wonder whether we are making this more complex than necessary.  
>> Rather than requiring that  is always independently valid from 
>> , then would it not be simpler to allow  to have invalid 
>> configuration but always require that whenever  is changed then 
>>  is updated and must always be valid.  This would allow  
>> to reference configuration in  without requiring it to be copied 
>> into .
>> 
>> I still think that we should allow the configuration to be copied into 
>>  for clients that also want  to be validate independently 
>> from , but otherwise, the requirement of copying keys are 
>> certificates into running doesn't seem ideal.
>> 
>> Any thoughts?
>> 
>> Regards,
>> Rob
>> 
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
> 
> -- 
> Jürgen Schönwälder  Constructor University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
> 
> ___
> 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] NETMOD Agenda Updated

[Kent Watsen]

The NETMOD agenda has been updated:

https://datatracker.ietf.org/meeting/116/session/netmod

And produced in full below for convenience.

Kent (and Jason for putting it together!)



# Agenda/Materials for the NETMOD 116 WG Session

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

## Session:

Friday 2023-03-31 09:30-11:30 JST (00:30 - 02:30 UTC)
Room: 4FG412-G413


## 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/ietf116/?group=netmod=netmod=1
Onsite tool: 
https://meetings.conf.meetecho.com/onsite116/?group=netmod=netmod=1
Audio Only: https://mp3.conf.meetecho.com/ietf116/netmod/1.m3u
Zulip: https://zulip.ietf.org/#narrow/stream/netmod

## Available During and After Session:

Notes:  https://notes.ietf.org/notes-ietf-116-netmod#both
Slides: https://datatracker.ietf.org/meeting/116/session/netmod
Drafts (TGZ): https://datatracker.ietf.org/meeting/116/agenda/netmod-drafts.tgz
Drafts (PDF): https://datatracker.ietf.org/meeting/116/agenda/netmod-drafts.pdf
Datatracker: https://datatracker.ietf.org/group/netmod/about/
ICS: https://datatracker.ietf.org/meeting/116/session/30184.ics

## Available After Session:

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

# 1) Session Intro & WG Status
### Presenters: Chairs (10 min)


# Chartered items:


## 2) Common Interface Extension YANG Data Models, Sub-interface VLAN YANG Data 
Models (10 min)
### Presenter: Scott Mansfield
### Draft: https://datatracker.ietf.org/doc/draft-ietf-netmod-intf-ext-yang-11
### Draft: 
https://datatracker.ietf.org/doc/draft-ietf-netmod-sub-intf-vlan-model-08


## 3) YANG Versioning Update and Discussion (30 min)
### Presenters: Tom Hill and Joe Clarke
### Draft: 
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-module-versioning-08
### Draft: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-semver-10
### Draft: 
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-schema-comparison-02


## 4) System Config (10 min)
### Presenter: Qiufang Ma
### Draft: https://datatracker.ietf.org/doc/draft-ietf-netmod-system-config-01


# Non-Chartered items:


## 5) Immutable Flag (10 min)
### Presenter: Qiufang Ma
### Draft: https://datatracker.ietf.org/doc/draft-ma-netmod-immutable-flag-05


## 6) Representing Unknown YANG bits in Operational State (10 min)
### Presenter: Jeff Haas
### Draft: https://datatracker.ietf.org/doc/draft-haas-netmod-unknown-bits-01


## 7) YANG lessons from BGP YANG work (10 min)
### Presenter: Jeff Haas and Mahesh Jethanandani
### No associated draft


## 8) Security Considerations Template for YANG Module Documents (10 min)
### Presenter: Kathleen Moriarty
### Draft: https://datatracker.ietf.org/doc/draft-moriarty-yangsecuritytext-02


## 9) Incident Management for Network Services (10 min)
### Presenter: Chong Feng
### Draft: 
https://datatracker.ietf.org/doc/draft-feng-opsawg-incident-management-00


# Unscheduled time (10 min)

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

Re: [netmod] Changing an identity base

[Kent Watsen]

Italio,

Can you add an item for this issue here:

https://github.com/netmod-wg/yang-next/issues

Including a pointer to this thread in the mail archive would be most excellent.

K.


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

Re: [netmod] IPR Poll on draft-ietf-netmod-yang-semver-09

[Kent Watsen]

Authors/All,

One of the authors pointed out that the list of contributors was incomplete, 
and specifically didn't include all listed in the paragraph of the contributors 
section.  We had mistakenly read this paragraph as Acknowledgments versus 
Contributors.  It does appear that some of those listed may be Contributors, 
i.e., materially contributed to the technical solution or the text (excluding 
editorial changes),  while others may in fact belong in an Acknowledgement 
section.  Given this, we'd like to ask the authors to refactor the Contributors 
section into separate Acknowledgement and Contributor sections before moving 
forward on this document.  Once we have the new version, we can then judge if 
there are any missing IPR statements.

Thank you,

Kent and Lou


> On Jan 16, 2023, at 5:59 PM, Kent Watsen  wrote:
> 
> [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 WGLC 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 and Lou
> 
> 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 mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WGLC on draft-ietf-netmod-syslog-model-28

[Kent Watsen]

NETMOD WG,

We started a WGLC on the Syslog model ~7 weeks ago, to which Reshad voiced a 
concern which was addressed in last week's update, per Joe's email here: 
https://mailarchive.ietf.org/arch/msg/netmod/uML_a4oCZU7FdH95A6LENmCd1VI/.

Given that this draft has been a work-in-progress for some time, with numerous 
reviews, I (as Shepherd and co-Chair) am thinking to progress it now, even 
though the most recent WGLC solicited only one response, being Reshad's.

Are there any objections to this proposal?

Thanks,
Kent


> On Jan 13, 2023, at 8:04 AM, Kent Watsen  wrote:
> 
> Dear NETMOD WG,
> 
> This message begins a two-week WGLC for draft-ietf-netmod-syslog-model-28 
> ending on Friday, January 27th.  Here is a direct link to the HTML version of 
> the draft:
> 
>   https://datatracker.ietf.org/doc/html/draft-ietf-netmod-syslog-model-28
> 
> 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

Re: [netmod] Strictness of Base64classic in RFC 7950/7951

[Kent Watsen]

> On Feb 28, 2023, at 2:25 AM, Ladislav Lhotka  wrote:
> 
> Was it this thread?
> 
> https://mailarchive.ietf.org/arch/msg/netconf/ra_KfLp2HPUZajLIYQ_MBLf-sfw/
> 

No, it didn't regard the sztp-csr draft's IESG LC.

K.


> Lada
> 

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

Re: [netmod] Strictness of Base64classic in RFC 7950/7951

[Kent Watsen]

>> This was discussed in late 2021.   I switched from:
>> 
>>  base64encodedvalue==
>> 
>> to:
>> 
>>  BASE64VALUE=
>> 
>> in all my drafts then.  Which document are you looking at?
> 
> RFC 8366 (from 2018).

That document was published before the issue was discovered.  File an Errata 
for it?


> Do you have a pointer to the discussion?

Not at hand.


> Was there, at the same time, any conclusion with respect to my question 
> (strict or soup)?

No, only that it was wrong and should be fixed.  ;)


K.

> Grüße, Carsten


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

Re: [netmod] Strictness of Base64classic in RFC 7950/7951

[Kent Watsen]

This was discussed in late 2021.   I switched from:

base64encodedvalue==

to:

BASE64VALUE=

in all my drafts then.  Which document are you looking at?

Kent




> On Feb 27, 2023, at 9:24 AM, Carsten Bormann  wrote:
> 
> On 2023-02-27, at 15:04, Ladislav Lhotka  wrote:
>> 
>> Unlike non-alphabet characters, RFC 4648 doesn't say that such a character 
>> in encoded data is invalid.
> 
> Not explicitly, but it also gives you an algorithm for arriving at the 
> encoded value that never can result in the characters that I consider invalid 
> [1]:
> 
>   When fewer than 24 input
>   bits are available in an input group, bits with value zero are added
>   (on the right) to form an integral number of 6-bit groups.  
> 
> Note the explicit “with value zero”.
> 
>> FWIW, my implementation (Yangson) uses Python standard library base64 that 
>> accepts it without complaints even with validation turned on:
>> 
> import base64
> base64.b64decode("ue==", validate=True)
>> b'\xb9'
>> 
>> So I assume the authors consider this input valid, and I saw no reason to be 
>> concerned about it.
> 
> Thank you — that was the kind of input I was looking for.
> 
> Now what do other implementations do?
> 
> Grüße, Carsten
> 
> [1]: https://www.rfc-editor.org/rfc/rfc4648#page-6
> 
> And the missing [2] from my previous message:
> [2]: 
> https://www.ietf.org/archive/id/draft-bormann-cbor-cddl-more-control-00.html#name-byte-strings-base16-hex-bas
> ___
> 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] [netconf] Security text for I-D with YANG modules

[Kent Watsen]

[-netconf, +netmod]

True, that claim seems overstated and one would think that such should be in 
NETMOD.

Searching OPSAWG, I don't see it.  Can you provide a link?

K.



> On Feb 20, 2023, at 12:27 PM, tom petch  wrote:
> 
> I see an I-D has appeared recently with the title
>  Security Considerations Template for YANG Module Documents
> 
> It says
> " The text has been developed and
>   refined over many years on an Operations Area working group mailing
>  list"
> 
> Oh dear,   my memory must be going - I can recall seeing nothing about this 
> on NETCONF or NETMOD WG lists which I would regard as the epicentre of things 
> YANG.  If my memory is not false, then it seems somewhat discourteous to me, 
> but then this is security and my exposure to WG such as TLS long ago stopped 
> me from expecting consideration of others from them:-)
> 
> Tom Petch
> ___
> netconf mailing list
> netc...@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

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

[netmod] Publication has been requested for draft-ietf-netmod-rfc6991-bis-15

[Kent Watsen via Datatracker]

Kent Watsen has requested publication of draft-ietf-netmod-rfc6991-bis-15 as 
Proposed Standard on behalf of the NETMOD working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6991-bis/


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

Re: [netmod] IPR Poll on draft-ietf-netmod-yang-semver-09

[Kent Watsen]

Thank you all!   Everyone replied:

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

We'll move to WGLC as soon as the IPR call on "yang-module-versioning" 
completes.

Kent


> On Jan 16, 2023, at 5:59 PM, Kent Watsen  wrote:
> 
> [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 WGLC 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 and Lou
> 
> 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 mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Editorial Errata Reported] RFC8519 (7313)

[Kent Watsen]

Rob,

Errata should be accepted.

Kent


> On Jan 18, 2023, at 10:02 AM, RFC Errata System  
> wrote:
> 
> The following errata report has been submitted for RFC8519,
> "YANG Data Model for Network Access Control Lists (ACLs)".
> 
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7313
> 
> --
> Type: Editorial
> Reported by: Mohamed Boucadair 
> 
> Section: A.1
> 
> Original Text
> -
>   The following figure is the tree diagram of example-newco-acl.  In
>   this example, /ietf-acl:acls/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/
>   ietf-acl:matches are augmented with two new choices: protocol-
>   payload-choice and metadata.  The protocol-payload-choice uses a
>   grouping with an enumeration of all supported protocol values.
>   Metadata matches apply to fields associated with the packet, that are
>   not in the packet header, such as overall packet length.  In another
>   example, /ietf-acl:acls/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/
>   ietf-acl:actions are augmented with a new choice of actions.
> 
> Corrected Text
> --
>   The following figure is the tree diagram of example-newco-acl.  In
>   this example, /acl:acls/acl:acl/acl:aces/acl:ace/acl:matches
>   are augmented with two new choices: protocol-payload-choice and
>   metadata.  The protocol-payload-choice uses a
>   grouping with an enumeration of all supported protocol values.
>   Metadata matches apply to fields associated with the packet, that are
>   not in the packet header, such as overall packet length.  In another
>   example, /acl:acls/acl:acl/acl:aces/acl:ace/acl:actions 
>   are augmented with a new choice of actions.
> 
> Notes
> -
> The prefix is "acl" not "ietf-acl"
> 
> ==
> module ietf-access-control-list {
>  yang-version 1.1;
>  namespace "urn:ietf:params:xml:ns:yang:ietf-access-control-list";
>  prefix acl;
>  ...
> ==
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --
> RFC8519 (draft-ietf-netmod-acl-model-21)
> --
> Title   : YANG Data Model for Network Access Control Lists (ACLs)
> Publication Date: March 2019
> Author(s)   : M. Jethanandani, S. Agarwal, L. Huang, D. Blair
> Category: PROPOSED STANDARD
> Source  : Network Modeling
> Area: Operations and Management
> Stream  : IETF
> Verifying Party : IESG
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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