Re: [netmod] [Editorial Errata Reported] RFC6991 (7647)

2023-09-22 Thread Jürgen Schönwälder
On Mon, Sep 18, 2023 at 04:23:59AM -0700, RFC Errata System wrote:

> Notes
> -
> In Section 3, the textual definition of the "ietf-yang-types" module 
> presents, in my opinion, inconsistencies when defining typedefs that point to 
> other typedefs in the same module: sometimes the value for the "type" key 
> contains the prefix of the module and sometimes not. Please, see the example 
> attached. This can also be applied to other typedefs defined in the latest 
> revisions of the module, such as "date-no-zone" and "time-no-zone". I think 
> this should be addressed to provide clarification and consistency, and thus 
> can be extended to other modules and the YANG standard as well. Thanks for 
> your time.
>

Using the prefix is perhaps redundant but surely not wrong.

Which consistency are you looking for, use of prefixes only when
absolutely necessary, or always use prefixes?

/js

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

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


Re: [netmod] Poll on YANG Versioning NBC Approach

2023-09-22 Thread Per Andersson (perander)
Hi!

> Andy Bierman  on Thursday, September 14, 2023 18:40:
>> On Thu, Sep 14, 2023 at 9:05 AM Acee Lindem 
>> mailto:acee.i...@gmail.com>> wrote:
>>> On Sep 13, 2023, at 10:36, Ladislav Lhotka 
>>> mailto:40nic...@dmarc.ietf.org>> 
>>> wrote:
(...)
>>> We have already seen cases that the update rules prevented fixing problems 
>>> in YANG modules in a straightforward way, and backward-compatible fixes 
>>> negatively affected module readability. This is inevitable until the 
>>> ecosystem of YANG modules stabilizes. That's why I think changing update 
>>> rules from MUST to SHOULD is appropriate - it should have been so from the 
>>> beginning.
>>
>> I wholeheartedly agree. We need to be able to fix YANG modules with NBC 
>> changes. I know of at least one implementation that support NBC changes for 
>> proprietary models with node-specific translation
>
> Some of us do not think a bugfix counts as an NBC change.
> If the YANG definition is wrong and has been wrong from the start, then BC is 
> not important.
> Fixing the YANG module so the definitions match the intent of the authors is 
> important.

I don't understand why the motivation for a particular change should come into 
play.
Either the change is NBC or BC, whether it being a bugfix or not, and the text 
in RFC 7950
states how it should be handled.

Although I am on the vendor side in this context, as a user I find it important 
to be notified
if a change is NBC even if it is a bugfix. It is also important to be able to 
both publish and
consume compatibility levels on dependencies and imports, e.g. recommended-min.


> IMO this new draft is not really needed at all, since bugfix exceptions 
> should be allowed
> and should have always been allowed.

I was not involved when YANG was defined, so I know little to nothing of these 
discussions.
What I follow is the actual text in the standard, and it does not discern 
between classes of
motivation for changes (e.g. bugfix, feature) and how they should be allowed or 
not.


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