[netconf] Re: [core] adding PEN-based SID allocation to RFC9595

[Carsten Bormann <[e-mail]>]

Hi Andy,

Apologies for Apple mail not picking up the difference between what you wrote and what MCR wrote.
So, one of you said :-):

> Carsten started a thread about PEN-based range assignments (not sure where)

I wrote a draft a while ago:

https://www.ietf.org/archive/id/draft-bormann-core-yang-sid-pen-01.html

These are numbers in the 64-bit space.
If you want to get 32-bit numbers for better deltas, we have to be a bit more frugal.
(We could still do both a chunk of 32-bit numbers and a wider swatch of 64-bit numbers at the same time.)

(Let’s say we want to accommodate up to 19 bit PENs, and we want to allocate 31 of the 32 bits of 1+4 space, leaving the rest for mega-ranges, we’d have 4096 SIDs for each PEN.
Organizations that need more can just get a mega-range.)ef

> - A mini-range could be automatically assigned for PEN
>     20 bits: PEN   + 12 bit SID range  == 4096 SIDs per PEN

Yes, but we still need space for mega ranges.

> - A real mega-range must be allocated if 4096 SIDs are not enough or 2^^20 PENs gets filled up

If there are 2**20 PENs, we’ll have to rethink this.
2**19 is 8 times what we have allocated so far.

> Another alternative is to create a vendor-proprietary FCFS range under the
> IETF Mega-Range.   I think that 100K numbers would be plenty for now.
> Or we could create another Mega-Range for this.

We don’t need to do this, because:

> I am thinking about starting an OpenSID (public) mega-range and just creating SID files
> for every publicly available YANG module.  netconfcentral.org already tracks over 4000 modules.
> IMO the rule that there SHOULD only be one SID assignment for each YANG schema node
> is not required and impeding any progress to YANG/CBOR adoption.

That’s what 9254 says: It’s not required, but still rather useful.

> One issue that came up was that IANA does not want to manage all the mega-ranges.

What do you mean by that?
Manage the mega-ranges (per se) or manage the SIDs inside each mega-range?
The point is that the owner of the mega-range does the latter.

> This requires excellent tooling and procedures, neither of which are mature yet.
> An automatic PEN range would not need any IANA involvement.

Correct.

> IMO waiting for each "owner" of the YANG module to publish a SID file is a non-starter.
> There are no SID files yet and adding them 1 or 2 at a time will take a decade.

I like you idea of going ahead and publishing SID files for random vendor stuff where the vendor is not doing its homework.
But if they do, they should be in control.

> I've asked for time to present about
> draft-richardson-netmod-atrest-extensions, which is very much a drafty-draft.

The main useful idea I see here is submaps.  
That allows the deltas to be more efficient if you augment a module with more than one item.

> In order to let private enterprises do their own extensions, having SIDs
> would help.  

We could also cbor-packed—like table setups for data-item internal SID ranges.
Requires more thinking.
Lots of complexity without a clear benefit, though.

> Without SIDs for every module in use the YANG/CBOR encoding is not really worth using.
> Any effort to get some SID files out there would help.

Yes!  Let’s

* Fix PYANG to spit out conforming output (or use my tools for making the PYANG output conforming)
* Go ahead with the YANG-SID Modules Designated Experts (Michel Veillette, Alexander Pelov, Laurent Toutain) and register everything that belongs to the IETF
* Do the IEEE thing
* Set up something that enables third-party registrations of SIDs for other YANG modules

Now, doing the PEN thing (32, 64, or both) is kind of orthogonal to that; I can update my draft to provide a 32-bit range (say, 4000 SIDs per PEN) as well in addition to the 64-bit range already in the draft (100000 SIDs per PEN).

Grüße, Carsten