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

[Andy Bierman <[e-mail]>]

On Thu, Jan 16, 2020 at 2:28 AM Ivaylo Petrov <[e-mail]> wrote:

> 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.
>
>

These goals are not going to be easy to achieve.
The biggest challenge is maintaining existing SIDs from draft to draft.

There is a significant amount of metadata needed to generate a SID file,
starting with all the previous YANG revisions or SID files, and when/if
the SID files have been reset vs. updated with preserved numbers.

SID assignments depend on statement order.
YANG identifiers do not depend on statement order at all.
Most definitions are actually conceptual, and only the
conceptual expansion of submodules, groupings, augments, and uses
can be numbered. This leads to all sorts of opportunities for bugs.
Some changes are difficult to detect (like 2 augments that get combined)
which have zero impact on YANG identifiers but a huge impact on SIDs.

My biggest concern about SID generation is that it depends on all
the revisions of all the imported modules.  The SID file for module X
is dependent on the groupings expanded from module Y and Z
(and Z imports A, which imports B, etc.)

If any of these imported modules change at all, then the SID file for the
target module
can change, even though that module did not change at all. The date that
the SID file is generated can change the outcome (!)  How does the SID tool
make sure the exact same set of imported modules is used?  How are these
dependencies documented in the SID file so generation of version N = 1 can
detect
object changes correctly?


Andy




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
>