I am still confused, and could not find the answer in draft-ietf-core-sid, and i would like to gret unconfused to be able to ask for the temporary SID allocations:
Assume We keep the the allocation of 2400...49 range for RFC8366, then i understand that this first means "the team" needs to create a .sid file for rfc8366 from that range. Great. But then how about rfc8366bis ? Will that be able to take unused SID from the 2400...49 range ? Seems like a waste if not, right ? So would we then later add [RFC8366bis] to the 2400...49 range ??? How about those temporary allocations. [email protected] does not mention them. Can we assume that we can still ask IANA for them using exactly the approach described above, aka: we start adding [I-D.ietf-anima-rfc8366bis] to the 2400...49 range ??? And then how about the 2450...2549 ranges for constrained voucher. I think they go back to pre-rfc8366bis times, and given how the rfc8366bis Yang model has not only extensions for constrained voucher, but also for other BRSKI extensions, i would be worried that one could use automated tools to allocate constrained voucher extensions in rfc8366bis into the 2450... range as opposed to the 2400 range. Maybe it's possible with manual hacking of the .sid file. Is that what we want ?? Would it not be more useful to: a) ask for temporary allocation of 2400...49 (on top of rfc8366) for rfc8366 bis as well as for only rfc8366bis for 2450...49. b) Create the .bis files for rfc8366 and rfc8366bis and update the constrained voucher draft to use the generated .sid values in it's examples. Aka: I'd be happy to ask as ANIMA chair for the temporary allocation if i knew that the allocations i am asking for will work out perfectly - be it through the approach described above, or any other. I just need to see a plan! Cheers Toerless On Tue, Jul 09, 2024 at 01:49:01PM -0400, Michael Richardson wrote: > > Toerless Eckert <[email protected]> wrote: > > Thanks, Michael - i wish that text you wrote would be in the SID RFC. > > Without it, its really impossible to imagine how the SID allocation is > supposed > > to work. > > I think the operational aspects of it will wind up in the wiki, to be revised > a few times as we discover awkward aspects. > > > Is there already an example of an early attempt at the resulting IANA > > information ? It's not clear to me where the .sid file would live. I > guess > > the YANG module would be in the RFC. Which isn't ideal for machine > consumption > > either... > > YANG modules live at places like: > > https://www.yangcatalog.org/yang-search/module_details/ietf-voucher@2023-01-10 > > and I expect this to be extended to include the .SID file. > > Esko, your issues probably relate to lack of merged: > https://github.com/core-wg/pyang/pull/7/files > > > > -- > Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > > -- --- [email protected] _______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
