Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Randy Presuhn <[e-mail]>]

Hi -

On 2022-04-14 1:13 PM, Jürgen Schönwälder wrote:
> On Thu, Apr 14, 2022 at 12:48:18PM -0700, Andy Bierman wrote:
> 
>> The proposal is for a 2 year phase to change modules
>> that really do want a zone index.  It is not blindly removing the zone
>> index.
> 
> People not reading type definitions will also not read a warning
> signs. This is blindly removing the zone index in two years, I hardly
> see a difference from doing the same (damage) today.
> 
> Lets start with one of the oldest modules affected, RFC 7317. The
> ietf-system module is using ip-address correctly (allowing DNS servers
> to be reachable via link-local addresses). So who is going to revise
> RFC 7317 in the two years? It would be strange to file an errata
> addressing a problem that will break the module in two years from
> now. In fact, there is no problem in RFC 7317, the problem is that we
> break the YANG module update rules that protect YANG modules from
> getting broken by updates to other YANG modules.
> 
> And we do all of this because the name ip-address in hindsight is
> confusing?
> 
> As you pointed out, an implementer can choose to ignore the optional
> zone index. However, if we remove the optional zone index, then
> implementors have no choice anymore since the data model by design
> prevents a meaningful implementation that works with link-local
> addresses. The key is that we have to trust data model writers to pick
> the right type. The assumption that every author who used ip-address
> really wanted ip-address-no-zone is very wild idea.
> 
> /js (feeling lost in the modern software world)

Total agreement.  I share your bewilderment that a standardization
organization would even consider deliberately breaking compatibility
to "fix" a non-problem, particularly a non-problem that has been widely
deployed for over a decade.

Randy