from:"mohamed . boucadair"

[netmod] Re: AD - Re: AUTH48: RFC-to-be 9644 for your review

2024-09-12 Thread mohamed . boucadair

Hi Kent,

Please see inline.

Cheers,
Med

De : Kent Watsen 
Envoyé : jeudi 12 septembre 2024 13:04
À : BOUCADAIR Mohamed INNOV/NET 
Cc : Mahesh Jethanandani ; netmod@ietf.org
Objet : Re: [netmod] AD - Re: AUTH48: RFC-to-be 9644 
 for your review


Hi Med,


On Sep 12, 2024, at 3:14 AM, 
mohamed.boucad...@orange.com wrote:

Hi Mahesh,

Please see inline.

Cheers,
Med

De : Mahesh Jethanandani 
mailto:mjethanand...@gmail.com>>
Envoyé : jeudi 12 septembre 2024 00:49
À : BOUCADAIR Mohamed INNOV/NET 
mailto:mohamed.boucad...@orange.com>>
Cc : Kent Watsen mailto:kent+i...@watsen.net>>; 
netmod@ietf.org
Objet : Re: [netmod] AD - Re: AUTH48: RFC-to-be 9644 
 for your review



Hi Med,

The reference of QUIC is to the protocol, RFC 9000, not NETCONF over QUIC, an 
I-D as you note; just as the reference is to SSH protocol, RFC 4252, not 
NETCONF over SSH, RFC 6242.
[Med] I understand the intent is to cite the transport themselves, but the text 
refers to MTI of these “YANG-based management protocols”. I don’t think we can 
make any claim about QUIC here as we don’t have an authoritative spec for that. 
If we want to cite QUIC, some further tweaking to the text is needed, IMO.

RESTCONF already supports QUIC.
[Med] Yes, RETCONF does not  require a specific version of HTTP but still TLS 
is what is indicated as MTI for RC per rfc8040#section-2.1.

No transport-binding document will be written to enable QUIC for RC.
[Med] Isn’t rfc9114 that is applicable for RC, rather than 9000?


On Sep 11, 2024, at 2:57 AM, 
mohamed.boucad...@orange.com wrote:

Hi Kent,

I like the NEWER better compared to the initial NEW you shared, however I think 
some more tweaking is needed.

I understand why you cited QUIC as well, but we don’t have formally a spec for 
mapping with QUIC (I know there is an individual I-D). We actually don’t need 
to be exhaustive here and cite every transport option.

The proposed NEWER changes a little bit the approach from the **recommending 
the use of MTI** to simply listing available MTI.

[mj] Why do you say that? The statement says the protocols have 
mandatory-to-implement …
[Med] Having an MTI does not mean that MTI is actually used/enabled.

Touché  :)

One could process “implement” to be at the runtime-level or code-level.  I 
meant the former, and see that you’re interpreting the later, which is fair.

First, I wonder if there isn’t a formal definition for MTI that disambiguates 
the two cases.  Looking, I see MTI used in the context of algorithms, which 
lends itself to the “code level” interpretation.  Fine.

[Med] Thanks

Then either s/implement/use/  or  s/-to-implement// ?
[Med] « have to use » would be better, IMO.


Separately, I see your update is different in a couple ways.  Please see below 
for details…


Cheers,
Med

De : Kent Watsen mailto:kent+i...@watsen.net>>
Envoyé : mercredi 11 septembre 2024 00:10
À : BOUCADAIR Mohamed INNOV/NET 
mailto:mohamed.boucad...@orange.com>>
Cc : netmod@ietf.org
Objet : Re: [netmod] AD - Re: AUTH48: RFC-to-be 9644 
 for your review

Hi Med,

NEWER (this is what I’m asking RFC Editor to do for the suite of client-server 
drafts)

This section is modeled after the template described in Section 3.7 of 
[RFC].

This first line wasn’t picked up.  Note that the word “modeled” gives an 
authors a little flexibility, as is needed sometimes.

To point, the RFC Editor takes the words literally and raise issues when things 
aren’t exactly same…until this word was changed.

Honestly, the same should be done to all of the templates defined in the 
document.

[Med] This is fair. Please see: 
https://github.com/netmod-wg/rfc8407bis/commit/972970ce16c050d8420f50f07637f4e00770cdd5


The "" YANG module defines a data model that is designed to be 
accessed via YANG-

IIRC, you use different words than “data model”.   I’m trying to use 
sufficiently ambiguous language that includes also modules that only define 
identities, or only enumerations, or only typedefs, etc.

I was going to write “data model, or parts of data models,” but it seemed 
unnecessary wordy and obscures the main point of the sentence.

I don’t deny that my text could be improved, but your take didn’t seem right 
either.

FWIW, I only know about your changes to my text because I received GitHub 
notifications.  Was a link for the PR sent?  In any case, it would’ve been nice 
if you’d stated that changes had been made, rather than me having to discover 
them on my own.

[Med] I didn’t share the PR because that wasn’t ready yet and I was waiting for 
the discussion to converge to have something I’m more happy with it. Now that 
you are on it, feel free to propose your edits directly there :-) Thanks.

Kent // contributor




Ce message et ses pieces jointes peuvent contenir

[netmod] Re: AD - Re: AUTH48: RFC-to-be 9644 for your review

2024-09-12 Thread mohamed . boucadair

Hi Mahesh,

Please see inline.

Cheers,
Med

De : Mahesh Jethanandani 
Envoyé : jeudi 12 septembre 2024 00:49
À : BOUCADAIR Mohamed INNOV/NET 
Cc : Kent Watsen ; netmod@ietf.org
Objet : Re: [netmod] AD - Re: AUTH48: RFC-to-be 9644 
 for your review



Hi Med,

The reference of QUIC is to the protocol, RFC 9000, not NETCONF over QUIC, an 
I-D as you note; just as the reference is to SSH protocol, RFC 4252, not 
NETCONF over SSH, RFC 6242.
[Med] I understand the intent is to cite the transport themselves, but the text 
refers to MTI of these “YANG-based management protocols”. I don’t think we can 
make any claim about QUIC here as we don’t have an authoritative spec for that. 
If we want to cite QUIC, some further tweaking to the text is needed, IMO.

On Sep 11, 2024, at 2:57 AM, 
mohamed.boucad...@orange.com wrote:

Hi Kent,

I like the NEWER better compared to the initial NEW you shared, however I think 
some more tweaking is needed.

I understand why you cited QUIC as well, but we don’t have formally a spec for 
mapping with QUIC (I know there is an individual I-D). We actually don’t need 
to be exhaustive here and cite every transport option.

The proposed NEWER changes a little bit the approach from the **recommending 
the use of MTI** to simply listing available MTI.

[mj] Why do you say that? The statement says the protocols have 
mandatory-to-implement …
[Med] Having an MTI does not mean that MTI is actually used/enabled.

Cheers,
Med

De : Kent Watsen mailto:kent+i...@watsen.net>>
Envoyé : mercredi 11 septembre 2024 00:10
À : BOUCADAIR Mohamed INNOV/NET 
mailto:mohamed.boucad...@orange.com>>
Cc : netmod@ietf.org
Objet : Re: [netmod] AD - Re: AUTH48: RFC-to-be 9644 
 for your review

Hi Med,

NEWER (this is what I’m asking RFC Editor to do for the suite of client-server 
drafts)

This section is modeled after the template described in Section 3.7 of 
[RFC].

The "" YANG module defines a data model that is designed to be 
accessed via YANG-based management protocols, such as NETCONF [RFC6241] and 
RESTCONF [RFC8040].  These protocols have mandatory-to-implement secure 
transport layers (e.g., SSH [RFC4252], TLS [RFC8446], QUIC [RFC9000]) and 
mandatory-to-implement mutual authentication.

Kent // contributor





On Sep 4, 2024, at 10:28 AM, Kent Watsen 
mailto:kent+i...@watsen.net>> wrote:

Hi Med,

A number of client-server drafts (in the NETCONF WG) are in AUTH48.   One 
AD-level issue raised on all the drafts regards the Security Considerations 
section not following the template in RFC 8407 or the template in rfc8407bis.  
You can see the discussion below.

My suggestion follows.

OLD:
This section uses the template described in Section 3.7 of [RFC].

The YANG module specified in this document defines a schema for data
that is designed to be accessed via network management protocols such
as NETCONF [RFC6241] or RESTCONF [RFC8040]. These network management
protocols are required to use a secure transport layer and mutual
authentication, e.g., SSH [RFC6242] without the "none" authentication
option, Transport Layer Security (TLS) [RFC8446] with mutual X.509
authentication, and HTTPS with HTTP authentication (Section 11 of
[RFC9110]).


NEW:
This section is modeled after the template described in Section 3.7 of 
[RFC].

The  YANG module defines "grouping” and “container” statements 
that are designed to be accessed via YANG-based management protocols, such as 
NETCONF [RFC6241] and RESTCONF [RFC8040].  These protocols have 
mandatory-to-implement secure transport layers (e.g., SSH [RFC4252], TLS 
[RFC8446], QUIC [RFC9000]) and mandatory-to-implement mutual authentication.


ALSO NEW?  (Add after the above paragraph?)

For the NETCONF protocol [RFC6241] , transport mapping documents include:
  - Using the NETCONF Protocol over Secure Shell (SSH) [RFC6242]
  - Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual 
X.509 Authentication [RFC 7589]
  - Using NETCONF over QUIC connection [NETCONF-QUIC]

For the RESTCONF protocol [RFC8040], the mandatory-to-implement transport is 
HTTPS, as defined in:
  - HTTP/1.1 [RFC9112]
  - HTTP/2 [RFC9112]
  - HTTP/3 [RFC9112]


Thoughts?


Kent  // contributor





Begin forwarded message:

From: Mahesh Jethanandani 
mailto:mjethanand...@gmail.com>>
Subject: Re: AD - Re: AUTH48: RFC-to-be 9644 
 for your review
Date: September 3, 2024 at 5:41:58 PM EDT
To: Kent Watsen mailto:kent+i...@watsen.net>>, Alanna 
Paloma mailto:apal...@amsl.com>>
Cc: Alice Russo mailto:aru...@amsl.com>>, 
netconf-...@ietf.org, NETCONF WG Chairs 
mailto:netconf-cha...@ietf.org>>, Per Andersson 
mailto:peran...@cisco.com>>, RFC Editor 
mailto:rfc-edi...@rfc-editor.org>>, auth48archive 
mailto:auth48arch...@rfc-editor.org>>
Resent-From: mailto:alias-boun...@ietf.org>>
Resent-To: kent+i...@watsen.net, 
per.i...@ionio.se,

[netmod] Re: AD - Re: AUTH48: RFC-to-be 9644 for your review

2024-09-11 Thread mohamed . boucadair

Hi Kent,

I like the NEWER better compared to the initial NEW you shared, however I think 
some more tweaking is needed.

I understand why you cited QUIC as well, but we don’t have formally a spec for 
mapping with QUIC (I know there is an individual I-D). We actually don’t need 
to be exhaustive here and cite every transport option.

The proposed NEWER changes a little bit the approach from the **recommending 
the use of MTI** to simply listing available MTI.

Cheers,
Med

De : Kent Watsen 
Envoyé : mercredi 11 septembre 2024 00:10
À : BOUCADAIR Mohamed INNOV/NET 
Cc : netmod@ietf.org
Objet : Re: [netmod] AD - Re: AUTH48: RFC-to-be 9644 
 for your review

Hi Med,

NEWER (this is what I’m asking RFC Editor to do for the suite of client-server 
drafts)

This section is modeled after the template described in Section 3.7 of 
[RFC].

The "" YANG module defines a data model that is designed to be 
accessed via YANG-based management protocols, such as NETCONF [RFC6241] and 
RESTCONF [RFC8040].  These protocols have mandatory-to-implement secure 
transport layers (e.g., SSH [RFC4252], TLS [RFC8446], QUIC [RFC9000]) and 
mandatory-to-implement mutual authentication.

Kent // contributor




On Sep 4, 2024, at 10:28 AM, Kent Watsen 
mailto:kent+i...@watsen.net>> wrote:

Hi Med,

A number of client-server drafts (in the NETCONF WG) are in AUTH48.   One 
AD-level issue raised on all the drafts regards the Security Considerations 
section not following the template in RFC 8407 or the template in rfc8407bis.  
You can see the discussion below.

My suggestion follows.

OLD:
This section uses the template described in Section 3.7 of [RFC].

The YANG module specified in this document defines a schema for data
that is designed to be accessed via network management protocols such
as NETCONF [RFC6241] or RESTCONF [RFC8040]. These network management
protocols are required to use a secure transport layer and mutual
authentication, e.g., SSH [RFC6242] without the "none" authentication
option, Transport Layer Security (TLS) [RFC8446] with mutual X.509
authentication, and HTTPS with HTTP authentication (Section 11 of
[RFC9110]).


NEW:
This section is modeled after the template described in Section 3.7 of 
[RFC].

The  YANG module defines "grouping” and “container” statements 
that are designed to be accessed via YANG-based management protocols, such as 
NETCONF [RFC6241] and RESTCONF [RFC8040].  These protocols have 
mandatory-to-implement secure transport layers (e.g., SSH [RFC4252], TLS 
[RFC8446], QUIC [RFC9000]) and mandatory-to-implement mutual authentication.


ALSO NEW?  (Add after the above paragraph?)

For the NETCONF protocol [RFC6241] , transport mapping documents include:
  - Using the NETCONF Protocol over Secure Shell (SSH) [RFC6242]
  - Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual 
X.509 Authentication [RFC 7589]
  - Using NETCONF over QUIC connection [NETCONF-QUIC]

For the RESTCONF protocol [RFC8040], the mandatory-to-implement transport is 
HTTPS, as defined in:
  - HTTP/1.1 [RFC9112]
  - HTTP/2 [RFC9112]
  - HTTP/3 [RFC9112]


Thoughts?


Kent  // contributor




Begin forwarded message:

From: Mahesh Jethanandani 
mailto:mjethanand...@gmail.com>>
Subject: Re: AD - Re: AUTH48: RFC-to-be 9644 
 for your review
Date: September 3, 2024 at 5:41:58 PM EDT
To: Kent Watsen mailto:kent+i...@watsen.net>>, Alanna 
Paloma mailto:apal...@amsl.com>>
Cc: Alice Russo mailto:aru...@amsl.com>>, 
netconf-...@ietf.org, NETCONF WG Chairs 
mailto:netconf-cha...@ietf.org>>, Per Andersson 
mailto:peran...@cisco.com>>, RFC Editor 
mailto:rfc-edi...@rfc-editor.org>>, auth48archive 
mailto:auth48arch...@rfc-editor.org>>
Resent-From: mailto:alias-boun...@ietf.org>>
Resent-To: kent+i...@watsen.net, 
per.i...@ionio.se, 
res...@yahoo.com

Hi Kent,


On Sep 3, 2024, at 12:18 PM, Kent Watsen 
mailto:kent+i...@watsen.net>> wrote:

Hi Mahesh,


On Aug 29, 2024, at 6:27 PM, Mahesh Jethanandani 
mailto:mjethanand...@gmail.com>> wrote:

Hi Kent,


On Aug 29, 2024, at 1:59 PM, Kent Watsen 
mailto:kent+i...@watsen.net>> wrote:


Hi Mahesh (and Alice/Alanna)




10) 

We have two options. There is the YANG security guidelines template that Alice 
points to, and then there is rfc8407bis template, that has been fairly stable 
for sometime. Even if you do not want to use the latter, because it is still a 
draft, we should adopt the guidelines that Alice points to. Do you disagree?

Yes, I sort of do disagree.

1) They are “guidelines”, which suggests variability MAY occur.

I will agree that they are guidelines, and as such can have variability in how 
they are used, specially as it applies to modules that are only defining 
enumerations or identities. However, comparing the guidelines in rfc8407bis to 
what is in the draft for ietf-ssh-server and ietf-ssh-client modules, I notice 
that

- There is no r

[netmod] Re: Paul Wouters' Discuss on draft-ietf-netmod-syslog-model-32: (with DISCUSS and COMMENT)

2024-09-11 Thread mohamed . boucadair

Hi Kent,

Yes, I was referring to both large tree diagrams and trees with long lines.

Having tree diagrams that span several pages is not convenient for readers and 
does not serve the purpose of having tree/subtrees in the narrative part. 
Splitting into small diagrams would help here. Some of the small diagrams can 
be manually tweaked to better fit the size constraints. We used that approach 
in many RFCs, e.g., rfc9182.

Cheers,
Med

De : Kent Watsen 
Envoyé : mardi 10 septembre 2024 20:09
À : BOUCADAIR Mohamed INNOV/NET 
Cc : Joe Clarke (jclarke) ; 
draft-ietf-netmod-syslog-mo...@ietf.org; netmod@ietf.org
Objet : Re: [netmod] Paul Wouters' Discuss on 
draft-ietf-netmod-syslog-model-32: (with DISCUSS and COMMENT)


Hi Med,

The issue here isn’t how *long* the examples are, but how *wide* they are.

The syslog model itself is relatively small, but the tree diagrams blow up (in 
both length and width) just by using the TCP/TLS-client-server draft’s 
groupings.  There really isn’t a way for the syslog model to be broken into 
smaller pieces to get around this.

Regarding "The tree as displayed in the draft does not actually adhere with 
this part in 8407bis”, I got curious and looked.  Assuming the groupings are 
NOT expanded (which the rfc8407bis text below allows), I’m unsure what issue 
triggers.  Can you say?

Separately, I noticed that the document does not seem to use the `rfcfold` 
utility (RFC 8792), which may be a different issue that could be fixed.

Kent // as author



On Sep 10, 2024, at 11:37 AM, 
mohamed.boucad...@orange.com wrote:

Re-,

The tree as displayed in the draft does not actually adhere with this part in 
8407bis:

   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.

On the tooling side, we do have the following in the 8407bis:

  The tooling may evolve in the future to provide better rendering
  of too long trees.  This tooling may offer (but not limited to),
  unfold trees, control of expanded views, ease navigation among
  various levels of a tree, support of hyperlinks, etc.  When such a
  tooling is available, too long trees can be displayed in the HTML
  version of documents that include such trees.

I know that Italo tried to have a discussion in 121 with Carsten for md(?), but 
I don’t know if that discussion actually happened. Italo can clarify this.

Cheers,
Med

De : Kent Watsen mailto:kent+i...@watsen.net>>
Envoyé : mardi 10 septembre 2024 17:07
À : Joe Clarke (jclarke) 
mailto:jclarke=40cisco@dmarc.ietf.org>>
Cc : 
draft-ietf-netmod-syslog-mo...@ietf.org;
 netmod@ietf.org
Objet : [netmod] Re: Paul Wouters' Discuss on 
draft-ietf-netmod-syslog-model-32: (with DISCUSS and COMMENT)

[removing the IESG]


Hi Joe, authors, and NETMOD.

On Sep 10, 2024, at 10:04 AM, Joe Clarke (jclarke) 
mailto:jclarke=40cisco@dmarc.ietf.org>> 
wrote:

Thanks for the comments and feedback, Paul.  I’ve opened GitHub 
issuehttps://github.com/netmod-wg/syslog-model/issues/14 so Mahesh and I can 
track the necessary changes on our end.  See below for some initial responses.

The layout is completely broken / wrapped, making the document fairly
unreadable. Can this be fixed somehow ?

[JMC] Éric had the same comment, and I thought we’d be good just expanding the 
full tree.  However, it seems this is causing readability and confusion 
problems.
I ran into a similar “wrapping tree diagrams is ugly" comment in the suite of 
client-server drafts.   Not expanding the groupings in the tree diagrams helps, 
but still may not be enough - you just need to try and see how it looks.  That 
said, there is still one thing that can be done to improve the appearance of 
*folded” tree diagrams, which is epitomized by the following RFC Editor comment 
put into the documents:

 Tree-diagrams in this draft may use the '\' line-folding mode 
defined in RFC 8792.
   However, nicer-to-the-eye is when the '\\' line-folding mode 
is used.  The AD suggested
   suggested putting a request here for the RFC Editor to help convert 
"ugly" '\' folded
   examples to use the '\\' folding mode.  "Help convert" may 
be interpreted as, identify
   what looks ugly and ask the authors to make the adjustment.

PS: there is a desire to have Datatracker *unfold* folded a

[netmod] Re: Paul Wouters' Discuss on draft-ietf-netmod-syslog-model-32: (with DISCUSS and COMMENT)

2024-09-11 Thread mohamed . boucadair

Hi Qin,

[Qin] Can we apply line wrapping defined in RFC8792 to tree diagram? Normally 
we apply it to text content in the document.

8792-folding can be exceptionally used per the following from 8407bis:

   Native YANG features (e.g., breaking line, "+") SHOULD be used to fit
   a module into the line limits.  Exceptionally, RFC8792-folding of
   YANG modules MAY be used if and only if native YANG features are not
   sufficient.  A similar approach (e.g., use "--yang-line-length 69" or
   split a tree into subtrees) SHOULD be followed for tree diagrams.

Cheers,
Med

De : Qin Wu 
Envoyé : mercredi 11 septembre 2024 04:48
À : Kent Watsen ; BOUCADAIR Mohamed INNOV/NET 

Cc : Joe Clarke (jclarke) ; 
draft-ietf-netmod-syslog-mo...@ietf.org; netmod@ietf.org
Objet : RE: [netmod] Re: Paul Wouters' Discuss on 
draft-ietf-netmod-syslog-model-32: (with DISCUSS and COMMENT)

Separately, I noticed that the document does not seem to use the `rfcfold` 
utility (RFC 8792), which may be a different issue that could be fixed.

Kent // as author

[Qin] Can we apply line wrapping defined in RFC8792 to tree diagram? Normally 
we apply it to text content in the document.

On Sep 10, 2024, at 11:37 AM, 
mohamed.boucad...@orange.com wrote:

Re-,

The tree as displayed in the draft does not actually adhere with this part in 
8407bis:

   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.

On the tooling side, we do have the following in the 8407bis:

  The tooling may evolve in the future to provide better rendering
  of too long trees.  This tooling may offer (but not limited to),
  unfold trees, control of expanded views, ease navigation among
  various levels of a tree, support of hyperlinks, etc.  When such a
  tooling is available, too long trees can be displayed in the HTML
  version of documents that include such trees.

I know that Italo tried to have a discussion in 121 with Carsten for md(?), but 
I don’t know if that discussion actually happened. Italo can clarify this.
[Qin] if the picture can be embedded into pdf version or html version, this 
rendering issue can be easily solved since zoom in or zoom out picture is easy.

Cheers,
Med

De : Kent Watsen mailto:kent+i...@watsen.net>>
Envoyé : mardi 10 septembre 2024 17:07
À : Joe Clarke (jclarke) 
mailto:jclarke=40cisco@dmarc.ietf.org>>
Cc : 
draft-ietf-netmod-syslog-mo...@ietf.org;
 netmod@ietf.org
Objet : [netmod] Re: Paul Wouters' Discuss on 
draft-ietf-netmod-syslog-model-32: (with DISCUSS and COMMENT)

[removing the IESG]


Hi Joe, authors, and NETMOD.

On Sep 10, 2024, at 10:04 AM, Joe Clarke (jclarke) 
mailto:jclarke=40cisco@dmarc.ietf.org>> 
wrote:

Thanks for the comments and feedback, Paul.  I’ve opened GitHub 
issuehttps://github.com/netmod-wg/syslog-model/issues/14 so Mahesh and I can 
track the necessary changes on our end.  See below for some initial responses.

The layout is completely broken / wrapped, making the document fairly
unreadable. Can this be fixed somehow ?

[JMC] Éric had the same comment, and I thought we’d be good just expanding the 
full tree.  However, it seems this is causing readability and confusion 
problems.
I ran into a similar “wrapping tree diagrams is ugly" comment in the suite of 
client-server drafts.   Not expanding the groupings in the tree diagrams helps, 
but still may not be enough - you just need to try and see how it looks.  That 
said, there is still one thing that can be done to improve the appearance of 
*folded” tree diagrams, which is epitomized by the following RFC Editor comment 
put into the documents:

 Tree-diagrams in this draft may use the '\' line-folding mode 
defined in RFC 8792.
   However, nicer-to-the-eye is when the '\\' line-folding mode 
is used.  The AD suggested
   suggested putting a request here for the RFC Editor to help convert 
"ugly" '\' folded
   examples to use the '\\' folding mode.  "Help convert" may 
be interpreted as, identify
   what looks ugly and ask the authors to make the adjustment.

PS: there is a desire to have Datatracker *unfold* folded artwork/sourcecode 
for document output formats that can support horizontal scrolling.  
Specifically, for an HTML-rendered document, the ideal is for examples to be 
unfolded and

[netmod] Re: Paul Wouters' Discuss on draft-ietf-netmod-syslog-model-32: (with DISCUSS and COMMENT)

2024-09-10 Thread mohamed . boucadair

Re-,

The tree as displayed in the draft does not actually adhere with this part in 
8407bis:

   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.

On the tooling side, we do have the following in the 8407bis:

  The tooling may evolve in the future to provide better rendering
  of too long trees.  This tooling may offer (but not limited to),
  unfold trees, control of expanded views, ease navigation among
  various levels of a tree, support of hyperlinks, etc.  When such a
  tooling is available, too long trees can be displayed in the HTML
  version of documents that include such trees.

I know that Italo tried to have a discussion in 121 with Carsten for md(?), but 
I don’t know if that discussion actually happened. Italo can clarify this.

Cheers,
Med

De : Kent Watsen 
Envoyé : mardi 10 septembre 2024 17:07
À : Joe Clarke (jclarke) 
Cc : draft-ietf-netmod-syslog-mo...@ietf.org; netmod@ietf.org
Objet : [netmod] Re: Paul Wouters' Discuss on 
draft-ietf-netmod-syslog-model-32: (with DISCUSS and COMMENT)

[removing the IESG]


Hi Joe, authors, and NETMOD.

On Sep 10, 2024, at 10:04 AM, Joe Clarke (jclarke) 
mailto:jclarke=40cisco@dmarc.ietf.org>> 
wrote:

Thanks for the comments and feedback, Paul.  I’ve opened GitHub issue 
https://github.com/netmod-wg/syslog-model/issues/14 so Mahesh and I can track 
the necessary changes on our end.  See below for some initial responses.

The layout is completely broken / wrapped, making the document fairly
unreadable. Can this be fixed somehow ?

[JMC] Éric had the same comment, and I thought we’d be good just expanding the 
full tree.  However, it seems this is causing readability and confusion 
problems.
I ran into a similar “wrapping tree diagrams is ugly" comment in the suite of 
client-server drafts.   Not expanding the groupings in the tree diagrams helps, 
but still may not be enough - you just need to try and see how it looks.  That 
said, there is still one thing that can be done to improve the appearance of 
*folded” tree diagrams, which is epitomized by the following RFC Editor comment 
put into the documents:

 Tree-diagrams in this draft may use the '\' line-folding mode 
defined in RFC 8792.
   However, nicer-to-the-eye is when the '\\' line-folding mode 
is used.  The AD suggested
   suggested putting a request here for the RFC Editor to help convert 
"ugly" '\' folded
   examples to use the '\\' folding mode.  "Help convert" may 
be interpreted as, identify
   what looks ugly and ask the authors to make the adjustment.

PS: there is a desire to have Datatracker *unfold* folded artwork/sourcecode 
for document output formats that can support horizontal scrolling.  
Specifically, for an HTML-rendered document, the ideal is for examples to be 
unfolded and placed into a textbox that causes a browser to create a textbox 
with horizontal scrolling.   I’m unsure if there is an open-ticket for this 
work to get done.

Kent // as contributor




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

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

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

2024-09-10 Thread mohamed . boucadair

Hi all, 

This version implements the changes discussed with Kent [1] and Amanda [2] for 
better guidance to handle illegal identifiers. The version also:

* addresses an offline comment received from Qiufang about a stale text in 
4.30.2. 
* fixes a bug in 8407 in 4.1 which used to point IANA considerations of 
rfc7950, while this should be RFC6020.

Hope the doc is now ready to move forward.

Cheers,
Med

[1] https://mailarchive.ietf.org/arch/msg/netmod/rmXxDoP1pacbUjtYvZhrQMBDz6o/
[2] https://mailarchive.ietf.org/arch/msg/netmod/ucCARvnTxwlfyPf8k3V0aBDgx5c/

> -Message d'origine-
> De : internet-dra...@ietf.org 
> Envoyé : mardi 10 septembre 2024 13:58
> À : i-d-annou...@ietf.org
> Cc : netmod@ietf.org
> Objet : [netmod] I-D Action: draft-ietf-netmod-rfc8407bis-15.txt
> 
> 
> Internet-Draft draft-ietf-netmod-rfc8407bis-15.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-15.txt
>Pages:   92
>Dates:   2024-09-10
> 
> Abstract:
> 
>This memo provides guidelines for authors and reviewers of
>specifications containing YANG modules, including IANA-
> maintained
>modules.  Recommendations and procedures are defined, which
> are
>intended to increase interoperability and usability of Network
>Configuration Protocol (NETCONF) and RESTCONF protocol
>implementations that utilize YANG modules.  This document
> obsoletes
>RFC 8407.
> 
>Also, this document updates RFC 8126 by providing additional
>guidelines for writing the IANA considerations for RFCs that
> specify
>IANA-maintained modules.  The document also updates RFC 6020
> by
>clarifying how modules and their revisions are handled by
> IANA.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-netmod-
> rfc8407bis%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C847
> 68acb7c624f1bc4d808dcd18fe986%7C90c7a20af34b40bfbc48b9253b6f5d20%
> 7C0%7C0%7C638615663239169374%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w
> LjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%
> 7C&sdata=fOyva%2BZfs99TtnL8VhDmVtwpeoP0Elua02WDJz8%2BLEc%3D&reser
> ved=0
> 
> There is also an HTML version available at:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-netmod-rfc8407bis-
> 15.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C84768acb7
> c624f1bc4d808dcd18fe986%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C
> 0%7C638615663239178139%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
> AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sda
> ta=MclVANBXDUvF%2FP4ljLAMxSXg8cQYMxpP4f096HYHPUA%3D&reserved=0
> 
> A diff from the previous version is available at:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> Fauthor-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-netmod-
> rfc8407bis-
> 15&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C84768acb7c624f
> 1bc4d808dcd18fe986%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6
> 38615663239182916%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ
> QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Cq
> kyv1MTlaNalaDDUfUA6K27UMx7TCZN%2B0dUT%2BcCZ6w%3D&reserved=0
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 
> 
> ___
> netmod mailing list -- netmod@ietf.org
> To unsubscribe send an email to netmod-le...@ietf.org

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

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

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

[netmod] Re: [IANA #1373241] RE: Regarding draft-ietf-netmod-rfc8407bis

2024-09-09 Thread mohamed . boucadair

Hi Amanda, 

Please see inline.

Cheers,
Med

> -Message d'origine-
> De : Amanda Baber via RT 
> Envoyé : mardi 10 septembre 2024 04:04
> À : kent+i...@watsen.net; BOUCADAIR Mohamed INNOV/NET
> 
> Cc : netmod@ietf.org
> Objet : [IANA #1373241] RE: [netmod] Regarding draft-ietf-netmod-
> rfc8407bis
> 
> 
> Hi Med,
> 
> Sounds good, but there is an issue with the registration
> procedure text at the end:
> 
> > NEW:
> >   -  If a new registration uses an identifier that does not
> comply
> >  with the naming conventions listed in Section 4.3.1,
> IANA
> >  should check if a guidance to generate legal
> identifiers was
> >  supplied in the RFC that specified the initial version
> of the
> >  module.  If no such guidance is available, IANA should
> check
> >  the latest revision of the IANA-maintained module for
> similar
> >  patterns.  If failed, IANA should seek advice from
> relevant
> >  registry experts (e.g., designated experts for a
> registry with
> >  Expert Review policy (Section 4.5 of [RFC8126])  or
> responsible
> >  Area Director for a registry with IETF Review (Section
> 4.8 of
> >  [RFC8126]) or Standards Action ((Section 4.9 of
> [RFC8126]))).
> 
> Mentioning one of two registration procedures that involve an
> expert (leaving out Specification Required) but then naming two
> procedures that we should associate with the ADs is a little
> confusing. Are these examples, or are they inadvertently
> incomplete sets?

[Med] These are only examples.

 We would also have to contact the AD about RFC
> Required and IESG Approval registrations, and might have to
> contact them about First Come First Served registrations, in the
> absence of a still-open WG whose chairs we could ask.
> 
> I see that we're effectively being told not to contact the YANG
> doctors ourselves, but I'm not sure that the document needs to
> tell IANA which parties are associated with different
> procedures.
> 
> It could just tell us to "seek advice from relevant registry
> experts (e.g., the IESG-designated experts associated with an
> Expert Review (Section 4.5 of RFC 8126) registry) or the
> responsible Area Director." That would still give us room to find
> someone else for FCFS, if appropriate.

[Med] Noted. Updated the text as suggested. Thanks. 

> 
> thanks,
> Amanda


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

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

[netmod] Re: [IANA #1373241] RE: Regarding draft-ietf-netmod-rfc8407bis

2024-09-09 Thread mohamed . boucadair

Hi Amanda, 

Good inputs. 

Added the follow text as a new bullet:

NEW:
  -  If a new registration uses an identifier that does not comply
 with the naming conventions listed in Section 4.3.1, IANA
 should check if a guidance to generate legal identifiers was
 supplied in the RFC that specified the initial version of the
 module.  If no such guidance is available, IANA should check
 the latest revision of the IANA-maintained module for similar
 patterns.  If failed, IANA should seek advice from relevant
 registry experts (e.g., designated experts for a registry with
 Expert Review policy (Section 4.5 of [RFC8126]) or responsible
 Area Director for a registry with IETF Review (Section 4.8 of
 [RFC8126]) or Standards Action ((Section 4.9 of [RFC8126]))).

Better?

Cheers,
Med

PS: The full diff can still be seen using the same URL: 
https://author-tools.ietf.org/api/iddiff?url_1=https://netmod-wg.github.io/rfc8407bis/draft-ietf-netmod-rfc8407bis.txt&url_2=https://netmod-wg.github.io/rfc8407bis/Amanda/IANA-follow-up-on-expanding-numbers/draft-ietf-netmod-rfc8407bis.txt

> -Message d'origine-
> De : Amanda Baber via RT 
> Envoyé : vendredi 6 septembre 2024 21:39
> À : kent+i...@watsen.net; BOUCADAIR Mohamed INNOV/NET
> 
> Cc : netmod@ietf.org
> Objet : [IANA #1373241] RE: [netmod] Regarding draft-ietf-netmod-
> rfc8407bis
> 
> 
> Hi,
> 
> The new text works, but I'm not sure whether it should be
> included here. See [AB] inline.
> 
> > 1) Regarding "For example, authors of a module with such
> identifiers
> > have to indicate...”, I’m unsure how the registrant is suppose
> to
> > propose valid YANG identifiers.   First, I wonder if the
> registrant
> > would even be aware of the existence of a YANG module for the
> > underlying registry.   Next, I wonder if the registrant would
> know
> > what are valid YANG identifier values.
> >
> > [Med] Fully agree that the registrant of a new entry does not
> (and
> > does not even need to) know the existence of the IANA-
> maintained
> > module. The instruction here is not for those.
> >
> > What I do know, because it happened to me, if that my using the
> > underlying value caused a YANG error.   This is what I suspect
> will
> > happen to IANA.   That is, they’ll first try the underlying
> value and
> > get a module-validation error…
> >
> >
> > Thus I wonder if the instructions should be more in the form of
> “do
> > this when an error occurs”, instead of instructions that
> attempt to
> > proactively determine the issues before they occur?
> >
> > [Med] The proactive approach has the merit to ensure consistent
> naming
> > conventions and straightforward actions for IANA. I think that
> we
> > should encourage authors to look into this. There might be
> errors if
> > the naming conventions listed in Section 4.3.1 are not
> followed. I
> > have no problem to reword the text so that this can be easily
> consumed
> > by IANA as well. I hope Amanda can share her
> feedback/preference.
> 
> [AB] I see how this advice would work if IANA were creating the
> module, but I'm a little less clear on how it works for
> anticipating future underlying registrations.
> 
> If an identifier won't validate, IANA will already know that they
> have to take some action to remedy it. The first step would be to
> check whether the module had already solved the problem for an
> earlier occurrence of "3des-*". If there were no such existing
> registration, and knowing that "3" might be rendered as either
> "triple" or "three," instead of checking the RFC that created the
> module for advice about a string that didn't appear in the
> underlying registry at the time of publication, we would more
> likely ask the YANG doctors how to proceed. (If the underlying
> registry had designated experts, we might check with them first.)
> 
> If the authors for a specific module already know that there are
> that likely to be more "3des-*" registrations in the future,
> there's no harm in calling it out (as long as they don't appear
> to be implying that the "triple-" solution should be applied to
> any leading number), but in general, it might be better to give
> IANA advice about how to resolve identifier questions in general
> (e.g., check the existing module, contact the YANG doctors or
> other appropriate party).
> 
> thanks,
> Amanda

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

[netmod] Re: [IANA #1373241] Regarding draft-ietf-netmod-rfc8407bis

2024-09-06 Thread mohamed . boucadair

Hi Kent,

Please see inline.

Cheers,
Med

De : Kent Watsen
Envoyé : vendredi 6 septembre 2024 14:24
À : BOUCADAIR Mohamed INNOV/NET
Cc : iana-iss...@iana.org; netmod@ietf.org
Objet : Re: [IANA #1373241] [netmod] Regarding draft-ietf-netmod-rfc8407bis

Hi Med,

1) Regarding "For example, authors of a module with such identifiers have to
indicate...”, I’m unsure how the registrant is suppose to propose valid YANG
identifiers. First, I wonder if the registrant would even be aware of the
existence of a YANG module for the underlying registry. Next, I wonder if the
registrant would know what are valid YANG identifier values.

[Med] Fully agree that the registrant of a new entry does not (and does not
even need to) know the existence of the IANA-maintained module. The instruction
here is not for those.

What I do know, because it happened to me, if that my using the underlying
value caused a YANG error. This is what I suspect will happen to IANA. That
is, they’ll first try the underlying value and get a module-validation error…

Thus I wonder if the instructions should be more in the form of “do this when
an error occurs”, instead of instructions that attempt to proactively determine
the issues before they occur?

[Med] The proactive approach has the merit to ensure consistent naming
conventions and straightforward actions for IANA. I think that we should
encourage authors to look into this. There might be errors if the naming
conventions listed in Section 4.3.1 are not followed. I have no problem to
reword the text so that this can be easily consumed by IANA as well. I hope
Amanda can share her feedback/preference.

2) Regarding this following

-- If a name in the IANA registry does not comply with the
-- YANG naming conventions, add details how IANA can generate
-- legal identifiers.

Who is this comment addressed too? IANA? Is the idea that IANA leaves a
comment for themselves?

[Med] This is part of a template to be used by the authors of the RFC that
defines the initial version. This is to remind the authors to make that check
and supply instructions if needed.

Kent // contributor

On Sep 6, 2024, at 5:56 AM,
mohamed.boucad...@orange.com wrote:

Hi Amanda,

Thanks for these inputs.

OK to add 6to4 as another example. It is actually a good example as we do have
two ways to spell it out in existing RFCs :-)

I updated the text to better insist that the effort should be on the authors
side to make the IANA task easy. Also, updated the template with a placeholder
for that check. Please see the proposed changes at:

https://author-tools.ietf.org/api/iddiff?url_1=https://netmod-wg.github.io/rfc8407bis/draft-ietf-netmod-rfc8407bis.txt&url_2=https://netmod-wg.github.io/rfc8407bis/Amanda/IANA-follow-up-on-expanding-numbers/draft-ietf-netmod-rfc8407bis.txt

Hope this is better.

Cheers,
Med

-Message d'origine-
De : Amanda Baber via RT mailto:iana-iss...@iana.org>>
Envoyé : vendredi 6 septembre 2024 07:52
À : kent+i...@watsen.net; BOUCADAIR Mohamed
INNOV/NET
mailto:mohamed.boucad...@orange.com>>
Cc : netmod@ietf.org
Objet : [IANA #1373241] RE: [netmod] Regarding draft-ietf-netmod-
rfc8407bis

Hi Med, Kent,

I apologize for missing this.

In the 4.30.3 note about creating names, a replacement like this
might be better for IANA:

OLD: (e.g., "3des-cbc" will be "triple-des-cbc" (Section 6.3 of
[RFC4253]))

NEW: (e.g., "3des-cbc" will be "triple-des-cbc" (Section 6.3 of
[RFC4253]); "6to4" will be "sixToFour")

The "6to4"/"sixToFour" example is taken from the iana-if-type
module, published in Section 2 of RFC 7224.

The reasoning here is that the note says that "the procedure MUST
detail how IANA can generate legal identifiers from such a name."

Because we're being told that this is an example of an IANA
Considerations section providing sufficient detail for future
registrations, it would be helpful for us if the note were to
acknowledge, at least implicitly, that future authors may not be
able to supply a single naming pattern that we can always apply
automatically.

The missing piece of information here, I think, is that IANA
operations staff didn't know (and, in the future, may not know
again) that "3des" is pronounced "triple-des." As such, it's
possible for us to read the current example and wonder whether
IANA is being told to replace any leading number in an identifier
with a multiplicative.

thanks,
Amanda

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

[netmod] Re: [IANA #1373241] RE: Regarding draft-ietf-netmod-rfc8407bis

2024-09-06 Thread mohamed . boucadair

Hi Amanda,

Thanks for these inputs.

OK to add 6to4 as another example. It is actually a good example as we do have 
two ways to spell it out in existing RFCs :-)

I updated the text to better insist that the effort should be on the authors 
side to make the IANA task easy. Also, updated the template with a placeholder 
for that check. Please see the proposed changes at: 

https://author-tools.ietf.org/api/iddiff?url_1=https://netmod-wg.github.io/rfc8407bis/draft-ietf-netmod-rfc8407bis.txt&url_2=https://netmod-wg.github.io/rfc8407bis/Amanda/IANA-follow-up-on-expanding-numbers/draft-ietf-netmod-rfc8407bis.txt
 

Hope this is better.

Cheers,
Med

> -Message d'origine-
> De : Amanda Baber via RT 
> Envoyé : vendredi 6 septembre 2024 07:52
> À : kent+i...@watsen.net; BOUCADAIR Mohamed INNOV/NET
> 
> Cc : netmod@ietf.org
> Objet : [IANA #1373241] RE: [netmod] Regarding draft-ietf-netmod-
> rfc8407bis
> 
> 
> Hi Med, Kent,
> 
> I apologize for missing this.
> 
> In the 4.30.3 note about creating names, a replacement like this
> might be better for IANA:
> 
> OLD: (e.g., "3des-cbc" will be "triple-des-cbc" (Section 6.3 of
> [RFC4253]))
> 
> NEW: (e.g., "3des-cbc" will be "triple-des-cbc" (Section 6.3 of
> [RFC4253]); "6to4" will be "sixToFour")
> 
> The "6to4"/"sixToFour" example is taken from the iana-if-type
> module, published in Section 2 of RFC 7224.
> 
> The reasoning here is that the note says that "the procedure MUST
> detail how IANA can generate legal identifiers from such a name."
> 
> Because we're being told that this is an example of an IANA
> Considerations section providing sufficient detail for future
> registrations, it would be helpful for us if the note were to
> acknowledge, at least implicitly, that future authors may not be
> able to supply a single naming pattern that we can always apply
> automatically.
> 
> The missing piece of information here, I think, is that IANA
> operations staff didn't know (and, in the future, may not know
> again) that "3des" is pronounced "triple-des." As such, it's
> possible for us to read the current example and wonder whether
> IANA is being told to replace any leading number in an identifier
> with a multiplicative.
> 
> thanks,
> Amanda


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

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

[netmod] Re: Regarding draft-ietf-netmod-rfc8407bis

2024-09-04 Thread mohamed . boucadair

Re-,

Please see inline.

Cheers,
Med

De : Kent Watsen 
Envoyé : mercredi 4 septembre 2024 15:29
À : BOUCADAIR Mohamed INNOV/NET ; Amanda Baber 

Cc : netmod@ietf.org; Amanda Baber via RT 
Objet : Re: [netmod] Regarding draft-ietf-netmod-rfc8407bis

Hi Amanda,

 Please find one comment for you below.

Hi Med,

 Please see below for replies to other comments.

Kent



On Sep 4, 2024, at 8:12 AM, 
mohamed.boucad...@orange.com wrote:

Hi Kent, all,
(apologies for the delay to follow-up as I was out of office)

Please see inline.

Cheers,
Med

De : Kent Watsen mailto:kent+i...@watsen.net>>
Envoyé : dimanche 11 août 2024 20:48
À : netmod@ietf.org
Objet : [netmod] Regarding draft-ietf-netmod-rfc8407bis


The minutes for the NETMOD 120 session [0] captures this dialog:

 Tim Carey: What is the update for the best practices document and
 node-tags document

 Lou Berger: Best practices - I do not recall and will have to come 
back.


The update follows, in the form of the history/state of the current WGLC.


1) The chairs started the WGLC on the May 6 [1].  At this time, the document 
was at version -11.

2) Due to receiving no responses, the chairs extended the WGLC on June 3 [2] 
(still -11) and requested a YangDoctor review.  Two responses were received, 
both by the authors.

3) Xufeng provided a YangDoctors review on June 18 [3].  There was an exchange 
and then -12 was published on June 21.

4) Amanda Baber from IANA posted some concerns on June 26 [4], and -13 was 
published on July 3.  FWIW, I do not find a response from Amanda about if the 
update is okay, but I can see that her comment about “3des -> triple-res” was 
not addressed.
[Med] For “3des -> triple-des” comment, I clarified in my reply to Amanda that 
this is an example + instructions about how to spell out those are supposed to 
be supplied by authors of iana-maintained modules per the following:

  -  If the name in the IANA registry does not comply with the
 naming conventions listed in Section 4.3.1, the procedure MUST
 detail how IANA can generate legal identifiers from such a
 name.

For the specific example, triple is used instead of three to follow, for 
example, this part from RFC4253:

   The "3des-cbc" cipher is three-key triple-DES (encrypt-decrypt-
   encrypt), where the first 8 bytes of the key are used for the first
   encryption, the next 8 bytes for the decryption, and the following 8
bytes for the final encryption.

Would be great to hear back from Amanda, though.

Amanda, please see [4] at bottom for context.



5) Xufeng and Med continue discussion, and -14 was published on July 5.

That’s it.  No other comments are in the mail archive.  The WGLC never closed.  
It is fair to say that few reviews were received after the extension on June 3.


As a contributor, looking at the current version I noticed the following 
issues, which I hope will be received as WGLC comments.  This is not a complete 
review, just some things I noticed jumping around diffs.

a) In Section 4.30.3, the examples are folded incorrectly (RFC 8792).  They use 
some (unsupported) mixed of the `\` or the `\\` strategies.

[Med] I fail to see these two mixed/used in the examples. Can you please help 
pointing to those? Thanks.

Following is just one example, there are others instances elsewhere.

The following snippet appears in 
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-14#section-4.30.3:

 START SNIPPET 
=== NOTE: '\' line wrapping per RFC 8792 

  revision 2023-11-27 {
description
  "Registered RR Type RESINFO 261.";
reference
  "https://www.iana.org/assignments/yang-parameters/iana-dns-\
   
class-rr-t...@2023-11-27.yang"
  }
 END SNIPPET 

OLD:
  "https://www.iana.org/assignments/yang-parameters/iana-dns-\
   
class-rr-t...@2023-11-27.yang”

NEW: (removing the whitespace on the 2nd line)
  "https://www.iana.org/assignments/yang-parameters/iana-dns-\
class-rr-t...@2023-11-27.yang"


There whitespace, added for formatting reasons

[Med] Aah, I see. The whitespaces were added by markdown as I’m using 
“include-fold” in the .md file. Anyway, with the PR below, 8792 folding is not 
used for these examples anymore.


 More than that, YANG modules can avoid folding, in many cases, by converting a 
long line into a sequence of line-terminated string concatenations.  I suggest 
trying this to eliminate the folding altogether.

[Med] OK. Please see: https://github.com/netmod-wg/rfc8407bis/pull/63/files

Looks right.
[Med] Thanks.


 b) In Section 4.30.3.1: the “reference” statement isn’t described like it is 
in Section 4.30.3.2.  Should i

[netmod] Re: Regarding draft-ietf-netmod-rfc8407bis

2024-09-04 Thread mohamed . boucadair

Hi Kent, all,
(apologies for the delay to follow-up as I was out of office)

Please see inline.

Cheers,
Med

De : Kent Watsen 
Envoyé : dimanche 11 août 2024 20:48
À : netmod@ietf.org
Objet : [netmod] Regarding draft-ietf-netmod-rfc8407bis


The minutes for the NETMOD 120 session [0] captures this dialog:

 Tim Carey: What is the update for the best practices document and
 node-tags document

 Lou Berger: Best practices - I do not recall and will have to come 
back.


The update follows, in the form of the history/state of the current WGLC.


1) The chairs started the WGLC on the May 6 [1].  At this time, the document 
was at version -11.

2) Due to receiving no responses, the chairs extended the WGLC on June 3 [2] 
(still -11) and requested a YangDoctor review.  Two responses were received, 
both by the authors.

3) Xufeng provided a YangDoctors review on June 18 [3].  There was an exchange 
and then -12 was published on June 21.

4) Amanda Baber from IANA posted some concerns on June 26 [4], and -13 was 
published on July 3.  FWIW, I do not find a response from Amanda about if the 
update is okay, but I can see that her comment about "3des -> triple-res" was 
not addressed.
[Med] For "3des -> triple-des" comment, I clarified in my reply to Amanda that 
this is an example + instructions about how to spell out those are supposed to 
be supplied by authors of iana-maintained modules per the following:

  -  If the name in the IANA registry does not comply with the
 naming conventions listed in Section 4.3.1, the procedure MUST
 detail how IANA can generate legal identifiers from such a
 name.

For the specific example, triple is used instead of three to follow, for 
example, this part from RFC4253:

   The "3des-cbc" cipher is three-key triple-DES (encrypt-decrypt-
   encrypt), where the first 8 bytes of the key are used for the first
   encryption, the next 8 bytes for the decryption, and the following 8
bytes for the final encryption.

Would be great to hear back from Amanda, though.

5) Xufeng and Med continue discussion, and -14 was published on July 5.

That's it.  No other comments are in the mail archive.  The WGLC never closed.  
It is fair to say that few reviews were received after the extension on June 3.


As a contributor, looking at the current version I noticed the following 
issues, which I hope will be received as WGLC comments.  This is not a complete 
review, just some things I noticed jumping around diffs.

a) In Section 4.30.3, the examples are folded incorrectly (RFC 8792).  They use 
some (unsupported) mixed of the `\` or the `\\` strategies.

[Med] I fail to see these two mixed/used in the examples. Can you please help 
pointing to those? Thanks.

 More than that, YANG modules can avoid folding, in many cases, by converting a 
long line into a sequence of line-terminated string concatenations.  I suggest 
trying this to eliminate the folding altogether.

[Med] OK. Please see: https://github.com/netmod-wg/rfc8407bis/pull/63/files

b) In Section 4.30.3.1: the "reference" statement isn't described like it is in 
Section 4.30.3.2.  Should it be?

[Med] I don't see any difference out there. Can you please point to the text 
you identified?

c) In Section 4.30.3.2: I still don't understand why we'd want the "reference" 
statement pointing to IANA_FOO_URL_With_REV.  For example, a module-reader 
would have to be in possession of the module in order to see this statement's 
value, so value of pointing someone to the module when they already have it 
doesn't make sense to me.

[Med] Your reasoning is fair for the current version, not previous (or future) 
revisions. When new revisions are made on top of old ones, having specific URLs 
is useful to access previous revisions, for whatever reason.

d) In both Appendix B and C: replace "the format is (year-month-day)" with "the 
format is (-MM-DD)"...or otherwise specify what is meant by 
"year-month-day"elsewhere?

[Med] The format "(year-month-day)" was inherited from 8407. I'm neutral on 
this. FWIW, a PR of this is available at: 
https://github.com/netmod-wg/rfc8407bis/pull/64/files.

As chair again, the consensus is unclear.  It would great if Amanda could reply 
to Med's update, and if my comments above could be addressed.

Also, would anyone in the WG like to be the Document Shepherd for this draft?   
Being a shepherd provides valuable insight to how the IETF process works.  It 
would be helpful to start the Shepherd Write-up process.


[0] https://datatracker.ietf.org/doc/minutes-120-netmod-202407222000/
[1] https://mailarchive.ietf.org/arch/msg/netmod/u5Vk7_DgeXAOuq4h02hROfTYQaU/
[2] https://mailarchive.ietf.org/arch/msg/netmod/G0ItnC5vaTXSAuh5XX-1p4mD7MA/
[3] https://mailarchive.ietf.org/arch/msg/netmod/Lto49pXDCpKdUdR-ISUrRFVWhBw/
[4] https://mailarchive.ietf.org/arch/msg/netmod/HC2ipQcCLN_QaGlDjhDvCz_P_OI/


Kent

[netmod] Re: Current document status updates

2024-07-17 Thread mohamed . boucadair

Hi James, all,

Here is a status update for these two I-Ds:


  *   draft-ietf-netmod-rfc8407bis
 *   Changes since IETF#119
*   WGLC based on -11
*   Addressed comments from IANA about maintenance instructions: added 
a new section to make these visible to IANA
*   Updates RFC 6020 to record current IANA practices for registering 
modules and their revisions
*   YANG doctor review: raised some nits that were fixed in latest 
version: fix an example, updated the guidance so that the "file name" after the 
 is mandatory, add a registration template to better insist that 
6020 should be used for IANA registration, not RFC 7950.
 *   Pending issues: None
 *   Next Step: Ready to be sent to IESG for Publication.


  *   draft-ietf-netmod-acl-extensions
 *   Changes since IETF#119
*   Passed WGLC
*   Minor edits to enhance readability and some fixes (references, 
etc.) to address comments from Lou (Doc Shepherd)
 *   Pending issues: None
 *   Next Step: Ready to be sent to IESG for Publication. Hope this will 
happen SOON

Cheers,
Med

De : James Cumming (Nokia) 
Envoyé : mercredi 17 juillet 2024 18:17
À : netmod@ietf.org
Objet : [netmod] Current document status updates

Good day all,

Would anyone who has a current (or expired) working group document that is not 
on the agenda for IETF 120 mind providing a short status update to the list 
please?

The current list is documents for the WG is available here: 
https://datatracker.ietf.org/group/netmod/documents/

Thank you in advance

James


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

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

[netmod] Re: Mail regarding draft-ietf-tvr-schedule-yang

2024-07-14 Thread mohamed . boucadair

Hi Yingzhen,

Thanks for the follow-up.

Please see inline.

Cheers,
Med

De : Yingzhen Qu
Envoyé : dimanche 14 juillet 2024 06:09
À : BOUCADAIR Mohamed INNOV/NET
Cc : draft-ietf-tvr-schedule-y...@ietf.org; t...@ietf.org; netmod@ietf.org;
draft-ietf-netmod-schedule-yang@ietf.org
Objet : Re: Mail regarding draft-ietf-tvr-schedule-yang

Hi Med,

Thanks for the review and comments.

* There is a disconnect between the types used in existing
topology/interface models and the TVR one.
Do you mean the model is not augmenting existing models? If so, that's done on
purpose so we don't create dependencies to existing models.

[Med] No, I meant that the type of some data nodes are not matching the types
used for similar nodes in existing models: e.g., if/name is a union in your
case while this is a string in 8343, your node-id is yang:dotted-quad in
ietf-tvr-node while it is a uri in 8345 (but you have it right in
ietf-tvr-topology), source-link-id is a string while this is a uri in 8345.
Some text to explain the rationale why you deviate from those is missing, IMO.
Also, the change of the type between modules in the same document raises the
question of correlation between these modules (e.g., node-id).

* Are there cases where the same schedule will be used by multiple
interfaces/nodes? If so, consider factorizing and only have a reference to that
same schedule rather that defining it for each interface/node.
Are you suggesting for example we define a list of schedules with IDs, then
under each interface/node use the IDs to reference the schedules? It's possible
there might be multiple interfaces using the same schedule, however the
attributes such as bandwidth may not be the same.

[Med] Profiling does not prevent overriding a value when needed.

The current design is simpler.

[Med] It is simpler but may not be optimal for storing and manipulating large
topology files. I’m not pushing for any direction here but simply checking if
you considered these aspects. You may refer to
https://mailarchive.ietf.org/arch/msg/opsawg/uqvSkt5w-spTkRJ0f-DzUDTwT0c/ for
an example where such considerations are problematic when not adequately
handled in the design. If you are confident that all is well set in your design
and that such issues are not applicable in your case, please say so in the
draft. Thanks.

Other editorial suggestions I will fix in the next version of the draft after
the datatracker opens.

Thanks,
Yingzhen

On Fri, Jul 12, 2024 at 3:00 AM
mailto:mohamed.boucad...@orange.com>> wrote:
Hi Authors, all,

As part of our effort to check that the NETMOD Common Schedule module
(draft-ietf-netmod-schedule-yang) common basis set for target uses, I reviewed
all the I-Ds that use draft-ietf-netmod-schedule-yang. The review also focuses
on whether the grouping are used as intended and if some of the existing
groupings makes sense for a specific context.

Great to see that the new revision uses the utc grouping that we created as an
outcome of the IETF#119 TVR discussion.

I didn’t flagged any major issue related to the use of the common structures.
The narrative text should be updated to redirect the readers to the common spec
for more details about the period/recurrence data nodes. That’s an easy to fix
thing.

One open question though, is whether you considered to graft the state grouping
to the TVR modules (e.g. track failure of triggered actions, invocation
counters, etc.).

The review below includes a more detailed list of open questions, but I’m
providing here main ones:

* There is a disconnect between the types used in existing
topology/interface models and the TVR one.
* Are there cases where the same schedule will be used by multiple
interfaces/nodes? If so, consider factorizing and only have a reference to that
same schedule rather that defining it for each interface/node.

FWIW, my detailed review of draft-ietf-tvr-schedule-yang can be found at:

* pdf:
https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2024/draft-ietf-tvr-schedule-yang-01-rev%20Med.pdf
* doc:
https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/2024/draft-ietf-tvr-schedule-yang-01-rev%20Med.doc

Cheers,
Med

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, use

[netmod] Re: I-D Action: draft-ietf-opsawg-ucl-acl-04.txt

2024-07-12 Thread mohamed . boucadair

Hi all,

draft-ietf-opsawg-ucl-acl was updated to align with structures that are defined 
in the netmod common module. The full changes since IETF#119 can be seen at:

Diff: 
https://author-tools.ietf.org/iddiff?url1=draft-ietf-opsawg-ucl-acl-03&url2=draft-ietf-opsawg-ucl-acl-05&difftype=--html

As discussed in IETF#119, we think that draft-ietf-opsawg-ucl-acl is ready for 
the WGLC. However, the call can wait till the common module is also WGLCed in 
netmod.

Till that happens, comments and reviews are more than welcome.

Thanks. 

Cheers,
Med

> -Message d'origine-
> De : internet-dra...@ietf.org 
> Envoyé : jeudi 6 juin 2024 19:28
> À : i-d-annou...@ietf.org
> Cc : ops...@ietf.org
> Objet : I-D Action: draft-ietf-opsawg-ucl-acl-04.txt
> 
> 
> Internet-Draft draft-ietf-opsawg-ucl-acl-04.txt is now available.
> It is a work item of the Operations and Management Area Working
> Group (OPSAWG) WG of the IETF.
> 
>Title:   A YANG Data Model and RADIUS Extension for Policy-
> based Network Access Control
>    Authors: Qiufang Ma
> Qin Wu
> Mohamed Boucadair
> Daniel King
>Name:draft-ietf-opsawg-ucl-acl-04.txt
>Pages:   38
>Dates:   2024-06-06
> 
> Abstract:
> 
>This document defines a YANG data model for policy-based
> network
>access control, which provides consistent and efficient
> enforcement
>of network access control policies based on group identity.
>Moreover, this document defines a mechanism to ease the
> maintenance
>of the mapping between a user group identifier and a set of
> IP/MAC
>addresses to enforce policy-based network access control.
> 
>In addition, the document defines a Remote Authentication
> Dial-in
>User Service (RADIUS) attribute that is used to communicate
> the user
>group identifier as part of identification and authorization
>information.
> 


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

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

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

[netmod] Mail regarding draft-ietf-tvr-schedule-yang

2024-07-12 Thread mohamed . boucadair

Hi Authors, all,

Great to see that the new revision uses the utc grouping that we created as an
outcome of the IETF#119 TVR discussion.

I didn't flagged any major issue related to the use of the common structures.
The narrative text should be updated to redirect the readers to the common spec
for more details about the period/recurrence data nodes. That's an easy to fix
thing.

One open question though, is whether you considered to graft the state grouping
to the TVR modules (e.g. track failure of triggered actions, invocation
counters, etc.).

The review below includes a more detailed list of open questions, but I'm
providing here main ones:

FWIW, my detailed review of draft-ietf-tvr-schedule-yang can be found at:

Cheers,
Med

Orange Restricted

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

[netmod] Review of draft-contreras-opsawg-scheduling-oam-tests

2024-07-12 Thread mohamed . boucadair

Hi Authors, all,

There are some issues (?) related to the mix use of both utc and grouping with
a time zone. Some clarification is needed. Also, the modules can benefit from
the state grouping as a scheduled OAM can failure for various reasons. Tracking
those is important for auditing objectives discussed in the spec.

The schedules are linked to tests but it is not clear how the result/outcome of
the actions required to be linked back to the tests themselves or schedules.

Some brainstorming is needed about how to bind a test characterization with a
schedule. The authors adequately tagged that issue, but not sure we need
imports here.

My detailed review of draft-contreras-opsawg-scheduling-oam-tests can be found
at:

* pdf:
https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2024/draft-contreras-opsawg-scheduling-oam-tests-02-rev%20Med.pdf
* doc:
https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/2024/draft-contreras-opsawg-scheduling-oam-tests-02-rev%20Med.doc

As a side note, I like the spirit and objectives of
draft-contreras-opsawg-scheduling-oam-tests.

Cheers,
Med

[netmod] Re: [IANA #1289473] Revision statements in IANA-maintained YANG modules

2024-06-27 Thread mohamed . boucadair

Hi Amanda, 

Thank you for the follow up.

A first candidate revised version to address your comments can be seen at: 
https://author-tools.ietf.org/api/iddiff?url_1=https://netmod-wg.github.io/rfc8407bis/draft-ietf-netmod-rfc8407bis.txt&url_2=https://netmod-wg.github.io/rfc8407bis/amanda-iana/draft-ietf-netmod-rfc8407bis.txt
 

Please see inline for more context.

Cheers,
Med

> -Message d'origine-
> De : Amanda Baber via RT 
> Envoyé : jeudi 27 juin 2024 03:34
> Cc : netmod@ietf.org; BOUCADAIR Mohamed INNOV/NET
> 
> Objet : [IANA #1289473] Revision statements in IANA-maintained
> YANG modules
> 
> 
> Hi Med,
> 
> Sorry about my lateness here.
> 
> Section 4.30.3 seems to be directed at both authors and IANA, but
> IANA usually doesn't look to implement information that isn't
> included in or pointed to by the IANA Considerations section. I'd
> like to ask that the IANA Considerations section include a sub-
> section that says something like this:

[Med] Sure. 

> 
> ==
> 
> IANA should refer to Section 4.30.3 for information necessary to
> populate revision statements and identity and enumeration [enum?]
> sub-statements in IANA-maintained modules. In particular, the
> following should be noted:
> 
> * When an underlying registration is deprecated or obsoleted, a
> corresponding 'status' sub-statement should be added to the
> identity or enumeration statement.
> 
> * When the registration doesn't refer to an RFC, the reference
> statement should point to the URL for the module itself. [If this
> is correct. I've included a question about this at the end of the
> email.]

[Med] For this one, I prefer we echo the exact guidance:

"The "reference" substatement points specifically to the published
module (i.e., IANA_FOO_URL_With_REV). It may also point to an
authoritative event triggering the update to the YANG module. In all
cases, this event is cited from the underlying IANA registry. If the
update is triggered by an RFC, that RFC must also be included in
the "reference" substatement."

> 
> In addition, when the module is published, IANA must add the
> following notes to the YANG Module Names registry and the
> underlying registry (if applicable), respectively:
> 
> * "New values must not be directly added to the "iana-foo" YANG
> module.  They must instead be added to the "foo" registry."
> 
> * "When this registry is modified, the YANG module "iana-foo"
> [IANA_FOO_URL] must be updated as defined in RFC ."
> 

[Med] OK

> ==
> 
> This would help us pull out the information we'll need to
> maintain a short internal help document. When we update a module,
> we create new statements by copying the structure of an existing
> statement, so all we really need to highlight here is information
> that it may not be possible to derive from the existing module
> (the fact that the "status" field exists, what to do when the
> registration doesn't refer to an RFC).
> 
> A big issue here is that IANA operations staff (as opposed to
> technical staff, or the VP) don't know the YANG language. We're
> all liberal arts majors who have at most taken some programming
> classes and a couple of networking classes at a community college
> or UCLA Extension. As such, the IANA-relevant information in this
> document has taken some time to pick out.
> 
> A few other issues:
> 
> Section 4.1, Module Naming Conventions: the document states that
> "All published module names MUST be unique. For a YANG module
> published in an RFC, this uniqueness is guaranteed by IANA." What
> does "guaranteed" mean here?

[Med] This is explained in these IANA considerations: 
https://datatracker.ietf.org/doc/html/rfc6020#section-14. Updated the text you 
quoted to refer to that section.

Per Section 4.27, rfc7950#section-11 naming rules for revised modules are to be 
followed, especially:

   Note that definitions contained in a module are available to be
   imported by any other module and are referenced in "import"
   statements via the module name.  Thus, a module name MUST NOT be
   changed.  Furthermore, the "namespace" statement MUST NOT be changed,
   since all XML elements are qualified by the namespace.


 IANA doesn't currently check for
> this. We would assume that the new module was a replacement for
> the existing one, and add it to the registry (without removing
> the existing one, because we've been instructed to leave all
> previous versions in the registry rather than replace them. It
> should probably be noted that that instruction hasn't been
> documented in an RFC). Should we check for that? If so, what
> would we look for?

[Med] Good point. The document states that all revisions are currently 
maintained by IANA, e.g.,

 All revisions of IETF and IANA published modules can be found
 at the YANG Parameters registry
 (https://www.iana.org/assignments/yang-parameters).

However, we don't have any formal text to convey the current IANA practice, 
which may be seen as breaking this part from 6020:

   All m

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

2024-06-25 Thread mohamed . boucadair

Hi all, 

The main changes in this version are:

* clarify the relationship with RFC 3231
* Reflect comments received during TVR session (related to UTC groupings)
* Enhance the narrative text
* Add a discussion how the model can be reused in the context of RFC 8413

We think that this version is stable enough to consider an early yangdoctors 
review.

Cheers,
Med

> -Message d'origine-
> De : internet-dra...@ietf.org 
> Envoyé : mardi 25 juin 2024 10:05
> À : i-d-annou...@ietf.org
> Cc : netmod@ietf.org
> Objet : I-D Action: draft-ietf-netmod-schedule-yang-02.txt
> 
> 
> Internet-Draft draft-ietf-netmod-schedule-yang-02.txt is now
> available. It is a work item of the Network Modeling (NETMOD) WG
> of the IETF.
> 
>Title:   A Common YANG Data Model for Scheduling
>Authors: Qiufang Ma
> Qin Wu
> Mohamed Boucadair
> Daniel King
>Name:draft-ietf-netmod-schedule-yang-02.txt
>Pages:   58
>Dates:   2024-06-25
> 
> Abstract:
> 
>This document defines a common schedule YANG module which is
> designed
>to be applicable for scheduling purposes such as event,
> policy,
>services, or resources based on date and time.  For the sake
> of
>better modularity, the module includes basic, intermediate,
> and
>advanced versions of recurrence related groupings. 


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

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

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

[netmod] Re: Yangdoctors last call review of draft-ietf-netmod-rfc8407bis-11

2024-06-21 Thread mohamed . boucadair

Hi Xufeng, 

FWIW, all the changes indicated in my reply are now implemented in 
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8407bis/12/.

Thanks again for your careful review.

Cheers,
Med

> -Message d'origine-
> De : BOUCADAIR Mohamed INNOV/NET
> Envoyé : mardi 18 juin 2024 09:04
> À : 'Xufeng Liu' ; yang-
> doct...@ietf.org
> Cc : draft-ietf-netmod-rfc8407bis@ietf.org; last-
> c...@ietf.org; netmod@ietf.org
> Objet : RE: Yangdoctors last call review of draft-ietf-netmod-
> rfc8407bis-11
> 
> Hi Xufeng,
> 
> Thank you for the review.
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > -Message d'origine-
> > De : Xufeng Liu via Datatracker  Envoyé :
> mardi 18
> > juin 2024 05:33 À : yang-doct...@ietf.org Cc :
> > draft-ietf-netmod-rfc8407bis@ietf.org; last- c...@ietf.org;
> > netmod@ietf.org Objet : Yangdoctors last call review of
> > draft-ietf-netmod-
> > rfc8407bis-11
> >
> >
> > Reviewer: Xufeng Liu
> > Review result: Ready with Nits
> >
> > 3.2. Code Components
> > The “file name” after the "" tag is something
> described
> > as “SHOULD” be included. If there is no such a “file name”, the
> tool
> > “rfcstrip”
> > will not extract the correct file. Should we consider making
> this
> > “file name” a “MUST”?
> 
> [Med] I tend to agree with you on this one.
> 
> >
> > 3.5.1. YANG Module Classification
> > In the section “Network model”, the term "Network model” is
> described
> > as “relevant protocols operating at the link and network
> layers”. Can
> > a network model be designed for other layers, such as OTN or
> MPLS?
> 
> [Med] Yes as far as it "describes a network-level abstraction (or
> a subset of aspects of a network infrastructure)". Please note
> that the text you quoted starts with "including", which does not
> exclude other network-level matters.
> 
> 
>  If so, such a description seems to
> > be too narrow.  RFC 8309 clarifies the “Service Model”, which
> is the
> > section before this one. Is there a definition of the “network
> model”
> > in RFC 8309?
> 
> [Med] No. However, this maps to "network configuration model"
> mentioned in the example illustrated in Figure 3 of RFC8309. This
> is mentioned in the text:
> 
>   This model corresponds to
>   the network configuration model discussed in [RFC8309].
> 
> RFC8969 does not mention "configuration" because a network model
> can be used for non-configuration purposes.
> 
> >
> > 3.8. IANA Considerations Section
> > The “YANG Module Names” registry is defined in RFC 6020, but
> not RFC
> > 7950. Many YANG module writers mistakenly used RFC 7950.
> > Should we consider bringing this up with special attention?
> 
> [Med] We do already have the following:
> 
> Section 3.8:
>Each normative YANG module MUST be registered in both the
> "IETF XML
>Registry" [RFC3688] [IANA-XML] and the "YANG Module Names"
> registry
>[RFC6020] [IANA-MOD-NAMES].
> 
> Appendix A:
>*  IANA Considerations section -- this section must always be
>   present.  For each module within the document, ensure that
> the
>   IANA Considerations section contains entries for the
> following
>   IANA registries:
> 
>   XML Namespace Registry:  Register the YANG module
> namespace.
> 
>   YANG Module Registry:  Register the YANG module name,
> prefix,
>  namespace, and RFC number, according to the rules
> specified in
>  [RFC6020].
> 
> We might further emphasis on this point by adding a registration
> template in Section 3.8. A PR to exercise this can be seen here:
> https://github.com/netmod-wg/rfc8407bis/pull/56/files.
> 
> >
> > 4.5. Conditional Statements
> > An example not preferred is given, but there is no preferred
> fix.
> > Would it be better to provide the proffered solution?
> >
> 
> [Med] Good point. Please see https://github.com/netmod-
> wg/rfc8407bis/pull/57/files


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

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

[netmod] Schedule Model: RFC 3231 Objects

2024-06-20 Thread mohamed . boucadair

Hi all,

Even if we are not defining data nodes,
https://netmod-wg.github.io/schedule-yang/draft-ietf-netmod-schedule-yang.html#name-relationship-to-the-disman-
includes an assessment about how 3231 objects can be mapped to the YANG model
parameters. The following one are not supported in the YANG comment model
because this actual use is not evident in a common model, redundant with other
information (client identity), depends on the actual actions, etc.

If you have a preference whether this should be supported + have better
understanding on how this can be useful in the common schedule model, please
let us discuss :-)

Thank you

Cheers,
Med

[netmod] Schedule Model: Your comments at IETF#119/TVR

2024-06-20 Thread mohamed . boucadair

Hi Erik,

At TVR@IETF119, you raised the following comment
(https://datatracker.ietf.org/doc/minutes-119-tvr-202403200300/):

==
Erik Kline: sldie 5, timezones makes everything worse. datetime start is
bad name. call it "utc start time". interval vs duration?

possibly going to be removed, working with schedule authors for specific
grouping for tvr

Erik Kline: If you want to recurr make the control system do it if want
to make truly simple. so remove that from model.
===

We updated the common module to address the comments about use explicit names
for utc groupings + clarify interval vs. duration). The changes can be seen at
https://netmod-wg.github.io/schedule-yang/draft-ietf-netmod-schedule-yang.html#name-the-recurrence-utc-grouping.
These changes will be inherited by the TVR spec.

I'm not sure to understand the last part of your comment above. I would
appreciate if you can clarify. Thanks.

Cheers,
Med

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

2024-06-19 Thread mohamed . boucadair

Hi Qiufang,

This version looks good to me. Thanks. 

Cheers,
Med

> -Message d'origine-
> De : maqiufang (A) 
> Envoyé : mardi 18 juin 2024 11:05
> À : BOUCADAIR Mohamed INNOV/NET ;
> Michal Vaško ; yang-doct...@ietf.org
> Cc : draft-ietf-netmod-system-config@ietf.org; last-
> c...@ietf.org; netmod@ietf.org
> Objet : RE: [netmod] Yangdoctors last call review of draft-ietf-
> netmod-system-config-06
> 
> 
> Thanks a lot Med. I have submitted a new version to incorporate
> your fixes. You might want to review it at
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> Fauthor-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-netmod-
> system-config-
> 08&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ca351ee76402d46
> a5674708dc8f75ec6a%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6
> 38542983866493391%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ
> QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Yp
> 5MD%2Bg%2F1S4323gKKNTvzvy18l9LdtgLG3f59L%2F%2Fbg0%3D&reserved=0.
> 
> Best Regards,
> Qiufang
> 
> -Original Message-
> From: mohamed.boucad...@orange.com
> [mailto:mohamed.boucad...@orange.com]
> Sent: Tuesday, June 18, 2024 3:30 PM
> To: maqiufang (A) ; Michal Vaško
> ; yang-doct...@ietf.org
> Cc: draft-ietf-netmod-system-config@ietf.org; last-
> c...@ietf.org; netmod@ietf.org
> Subject: RE: [netmod] Yangdoctors last call review of draft-ietf-
> netmod-system-config-06
> 
> Hi Qiufang,
> 
> Thanks for taking care of this.
> 
> I submitted right now a PR with some minor fixes (e.g., align
> with 8407bis reco):
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> Fgithub.com%2Fnetmod-wg%2Fsystem-
> config%2Fpull%2F38&data=05%7C02%7Cmohamed.boucadair%40orange.com%
> 7Ca351ee76402d46a5674708dc8f75ec6a%7C90c7a20af34b40bfbc48b9253b6f
> 5d20%7C0%7C0%7C638542983866502315%7CUnknown%7CTWFpbGZsb3d8eyJWIjo
> iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7
> C%7C%7C&sdata=hTUH7sYC7r3om%2Fug7NAHC0dWwQFomD3jOBiBSpG8BOQ%3D&re
> served=0
> 
> Other than that, this looks good to me.
> 
> Cheers,
> Med
> 
> > -Message d'origine-
> > De : maqiufang (A)  Envoyé : lundi 17
> juin 2024
> > 14:28 À : BOUCADAIR Mohamed INNOV/NET
> ;
> > Michal Vaško ; yang-doct...@ietf.org Cc :
> > draft-ietf-netmod-system-config@ietf.org; last-
> c...@ietf.org;
> > netmod@ietf.org Objet : RE: [netmod] Yangdoctors last call
> review of
> > draft-ietf-
> > netmod-system-config-06
> >
> >
> > Hi, Med and Michal,
> >
> > Thanks for your review, the authors have submitted a new
> version
> >
> (https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%
> > 2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-netmod-system-
> > config-
> >
> 07&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C1a59a213597040
> >
> 741c9708dc8ec8ee94%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6
> >
> 38542240852698598%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ
> >
> QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=am
> > rvfTAx%2Fh2IvNtkbpBjGC8gInnlriPP9bGfYYACvKQ%3D&reserved=0)  to
> resolve
> > the nits you raised below, together with some other updates
> received
> > from the WG. Please review the diff
> >
> (https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%
> > 2Fauthor-tools.ietf.org%2Fiddiff%3Furl1%3Ddraft-ietf-netmod-
> > system-config-06%26url2%3Ddraft-ietf-netmod-system-config-
> > 07%26difftype%3D--
> >
> html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C1a59a2135970
> >
> 40741c9708dc8ec8ee94%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7
> >
> C638542240852716505%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL
> >
> CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=
> > 8N0szV%2FeKhtq3zkood1OXjcfl1uwBL1wbdO1%2FVSAq1o%3D&reserved=0)
> > and let us know if you have further comments. Thanks a lot!
> >
> > Best Regards,
> > Qiufang
> >
> > -Original Message-
> > From: mohamed.boucad...@orange.com
> > [mailto:mohamed.boucad...@orange.com]
> > Sent: Thursday, June 13, 2024 7:25 PM
> > To: Michal Vaško ; yang-doct...@ietf.org
> > Cc: draft-ietf-netmod-system-config@ietf.org; last-
> c...@ietf.org;
> > netmod@ietf.org
> > Subject: RE: [netmod] Yangdoctors last call review of draft-
> ietf-
> > netmod-system-config-06
> >
> > Hi all,
> >
> > On this one:
> >
> > > - all 'local-as' and 'peer-as' nodes are uint32, so in JSON
> > encoding
> > > numbers should be used instead of strings
> >
> > Even if this an example, the authors may consider using
> "inet:as-
> > number" rather than uint32.
> >
> > As I'm there,
> >
> > (1)
> >
> >  the name of this leaf is weird:
> >
> >leaf name {
> >  type inet:ip-address;
> >}
> >
> > I would change the name.
> >
> > (2) I would delete from the description of the ietf-system-
> datastore
> > module:
> >
> > The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
> > 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
> > 'NOT RECO

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

2024-06-18 Thread mohamed . boucadair

Hi Qiufang, 

Thanks for taking care of this. 

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

Other than that, this looks good to me.

Cheers,
Med

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

[netmod] Re: Yangdoctors last call review of draft-ietf-netmod-rfc8407bis-11

2024-06-18 Thread mohamed . boucadair

Hi Xufeng, 

Thank you for the review.

Please see inline. 

Cheers,
Med

> -Message d'origine-
> De : Xufeng Liu via Datatracker 
> Envoyé : mardi 18 juin 2024 05:33
> À : yang-doct...@ietf.org
> Cc : draft-ietf-netmod-rfc8407bis@ietf.org; last-
> c...@ietf.org; netmod@ietf.org
> Objet : Yangdoctors last call review of draft-ietf-netmod-
> rfc8407bis-11
> 
> 
> Reviewer: Xufeng Liu
> Review result: Ready with Nits
> 
> 3.2. Code Components
> The “file name” after the "" tag is something
> described as “SHOULD” be included. If there is no such a “file
> name”, the tool “rfcstrip”
> will not extract the correct file. Should we consider making this
> “file name” a “MUST”?

[Med] I tend to agree with you on this one.

> 
> 3.5.1. YANG Module Classification
> In the section “Network model”, the term "Network model” is
> described as “relevant protocols operating at the link and
> network layers”. Can a network model be designed for other
> layers, such as OTN or MPLS?

[Med] Yes as far as it "describes a network-level abstraction (or a subset of 
aspects of a network infrastructure)". Please note that the text you quoted 
starts with "including", which does not exclude other network-level matters.


 If so, such a description seems to
> be too narrow.  RFC 8309 clarifies the “Service Model”, which is
> the section before this one. Is there a definition of the
> “network model” in RFC 8309?

[Med] No. However, this maps to "network configuration model" mentioned in the 
example illustrated in Figure 3 of RFC8309. This is mentioned in the text: 

  This model corresponds to
  the network configuration model discussed in [RFC8309].

RFC8969 does not mention "configuration" because a network model can be used 
for non-configuration purposes.

> 
> 3.8. IANA Considerations Section
> The “YANG Module Names” registry is defined in RFC 6020, but not
> RFC 7950. Many YANG module writers mistakenly used RFC 7950.
> Should we consider bringing this up with special attention?

[Med] We do already have the following:

Section 3.8:
   Each normative YANG module MUST be registered in both the "IETF XML
   Registry" [RFC3688] [IANA-XML] and the "YANG Module Names" registry
   [RFC6020] [IANA-MOD-NAMES].

Appendix A:
   *  IANA Considerations section -- this section must always be
  present.  For each module within the document, ensure that the
  IANA Considerations section contains entries for the following
  IANA registries:

  XML Namespace Registry:  Register the YANG module namespace.

  YANG Module Registry:  Register the YANG module name, prefix,
 namespace, and RFC number, according to the rules specified in
 [RFC6020].

We might further emphasis on this point by adding a registration template in 
Section 3.8. A PR to exercise this can be seen here: 
https://github.com/netmod-wg/rfc8407bis/pull/56/files.

> 
> 4.5. Conditional Statements
> An example not preferred is given, but there is no preferred fix.
> Would it be better to provide the proffered solution?
> 

[Med] Good point. Please see 
https://github.com/netmod-wg/rfc8407bis/pull/57/files


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

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

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

2024-06-13 Thread mohamed . boucadair

Hi all,

On this one: 

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

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

As I'm there,

(1)

 the name of this leaf is weird:

   leaf name {
 type inet:ip-address;
   }

I would change the name. 

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

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

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

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

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

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

For example, 

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

Does not mention RESTCONF.

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

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

Hope this helps.

Cheers,
Med

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

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

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

[netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis

2024-06-03 Thread mohamed . boucadair

Hi Lou, all,

As authors were also invited to share their feedback, I will share my own.

I confirm that this version is ready to be sent to the IESG (modulo the point
below). The document benefited from good reviews dung its development with all
issues cleared as they show up. Many YANGDOTCORs were solicited individually
and their feedback recorded in the doc (see ACK section). SAAG was solicited to
review the security templates/cons [1].

The only pending point is with IANA: a list of requirements that it looks like
IANA needs to be aware of when updating IANA-maintained YANG modules [2]. Still
waiting for a follow-up on their side, though.

Cheers,
Med

[1] https://mailarchive.ietf.org/arch/msg/saag/z338jOL6mpYIIzT0Xk8ioCvi6v4/
[2] [netmod] Re: [IANA #1289473] Revision statements in IANA-maintained YANG
modules
(ietf.org)

De : Lou Berger
Envoyé : lundi 3 juin 2024 23:48
À : netmod@ietf.org
Objet : [netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis

WG, We (the chairs) remain hopeful that some might still comment on this
document, and are extending this WG LC To help the review, please see
https://author-tools.ietf.org/iddiff?url1=rfc8407&url2=draft-ietf-netmod-rfc8407bis-11&difftype=--html
Positive comments, e.g., "I've reviewed this document and believe it is ready
for publication", are welcome! This is useful and important, even from authors.
Thank you, Lou & Kent

On 5/6/2024 9:57 AM, Kent Watsen wrote:
This email begins a two-week WGLC on:

Guidelines for Authors and Reviewers of Documents Containing YANG
Data Models
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8407bis/

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

No IPR has been declared for this document:
https://mailarchive.ietf.org/arch/msg/netmod/1LDpkPi_C8cqktc7HXSZgyPDCBE/

Kent & Lou (as co-chairs)

___

netmod mailing list

netmod@ietf.org

https://www.ietf.org/mailman/listinfo/netmod

[netmod] Re: [IANA #1289473] Revision statements in IANA-maintained YANG modules

2024-05-30 Thread mohamed . boucadair

Hi Amanda, 

Any update about this point? Do you still think some change is needed? 

Thank you.

Cheers,
Med

> -Message d'origine-
> De : BOUCADAIR Mohamed INNOV/NET
> Envoyé : lundi 6 mai 2024 17:18
> À : 'iana-issues-comm...@iana.org' 
> Objet : RE: [IANA #1289473] Revision statements in IANA-
> maintained YANG modules
> 
> Hi Amanda,
> 
> Apologies for the delay to reply as I was out of office last
> week. I will also be unavailable most of this week as well.
> 
> We do have this section
> https://boucadair.github.io/rfc8407bis/draft-ietf-netmod-
> rfc8407bis.html#name-guidance-for-writing-the-ia with a set of
> instructions that are meant to feed the maintenance. However, I'm
> not sure if that is what you are looking for.
> 
> The only change I made so far can be tracked here:
> https://author-
> tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/rfc84
> 07bis/draft-ietf-netmod-
> rfc8407bis.txt&url_2=https://boucadair.github.io/rfc8407bis/maint
> enance-instructions/draft-ietf-netmod-rfc8407bis.txt
> 
> I can make more changes once I have a better understanding of the
> concern :-)
> 
> Thank you.
> 
> Cheers,
> Med
> 
> > -Message d'origine-
> > De : Amanda Baber via RT 
> Envoyé :
> > mercredi 1 mai 2024 03:19 Cc : BOUCADAIR Mohamed INNOV/NET
> >  Objet : [IANA #1289473] Revision
> > statements in IANA-maintained YANG modules
> >
> >
> > Hi Med,
> >
> > A note about draft-ietf-netmod-rfc8407bis:
> >
> > It's easy to find information about creating IANA-maintained
> modules,
> > but information about maintaining them isn't as easy to find. I
> wonder
> > if in addition to telling us what to register, the IANA
> Considerations
> > section might also list the points that IANA needs to take away
> from
> > the document (perhaps with pointers to the appropriate
> > section/subsections).
> >
> > thanks,
> > Amanda

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

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

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

2024-05-24 Thread mohamed . boucadair

Hi Lou,

Thank you for catching this.

Please check the candidate changes here: Diff: 
draft-ietf-netmod-acl-extensions-08.txt - 
draft-ietf-netmod-acl-extensions.txt

Let's know if any further change is needed.

Cheers,
Med

De : Lou Berger 
Envoyé : vendredi 24 mai 2024 14:51
À : BOUCADAIR Mohamed INNOV/NET ; 
draft-ietf-netmod-acl-extensi...@ietf.org
Cc : NetMod WG Chairs ; NETMOD Group 
Objet : Re: [netmod] Re: WG Last Call: draft-ietf-netmod-acl-extensions-06


Thank you Med/Authors!

As part of preparing my write up, I caught the following nit:

References for VLAN are missing in general, and I-SID are missing from the 
module.  I think it would be good add these. (See rfc8519 for an example VLAN 
description/reference.)

WG,

Please review the changes (see, wdiff draft-ietf-netmod-acl-extensions-06.txt 
draft-ietf-netmod-acl-extensions-08.txt)
 and send any comments you have.  We are NOT planning an additional WG last 
call prior to submission.

Thank you,

Lou

On 5/16/2024 8:08 AM, 
mohamed.boucad...@orange.com wrote:

Hi Lou,



Already shared on the list how -07 addresses the pending comments from Mahesh 
and Qiufang.



I think -08 is now ready for the next step. Thanks.



Cheers,

Med



-Message d'origine-

De : Lou Berger 

Envoyé : mardi 14 mai 2024 15:10

À : NETMOD Group 

Cc : NetMod WG Chairs 

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

extensions-06



Hi,



The WG poll has triggered some good comment.



Authors,



Please address all comments received and publish a new version.

Please also let the WG know how each comment is addressed.



Thank you,

Lou





On 4/29/2024 5:41 PM, Lou Berger wrote:

All,



This starts working group last call on



https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2

Fdata

tracker.ietf.org%2Fdoc%2Fdraft-ietf-netmod-acl-

extensions%2F&data=05%7



C02%7Cmohamed.boucadair%40orange.com%7C7c1f244274724a6ae86608dc74

1742a



d%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638512890449213291

%7CUn



known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I

k1haW



wiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=KqdX3A0iIOgsaznUd48b9W%2BWgh3

8ZcIu

Zvm5V6oSVSE%3D&reserved=0



The working group last call ends on May 13th.

Please send your comments to the working group mailing list.



Positive comments, e.g., "I've reviewed this document and

believe it

is ready for publication", are welcome!

This is useful and important, even from authors.



Thank you,

Lou (Co-Chair & doc Shepherd)







___

netmod mailing list -- netmod@ietf.org

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



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

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

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

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

Thank you.



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 emai

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

2024-05-16 Thread mohamed . boucadair

Hi Lou, 

Already shared on the list how -07 addresses the pending comments from Mahesh 
and Qiufang.

I think -08 is now ready for the next step. Thanks. 

Cheers,
Med

> -Message d'origine-
> De : Lou Berger 
> Envoyé : mardi 14 mai 2024 15:10
> À : NETMOD Group 
> Cc : NetMod WG Chairs 
> Objet : [netmod] Re: WG Last Call: draft-ietf-netmod-acl-
> extensions-06
> 
> Hi,
> 
> The WG poll has triggered some good comment.
> 
> Authors,
> 
> Please address all comments received and publish a new version.
> Please also let the WG know how each comment is addressed.
> 
> Thank you,
> Lou
> 
> 
> On 4/29/2024 5:41 PM, Lou Berger wrote:
> > All,
> >
> > This starts working group last call on
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> Fdata
> > tracker.ietf.org%2Fdoc%2Fdraft-ietf-netmod-acl-
> extensions%2F&data=05%7
> >
> C02%7Cmohamed.boucadair%40orange.com%7C7c1f244274724a6ae86608dc74
> 1742a
> >
> d%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638512890449213291
> %7CUn
> >
> known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I
> k1haW
> >
> wiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=KqdX3A0iIOgsaznUd48b9W%2BWgh3
> 8ZcIu
> > Zvm5V6oSVSE%3D&reserved=0
> >
> > The working group last call ends on May 13th.
> > Please send your comments to the working group mailing list.
> >
> > Positive comments, e.g., "I've reviewed this document and
> believe it
> > is ready for publication", are welcome!
> > This is useful and important, even from authors.
> >
> > Thank you,
> > Lou (Co-Chair & doc Shepherd)
> >
> >
> 
> ___
> netmod mailing list -- netmod@ietf.org
> To unsubscribe send an email to netmod-le...@ietf.org

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

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

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

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

2024-05-14 Thread mohamed . boucadair

Hi Qiufang, 

Thank you for the review. 

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

Cheers,
Med

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

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

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

[Med] No.

 Did I miss something?

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

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

[Med] ACK

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

[Med] ACK.

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

[Med] Good catches. Fixed.

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

[Med] ACK

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

[Med] ACK

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

[Med] Fixed.

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

[Med] Fixed, thanks.

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

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

2024-05-14 Thread mohamed . boucadair

Hi Mahesh, all,

https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-extensions/07/ has now 
the sets defined as reusable groupings + augment the ACL models. The structure 
is basically a revert back to what we used to have in -00.

Cheers,
Med

De : netmod  De la part de Mahesh Jethanandani
Envoyé : mardi 30 avril 2024 02:58
À : Lou Berger 
Cc : NETMOD Working Group ; NETMOD WG Chairs 

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



Hi Lou,

I have reviewed the document and believe it is ready for publication barring 
one comment and one clarification from Joe. I refer to this thread:

https://mailarchive.ietf.org/arch/msg/netmod/QrixYe6E4R9TFZ0O0S7eBaj4RyY/

In particular, this comment from that thread. What I wanted to add for 
clarification, is that I agree with Joe on defining a grouping for defined-sets 
that can then be used by other models. However, when it comes to the ACL 
extension model itself, I believe that defined-sets should be defined as an 
augmentation of the ACL model, and should not be defined as a standalone 
container sitting at the root of the config tree. See sample YANG code below.

I actually agree with your above statement in the Introduction that you had, 
about the module being solely an enhancement of the ACL YANG model, and was 
surprised to see it taken out. The point I was making was that just like what 
you have done with augmenting "/acl:acls/acl:acl/acl:aces/acl:ace/acl:matches” 
to add ‘choice payload’, ‘choice alias’ etc, you could have augmented 
“/acl:acls” to add ‘defined-sets’ and ‘aliases’.
Right now, as is, the ietf-acl-enh module sits on the root of the config tree, 
with no relation to the ACL model, other than references to it from within the 
ACL model. If the definitions in ietf-acl-enh are to be consumed by the ACL 
model only, why not augment the ACL model (as shown below) to add them in the 
ACL tree?

[Med] This is fair. Now that I managed to refresh the context in my mind I 
confirm that we have done that in a previous version of the spec, but the 
feedback we received from the WG was to move those upper in the hierarchy 
(because there might be other cases). See for example 
https://datatracker.ietf.org/doc/minutes-115-netmod-202211080930/"
 
rel="nofollow">https://datatracker.ietf.org/doc/minutes-115-netmod-202211080930/:

==
Joe Clarke: It would be nice in a standalone container (i.e. groupings that 
could be imported). I see some other use cases for these defined groupings 
besides just ACLs.
==

I know that routing policy uses defined-sets, but I believe they have already 
defined their own. Which other models do you foresee using these groupings 
(which I am now correcting to as ask, “… using this standalone container”?).




If that is the case I see no reason why those containers should not be 
augmentations into the same model, as in

augment “/acl:acls” {
  container defined-sets {
  ….
  }

  container aliases {
 …
  }
}



On Apr 29, 2024, at 2:41 PM, Lou Berger 
mailto:lber...@labn.net>> wrote:

All,

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

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

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

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


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


Mahesh Jethanandani
mjethanand...@gmail.com






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

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

Re: [netmod] IPR on call on draft-ietf-netmod-rfc8407bis-11

2024-05-05 Thread mohamed . boucadair

Hi Kent, all,

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

Cheers,
Med

> -Message d'origine-
> De : Kent Watsen 
> Envoyé : mardi 30 avril 2024 00:06
> À : BOUCADAIR Mohamed INNOV/NET ;
> Andy Bierman ; Qin Wu 
> Cc : netmod@ietf.org
> Objet : IPR on call on draft-ietf-netmod-rfc8407bis-11
> 
> 
> Authors, Contributors, WG,
> 
> As a prerequisite for the WGLC on this document:
> 
>   Guidelines for Authors and Reviewers of Documents Containing
> YANG Data Models
>   https://eur03.safelinks.protection.outlook.com/?url=https%3A
> %2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-netmod-
> rfc8407bis-
> 11&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C7066252b770840
> f3c50308dc6898d008%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6
> 38500252737823497%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ
> QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=w4
> prd4vgHS8gll%2BxpIzT2gOMwsVz2qVDsBF940HTMTw%3D&reserved=0
> 
>   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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> Fdatatracker.ietf.org%2Fipr%2Fsearch%2F%3Fsubmit%3Ddraft%26id%3Dd
> raft-ietf-netmod-
> rfc8407bis&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C706625
> 2b770840f3c50308dc6898d008%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0
> %7C0%7C638500252737832210%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
> wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&
> sdata=3RV8TMMRQ2DK9RNdL3YtKNJNoCPgWEOaQDVrS1GVZ68%3D&reserved=0
> 
> Thanks.
> 
> Lou and Kent  (WG Chairs)


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

Re: [netmod] AD review of draft-ietf-netmod-rfc6991-bis-15

2024-04-18 Thread mohamed . boucadair

Hi Jürgen, all,

With regards to draft-ietf-sedate-datetime-extended, we do have a related open 
issue about this at: 
https://github.com/boucadair/policy-based-network-acl/issues/74 for 
draft-ietf-netmod-schedule.

I think that it is better to handle this as part of the 6991-bis (rather than 
in a separate module). I would update the definition to align with the sedate 
ABNF.

Cheers,
Med

> -Message d'origine-
> De : netmod  De la part de Jürgen Schönwälder
> Envoyé : jeudi 18 avril 2024 15:06
> À : Mahesh Jethanandani 
> Cc : NETMOD Working Group 
> Objet : Re: [netmod] AD review of draft-ietf-netmod-rfc6991-bis-15
> 
> 
> On Tue, Apr 16, 2024 at 10:08:09AM -0700, Mahesh Jethanandani wrote:
> > Hi Jürgen,
> >
> > It appears that Brian and you had made progress on the other thread
> related to IPv6 zone definition. Are there any outstanding issues that
> need to be resolved?
> >
> > What is the plan to submit an updated version of the document?
> >
> 
> I had to take a fresh look at things and I think the discussion around
> zones of IP addresses is moving to a conclusion. That said, I believe
> we are not done with the work related to dates, times, and durations.
> What we have is not really good and also in conflict with newer work
> that came out of the sedate WG and has passed IESG approval (I think).
> Here is a not so short summary (I have even more details since I did
> take a look into what standard libraries of various system programming
> languages offer).
> 
> * date-and-time, date, time
> 
>   For time zones, we used to have the canonical format +00:00 for
>   systems in UTC located and a known timezone offset of 00:00. For
>   systems in UTC with an unknown timezone offset, the canonical format
>   has been -00:00. This was based on RFC 3339 which introduced the
>   -00:00 which is not strictly allowed by the ISO 8601 format.
> 
>   The sedate work is updating RFC 3339 recommending against the use of
>   the -00:00 notation (since it is not conforming to ISO 8601) and
>   instead suggests that Z is used for systems in UTC with an unknown
>   timezone offset.
> 
>   The question is now how we deal with this non-backwards compatible
>   change of RFC 3339 that apparently got approved by the IESG and
>   hence there is believe that the Internet won't break based on the
>   argument that using Z instead of -00:00 is already common practice.
>   If so, do we simply align our definition with the updated version of
>   RFC 3339?  Or do we go an deprecate date-and-time and create a new
>   definition (and then we deal with the updates of all affected
>   modules over time)?
> 
>   Note that this also affects the newly defined zoned types date and
>   time.
> 
>   Looking forward, we may even want to consider supporting formats
>   that allow for timezone names instead of only static numeric
>   offsets. So another option might be to leave date-and-time as is
>   (potentially deprecating it once there is a better replacement) and
>   to start a new module, say ietf-chrono, that defines new date and
>   time related types that are aligned with the updated RFC 3339 and
>   the work done by the sedate working group to enable the use of time
>   zone names.
> 
> * nanoseconds, microseconds, milliseconds, seconds, minutes, hours
> 
>   There was some discussion around the choice of signed vs unsigned
>   base types and the choice between 32 and 64 bits. I have
>   investigated a bit what standard libraries of system programming
>   languages do and I concluded that using signed integer types
>   dominates and that we should use 64-bit types for everything up
>   to and including seconds (and not offer 32-bit alternatives).
> 
>   It is easy to range restrict to just positive numbers and it is
>   also easy to range restrict to use less than 64 bits.
> 
>   If we would start a new module for date and time types, then these
>   definitions should likely be moved there as well.
> 
> I believe to have proper types for data and time and durations, it is
> best to factor this work out into a separate effort. This gives us
> more freedom to do things right without any harm on backwards
> compatibility (we would not change date-and-time, except perhaps
> adding a warning note that use of -00:00 is getting discouraged).
> 
> /js
> 
> --
> Jürgen Schönwälder  Constructor University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fnetmod&data=05%7C02%7Cmohamed.boucadai
> r%40orange.com%7Cf6a1137e0ba34522105f08dc5fa85411%7C90c7a20af34b40bfbc
> 48b9253b6f5d20%7C0%7C0%7C638490423774715463%7CUnknown%7CTWFpbGZsb3d8ey
> JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7
> C%7C%7C&sdata=HBu%2Bm9zCbDl%2Bo%2Fy%2B%2Bno7nhVn%2FcTMofvz%2B2b%2FHyEm
> E1s%3

Re: [netmod] [saag] draft-ietf-netmod-rfc8407bis: YANG Security Template

2024-04-18 Thread mohamed . boucadair

Hi all, 

FWIW, we made some changes to the security considerations [1] since your last 
review. For convenience the changes to the template can be tracked at [2].

Please let us know if you have any comment about the updated guidance.

Thank you.

Cheers,
Med

[1] 
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-11#name-security-considerations-sec

[2] 
https://author-tools.ietf.org/diff?url_1=https://raw.githubusercontent.com/boucadair/rfc8407bis/main/templates/pre-04-sec-template.txt&url_2=https://raw.githubusercontent.com/boucadair/rfc8407bis/main/templates/sec-template.txt

> -Message d'origine-
> De : Michael Richardson 
> Envoyé : dimanche 26 novembre 2023 16:18
> À : BOUCADAIR Mohamed INNOV/NET ;
> s...@ietf.org; Qin Wu (bill...@huawei.com) 
> Objet : Re: [saag] draft-ietf-netmod-rfc8407bis: YANG Security
> Template
> 
> 
> mohamed.boucad...@orange.com wrote:
> > The Security template used in documents that specify YANG
> modules is
> > stable since years now. FYI, we are in the process of preparing
> > RFC8407bis, so we would welcome comments on that part:
> > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-
> rfc8407bis-04#name-security-considerations-sec
> 
> I see the exception for documents that are based upon RFC8791.
> I think it's probably enough, but maybe I'd move that paragraph
> earlier.
> 
> 
> --
> Michael Richardson , Sandelman Software Works
>  -= IPv6 IoT consulting =-  *I*LIKE*TRAINS*
> 
> 

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

Re: [netmod] On prefixes again RE: IETF#119 I-D Status: draft-ietf-netmod-rfc8407bis

2024-04-15 Thread mohamed . boucadair

Hi all,

These proposed changes are now implemented in the public version.

Cheers,
Med

De : BOUCADAIR Mohamed INNOV/NET
Envoyé : mercredi 20 mars 2024 23:13
À : netmod@ietf.org
Objet : RE: [netmod] On prefixes again RE: IETF#119 I-D Status: 
draft-ietf-netmod-rfc8407bis

Hi all,

After reviewing all the feedback so far, I modified the proposed change as 
follows:

NEW:
   Prefix values SHOULD be short but meaningful to the intended user.
   Prefix values SHOULD NOT conflict with known modules that have been
   previously published.

The full change can be seen here: 
https://author-tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/rfc8407bis/draft-ietf-netmod-rfc8407bis.txt&url_2=https://boucadair.github.io/rfc8407bis/prefix-pattern/draft-ietf-netmod-rfc8407bis.txt.

Cheers,
Med

De : netmod mailto:netmod-boun...@ietf.org>> De la 
part de Andy Bierman
Envoyé : dimanche 17 mars 2024 03:52
À : Christian Hopps mailto:cho...@chopps.org>>
Cc : Jürgen Schönwälder 
mailto:jschoenwaelder@constructor.university>>;
 netmod@ietf.org
Objet : Re: [netmod] On prefixes again RE: IETF#119 I-D Status: 
draft-ietf-netmod-rfc8407bis

On Sat, Mar 16, 2024 at 2:41 AM Christian Hopps 
mailto:cho...@chopps.org>> wrote:

> On Mar 15, 2024, at 19:13, Per Andersson (perander) 
> mailto:peran...@cisco.com>> wrote:
>
> Christian Hopps mailto:cho...@chopps.org>> on Friday, 
> March 15, 2024 20:10:
>>> On Mar 15, 2024, at 13:26, 
>>> mohamed.boucad...@orange.com wrote:
>>>
>>> Re-,
>>> I’m not sure to agree with your last statement, Andy.
>>> The reality is that the OLD reco is inducing many cycles and waste of time 
>>> for no obvious technical reason:  see an example 
>>> herehttps://mailarchive.ietf.org/arch/msg/teas/eknpfAZIb9gX7GvUN1UoByCf5e4/
>>> Let’s save the authors time with a clear guidance:
>>>• Pick ietf- or iana- as a function of the module
>>
>> I disagree with this guidance.
>
> Can you explain your motivation?

Well first, what has been state earlier in the thread. But basically they add 
almost no value and gratuitously extend what is supposed to be a short 
identifier.

I am sorry for bringing this up.

I just grep'ed through about 1000 YANG modules to do a guestimate of the prefix 
usage,
looking for "meaningful" prefixes.

It is not that consistent across SDOs. IMO BBF is the best (by far).
The IETF has the most 2-letter prefixes.
DOTS and TE have structured prefixes (about 7 - 12 chars).
IMO these are good examples for new YANG modules.

The most important property is that the prefix is meaningful.

Thanks,
Chris.

Andy

>
>
> --
> Per

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

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

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

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

2024-03-26 Thread mohamed . boucadair

Hi all, 

I support this work, obviously. 

Cheers,
Med

> -Message d'origine-
> De : netmod  De la part de Kent Watsen
> Envoyé : mardi 26 mars 2024 16:50
> À : netmod@ietf.org
> Objet : [netmod] Adoption call for draft-ma-opsawg-schedule-yang-04
> 
> NETMOD WG,
> 
> This email begins a 2-week adoption poll for:
> 
>   A Common YANG Data Model for Scheduling
>   https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> Fdatatracker.ietf.org%2Fdoc%2Fdraft-ma-opsawg-schedule-
> yang&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cf26255e048cd4ba2f
> 6b208dc4dac7680%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638470650
> 338127416%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi
> LCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=qk9Ay4%2BeGE%2FGNHx7
> LirV%2BKn9rzpGAW9PqD3Q0ti54nk%3D&reserved=0
> 
>   PS: This draft moved from OPSAWG to NETMOD
> 
> There is no known IPR on this draft:
> 
>   https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> Fmailarchive.ietf.org%2Farch%2Fmsg%2Fnetmod%2Fmg1KP3m6bCSXh-3N-
> YKLvEb_udk%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cf26255e0
> 48cd4ba2f6b208dc4dac7680%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C
> 638470650338137041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo
> iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=E2iJX0w3cCH
> 4yq6j1gcnYZA4kqbCxAaC420mxd0PBrU%3D&reserved=0
> 
> 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fnetmod&data=05%7C02%7Cmohamed.boucadai
> r%40orange.com%7Cf26255e048cd4ba2f6b208dc4dac7680%7C90c7a20af34b40bfbc
> 48b9253b6f5d20%7C0%7C0%7C638470650338145053%7CUnknown%7CTWFpbGZsb3d8ey
> JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7
> C%7C%7C&sdata=X6QGHzu4XIvqWUbsOf9pIxHNO7G5aAWTTXdCRU%2B6cKw%3D&reserve
> d=0

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

This message and its attachments 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

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

2024-03-25 Thread mohamed . boucadair

Hi Kent, all,

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

Cheers,
Med

De : Kent Watsen 
Envoyé : mardi 26 mars 2024 00:45
À : maqiufang (A) ; Qin Wu ; 
BOUCADAIR Mohamed INNOV/NET ; Daniel King 

Cc : netmod@ietf.org
Objet : IPR Call on draft-ma-opsawg-schedule-yang-04

[This draft moved from OPSAWG to NETMOD]


Authors, Contributors, WG,

As a prerequisite for the adoption on this document:

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

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

Please state either:

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

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

If yes to the above, please state either:

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

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

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

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

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


Thanks.
Kent Watsen (as co-chair)


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

Re: [netmod] Regrading IPR for draft-ietf-netmod-acl-extensions-06

2024-03-25 Thread mohamed . boucadair

Hi Lou, all, 

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

Cheers,
Med

> -Message d'origine-
> De : Lou Berger 
> Envoyé : lundi 25 mars 2024 23:00
> À : BOUCADAIR Mohamed INNOV/NET ;
> samier.barguilgiraldo@telefonica.com; OSCAR GONZALEZ DE DIOS
> ; Qin Wu 
> Cc : NETMOD Group ; NetMod WG Chairs  cha...@ietf.org>
> Objet : Regrading IPR for draft-ietf-netmod-acl-extensions-06
> 
> Due to the content change between the last poll on -03 and the current
> rev:
> 
> Authors, Contributors, WG,
> 
> As part of the renewed WG Last 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.
> 
> NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES.
> 
> 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
> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftrac.
> tools.ietf.org%2Fgroup%2Fiesg%2Ftrac%2Fwiki%2FIntellectualProperty&dat
> a=05%7C02%7Cmohamed.boucadair%40orange.com%7C59d3d0413da045813dcf08dc4
> d16e2c0%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63847000789050520
> 7%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6
> Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=odoc%2BvNyPN01me0sJGLlyOsaOK
> pxAG4tJmQ7tJvyCJQ%3D&reserved=0.
> 
> Thank you,
> Lou (Co-Chair & doc Shepherd)
> 
> PS Please include all listed in the headers of this message in your
> response.
> 
> 


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

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

2024-03-21 Thread mohamed . boucadair

Hi all,

FWIW, the proposed changes to address the point mentioned by Mahesh [1] can be 
seen at: description text by boucadair · Pull Request #51 · 
boucadair/rfc8407bis 
(github.com)

For convenience, the changes can be tracked here: Diff: 
draft-ietf-netmod-rfc8407bis.txt - 
draft-ietf-netmod-rfc8407bis.txt

Only the template is updated because we do already have the following:

==
Concretely, the IANA Considerations Section SHALL at least
   provide the following information:

   *  ...

   *  An instruction about how to generate the "revision" statement.
==

Cheers,
Med

[1] refer to [yang-doctors] [IANA #1289473] Revision statements in 
IANA-maintained YANG modules 
(ietf.org)
 for more context.

De : Mahesh Jethanandani 
Envoyé : mercredi 13 mars 2024 03:51
À : BOUCADAIR Mohamed INNOV/NET 
Cc : netmod@ietf.org
Objet : Re: [netmod] IETF#119 I-D Status: draft-ietf-netmod-rfc8407bis

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






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

Re: [netmod] On prefixes again RE: IETF#119 I-D Status: draft-ietf-netmod-rfc8407bis

2024-03-20 Thread mohamed . boucadair

Hi all,

After reviewing all the feedback so far, I modified the proposed change as 
follows:

NEW:
   Prefix values SHOULD be short but meaningful to the intended user.
   Prefix values SHOULD NOT conflict with known modules that have been
   previously published.

The full change can be seen here: 
https://author-tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/rfc8407bis/draft-ietf-netmod-rfc8407bis.txt&url_2=https://boucadair.github.io/rfc8407bis/prefix-pattern/draft-ietf-netmod-rfc8407bis.txt.

Cheers,
Med

De : netmod  De la part de Andy Bierman
Envoyé : dimanche 17 mars 2024 03:52
À : Christian Hopps 
Cc : Jürgen Schönwälder ; netmod@ietf.org
Objet : Re: [netmod] On prefixes again RE: IETF#119 I-D Status: 
draft-ietf-netmod-rfc8407bis

On Sat, Mar 16, 2024 at 2:41 AM Christian Hopps 
mailto:cho...@chopps.org>> wrote:

> On Mar 15, 2024, at 19:13, Per Andersson (perander) 
> mailto:peran...@cisco.com>> wrote:
>
> Christian Hopps mailto:cho...@chopps.org>> on Friday, 
> March 15, 2024 20:10:
>>> On Mar 15, 2024, at 13:26, 
>>> mohamed.boucad...@orange.com wrote:
>>>
>>> Re-,
>>> I’m not sure to agree with your last statement, Andy.
>>> The reality is that the OLD reco is inducing many cycles and waste of time 
>>> for no obvious technical reason:  see an example 
>>> herehttps://mailarchive.ietf.org/arch/msg/teas/eknpfAZIb9gX7GvUN1UoByCf5e4/
>>> Let’s save the authors time with a clear guidance:
>>>• Pick ietf- or iana- as a function of the module
>>
>> I disagree with this guidance.
>
> Can you explain your motivation?

Well first, what has been state earlier in the thread. But basically they add 
almost no value and gratuitously extend what is supposed to be a short 
identifier.

I am sorry for bringing this up.

I just grep'ed through about 1000 YANG modules to do a guestimate of the prefix 
usage,
looking for "meaningful" prefixes.

It is not that consistent across SDOs. IMO BBF is the best (by far).
The IETF has the most 2-letter prefixes.
DOTS and TE have structured prefixes (about 7 - 12 chars).
IMO these are good examples for new YANG modules.

The most important property is that the prefix is meaningful.

Thanks,
Chris.

Andy

>
>
> --
> Per

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

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

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

Re: [netmod] On prefixes again RE: IETF#119 I-D Status: draft-ietf-netmod-rfc8407bis

2024-03-15 Thread mohamed . boucadair

Re-,

I’m not sure to agree with your last statement, Andy.

The reality is that the OLD reco is inducing many cycles and waste of time for 
no obvious technical reason:  see an example here 
https://mailarchive.ietf.org/arch/msg/teas/eknpfAZIb9gX7GvUN1UoByCf5e4/

Let’s save the authors time with a clear guidance:

  *   Pick ietf- or iana- as a function of the module
  *   Use something meaningful, but preferably not too long

Cheers,
Med

De : Andy Bierman 
Envoyé : vendredi 15 mars 2024 18:01
À : Jürgen Schönwälder ; Andy Bierman 
; BOUCADAIR Mohamed INNOV/NET 
; netmod@ietf.org
Objet : Re: [netmod] On prefixes again RE: IETF#119 I-D Status: 
draft-ietf-netmod-rfc8407bis

On Fri, Mar 15, 2024 at 9:42 AM Jürgen Schönwälder 
mailto:jschoenwaelder@constructor.university>>
 wrote:
Yes, for long XPath expressions, one likes to have short prefixes, the
shorter the better. In other contexts, such as type definitions, one
may want to use longer prefixes providing more context. It seems you
can't have both at the same time. Given this inherent conflict, I am
not sure that generally pushing for longer prefixes is a good thing.

For modules with long XPath expressions, an author may consider to go
for one character local prefixes even if they require to lookup their
meaning in the imports (or people have modern editors that can
dynamically show an expansion) because mutli-line XPath expressions
with lots of repetitive substrings are pretty bad for human eyes.

Short is OK if the prefix is familiar to the reader. Like "if".
What if the writer wanted a, b, c, d, etc? Shortt but not meaningful.
It is a judgment call every time, too complex for a guideline.

The guideline only mentions short so the prefix will not conflict and the 
import-stmt in
other modules will not need a different prefix.  This is only for reader 
familiarity, since the
YANG compiler does not care which prefix is used.

The naming convention already established is that the SDO prefix (ietf or iana) 
is not used.
It would not help readers to change it now.

/js

Andy

On Fri, Mar 15, 2024 at 08:22:03AM -0700, Andy Bierman wrote:
> On Fri, Mar 15, 2024 at 7:24 AM Jürgen Schönwälder
> mailto:jschoenwaelder@constructor.university>>
>  wrote:
>
> > I wonder which problem we are solving with adding more little rules.
> > Perhaps a future version of YANG will do away with prefixes but until
> > this happens, I do not think we need to add more rules about how to
> > choose prefixes. The original intend was that they are short to keep
> > YANG snippets concise and easy to read.
> >
> >
>
> This is the IETF Coding Conventions document, not the YANG specification.
> Naming conventions are CLRs but often with some benefits.
>
> What problems?
>
> 1) If there are multiple modules used in imports then the reader must be
> able to
> easily tell the prefixes apart.  If prefixes are too short and not
> meaningful, this task
> gets more difficult.  I find myself constantly going back to the imports to
> make sure
> I am matching the prefix to the correct module.
>
> 2) If there are complex XPath expressions then prefixes that are too long
> make the
> expression unreadable, especially as it is chopped into "string" +
> "string"  format
> to fit into 72 character lines. If prefixes are too short then back to
> problem (1).
>
> 3)  It is becoming more common to have vendor modules import modules from
> multiple SDOs.
> Prefix naming conventions are already the BCP everywhere but the IETF.
>
> Is it too late to start for IETF? There are many modules already with no
> naming consistency,
> so this would only affect new modules. There will never be consistent
> naming of prefixes
> so it may not be worth the change now.
>
>
>
> /js
> >
>
>

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

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/ne

Re: [netmod] On prefixes again RE: IETF#119 I-D Status: draft-ietf-netmod-rfc8407bis

2024-03-15 Thread mohamed . boucadair

Chris, 

> Right.. I don't understand the need for uniqueness even, since one
> specifies a prefix when importing other modules.

When importing, one should follow this part from 7550:

   To
   improve readability of YANG modules, the prefix defined by a module
   SHOULD be used when the module is imported, unless there is a
   conflict.  If there is a conflict, i.e., two different modules that
   both have defined the same prefix are imported, at least one of them
   MUST be imported with a different prefix.

Use a consistent pattern + assign a prefix which not conflicting with assigned 
ones is consistent with the first SHOULD (and improve readability argument).

Cheers,
Med

> -Message d'origine-
> De : Christian Hopps 
> Envoyé : vendredi 15 mars 2024 16:55
> À : Jürgen Schönwälder 
> Cc : BOUCADAIR Mohamed INNOV/NET ;
> netmod@ietf.org
> Objet : Re: [netmod] On prefixes again RE: IETF#119 I-D Status: draft-
> ietf-netmod-rfc8407bis
> 
> 
> Jürgen Schönwälder  writes:
> 
> > I wonder which problem we are solving with adding more little rules.
> > Perhaps a future version of YANG will do away with prefixes but
> until
> > this happens, I do not think we need to add more rules about how to
> > choose prefixes. The original intend was that they are short to keep
> > YANG snippets concise and easy to read.
> 
> Right.. I don't understand the need for uniqueness even, since one
> specifies a prefix when importing other modules. I'd definitely vote
> for not requiring standard prefix prefixes like "ietf-".
> 
> Thanks,
> Chris
> 
> > /js
> >
> > On Fri, Mar 15, 2024 at 01:02:58PM +,
> mohamed.boucad...@orange.com wrote:
> >> Hi Andy,
> >>
> >> (changing the subject to ease tracking this)
> >>
> >> The thread I was referring is:
> >> https://mailarchive.ietf.org/arch/msg/netmod/6VkSrroaxwXHSI19Jj0j-
> tbF
> >> CjA/
> >>
> >> I do personally think that it is a good guidance to prefix IETF
> modules with “ietf-“ and IANA-maintained ones with “iana-‘. This is
> consistent with the practice we followed recently for iana-maintained
> modules.
> >>
> >> If we recommend this prefix pattern, I’m afraid that we need to
> >> revisit the text about short prefixes, e.g.,
> >>
> >> 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 prefixed with “ietf-“ for IETF modules
> and
> >>“iana-“ for IANA-maintained modules. Prefix values SHOULD NOT be
> >>too long and SHOULD NOT conflict with known modules that have
> been
> >>previously published.
> >>
> >> Cheers,
> >> Med
> >>
> >> De : Andy Bierman  Envoyé : jeudi 14 mars 2024
> >> 22:53 À : Mahesh Jethanandani  Cc :
> >> BOUCADAIR Mohamed INNOV/NET ;
> >> netmod@ietf.org Objet : Re: [netmod] IETF#119 I-D Status:
> >> draft-ietf-netmod-rfc8407bis
> >>
> >> Hi,
> >>
> >> I cannot find this email wrt/ short prefixes
> >>
> >>
> >>   *   (short/uniqueness of prefixes
> >>
> >> Other SDOs are using a prefix in their prefixes (e.g. openconfig).
> >> It is common for servers to have both "if:interfaces" and "oc-
> if:interfaces" subtrees.
> >>
> >> It might be a good idea to have a guideline that all IETF YANG
> >> modules SHOULD use the "ietf-" string in the module prefix.  This
> >> should reduce the chance of name collisions between SDOs and
> vendors, and helps identify the module as an IETF module.
> >>
> >>
> >> Andy
> >>
> >>
> >>
> >> On Tue, Mar 12, 2024 at 10:51 AM Mahesh Jethanandani
> mailto:mjethanand...@gmail.com>> wrote:
> >> 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 netmod-rfc8407bis.diff>
> >>
> >>   *   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
> >>
> >>
> _
> >> ___

Re: [netmod] On prefixes again RE: IETF#119 I-D Status: draft-ietf-netmod-rfc8407bis

2024-03-15 Thread mohamed . boucadair

Hi Jürgen,

I agree this is marginal, but the proposed change is mainly to ensure some 
consistency and to some extend avoid collision with other SDOs. In the 
meantime, the initial reco is not technically justified :-) 

Please note that the initial reco is not always followed in practice: for 
example, we do have in the registry:

* ietf-mud, while mud is available 
* ietf-acldns while acldns whould be OK
* ietf-syslog while syslog would be 
* packet-fields while pf would be OK as per the 8487
* sain-interface while sain-if would work
...

Almost the majority of the IANA-maintained modules are prefixed with 'iana-".

Cheers,
Med

> -Message d'origine-
> De : Jürgen Schönwälder 
> Envoyé : vendredi 15 mars 2024 15:24
> À : BOUCADAIR Mohamed INNOV/NET 
> Cc : netmod@ietf.org
> Objet : Re: [netmod] On prefixes again RE: IETF#119 I-D Status: draft-
> ietf-netmod-rfc8407bis
> 
> I wonder which problem we are solving with adding more little rules.
> Perhaps a future version of YANG will do away with prefixes but until
> this happens, I do not think we need to add more rules about how to
> choose prefixes. The original intend was that they are short to keep
> YANG snippets concise and easy to read.
> 
> /js
> 
> On Fri, Mar 15, 2024 at 01:02:58PM +, mohamed.boucad...@orange.com
> wrote:
> > Hi Andy,
> >
> > (changing the subject to ease tracking this)
> >
> > The thread I was referring is:
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
> > archive.ietf.org%2Farch%2Fmsg%2Fnetmod%2F6VkSrroaxwXHSI19Jj0j-
> tbFCjA%2
> >
> F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cab1c68644b9f46df886f
> >
> 08dc44fb96df%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638461094563
> >
> 962002%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ
> >
> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=E0dsjDvDZ8KVY4UinoQWBFq
> > 5f%2BWG3bwREGRrMWlL9sA%3D&reserved=0
> >
> > I do personally think that it is a good guidance to prefix IETF
> modules with “ietf-“ and IANA-maintained ones with “iana-‘. This is
> consistent with the practice we followed recently for iana-maintained
> modules.
> >
> > If we recommend this prefix pattern, I’m afraid that we need to
> > revisit the text about short prefixes, e.g.,
> >
> > 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 prefixed with “ietf-“ for IETF modules
> and
> >“iana-“ for IANA-maintained modules. Prefix values SHOULD NOT be
> >too long and SHOULD NOT conflict with known modules that have
> been
> >previously published.
> >
> > Cheers,
> > Med
> >
> > De : Andy Bierman  Envoyé : jeudi 14 mars 2024
> > 22:53 À : Mahesh Jethanandani  Cc :
> BOUCADAIR
> > Mohamed INNOV/NET ; netmod@ietf.org
> > Objet : Re: [netmod] IETF#119 I-D Status: draft-ietf-netmod-
> rfc8407bis
> >
> > Hi,
> >
> > I cannot find this email wrt/ short prefixes
> >
> >
> >   *   (short/uniqueness of prefixes
> >
> > Other SDOs are using a prefix in their prefixes (e.g. openconfig).
> > It is common for servers to have both "if:interfaces" and "oc-
> if:interfaces" subtrees.
> >
> > It might be a good idea to have a guideline that all IETF YANG
> modules
> > SHOULD use the "ietf-" string in the module prefix.  This should
> > reduce the chance of name collisions between SDOs and vendors, and
> helps identify the module as an IETF module.
> >
> >
> > Andy
> >
> >
> >
> > On Tue, Mar 12, 2024 at 10:51 AM Mahesh Jethanandani
> mailto:mjethanand...@gmail.com>> wrote:
> > 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 3A%2F%2Fboucadair.github.io%2Frfc8407bis%2F%23go.draft-ietf-netmod-
> rfc8407bis.diff&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cab1c68
> 644b9f46df886f08dc44fb96df%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%
> 7C638461094563973290%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI
> joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=ctWpUZX9p
> OsZHqYtzfYobIF5lIOAT68OE%2FhTSeDaxd4%3D&reserved=0>
> >

[netmod] On prefixes again RE: IETF#119 I-D Status: draft-ietf-netmod-rfc8407bis

2024-03-15 Thread mohamed . boucadair

Hi Andy,

(changing the subject to ease tracking this)

The thread I was referring is: 
https://mailarchive.ietf.org/arch/msg/netmod/6VkSrroaxwXHSI19Jj0j-tbFCjA/

I do personally think that it is a good guidance to prefix IETF modules with 
“ietf-“ and IANA-maintained ones with “iana-‘. This is consistent with the 
practice we followed recently for iana-maintained modules.

If we recommend this prefix pattern, I’m afraid that we need to revisit the 
text about short prefixes, e.g.,

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 prefixed with “ietf-“ for IETF modules and
   “iana-“ for IANA-maintained modules. Prefix values SHOULD NOT be
   too long and SHOULD NOT conflict with known modules that have been
   previously published.

Cheers,
Med

De : Andy Bierman 
Envoyé : jeudi 14 mars 2024 22:53
À : Mahesh Jethanandani 
Cc : BOUCADAIR Mohamed INNOV/NET ; netmod@ietf.org
Objet : Re: [netmod] IETF#119 I-D Status: draft-ietf-netmod-rfc8407bis

Hi,

I cannot find this email wrt/ short prefixes


  *   (short/uniqueness of prefixes

Other SDOs are using a prefix in their prefixes (e.g. openconfig).
It is common for servers to have both "if:interfaces" and "oc-if:interfaces" 
subtrees.

It might be a good idea to have a guideline that all IETF YANG modules SHOULD
use the "ietf-" string in the module prefix.  This should reduce the chance of 
name collisions
between SDOs and vendors, and helps identify the module as an IETF module.


Andy



On Tue, Mar 12, 2024 at 10:51 AM Mahesh Jethanandani 
mailto:mjethanand...@gmail.com>> wrote:
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

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

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

2024-03-12 Thread 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

2024-03-12 Thread 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

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

2024-03-05 Thread mohamed . boucadair

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 the
> uniqueness
> >> IMO.
> >>
> >> Also, as per RFC2119, we should clarify when the SHOULD NOT can be
> >> safely ignored:
> >>
> >>     SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean
> >> that
> >>
> >>     there may exist valid reasons in particular circumstances when
> >> the
> >>
> >>     particular behavior is acceptable or even useful, but the full
> >>
> >>     implications should be understood and the case carefully
> weighed
> >>
> >>     before implementing any behavior described with this label.
> >>
> >> An obvious case is an updated version of a published version.
> > ...
> >
> > In dealing with SHOULD statements in RFCs, both as an implementor
> and
> > as a specification writer, I find it useful to re-phrase (at least
> in
> > my head) a "SHOULD NOT X" as "MUST be able to cope with others doing
> > X, even if it does not itself do X."
> >
> > A "SHOULD NOT X" in a specification does NOT relieve implementations
> > of the duty to work correctly when X happens, because "SHOULD NOT X"
> > means that X is indeed permitted, even if discouraged.  If X causes
> a
> > an implementation pair to violate protocol or miscommunicate (e.g.
> > referencing the wrong syntax or semantics) at some level, then it
> > really needs to be a "MUST NOT".
> >
> > But this is an old, old argument, and gliding along with "likely
> > uniqueness" rather than uniqueness has been a longstanding
> bug/feature
> > of netmod.  I'd just like to see a bit more guidance for
> implementors
> > so their products don't crash and burn when they do encounter
> > "duplicate" prefixes in the wild.
> >
> > Randy
> >
> > ___
> > netmod mailing list
> > netmod@ietf.org
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> >
> ietf.org%2Fmailman%2Flistinfo%2Fnetmod&data=05%7C02%7Cmohamed.boucadai
> >
> r%40orange.com%7C3b125a3e5a83426657e108dc3c8376a4%7C90c7a20af34b40bfbc
> >
> 48b9253b6f5d20%7C0%7C0%7C638451782524628913%7CUnknown%7CTWFpbGZsb3d8ey
> >
> JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7
> >
> C%7C%7C&sdata=fkyIdrLqhqIkfdivCbWnetivTNNcpW07OepfdUat3mo%3D&reserved=
> > 0
> 
> --
> Jürgen Schönwälder

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

2024-03-05 Thread mohamed . boucadair

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<mailto:mohamed.boucad...@orange.com> wrote:

Hi all,

I think that this version is ready for the WGLC.

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

Cheers,
Med

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

-Message d'origine-
De : I-D-Announce 
mailto:i-d-announce-boun...@ietf.org>> De la 
part de
internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>
Envoyé : mercredi 28 février 2024 10:01
À : i-d-annou...@ietf.org<mailto:i-d-annou...@ietf.org>
Cc : netmod@ietf.org<mailto: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<https://data/>
tracker.ietf.org<http://tracker.ietf.org/>%2Fdoc%2Fdraft-ietf-netmod-
rfc8407bis%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com<http://40orange.com/>%7C51672231
30c943a5a4c608dc383bce6b%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C
638447076716455966%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo
iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=s5VX9Hb%2Fl
P9v5QurysF69syyEyba9yYss7xd7K5E2FE%3D&reserved=0

There is also an HTML version available at:
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww<https://www/>.
ietf.org<http://ietf.org/>%2Farchive%2Fid%2Fdraft-ietf-netmod-rfc8407bis-
09.html&data=05%7C02%7Cmohamed.boucadair%40orange.com<http://40orange.com/>%7C5167223130c943
a5a4c608dc383bce6b%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638447
076716464395%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=%2Br3nHahSq8OV24f
hFxBkJaqY43Q0GUxcbPZSFhji4uk%3D&reserved=0

A diff from the previous version is available at:
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauth<https://auth/>
or-tools.ietf.org<http://or-tools.ietf.org/>%2Fiddiff%3Furl2%3Ddraft-ietf-netmod-rfc8407bis-
09&data=05%7C02%7Cmohamed.boucadair%40orange.com<http://40orange.com/>%7C5167223130c943a5a4c
608dc383bce6b%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63844707671
6470644%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC
JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=zo%2FrtFJrYJkJXOceIpzR
mlGAQF2c8m9Z%2F0vShl5o8gQ%3D&reserved=0

Internet-Drafts are also available by rsync at:
rsync.ietf.org<http://rsync.ietf.org/>::internet-drafts



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 privileg

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

2024-03-04 Thread mohamed . boucadair

d-annou...@ietf.org>
Cc : netmod@ietf.org<mailto:netmod@ietf.org>
Objet : I-D Action: draft-ietf-netmod-rfc8407bis-09.txt

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

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

Abstract:

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

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

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

There is also an HTML version available at:
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
ietf.org%2Farchive%2Fid%2Fdraft-ietf-netmod-rfc8407bis-
09.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C5167223130c943
a5a4c608dc383bce6b%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638447
076716464395%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=%2Br3nHahSq8OV24f
hFxBkJaqY43Q0GUxcbPZSFhji4uk%3D&reserved=0

A diff from the previous version is available at:
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauth
or-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-netmod-rfc8407bis-
09&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C5167223130c943a5a4c
608dc383bce6b%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63844707671
6470644%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC
JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=zo%2FrtFJrYJkJXOceIpzR
mlGAQF2c8m9Z%2F0vShl5o8gQ%3D&reserved=0

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



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

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

2024-03-03 Thread mohamed . boucadair

 the WGLC.

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

Cheers,
Med

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

-Message d'origine-
De : I-D-Announce 
mailto:i-d-announce-boun...@ietf.org>> De la 
part de
internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>
Envoyé : mercredi 28 février 2024 10:01
À : i-d-annou...@ietf.org<mailto:i-d-annou...@ietf.org>
Cc : netmod@ietf.org<mailto: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<https://data/>
tracker.ietf.org<http://tracker.ietf.org/>%2Fdoc%2Fdraft-ietf-netmod-
rfc8407bis%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com<http://40orange.com/>%7C51672231
30c943a5a4c608dc383bce6b%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C
638447076716455966%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo
iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=s5VX9Hb%2Fl
P9v5QurysF69syyEyba9yYss7xd7K5E2FE%3D&reserved=0

There is also an HTML version available at:
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww<https://www/>.
ietf.org<http://ietf.org/>%2Farchive%2Fid%2Fdraft-ietf-netmod-rfc8407bis-
09.html&data=05%7C02%7Cmohamed.boucadair%40orange.com<http://40orange.com/>%7C5167223130c943
a5a4c608dc383bce6b%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638447
076716464395%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=%2Br3nHahSq8OV24f
hFxBkJaqY43Q0GUxcbPZSFhji4uk%3D&reserved=0

A diff from the previous version is available at:
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauth<https://auth/>
or-tools.ietf.org<http://or-tools.ietf.org/>%2Fiddiff%3Furl2%3Ddraft-ietf-netmod-rfc8407bis-
09&data=05%7C02%7Cmohamed.boucadair%40orange.com<http://40orange.com/>%7C5167223130c943a5a4c
608dc383bce6b%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63844707671
6470644%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC
JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=zo%2FrtFJrYJkJXOceIpzR
mlGAQF2c8m9Z%2F0vShl5o8gQ%3D&reserved=0

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



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




Ce message et ses pieces jointes peuvent

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

2024-03-03 Thread mohamed . boucadair

Hi Qiufang,

Thanks for the comments.

Please see inline.

Cheers,
Med

De : maqiufang (A)
Envoyé : jeudi 29 février 2024 07:29
À : BOUCADAIR Mohamed INNOV/NET ; Kent Watsen

Cc : netmod@ietf.org; netmod-cha...@ietf.org
Objet : RE: [netmod] Next steps for draft-ietf-netmod-rfc8407bis

Hi, Med, Kent, all

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

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

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

NEW:

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

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

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

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

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

[Med] The sec considerations of such data nodes will be listed under writeable
and/or readable items of the existing template. I’m not sure adding this
mention is useful from a security standpoint.

Best Regards,
Qiufang

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

Hi all,

I think that this version is ready for the WGLC.

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

Cheers,
Med

[1] Slide#7 of
https://datatracker.ietf.org/meeting/117/materials/slides-117-netmod-7-guidelines-for-authors-and-reviewers-of-documents-containing-yang-data-models-00
-Message d'origine-
De : I-D-Announce
mailto:i-d-announce-boun...@ietf.org>> De la
part de
internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>
Envoyé : mercredi 28 février 2024 10:01
À : i-d-annou...@ietf.org<mailto:i-d-annou...@ietf.org>
Cc : netmod@ietf.org<mailto: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 considera

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

2024-02-28 Thread mohamed . boucadair

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

Cheers,
Med

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


-Message d'origine-
De : I-D-Announce 
mailto:i-d-announce-boun...@ietf.org>> De la 
part de
internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>
Envoyé : mercredi 28 février 2024 10:01
À : i-d-annou...@ietf.org<mailto:i-d-annou...@ietf.org>
Cc : netmod@ietf.org<mailto: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<https://data/>
tracker.ietf.org%2Fdoc%2Fdraft-ietf-netmod-
rfc8407bis%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C51672231
30c943a5a4c608dc383bce6b%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C
638447076716455966%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo
iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=s5VX9Hb%2Fl
P9v5QurysF69syyEyba9yYss7xd7K5E2FE%3D&reserved=0

There is also an HTML version available at:
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww<https://www/>.
ietf.org%2Farchive%2Fid%2Fdraft-ietf-netmod-rfc8407bis-
09.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C5167223130c943
a5a4c608dc383bce6b%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638447
076716464395%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=%2Br3nHahSq8OV24f
hFxBkJaqY43Q0GUxcbPZSFhji4uk%3D&reserved=0

A diff from the previous version is available at:
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauth<https://auth/>
or-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-netmod-rfc8407bis-
09&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C5167223130c943a5a4c
608dc383bce6b%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63844707671
6470644%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC
JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=zo%2FrtFJrYJkJXOceIpzR
mlGAQF2c8m9Z%2F0vShl5o8gQ%3D&reserved=0

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



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<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&#x

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

2024-02-28 Thread mohamed . boucadair

8407bis-09.txt

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

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

Abstract:

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

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

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

There is also an HTML version available at:
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
ietf.org%2Farchive%2Fid%2Fdraft-ietf-netmod-rfc8407bis-
09.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C5167223130c943
a5a4c608dc383bce6b%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638447
076716464395%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=%2Br3nHahSq8OV24f
hFxBkJaqY43Q0GUxcbPZSFhji4uk%3D&reserved=0

A diff from the previous version is available at:
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauth
or-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-netmod-rfc8407bis-
09&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C5167223130c943a5a4c
608dc383bce6b%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63844707671
6470644%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC
JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=zo%2FrtFJrYJkJXOceIpzR
mlGAQF2c8m9Z%2F0vShl5o8gQ%3D&reserved=0

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



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

2024-02-28 Thread mohamed . boucadair

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&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C51672231
> 30c943a5a4c608dc383bce6b%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C
> 638447076716455966%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo
> iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=s5VX9Hb%2Fl
> P9v5QurysF69syyEyba9yYss7xd7K5E2FE%3D&reserved=0
> 
> There is also an HTML version available at:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Farchive%2Fid%2Fdraft-ietf-netmod-rfc8407bis-
> 09.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C5167223130c943
> a5a4c608dc383bce6b%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638447
> 076716464395%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=%2Br3nHahSq8OV24f
> hFxBkJaqY43Q0GUxcbPZSFhji4uk%3D&reserved=0
> 
> A diff from the previous version is available at:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauth
> or-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-netmod-rfc8407bis-
> 09&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C5167223130c943a5a4c
> 608dc383bce6b%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63844707671
> 6470644%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC
> JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=zo%2FrtFJrYJkJXOceIpzR
> mlGAQF2c8m9Z%2F0vShl5o8gQ%3D&reserved=0
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 



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

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

2024-02-22 Thread mohamed . boucadair

Hi Andy,

We need to be careful here to avoid redundant guidance.

For example, the guidance you are suggesting is already covered in 4.23. It 
even includes guidance for motivating exceptions:

   Designers SHOULD describe and justify any NMDA exceptions in detail,
   such as the use of separate subtrees and/or separate leafs.  The
   "description" statements for both the configuration and the
   operational state SHOULD be used for this purpose.

The proposed narrative text is about highlighting when a temporary non-NMDA is 
**included in the spec**; to echo this part from 4.23.3, bullet a:

A temporary non-NMDA version of
this type of module MAY exist, as either an existing model or a
model created by hand or with suitable tools that mirror the
current modeling strategies.  Both the NMDA and the non-NMDA
modules SHOULD be published in the same document, with NMDA
modules in the document main body and the non-NMDA modules in a
non-normative appendix.  The use of the non-NMDA module will
allow temporary bridging of the time period until NMDA
implementations are available.

That’s said, if you have a NDMA-related text proposal of you think is worth 
highlighting in the narrative text, please share it. Thanks.

Cheers,
Med

De : Andy Bierman 
Envoyé : vendredi 23 février 2024 02:25
À : BOUCADAIR Mohamed INNOV/NET 
Cc : Kent Watsen ; netmod@ietf.org
Objet : Re: [netmod] Rfc8407 - what does this text mean?

Hi,

I don't think the issue is whether a foo-state module is included in the RFC or 
not.
There is an algorithm to produce the foo-state module for vendors to use.

IMO the NMDA guideline should indicate "need NMDA", and be present if it is 
believed that the operational state can be
different than the config. In that case a  on  would be 
useful.
If not, then the foo-state module is not even relevant.


Andy



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

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

2024-02-20 Thread mohamed . boucadair

Hi Andy,

Please see inline.

Cheers,
Med

De : Andy Bierman
Envoyé : mardi 20 février 2024 18:19
À : BOUCADAIR Mohamed INNOV/NET
Cc : Kent Watsen ; netmod@ietf.org
Objet : Re: [netmod] Rfc8407 - what does this text mean?

On Mon, Feb 19, 2024 at 11:39 PM
mailto:mohamed.boucad...@orange.com>> wrote:
Hi all,

I updated the PR to use a wording aligned with 4.23:

NEW:
If the document contains a temporary non-NMDA (Network Management
Datastore Architecture) [RFC8342], then the Introduction section
should mention this fact with the reasoning that motivated that
design. Refer to Section 4.23 for more NMDA-related guidance.

Does this mean that the Transition to NMDA is completed, and it is now
considered a bad idea
to include a non-NMDA 'state' module?
[Med] We don’t actually change the core NMDA guidance (hence the pointer to
4.23). All we do here is, given the SHOULD NMDA-compliant reco in 4.23 and the
practice adopted for published modules since then, we encourage highlighting
exceptions (MAY temporary thing in 4.23) in the Introduction rather than the
SHOULD.

Most deployments (90%?) are non-NMDA.
The motivation will always be to allow this 90% to retrieve the operational
values of specific configuration data.

Cheers,
Med

Andy

De : Andy Bierman mailto:a...@yumaworks.com>>
Envoyé : lundi 19 février 2024 19:58
À : Kent Watsen mailto:kent%2bi...@watsen.net>>
Cc : BOUCADAIR Mohamed INNOV/NET
mailto:mohamed.boucad...@orange.com>>;
netmod@ietf.org
Objet : Re: [netmod] Rfc8407 - what does this text mean?

On Mon, Feb 19, 2024 at 6:54 AM Kent Watsen
mailto:kent%2bi...@watsen.net>> wrote:
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.

Guidelines should be specific and clear.
This inverse exception text seems better than the boilerplate text you want to
replace.

What exactly does it mean for a YANG module to be non-NMDA-compliant?
Is the guideline forbidding config/state sibling containers, or just those that
use a grouping or cut-and-paste
to implement its non-NMDA-ness?
Maybe NMDA experts can explain when this exception is needed and what it should
say.

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!

No wonder I didn't remember the WG discussing this during draft-8407.

Cheers,
Med

Andy

[1]
https://author-tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/rfc8407bis/draft-ietf-netmod-rfc8407bis.txt&url_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
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

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 sec

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

2024-02-20 Thread mohamed . boucadair

Hi Andy,

De : Andy Bierman
Envoyé : mardi 20 février 2024 18:19
À : BOUCADAIR Mohamed INNOV/NET
Cc : Kent Watsen ; netmod@ietf.org
Objet : Re: [netmod] Rfc8407 - what does this text mean?

On Mon, Feb 19, 2024 at 11:39 PM
mailto:mohamed.boucad...@orange.com>> wrote:
Hi all,

I updated the PR to use a wording aligned with 4.23:

Does this mean that the Transition to NMDA is completed, and it is now
considered a bad idea
to include a non-NMDA 'state' module? Most deployments (90%?) are non-NMDA.
The motivation will always be to allow this 90% to retrieve the operational
values of specific configuration data.

Cheers,
Med

Andy

On Mon, Feb 19, 2024 at 6:54 AM Kent Watsen
mailto:kent%2bi...@watsen.net>> wrote:
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.

Guidelines should be specific and clear.
This inverse exception text seems better than the boilerplate text you want to
replace.

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!

No wonder I didn't remember the WG discussing this during draft-8407.

Cheers,
Med

Andy

[2] https://mailarchive.ietf.org/arch/msg/netmod/B4TUQZf7jud5wqrBwzEqEND6-rw/

Hi Andy,

Thanks for the speedy reply.

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

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 discussi

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

2024-02-19 Thread mohamed . boucadair

Hi all,

I updated the PR to use a wording aligned with 4.23:

Cheers,
Med

De : Andy Bierman
Envoyé : lundi 19 février 2024 19:58
À : Kent Watsen
Cc : BOUCADAIR Mohamed INNOV/NET ; netmod@ietf.org
Objet : Re: [netmod] Rfc8407 - what does this text mean?

On Mon, Feb 19, 2024 at 6:54 AM Kent Watsen
mailto:kent%2bi...@watsen.net>> wrote:
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.

Guidelines should be specific and clear.
This inverse exception text seems better than the boilerplate text you want to
replace.

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!

No wonder I didn't remember the WG discussing this during draft-8407.

Cheers,
Med

Andy

[2] https://mailarchive.ietf.org/arch/msg/netmod/B4TUQZf7jud5wqrBwzEqEND6-rw/

Hi Andy,

Thanks for the speedy reply.

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

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
https://www.iet

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

2024-02-19 Thread mohamed . boucadair

Hi Kent, all,

I also think that highlighting the exceptions + motivate them makes sense here.
A PR to fix that can be seen at [2].
FWIW, the OLD text was added draft-ietf-netmod-rfc6087bis-17 as per a comment
in the AD review [2].

Cheers,
Med

[2] https://mailarchive.ietf.org/arch/msg/netmod/B4TUQZf7jud5wqrBwzEqEND6-rw/

De : netmod De la part de Kent Watsen
Envoyé : vendredi 16 février 2024 21:55
À : Andy Bierman
Cc : netmod@ietf.org
Objet : Re: [netmod] Rfc8407 - what does this text mean?

Hi Andy,

Thanks for the speedy reply.

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

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

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

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

2024-02-16 Thread mohamed . boucadair

Hi all, 

This version integrates the "case+when" reco as discussed in the mailing list.

We have no pending issue so far. 

I think that the document is now ready for the WGLC. 

Cheers,
Med

> -Message d'origine-
> De : I-D-Announce  De la part de
> internet-dra...@ietf.org
> Envoyé : vendredi 16 février 2024 09:26
> À : i-d-annou...@ietf.org
> Cc : netmod@ietf.org
> Objet : I-D Action: draft-ietf-netmod-rfc8407bis-08.txt
> 
> Internet-Draft draft-ietf-netmod-rfc8407bis-08.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: Mohamed Boucadair
> Qin Wu
>Name:draft-ietf-netmod-rfc8407bis-08.txt
>Pages:   84
>Dates:   2024-02-16
> 
> Abstract:
> 
>This memo provides guidelines for authors and reviewers of
>specifications containing YANG modules, including IANA-maintained
>modules.  Recommendations and procedures are defined, which are
>intended to increase interoperability and usability of Network
>Configuration Protocol (NETCONF) and RESTCONF protocol
>implementations that utilize YANG modules.  This document obsoletes
>RFC 8407.
> 
>Also, this document updates RFC 8126 by providing additional
>guidelines for writing the IANA considerations for RFCs that
> specify
>IANA-maintained modules.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Fdraft-ietf-netmod-
> rfc8407bis%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ccaa398d6
> 760a4cb5629508dc2ec8f7a8%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C
> 638436687882032238%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo
> iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=KQWBc%2FzC%
> 2BmhmYZJpeqtnMXNXvaIL%2BsFXO4e%2BfroZ%2BoQ%3D&reserved=0
> 
> There is also an HTML version available at:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Farchive%2Fid%2Fdraft-ietf-netmod-rfc8407bis-
> 08.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ccaa398d6760a4c
> b5629508dc2ec8f7a8%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638436
> 687882042059%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=EnGbrUfb29t5WFzSl
> EnXlApoxiG%2B8k9e884c%2Fx%2BeQwU%3D&reserved=0
> 
> A diff from the previous version is available at:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauth
> or-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-netmod-rfc8407bis-
> 08&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ccaa398d6760a4cb5629
> 508dc2ec8f7a8%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63843668788
> 2048789%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC
> JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=rt4cEfNoNkD8Kxr8lJ4S8m
> w4k737CtMfsM2FAsnqg%2FM%3D&reserved=0
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 
> 
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fi-d-
> announce&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ccaa398d6760a4
> cb5629508dc2ec8f7a8%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63843
> 6687882054624%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu
> MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=s36uefl5Va%2FWfA
> 1d1lU0kCnMxigcpToKGmpseapySNM%3D&reserved=0


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

This message and its attachments 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

Re: [netmod] case + when in 8407bis

2024-02-09 Thread mohamed . boucadair

Hi all,

This is a nudge about this pending issue.

Here is the main proposed reco:

NEW:
   Some modules use "case + when" construct but provide duplicated
   information (e.g., the "when" statements are constraining a single
   case in the choice as shown in the example below).  Such constructs
   with duplicated information SHOULD NOT be used.

   ...

   Note that the use of "case + when" is still useful in cases where

   complementary modelling constraints should be expressed.  See the

   example provided below.

   ...

The full PR can be seen at: 
https://github.com/boucadair/rfc8407bis/pull/33/files.

Please let me know if you have any objection to include this text in the draft. 
Thanks.

Cheers,
Med

De : BOUCADAIR Mohamed INNOV/NET
Envoyé : mercredi 24 janvier 2024 15:17
À : 'Italo Busi' ; Martin Björklund 
Cc : netmod@ietf.org
Objet : RE: [netmod] case + when in 8407bis

Hi Italo,

Thanks for sharing your thoughts.

I do still think there is a value in providing some guidance for such 
constructs.

I updated the PR with the example you provided as I find it better that the one 
we used to have. Feel free to review and proposed changes to the proposed PR 
at: https://github.com/boucadair/rfc8407bis/pull/33/files.

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

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

2024-02-09 Thread mohamed . boucadair

Hi Kent,

Please see inline.

Cheers,
Med

De : Kent Watsen
Envoyé : jeudi 8 février 2024 16:55
À : BOUCADAIR Mohamed INNOV/NET
Cc : netmod@ietf.org
Objet : Re: [netmod] rfc8407bis IANA guidance (enums vs identities)

Hi Mohamad,

Thanks for the response.
Some thoughts below.

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)

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?

[Med] No. These are examples of the use of enums or identitirefs.

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.

[Med] Works for me. Updated. Thanks.

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.
[Med] There is no normative language in this text. I do still think this text
is useful as it to provide an example of a specific context.

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.

[Med] I merged this change with the other comment I received offline and went
for the following:

NEW:

If distributed extensibility or hierarchical organization of
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&url_2=https://boucadair.github.io/rfc8407bis/enum-vs-identities/draft-ietf-netmod-rfc8407bis.txt

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

2024-02-08 Thread mohamed . boucadair

Re-,

I got an offline comment that there is an ambiguity about how to interpret "If
the set of values is fixed and" part of 4.11.1. In order to make the guidance
more explicit, I propose we also add the following:

NEW:
If the set of the data type contents requires some hierarchy or
the allocation of the values is distributed, then an "identityref"
data type SHOULD be used.

The full proposed changes can still be tracked using the same link below.

Cheers,
Med

De : BOUCADAIR Mohamed INNOV/NET
Envoyé : jeudi 8 février 2024 09:37
À : 'Kent Watsen' ; netmod@ietf.org
Objet : RE: [netmod] rfc8407bis IANA guidance (enums vs identities)

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)

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.

(2)

Cheers,
Med

De : netmod mailto:netmod-boun...@ietf.org>> De la
part de Kent Watsen
Envoyé : mercredi 7 février 2024 18:29
À : netmod@ietf.org
Objet : [netmod] rfc8407bis IANA guidance (enums vs identities)

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

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

2024-02-08 Thread mohamed . boucadair

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)

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.

(2)

Cheers,
Med

De : netmod De la part de Kent Watsen
Envoyé : mercredi 7 février 2024 18:29
À : netmod@ietf.org
Objet : [netmod] rfc8407bis IANA guidance (enums vs identities)

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:

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 wa

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

2024-02-07 Thread mohamed . boucadair

Hi all, 

Here is an update on the initial comments from Dale:

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

After discussion with Dale, this PR is created: 
https://github.com/boucadair/rfc8407bis/pull/36/files. This will be merged into 
the next iteration of i-d.rfc8407bis. 

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

The secretariat helped fixing the broken link. 

With these actions, I think that the erratum can be safely rejected.

Cheers,
Med

> -Message d'origine-
> De : BOUCADAIR Mohamed INNOV/NET
> Envoyé : mardi 30 janvier 2024 18:53
> À : 'RFC Errata System' ;
> wor...@alum.mit.edu
> Cc : netmod@ietf.org
> Objet : RE: [netmod] [Editorial Errata Reported] RFC8407 (7791)
> 
> Hi Dale, all,
> 
> I don't think filling an erratum is appropriate here given that the
> original text is not broken (including the URL). I suggest to reject
> it.
> 
> However, text enhancements can be considered as part of
> https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8407bis/. Let's
> have that discussion. Thanks.
> 
> Cheers,
> Med
> 
> > -Message d'origine-
> > De : netmod  De la part de RFC Errata
> System
> > Envoyé : mardi 30 janvier 2024 18:01 À : rfc-edi...@rfc-editor.org
> Cc
> > : wor...@alum.mit.edu; netmod@ietf.org Objet : [netmod] [Editorial
> > Errata Reported] RFC8407 (7791)
> >
> > The following errata report has been submitted for RFC8407,
> > "Guidelines for Authors and Reviewers of Documents Containing YANG
> > Data Models".
> >
> > --
> > You may review the report below and at:
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > rfc-
> >
> editor.org%2Ferrata%2Feid7791&data=05%7C02%7Cmohamed.boucadair%40orang
> >
> e.com%7C2cb3e186d23d4eac917208dc21b511f8%7C90c7a20af34b40bfbc48b9253b6
> >
> f5d20%7C0%7C0%7C638422308774178382%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
> >
> wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&s
> > data=6Qi9sKVPa44FCI8dW984szRS1EZso%2FpPr%2BRDnsGkobE%3D&reserved=0
> >
> > --
> > Type: Editorial
> > Reported by: Dale R. Worley 
> >
> > Section: GLOBAL
> >
> > Original Text
> > -
> > There are two related items.
> >
> > 1) Section 3.7.1 "Security Considerations Section Template" begins
> >
> >X.  Security Considerations
> >
> >The YANG module specified in this document defines a schema for
> > data
> >that is designed to be accessed via network management protocols
> > such
> >as NETCONF [RFC6241] or RESTCONF [RFC8040].  The lowest NETCONF
> > layer
> >is the secure transport layer, and the mandatory-to-implement
> > secure
> >transport is Secure Shell (SSH) [RFC6242].  The lowest RESTCONF
> > layer
> >is HTTPS, and the mandatory-to-implement secure transport is TLS
> >[RFC8446].
> >
> > 2) RFC 8470 says "the latest approved template (available at
> )".  But
> the template at that URL says "the latest approved template (available
> at http://trac.tools.ietf.org/area/ops/trac/wiki/yang-security-
> guidelines).">
> >
> > Corrected Text
> > --
> > 1) It would be helpful if the beginning of the template contained a
> > reference to RFC 8407 to provide a pointer back to where the
> templated
> > section of Yang module definitions was instantiated from.  Perhaps
> > starting the template with "[Instantiated from the template of
> > [RFC8407] section 3.7.1.]"
> >
> > 2) While the URL given in RFC 8407 works, the URL given in the
> online
> > template only goes to a generic page, "Welcome to the IETF Community
> > Wiki".  Presumably the URL in the online template should be the URL
> of
> > that page itself.
> >
> >
> >
> > Notes
> > -
> > Item (2) is a straightforward correction.  Item (1) is in service to
> > having better pointers/references in our documents.
> >
> > Instructions:
> > -
> > This erratum is currently posted as "Reported". (If it is spam, it
> > will be removed shortly by the RFC Production Center.) Please use
> > "Reply All" to discuss whether it should be verified or rejected.
> When
> > a decision is reached, the verifying party will log in to change the
> > status and edit the report, if necessary.
> >
> > --
> > RFC8407 (draft-ietf-netmod-rfc6087bis-20)
> > --
> > Title   : Guidelines for Authors and Reviewers of
> > Documents Containing

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

2024-02-07 Thread mohamed . boucadair

Hi Mahesh, all,

FWIW, we submitted an updated version of the draft to address the pending
points from your reviews. A diff to track the changes vs. -04 can be seen at:
https://author-tools.ietf.org/iddiff?url1=draft-ietf-netmod-acl-extensions-04&url2=draft-ietf-netmod-acl-extensions-06&difftype=--html.

Cheers,
Med

De : BOUCADAIR Mohamed INNOV/NET
Envoyé : mardi 23 janvier 2024 16:57
À : 'Mahesh Jethanandani'
Cc : Lou Berger ; NETMOD Group ; NetMod WG
Chairs
Objet : RE: [netmod] WG Last Call: draft-ietf-netmod-acl-extensions-03

Hi Mahesh,

Thanks for the follow-up. Made some changes as you can see at
https://boucadair.github.io/enhanced-acl-netmod/#go.draft-ietf-netmod-acl-extensions.diff.

Please see inline for more context.

Cheers,
Med

Orange Restricted
De : Mahesh Jethanandani
mailto:mjethanand...@gmail.com>>
Envoyé : mercredi 20 décembre 2023 18:20
À : BOUCADAIR Mohamed INNOV/NET
mailto:mohamed.boucad...@orange.com>>
Cc : Lou Berger mailto:lber...@labn.net>>; NETMOD Group
mailto:netmod@ietf.org>>; NetMod WG Chairs
mailto:netmod-cha...@ietf.org>>
Objet : Re: [netmod] WG Last Call: draft-ietf-netmod-acl-extensions-03

Hi Med,

Thanks for addressing some of my comments. Please see inline.

On Dec 19, 2023, at 12:09 AM,
mohamed.boucad...@orange.com wrote:

Hi Mahesh, all,

Thank you for the review and comments. We just posed
draft-ietf-netmod-acl-extensions-04.

Please see more context inline.

Cheers,
Med

De : netmod mailto:netmod-boun...@ietf.org>> De la
part de Mahesh Jethanandani
Envoyé : mardi 5 décembre 2023 23:09
À : Lou Berger mailto:lber...@labn.net>>
Cc : NETMOD Group mailto:netmod@ietf.org>>; NetMod WG Chairs
mailto:netmod-cha...@ietf.org>>
Objet : Re: [netmod] WG Last Call: draft-ietf-netmod-acl-extensions-03

Hi,

I do support this work, as it is much needed, and would like to see it
progress. However, I do believe that the document needs to undergo a revision
to qualify for LC. Some of the comments are editorial or minor, and can be
addressed easily, but others are not. They should all be addressed for the WG
to call the document ready.

- The Security Considerations section has both the read/write nodes and the
read-only nodes as empty (or marked as TBC, which I imagine stands for To Be
Completed). This needs to be filled out, or if no nodes are worth any security
considerations, it should be stated so, and why.

[Med] ACK. We don’t repeat what is already in 8519 but focus on key additions
in the spec: https://github.com/boucadair/enhanced-acl-netmod/pull/65/files

[mj] Thanks for updating the section.

s/setf/set/
s/Simialr/Similar/

and in other place
s/modelled/modeled/

[Med] Thanks. Fixed.

- Isn’t the YANG model normative portion of the document? Isn’t what this
document all about? Why is it then in the Appendix?

[Med] We are using a script to generate the IANA modules + we are actually
following this part from the 8407bis:

It is RECOMMENDED to include the URL from where to retrieve the
recent version of the module. When a script is used, the Internet-
Draft that defines an IANA-maintained module SHOULD include an
appendix with the initial full version of the module. Including such
an appendix in pre-RFC versions is meant to assess the correctness of
the outcome of the supplied script. The authors MUST include a note
to the RFC Editor requesting that the appendix be removed before
publication as RFC and that RFC is replaced with the RFC number
that is assigned to the document. Initial versions of IANA-
maintained modules that are published in RFCs may be misused despite
the appropriate language to refer to the IANA registry to retrieve
the up-to-date module.

[mj] I am not clear on what happens to the IANA module once the draft is
published as an RFC based on what you cite from 8407bis.
[Med] It will be removed as per the note:

(2) The modules are provided in {{iana-icmp}}, {{iana-icmpv6}}, and
{{iana-ipv6-ext}} for the users convenience before publication as RFC. Please
remove these appendices from the final RFC.

The document states that the reference to “RFC ” is replaced with the
actual RFC number, but it also says that the Appendix be removed. What happens
to the initial version of the module itself? Is it removed if the Appendix is
removed?
[Med] It will be removed as per the note above. Please note that this practice
is already followed in rfc9108, for example.

Or does it remain in the Appendix as an initial version, with language that
indicates that the IANA registry should be used to retrieve the most up-to-date
model? The language in Section 1.1 item (2) does not help.

The above text from 8407bis needs to be explicit on what happens to the initial
version of the module as part of the RFC publication.
[Med] Please feel free to propose changes to this part of the bis for better
clarity:

The authors MUST include a note
to the RFC Editor r

Re: [netmod] rfc8407bis IANA module identifier name

2024-02-06 Thread mohamed . boucadair

Hi Qin, all,

Thanks.

As you know, rfc8407bis covers also considerations for when a script is used to
generate the module.

Aaah, I have a minor comment about draft-ietf-netconf-ssh-client-server, I see
that it is not consistent with the bis as it uses folding while this can be
avoided as per:

“Native YANG features (e.g., breaking line, "+") SHOULD be used to fit a module
into the line limits. Exceptionally, RFC8792-folding of YANG modules MAY be
used if and only if native YANG features are not sufficient.”

Cheers,
Med

De : Qin Wu
Envoyé : mardi 6 février 2024 01:53
À : BOUCADAIR Mohamed INNOV/NET ; Kent Watsen
; netmod@ietf.org
Objet : RE: [netmod] rfc8407bis IANA module identifier name

Med, Kent:

The proposed changes look good, when I get chance to review
draft-ietf-netconf-ssh-client-server, I found python code in Appendix A

(https://datatracker.ietf.org/doc/html/draft-ietf-netconf-ssh-client-server-36#name-yang-modules-for-iana)
for identity generation is

very useful, especially the code that can help translate 3des in IANA registry
(https://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml#ssh-parameters-17)

into triple-des in IANA maintained modules.

One side comment, how often does the encryption algorithm name start with
number?

-Qin
发件人: netmod [mailto:netmod-boun...@ietf.org] 代表
mohamed.boucad...@orange.com
发送时间: 2024年2月5日 23:09
收件人: Kent Watsen mailto:kent+i...@watsen.net>>;
netmod@ietf.org
主题: Re: [netmod] rfc8407bis IANA module identifier name

Hi Kent, all,

Thanks for raising this point.

For registries where a name is available, mirroring it in the YANG module would
be the right approach. That’s would also be consistent with the approach in
Section 4.30.3.2.

FWIW, here is an attempt to address your comments:
https://author-tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/rfc8407bis/draft-ietf-netmod-rfc8407bis.txt&url_2=https://boucadair.github.io/rfc8407bis/boucadair-patch-1/draft-ietf-netmod-rfc8407bis.txt

Cheers,
Med

De : netmod mailto:netmod-boun...@ietf.org>> De la
part de Kent Watsen
Envoyé : dimanche 4 février 2024 15:53
À : netmod@ietf.org
Objet : [netmod] rfc8407bis IANA module identifier name

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

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

Re: [netmod] rfc8407bis IANA module identifier name

2024-02-05 Thread mohamed . boucadair

Hi Kent, all,

Thanks for raising this point.

For registries where a name is available, mirroring it in the YANG module would
be the right approach. That's would also be consistent with the approach in
Section 4.30.3.2.

Cheers,
Med

De : netmod De la part de Kent Watsen
Envoyé : dimanche 4 février 2024 15:53
À : netmod@ietf.org
Objet : [netmod] rfc8407bis IANA module identifier name

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

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

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

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

2024-01-30 Thread mohamed . boucadair

Hi Dale, all, 

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

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

Cheers,
Med

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

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

Re: [netmod] case + when in 8407bis

2024-01-24 Thread mohamed . boucadair

Hi Italo,

Thanks for sharing your thoughts.

I do still think there is a value in providing some guidance for such 
constructs.

I updated the PR with the example you provided as I find it better that the one 
we used to have. Feel free to review and proposed changes to the proposed PR 
at: https://github.com/boucadair/rfc8407bis/pull/33/files.

Cheers,
Med

De : Italo Busi 
Envoyé : vendredi 12 janvier 2024 23:17
À : BOUCADAIR Mohamed INNOV/NET ; Martin 
Björklund 
Cc : netmod@ietf.org
Objet : RE: [netmod] case + when in 8407bis

In my current experience the use of case+when has been in many cases useless 
and in some cases even misleading and I am now pushing back when proposed

For example, with the following YANG code, the leaf bar is not mandatory in 
case of type c as it would appear at the first glance (that was the intention 
when a similar YANG code was designed):

leaf type {
  type enumeration {
enum a;
enum b;
enum c;
  }
  mandatory true;
}
choice type-choice {
  case b {
container type-b {
  when "../type = 'b'";
  leaf foo {
type string;
  }
}
  }
  case c {
container type-c {
  when "../type = 'c'";
  leaf bar {
mandatory true;
type string;
  }
}
  }
}

However, thinking further, in the following example (I have never found 
something similar so far but it is possible at least in theory), using 
case+when can be useful:

leaf type {
  type enumeration {
enum a;
enum b;
enum c;
  }
}
choice second-type {
  mandatory true;
  case foo {
container foo {
  presence "When present, indicates type foo"
  leaf foo-attribute {
type string;
  }
}
  }
  case b {
container bar {
  when "../type = 'a' or ../type = 'b'";
  presence "When present, indicates type bar"
  leaf bar-attribute {
type string;
  }
}
  }
  case c {
container baz {
  when "../type = 'c'";
  leaf baz-attribute {
mandatory true;
type string;
  }
}
  }
}

It seems to me that the main difference between the two examples if the fact 
that in the first example the case and attributes used in the when statements 
are providing duplicated information while in the second example they are 
providing complimentary information

Based on my current thoughts I think it would be worthwhile saying that the use 
of case+when SHOULD NOT be used when providing duplicated information (i.e., 
when the when statements is constraining a single case in the choice)

My 2 cent

Italo

> -Original Message-
> From: mohamed.boucad...@orange.com
> mailto:mohamed.boucad...@orange.com>>
> Sent: venerdì 15 dicembre 2023 08:28
> To: Martin Björklund mailto:mbj+i...@4668.se>>
> Cc: netmod@ietf.org
> Subject: Re: [netmod] case + when in 8407bis
>
> Re-,
>
> > To be clear, I think the paragraph:
> >
> >Some modules use "case + when" construct such as shown in the
> > example
> >below.  Such a construct MUST be avoided by removing the "when"
> >statement or using a "container" outside the "choice".
> >
> > and the example that follows should be removed.
> >
>
> Noted your objection.
>
> For now, I removed the text from the main, i.e., will be removed from the
> next iteration of the draft that will be submitted early next week.
>
> However, I created a PR
> (https://github.com/boucadair/rfc8407bis/pull/33/files)
>  to keep the
> discussion running as I think there is room for some guidance there.
>
> I f you consider the example share by Tom, if the "when" is important,
> removing choice/case and define these as container+when for these data
> nodes is cleaner. After all, the check leads to exclusive choices.
>
> Cheers,
> Med
>
> > -Message d'origine-
> > De : Martin Björklund mailto:mbj+i...@4668.se>> Envoyé : 
> > jeudi 14 décembre
> > 2023 21:48 À : BOUCADAIR Mohamed INNOV/NET
> > mailto:mohamed.boucad...@orange.com>> Cc : 
> > netmod@ietf.org Objet : Re:
> > [netmod] case + when in 8407bis
> >
> > Hi,
> >
> >
> > mohamed.boucad...@orange.com wrote:
> > > Hi Martin, all,
> > >
> > > Please remember that RFC8407 includes already the following:
> > >
> > > ==
>

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

2024-01-23 Thread mohamed . boucadair

Hi Mahesh,

Thanks for the follow-up. Made some changes as you can see at
https://boucadair.github.io/enhanced-acl-netmod/#go.draft-ietf-netmod-acl-extensions.diff.

Please see inline for more context.

Cheers,
Med

Orange Restricted
De : Mahesh Jethanandani
Envoyé : mercredi 20 décembre 2023 18:20
À : BOUCADAIR Mohamed INNOV/NET
Cc : Lou Berger ; NETMOD Group ; NetMod WG
Chairs
Objet : Re: [netmod] WG Last Call: draft-ietf-netmod-acl-extensions-03

Hi Med,

Thanks for addressing some of my comments. Please see inline.

On Dec 19, 2023, at 12:09 AM,
mohamed.boucad...@orange.com wrote:

Hi Mahesh, all,

Thank you for the review and comments. We just posed
draft-ietf-netmod-acl-extensions-04.

Please see more context inline.

Cheers,
Med

Hi,

[Med] ACK. We don’t repeat what is already in 8519 but focus on key additions
in the spec: https://github.com/boucadair/enhanced-acl-netmod/pull/65/files

[mj] Thanks for updating the section.

s/setf/set/
s/Simialr/Similar/

and in other place
s/modelled/modeled/

[Med] Thanks. Fixed.

- Isn’t the YANG model normative portion of the document? Isn’t what this
document all about? Why is it then in the Appendix?

[Med] We are using a script to generate the IANA modules + we are actually
following this part from the 8407bis:

[mj] I am not clear on what happens to the IANA module once the draft is
published as an RFC based on what you cite from 8407bis.
[Med] It will be removed as per the note:

(2) The modules are provided in {{iana-icmp}}, {{iana-icmpv6}}, and
{{iana-ipv6-ext}} for the users convenience before publication as RFC. Please
remove these appendices from the final RFC.

The authors MUST include a note
to the RFC Editor requesting that the appendix be removed before
publication as RFC and that RFC is replaced with the RFC number
that is assigned to the document.

- Why is the Section titled "Initial Version of the The ICMPv4 Types
IANA-Maintained Module”, when the model in question is
"iana-icmpv6-ty...@2020-09-25.yang”?
[Med] This was a typo. Fixed.

[mj] You fixed it another location. However, I still see the following in the
-04 version of the document.
[Med] Thanks for catching this. Fixed.

B.2. Initial Version of the The ICMPv4 Types IANA-Maintained Module
file
"iana-icmpv6-ty...@2020-09-25.yang"

module ian

Re: [netmod] [yang-doctors] Operational State usage of YANG choices and constraints (fix draft address)

2024-01-23 Thread mohamed . boucadair

Hi Mahesh,

Please see inline.

Cheers,
Med

De : Mahesh Jethanandani 
Envoyé : lundi 22 janvier 2024 17:43
À : BOUCADAIR Mohamed INNOV/NET 
Cc : Acee Lindem ; YANG Doctors ; 
netmod@ietf.org; draft-ietf-netmod-rfc8407...@ietf.org
Objet : Re: [yang-doctors] [netmod] Operational State usage of YANG choices and 
constraints (fix draft address)

Hi Med,

On Jan 21, 2024, at 11:44 PM, 
mohamed.boucad...@orange.com wrote:

Hi Acee,

> I think these points are worth addressing in RFC8407 BIS.

We do already have the following in the bis, which I think covers your initial 
question about “mandatory true” data nodes for operational state”:

   Section 8.1 of [RFC7950] includes a provision for defining a
   constraint on state data and specifies that the constraint must be
   true in a valid state data.  However, Section 5.3 of [RFC8342]
   softens that behavior by allowing semantic constraints to be violated
   under some circumstances to help detecting anomalies.  Relaxing
   validation constraints on state data is meant to reveal deviations of
   the observed behavior vs. intended behavior of a managed entity and
   hopefully trigger corrective actions by a management system.  From
   that perspective, it is RECOMMENDED to avoid defining constraints on
   state data that would hinder the detection by a management system of
   abnormal behaviors of a managed entity.

[mj] When I read this, it tells me that it is ok to put constraints on state 
data.

[Med] The key part is the reco in the last sentence. I think we have a valid 
path here given what is in 8.1 of 7950 and the provisions in 5.3 of 8342.

What I am hearing on the mailing list, by Juergen and others, is questioning 
the use of constraints on state data. What I am interested in understanding is, 
would there be a problem in dropping/ignoring constraints on state data?

Thanks.

No?

Cheers,
Med

De : netmod mailto:netmod-boun...@ietf.org>> De la 
part de Acee Lindem
Envoyé : vendredi 19 janvier 2024 18:47
À : Andy Bierman mailto:a...@yumaworks.com>>
Cc : Jürgen Schönwälder 
mailto:jschoenwaelder@constructor.university>>;
 YANG Doctors mailto:yang-doct...@ietf.org>>; 
netmod@ietf.org; 
draft-ietf-netmod-rfc8407...@ietf.org
Objet : Re: [netmod] [yang-doctors] Operational State usage of YANG choices and 
constraints (fix draft address)

Hi Andy,

On Jan 19, 2024, at 12:17, Andy Bierman 
mailto:a...@yumaworks.com>> wrote:

On Fri, Jan 19, 2024 at 9:02 AM Acee Lindem 
mailto:acee.i...@gmail.com>> wrote:
Along the same lines, what is the sentiment for “mandatory true” data nodes for 
operational state (i.e., “config false” nodes)? Does this make sense to 
identify data nodes the must be returned if the parent node is returned?

What does "must be returned" mean?

Obviously, it does not mean returning the data even if the filters do not 
select that node. (I hope)
I used to think it meant conformance  (whether the server must implement or may 
implement).
I was told years ago that is not the case. Use if-feature for that. No 
if-feature == mandatory-to-implement.

If a client requests the parent subtree, then how would it know the difference 
between config=false
nodes that are not present vs. the server just decided not to return them (even 
though conformance
to the retrieval operation requires them)?

IMO the mandatory-stmt for config=false nodes does not make any sense at all.

I’m fine with that - we just need to make sure that this is reflected in our 
IETF models. I think these points are worth addressing in RFC8407 BIS.

Thanks,
Acee

Thanks
Acee

Andy

> On Dec 22, 2023, at 2:36 PM, Jürgen Schönwälder 
> mailto:jschoenwaelder@constructor.university>>
>  wrote:
>
> On Fri, Dec 22, 2023 at 07:22:55PM +, Kent Watsen wrote:
>> 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.
>>
>
> What is accurate?
>
> I think the answer is "it depends". There are states that a model
> allows to represent and there are states it does not allow to
> represent. If a device ends up in a state that the model can't
> represent, then the device has a problem, From a debugging point of
> view, the worst is a device in a state that can't be represented
> propoerly reporting a valid state it is not in.
>
> So like everything else, it is a modeling decision, like picking types
> and everything else. I am not sure that 'as accurate as possible" is a
> helpful guideline; for operational state I prefer to see as much as
> possible the device's true state. (But even picking data types for
> leaves restricts what can be represented, so it is a judgement call.)
>
> /js
>
> --
> Jürgen Schönwälder  Constructor University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax

Re: [netmod] [yang-doctors] Operational State usage of YANG choices and constraints (fix draft address)

2024-01-22 Thread mohamed . boucadair

Re-,

I’m afraid that if we call out “mandatory” here, we will need to do the same 
for all the items listed in rfc8342#section-5.3:

   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.

Please let me know your preference.

Thank you.

Cheers,
Med

De : Acee Lindem 
Envoyé : lundi 22 janvier 2024 15:56
À : BOUCADAIR Mohamed INNOV/NET 
Cc : YANG Doctors ; netmod@ietf.org; 
draft-ietf-netmod-rfc8407...@ietf.org
Objet : Re: [netmod] [yang-doctors] Operational State usage of YANG choices and 
constraints (fix draft address)

Hi Med,

On Jan 22, 2024, at 02:44, 
mohamed.boucad...@orange.com wrote:

Hi Acee,

> I think these points are worth addressing in RFC8407 BIS.

We do already have the following in the bis, which I think covers your initial 
question about “mandatory true” data nodes for operational state”:

   Section 8.1 of [RFC7950] includes a provision for defining a
   constraint on state data and specifies that the constraint must be
   true in a valid state data.  However, Section 5.3 of [RFC8342]
   softens that behavior by allowing semantic constraints to be violated
   under some circumstances to help detecting anomalies.  Relaxing
   validation constraints on state data is meant to reveal deviations of
   the observed behavior vs. intended behavior of a managed entity and
   hopefully trigger corrective actions by a management system.  From
   that perspective, it is RECOMMENDED to avoid defining constraints on
   state data that would hinder the detection by a management system of
   abnormal behaviors of a managed entity.

It does cover it with “validation constraints” and “deviations of observed 
behavior”. However, it might be good to explicitly cover “mandatory” since this 
indicates to return a data node rather than suppress data nodes not being 
returned due to validation.

Thanks,
Acee

No?

Cheers,
Med

De : netmod mailto:netmod-boun...@ietf.org>> De la 
part de Acee Lindem
Envoyé : vendredi 19 janvier 2024 18:47
À : Andy Bierman mailto:a...@yumaworks.com>>
Cc : Jürgen Schönwälder 
mailto:jschoenwaelder@constructor.university>>;
 YANG Doctors mailto:yang-doct...@ietf.org>>; 
netmod@ietf.org; 
draft-ietf-netmod-rfc8407...@ietf.org
Objet : Re: [netmod] [yang-doctors] Operational State usage of YANG choices and 
constraints (fix draft address)

Hi Andy,

On Jan 19, 2024, at 12:17, Andy Bierman 
mailto:a...@yumaworks.com>> wrote:

On Fri, Jan 19, 2024 at 9:02 AM Acee Lindem 
mailto:acee.i...@gmail.com>> wrote:
Along the same lines, what is the sentiment for “mandatory true” data nodes for 
operational state (i.e., “config false” nodes)? Does this make sense to 
identify data nodes the must be returned if the parent node is returned?

What does "must be returned" mean?

Obviously, it does not mean returning the data even if the filters do not 
select that node. (I hope)
I used to think it meant conformance  (whether the server must implement or may 
implement).
I was told years ago that is not the case. Use if-feature for that. No 
if-feature == mandatory-to-implement.

If a client requests the parent subtree, then how would it know the difference 
between config=false
nodes that are not present vs. the server just decided not to return them (even 
though conformance
to the retrieval operation requires them)?

IMO the mandatory-stmt for config=false nodes does not make any sense at all.

I’m fine with that - we just need to make sure that this is reflected in our 
IETF models. I think these points are worth addressing in RFC8407 BIS.

Thanks,
Acee

Thanks
Acee

Andy

> On Dec 22, 2023, at 2:36 PM, Jürgen Schönwälder 
> mailto:jschoenwaelder@constructor.university>>
>  wrote:
>
> On Fri, Dec 22, 2023 at 07:22:55PM +, Kent Watsen wrote:
>> 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.
>>
>
> What is accurate?
>
> I think the answer is "it depends". There are states that a model
> allows to represent and there are states it does not allow to
> represent. If a device ends up in a state that the model can't
> represent, then the device has a problem, From a debugging point of
> view, the worst is a device in a state that can't be represented
> propoerly reporting a valid state it is not in.
>
> So like everything else, it is a modeling decision, like picking types
> and everything else. I am not sure that 'as accurate as possible" is a
> helpful guideline; for operational state I prefer to see as much as
> possible the device's true state. (But even picking data types for
> leaves restricts what can be represented, so it is a judgement call.)
>
> /js
>
> --
> Jürgen Schönwälder

Re: [netmod] [yang-doctors] Operational State usage of YANG choices and constraints (fix draft address)

2024-01-21 Thread mohamed . boucadair

Hi Acee,

> I think these points are worth addressing in RFC8407 BIS.

We do already have the following in the bis, which I think covers your initial 
question about “mandatory true” data nodes for operational state”:

   Section 8.1 of [RFC7950] includes a provision for defining a
   constraint on state data and specifies that the constraint must be
   true in a valid state data.  However, Section 5.3 of [RFC8342]
   softens that behavior by allowing semantic constraints to be violated
   under some circumstances to help detecting anomalies.  Relaxing
   validation constraints on state data is meant to reveal deviations of
   the observed behavior vs. intended behavior of a managed entity and
   hopefully trigger corrective actions by a management system.  From
   that perspective, it is RECOMMENDED to avoid defining constraints on
   state data that would hinder the detection by a management system of
   abnormal behaviors of a managed entity.

No?

Cheers,
Med

De : netmod  De la part de Acee Lindem
Envoyé : vendredi 19 janvier 2024 18:47
À : Andy Bierman 
Cc : Jürgen Schönwälder ; YANG Doctors 
; netmod@ietf.org; draft-ietf-netmod-rfc8407...@ietf.org
Objet : Re: [netmod] [yang-doctors] Operational State usage of YANG choices and 
constraints (fix draft address)

Hi Andy,

On Jan 19, 2024, at 12:17, Andy Bierman 
mailto:a...@yumaworks.com>> wrote:

On Fri, Jan 19, 2024 at 9:02 AM Acee Lindem 
mailto:acee.i...@gmail.com>> wrote:
Along the same lines, what is the sentiment for “mandatory true” data nodes for 
operational state (i.e., “config false” nodes)? Does this make sense to 
identify data nodes the must be returned if the parent node is returned?

What does "must be returned" mean?

Obviously, it does not mean returning the data even if the filters do not 
select that node. (I hope)
I used to think it meant conformance  (whether the server must implement or may 
implement).
I was told years ago that is not the case. Use if-feature for that. No 
if-feature == mandatory-to-implement.

If a client requests the parent subtree, then how would it know the difference 
between config=false
nodes that are not present vs. the server just decided not to return them (even 
though conformance
to the retrieval operation requires them)?

IMO the mandatory-stmt for config=false nodes does not make any sense at all.

I’m fine with that - we just need to make sure that this is reflected in our 
IETF models. I think these points are worth addressing in RFC8407 BIS.

Thanks,
Acee

Thanks
Acee

Andy

> On Dec 22, 2023, at 2:36 PM, Jürgen Schönwälder 
> mailto:jschoenwaelder@constructor.university>>
>  wrote:
>
> On Fri, Dec 22, 2023 at 07:22:55PM +, Kent Watsen wrote:
>> 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.
>>
>
> What is accurate?
>
> I think the answer is "it depends". There are states that a model
> allows to represent and there are states it does not allow to
> represent. If a device ends up in a state that the model can't
> represent, then the device has a problem, From a debugging point of
> view, the worst is a device in a state that can't be represented
> propoerly reporting a valid state it is not in.
>
> So like everything else, it is a modeling decision, like picking types
> and everything else. I am not sure that 'as accurate as possible" is a
> helpful guideline; for operational state I prefer to see as much as
> possible the device's true state. (But even picking data types for
> leaves restricts what can be represented, so it is a judgement call.)
>
> /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 

___
yang-doctors mailing list
yang-doct...@ietf.org
https://www.ietf.org/mailman/listinfo/yang-doctors

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

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

2023-12-19 Thread mohamed . boucadair

Hi Mahesh, all,

Thank you for the review and comments. We just posed 
draft-ietf-netmod-acl-extensions-04.

Please see more context inline.

Cheers,
Med

De : netmod  De la part de Mahesh Jethanandani
Envoyé : mardi 5 décembre 2023 23:09
À : Lou Berger 
Cc : NETMOD Group ; NetMod WG Chairs 
Objet : Re: [netmod] WG Last Call: draft-ietf-netmod-acl-extensions-03

Hi,

I do support this work, as it is much needed, and would like to see it 
progress. However, I do believe that the document needs to undergo a revision 
to qualify for LC. Some of the comments are editorial or minor, and can be 
addressed easily, but others are not. They should all be addressed for the WG 
to call the document ready.

- The Security Considerations section has both the read/write nodes and the 
read-only nodes as empty (or marked as TBC, which I imagine stands for To Be 
Completed). This needs to be filled out, or if no nodes are worth any security 
considerations, it should be stated so, and why.

[Med] ACK. We don't repeat what is already in 8519 but focus on key additions 
in the spec: https://github.com/boucadair/enhanced-acl-netmod/pull/65/files

- Isn't the YANG model normative portion of the document? Isn't what this 
document all about? Why is it then in the Appendix?

[Med] We are using a script to generate the IANA modules + we are actually 
following this part from the 8407bis:

   It is RECOMMENDED to include the URL from where to retrieve the
   recent version of the module.  When a script is used, the Internet-
   Draft that defines an IANA-maintained module SHOULD include an
   appendix with the initial full version of the module.  Including such
   an appendix in pre-RFC versions is meant to assess the correctness of
   the outcome of the supplied script.  The authors MUST include a note
   to the RFC Editor requesting that the appendix be removed before
   publication as RFC and that RFC  is replaced with the RFC number
   that is assigned to the document.  Initial versions of IANA-
   maintained modules that are published in RFCs may be misused despite
   the appropriate language to refer to the IANA registry to retrieve
   the up-to-date module.

- Why is the Section titled "Initial Version of the The ICMPv4 Types 
IANA-Maintained Module", when the model in question is 
"iana-icmpv6-ty...@2020-09-25.yang"?
[Med] This was a typo. Fixed.

- 'defined-sets' and 'aliases' have been defined in a the separate model 
'ietf-acl-enh'. Are these sets and aliases defined to be used outside of ACL? 
If that is the case then having them outside the 'ietf-access-control-list' 
model makes sense. Otherwise, almost everything in the 'ietf-acl-enh' is an 
augmentation of the model defined in RFC 8519, as stated in the Introduction of 
the document

[Med] These are defined to be consumed for ACL policies.


"The YANG module in this document is solely based on augmentations to the ACL 
YANG module defined in [RFC8519]."

[Med] The intent was to highlight that we are not using a bis approach. Tweaked 
the paragraph that includes that text for better clarity.

If that is the case I see no reason why those containers should not be 
augmentations into the same model, as in

augment "/acl" {
  container defined-sets {
  
  }

  container aliases {
 ...
  }
}


- I just pulled down the latest version (-03) of the draft, and ran into this 
error.

$ pyang ietf-acl-...@2022-10-24.yang
iana-icmpv6-ty...@2020-09-25.yang:1: 
error: unexpected latest revision "2023-04-28" in 
iana-icmpv6-ty...@2020-09-25.yang, 
should be "2020-09-25".

[Med] Fixed. Thanks.

- Section 3.4. TCP Flags Handling. The document states that.

"Clients that support both 'flags-bitmask' and 'flags' matching fields MUST NOT 
set these fields in the same request.".

Can the model have a must statement to prevent this from being configured 
inadvertently?

[Med] We don't see how to do that with a must statement, hence the normative 
language in the narrative text.

Same for Section 3.5 Fragments Handling
[Med] Same answer :-)

- There should be clear direction to the RFC Editor on what should be done with 
revision dates. The same is true for other placeholder text. For example, what 
is the RFC Editor to do with text "RFC "?
[Med] Done: https://github.com/boucadair/enhanced-acl-netmod/pull/59/files

- References in the YANG model should be expanded to include the title of the 
RFC.

[Med] We are echoing references as listed in an IANA registry, so we do not 
have control over that reference.

- Examples are always good. Not only can they be used to validate the model, 
but users get to understand how it can be used. See other models such as BGP, 
TCP, BFD on how an example can be added.

[Med] We do already have many in the core document. Will consider adding more 
if needed.

- How is this a re

Re: [netmod] [IANA #1291942] RE: Early review: draft-boucadair-netmod-rfc8407bis (IETF 117)

2023-12-18 Thread mohamed . boucadair

Hi all, 

The changes indicated below are now implemented in the public version: 
https://author-tools.ietf.org/iddiff?url2=draft-ietf-netmod-rfc8407bis-06.

Cheers,
Med

> -Message d'origine-
> De : BOUCADAIR Mohamed INNOV/NET
> Envoyé : jeudi 14 décembre 2023 07:39
> À : netmod@ietf.org
> Objet : TR: [IANA #1291942] RE: Early review: draft-boucadair-
> netmod-rfc8407bis (IETF 117)
> 
> Hi all,
> 
> FWIW, I checked with IANA whether the changes [1] made to address
> the comment from Martin [2] are clear enough. Please see below.
> 
> Unless I hear any further comments on these changes, I will
> proceed with the submission of the new version early next week.
> 
> Cheers,
> Med
> 
> [1]: https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-
> netmod-
> rfc8407bis&url_2=https://boucadair.github.io/rfc8407bis/draft-
> ietf-netmod-rfc8407bis.txt
> [2]:
> https://mailarchive.ietf.org/arch/msg/netmod/3_tg5oPbHhNQPbo3mMWy
> 0m0cIzg/
> 
> -Message d'origine-
> De : Amanda Baber via RT  Envoyé : mercredi
> 13 décembre 2023 20:57 À : BOUCADAIR Mohamed INNOV/NET
>  Objet : [IANA #1291942] RE: Early
> review: draft-boucadair-netmod-rfc8407bis (IETF 117)
> 
> Hi Med,
> 
> That works. Thanks!
> 
> Amanda
> 
> On Wed Dec 13 08:34:22 2023, mohamed.boucad...@orange.com wrote:
> > Hi Amanda,
> >
> > Thank you for the review. Unless you have an objection, I will
> forward
> > it to the netmod list.
> >
> > I confirm for 8126. Please let me know if this note in the
> abstract is
> > not that clear:
> >
> > Also, this document updates RFC 8126 by providing additional
> > guidelines for writing the IANA considerations for RFCs that
> specify
> > IANA-maintained modules.
> >
> > Thanks again.
> >
> > 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

Re: [netmod] case + when in 8407bis

2023-12-14 Thread mohamed . boucadair

Re-,

> To be clear, I think the paragraph:
> 
>Some modules use "case + when" construct such as shown in the
> example
>below.  Such a construct MUST be avoided by removing the
> "when"
>statement or using a "container" outside the "choice".
> 
> and the example that follows should be removed.
>

Noted your objection. 

For now, I removed the text from the main, i.e., will be removed from the next 
iteration of the draft that will be submitted early next week.

However, I created a PR (https://github.com/boucadair/rfc8407bis/pull/33/files) 
to keep the discussion running as I think there is room for some guidance 
there. 

I f you consider the example share by Tom, if the "when" is important, removing 
choice/case and define these as container+when for these data nodes is cleaner. 
After all, the check leads to exclusive choices. 

Cheers,
Med

> -Message d'origine-
> De : Martin Björklund 
> Envoyé : jeudi 14 décembre 2023 21:48
> À : BOUCADAIR Mohamed INNOV/NET 
> Cc : netmod@ietf.org
> Objet : Re: [netmod] case + when in 8407bis
> 
> Hi,
> 
> 
> mohamed.boucad...@orange.com wrote:
> > Hi Martin, all,
> >
> > Please remember that RFC8407 includes already the following:
> >
> > ==
> > "when" statement evaluation is generally more expensive than
> > "if-feature" or "choice" statements ==
> 
> Yes, this is fine.  It is something that the module designer can
> keep in mind when designing the module (actually, the text says
> "MAY be considered").
> 
> > I understand that you may have a concern with the MUST NOT
> language,
> > but we do need some guidance for such constraints. If there are
> cases
> > where having both makes sense, we can transform the MUST NOT to
> SHOULD
> > NOT with a guidance when it is OK to maintain that constraint.
> 
> I don't agree that we should have SHOULD NOT either.  It feels
> very arbitrary to have such a statement for this particular
> construct.
> 
> To be clear, I think the paragraph:
> 
>Some modules use "case + when" construct such as shown in the
> example
>below.  Such a construct MUST be avoided by removing the
> "when"
>statement or using a "container" outside the "choice".
> 
> and the example that follows should be removed.
> 
> 
> /martin

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

Re: [netmod] case + when in 8407bis

2023-12-14 Thread mohamed . boucadair

Hi Martin,

Please see inline.

Cheers,
Med

> -Message d'origine-
> De : Martin Björklund 
> Envoyé : jeudi 14 décembre 2023 21:48
> À : BOUCADAIR Mohamed INNOV/NET 
> Cc : netmod@ietf.org
> Objet : Re: [netmod] case + when in 8407bis
> 
> Hi,
> 
> 
> mohamed.boucad...@orange.com wrote:
> > Hi Martin, all,
> >
> > Please remember that RFC8407 includes already the following:
> >
> > ==
> > "when" statement evaluation is generally more expensive than
> > "if-feature" or "choice" statements ==
> 
> Yes, this is fine.  It is something that the module designer can
> keep in mind when designing the module (actually, the text says
> "MAY be considered").
> 

[Med] ACK for the MAY part. However, that excerpt seems to implicitly assume 
that either a "when" is present or "choice". At least this is how I interpret 
that text. No?

> > I understand that you may have a concern with the MUST NOT
> language,
> > but we do need some guidance for such constraints. If there are
> cases
> > where having both makes sense, we can transform the MUST NOT to
> SHOULD
> > NOT with a guidance when it is OK to maintain that constraint.
> 
> I don't agree that we should have SHOULD NOT either.  It feels
> very arbitrary to have such a statement for this particular
> construct.
> 
> To be clear, I think the paragraph:
> 
>Some modules use "case + when" construct such as shown in the
> example
>below.  Such a construct MUST be avoided by removing the
> "when"
>statement or using a "container" outside the "choice".
> 
> and the example that follows should be removed.
> 
> 
> /martin

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

Re: [netmod] case + when in 8407bis

2023-12-14 Thread mohamed . boucadair

Hi Martin, all,

Please remember that RFC8407 includes already the following:

==
"when" statement evaluation is generally more expensive than "if-feature" or 
"choice" statements
==

I understand that you may have a concern with the MUST NOT language, but we do 
need some guidance for such constraints. If there are cases where having both 
makes sense, we can transform the MUST NOT to SHOULD NOT with a guidance when 
it is OK to maintain that constraint.

Thanks. 

Cheers,
Med

> -Message d'origine-
> De : Martin Björklund 
> Envoyé : lundi 11 décembre 2023 09:43
> À : BOUCADAIR Mohamed INNOV/NET 
> Cc : netmod@ietf.org
> Objet : Re: [netmod] case + when in 8407bis
> 
> Hi,
> 
> mohamed.boucad...@orange.com wrote:
> > Re-,
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> > > -Message d'origine-
> > > De : Martin Björklund  Envoyé : vendredi 8
> > > décembre 2023 17:35 À : BOUCADAIR Mohamed INNOV/NET
> > >  Cc : netmod@ietf.org Objet :
> Re:
> > > [netmod] case + when in 8407bis
> > >
> > > mohamed.boucad...@orange.com wrote:
> > > > Re-,
> > > >
> > > > There was an invitation to review the changes:
> > >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> Fma
> > >
> il%2F&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C94804503f64
> c47
> > >
> c5e08708dbfa252a29%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6
> 383
> > >
> 78809765220362%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
> oiV
> > >
> 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=BGyJa
> Mq6
> > > i%2B6eh9zd0kRX8oAGJ33x4nFW8XVB9L15E8w%3D&reserved=0
> > > archive.ietf.org%2Farch%2Fmsg%2Fnetmod%2F4NDzo7SLinue-
> > >
> CeHGRyOD6aWXHI%2F&data=05%7C01%7Cmohamed.boucadair%40orange.com%7
> Cde
> > > eb
> > >
> 1242f9e74a43da5208dbf80baf06%7C90c7a20af34b40bfbc48b9253b6f5d20%7
> C0%
> > > 7C
> > >
> 0%7C638376501320001779%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
> AiL
> > > CJ
> > >
> QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata
> =k4
> > > pc 95TknbyhSk4duRn%2Brt6vlTPOchzrsVbFOiuYv4M%3D&reserved=0,
> but no
> > > follow-up.
> > > >
> > > > Do you have any concern with that part? Thanks.
> > >
> > > I do, but I suspect that there is a reason for this rule, so
> I'd
> > > like to understand that.  (I have some faint memory of such a
> > > discussion on the list, but I may be wrong).
> > >
> > > My objection is (1) why should this legal construct not be
> used and
> >
> > [Med] The reasoning is: What would be intuitive is to see a
> model use
> > either of these approaches rather than both. This questions the
> need
> > for the choice/case statement in the first place.
> 
> Ok.  I object to this recommendation.  It is a valid construct,
> and if the model designer thinks that the model is best when this
> consruct is used, they should be allowed to use it.
> 
> 
> /martin
> 
> 
> 
> 
> >
> > > (2) I don't think the proposed workaround is correct, since
> if you
> > > move the when to a container that surrounds the entire
> choice, the
> > > other cases in the choice are also made conditional.
> >
> > [Med] Actually, that's not what the text intends to say. The
> proposal
> > is to consider getting rid of choice.
> >
> > >
> > >
> > >
> > > /martin
> >
> _
> _
> > __
> > 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.
> >

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

[netmod] TR: [IANA #1291942] RE: Early review: draft-boucadair-netmod-rfc8407bis (IETF 117)

2023-12-13 Thread mohamed . boucadair

Hi all,

FWIW, I checked with IANA whether the changes [1] made to address the comment 
from Martin [2] are clear enough. Please see below. 

Unless I hear any further comments on these changes, I will proceed with the 
submission of the new version early next week.

Cheers,
Med

[1]: 
https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-netmod-rfc8407bis&url_2=https://boucadair.github.io/rfc8407bis/draft-ietf-netmod-rfc8407bis.txt
[2]: https://mailarchive.ietf.org/arch/msg/netmod/3_tg5oPbHhNQPbo3mMWy0m0cIzg/

-Message d'origine-
De : Amanda Baber via RT  
Envoyé : mercredi 13 décembre 2023 20:57
À : BOUCADAIR Mohamed INNOV/NET 
Objet : [IANA #1291942] RE: Early review: draft-boucadair-netmod-rfc8407bis 
(IETF 117)

Hi Med,

That works. Thanks!

Amanda

On Wed Dec 13 08:34:22 2023, mohamed.boucad...@orange.com wrote:
> Hi Amanda,
> 
> Thank you for the review. Unless you have an objection, I will forward 
> it to the netmod list.
> 
> I confirm for 8126. Please let me know if this note in the abstract is 
> not that clear:
> 
> Also, this document updates RFC 8126 by providing additional 
> guidelines for writing the IANA considerations for RFCs that specify 
> IANA-maintained modules.
> 
> Thanks again.
> 
> Cheers,
> Med
> 
> > -Message d'origine-
> > De : Amanda Baber via RT  Envoyé : mardi 12 
> > décembre 2023 19:57 À : BOUCADAIR Mohamed INNOV/NET 
> >  Cc : bill...@huawei.com Objet : [IANA 
> > #1291942] RE: Early review: draft-boucadair-netmod- rfc8407bis (IETF 
> > 117)
> >
> > Hi Med,
> >
> > This is clear enough for us. Thanks!
> >
> > Sabrina had a question about the fact that it's updated RFC 8126: is 
> > this on account of Section 4.30.3, "Guidance for Writing the IANA 
> > Considerations for RFCs Defining IANA-Maintained Modules," or for 
> > another reason?
> >
> > Amanda
> >
> > On Fri Dec 08 07:56:38 2023, mohamed.boucad...@orange.com wrote:
> > > Hi Amanda,
> > >
> > > We received yesterday a comment from Martin (echoing if I'm not 
> > > mistaken a discussion yangdoctors had with IANA).
> > >
> > > I updated the 8407bis as can be seen in the diff: https://author-
> > > tools.ietf.org/api/iddiff?doc_1=draft-ietf-netmod-
> > >
> > rfc8407bis&url_2=https://eur03.safelinks.protection.outlook.com/?url
> > =http%3A%2F%2Fh%2F&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Cb
> > 237e6d6859741f8878408dbfc159f94%7C90c7a20af34b40bfbc48b9253b6f5d20%7
> > C0%7C0%7C638380942381059264%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw
> > MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&s
> > data=1WLN6iL5JsdGdL0If6%2BjcaReCtYgnaHTt2Dc%2BTXzah8%3D&reserved=0
> > > ttps%3A%2F%2Fboucadair.github.io%2Frfc8407bis%2Fdraft-ietf-
> > &data=05%7C
> > >
> > 01%7Cmohamed.boucadair%40orange.com%7C5a8baffaa60348bf544708dbfb444c
> > 9b
> > >
> > %7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638380043664326163%7CU
> > nk
> > >
> > nown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
> > Ww
> > >
> > iLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=ieawrY3uT%2Bohkw97Ha3d5wGBqJWv
> > iB
> > > YNRz3hZRoiWYU%3D&reserved=0
> > > netmod-rfc8407bis.txt
> > >
> > > The full text can be seen at:
> > >
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbo
> > uc%2F&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Cb237e6d6859741
> > f8878408dbfc159f94%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6383
> > 80942381059264%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
> > 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=76vf6mmq
> > TKU5DRIRJ2hANms%2Bl0%2BabgpoBkG1eC8%2Byjs%3D&reserved=0
> > > adair.github.io%2Frfc8407bis%2Fdraft-ietf-netmod-
> > &data=05%7C01%7Cmoham
> > >
> > ed.boucadair%40orange.com%7C5a8baffaa60348bf544708dbfb444c9b%7C90c7a
> > 20
> > >
> > af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638380043664326163%7CUnknown%7CT
> > WF
> > >
> > pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI
> > 6M
> > >
> > n0%3D%7C1000%7C%7C%7C&sdata=fhBywi6ULrGZaRIZHpfGUsOkC%2FuwaaZPBeFncm
> > HB
> > > Xyk%3D&reserved=0
> > > rfc8407bis.html
> > >
> > > Can you please let me know if the changes are clear enough for 
> > > IANA?
> > > Thanks.
> > >
> > > Cheers,
> > > Med
> > >
> > > > -Message d'origine-
> > > > De : Amanda Baber via RT  Envoyé : jeudi 
> > > > 17 août 2023 22:02 Cc : BOUCADAIR Mohamed INNOV/NET 
> > > > ; bill...@huawei.com Objet : [IANA 
> > > > #1277027] Early review: draft-boucadair-netmod- rfc8407bis (IETF
> > > > 117)
> > > >
> > > > Hi Med,
> > > >
> > > > Sorry about the delay. I managed to get COVID immediately after
> > the
> > > > meeting. This looks good, and I did look through Section 5.3.
> > We'll
> > > > make sure this is documented internally.
> > > >
> > > > thanks,
> > > > Amanda
> > > >
> > > > On Fri Jul 21 05:56:51 2023, mohamed.boucad...@orange.com wrote:
> > > > > Hi Amanda,
> > > > >
> > > > > Thank you for the review.
> > > > >
> > > > > I updated the text as per your feedback:
> > > > >
> > > >
> >

Re: [netmod] case + when in 8407bis

2023-12-08 Thread mohamed . boucadair

Re-, 

Please see inline. 

Cheers,
Med

> -Message d'origine-
> De : Martin Björklund 
> Envoyé : vendredi 8 décembre 2023 17:35
> À : BOUCADAIR Mohamed INNOV/NET 
> Cc : netmod@ietf.org
> Objet : Re: [netmod] case + when in 8407bis
> 
> mohamed.boucad...@orange.com wrote:
> > Re-,
> >
> > There was an invitation to review the changes:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
> archive.ietf.org%2Farch%2Fmsg%2Fnetmod%2F4NDzo7SLinue-
> CeHGRyOD6aWXHI%2F&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Cdeeb
> 1242f9e74a43da5208dbf80baf06%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C
> 0%7C638376501320001779%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ
> QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=k4pc
> 95TknbyhSk4duRn%2Brt6vlTPOchzrsVbFOiuYv4M%3D&reserved=0, but no
> follow-up.
> >
> > Do you have any concern with that part? Thanks.
> 
> I do, but I suspect that there is a reason for this rule, so I'd like
> to understand that.  (I have some faint memory of such a discussion on
> the list, but I may be wrong).
> 
> My objection is (1) why should this legal construct not be used and

[Med] The reasoning is: What would be intuitive is to see a model use either of 
these approaches rather than both. This questions the need for the choice/case 
statement in the first place.

> (2) I don't think the proposed workaround is correct, since if you
> move the when to a container that surrounds the entire choice, the
> other cases in the choice are also made conditional.

[Med] Actually, that's not what the text intends to say. The proposal is to 
consider getting rid of choice. 

> 
> 
> 
> /martin

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

Re: [netmod] URLs from where to retrieve the latest version of an IANA module RE: New guidelines for IANA in draft-ietf-netmod-rfc8407bis

2023-12-08 Thread mohamed . boucadair

Re-,



> -Message d'origine-
> De : Martin Björklund 
> Envoyé : vendredi 8 décembre 2023 17:31
> À : BOUCADAIR Mohamed INNOV/NET 
> Cc : netmod@ietf.org
> Objet : Re: URLs from where to retrieve the latest version of an IANA
> module RE: [netmod] New guidelines for IANA in draft-ietf-netmod-
> rfc8407bis
> 
> mohamed.boucad...@orange.com wrote:
> > Re-,
> >
> > > I cannot find the reference [IANA_FOO_URL].
> >
> > That's normal. That is defined as a generic reference whenever we
> need
> > in the bis to point to the latest version of a module.
> 
> The problem is that "[IANA_FOO_URL]" looks like a reference, but it is
> not present in the References section.  I can also not find where it
> is defined as a generic reference.

[Med] Please see the last para in Section 4.30.2.

  Perhaps it should be just
> "IANA_FOO_URL" and also defined in section 2?
> 

[Med] No problem to use that in the narrative text, but I still prefer leave it 
as such in the template (4.30.3.1.)

   When this registry is modified, the YANG module "iana-foo"
   [IANA_FOO_URL] must be updated as defined in RFC. 

> 
> /martin
> 
> 
> 
> >
> > I made the following change to have both the parent link and
> > per-revision one:
> >
> > ==
> > OLD:
> >Examples of IANA URLs from where to retrieve the latest version
> of an
> >IANA-maintained module are: [IANA_BGP-L2_URL], [IANA_PW-
> Types_URL],
> >and [IANA_BFD_URL].  [IANA_FOO_URL] is used in the following to
> refer
> >to such URLs.  These URLs are expected to be sufficiently
> permanent
> >and stable.
> >
> > NEW:
> >Examples of IANA URLs from where to retrieve the latest version
> of an
> >IANA-maintained module are: [IANA_BGP-L2_URL], [IANA_PW-
> Types_URL],
> >and [IANA_BFD_URL].  [IANA_FOO_URL] is used in the following to
> refer
> >to such URLs.  These URLs are expected to be sufficiently
> permanent
> >and stable.  Whenever referencing a specific version of an IANA-
> >maintained module is needed, then URLs such as
> >[IANA_BGP-L2_URL-Revision] are used.  [IANA_FOO_URL_With_REV] is
> used
> >in the following to refer to such URLs.
> > ==
> >
> > IANA_FOO_URL can be used in the description, cross-reference
> purposes,
> > and importing any available latest version.
> >
> > IANA_FOO_URL_With_REV can be used in revisions or when importing
> > specific version of module (for whatever reason).
> >
> > Cheers,
> > Med
> >
> > > -Message d'origine-
> > > De : Martin Björklund  Envoyé : vendredi 8
> > > décembre 2023 09:07 À : BOUCADAIR Mohamed INNOV/NET
> > >  Cc : netmod@ietf.org Objet : Re:
> > > [netmod] New guidelines for IANA in draft-ietf-netmod- rfc8407bis
> > >
> > > Hi,
> > >
> > > mohamed.boucad...@orange.com wrote:
> > > > Hi Martin,
> > > >
> > > > Thanks for raising these points.
> > > >
> > > > Please see inline.
> > > >
> > > > Cheers,
> > > > Med
> > > >
> > > > > -Message d'origine-
> > > > > De : netmod  De la part de Martin
> > > Björklund
> > > > > Envoyé : jeudi 7 décembre 2023 17:05 À : netmod@ietf.org
> Objet :
> > > > > [netmod] New guidelines for IANA in draft-ietf-netmod-
> > > > > rfc8407bis
> > > > >
> > > > > Hi,
> > > > >
> > > > > There has been some discussion with IANA on the YANG doctors
> > > > > list regarding this text in section 4.8 in RFC 8407:
> > > > >
> > > > >A "revision" statement MUST be present for each published
> > > version
> > > > > of
> > > > >the module.  The "revision" statement MUST have a
> "reference"
> > > > >substatement.  It MUST identify the published document that
> > > > > contains
> > > > >the module.
> > > > >
> > > > > (the same text is present in rfc8407bis)
> > > > >
> > > > > It continues with the motivation behind the rule:
> > > > >
> > > > >Modules are often extracted from their original
> > > > >documents, and it is useful for developers and operators to
> > > know
> > > > > how
> > > > >to find the original source document in a consistent
> manner.
> > > > >
> > > > > As can be seen in e.g.,
> > > > >
> > >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> > > w%
> > >
> 2F&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C8778e705b2e34e997
> > > 90
> > >
> 808dbf7c4c75c%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638376196
> > > 75
> > >
> 3722174%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi
> > > LC
> > >
> JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Fxf8A2Rg8DoawhFAJ
> > > qe xoKe%2BReEruxK23PK1BYY5UAQ%3D&reserved=0.
> > > > > iana.org%2Fassignments%2Fyang-parameters%2Fiana-dns-class-rr-
> > > > > type%402023-11-
> > > > >
> > >
> 08.yang&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Ccf5ad65dd26d
> > > > > 4a
> > > > >
> > >
> e3a1f508dbf73e4f79%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6383
> > > > > 75
> > > > >
> > >
> 619746432780%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
> > > > > uM
> > > > >
> > >
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2

Re: [netmod] case + when in 8407bis

2023-12-08 Thread mohamed . boucadair

Re-,

There was an invitation to review the changes: 
https://mailarchive.ietf.org/arch/msg/netmod/4NDzo7SLinue-CeHGRyOD6aWXHI/, but 
no follow-up.

Do you have any concern with that part? Thanks.

Cheers,
Med

> -Message d'origine-
> De : netmod  De la part de Martin Björklund
> Envoyé : vendredi 8 décembre 2023 11:47
> À : netmod@ietf.org
> Objet : [netmod] case + when in 8407bis
> 
> Hi,
> 
> rfc8407bis has this text:
> 
>Some modules use "case + when" construct such as shown in the
> example
>below.  Such a construct MUST be avoided by removing the "when"
>statement or using a "container" outside the "choice".
> 
>  case yang-datastore {
>when 'derived-from-or-self(ex:source-type, "ex:yang-
> datastore")';
>description
>  "Example data source for local or remote YANG datastore.";
>...
>  }
> 
> Can you point me to the discussion about this?  I searched the
> archives but didn't find anything.
> 
> 
> /martin
> 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fnetmod&data=05%7C01%7Cmohamed.boucadai
> r%40orange.com%7C9b02ddd4750d4649ef0908dbf7db015b%7C90c7a20af34b40bfbc
> 48b9253b6f5d20%7C0%7C0%7C638376292213677090%7CUnknown%7CTWFpbGZsb3d8ey
> JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C300
> 0%7C%7C%7C&sdata=vd8%2Fetx2tzEpwGG97kPTrA2cJTb4nD5o740eVFOEpsY%3D&rese
> rved=0

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

This message and its attachments 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] URLs from where to retrieve the latest version of an IANA module RE: New guidelines for IANA in draft-ietf-netmod-rfc8407bis

2023-12-08 Thread mohamed . boucadair

Re-,

> I cannot find the reference [IANA_FOO_URL].  

That's normal. That is defined as a generic reference whenever we need in the 
bis to point to the latest version of a module. 

I made the following change to have both the parent link and per-revision one:

==
OLD:
   Examples of IANA URLs from where to retrieve the latest version of an
   IANA-maintained module are: [IANA_BGP-L2_URL], [IANA_PW-Types_URL],
   and [IANA_BFD_URL].  [IANA_FOO_URL] is used in the following to refer
   to such URLs.  These URLs are expected to be sufficiently permanent
   and stable. 

NEW:
   Examples of IANA URLs from where to retrieve the latest version of an
   IANA-maintained module are: [IANA_BGP-L2_URL], [IANA_PW-Types_URL],
   and [IANA_BFD_URL].  [IANA_FOO_URL] is used in the following to refer
   to such URLs.  These URLs are expected to be sufficiently permanent
   and stable.  Whenever referencing a specific version of an IANA-
   maintained module is needed, then URLs such as
   [IANA_BGP-L2_URL-Revision] are used.  [IANA_FOO_URL_With_REV] is used
   in the following to refer to such URLs.
==

IANA_FOO_URL can be used in the description, cross-reference purposes, and 
importing any available latest version. 

IANA_FOO_URL_With_REV can be used in revisions or when importing specific 
version of module (for whatever reason).  

Cheers,
Med

> -Message d'origine-
> De : Martin Björklund 
> Envoyé : vendredi 8 décembre 2023 09:07
> À : BOUCADAIR Mohamed INNOV/NET 
> Cc : netmod@ietf.org
> Objet : Re: [netmod] New guidelines for IANA in draft-ietf-netmod-
> rfc8407bis
> 
> Hi,
> 
> mohamed.boucad...@orange.com wrote:
> > Hi Martin,
> >
> > Thanks for raising these points.
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> > > -Message d'origine-
> > > De : netmod  De la part de Martin
> Björklund
> > > Envoyé : jeudi 7 décembre 2023 17:05 À : netmod@ietf.org Objet :
> > > [netmod] New guidelines for IANA in draft-ietf-netmod- rfc8407bis
> > >
> > > Hi,
> > >
> > > There has been some discussion with IANA on the YANG doctors list
> > > regarding this text in section 4.8 in RFC 8407:
> > >
> > >A "revision" statement MUST be present for each published
> version
> > > of
> > >the module.  The "revision" statement MUST have a "reference"
> > >substatement.  It MUST identify the published document that
> > > contains
> > >the module.
> > >
> > > (the same text is present in rfc8407bis)
> > >
> > > It continues with the motivation behind the rule:
> > >
> > >Modules are often extracted from their original
> > >documents, and it is useful for developers and operators to
> know
> > > how
> > >to find the original source document in a consistent manner.
> > >
> > > As can be seen in e.g.,
> > >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww%
> 2F&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C8778e705b2e34e99790
> 808dbf7c4c75c%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63837619675
> 3722174%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC
> JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Fxf8A2Rg8DoawhFAJqe
> xoKe%2BReEruxK23PK1BYY5UAQ%3D&reserved=0.
> > > iana.org%2Fassignments%2Fyang-parameters%2Fiana-dns-class-rr-
> > > type%402023-11-
> > >
> 08.yang&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Ccf5ad65dd26d
> > > 4a
> > >
> e3a1f508dbf73e4f79%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6383
> > > 75
> > >
> 619746432780%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
> > > uM
> > >
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=X6s86KFMCkdu
> > > 03 Z6hne6g16fU405pTiLPhv5gZYZV4k%3D&reserved=0,
> > > this rule has not been followed.
> > >
> > > The discussion ended with the recommendation to IANA to always add
> a
> > > "reference" statement that refers to the published module (e.g.,
> > >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww%
> 2F&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C8778e705b2e34e99790
> 808dbf7c4c75c%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63837619675
> 3722174%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC
> JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Fxf8A2Rg8DoawhFAJqe
> xoKe%2BReEruxK23PK1BYY5UAQ%3D&reserved=0.
> > > iana.org%2Fassignments%2Fyang-parameters%2Fiana-dns-class-rr-
> > > type%402023-11-
> > >
> 08.yang&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Ccf5ad65dd26d
> > > 4a
> > >
> e3a1f508dbf73e4f79%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6383
> > > 75
> > >
> 619746432780%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
> > > uM
> > >
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=X6s86KFMCkdu
> > > 03 Z6hne6g16fU405pTiLPhv5gZYZV4k%3D&reserved=0).
> > >
> > > If people agree that this is the correct solution, I think we
> should
> > > update 8407bis with this.
> > >
> > > Specifically, I suggest to change 4.30.3.1 and 4.30.3.2:
> > >
> > > OLD:
> > >
> > > When the "iana-foo" YANG module i

[netmod] iana-template RE: New guidelines for IANA in draft-ietf-netmod-rfc8407bis

2023-12-08 Thread mohamed . boucadair

Hi Martin, 

> Ok.  Perhaps we should include an explicit template for IANA-
> maintained modules in an appendix, just like we do with IETF-modules
> in appendix B?

Let's see if we can agree on a template. Feel free to review:

==
module iana-template {
  yang-version 1.1;

  // replace this string with a unique namespace URN value

  namespace "urn:ietf:params:xml:ns:yang:iana-template";

  // replace with the assigned prefix

  prefix iana-foo;

  organization
"Internet Assigned Numbers Authority (IANA)";

  contact
"Internet Assigned Numbers Authority

 ICANN
 12025 Waterfront Drive, Suite 300
 Los Angeles, CA 90094

 Tel: +1 424 254 5300

 ";

  description
"This module defines a template for IANA-maintained modules.

 Copyright (c)  IETF Trust and the persons 
 identified as authors of the code.  All rights reserved.

 Redistribution and use in source and binary forms, with or
 without modification, is permitted pursuant to, and subject to
 the license terms contained in, the Simplified BSD License set
 forth in Section 4.c of the IETF Trust's Legal Provisions
 Relating to IETF Documents
 (https://trustee.ietf.org/license-info).

 The initial version of this YANG module is part of RFC ; see 
 the RFC itself for full legal notices.

  // RFC Ed.: replace  with actual RFC number and remove
  // this note

  // If a script is used, complete with the script information

 This version of this YANG module was generated from the
 corresponding IANA registry using an .

  // RFC Ed.: replace the URL and remove this note

 The latest version of this YANG module is available at
 .";

  // replace with the registry name and the URL of the IANA registry

  reference
"Registry Name (URL)";


  // replace 'date-revision' with the module publication date
  // the format is (year-month-day)

  revision date-revision {
description
  "Indicates the list of changes";
reference
  "URL of the latest version of the module";
  }

  // replace 'date-initial' with the module publication date
  // the format is (year-month-day)

  revision date-initial {
description
  "Initial version";
reference
  "URL of the published initial version of the module
   RFC : RFC Title";

  // RFC Ed.: Update with the RFC number and title 
  // of the RFC that defined the initial version of
  // the module and remove this not
  }

  // identity statements
  // typedef statements
} 
==

Cheers,
Med

[1]: 
https://github.com/boucadair/rfc8407bis/blob/main/templates/iana-template.yang

> -Message d'origine-
> De : Martin Björklund 
> Envoyé : vendredi 8 décembre 2023 09:07
> À : BOUCADAIR Mohamed INNOV/NET 
> Cc : netmod@ietf.org
> Objet : Re: [netmod] New guidelines for IANA in draft-ietf-netmod-
> rfc8407bis
> 
> Hi,
> 
> mohamed.boucad...@orange.com wrote:
> > Hi Martin,
> >
> > Thanks for raising these points.
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> > > -Message d'origine-
> > > De : netmod  De la part de Martin
> Björklund
> > > Envoyé : jeudi 7 décembre 2023 17:05 À : netmod@ietf.org Objet :
> > > [netmod] New guidelines for IANA in draft-ietf-netmod- rfc8407bis
> > >
> > > Hi,
> > >
> > > There has been some discussion with IANA on the YANG doctors list
> > > regarding this text in section 4.8 in RFC 8407:
> > >
> > >A "revision" statement MUST be present for each published
> version
> > > of
> > >the module.  The "revision" statement MUST have a "reference"
> > >substatement.  It MUST identify the published document that
> > > contains
> > >the module.
> > >
> > > (the same text is present in rfc8407bis)
> > >
> > > It continues with the motivation behind the rule:
> > >
> > >Modules are often extracted from their original
> > >documents, and it is useful for developers and operators to
> know
> > > how
> > >to find the original source document in a consistent manner.
> > >
> > > As can be seen in e.g.,
> > >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww%
> 2F&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C8778e705b2e34e99790
> 808dbf7c4c75c%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63837619675
> 3722174%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC
> JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Fxf8A2Rg8DoawhFAJqe
> xoKe%2BReEruxK23PK1BYY5UAQ%3D&reserved=0.
> > > iana.org%2Fassignments%2Fyang-parameters%2Fiana-dns-class-rr-
> > > type%402023-11-
> > >
> 08.yang&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Ccf5ad65dd26d
> > > 4a
> > >
> e3a1f508dbf73e4f79%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6383
> > > 75
> > >
> 619746432780%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
> > > uM
> > >
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=X6s86KFMCkdu
> > > 03 Z6hne6g16fU405pTiLPhv5gZYZV4k%3D&reserved=0,
> > > this rule has not been followed.
>

Re: [netmod] New guidelines for IANA in draft-ietf-netmod-rfc8407bis

2023-12-07 Thread mohamed . boucadair

Hi Martin,

Thanks for raising these points. 

Please see inline. 

Cheers,
Med

> -Message d'origine-
> De : netmod  De la part de Martin Björklund
> Envoyé : jeudi 7 décembre 2023 17:05
> À : netmod@ietf.org
> Objet : [netmod] New guidelines for IANA in draft-ietf-netmod-
> rfc8407bis
> 
> Hi,
> 
> There has been some discussion with IANA on the YANG doctors list
> regarding this text in section 4.8 in RFC 8407:
> 
>A "revision" statement MUST be present for each published version
> of
>the module.  The "revision" statement MUST have a "reference"
>substatement.  It MUST identify the published document that
> contains
>the module.
> 
> (the same text is present in rfc8407bis)
> 
> It continues with the motivation behind the rule:
> 
>Modules are often extracted from their original
>documents, and it is useful for developers and operators to know
> how
>to find the original source document in a consistent manner.
> 
> As can be seen in e.g.,
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> iana.org%2Fassignments%2Fyang-parameters%2Fiana-dns-class-rr-
> type%402023-11-
> 08.yang&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Ccf5ad65dd26d4a
> e3a1f508dbf73e4f79%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638375
> 619746432780%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=X6s86KFMCkdu03
> Z6hne6g16fU405pTiLPhv5gZYZV4k%3D&reserved=0,
> this rule has not been followed.
> 
> The discussion ended with the recommendation to IANA to always add a
> "reference" statement that refers to the published module (e.g.,
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> iana.org%2Fassignments%2Fyang-parameters%2Fiana-dns-class-rr-
> type%402023-11-
> 08.yang&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Ccf5ad65dd26d4a
> e3a1f508dbf73e4f79%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638375
> 619746432780%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=X6s86KFMCkdu03
> Z6hne6g16fU405pTiLPhv5gZYZV4k%3D&reserved=0).
> 
> If people agree that this is the correct solution, I think we should
> update 8407bis with this.
> 
> Specifically, I suggest to change 4.30.3.1 and 4.30.3.2:
> 
> OLD:
> 
> When the "iana-foo" YANG module is updated, a new "revision"
> statement with a unique revision date must be added in front of the
> existing revision statements.
> 
> NEW:
> 
> When the "iana-foo" YANG module is updated, a new "revision"
> statement with a unique revision date must be added in front of the
> existing revision statements.  The "revision" statement must have a
> "reference" substatement that to the published module (e.g.,
>  ...)
> 
> 

[Med] Looks reasonable to me. As you can see in the proposed PR 
(https://github.com/boucadair/rfc8407bis/pull/31/files) I went with a slightly 
modified wording because we do already have the following to refer to the link 
to be used:

   Examples of IANA URLs from where to retrieve the latest version of an
   IANA-maintained module are: [IANA_BGP-L2_URL], [IANA_PW-Types_URL],
   and [IANA_BFD_URL].  [IANA_FOO_URL] is used in the following to refer
   to such URLs.  These URLs are expected to be sufficiently permanent
   and stable.

The change is consistent with this part of the bis:

   If an IANA-maintained module is imported by another module, a
   normative reference with the IANA URL from where to retrieve the
   IANA-maintained module SHOULD be included.  Although not encouraged,
   referencing the RFC that defines the initial version of the IANA
   module is acceptable in specific cases (e.g., the imported version is
   specifically the initial version, ...

> 
> 
> Further, some IANA modules use the IETF template for the module's
> "description", see e.g.,
> 
> That module has in its "description":
> 
>  This version of this YANG module is part of RFC 8294; see
>  the RFC itself for full legal notices.";
> 
> But that is not correct.  Other module use this instead:
> 
>  The initial version of this YANG module is part of RFC 7224;
>  see the RFC itself for full legal notices.";
> 
> I think 8407bis should recommend that IANA-maintained modules use this
> wording instead.
> 

[Med] Good point. Made this change so far: 

OLD:
   For both cases, the document that defines an IANA-maintained module
   MUST include a note indicating that the document is only documenting
   the initial version of the module and that the authoritative version
   is to be retrieved from the IANA registry.

NEW:
   For both cases, the document that defines an IANA-maintained module
   MUST include a note indicating that the document is only documenting
   the initial version of the module and that the authoritative version
   is to be retrieved from the IANA registry. Also, the IANA-maintained 
   module MUST include the following note indicating the RFC that 
   reg

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

2023-12-01 Thread mohamed . boucadair

Hi all, 

This minor revision include some text about content of revision statements for 
revised modules in bis RFCs, typically. It also reminds that the summary of 
changes should be anyway provided in the document as per "Guidelines to Authors 
of Internet-Drafts". 

6991bis is used as an example.

Cheers,
Med 

> -Message d'origine-
> De : I-D-Announce  De la part de
> internet-dra...@ietf.org
> Envoyé : vendredi 1 décembre 2023 11:37
> À : i-d-annou...@ietf.org
> Cc : netmod@ietf.org
> Objet : I-D Action: draft-ietf-netmod-rfc8407bis-05.txt
> 
> Internet-Draft draft-ietf-netmod-rfc8407bis-05.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: Mohamed Boucadair
> Qin Wu
>Name:draft-ietf-netmod-rfc8407bis-05.txt
>Pages:   78
>Dates:   2023-12-01
> 
> Abstract:
> 
>This memo provides guidelines for authors and reviewers of
>specifications containing YANG modules, including IANA-maintained
>modules.  Recommendations and procedures are defined, which are
>intended to increase interoperability and usability of Network
>Configuration Protocol (NETCONF) and RESTCONF protocol
>implementations that utilize YANG modules.  This document obsoletes
>RFC 8407.
> 
>Also, this document updates RFC 8126 by providing additional
>guidelines for writing the IANA considerations for RFCs that
> specify
>IANA-maintained modules.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Fdraft-ietf-netmod-
> rfc8407bis%2F&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C303156a8
> 34e948ff999d08dbf2598886%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C
> 638370238575567395%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo
> iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=yTjG53lF
> kgm9uyUZkWubN%2FDmrc6yLsfNg9LIiLNII78%3D&reserved=0
> 
> There is also an HTML version available at:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Farchive%2Fid%2Fdraft-ietf-netmod-rfc8407bis-
> 05.html&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C303156a834e948
> ff999d08dbf2598886%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638370
> 238575567395%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=X6RBJTnrESy4TD
> eJVZJe%2FIef9p5%2Bj%2BW36n34%2BPnUYI8%3D&reserved=0
> 
> A diff from the previous version is available at:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauth
> or-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-netmod-rfc8407bis-
> 05&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C303156a834e948ff999
> d08dbf2598886%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63837023857
> 5567395%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC
> JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=1JpSew8YQQqhppEHdPn
> %2FUoWpiHlduFc%2FDniwJvwPOm0%3D&reserved=0
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 
> 
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fi-d-
> announce&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C303156a834e94
> 8ff999d08dbf2598886%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63837
> 0238575567395%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu
> MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=0dRChQycpjVIo
> 8KZjA1Jxh7zLyPJ2VhTLI41r6bvbk8%3D&reserved=0


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

This message and its attachments 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

Re: [netmod] [saag] draft-ietf-netmod-rfc8407bis: YANG Security Template

2023-12-01 Thread mohamed . boucadair

Hi Michael,

Thanks. 

Do you mean move it before the text starting with "Each specification ..". If 
so, I don't think the flow would be OK as that text applies for all modules, 
including 8791. 

Cheers,
Med

> -Message d'origine-
> De : Michael Richardson 
> Envoyé : dimanche 26 novembre 2023 16:18
> À : BOUCADAIR Mohamed INNOV/NET ;
> s...@ietf.org; Qin Wu (bill...@huawei.com) 
> Objet : Re: [saag] draft-ietf-netmod-rfc8407bis: YANG Security
> Template
> 
> 
> mohamed.boucad...@orange.com wrote:
> > The Security template used in documents that specify YANG
> modules is
> > stable since years now. FYI, we are in the process of preparing
> > RFC8407bis, so we would welcome comments on that part:
> > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-
> rfc8407bis-04#name-security-considerations-sec
> 
> I see the exception for documents that are based upon RFC8791.
> I think it's probably enough, but maybe I'd move that paragraph
> earlier.
> 
> 
> --
> Michael Richardson , Sandelman Software Works
>  -= IPv6 IoT consulting =-  *I*LIKE*TRAINS*
> 
> 

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

Re: [netmod] [saag] draft-ietf-netmod-rfc8407bis: YANG Security Template

2023-12-01 Thread mohamed . boucadair

Hi Rich,

Thank you for the comment.

I think that you got the intent of that wording: leave room for judgement of
what merits to be called out there. I have personally a preference to maintain
the current wording, but I'm open to hear more opinions.

Cheers,
Med

De : Salz, Rich
Envoyé : vendredi 24 novembre 2023 18:21
À : BOUCADAIR Mohamed INNOV/NET ; s...@ietf.org
Cc : Qin Wu (bill...@huawei.com)
Objet : Re: [saag] draft-ietf-netmod-rfc8407bis: YANG Security Template

The Security template used in documents that specify YANG modules is stable
since years now. FYI, we are in the process of preparing RFC8407bis, so we
would welcome comments on that part:
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-04#name-security-considerations-sec

You should remove the word "especially" in the two places it's used and
"significant" from the privacy concerns item.

They do not make the intent more clear, and when you remove those words it
still leaves the authors to have room for judgement.

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

Re: [netmod] Regrading IPR for draft-ietf-netmod-acl-extensions-03

2023-11-28 Thread mohamed . boucadair

Hi Lou, all, 

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

Cheers,
Med

> -Message d'origine-
> De : Lou Berger 
> Envoyé : mardi 28 novembre 2023 23:27
> À : BOUCADAIR Mohamed INNOV/NET ;
> samier.barguilgiraldo@telefonica.com; OSCAR GONZALEZ DE DIOS
> ; Qin Wu 
> Cc : NETMOD Group ; NetMod WG Chairs  cha...@ietf.org>
> Objet : Regrading IPR for draft-ietf-netmod-acl-extensions-03
> 
> Authors, Contributors, WG,
> 
> As part of WG Last 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.
> 
> NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES.
> 
> 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
> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftrac.
> tools.ietf.org%2Fgroup%2Fiesg%2Ftrac%2Fwiki%2FIntellectualProperty&dat
> a=05%7C01%7Cmohamed.boucadair%40orange.com%7Cbcc58e64431b4245039b08dbf
> 061223b%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63836807219996534
> 4%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6
> Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ywoLAb%2BXV2FqN3hV6p83QNW
> hXx6o7ZppWBjt6%2BVko2w%3D&reserved=0.
> 
> Thank you,
> Lou (Co-Chair & doc Shepherd)
> 
> PS Please include all listed in the headers of this message in your
> response.
> 


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

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

2023-11-24 Thread mohamed . boucadair

Hi all,

This version implements the change about conditional checks on state data. It 
also adds an example for the use of yangson (received offline requests about 
this).

Italo raised a comment during teas session about the lack of instructions in 
8407bis about listing changes in bis doc. After double checking, no change is 
needed to 8407bis as that is already covered by the ID-Guidelines cited in the 
doc. 

Also, sent a message to SAAG for the review of the security cons: 
https://mailarchive.ietf.org/arch/msg/saag/z338jOL6mpYIIzT0Xk8ioCvi6v4/. Rich 
Salz already reviewed that text and he thinks that all is OK. Will report to 
the WG if feedback from saag is received.

Cheers,
Med

> -Message d'origine-
> De : I-D-Announce  De la part de
> internet-dra...@ietf.org
> Envoyé : jeudi 23 novembre 2023 14:31
> À : i-d-annou...@ietf.org
> Cc : netmod@ietf.org
> Objet : I-D Action: draft-ietf-netmod-rfc8407bis-04.txt
> 
> Internet-Draft draft-ietf-netmod-rfc8407bis-04.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: Mohamed Boucadair
> Qin Wu
>Name:draft-ietf-netmod-rfc8407bis-04.txt
>Pages:   76
>Dates:   2023-11-23
> 
> Abstract:
> 
>This memo provides guidelines for authors and reviewers of
>specifications containing YANG modules, including IANA-maintained
>modules.  Recommendations and procedures are defined, which are
>intended to increase interoperability and usability of Network
>Configuration Protocol (NETCONF) and RESTCONF protocol
>implementations that utilize YANG modules.  This document obsoletes
>RFC 8407.
> 
>Also, this document updates RFC 8126 by providing additional
>guidelines for writing the IANA considerations for RFCs that
> specify
>IANA-maintained modules.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Fdraft-ietf-netmod-
> rfc8407bis%2F&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C547adf8f
> a5a4408288ec08dbec2892c5%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C
> 638363431226567474%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo
> iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ctbIDOKn
> %2BCNfAMK%2F4Xr%2FrRMfmhmY3uLMLmk2fENujc8%3D&reserved=0
> 
> There is also an HTML version available at:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Farchive%2Fid%2Fdraft-ietf-netmod-rfc8407bis-
> 04.html&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C547adf8fa5a440
> 8288ec08dbec2892c5%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638363
> 431226567474%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=vBipgU72pusIP8
> h4x4vGOKpoiauxWbgb60lMIKJV5bg%3D&reserved=0
> 
> A diff from the previous version is available at:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauth
> or-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-netmod-rfc8407bis-
> 04&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C547adf8fa5a4408288e
> c08dbec2892c5%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63836343122
> 6567474%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC
> JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=aZaM%2FwCgzBjHPhhib
> Xivg5RXOo4%2B9gNHvbNWuYluWjY%3D&reserved=0
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 
> 
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fi-d-
> announce&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C547adf8fa5a44
> 08288ec08dbec2892c5%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63836
> 3431226723798%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu
> MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=HADq32A4SHz%2
> BNukgl7FJR0si%2BSRrc6hiP4ZVpYtl864%3D&reserved=0


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

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

2023-11-16 Thread mohamed . boucadair

Re, 

Thanks, Jürgern.

Please see inline.

Cheers,
Med

> -Message d'origine-
> De : Jürgen Schönwälder 
> Envoyé : jeudi 16 novembre 2023 11:30
> À : BOUCADAIR Mohamed INNOV/NET 
> Cc : Kent Watsen ; Jason Sterne (Nokia)
> ; netmod@ietf.org; Rob Wilton (rwilton)
> 
> Objet : Re: [netmod] draft-ietf-netmod-rfc8407bis: must + error-
> message for "config false"
> 
> I think an important piece is missing here is, namely _who_ is doing
> the validation and who is in charge of keeping things valid. For
> config data, the server has the task to keep the config datastores
> valid (or more precisely the resulting intended configuration).
> 

[Med] Yeah, but I assume that is known.

> For state data, if the server's state does not satisfy the
> constraints, then this is what the server's true state is.

[Med] Agree.

 It is then
> at best a client's job to check whether a server's state is valid.
> (And then there are subtleties like whether it is at all feasible for
> a client to obtain a consistent snapshot of the server's state.)

[Med] Agree on the client part. That was the intent of this part of the text: 

 " observed behavior vs. intended behavior of a managed entity and
   hopefully trigger corrective actions by a management system."

I tried to avoid diverting much on whether/how this is done.

> 
> /js
> 
> On Thu, Nov 16, 2023 at 09:33:05AM +, mohamed.boucad...@orange.com
> wrote:
> > Hi all,
> >
> > Thank you all for the feedback.
> >
> > Here is the text I suggest to capture the outcome of the discussion:
> >
> >Section 8.1 of [RFC7950] includes a provision for defining a
> >constraint on state data and specifies that the constraint must
> be
> >true in a valid state data.  However, Section 5.3 of [RFC8342]
> soften
> >that behavior by allowing semantic constraints to be violated
> under
> >some circumstances to help detecting anomalies.  Relaxing
> validation
> >constraints on state data is meant to reveal deviations of the
> >observed behavior vs. intended behavior of a managed entity and
> >hopefully trigger corrective actions by a management system.
> From
> >that perspective, it is RECOMMENDED to avoid defining constraints
> on
> >state data that would hinder the detection of abnormal behaviors
> of a
> >managed entity.
> >
> > Comments are still welcome.
> >
> > You can also proposed change here:
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> >
> ub.com%2Fboucadair%2Frfc8407bis%2Fpull%2F24%2Ffiles&data=05%7C01%7Cmoh
> >
> amed.boucadair%40orange.com%7Cf0eabc06cf0f4c9a77dc08dbe68f0080%7C90c7a
> >
> 20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638357274079883264%7CUnknown%7CT
> >
> WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI
> >
> 6Mn0%3D%7C3000%7C%7C%7C&sdata=gosEFikCJxcPPyDzp240dCRRbTnpF7jyQWDD6SKW
> > ioI%3D&reserved=0
> >
> > Thanks.
> >
> > Cheers,
> > Med
> >
> > > -Message d'origine-
> > > De : netmod  De la part de Kent Watsen
> > > Envoyé : mardi 7 novembre 2023 09:17 À : Jason Sterne (Nokia)
> > >  Cc : Jürgen Schönwälder
> > > ;
> > > netmod@ietf.org; Rob Wilton (rwilton)
> > > 
> > > Objet : Re: [netmod] draft-ietf-netmod-rfc8407bis: must + error-
> > > message for "config false"
> > >
> > > 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, a

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

2023-11-16 Thread mohamed . boucadair

Hi all, 

Thank you all for the feedback. 

Here is the text I suggest to capture the outcome of the discussion: 

   Section 8.1 of [RFC7950] includes a provision for defining a
   constraint on state data and specifies that the constraint must be
   true in a valid state data.  However, Section 5.3 of [RFC8342] soften
   that behavior by allowing semantic constraints to be violated under
   some circumstances to help detecting anomalies.  Relaxing validation
   constraints on state data is meant to reveal deviations of the
   observed behavior vs. intended behavior of a managed entity and
   hopefully trigger corrective actions by a management system.  From
   that perspective, it is RECOMMENDED to avoid defining constraints on
   state data that would hinder the detection of abnormal behaviors of a
   managed entity.

Comments are still welcome.

You can also proposed change here: 
https://github.com/boucadair/rfc8407bis/pull/24/files

Thanks. 

Cheers,
Med

> -Message d'origine-
> De : netmod  De la part de Kent Watsen
> Envoyé : mardi 7 novembre 2023 09:17
> À : Jason Sterne (Nokia) 
> Cc : Jürgen Schönwälder ;
> netmod@ietf.org; Rob Wilton (rwilton)
> 
> Objet : Re: [netmod] draft-ietf-netmod-rfc8407bis: must + error-
> message for "config false"
> 
> 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 mana

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

2023-11-08 Thread mohamed . boucadair

Hi all, 

This version includes a new section on abstract structure as per a suggestion I 
shared on the list last week.

The plan for the next iteration is to cover the issue on "must"/"config false" 
and any comment from the yangdoctors I contacted offline.

Cheers,
Med

> -Message d'origine-
> De : I-D-Announce  De la part de
> internet-dra...@ietf.org
> Envoyé : mardi 7 novembre 2023 21:26
> À : i-d-annou...@ietf.org
> Cc : netmod@ietf.org
> Objet : I-D Action: draft-ietf-netmod-rfc8407bis-03.txt
> 
> Internet-Draft draft-ietf-netmod-rfc8407bis-03.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: Mohamed Boucadair
> Qin Wu
>Name:draft-ietf-netmod-rfc8407bis-03.txt
>Pages:   76
>Dates:   2023-11-07
> 
> Abstract:
> 
>This memo provides guidelines for authors and reviewers of
>specifications containing YANG modules, including IANA-maintained
>modules.  Recommendations and procedures are defined, which are
>intended to increase interoperability and usability of Network
>Configuration Protocol (NETCONF) and RESTCONF protocol
>implementations that utilize YANG modules.  This document obsoletes
>RFC 8407.
> 
>Also, this document updates RFC 8126 by providing additional
>guidelines for writing the IANA considerations for RFCs that
> specify
>IANA-maintained modules.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Fdraft-ietf-netmod-
> rfc8407bis%2F&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C933c9369
> d9b5494cc7ac08dbdfcfd804%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C
> 638349856018480325%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo
> iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=inWLx4t3
> J415mpOXkFzvonpkjj78Myq7tdznOcwsxP0%3D&reserved=0
> 
> There is also an HTML version available at:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Farchive%2Fid%2Fdraft-ietf-netmod-rfc8407bis-
> 03.html&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C933c9369d9b549
> 4cc7ac08dbdfcfd804%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638349
> 856018480325%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=lyoHx4cr6DQOFu
> HAZymHRbA84e9A8H%2FgqM%2BdiBykTr8%3D&reserved=0
> 
> A diff from the previous version is available at:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauth
> or-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-netmod-rfc8407bis-
> 03&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C933c9369d9b5494cc7a
> c08dbdfcfd804%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63834985601
> 8480325%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC
> JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=CNCHtbReBAoeT%2FssN
> VVJhr4jbX%2BmKOrAdqT4i7s93Jc%3D&reserved=0
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 
> 
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fi-d-
> announce&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C933c9369d9b54
> 94cc7ac08dbdfcfd804%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63834
> 9856018480325%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu
> MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=51tfMON3GkeGP
> jHIJxYtuNG9wDv0Mn1aLi7QDIPpawo%3D&reserved=0


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

This message and its attachments 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] draft-ietf-netmod-rfc8407bis: RFC 8791 vs. "yang-data"

2023-10-31 Thread mohamed . boucadair

Hi all,

I suggest to add a short section on abstract data structures: 
https://github.com/boucadair/rfc8407bis/pull/19/files

Please review.

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] draft-ietf-netmod-rfc8407bis: must + error-message for "config false"

2023-10-31 Thread mohamed . boucadair

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

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

2023-10-20 Thread mohamed . boucadair

Hi all, 

This changes in this version are:

   *  Fixed an inconsistency in Section 4.6.2 where the example mentions
  identities, but uses them without their prefix as per
  Section 4.6.4.

   *  Fixed an inconsistency in Section 4.6.4 fails to use derived-from-
  or-self() mentioned back in Section 4.6.2.

Thanks Michal for reporting the issue. 

Cheers,
Med

> -Message d'origine-
> De : I-D-Announce  De la part de
> internet-dra...@ietf.org
> Envoyé : vendredi 20 octobre 2023 17:22
> À : i-d-annou...@ietf.org
> Cc : netmod@ietf.org
> Objet : I-D Action: draft-ietf-netmod-rfc8407bis-02.txt
> 
> Internet-Draft draft-ietf-netmod-rfc8407bis-02.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: Mohamed Boucadair
> Qin Wu
>Name:draft-ietf-netmod-rfc8407bis-02.txt
>Pages:   76
>Dates:   2023-10-20
> 
> Abstract:
> 
>This memo provides guidelines for authors and reviewers of
>specifications containing YANG modules, including IANA-maintained
>modules.  Recommendations and procedures are defined, which are
>intended to increase interoperability and usability of Network
>Configuration Protocol (NETCONF) and RESTCONF protocol
>implementations that utilize YANG modules.  This document obsoletes
>RFC 8407.
> 
>Also, this document updates RFC 8126 by providing additional
>guidelines for writing the IANA considerations for RFCs that
> specify
>IANA-maintained modules.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Fdraft-ietf-netmod-
> rfc8407bis%2F&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Cc22cca3e
> ef3f4243541808dbd1805148%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C
> 638334121278818729%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo
> iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=MSP5pPIy
> 2mhTkFEfYbzyGA4VeoWx1lWfvjhBFIwoh7c%3D&reserved=0
> 
> There is also an HTML version available at:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Farchive%2Fid%2Fdraft-ietf-netmod-rfc8407bis-
> 02.html&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Cc22cca3eef3f42
> 43541808dbd1805148%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638334
> 121278818729%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=xTBh4STo%2FjIF
> i%2FcaEbxHsvkAr%2FVrg%2FiQhP37lp6sK3A%3D&reserved=0
> 
> A diff from the previous version is available at:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauth
> or-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-netmod-rfc8407bis-
> 02&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Cc22cca3eef3f4243541
> 808dbd1805148%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63833412127
> 8818729%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC
> JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Q1Q%2BsOZ3Sz5V9Z7Y8
> 40HeuHvdhXCPHb%2BfUy6pODKReA%3D&reserved=0
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 
> 
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fi-d-
> announce&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Cc22cca3eef3f4
> 243541808dbd1805148%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63833
> 4121278818729%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu
> MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=WgKiRQzDrjO6s
> td5wwqq3gEE8TuWGoNaoOcwESjpyKY%3D&reserved=0


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

This message and its attachments 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] rfc8407bis: when to use identities (RE: List name: singular or plural?)

2023-10-18 Thread mohamed . boucadair

Hi Alex, 

(focusing in the identities part of the comment)

> when to use groupings or choices or identities, with the last one in
> particular in my experience often being poorly understood despite RFC
> 8407 mentioning it but perhaps not clear enough.)

I considered your comment when preparing -01 of 8407bis, but I finally made no 
change because I concluded that the current text is clear enough.

As a reminder, RFC8407bis has the following: 

4.11.1.  Fixed-Value Extensibility

   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.

   ...

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


And the following for IANA-maintained modules: 

   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.

Cheers,
Med

> -Message d'origine-
> De : netmod  De la part de Alexander Clemm
> Envoyé : vendredi 8 septembre 2023 20:28
> À : Italo Busi ; Carsten
> Bormann ; netmod 
> Objet : Re: [netmod] List name: singular or plural?
> 
> I agree.  I am actually surprised to not see it in RFC 8407.  This is
> a very useful "best practice" as a design pattern.  (I think there are
> other useful patterns worth describing as well, such as concerning
> when to use groupings or choices or identities, with the last one in
> particular in my experience often being poorly understood despite RFC
> 8407 mentioning it but perhaps not clear enough.)
> --- Alex


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

1 2 >

1 - 100 of 107 matches

Mail list logo