Re: [netmod] I-D Action: draft-ietf-netmod-rfc6991-bis-14.txt

[tom petch <[e-mail]>]

<at the end <tp>>

From: netmod <[e-mail]> on behalf of Acee Lindem (acee) 
Sent: 08 December 2022 10:55

From: netmod <[e-mail]> on behalf of Andy Bierman <[e-mail]>
Date: Wednesday, December 7, 2022 at 10:48 PM

On Wed, Dec 7, 2022 at 7:02 PM Kent Watsen <[e-mail]> wrote:

>> Deprecating ip-address (and ipv4-address and ipv6-address?) is probably the
>> most disruptive
>> change to YANG that one could make.

No, the most disruptive thing would be to do what roughly 1/2 of the WG was proposing before, which is to introduce now a non-backwards compatible change in the existing definitions, which would immediately break all legacy uses.


>> A type name cannot be changed.

Nothing of the sort is being proposed here.


>> A new name can be introduced so there are 2 types that do the same thing.
>> IMO this will increase the overall confusion, and not help in any way.

We are addressing the current/existing confusion, as discussed in the last 9 months and in a virtual interim.  Not doing anything would be truly unhelpful.

The strategy is to gradually move towards having only explicit names.   The first step is to introduce a new explicit name, while deprecating the legacy ambiguous name.  This provides time for modules to slowly migrate to the new name.  The second step, to be done only after the "versioning" work lands, is to remove the legacy deprecated name, while marking the module revision as having an NBC change.

IMO there is no operational problem to fix.
It is too late to change the names of the IP addresses with zones.
It is not a real problem because the server is still responsible for
accepting or sending the zone index (just like address 0.0.0.0).

For data types where the zone is never supposed to be allowed may need to
change to the no-zone variant.

Redoing all YANG modules that use the (proposed) deprecated ip-address
to some other type name is very disruptive and not needed.

I agree – this is the “cut the baby in half” option.

<tp>

The wisdom of Solomon.

With hindsight we could have done better but we are where we are and I do not see reports of problems arising because a module writer did not read the specification before assuming he knew what was meant.
The idea of making an identifier carry the semantics of an identity is not just one of my pet hates but an approach that leads to mistakes.  (Happily most YANG Doctors appreciate this so we rarely end up with XPath such as
/link/link-interface/link-interface-msd/link-interface-msd-erd etc )

On the other hand I was just looking at the IANA registries for LSR and trying to find which one contains a more detailed  set of TLV - the choice of identifiers has grown with time and does not make it easy.

Tom Petch
Acee


Andy

Between the two steps is when there may be confusion but even then, not really, if tooling properly warns about deprecated nodes.


Kent // contributor