subject:"\[netmod\] Rfc8407 \- what does this text mean\?"

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-22 Thread Andy Bierman

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


On Tue, Feb 20, 2024 at 10:34 PM  wrote:

> 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  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 
> *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  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
>
>
>
> K.
>
>
>
>
>
>
>
> Andy
>
>
>
>
>
>
>
> [1]
> https://author-tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/rfc8407bis/draft-ietf-netmod-rfc8407bis.txt_2=https://boucadair.github.io/rfc8407bis/nmda-exceptions/draft-ietf-netmod-rfc8407bis.txt
>
>
>
> [2]
> https://mailarchive.ietf.org/arch/msg/netmod/B4TUQZf7jud5wqrBwzEqEND6-rw/
>
>
>
>
>
> *De :* netmod  *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.
>
>
>
> 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

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<mailto: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<mailto: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_2=https://boucadair.github.io/rfc8407bis/nmda-exceptions/draft-ietf-netmod-rfc8407bis.txt

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

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

Hi Andy,

Thanks for the speedy reply.

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

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

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

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

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

PS: top-posting for simplicity

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

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

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

2024-02-20 Thread Andy Bierman

On Mon, Feb 19, 2024 at 11:39 PM  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?  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 
> *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  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
>
>
>
> K.
>
>
>
>
>
>
>
> Andy
>
>
>
>
>
>
>
> [1]
> https://author-tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/rfc8407bis/draft-ietf-netmod-rfc8407bis.txt_2=https://boucadair.github.io/rfc8407bis/nmda-exceptions/draft-ietf-netmod-rfc8407bis.txt
>
>
>
> [2]
> https://mailarchive.ietf.org/arch/msg/netmod/B4TUQZf7jud5wqrBwzEqEND6-rw/
>
>
>
>
>
> *De :* netmod  *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.
>
>
>
> This guidance seems inverted, at least within the IETF (where SHOULDs are
> interpreted as MUSTs), and likely outside the IETF also, assuming rfc8407
> is read.  See the first paragraph of
> https://datatracker.ietf.org/doc/html/rfc8407#section-4.23.3
>
>
>
> I doubt any module would get past the IETF-publication process now if it
> defined a non-NMDA compliant structure (i.e., CF nodes that provide the
> opstate value for CT nodes), unless it was a “temporary non-NMDA module” (
> https://datatracker.ietf.org/doc/html/rfc8407#section-4.23.3.1).
>
>
>
> Since this, for awhile now, is the normal thing to do, the text
> highlighted in my OP seems to have little to no value.  That said, an
> “inverted” statement would have some value, that is, to explicitly
> highlight if the document defines any “temporary non-NMDA modules”.  This
> would be akin to highlighting when a document defines any IANA-maintained
> modules.
>
>
>
> I am proposing to update the text in rfc8407bis accordingly (to invert the
> guidance).  Thoughts?
>
>
>
> If there is agreement to update this text accordingly, I will delete the
> "Adherence to the NMDA” section in all my drafts, since none of them define
> a “temporary non-NMDA module”.
>
>
>
> PS: top-posting for simplicity
>
>
>
> K.
>
>
>
>
>
>
>
> On Feb 16, 2024, at 3:25 PM, Andy Bierman  wrote:
>
>
>
>
>
>
>
> On Fri, Feb 16, 2024 at 12:07 PM Kent Watsen  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

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<mailto: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 mailin

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

2024-02-19 Thread Andy Bierman

On Mon, Feb 19, 2024 at 6:54 AM Kent Watsen  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
>
>
> K.
>
>

Andy


>
>
> [1]
> https://author-tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/rfc8407bis/draft-ietf-netmod-rfc8407bis.txt_2=https://boucadair.github.io/rfc8407bis/nmda-exceptions/draft-ietf-netmod-rfc8407bis.txt
>
> [2]
> https://mailarchive.ietf.org/arch/msg/netmod/B4TUQZf7jud5wqrBwzEqEND6-rw/
>
>
> *De :* netmod  *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.
>
> This guidance seems inverted, at least within the IETF (where SHOULDs are
> interpreted as MUSTs), and likely outside the IETF also, assuming rfc8407
> is read.  See the first paragraph of
> https://datatracker.ietf.org/doc/html/rfc8407#section-4.23.3
>
> I doubt any module would get past the IETF-publication process now if it
> defined a non-NMDA compliant structure (i.e., CF nodes that provide the
> opstate value for CT nodes), unless it was a “temporary non-NMDA module” (
> https://datatracker.ietf.org/doc/html/rfc8407#section-4.23.3.1).
>
> Since this, for awhile now, is the normal thing to do, the text
> highlighted in my OP seems to have little to no value.  That said, an
> “inverted” statement would have some value, that is, to explicitly
> highlight if the document defines any “temporary non-NMDA modules”.  This
> would be akin to highlighting when a document defines any IANA-maintained
> modules.
>
>
> I am proposing to update the text in rfc8407bis accordingly (to invert the
> guidance).  Thoughts?
>
>
> If there is agreement to update this text accordingly, I will delete the
> "Adherence to the NMDA” section in all my drafts, since none of them define
> a “temporary non-NMDA module”.
>
> PS: top-posting for simplicity
>
> K.
>
>
>
>
> On Feb 16, 2024, at 3:25 PM, Andy Bierman  wrote:
>
>
>
> On Fri, Feb 16, 2024 at 12:07 PM Kent Watsen  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
>
>
>
>

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

2024-02-19 Thread Kent Watsen

Hi Med,

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

Thank you.  

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


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

That’s a great find!


> Cheers,
> Med

K.


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

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

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<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] Rfc8407 - what does this text mean?

2024-02-16 Thread Kent Watsen

Hi Andy,

Thanks for the speedy reply.

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

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

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

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

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

PS: top-posting for simplicity

K.

> On Feb 16, 2024, at 3:25 PM, Andy Bierman  wrote:
> 
> 
> 
> On Fri, Feb 16, 2024 at 12:07 PM Kent Watsen  > 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

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

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

2024-02-16 Thread Andy Bierman

On Fri, Feb 16, 2024 at 12:07 PM Kent Watsen  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
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Rfc8407 - what does this text mean?

2024-02-16 Thread Kent Watsen

NETMOD,

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

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

   Example:

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


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

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

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

Thanks,
Kent

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

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

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

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

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

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

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

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

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

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

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

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

[netmod] Rfc8407 - what does this text mean?

12 matches

Site Navigation

Mail list logo

Footer information