Re: [netmod] Use of prefixes in YANG models

2021-03-19 Thread Mahesh Jethanandani 


> On Mar 19, 2021, at 12:46 AM, Juergen Schoenwaelder 
>  wrote:
> 
> On Fri, Mar 19, 2021 at 09:23:06AM +, tom petch wrote:
>> 
>> If  the spec was more precise it would settle the arguments.
>> 
> 
> RFC 7950 says that tools must support a prefix statement inside an
> import statement, which overrides the prefix defined in the imported
> module. A tool that does not support this is not implementing RFC 7950
> correctly.
> 
> RFC 8407 provides additional rules for authors writing IETF YANG
> modules. Implementations may generate warnings (perhaps even errors,
> may be implementation specific) if these rules are violated by modules
> to which the RFC 8407 rules apply. (This implies that a tool needs to
> know whether RFC 8407 rules apply or not.)

I believe support by tools for the additional rules imposed by RFC 8407 would 
be helpful. There are several ways to recognize that the module in question is 
an IETF module, e.g. namespace, or by a more direct option on the tool CLI, 
e.g. —ietf option in pyang. The tools can print a warning if the prefix of the 
imported module is not used.

> 
> It is true that RFC 8407 is not very explicit to which YANG modules
> the rules apply but given the many IETF specific rules, it is kind of
> implicit that the rules may not apply 1:1 to YANG modules published by
> other organizations.

Additionally, RFC 8407 is a BCP. It does not update RFC 7950. However, it is 
changing the prefix requirement for import in RFC 7950, from a SHOULD to a 
MUST. Aren’t languages supposed to be consistent in how its rules are meant to 
be interpreted?

> 
> /js
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

Mahesh Jethanandani
mjethanand...@gmail.com





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

Re: [netmod] Use of prefixes in YANG models

2021-03-19 Thread Juergen Schoenwaelder 
On Fri, Mar 19, 2021 at 04:38:11PM +, tom petch wrote:
> 
> 
> Apologies for the useless quoting that my webmail imposes on me:-(
>

Your webmail does not allow to edit the quoted text?

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

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

Re: [netmod] Use of prefixes in YANG models

2021-03-19 Thread tom petch 
From: Andy Bierman 
Sent: 19 March 2021 11:55

On Fri, Mar 19, 2021 at 2:23 AM tom petch 
mailto:ie...@btconnect.com>> wrote:
From: Andy Bierman mailto:a...@yumaworks.com>>
Sent: 18 March 2021 18:02

On Thu, Mar 18, 2021 at 10:41 AM Don Fedyk 
mailto:dfe...@labn.net><mailto:dfe...@labn.net<mailto:dfe...@labn.net>>>
 wrote:
So you are saying I should beat up on the tool chain people that have not 
followed the spec. I tried that already  , but since I can redefine the 
prefixes locally as a workaround, and I couldn’t convince them it was an issue, 
it fell by the wayside with one tool so far.

If  the spec was more precise it would settle the arguments.

I think it is unfortunate that the IETF wanted so many clever little rules for 
the creation of YANG modules.
Also unfortunate that RFC 2119 terms in the style guide get confused with 
similar terms in the YANG RFC.

RFC 8407 is normative for IETF YANG module authors.
RFC 7950 is for YANG module tool-makers.
People should know the difference, especially since 8407 only applies to the 
IETF, not other organizations.


Apologies for the useless quoting that my webmail imposes on me:-(

Andy

Of course tool chains should allow for a change of prefix but you did write, in 
RFC8407,
"   o  The proper module prefix MUST be used for all identifiers imported
  from other modules.
"
and this discussion started with the meaning of 'proper' here.  I take it to 
mean the prefix defined by the author of the imported module.  I may have a 
brilliant idea that is a massive improvement on what the author of the imported 
module chose, but too late.  If this is an RFC, then I can only cause confusion 
by using a different prefix in my module and that would be improper.

Is this what you intended?


You mean what the WG intended.
I believe you are correct.

Use the prefix defined in the imported module if it is not already in use 
amongst the
local prefixes within the module.  Otherwise pick a different prefix.
(No guidelines for picking a replacement prefix are given)


Andy

Thank you for that; yes, it was the intent of the WG that I was looking for 
clarification of.

Tom Petch


Tom Petch



Andy

Regards,
Don


Andy


From: Andy Bierman 
mailto:a...@yumaworks.com><mailto:a...@yumaworks.com<mailto:a...@yumaworks.com>>>
Sent: Thursday, March 18, 2021 1:23 PM
To: Don Fedyk 
mailto:dfe...@labn.net><mailto:dfe...@labn.net<mailto:dfe...@labn.net>>>
Cc: tom petch 
mailto:ie...@btconnect.com><mailto:ie...@btconnect.com<mailto:ie...@btconnect.com>>>;
 Mahesh Jethanandani 
mailto:mjethanand...@gmail.com><mailto:mjethanand...@gmail.com<mailto:mjethanand...@gmail.com>>>;
 Juergen Schoenwaelder 
mailto:j.schoenwael...@jacobs-university.de><mailto:j.schoenwael...@jacobs-university.de<mailto:j.schoenwael...@jacobs-university.de>>>;
 
netmod@ietf.org<mailto:netmod@ietf.org><mailto:netmod@ietf.org<mailto:netmod@ietf.org>>
Subject: Re: [netmod] Use of prefixes in YANG models



On Thu, Mar 18, 2021 at 10:07 AM Don Fedyk 
mailto:dfe...@labn.net><mailto:dfe...@labn.net<mailto:dfe...@labn.net>>>
 wrote:
Clarity and consistency would help.

Many of the supporting tool chains are picky about prefixes. IE they must be 
the same as in the definition file.  I have a case where yanglint wants "local 
prefixes or derived-from(-or-self) construct" for an local identity in an xpath 
statement. (either remedy seems to work.) I argued for the prefixes in but 
others argue they are not necessary but I cannot validate without them.


The tool makers should understand that YANG prefixes are not required to be 
unique.
It is understood that short character sequences have a high probability of 
duplication.
So what if the server wants to support 2 modules with the same prefix defined 
in the YANG module?
Is it not clear that the ENTIRE point of having the prefix-stmt in the 
import-stmt is
because the imported modules may have prefixes that collide?



Andy

"not(derived-from(../../bridge-type,'two-port-mac-relay-bridge'))" works 
(prefix/no prefix)
But "../../bridge-type != 'dot1q:two-port-mac-relay-bridge'  works too.

Thanks
Don



-Original Message-
From: netmod 
mailto:netmod-boun...@ietf.org><mailto:netmod-boun...@ietf.org<mailto:netmod-boun...@ietf.org>>>
 On Behalf Of tom petch
Sent: Thursday, March 18, 2021 7:50 AM
To: Mahesh Jethanandani 
mailto:mjethanand...@gmail.com><mailto:mjethanand...@gmail.com<mailto:mjethanand...@gmail.com>>>;
 Juergen Schoenwaelder 
mailto:j.schoenwael...@jacobs-university.de><mailto:j.schoenwael...@jacobs-university.de<mailto:j.schoenwael...@jacobs-university.de>>>
Cc: 
netmod@ietf.org<mailto:netmod@ietf.org><mailto:netmod@ietf.org<mailto:netmod@ietf.org>>
Subject: Re: [netmod] Use o

Re: [netmod] Use of prefixes in YANG models

2021-03-19 Thread Andy Bierman 
On Fri, Mar 19, 2021 at 2:23 AM tom petch  wrote:

> From: Andy Bierman 
> Sent: 18 March 2021 18:02
>
> On Thu, Mar 18, 2021 at 10:41 AM Don Fedyk  dfe...@labn.net>> wrote:
> So you are saying I should beat up on the tool chain people that have not
> followed the spec. I tried that already  , but since I can redefine the
> prefixes locally as a workaround, and I couldn’t convince them it was an
> issue, it fell by the wayside with one tool so far.
>
> If  the spec was more precise it would settle the arguments.
>
> I think it is unfortunate that the IETF wanted so many clever little rules
> for the creation of YANG modules.
> Also unfortunate that RFC 2119 terms in the style guide get confused with
> similar terms in the YANG RFC.
>
> RFC 8407 is normative for IETF YANG module authors.
> RFC 7950 is for YANG module tool-makers.
> People should know the difference, especially since 8407 only applies to
> the IETF, not other organizations.
>
> 
> Apologies for the useless quoting that my webmail imposes on me:-(
>
> Andy
>
> Of course tool chains should allow for a change of prefix but you did
> write, in RFC8407,
> "   o  The proper module prefix MUST be used for all identifiers imported
>   from other modules.
> "
> and this discussion started with the meaning of 'proper' here.  I take it
> to mean the prefix defined by the author of the imported module.  I may
> have a brilliant idea that is a massive improvement on what the author of
> the imported module chose, but too late.  If this is an RFC, then I can
> only cause confusion by using a different prefix in my module and that
> would be improper.
>
> Is this what you intended?
>


You mean what the WG intended.
I believe you are correct.

Use the prefix defined in the imported module if it is not already in use
amongst the
local prefixes within the module.  Otherwise pick a different prefix.
(No guidelines for picking a replacement prefix are given)




>
> Tom Petch
>
>

Andy


> Regards,
> Don
>
>
> Andy
>
>
> From: Andy Bierman mailto:a...@yumaworks.com>>
> Sent: Thursday, March 18, 2021 1:23 PM
> To: Don Fedyk mailto:dfe...@labn.net>>
> Cc: tom petch mailto:ie...@btconnect.com>>; Mahesh
> Jethanandani mailto:mjethanand...@gmail.com>>;
> Juergen Schoenwaelder  j.schoenwael...@jacobs-university.de>>; netmod@ietf.org netmod@ietf.org>
> Subject: Re: [netmod] Use of prefixes in YANG models
>
>
>
> On Thu, Mar 18, 2021 at 10:07 AM Don Fedyk  dfe...@labn.net>> wrote:
> Clarity and consistency would help.
>
> Many of the supporting tool chains are picky about prefixes. IE they must
> be the same as in the definition file.  I have a case where yanglint wants
> "local prefixes or derived-from(-or-self) construct" for an local identity
> in an xpath statement. (either remedy seems to work.) I argued for the
> prefixes in but others argue they are not necessary but I cannot validate
> without them.
>
>
> The tool makers should understand that YANG prefixes are not required to
> be unique.
> It is understood that short character sequences have a high probability of
> duplication.
> So what if the server wants to support 2 modules with the same prefix
> defined in the YANG module?
> Is it not clear that the ENTIRE point of having the prefix-stmt in the
> import-stmt is
> because the imported modules may have prefixes that collide?
>
>
>
> Andy
>
> "not(derived-from(../../bridge-type,'two-port-mac-relay-bridge'))" works
> (prefix/no prefix)
> But "../../bridge-type != 'dot1q:two-port-mac-relay-bridge'  works too.
>
> Thanks
> Don
>
>
>
> -----Original Message-----
> From: netmod mailto:netmod-boun...@ietf.org>> On
> Behalf Of tom petch
> Sent: Thursday, March 18, 2021 7:50 AM
> To: Mahesh Jethanandani  mjethanand...@gmail.com>>; Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de j.schoenwael...@jacobs-university.de>>
> Cc: netmod@ietf.org<mailto:netmod@ietf.org>
> Subject: Re: [netmod] Use of prefixes in YANG models
>
> From: netmod mailto:netmod-boun...@ietf.org>> on
> behalf of Juergen Schoenwaelder  <mailto:j.schoenwael...@jacobs-university.de>>
> Sent: 18 March 2021 08:05
>
> We often do not do a good job in distinguishing technical requirements
> from usage guidelines. (And RFC 2119 keywords make things worse.)
>
> As far as I recall, the intent of the RFC 8407 text was to say that it is
> helpful for _humans_ to always use 'if:name' when you refer to the leaf
> 'name' defined in 'ietf-interfaces' or 'yang:date-and-time' when you refer
> to 'date-and-time' defined in 'ietf

Re: [netmod] Use of prefixes in YANG models

2021-03-19 Thread Juergen Schoenwaelder 
On Fri, Mar 19, 2021 at 09:23:06AM +, tom petch wrote:
> 
> If  the spec was more precise it would settle the arguments.
>

RFC 7950 says that tools must support a prefix statement inside an
import statement, which overrides the prefix defined in the imported
module. A tool that does not support this is not implementing RFC 7950
correctly.

RFC 8407 provides additional rules for authors writing IETF YANG
modules. Implementations may generate warnings (perhaps even errors,
may be implementation specific) if these rules are violated by modules
to which the RFC 8407 rules apply. (This implies that a tool needs to
know whether RFC 8407 rules apply or not.)

It is true that RFC 8407 is not very explicit to which YANG modules
the rules apply but given the many IETF specific rules, it is kind of
implicit that the rules may not apply 1:1 to YANG modules published by
other organizations.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

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

Re: [netmod] Use of prefixes in YANG models

2021-03-19 Thread tom petch 
From: Andy Bierman 
Sent: 18 March 2021 18:02

On Thu, Mar 18, 2021 at 10:41 AM Don Fedyk 
mailto:dfe...@labn.net>> wrote:
So you are saying I should beat up on the tool chain people that have not 
followed the spec. I tried that already  , but since I can redefine the 
prefixes locally as a workaround, and I couldn’t convince them it was an issue, 
it fell by the wayside with one tool so far.

If  the spec was more precise it would settle the arguments.

I think it is unfortunate that the IETF wanted so many clever little rules for 
the creation of YANG modules.
Also unfortunate that RFC 2119 terms in the style guide get confused with 
similar terms in the YANG RFC.

RFC 8407 is normative for IETF YANG module authors.
RFC 7950 is for YANG module tool-makers.
People should know the difference, especially since 8407 only applies to the 
IETF, not other organizations.


Apologies for the useless quoting that my webmail imposes on me:-(

Andy

Of course tool chains should allow for a change of prefix but you did write, in 
RFC8407,
"   o  The proper module prefix MUST be used for all identifiers imported
  from other modules.
"
and this discussion started with the meaning of 'proper' here.  I take it to 
mean the prefix defined by the author of the imported module.  I may have a 
brilliant idea that is a massive improvement on what the author of the imported 
module chose, but too late.  If this is an RFC, then I can only cause confusion 
by using a different prefix in my module and that would be improper.

Is this what you intended?

Tom Petch

Regards,
Don


Andy


From: Andy Bierman mailto:a...@yumaworks.com>>
Sent: Thursday, March 18, 2021 1:23 PM
To: Don Fedyk mailto:dfe...@labn.net>>
Cc: tom petch mailto:ie...@btconnect.com>>; Mahesh 
Jethanandani mailto:mjethanand...@gmail.com>>; Juergen 
Schoenwaelder 
mailto:j.schoenwael...@jacobs-university.de>>;
 netmod@ietf.org<mailto:netmod@ietf.org>
Subject: Re: [netmod] Use of prefixes in YANG models



On Thu, Mar 18, 2021 at 10:07 AM Don Fedyk 
mailto:dfe...@labn.net>> wrote:
Clarity and consistency would help.

Many of the supporting tool chains are picky about prefixes. IE they must be 
the same as in the definition file.  I have a case where yanglint wants "local 
prefixes or derived-from(-or-self) construct" for an local identity in an xpath 
statement. (either remedy seems to work.) I argued for the prefixes in but 
others argue they are not necessary but I cannot validate without them.


The tool makers should understand that YANG prefixes are not required to be 
unique.
It is understood that short character sequences have a high probability of 
duplication.
So what if the server wants to support 2 modules with the same prefix defined 
in the YANG module?
Is it not clear that the ENTIRE point of having the prefix-stmt in the 
import-stmt is
because the imported modules may have prefixes that collide?



Andy

"not(derived-from(../../bridge-type,'two-port-mac-relay-bridge'))" works 
(prefix/no prefix)
But "../../bridge-type != 'dot1q:two-port-mac-relay-bridge'  works too.

Thanks
Don



-Original Message-
From: netmod mailto:netmod-boun...@ietf.org>> On 
Behalf Of tom petch
Sent: Thursday, March 18, 2021 7:50 AM
To: Mahesh Jethanandani 
mailto:mjethanand...@gmail.com>>; Juergen 
Schoenwaelder 
mailto:j.schoenwael...@jacobs-university.de>>
Cc: netmod@ietf.org<mailto:netmod@ietf.org>
Subject: Re: [netmod] Use of prefixes in YANG models

From: netmod mailto:netmod-boun...@ietf.org>> on 
behalf of Juergen Schoenwaelder 
mailto:j.schoenwael...@jacobs-university.de>>
Sent: 18 March 2021 08:05

We often do not do a good job in distinguishing technical requirements from 
usage guidelines. (And RFC 2119 keywords make things worse.)

As far as I recall, the intent of the RFC 8407 text was to say that it is 
helpful for _humans_ to always use 'if:name' when you refer to the leaf 'name' 
defined in 'ietf-interfaces' or 'yang:date-and-time' when you refer to 
'date-and-time' defined in 'ietf-yang-types'.

I believe we agreed that module authors assigning a prefix different from the 
default prefix during an import should have either technical reasons for doing 
so (resolving prefixes clashes) or some other good reason to depart from the 
general guideline aiming to reduce human confusion.


To make an abstract concept concrete, draft-ietf-babel-yang-model imports yang 
types from RFC6991 and gives it the prefix yt: as in yt:date-and-time or 
yt:counter32.  An early YANG Doctor review by Radek did not comment on this 
aspect of the I-D.  More recently, I have.

Tom Petch



/js (who stopped believing that RFC 2119 keywords are helpful years ago)

On Wed, Mar 17, 2021 at 05:03:11PM -0700, Mahesh Jethanandani wrote:
> I have seen the debate on the use of prefixes in YANG models, specially as it 
> relates to their use w

Re: [netmod] Use of prefixes in YANG models

2021-03-19 Thread Ladislav Lhotka 
Don Fedyk  writes:

> Clarity and consistency would help.

Right, but mainly human readers. Properly written tools should have no problems 
with 

>
> Many of the supporting tool chains are picky about prefixes. IE they
> must be the same as in the definition file.  I have a case where

This is simply wrong, but it is in fact the same problem that plagued XML. 
James Clark, one of XML gurus, identified the namespace/prefix duality as a 
serious design flaw in XML. This is an instructive reading:

https://blog.jclark.com/2010/01/xml-namespaces.html

> yanglint wants "local prefixes or derived-from(-or-self) construct"
> for an local identity in an xpath statement. (either remedy seems to
> work.) I argued for the prefixes in but others argue they are not
> necessary but I cannot validate without them.
>
> "not(derived-from(../../bridge-type,'two-port-mac-relay-bridge'))" works 
> (prefix/no prefix)
> But "../../bridge-type != 'dot1q:two-port-mac-relay-bridge'works too.

The latter is known to be brittle and shoould not be used. That's why the 
derived-from function was introduced.

Lada

>
> Thanks
> Don 
>
>  
>
> -Original Message-
> From: netmod  On Behalf Of tom petch
> Sent: Thursday, March 18, 2021 7:50 AM
> To: Mahesh Jethanandani ; Juergen Schoenwaelder 
> 
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Use of prefixes in YANG models
>
> From: netmod  on behalf of Juergen Schoenwaelder 
> 
> Sent: 18 March 2021 08:05
>
> We often do not do a good job in distinguishing technical requirements from 
> usage guidelines. (And RFC 2119 keywords make things worse.)
>
> As far as I recall, the intent of the RFC 8407 text was to say that it is 
> helpful for _humans_ to always use 'if:name' when you refer to the leaf 
> 'name' defined in 'ietf-interfaces' or 'yang:date-and-time' when you refer to 
> 'date-and-time' defined in 'ietf-yang-types'.
>
> I believe we agreed that module authors assigning a prefix different from the 
> default prefix during an import should have either technical reasons for 
> doing so (resolving prefixes clashes) or some other good reason to depart 
> from the general guideline aiming to reduce human confusion.
>
> 
> To make an abstract concept concrete, draft-ietf-babel-yang-model imports 
> yang types from RFC6991 and gives it the prefix yt: as in yt:date-and-time or 
> yt:counter32.  An early YANG Doctor review by Radek did not comment on this 
> aspect of the I-D.  More recently, I have.
>
> Tom Petch
>
>
>
> /js (who stopped believing that RFC 2119 keywords are helpful years ago)
>
> On Wed, Mar 17, 2021 at 05:03:11PM -0700, Mahesh Jethanandani wrote:
>> I have seen the debate on the use of prefixes in YANG models, specially as 
>> it relates to their use when importing a model. I think it would nice to be 
>> clear on what is required, what is nice, and what is not ok to do. I do not 
>> want to confuse this discussion with the length of the prefix, which I 
>> believe is somewhat related but not the same discussion.
>>
>> RFC 7950 says:
>>
>>All prefixes, including the prefix for the module itself, MUST be
>>unique within the module or submodule.
>>
>> This is a requirement, as is clear by the MUST.
>>
>> Then RFC 7950 says:
>>
>>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.
>>
>> It also says:
>>
>>When used inside the "import" statement, the "prefix" statement
>>defines the prefix to be used when accessing definitions inside the
>>imported module.
>>
>> Clearly, the scope of the "prefix" statement used with an "import" statement 
>> is limited to the module where it is imported and does not impact the 
>> imported module. As such, and because it is a SHOULD and not a MUST, this is 
>> a "nice to have"  without conflicts, but one would not be wrong using a 
>> different prefix from the one defined in the imported module. Add to this, 
>> most tools, e.g. pyang or yanglint do not complain if you do define a 
>> different prefix when there are no conflicts. I have not seen a problem in 
>> the implementation of the module when the prefix is different.
>>
>> RFC 8407 confuses this whole situation by saying:
>>
>>   The proper module prefix MUST be used for all identifiers imported
>>   from other modules.
>>
>> which as written is true for identifiers (but not for other types of 
>> imports??). Besides, it does not define what is &quo

Re: [netmod] Use of prefixes in YANG models

2021-03-18 Thread Andy Bierman 
On Thu, Mar 18, 2021 at 10:41 AM Don Fedyk  wrote:

> So you are saying I should beat up on the tool chain people that have not
> followed the spec. I tried that already  , but since I can redefine the
> prefixes locally as a workaround, and I couldn’t convince them it was an
> issue, it fell by the wayside with one tool so far.
>
>
>
> If  the spec was more precise it would settle the arguments.
>

I think it is unfortunate that the IETF wanted so many clever little rules
for the creation of YANG modules.
Also unfortunate that RFC 2119 terms in the style guide get confused with
similar terms in the YANG RFC.

RFC 8407 is normative for IETF YANG module authors.
RFC 7950 is for YANG module tool-makers.
People should know the difference, especially since 8407 only applies to
the IETF, not other organizations.


Regards,
>
> Don
>


Andy


>
>
> *From:* Andy Bierman 
> *Sent:* Thursday, March 18, 2021 1:23 PM
> *To:* Don Fedyk 
> *Cc:* tom petch ; Mahesh Jethanandani <
> mjethanand...@gmail.com>; Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de>; netmod@ietf.org
> *Subject:* Re: [netmod] Use of prefixes in YANG models
>
>
>
>
>
>
>
> On Thu, Mar 18, 2021 at 10:07 AM Don Fedyk  wrote:
>
> Clarity and consistency would help.
>
> Many of the supporting tool chains are picky about prefixes. IE they must
> be the same as in the definition file.  I have a case where yanglint wants
> "local prefixes or derived-from(-or-self) construct" for an local identity
> in an xpath statement. (either remedy seems to work.) I argued for the
> prefixes in but others argue they are not necessary but I cannot validate
> without them.
>
>
>
>
>
> The tool makers should understand that YANG prefixes are not required to
> be unique.
>
> It is understood that short character sequences have a high probability of
> duplication.
>
> So what if the server wants to support 2 modules with the same prefix
> defined in the YANG module?
>
> Is it not clear that the ENTIRE point of having the prefix-stmt in the
> import-stmt is
>
> because the imported modules may have prefixes that collide?
>
>
>
>
>
>
>
> Andy
>
>
>
> "not(derived-from(../../bridge-type,'two-port-mac-relay-bridge'))" works
> (prefix/no prefix)
> But "../../bridge-type != 'dot1q:two-port-mac-relay-bridge'  works too.
>
> Thanks
> Don
>
>
>
> -Original Message-
> From: netmod  On Behalf Of tom petch
> Sent: Thursday, March 18, 2021 7:50 AM
> To: Mahesh Jethanandani ; Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de>
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Use of prefixes in YANG models
>
> From: netmod  on behalf of Juergen Schoenwaelder
> 
> Sent: 18 March 2021 08:05
>
> We often do not do a good job in distinguishing technical requirements
> from usage guidelines. (And RFC 2119 keywords make things worse.)
>
> As far as I recall, the intent of the RFC 8407 text was to say that it is
> helpful for _humans_ to always use 'if:name' when you refer to the leaf
> 'name' defined in 'ietf-interfaces' or 'yang:date-and-time' when you refer
> to 'date-and-time' defined in 'ietf-yang-types'.
>
> I believe we agreed that module authors assigning a prefix different from
> the default prefix during an import should have either technical reasons
> for doing so (resolving prefixes clashes) or some other good reason to
> depart from the general guideline aiming to reduce human confusion.
>
> 
> To make an abstract concept concrete, draft-ietf-babel-yang-model imports
> yang types from RFC6991 and gives it the prefix yt: as in yt:date-and-time
> or yt:counter32.  An early YANG Doctor review by Radek did not comment on
> this aspect of the I-D.  More recently, I have.
>
> Tom Petch
>
>
>
> /js (who stopped believing that RFC 2119 keywords are helpful years ago)
>
> On Wed, Mar 17, 2021 at 05:03:11PM -0700, Mahesh Jethanandani wrote:
> > I have seen the debate on the use of prefixes in YANG models, specially
> as it relates to their use when importing a model. I think it would nice to
> be clear on what is required, what is nice, and what is not ok to do. I do
> not want to confuse this discussion with the length of the prefix, which I
> believe is somewhat related but not the same discussion.
> >
> > RFC 7950 says:
> >
> >All prefixes, including the prefix for the module itself, MUST be
> >unique within the module or submodule.
> >
> > This is a requirement, as is clear by the MUST.
> >
> > Then RFC 7950 says:
> >
> >To
> >improve readability of YANG modules, the p

Re: [netmod] Use of prefixes in YANG models

2021-03-18 Thread Don Fedyk 
So you are saying I should beat up on the tool chain people that have not 
followed the spec. I tried that already  , but since I can redefine the 
prefixes locally as a workaround, and I couldn’t convince them it was an issue, 
it fell by the wayside with one tool so far.

If  the spec was more precise it would settle the arguments.
Regards,
Don

From: Andy Bierman 
Sent: Thursday, March 18, 2021 1:23 PM
To: Don Fedyk 
Cc: tom petch ; Mahesh Jethanandani 
; Juergen Schoenwaelder 
; netmod@ietf.org
Subject: Re: [netmod] Use of prefixes in YANG models



On Thu, Mar 18, 2021 at 10:07 AM Don Fedyk 
mailto:dfe...@labn.net>> wrote:
Clarity and consistency would help.

Many of the supporting tool chains are picky about prefixes. IE they must be 
the same as in the definition file.  I have a case where yanglint wants "local 
prefixes or derived-from(-or-self) construct" for an local identity in an xpath 
statement. (either remedy seems to work.) I argued for the prefixes in but 
others argue they are not necessary but I cannot validate without them.


The tool makers should understand that YANG prefixes are not required to be 
unique.
It is understood that short character sequences have a high probability of 
duplication.
So what if the server wants to support 2 modules with the same prefix defined 
in the YANG module?
Is it not clear that the ENTIRE point of having the prefix-stmt in the 
import-stmt is
because the imported modules may have prefixes that collide?



Andy

"not(derived-from(../../bridge-type,'two-port-mac-relay-bridge'))" works 
(prefix/no prefix)
But "../../bridge-type != 'dot1q:two-port-mac-relay-bridge'  works too.

Thanks
Don



-Original Message-
From: netmod mailto:netmod-boun...@ietf.org>> On 
Behalf Of tom petch
Sent: Thursday, March 18, 2021 7:50 AM
To: Mahesh Jethanandani 
mailto:mjethanand...@gmail.com>>; Juergen 
Schoenwaelder 
mailto:j.schoenwael...@jacobs-university.de>>
Cc: netmod@ietf.org<mailto:netmod@ietf.org>
Subject: Re: [netmod] Use of prefixes in YANG models

From: netmod mailto:netmod-boun...@ietf.org>> on 
behalf of Juergen Schoenwaelder 
mailto:j.schoenwael...@jacobs-university.de>>
Sent: 18 March 2021 08:05

We often do not do a good job in distinguishing technical requirements from 
usage guidelines. (And RFC 2119 keywords make things worse.)

As far as I recall, the intent of the RFC 8407 text was to say that it is 
helpful for _humans_ to always use 'if:name' when you refer to the leaf 'name' 
defined in 'ietf-interfaces' or 'yang:date-and-time' when you refer to 
'date-and-time' defined in 'ietf-yang-types'.

I believe we agreed that module authors assigning a prefix different from the 
default prefix during an import should have either technical reasons for doing 
so (resolving prefixes clashes) or some other good reason to depart from the 
general guideline aiming to reduce human confusion.


To make an abstract concept concrete, draft-ietf-babel-yang-model imports yang 
types from RFC6991 and gives it the prefix yt: as in yt:date-and-time or 
yt:counter32.  An early YANG Doctor review by Radek did not comment on this 
aspect of the I-D.  More recently, I have.

Tom Petch



/js (who stopped believing that RFC 2119 keywords are helpful years ago)

On Wed, Mar 17, 2021 at 05:03:11PM -0700, Mahesh Jethanandani wrote:
> I have seen the debate on the use of prefixes in YANG models, specially as it 
> relates to their use when importing a model. I think it would nice to be 
> clear on what is required, what is nice, and what is not ok to do. I do not 
> want to confuse this discussion with the length of the prefix, which I 
> believe is somewhat related but not the same discussion.
>
> RFC 7950 says:
>
>All prefixes, including the prefix for the module itself, MUST be
>unique within the module or submodule.
>
> This is a requirement, as is clear by the MUST.
>
> Then RFC 7950 says:
>
>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.
>
> It also says:
>
>When used inside the "import" statement, the "prefix" statement
>defines the prefix to be used when accessing definitions inside the
>imported module.
>
> Clearly, the scope of the "prefix" statement used with an "import" statement 
> is limited to the module where it is imported and does not impact the 
> imported module. As such, and because it is a SHOULD and not a MUST, this is 
> a "nice to have"  without conflicts, but one would not be wrong using a 
> different prefix from the one defined in the imported module. Add to this, 
> most tools, e.g. pyang or yanglint do not complain if you do define a 
> different prefix when there are no conflicts. I have no

Re: [netmod] Use of prefixes in YANG models

2021-03-18 Thread Andy Bierman 
On Thu, Mar 18, 2021 at 10:07 AM Don Fedyk  wrote:

> Clarity and consistency would help.
>
> Many of the supporting tool chains are picky about prefixes. IE they must
> be the same as in the definition file.  I have a case where yanglint wants
> "local prefixes or derived-from(-or-self) construct" for an local identity
> in an xpath statement. (either remedy seems to work.) I argued for the
> prefixes in but others argue they are not necessary but I cannot validate
> without them.
>
>

The tool makers should understand that YANG prefixes are not required to be
unique.
It is understood that short character sequences have a high probability of
duplication.
So what if the server wants to support 2 modules with the same prefix
defined in the YANG module?
Is it not clear that the ENTIRE point of having the prefix-stmt in the
import-stmt is
because the imported modules may have prefixes that collide?



Andy

"not(derived-from(../../bridge-type,'two-port-mac-relay-bridge'))" works
> (prefix/no prefix)
> But "../../bridge-type != 'dot1q:two-port-mac-relay-bridge'  works too.
>
> Thanks
> Don
>
>
>
> -Original Message-
> From: netmod  On Behalf Of tom petch
> Sent: Thursday, March 18, 2021 7:50 AM
> To: Mahesh Jethanandani ; Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de>
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Use of prefixes in YANG models
>
> From: netmod  on behalf of Juergen Schoenwaelder
> 
> Sent: 18 March 2021 08:05
>
> We often do not do a good job in distinguishing technical requirements
> from usage guidelines. (And RFC 2119 keywords make things worse.)
>
> As far as I recall, the intent of the RFC 8407 text was to say that it is
> helpful for _humans_ to always use 'if:name' when you refer to the leaf
> 'name' defined in 'ietf-interfaces' or 'yang:date-and-time' when you refer
> to 'date-and-time' defined in 'ietf-yang-types'.
>
> I believe we agreed that module authors assigning a prefix different from
> the default prefix during an import should have either technical reasons
> for doing so (resolving prefixes clashes) or some other good reason to
> depart from the general guideline aiming to reduce human confusion.
>
> 
> To make an abstract concept concrete, draft-ietf-babel-yang-model imports
> yang types from RFC6991 and gives it the prefix yt: as in yt:date-and-time
> or yt:counter32.  An early YANG Doctor review by Radek did not comment on
> this aspect of the I-D.  More recently, I have.
>
> Tom Petch
>
>
>
> /js (who stopped believing that RFC 2119 keywords are helpful years ago)
>
> On Wed, Mar 17, 2021 at 05:03:11PM -0700, Mahesh Jethanandani wrote:
> > I have seen the debate on the use of prefixes in YANG models, specially
> as it relates to their use when importing a model. I think it would nice to
> be clear on what is required, what is nice, and what is not ok to do. I do
> not want to confuse this discussion with the length of the prefix, which I
> believe is somewhat related but not the same discussion.
> >
> > RFC 7950 says:
> >
> >All prefixes, including the prefix for the module itself, MUST be
> >unique within the module or submodule.
> >
> > This is a requirement, as is clear by the MUST.
> >
> > Then RFC 7950 says:
> >
> >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.
> >
> > It also says:
> >
> >When used inside the "import" statement, the "prefix" statement
> >defines the prefix to be used when accessing definitions inside the
> >imported module.
> >
> > Clearly, the scope of the "prefix" statement used with an "import"
> statement is limited to the module where it is imported and does not impact
> the imported module. As such, and because it is a SHOULD and not a MUST,
> this is a "nice to have"  without conflicts, but one would not be wrong
> using a different prefix from the one defined in the imported module. Add
> to this, most tools, e.g. pyang or yanglint do not complain if you do
> define a different prefix when there are no conflicts. I have not seen a
> problem in the implementation of the module when the prefix is different.
> >
> > RFC 8407 confuses this whole situation by saying:
> >
> >   The proper module prefix MUST be used for all identifiers imported
> >   from other modules.
> >
> > which as written is true for identifiers (but not for other types of
> imports??). Besides, it does not define what is "proper mo

Re: [netmod] Use of prefixes in YANG models

2021-03-18 Thread Don Fedyk 
Clarity and consistency would help.

Many of the supporting tool chains are picky about prefixes. IE they must be 
the same as in the definition file.  I have a case where yanglint wants "local 
prefixes or derived-from(-or-self) construct" for an local identity in an xpath 
statement. (either remedy seems to work.) I argued for the prefixes in but 
others argue they are not necessary but I cannot validate without them. 

"not(derived-from(../../bridge-type,'two-port-mac-relay-bridge'))" works 
(prefix/no prefix)
But "../../bridge-type != 'dot1q:two-port-mac-relay-bridge'  works too.

Thanks
Don 

 

-Original Message-
From: netmod  On Behalf Of tom petch
Sent: Thursday, March 18, 2021 7:50 AM
To: Mahesh Jethanandani ; Juergen Schoenwaelder 

Cc: netmod@ietf.org
Subject: Re: [netmod] Use of prefixes in YANG models

From: netmod  on behalf of Juergen Schoenwaelder 

Sent: 18 March 2021 08:05

We often do not do a good job in distinguishing technical requirements from 
usage guidelines. (And RFC 2119 keywords make things worse.)

As far as I recall, the intent of the RFC 8407 text was to say that it is 
helpful for _humans_ to always use 'if:name' when you refer to the leaf 'name' 
defined in 'ietf-interfaces' or 'yang:date-and-time' when you refer to 
'date-and-time' defined in 'ietf-yang-types'.

I believe we agreed that module authors assigning a prefix different from the 
default prefix during an import should have either technical reasons for doing 
so (resolving prefixes clashes) or some other good reason to depart from the 
general guideline aiming to reduce human confusion.


To make an abstract concept concrete, draft-ietf-babel-yang-model imports yang 
types from RFC6991 and gives it the prefix yt: as in yt:date-and-time or 
yt:counter32.  An early YANG Doctor review by Radek did not comment on this 
aspect of the I-D.  More recently, I have.

Tom Petch



/js (who stopped believing that RFC 2119 keywords are helpful years ago)

On Wed, Mar 17, 2021 at 05:03:11PM -0700, Mahesh Jethanandani wrote:
> I have seen the debate on the use of prefixes in YANG models, specially as it 
> relates to their use when importing a model. I think it would nice to be 
> clear on what is required, what is nice, and what is not ok to do. I do not 
> want to confuse this discussion with the length of the prefix, which I 
> believe is somewhat related but not the same discussion.
>
> RFC 7950 says:
>
>All prefixes, including the prefix for the module itself, MUST be
>unique within the module or submodule.
>
> This is a requirement, as is clear by the MUST.
>
> Then RFC 7950 says:
>
>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.
>
> It also says:
>
>When used inside the "import" statement, the "prefix" statement
>defines the prefix to be used when accessing definitions inside the
>imported module.
>
> Clearly, the scope of the "prefix" statement used with an "import" statement 
> is limited to the module where it is imported and does not impact the 
> imported module. As such, and because it is a SHOULD and not a MUST, this is 
> a "nice to have"  without conflicts, but one would not be wrong using a 
> different prefix from the one defined in the imported module. Add to this, 
> most tools, e.g. pyang or yanglint do not complain if you do define a 
> different prefix when there are no conflicts. I have not seen a problem in 
> the implementation of the module when the prefix is different.
>
> RFC 8407 confuses this whole situation by saying:
>
>   The proper module prefix MUST be used for all identifiers imported
>   from other modules.
>
> which as written is true for identifiers (but not for other types of 
> imports??). Besides, it does not define what is "proper module prefix". In 
> the absence of a proper definition, one should follow what RFC 7950 says.
>
> Comments?
>
> Mahesh Jethanandani
> mjethanand...@gmail.com
>
>
>
>
>

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


--
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 <https://www.jacobs-university.de/>

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

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

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

Re: [netmod] Use of prefixes in YANG models

2021-03-18 Thread tom petch 
From: netmod  on behalf of Juergen Schoenwaelder 

Sent: 18 March 2021 08:05

We often do not do a good job in distinguishing technical requirements
from usage guidelines. (And RFC 2119 keywords make things worse.)

As far as I recall, the intent of the RFC 8407 text was to say that it
is helpful for _humans_ to always use 'if:name' when you refer to the
leaf 'name' defined in 'ietf-interfaces' or 'yang:date-and-time' when
you refer to 'date-and-time' defined in 'ietf-yang-types'.

I believe we agreed that module authors assigning a prefix different
from the default prefix during an import should have either technical
reasons for doing so (resolving prefixes clashes) or some other good
reason to depart from the general guideline aiming to reduce human
confusion.


To make an abstract concept concrete, draft-ietf-babel-yang-model imports yang 
types from RFC6991 and gives it the prefix yt: as in yt:date-and-time or 
yt:counter32.  An early YANG Doctor review by Radek did not comment on this 
aspect of the I-D.  More recently, I have.

Tom Petch



/js (who stopped believing that RFC 2119 keywords are helpful years ago)

On Wed, Mar 17, 2021 at 05:03:11PM -0700, Mahesh Jethanandani wrote:
> I have seen the debate on the use of prefixes in YANG models, specially as it 
> relates to their use when importing a model. I think it would nice to be 
> clear on what is required, what is nice, and what is not ok to do. I do not 
> want to confuse this discussion with the length of the prefix, which I 
> believe is somewhat related but not the same discussion.
>
> RFC 7950 says:
>
>All prefixes, including the prefix for the module itself, MUST be
>unique within the module or submodule.
>
> This is a requirement, as is clear by the MUST.
>
> Then RFC 7950 says:
>
>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.
>
> It also says:
>
>When used inside the "import" statement, the "prefix" statement
>defines the prefix to be used when accessing definitions inside the
>imported module.
>
> Clearly, the scope of the “prefix" statement used with an “import” statement 
> is limited to the module where it is imported and does not impact the 
> imported module. As such, and because it is a SHOULD and not a MUST, this is 
> a “nice to have”  without conflicts, but one would not be wrong using a 
> different prefix from the one defined in the imported module. Add to this, 
> most tools, e.g. pyang or yanglint do not complain if you do define a 
> different prefix when there are no conflicts. I have not seen a problem in 
> the implementation of the module when the prefix is different.
>
> RFC 8407 confuses this whole situation by saying:
>
>   The proper module prefix MUST be used for all identifiers imported
>   from other modules.
>
> which as written is true for identifiers (but not for other types of 
> imports??). Besides, it does not define what is “proper module prefix". In 
> the absence of a proper definition, one should follow what RFC 7950 says.
>
> Comments?
>
> Mahesh Jethanandani
> mjethanand...@gmail.com
>
>
>
>
>

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


--
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

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

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

Re: [netmod] Use of prefixes in YANG models

2021-03-18 Thread Juergen Schoenwaelder 
We often do not do a good job in distinguishing technical requirements
from usage guidelines. (And RFC 2119 keywords make things worse.)

As far as I recall, the intent of the RFC 8407 text was to say that it
is helpful for _humans_ to always use 'if:name' when you refer to the
leaf 'name' defined in 'ietf-interfaces' or 'yang:date-and-time' when
you refer to 'date-and-time' defined in 'ietf-yang-types'.

I believe we agreed that module authors assigning a prefix different
from the default prefix during an import should have either technical
reasons for doing so (resolving prefixes clashes) or some other good
reason to depart from the general guideline aiming to reduce human
confusion.

/js (who stopped believing that RFC 2119 keywords are helpful years ago)

On Wed, Mar 17, 2021 at 05:03:11PM -0700, Mahesh Jethanandani wrote:
> I have seen the debate on the use of prefixes in YANG models, specially as it 
> relates to their use when importing a model. I think it would nice to be 
> clear on what is required, what is nice, and what is not ok to do. I do not 
> want to confuse this discussion with the length of the prefix, which I 
> believe is somewhat related but not the same discussion.
> 
> RFC 7950 says:
> 
>All prefixes, including the prefix for the module itself, MUST be
>unique within the module or submodule.
> 
> This is a requirement, as is clear by the MUST.
> 
> Then RFC 7950 says:
> 
>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.
> 
> It also says:
> 
>When used inside the "import" statement, the "prefix" statement
>defines the prefix to be used when accessing definitions inside the
>imported module.
> 
> Clearly, the scope of the “prefix" statement used with an “import” statement 
> is limited to the module where it is imported and does not impact the 
> imported module. As such, and because it is a SHOULD and not a MUST, this is 
> a “nice to have”  without conflicts, but one would not be wrong using a 
> different prefix from the one defined in the imported module. Add to this, 
> most tools, e.g. pyang or yanglint do not complain if you do define a 
> different prefix when there are no conflicts. I have not seen a problem in 
> the implementation of the module when the prefix is different.
> 
> RFC 8407 confuses this whole situation by saying:
> 
>   The proper module prefix MUST be used for all identifiers imported
>   from other modules.
> 
> which as written is true for identifiers (but not for other types of 
> imports??). Besides, it does not define what is “proper module prefix". In 
> the absence of a proper definition, one should follow what RFC 7950 says.
> 
> Comments?
> 
> Mahesh Jethanandani
> mjethanand...@gmail.com
> 
> 
> 
> 
> 

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


-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

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

[netmod] Use of prefixes in YANG models

2021-03-17 Thread Mahesh Jethanandani 
I have seen the debate on the use of prefixes in YANG models, specially as it 
relates to their use when importing a model. I think it would nice to be clear 
on what is required, what is nice, and what is not ok to do. I do not want to 
confuse this discussion with the length of the prefix, which I believe is 
somewhat related but not the same discussion.

RFC 7950 says:

   All prefixes, including the prefix for the module itself, MUST be
   unique within the module or submodule.

This is a requirement, as is clear by the MUST.

Then RFC 7950 says:

   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.

It also says:

   When used inside the "import" statement, the "prefix" statement
   defines the prefix to be used when accessing definitions inside the
   imported module.

Clearly, the scope of the “prefix" statement used with an “import” statement is 
limited to the module where it is imported and does not impact the imported 
module. As such, and because it is a SHOULD and not a MUST, this is a “nice to 
have”  without conflicts, but one would not be wrong using a different prefix 
from the one defined in the imported module. Add to this, most tools, e.g. 
pyang or yanglint do not complain if you do define a different prefix when 
there are no conflicts. I have not seen a problem in the implementation of the 
module when the prefix is different.

RFC 8407 confuses this whole situation by saying:

  The proper module prefix MUST be used for all identifiers imported
  from other modules.

which as written is true for identifiers (but not for other types of 
imports??). Besides, it does not define what is “proper module prefix". In the 
absence of a proper definition, one should follow what RFC 7950 says.

Comments?

Mahesh Jethanandani
mjethanand...@gmail.com





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