Re: [netmod] Draft IETF 119 NETMOD Agenda posted

[maqiufang (A)]

Hi, Jan, all

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

Kent,

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

 The consensus in the room was a new "Option 4" - i.e., this
 document doesn't say anything at all about the validity of
 .  That is, fully rely on existing 7950 and 8342
 statements.  This leaves it up to interpretation.

Has something changed since then?

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

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

Best Regards,
/jan

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

Qiufang,

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

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

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

Best Regards,
/jan


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

Hi, chairs,

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

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

Best Regards,
Qiufang
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Lou Berger
Sent: Friday, March 8, 2024 9:44 PM
To: NETMOD WG mailto:netmod@ietf.org>>
Cc: netmod-cha...@ietf.org
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 

[netmod] structured metadata for schema nodes using YANG extensions

[Jason Sterne (Nokia)]

Hi all,

I'm looking for information about doing more complex YANG extensions that the 
basic  type, e.g.:
oc-ext:openconfig-version "2.5.0";

The node-tags approach doesn't fit what I'm trying to do (tags can't have 
values).

RFC7950 says the following:
   The substatements of an
   extension are defined by the "extension" statement, using some
   mechanism outside the scope of this specification.  Syntactically,
   the substatements MUST be YANG statements, including extensions
   defined using "extension" statements.

Let me start with a simple example and build on it. Say I want to associate a 
color with any schema node. That's easy:

extension color {
argument "color";
description "Takes a value of red, green or blue";
}

leaf foo {
myext:color "red";
}

But what if I want a more complex structure for my color metadata like this?  
(a leaf-list and leaf inside a container)

leaf foo {
myext:chroma-metadata {
myext:colors "red green";
myext:saturation "45";
}

>From what I can tell, I'd have to define it like this:

extension chroma-metadata {
}
extension colors {
argument "color-list";
description "sub-statement of chroma-metadata. Space separated list of 
colors red, green and blue.";
}
extension saturation {
argument "saturation-level";
description "sub-statement of chroma-metadata";
}

Or if I wanted a list like this?

myext:chroma-metadata {
myext:color "red" {
myext:saturation "45";
}
myext:color "green" {
myext:saturation "23";
}
}

I don't think there is any formal way to do it, but could I say that the 
structure of the chroma-metadata follows a grouping I define?

grouping cm-struct {
list color {
leaf saturation { ... }
}
}

Could another option be to just define the top level extension chroma-metadata 
with a single argument, and then describe that the argument itself is a 
json-ietf blob of instance data that conforms to YANG grouping xyz?

Jason (he/him)

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

Re: [netmod] IETF#119 I-D Status: draft-ietf-netmod-rfc8407bis

[Mahesh Jethanandani]

Hi Med,

Thanks for driving this effort on updating RFC 8407. 

One additional change coming your way, is to address the question of how IANA 
is supposed to handle updates to IANA YANG modules. The YANG doctors are 
currently debating those changes. Once agreed, we will bring that discussion 
here, and will need to update rfc8407bis to provide guidance to authors who 
update an IANA module. Stay tuned.

Cheers.

> On Mar 12, 2024, at 5:00 AM, mohamed.boucad...@orange.com wrote:
> 
> Hi all, 
>  
> A candidate -10 is ready to address 3 comments from Jan:
> Long trees
> Updated security template
> Minor tweaks to Section 3.8
> The changes circulated on the list can be seen here: Compare Editor's Copy to 
> Datatracker 
> 
> Jan raised two other comments (short/uniqueness of prefixes + how to handle 
> “not set”) but no changes were made per the feedback received on the list.  
> Next steps:
> Submit -10 right after IETF#119
> WGLC
>  
> 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 detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
> ___
> netmod mailing list
> netmod@ietf.org 
> https://www.ietf.org/mailman/listinfo/netmod 
> 

Mahesh Jethanandani
mjethanand...@gmail.com






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

Re: [netmod] Draft IETF 119 NETMOD Agenda posted

[Andy Bierman]

On Tue, Mar 12, 2024 at 9:15 AM 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.
>
>

The WG does not think NMDA is too complicated or too difficult for clients
to use. I disagree.
Adding more datastores and interactions between datastores will make NMDA
even worse.
Retrieval of multiple datastores so they can be compared for transient
differences is a very complex
way to convey this state information to the client.

NMDA is too server-centric already. Maximum flexibility for the server
developer means
minimum consistency for the client developer.


Best Regards,
> /jan
>

Andy


>
> On 12 Mar 2024, at 03:44, maqiufang (A)  40huawei@dmarc.ietf.org> wrote:
>
> Hi, chairs,
>
> For system-config draft (
> https://datatracker.ietf.org/doc/draft-ietf-netmod-system-config/), the
> authors have submitted a new version to reflect the outcome of the interim,
> the main updates are following:
> 1.  Address the "origin" issue
> a.   The current document explicitly states that system configuration
> copied from  into  have its origin value being reported as
> "intended" and update the examples accordingly
> b.  Also, update the definition of "intended" origin identity in 8342
> to allow a subset of configuration in  to use "system" as origin
> value
> c.   The current document states data migration is out-of-scope
> except that gives a couple of implementation examples in section 4.2
> (please feel free to propose text if you have better suggestion)
> 2.  validity of  alone
> a.   The current document is silent on this point. Related statements
> which requires referenced system nodes must be copied into  are
> removed.
> 3.  Other updates
> a.   Usage examples refinement, e.g., fix validation errors, remove
> redundancy for conciseness
>
> There is currently no open issues, thus the authors believe this draft is
> ready for WGLC, but this might be worth a broad review on the mailing list.
>
> Best Regards,
> Qiufang
> *From:* netmod [mailto:netmod-boun...@ietf.org] *On Behalf Of *Lou Berger
> *Sent:* Friday, March 8, 2024 9:44 PM
> *To:* NETMOD WG 
> *Cc:* netmod-cha...@ietf.org
> *Subject:* Re: [netmod] Draft IETF 119 NETMOD Agenda posted
>
>
> **IMPORTANT**
>
> Authors of WG documents,
>
> If your document has not yet been submitted to the IESG for publication
> *and* your draft is not on the agenda, please either:
> (a) request to present status or
> (b) send email to the list summarizing status by end of day (any TZ)
> Friday, March 15.
>
> In either case, please include recent changes, open issues, plan to
> resolve open issues/complete the document.
>
> Thank you!
>
> Lou (and Kent)
> On 3/7/2024 3:53 PM, Jason Sterne (Nokia) wrote:
>
> Hello NETMOD WG,
>
> A draft NETMOD agenda for IETF 119 has been published. Please review and
> let the chairs know if any changes are needed or additional topics should
> be covered.
>
> The agenda is pasted below, but here's the link to the always-current
> version:
> https://datatracker.ietf.org/meeting/119/materials/agenda-119-netmod
>
> Presenters: please provide slides to netmod-cha...@ietf.org no later than
> Sunday March 17 (any time zone).
>
> Thanks,
> Jason (+ chairs Kent and Lou)
>
> Draft Agenda for the NETMOD 119 WG Session
>
> https://datatracker.ietf.org/meeting/119/materials/agenda-119-netmod
> https://datatracker.ietf.org/meeting/119/session/netmod
> Session:
>
> Thursday, March 21, 2024
> 13:00-15:00 Brisbane (Australia - Eastern Time)
> 03:00-05:00 UTC
> 23:00-01:00 Wednesday March 20 America - Eastern Time
>
> https://www.timeanddate.com/worldclock/converter.html?iso=20240321T03=47
>
> Room: M2 https://datatracker.ietf.org/meeting/119/floor-plan?room=m2
> WG Chairs:
>
> Lou Berger (lberger at labs dot net)
> Kent Watsen (kent plus ietf at watsen dot net)
> WG Secretary
>
> Jason Sterne (jason dot sterne at nokia dot com)
> Available During Session:
>
> MeetEcho: https://meetings.conf.meetecho.com/ietf119/?session=31987
> Onsite tool: https://meetings.conf.meetecho.com/onsite119/?session=31987
> Audio Only: https://mp3.conf.meetecho.com/ietf119/31987.m3u
> Available During and After Session:
>
> Notes: https://notes.ietf.org/notes-ietf-119-netmod?both
> Slides: https://datatracker.ietf.org/meeting/119/session/netmod
> Zulip (chat):
> 

Re: [netmod] Draft IETF 119 NETMOD Agenda posted

[Jan Lindblad (jlindbla)]

Kent,

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

 The consensus in the room was a new "Option 4" - i.e., this
 document doesn't say anything at all about the validity of
 .  That is, fully rely on existing 7950 and 8342
 statements.  This leaves it up to interpretation.

Has something changed since then?

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

Thanks for keeping me honest :-) Nothing has changed, and if everyone agrees 
that 7950 and 8342 language prevail (i.e. running always valid as well as 
intended always valid), I'm probably ok. I wasn't sure that was the case? But 
if we all agree with this, maybe stating just that wouldn't be a bad thing? 
Just so that this is perfectly clear now and in the future.

I'm not against discussing changes in this area, as long as the fundamental 
values of YANG are preserved and our mechanisms are clearly defined.

Best Regards,
/jan

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 no later than Sunday 
March 17 (any time zone).

Thanks,
Jason (+ chairs Kent and Lou)

Draft Agenda for the NETMOD 119 WG Session

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

Session:

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

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

WG Chairs:

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

WG Secretary

Jason Sterne (jason dot sterne at nokia dot com)

Available During Session:

MeetEcho: 

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 
>>  no later than Sunday March 17 (any time 
>> zone).
>>  
>> Thanks,
>> Jason (+ chairs Kent and Lou)
>>  
>> Draft Agenda for the NETMOD 119 WG Session
>> https://datatracker.ietf.org/meeting/119/materials/agenda-119-netmod
>> https://datatracker.ietf.org/meeting/119/session/netmod
>> 
>> Session:
>> Thursday, March 21, 2024
>> 13:00-15:00 Brisbane (Australia - Eastern Time)
>> 03:00-05:00 UTC
>> 23:00-01:00 Wednesday March 20 America - Eastern Time
>> https://www.timeanddate.com/worldclock/converter.html?iso=20240321T03=47
>> 
>> Room: M2 https://datatracker.ietf.org/meeting/119/floor-plan?room=m2
>> 
>> WG Chairs:
>> Lou Berger (lberger at labs dot net)
>> Kent Watsen (kent plus ietf at watsen dot net)
>> 
>> WG Secretary
>> Jason Sterne (jason dot sterne at nokia dot com)
>> 
>> Available During Session:
>> MeetEcho: https://meetings.conf.meetecho.com/ietf119/?session=31987
>> Onsite tool: https://meetings.conf.meetecho.com/onsite119/?session=31987
>> Audio Only: https://mp3.conf.meetecho.com/ietf119/31987.m3u
>> 
>> Available During and After Session:
>> Notes: 

Re: [netmod] Draft IETF 119 NETMOD Agenda posted

[Jan Lindblad (jlindbla)]

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 no later than Sunday 
March 17 (any time zone).

Thanks,
Jason (+ chairs Kent and Lou)

Draft Agenda for the NETMOD 119 WG Session

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

Session:

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

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

WG Chairs:

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

WG Secretary

Jason Sterne (jason dot sterne at nokia dot com)

Available During Session:

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

Available During and After Session:

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

Available After Session:

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

1) Session Intro & WG Status (10 min)

Presenter: Chairs

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

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

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

[Andy Bierman]

On Tue, Mar 12, 2024 at 7:28 AM Per Andersson (perander) 
wrote:

> Andy Bierman  on Tuesday, March 12, 2024 15:14:
> > On Tue, Mar 12, 2024 at 6:58 AM Jan Lindblad  j...@tail-f.com>> wrote:
> >> Then we have the other thing with RESTCONF where the module names are
> used instead, which also causes some (unnecessary) confusion. If NETCONF
> and RESTCONF could use the same "prefixes", things would be easier. In the
> early days of programming (I mean in the 60's), FORTRAN programmers were
> told to choose short function and variable names. This mindset has long
> since been abandoned. Why is this still a good practice in YANG prefixes?
> >
> > I disagree with any changes to module prefixes.
> > They are not confusing to anybody who bothers to learn a little about
> YANG.
> > Long prefixes make YANG harder to read, not easier.
>
> I disagree with this (hence agree with Jan).
>
> It was confusing to learn that RESTCONF and NETCONF
> use different prefixes.
>
> Short prefixes are nice when writing, longer descriptive prefixes
> are better when reading. Why would otherwise other identifiers
> have these long form names, and not have short identifiers too?
>
>

Module names need to be longer so they are unlikely to clash.
All other identifiers are scoped within a namespace, so no technical reason
to be longer.
I agree that using prefixes that are already assigned should be avoided.



>
> --
> Per


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

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

[Per Andersson (perander)]

Andy Bierman  on Tuesday, March 12, 2024 15:14:
> On Tue, Mar 12, 2024 at 6:58 AM Jan Lindblad 
> mailto:j...@tail-f.com>> wrote:
>> Then we have the other thing with RESTCONF where the module names are used 
>> instead, which also causes some (unnecessary) confusion. If NETCONF and 
>> RESTCONF could use the same "prefixes", things would be easier. In the early 
>> days of programming (I mean in the 60's), FORTRAN programmers were told to 
>> choose short function and variable names. This mindset has long since been 
>> abandoned. Why is this still a good practice in YANG prefixes?
>
> I disagree with any changes to module prefixes.
> They are not confusing to anybody who bothers to learn a little about YANG.
> Long prefixes make YANG harder to read, not easier.

I disagree with this (hence agree with Jan).

It was confusing to learn that RESTCONF and NETCONF
use different prefixes.

Short prefixes are nice when writing, longer descriptive prefixes
are better when reading. Why would otherwise other identifiers
have these long form names, and not have short identifiers too?


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

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

[Andy Bierman]

On Tue, Mar 12, 2024 at 6:58 AM Jan Lindblad  wrote:

> Jürgen,
>
> You have been in the YANG circles long enough to remember the basic
> tenets.
>
>YANG values the time and effort of the
>readers of models above those of modules writers and YANG tool-chain
>developers.
>
> In this spirit, it's obvious to me that choosing very short prefixes are
> making it much harder for newcomers to parse YANG modules. They see "snmp:"
> in one module and assumes it means the same as "snmp:" in another. Or
> "if:", "mpls:" and a bunch of other convenient, short prefixes that I have
> seen clashing in the real world. If we could foster the habit (best
> practice) of at least adding a few characters to distinguish the publishing
> organizations from each other, a lot would be won. "ietf-if:" and
> "vendor-if:" would be a lot clearer.
>
> Then we have the other thing with RESTCONF where the module names are used
> instead, which also causes some (unnecessary) confusion. If NETCONF and
> RESTCONF could use the same "prefixes", things would be easier. In the
> early days of programming (I mean in the 60's), FORTRAN programmers were
> told to choose short function and variable names. This mindset has long
> since been abandoned. Why is this still a good practice in YANG prefixes?
>
>

I disagree with any changes to module prefixes.
They are not confusing to anybody who bothers to learn a little about YANG.
Long prefixes make YANG harder to read, not easier.


Best Regards,
> /jan
>
>
>
Andy


>
> On 5 Mar 2024, at 10:38, Jürgen Schönwälder
>  wrote:
>
> Hi Med,
>
> I believe it is a misconception that text not written in capital letters
> is not normative. I also believe we need _guidelines_ on the choice of
> identifiers like prefixes and not hard rules.
>
> Prefixes do not have to be unique. It is nice if they are for widely
> used modules, but we are on a slippery path if we think of them as
> something that should be unique. Then they get long or clumsy or both
> (or worse we encourage a competition to allocate nice short prefixes).
> Yes, the original language is vague, on purpose. I guess I miss which
> problem is solved by requiring uniqueness that practically can't be
> ensured and is technically also not necessary.
>
> /js
>
> On 05.03.24 09:58, mohamed.boucad...@orange.com wrote:
>
> Hi Jürgen,
> Please see inline.
> Cheers,
> Med
>
> -Message d'origine-
> De : netmod  De la part de Jürgen Schönwälder
> Envoyé : lundi 4 mars 2024 20:44
> À : netmod@ietf.org
> Objet : Re: [netmod] On prefixes RE: Next steps for draft-ietf-netmod-
> rfc8407bis
>
> Hi,
>
> the statement "should be selected carefully to be unique" is
> impossible to implement given an open ended set of YANG modules.
>
> [Med] Hmm, but there is no normative text in that sentence. What
> concretely needs to be followed is indicated in the sentence right after
> (SHOULD NOT); which is inherited from 8407.
> Isn't "selected carefully to be unique" echoing the spirit of this text
> from RFC7950?
>Developers of YANG modules and submodules are RECOMMENDED to choose
>names for their modules that will have a low probability of colliding
>with standard or other enterprise modules, e.g., by using the
>enterprise or organization name as a prefix for the module name.
>Within a server, all module names MUST be unique.
>
> If this section only applies to IETF modules (I thought it is more
> general) and IANA never makes a mistake and we accept that prefixes
> get longer or cryptic over time, then this may be possible to
> implement, but I am not sure this is actually desirable.
>
> The original wording "likely to be unique" was selected carefully, it
> conveys the message that prefixes can't be assumed to be unique.
>
> [Med] "SHOULD ...likely" is really ambiguous as a reco if the text does
> not explain when it won't be
>
> Perhaps it should be even further watered down to "likely to be unique
> in a certain usage context".
>
> [Med] What is a usage context? how that usage context is known? How a
> module is concretely bound to it? Etc. IMO, this triggers more questions
> that it clarifies the guidance.
>
>
> I believe the original wording was good enough and does not need an
> update. Every update, even if well intended, carries a risk to break
> something that works.
>
> /js
>
> On 04.03.24 19:39, Randy Presuhn wrote:
>
> Hi -
>
> On 2024-03-04 12:51 AM, mohamed.boucad...@orange.com wrote:
>
> Hi Jan,
>
> I went so far with the following:
>
> OLD:
>
> Prefix values SHOULD be short but are also likely to be unique.
>
> Prefix values SHOULD NOT conflict with known modules that have
> been
>
> previously published.
>
> NEW:
>
> Prefix values should be selected carefully to be unique, and
> ideally
>
> not too long.  Specifically, prefix values SHOULD NOT conflict
> with
>
> known modules that have been previously published.
>
> I'm having troubles with the normative language here. If we
>
> maintain
>
> the 

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

[Jan Lindblad]

Jürgen,

You have been in the YANG circles long enough to remember the basic tenets. 

   YANG values the time and effort of the
   readers of models above those of modules writers and YANG tool-chain
   developers.

In this spirit, it's obvious to me that choosing very short prefixes are making 
it much harder for newcomers to parse YANG modules. They see "snmp:" in one 
module and assumes it means the same as "snmp:" in another. Or "if:", "mpls:" 
and a bunch of other convenient, short prefixes that I have seen clashing in 
the real world. If we could foster the habit (best practice) of at least adding 
a few characters to distinguish the publishing organizations from each other, a 
lot would be won. "ietf-if:" and "vendor-if:" would be a lot clearer.

Then we have the other thing with RESTCONF where the module names are used 
instead, which also causes some (unnecessary) confusion. If NETCONF and 
RESTCONF could use the same "prefixes", things would be easier. In the early 
days of programming (I mean in the 60's), FORTRAN programmers were told to 
choose short function and variable names. This mindset has long since been 
abandoned. Why is this still a good practice in YANG prefixes?

Best Regards,
/jan



> On 5 Mar 2024, at 10:38, Jürgen Schönwälder 
>  wrote:
> 
> Hi Med,
> 
> I believe it is a misconception that text not written in capital letters
> is not normative. I also believe we need _guidelines_ on the choice of
> identifiers like prefixes and not hard rules.
> 
> Prefixes do not have to be unique. It is nice if they are for widely
> used modules, but we are on a slippery path if we think of them as
> something that should be unique. Then they get long or clumsy or both
> (or worse we encourage a competition to allocate nice short prefixes).
> Yes, the original language is vague, on purpose. I guess I miss which
> problem is solved by requiring uniqueness that practically can't be
> ensured and is technically also not necessary.
> 
> /js
> 
> On 05.03.24 09:58, mohamed.boucad...@orange.com 
>  wrote:
>> Hi Jürgen,
>> Please see inline.
>> Cheers,
>> Med
>>> -Message d'origine-
>>> De : netmod  De la part de Jürgen Schönwälder
>>> Envoyé : lundi 4 mars 2024 20:44
>>> À : netmod@ietf.org
>>> Objet : Re: [netmod] On prefixes RE: Next steps for draft-ietf-netmod-
>>> rfc8407bis
>>> 
>>> Hi,
>>> 
>>> the statement "should be selected carefully to be unique" is
>>> impossible to implement given an open ended set of YANG modules.
>> [Med] Hmm, but there is no normative text in that sentence. What concretely 
>> needs to be followed is indicated in the sentence right after (SHOULD NOT); 
>> which is inherited from 8407.
>> Isn't "selected carefully to be unique" echoing the spirit of this text from 
>> RFC7950?
>>Developers of YANG modules and submodules are RECOMMENDED to choose
>>names for their modules that will have a low probability of colliding
>>with standard or other enterprise modules, e.g., by using the
>>enterprise or organization name as a prefix for the module name.
>>Within a server, all module names MUST be unique.
>>> If this section only applies to IETF modules (I thought it is more
>>> general) and IANA never makes a mistake and we accept that prefixes
>>> get longer or cryptic over time, then this may be possible to
>>> implement, but I am not sure this is actually desirable.
>>> 
>>> The original wording "likely to be unique" was selected carefully, it
>>> conveys the message that prefixes can't be assumed to be unique.
>> [Med] "SHOULD ...likely" is really ambiguous as a reco if the text does not 
>> explain when it won't be
>>> Perhaps it should be even further watered down to "likely to be unique
>>> in a certain usage context".
>> [Med] What is a usage context? how that usage context is known? How a module 
>> is concretely bound to it? Etc. IMO, this triggers more questions that it 
>> clarifies the guidance.
>>> 
>>> I believe the original wording was good enough and does not need an
>>> update. Every update, even if well intended, carries a risk to break
>>> something that works.
>>> 
>>> /js
>>> 
>>> On 04.03.24 19:39, Randy Presuhn wrote:
 Hi -
 
 On 2024-03-04 12:51 AM, mohamed.boucad...@orange.com wrote:
> Hi Jan,
> 
> I went so far with the following:
> 
> OLD:
> 
> Prefix values SHOULD be short but are also likely to be unique.
> 
> Prefix values SHOULD NOT conflict with known modules that have
> been
> 
> previously published.
> 
> NEW:
> 
> Prefix values should be selected carefully to be unique, and
> ideally
> 
> not too long.  Specifically, prefix values SHOULD NOT conflict
> with
> 
> known modules that have been previously published.
> 
> I'm having troubles with the normative language here. If we
>>> maintain
> the two sentences, the second SHOULD is sufficient for 

[netmod] IETF#119 I-D Status: draft-ietf-netmod-rfc8407bis

[mohamed . boucadair]

Hi all,


  *   A candidate -10 is ready to address 3 comments from Jan:
 *   Long trees
 *   Updated security template
 *   Minor tweaks to Section 3.8
 *   The changes circulated on the list can be seen here: Compare Editor's 
Copy to 
Datatracker
  *   Jan raised two other comments (short/uniqueness of prefixes + how to 
handle "not set") but no changes were made per the feedback received on the 
list.
  *   Next steps:
 *   Submit -10 right after IETF#119
 *   WGLC

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 detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] IETF#119 I-D Status: draft-ietf-netmod-acl-extensions

[mohamed . boucadair]

Hi all,

Here is a brief status of this I-D:


  *   -03: was in the WGLC (Dec 2023)
  *   -04/06: addressed comments received from Mahesh, e.g.,
 *   Fix some broken "when" statements
 *   Transform some normative language into YANG statements
 *   Grouped the examples in an appendix
 *   Update the security section
 *   Fix some broken titles
  *   Next step: run a second WGLC based on -06

I let Oscar, Samier, and Qin further comment as appropriate.

Cheers,
Med
Orange Restricted



Orange Restricted

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

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod