Re: [core] progressing ietf-core-yang-cbor and ietf-core-sid

[Ivaylo Petrov <[e-mail]>]

Hello,

Thank you very much for the discussion. It brings a lot of interesting
perspectives on the problem how to make sure SIDs are most usable for
people and make it difficult to make mistakes.

I believe there are a few important points that need to be agreed upon
before we accept how to fix anything. Here are my assumptions:
1. we don't want to waste too much SIDs while creating SID modules
2. we want SIDs to be as stable as possible
3. we don't want to unpleasantly surprise people with the way SIDs
need to be used as compared to only using YANG modules.

My question is what happens currently with an implementation that uses
a version of YANG module that has been present inside a draft, but
have differences with the version in the final RFC that is published
from the draft? I could not see multiple revisions of YANG modules
associated with the same RFC in the IANA page. I also don't see update
of the revision information for a module that has been changed in
different versions of a draft. Therefore my impression is that people
that start using YANG modules that are not fully finished either are
ready to update their implementation later when the modules are
finalized or they control both ends and can handle the fact that they
use YANG module version that could be incompatible with other
implementations. Coming from assumption 3 then is my question - do we
need to make anything different? I don't think the SID file needs to
be published as available on IANA's web page before the publication of
an RFC. Doing so would open a huge potential for problems a number of
which have already been mentioned in this thread. For me this does not
contradict assumption 2 as people should be aware of the possible
stability issues before publication of the RFC and that should the
expected behaviour from their point of view considering it is already
the case with YANG modules. Then going back to early allocation, what
is done during early allocation is simply assigning ranges, not
registration of the SIDs themselves. Those ranges are used to generate
the .sid files in the draft and people can use the values from the
draft at their own risk if they so decide, but they should be aware
that those values can change. I suspect that I am missing something
here, but if I am not, then SID files do not need to include dead
SIDs. There might be SIDs that are present in one published version of
a module and not in the next one, but we can not delete them as the
older revision of the YANG module might still be in use by some
implementations. Note that this is not a waste in this case, so we are
not violating assumption 1.

I am not sure I see how a version of the .sid file will help here. My
concern is that it will make finding the SID file that one wants more
difficult - one needs to know both the yang version and a sid file
version + the sid in order to be able to understand it. Currently one
can find the sid file that covers a range and from inside it figure
out which revision of which module is used and that is
straight-forward. Having multiple .sid files also means that
verification of SIDs will be that much more difficult as it will be
spread possibly over a number of files.

Andy, you have an interesting point about what will happen if there is
a problem with our .sid file generation tool. Could you give examples
of the types of errors that would cause significant issues? My general
answer is - if we have published the .sid file, some SIDs might be
lost. This is better than the alternative of modifying the meaning of
a SID leading to possible ambiguity. Fixing such errors might require
updating some .sid files and doing firmware update, which would not be
a pleasant thing. However for me one vital part of the role of the
Experts is to check that the output of the tool makes sense and to
guard against big allocation issues. A possibly interesting thing to
do would be to create another version of the SID allocation tool. That
way having two independent implementations would greatly reduce the
risk of issues if they produce the same output. Another safeguard here
is the fact that SID ranges are independent, therefore if the tool
messes up something, it should not be possible to do so in a way that
affects other ranges. I currently don't see how a problem - big, but
subtle, in the generation software can create a situation that would
make me want to change the SID architecture.

Best regards,
Ivaylo

On Thu, Jan 16, 2020 at 1:54 AM Andy Bierman <[e-mail]> wrote:
>
>
>
> On Wed, Jan 15, 2020 at 4:17 PM Michael Richardson <[e-mail]> wrote:
>>
>>
>> Carsten Bormann <[e-mail]> wrote:
>>     >> Yes, if we evolved the design during WG processing, then we could well
>>     >> have dead SIDs.  We could, at WGLC or IESG approval, edit the SID file
>>     >> and mark them as useable again.  (If there were no running code, we
>>     >> could reset the SID file entirely at that point) The SID file
>>     >> maintains the memory of the dead values for only as long as we want it
>>     >> to.
>>
>>     > This paragraph is exactly reflecting my nightmares about this.  We
>>     > could do a lot of things, if we wanted to.  What are our unambiguous,
>>     > not-to-be-missed instructions that make this fool-proof?
>>
>> We will screw up, but the fools are often brilliant in their ability to get
>> around fool-proofing :-)
>>
>>     > I would expect that we get rid of dead SIDs about as often as we revoke
>>     > TCP port number assignments, i.e., essentially never.  But this
>>     > requires getting around the cognitive dissonance of just having
>>     > “wasted” a SID value (*): With very strongly worded instructions, I’d
>>     > assume.
>>
>>     > Grüße, Carsten
>>
>>     > (*) (Note that there are way more SIDs than there are TCP ports.)
>>
>> The time when we are most likely to create dead SID values is during the
>> development of running code between WG Adoption and WGLC.
>> I think it is reasonable thing to decide, with some communication among
>> implementers to reset/re-allocate.
>>
>> Revisions to the YANG which deprecate leafs and therefore create deprecated
>> SID values are different: deployed code might still be using them.
>> (If we are revising published YANG, then certainly can never reset the SID process!)
>
>
>
> IMO there should be no concept of conformance status for a SID file.
> It would be unwise to recover SIDs of obsolete YANG definitions.
> It is safer to just burn the wasted range and keep range assignments small.
>
> Do SID files need to be identified by a 3-tuple {module-name, module-revision, sid-file-revision }
>
>    foo@2020-01-15.1  -> { foo, 2020-01-15, 1 }
>
> If the sid-file-revision is missing then it defaults to '1'.
> Hopefully SID files will be correct and updated revisions will not be needed.
>
> I think a robust CORECONF client needs to know the 3-tuples of all the SID files used by a server.
> It is not enough just to know module@revision-date.  We want to be able to
> rely on centralized (common) SID files and not have to retrieve each one
> from each server (because they doctored the real SID file or replaced it with their own).
>
>
> Andy
>
>
>
>>
>> --
>> Michael Richardson <[e-mail]>, Sandelman Software Works
>>  -= IPv6 IoT consulting =-
>> _______________________________________________
>> core mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/core
>
> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core