Re: [core] Robert Wilton's Discuss on draft-ietf-core-sid-21: (with DISCUSS and COMMENT)

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Michael,

> -----Original Message-----
> From: Michael Richardson <[e-mail]>
> Sent: Friday, October 20, 2023 4:58 PM
> To: Rob Wilton (rwilton) <[e-mail]>
> Cc: The IESG <[e-mail]>; [e-mail]; [e-mail];
> [e-mail]
> Subject: Re: [core] Robert Wilton's Discuss on draft-ietf-core-sid-21: (with
> DISCUSS and COMMENT)
> 
> 
> Thank you for persisting through this Rob!
[Rob Wilton (rwilton)] 
No problem.  I think that we are close to where we want to be.

> 
> Robert Wilton via Datatracker <[e-mail]> wrote:
>     > related aspects for creating/managing SID files in drafts that I want
>     > to ensure
>     > that the IESG is at very least aware of and happy with.
> 
>     > (1) p 23, sec 6.4.3.  Publication of the ".sid" file
> 
>     > For a YANG module approved for publication as an RFC, a ".sid" file
>     > SHOULD be included in the Internet-Draft as a source code block.
> 
>     > I'm wondering if this is really the best approach.  I.e., I think to
>     > guarantee
>     > that the SID file is correct at the point of pulication (e.g., if names
>     > of YANG
> 
> For the first year or two, with a new YANG module I strongly think that the
> authors need to review the resulting sid file (the allocations) to be sure
> that they are correct.
[Rob Wilton (rwilton)] 
I would like the primary responsibility to be on some designated SID experts (with input from the authors) rather than the authors themselves.  Many authors of YANG files won't know anything about SID files and hence won't necessarily know (or possibly even care) that they are right.

> 
> Yes, of course, IANA or RPC SHOULD double check.
> It is here that we might run into bugs in pyang that the RPC will need
> support on, and this is why I keep poking the Tools team about pyang
> maintenance.
> 
> I also want to push back on the idea that SIDs are just for constrained
> environments: we have heard from Andy that every byte counts in bigger
> networks, and that comparing uin63s is gonna be way faster than XML string
> compares.
[Rob Wilton (rwilton)] 
Yes, agreed.  We are also considering CBOR +/ SIDs for operational data on large network devices as well.

My comment was more meant to be about when the SID file becomes available.  I.e., whether they are maintained as the YANG module and drafts evolve.  Given it is quite common for updated YANG modules to be published in drafts with an incorrect revision-date, it seems even less likely to me that the SID files will necessarily be up to date and correct (if published in the draft).  I still think that the real solution here is to automate as much of this draft + YANG file handling as possible.  I.e., use a make file, or perhaps github hook to automatically generate an updated SID file when authors change the YANG file.  But this is beyond what we need to agree now and write into an RFC.

Regards,
Rob


> 
> 
> --
> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
>