Subject: [core] SID file --- status entry for allocation

From: Michael Richardson <[email-masked]>
Date: Thu, 24 Mar 2022 19:31:41 +0100

Today in discussion with ADs Rob Wilton and Francesca, it became clear that
we really need to add a status entry to the SID file for allocations.

The use case is where we have taken a YANG module to RFC, and have created a
stable set of SID allocations for it.  Then, we revise the module. During
that process of doing draft-foo-bar-rfcBIS, we might want to reset the SID
numbering as we add/subtract/modify the extension proposals.

So we need to know which parts of the SID file we can reset, and which parts
we can not.

This is a rudamentary pull request to do that.  I am uncertain if this YANG
module parses as yet.  I haven't done any work on sid.py to implement this.

Please let me know if I captured the proposal well enough.
I don't know what to call the thing which is not stable.
I feel that "unstable" does not quite capture the proper intent.

https://github.com/core-wg/yang-cbor/pull/141

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Andy Bierman <[email-masked]>
Date: Thu, 24 Mar 2022 12:45:48 -0700

> So we need to know which parts of the SID file we can reset, and which

This information is part of the development work in progress.
The SID file for an RFC MUST be stable, so the value of each leaf in an RFC
SID file
will always be 'stable' (and therefore useless).

Subsequent RFCs MUST NOT alter previous SID assignments made in previous
RFCs.
If SID assignments can be undone by a new RFC they can never be considered
stable.

All changes to I-Ds are inherently subject-to-review.
This may be worth noting at the file-level, but certainly
not at the SID level.

Andy

> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 24 Mar 2022 20:57:49 +0100

> This information is part of the development work in progress.

Exactly!
We distinguished the SID files you use for working with “unstable” YANG modules (e.g., still at I-D status for IETF, but the terminology needs to be wider than that) with the ones that have been adopted for “stable” YANG modules (in the IETF, published in an RFC).

> The SID file for an RFC MUST be stable, so the value of each leaf in an RFC SID file

This is why ’stable’ is the default, so we can use existing SID files.

> Subsequent RFCs MUST NOT alter previous SID assignments made in previous RFCs.

Exactly, that’s why these are marked stable.

> If SID assignments can be undone by a new RFC they can never be considered stable.

Indeed.

> All changes to I-Ds are inherently subject-to-review.

Well, “subject-to-review” was not the word we used in the discussion.
We used “unstable”, deliberately.

> This may be worth noting at the file-level, but certainly

That would be true if we could make sure that SID files never turn up in a place where their context may not be immediatelyavailable.

E.g., if I start revising a YANG module, I will feed the stable SID file to pyang and get a new SID file.  Now I need to make sure that SID file never gets into the hands of people who might think about this as the final product.
So pyang will mark some of the assignments as unstable.
I can even feed that to pyang after revising the YANG module again, and pyang will respect both the stable and the unstable assignments in the same file, but transfer the stability status to the new SID file, alongside with marking any new ones as unstable.  Until the YANG module itself makes the transition from unstable to stable, at which time I’d make a final allocation step, marking all surviving new allocations as stable (as well as the existing stable ones).

Grüße, Carsten

---

From: Andy Bierman <[email-masked]>
Date: Thu, 24 Mar 2022 13:16:00 -0700

On Thu, Mar 24, 2022 at 12:57 PM Carsten Bormann <[email-masked]> wrote:

> We distinguished the SID files you use for working with “unstable” YANG
> modules (e.g., still at I-D status for IETF, but the terminology needs to
> be wider than that) with the ones that have been adopted for “stable” YANG
> modules (in the IETF, published in an RFC).
>
> That would be true if we could make sure that SID files never turn up in a
> place where their context may not be immediatelyavailable.
>
> E.g., if I start revising a YANG module, I will feed the stable SID file
> to pyang and get a new SID file.  Now I need to make sure that SID file
> never gets into the hands of people who might think about this as the final
> product.
> I can even feed that to pyang after revising the YANG module again, and
> pyang will respect both the stable and the unstable assignments in the same
> file, but transfer the stability status to the new SID file, alongside with
> marking any new ones as unstable.  Until the YANG module itself makes the
> transition from unstable to stable, at which time I’d make a final
> allocation step, marking all surviving new allocations as stable (as well
> as the existing stable ones).
>
>

Is the WG supposed to hand-edit SID files for inclusion in I-Ds?
pyang needs to have the parent SID file to generate an update.

How does a developer know which individual SID assignments to set to
'unstable'?
If the tooling is supposed to know, then why do developers need to care?

Grüße, Carsten
Andy

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 24 Mar 2022 21:22:22 +0100

> Is the WG supposed to hand-edit SID files for inclusion in I-Ds?

I hope not.

> pyang needs to have the parent SID file to generate an update.

Yes.  Plus a flag that says whether this is another SID file with unstable SIDs or whether the resulting SID file will be the new stable.
(The first case could even be split into an “add-only” and a “wholesale replace” for the unstable ones — the unstable ones would simply be ignored in the latter case.)

> How does a developer know which individual SID assignments to set to 'unstable'?

Pyang knows (once given the above flag).

> If the tooling is supposed to know, then why do developers need to care?

Indeed, we didn’t say *why* you would want that information (except that it makes life easier for the tooling).
It was Rob’s conviction that you would want that, and I do sympathize with that.

Grüße, Carsten

---

From: Andy Bierman <[email-masked]>
Date: Thu, 24 Mar 2022 15:08:51 -0700

On Thu, Mar 24, 2022 at 1:22 PM Carsten Bormann <[email-masked]> wrote:

> Yes.  Plus a flag that says whether this is another SID file with unstable
> SIDs or whether the resulting SID file will be the new stable.
> (The first case could even be split into an “add-only” and a “wholesale
> replace” for the unstable ones — the unstable ones would simply be ignored
> in the latter case.)
>
The process for managing SID assignments should be marked 'unstable'.

I imagined that a SID allocation block would be the lowest granularity
needed for module updates.
So the granularity is the assignment-range, not each SID.

leaf /sid-file/assignment-range/stable { type boolean; default true; }

e.g.

Module foo initially has 1 assignment range

All I-Ds leading to first RFC:
{
    entry-point=2000
    size=40
    stable=false
}

Publish the first RFC (locking the assignment range forever!)

{
    entry-point=2000
    size=40
    stable=true
}

Later, a new assignment range is allocated for new SIDs intended for RFC_2

All I-Ds after RFC_N, leading to RFC_N+1 (now have 2 assignment ranges)

{
    entry-point=2000
    size=40
    stable=true
},
{
    entry-point=6000
    size=40
    stable=false
}

What are the use-cases for marking some SIDs within a range as stable,
and other SIDs in the same range as unstable?

The ranges are already intentionally small so "SID waste" is minimized.

Grüße, Carsten

Andy

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 25 Mar 2022 03:23:19 +0100

> and other SIDs in the same range as unstable?

There is quite some benefit from keeping the SIDs used by a module close together.
If you plan for evolution, you keep some free space in the SID range allocated for a module.
So the bis version of a module can expand into that free space first before needing to allocate a second range.

> The ranges are already intentionally small so "SID waste" is minimized.

There is a tradeoff here, and I would expect we arrive at some rule of thumb for how many SIDs we want to keep available in the SID range used for a module and its revisions (e.g., keep 1/3 for expansion?).

So I don’t think the granularity of stable/unstable assignment can be per range, it really needs to be per SID.

Grüße, Carsten

---

From: Andy Bierman <[email-masked]>
Date: Fri, 25 Mar 2022 08:36:22 -0700

On Thu, Mar 24, 2022 at 7:23 PM Carsten Bormann <[email-masked]> wrote:

> So the bis version of a module can expand into that free space first
> before needing to allocate a second range.
>
> There is a tradeoff here, and I would expect we arrive at some rule of
> thumb for how many SIDs we want to keep available in the SID range used for
> a module and its revisions (e.g., keep 1/3 for expansion?).
>

The per-SID entry flag allows for non-contiguous stable vs. unstable SIDs.
Is this really needed?   SID_base +17 and +19 are stable but +18 is
unstable?
If not, then a simple 'block-used' leaf should work:

// if any SIDs left in a range at RFC publication then last-used will be
less
// than entry-point + size - 1
{
    entry-point=2000
    size=40
    last-used=2039
},
{
    entry-point=6000
    size=40
    last-used=6004
}

Whatever the changes are, the SID file draft should contain normative text
explaining
exactly how this 'status=unstable' flag is used in the SID file.

It should be possible for multiple independent implementations of a SID
file generator
tool to be written, from the RFC.  It should be possible for such tools to
produce
the same exact series of SID files, for the same exact set of input YANG
modules.

The plan seems to be just to publish whatever pyang generates.
How will anybody know if the SID file is correct?

Grüße, Carsten

Andy

---

From: Michael Richardson <[email-masked]>
Date: Mon, 28 Mar 2022 09:02:37 +0200

> All I-Ds leading to first RFC: { entry-point=2000 size=40 stable=false
    > }

    > { entry-point=2000 size=40 stable=true }

We prefered not to say stable=true/false, on the assumption that there might
in the future be a third value.  So "status=stable"

    > and other SIDs in the same range as unstable?

Because when in the I-D stage for a RFCXXXXbis, we need to keep the SIDs
allocated by RFCXXXX stable, but the new ones from XXXXbis (an ID) could be
renumbered without conseuqnece.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 28 Mar 2022 09:05:15 +0200

Andy Bierman <[email-masked]> wrote:
    > The per-SID entry flag allows for non-contiguous stable vs. unstable
    > SIDs.  Is this really needed?  SID_base +17 and +19 are stable but +18
    > is unstable?  If not, then a simple 'block-used' leaf should work:

1) You assume two ranges, which many modules will not have.
2) SIDs created during RFCXXXXbis are unstable.

    > file generator tool to be written, from the RFC.  It should be possible
    > for such tools to produce the same exact series of SID files, for the
    > same exact set of input YANG modules.

Agreed.

    > The plan seems to be just to publish whatever pyang generates.  How
    > will anybody know if the SID file is correct?

I agree that we need to examine .sid files careful for awhile.
Certainly, core-sid can't go to Internet Standard until there is a second
implementation. (pyang being the first)

---

From: Andy Bierman <[email-masked]>
Date: Mon, 28 Mar 2022 03:21:24 -0700

> renumbered without conseuqnece.

I assume the exact procedures for automatic SID file generation will be
updated
to reflect the changes being made.  It looks like the procedure is not
manual and ad-hoc,
IMO dramatically reducing its robustness and reliability

I think the statements about permanent assignments is false:

   SIDs are assigned permanently.  Items introduced by a new revision of
   a YANG module are added to the list of SIDs already assigned.
   Assignment of SIDs to YANG items are usually automated as discussed
   in Appendix B, which also discusses some cases where manual
   interventions may be appropriate.

Andy

---

From: Alexander Pelov <[email-masked]>
Date: Mon, 28 Mar 2022 15:22:33 +0200

Dear Michael, all,

Thanks for getting the discussion to the mailing list! It is indeed
exciting to see the IETF in-person meetings allowing for these discussions
to take place.

I am not sure I understand the premise of your mail, and the discussion
that follows touches upon several possibilities.
If you revise a module, you provide a new YANG file (with a different
name/revision), and if you need to change the semantics of some item..
well, you need a new SID.

Can you please provide an example that needs adding something new and
cannot be solved as currently it stands?

Cheers,
Alexander

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 28 Mar 2022 16:07:01 +0200

On 2022-03-28, at 15:22, Alexander Pelov <[email-masked]> wrote:
> 
> Dear Michael, all,
> 
> Thanks for getting the discussion to the mailing list! It is indeed exciting to see the IETF in-person meetings allowing for these discussions to take place.
> 
> I am not sure I understand the premise of your mail, and the discussion that follows touches upon several possibilities.
> If you revise a module, you provide a new YANG file (with a different name/revision), and if you need to change the semantics of some item.. well, you need a new SID.

Hi Alex,

we have to distinguish two cases here:

(1) The YANG module was unstable (e.g., early I-D state).
In this case, we can do what we want, including changing the (also unstable) SID-name mapping.

(2) The YANG module was stable (e.g., we are working on a -bis for a published RFC).
In this case, the SID-name mapping already has been marked stable.
I also think it would be highly inadvisable to “change the semantics of some item” even in the YANG module — if you want to do that, give it a new name, too, which allows you to allocate a new SID for the new name.
But the old name will keep its stable SID.

The reason we want to do this is:
(1) to keep the SID-name mapping a function — there never can be two YANG names associated with a single SID.
(2) to keep the name-SID mapping “mostly" a function — while we cannot completely prevent several independent SID allocations for a YANG name, one objective is to have a single “canonical” SID mapping for each YANG name, preferably with the same provenance that the YANG module itself has.

Yes, this still has to be written up at this level of clarity, which I plan to do in the next 10 days or so.

Grüße, Carsten

> 
> Can you please provide an example that needs adding something new and cannot be solved as currently it stands?
> 
> Cheers,
> Alexander
> 
> 
> 
> 
> 
> 
> On Thu, Mar 24, 2022 at 7:33 PM Michael Richardson <[email-masked]> wrote:
>

---

From: Alexander Pelov <[email-masked]>
Date: Mon, 28 Mar 2022 16:30:21 +0200

Hi Carsten,

Thanks a lot for the clarifications! (Fully agree with the comments on
changing the semantics of an item!)

I was really looking at which problem we are trying to solve.
The "stable/unstable" is already getting to a solution (which may be the
best, but I am not sure what the problem is yet).

>From what I understand, the problem we are trying to solve is (and I am
paraphrasing to see if we are on the same page) to try to limit and have
one SID per YANG name. Something like a 'canonical SID' (which would make
for a bijective correspondence "YANG name" <-> "canonical SID", for YANG
modules that have SID allocations). Is there something else we are trying
to solve with the "stable/unstable" solution?

Cheers,
Alexander

On Mon, Mar 28, 2022 at 4:07 PM Carsten Bormann <[email-masked]> wrote:

> I also think it would be highly inadvisable to “change the semantics of
> some item” even in the YANG module — if you want to do that, give it a new
> name, too, which allows you to allocate a new SID for the new name.
> (2) to keep the name-SID mapping “mostly" a function — while we cannot
> completely prevent several independent SID allocations for a YANG name, one
> objective is to have a single “canonical” SID mapping for each YANG name,
> preferably with the same provenance that the YANG module itself has.
>

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 28 Mar 2022 16:34:44 +0200

On 2022-03-28, at 16:30, Alexander Pelov <[email-masked]> wrote:
> 
> From what I understand, the problem we are trying to solve is (and I am paraphrasing to see if we are on the same page) to try to limit and have one SID per YANG name. Something like a 'canonical SID' (which would make for a bijective correspondence "YANG name" <-> "canonical SID", for YANG modules that have SID allocations).

Indeed.

> Is there something else we are trying to solve with the "stable/unstable" solution?

The main observation is that these SID files may get wings and may turn up in places where they were not meant to be.  Being able to identify that some of the SID allocations in a SID file are still unstable may help in avoiding these SIDs turning up in production.

Grüße, Carsten

---

From: Alexander Pelov <[email-masked]>
Date: Mon, 28 Mar 2022 23:03:48 +0200

Hi again,

Thanks for the clarifications!

On Mon, Mar 28, 2022 at 4:34 PM Carsten Bormann <[email-masked]> wrote:

> modules that have SID allocations).
>
> Indeed.

It seems to me that the "canonical SID" property is nice to have (but not a
must have, because it cannot be really guaranteed).

The SID files winding up somewhere are the real pain here -> which is
actually simpler to solve if you consider that the definitive allocation is
an atomic operation.

Say, you have RFC123456.yang, with allocation of SIDs described in
RFC123456.SID.
Now, you have draft-RFC123456bis.yang -> until this one becomes an RFC, the
corresponding SID file can be considered in its entirety as provisional
allocation / temporary / draft / unstable.

In that sense, the stable/unstable (or other term for the same meaning)
works on the file level and is in direct connection to the YANG file.

> The main observation is that these SID files may get wings and may turn up
> in places where they were not meant to be.  Being able to identify that
> some of the SID allocations in a SID file are still unstable may help in
> avoiding these SIDs turning up in production.
>

During development, to know which SIDs you can regenerate freely and which
you CANNOT because they have been allocated in a "parent" module, you only
need the full history of the YANG / SID allocation. This you need in any
case to do the check, and the per-range stable/unstable option can be seen
as a way to ease the life of a tool developer, but cannot be used to
actually be trusted.

The example is the following:
The developers of draft-RFC123456bis.yang have access to both
RFC123456.yang and RFC123456.SID. When you allocate SIDs for
draft-RFC123456bis.yang, it is a very straightforward operation to make the
diff between what's already in RFC123456.SID and what needs to be allocated
and in what manner. As a matter of fact, "pyang sid" already does this!

Does that make sense? Can we simply have a per-SID-file "draft" property?

Cheers,
Alexander

---

From: Michael Richardson <[email-masked]>
Date: Mon, 28 Mar 2022 17:20:02 -0400

Alexander Pelov <[email-masked]> wrote:
    > that follows touches upon several possibilities.  If you revise a
    > module, you provide a new YANG file (with a different name/revision),
    > and if you need to change the semantics of some item..  well, you need
    > a new SID.

Yes.  That's what it looks like from the outside.

But, inside the sausage factory of the IETF, during the process we create internet-drafts.
When those internet drafts are revisions to published RFCs, they will contain
a mix of SID allocations which are published (and thus immutable), and some
which are new, and which are mutable during the WG deliberations.

We need to keep track of which is which so that we can:
  1) renumber/revise the mutable allocations
  2) make sure never to change the immutable ones

    > cannot be solved as currently it stands?

It's all solvable as is, but people have to pay more attention than may be
realistic outside of our design team.
The changes we discussed would just make the tooling better able to help the
user.  We could add it later if we can't get consensus on this.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 28 Mar 2022 17:22:20 -0400

> The main observation is that these SID files may get wings and may turn
    > up in places where they were not meant to be.  Being able to identify
    > that some of the SID allocations in a SID file are still unstable may
    > help in avoiding these SIDs turning up in production.

That's something I hadn't thought about.
It's entirely a good thing that in development SID files can be identified.
So +10.

---

From: Andy Bierman <[email-masked]>
Date: Mon, 28 Mar 2022 14:54:27 -0700

On Mon, Mar 28, 2022 at 2:04 PM Alexander Pelov <[email-masked]> wrote:

> It seems to me that the "canonical SID" property is nice to have (but not
> a must have, because it cannot be really guaranteed).
>
> Now, you have draft-RFC123456bis.yang -> until this one becomes an RFC,
> the corresponding SID file can be considered in its entirety as provisional
Agreed

>> up in places where they were not meant to be.  Being able to identify that

Almost.

It would be set if the SID file also records the "last-sid-file" revision
somehow.
The pyang tool requires this for the --sid-update-file parameter.

A WG does not need to renumber RFC123456bis every time a new bis draft is
released.
The RFC123456 SIDs MUST be preserved in each bis release, but none of the
new "draft" SIDs need to be preserved.

If the SID file recorded the previous version somehow then ANY SID
generation
tool can create the correct file, but without it, not even pyang can do it.

E.g.

RFC123456 published             2021-01-01             draft=false
RFC123456bis published        2022-01-01  (-00)    draft=true
RFC123456bis published        2022-02-01  (-01)    draft=true
RFC123456bis published        2022-03-01  (-02)    draft=true

The bis -00 MUST use RFC123456 as the --sid-update-file.
But -01 and -02 bis releases can choose to be a delta from any previous I-D
or
start over with a delta from the RFC version.

If a per-SID flag is used, the ability to go back to a previous SID file
revision as the base is lost.
Once the SID is marked stable in a new SID file, the tool does not know if
it was marked
stable in the RFC or later, so it can never change it back to unstable.

The ability for any tool to verify that a proper delta was generated is
needed and currently
does not exist. The [last-sid-file, current-YANG-file] are needed for this
purpose.

Andy

---

From: Alexander Pelov <[email-masked]>
Date: Tue, 29 Mar 2022 22:20:25 +0200

Hi Andy, Michael, all,

Thanks for the examples !

Once again, to see if we are on the same page, the problem seems to come
from needing two SID files:
RFC123456 and the last work version of RFC123456bis-02 (because of you have
both you can infer the immutable from RFC123456 and the provisionnaly
allocated for the RFC123456bis-01).

If this is the case, isn't it simply solved by saving a RFC123456bis-01.sid
and then using pyang --sid-update-file RFC123456bis-01.sid to generate the
RFC123456bis-02.sid

And if you want to have RFC123456bis-03.sid renumber from the 01 version
you simply do it based on RFC123456bis-01.sid.

It's just that I get the feeling we are trying to do version control here
and if this is the case I would really prefer we stick to git and some best
practices.

Cheers,
Alexander

Le lun. 28 mars 2022, 23:54, Andy Bierman <[email-masked]> a écrit :

>>> > From what I understand, the problem we are trying to solve is (and I
>>> am paraphrasing to see if we are on the same page) to try to limit and have
>> During development, to know which SIDs you can regenerate freely and
>> which you CANNOT because they have been allocated in a "parent" module, you
>> only need the full history of the YANG / SID allocation. This you need in
>> any case to do the check, and the per-range stable/unstable option can be
>> seen as a way to ease the life of a tool developer, but cannot be used to
>> actually be trusted.
>>
> But -01 and -02 bis releases can choose to be a delta from any previous
> I-D or

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 29 Mar 2022 22:43:24 +0200

On 2022-03-29, at 22:20, Alexander Pelov <[email-masked]> wrote:
> 
> If this is the case, isn't it simply solved by saving a RFC123456bis-01.sid and then using pyang --sid-update-file RFC123456bis-01.sid to generate the RFC123456bis-02.sid

Yes, and that needs the stable/unstable information per SID.

Grüße, Carsten

---

From: Andy Bierman <[email-masked]>
Date: Tue, 29 Mar 2022 14:02:56 -0700

On Tue, Mar 29, 2022 at 1:20 PM Alexander Pelov <[email-masked]> wrote:

> RFC123456 and the last work version of RFC123456bis-02 (because of you
> have both you can infer the immutable from RFC123456 and the provisionnaly
> If this is the case, isn't it simply solved by saving a
> RFC123456bis-01.sid and then using pyang --sid-update-file
> RFC123456bis-01.sid to generate the RFC123456bis-02.sid
>

Yes.

I want some operational verification of the SID file to be possible
A more robust solution can be achieved if the SID file stored the following
information:

  - parent-stable:  the revision-date of the stable ancestor for this SID
file.
     (present only if there is a stable ancestor e.g. RFC123456.sid)

  - parent-unstable: the revision-date for the parent of this SID file.
     (present only if this is draft and the parent is not the same as
parent-stable)

  - draft: TRUE if this is a work-in-progress; FALSE if this is a published
and stable SID file

It should be possible for one SID tool to check the correctness of a SID
file.
Currently there is not even a datestamp or a checksum or any of the metadata
(passed to pyang as parameters) saved in the SID file.

> and if this is the case I would really prefer we stick to git and some best

There is an assumption that SID files are like YANG modules, but they are
not.
A SID file expands the YANG module and therefore relies on all the imports.
If a YANG module uses groupings (about 90% of them?) then it is quite
possible
for the SID file to change even if the YANG module it is for did not change.

I am much more concerned about operational robustness than the ability
for a WG writing a bis-draft to save a few extra bytes in the CBOR encoding.

Andy

>>> It seems to me that the "canonical SID" property is nice to have (but
>>> not a must have, because it cannot be really guaranteed).
>>>
>> Once the SID is marked stable in a new SID file, the tool does not know
>> if it was marked
>> does not exist. The [last-sid-file, current-YANG-file] are needed for
>> this purpose.
>>
>>
>>
>>
>>> Cheers,
>>> Alexander
>>>
>>
>>
>> Andy
>>
>>
>>>
>>>
>>>>
>>>> Grüße, Carsten
>>>>

---

From: Alexander Pelov <[email-masked]>
Date: Tue, 29 Mar 2022 23:35:27 +0200

Hi Andy,

>From what I understood until now, the stable/unstable tag is helpful only
to the authors that work on draft-123456bis-02 so that they can generate
new SIDs keeping the previously temporary allocated for draft-123456bis-01.

Once the document becomes and RFC the whole stable/unstable difference
becomes useless. Also, it is meaningless to anyone other than the authors
of the YANG file, between versions.

Do you expect these to be used at any other moment?

(I do agree adding metadata such as dare created, "draft", or other file
level may be useful)

Cheers,
Alexander

Le mar. 29 mars 2022, 23:03, Andy Bierman <[email-masked]> a écrit :

> A more robust solution can be achieved if the SID file stored the
> following information:
>
>   - draft: TRUE if this is a work-in-progress; FALSE if this is a
> published and stable SID file
>
>>>>> The main observation is that these SID files may get wings and may
>>>>> turn up in places where they were not meant to be.  Being able to identify
>>>>> that some of the SID allocations in a SID file are still unstable may help
>>>>> in avoiding these SIDs turning up in production.
>>>>>
>>>>
>>>>
>>> It would be set if the SID file also records the "last-sid-file"
>>> revision somehow.
>>> A WG does not need to renumber RFC123456bis every time a new bis draft
>>> is released.
>>> The RFC123456 SIDs MUST be preserved in each bis release, but none of
>>> the new "draft" SIDs need to be preserved.
>>>

---

From: Andy Bierman <[email-masked]>
Date: Tue, 29 Mar 2022 15:22:20 -0700

> new SIDs keeping the previously temporary allocated for draft-123456bis-01.

The info used for --sid-update-file is needed in the SID file for a tool
to read that SID file and decide if it is correct.

> of the YANG file, between versions.
The stable=true flag is useful for developers and operators to  know that
the SID file is stable.

IMO, the WG should regenerate the I-D SID file from the RFC each time, or
at least
done at the end before RFC publication.

The most important factor for delta-SID performance is the difference
between
a SID for a container or list and its children.  The best numbering is
achieved
by sorting the path identifiers once, NOT multiple times.

Could be useful for debugging.
There is plenty of info in the SID file used only to generate an updated
SID file.

> (I do agree adding metadata such as dare created, "draft", or other file

The current pyang design is limited (without a sid-file-version in the
filename).
The date in the filename is tied to the YANG module revision, not the SID
file.
If imported groupings change, a new SID file using the same revision date
is needed to pick up these imported changes.  The 'parent' is a SID file,
not a YANG
file, so it needs the identifier [module-name, module-revision,
sid-file-version].

Cheers,
Andy

>>>>>> > From what I understand, the problem we are trying to solve is (and
>>>>>> I am paraphrasing to see if we are on the same page) to try to limit and
>>>>>> have one SID per YANG name. Something like a 'canonical SID' (which would
>>>>>> make for a bijective correspondence "YANG name" <-> "canonical SID", for
>>>>>> YANG modules that have SID allocations).
>>>>>>
>>>>>> Indeed.
>>>>>
>>>>>
>>>>> Now, you have draft-RFC123456bis.yang -> until this one becomes an
>>>>> RFC, the corresponding SID file can be considered in its entirety as
>>>>> provisional allocation / temporary / draft / unstable.
>>>>>
>>>>> In that sense, the stable/unstable (or other term for the same
>>>>> meaning) works on the file level and is in direct connection to the YANG
>>>>> file.
>>>>>
>>>>>
>>>>>
>>>> Agreed
>>>>
>>>>
>>>>
>>>> If a per-SID flag is used, the ability to go back to a previous SID
>>>> file revision as the base is lost.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 30 Mar 2022 12:44:20 -0400

> new SIDs keeping the previously temporary allocated for

Correct.

    > of the YANG file, between versions.

Correct.

If someone feeds the SID file into a code generator, then we want the result
to be clearly marked as unstable... do not ship to customers, etc.

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