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.
>
>
YANG module development has proven to be a messy process.
It is the exception, not the rule, that a module stays stable from draft-00
to RFC.


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



The implementor is on their own, just like now for YANG,
and just like MIB modules for 30+ years.  Vendors know that
implementing a work-in-progress is dangerous.  WGs should know
that publishing an RFC with zero implementation experience for the
technology in the draft is going to produce an inferior result.

Only the RFC versions of MIB or YANG modules is ever recorded by IANA.
The work-in-progress versions are extracted from drafts.
The YangModels github repo stores these modules.




> 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.
>
>
Relying on the YANG to SID algorithm to generate the SID file
assumes that every tool will generate the SID file correctly and
every tool is perfect and never has a new bug or a regression bug.
It is more realistic that SID interoperability will be achieved using
actual SID files
downloaded from a common repo.  A SID file version allows for
corrections to the YANG to SID translation.  The YANG module revision
is not changing.  It is not at fault.  Multiple SID files for the same YANG
revision
should be distinguishable.


> 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.
>
>
It would be naive to think that pyang cannot possibly have a bug in it,
or that YANG complexity in real modules is low enough to simply inspect
the file output like your constrained voucher example. How does the output
look
for ietf-bgp.yang (or any of the recent routing modules).

When a YANG module has a bug in it, a new revision with a new revision date
is
published to fix it. IMO it would be wise to provide a mechanism to fix a
bug in
a SID file.

Multiple independent implementations are always good for finding bugs in
the tools.
There are so many ways to change a YANG module, I suspect that the code
that updates a SID file (as opposed to resetting the SID translation each
time)
has the most opportunity for bugs.


Best regards,
> Ivaylo
>


Andy


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