Re: [core] [Ext] RE: Robert Wilton's Discuss on draft-ietf-core-sid-21: (with DISCUSS and COMMENT)

[Amanda Baber <[e-mail]>]

Sorry, two more questions: would the experts need to check the SID files after IANA extracts them? If so, would it make more sense to just have the experts supply the files to IANA? That was the plan a few years ago, I believe.

Amanda

On 10/19/23, 10:47 AM, "Amanda Baber" <[e-mail]> wrote:

    Hi Rob,

    If the tool can be used by anyone, with no knowledge of SID/YANG required, IANA can extract them just as we extract YANG files. Otherwise, we'd ask that experts provide them.

    To avoid discrepancies, we'd expect to extract the SID (if desired) and YANG files at the same time. The practice for YANG files has been to extract them immediately after RFC publication.

    Do we need to talk about generating SIDs for existing YANG files in the IANA registry at this time, or is that a separate discussion? 

    Thanks,
    Amanda

    On 10/19/23, 9:15 AM, "iesg on behalf of Rob Wilton (rwilton)" <[e-mail] on behalf of rwilton=[e-mail]> wrote:

        [Explicitly cc'ing Francesca and Sabrina to keep me honest and make sure I've not forgotten anything]

        Hi Carsten,

        We did spend 10 min discussing this on the telechat today.

        In summary, but I think that Subrina still needs to check, it sounds like IANA should be able to run some tooling (which we will need to provide) to generate an updated final SID file during the RFC publication cycle, i.e., this would be done at the same time the YANG module is being extracted.  Once generated/updated, the SID file should be checked with the authors and a designated expert on SID allocations for IETF YANG modules.

        In terms of how SID files are managed during the IETF process, what I suggested today (and didn't get any verbal push back from other ADs) was:

        1) Authors should have the option of not including/maintaining a SID file, if the protocol isn't obviously going to be needed/used by constrained devices.  Instead, IANA will create (or update the existing) SID file during the RFC publication process.
        2) Authors may include a SID file during YANG module development.  The authors can decide whether they prefer to keep the SID file in the internet draft, or to just store a stable reference to it.  In either case, the authors have responsibility for updating the SID file as the ID and YANG modules evolve and IANA only gets involved during the RFC publication phase.

        Does a process like the above sound reasonable to the authors/WG, and if, would you be able to suggest text?

        Regards,
        Rob


        > -----Original Message-----
        > From: Rob Wilton (rwilton)
        > Sent: Thursday, October 19, 2023 2:48 PM
        > To: Carsten Bormann <[e-mail]>
        > Cc: The IESG <[e-mail]>; [e-mail]; [e-mail];
        > core <[e-mail]>; Jaime Jiménez <[e-mail]>
        > Subject: RE: Robert Wilton's Discuss on draft-ietf-core-sid-21: (with DISCUSS and
        > COMMENT)
        > 
        > Hi Carsten,
        > 
        > For context, this doc is on the telechat next Thursday, but I'm hoping that we
        > can have some level of discussion on this today to try and help this move
        > forward expediently.
        > 
        > Please see inline ...
        > 
        > > -----Original Message-----
        > > From: Carsten Bormann <[e-mail]>
        > > Sent: Thursday, October 19, 2023 2:30 PM
        > > To: Rob Wilton (rwilton) <[e-mail]>
        > > Cc: The IESG <[e-mail]>; [e-mail]; core-
        > [e-mail];
        > > core <[e-mail]>; Jaime Jiménez <[e-mail]>
        > > Subject: Re: Robert Wilton's Discuss on draft-ietf-core-sid-21: (with DISCUSS
        > and
        > > COMMENT)
        > >
        > > Hi Rob,
        > >
        > > let me quickly comment on your DISCUSS content; a full response will come
        > > later.
        > >
        > > > On 19. Oct 2023, at 13:15, Robert Wilton via Datatracker
        > <[e-mail]>
        > > wrote:
        > > >
        > > > Robert Wilton has entered the following ballot position for
        > > > draft-ietf-core-sid-21: Discuss
        > > >
        > > > The document, along with other ballot positions, can be found here:
        > > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-core-sid/__;!!PtGJab4!6XkG71BBFuldXYNsZtfKWF7qQAWzES5klPGzICnjC2VCWcikCaZkDLAItunjugdqyLxEBECAxj5Ywtz_zLCcWocVorPVh0YY44A-jSo$ [datatracker[.]ietf[.]org]
        > > >
        > > >
        > > >
        > > > ----------------------------------------------------------------------
        > > > DISCUSS:
        > > > ----------------------------------------------------------------------
        > > >
        > > > Hi authors,
        > > >
        > > > Apologies for putting yet another discuss on this document - I promise that I
        > > > support it and want to see it published - but there are a couple of process
        > > > related aspects for creating/managing SID files in drafts that I want to
        > ensure
        > > > that the IESG is at very least aware of and happy with.
        > > >
        > > > (1) p 23, sec 6.4.3.  Publication of the ".sid" file
        > > >
        > > >   For a YANG module approved for publication as an RFC, a ".sid" file
        > > >   SHOULD be included in the Internet-Draft as a source code block.
        > > >
        > > > I'm wondering if this is really the best approach.
        > >
        > > I personally think that in the long run, in the course of embracing formal
        > > methods more, we want to have “attachments” to Internet-Drafts.  But we
        > don’t
        > > have (or need) this now:
        > [Rob Wilton (rwilton)]
        > Agreed, to both points.  I think that we need to find a way to stop
        > publishing/managing code within RFCs.
        > 
        > 
        > >
        > > > I.e., I think to guarantee
        > > > that the SID file is correct at the point of pulication (e.g., if names of YANG
        > > > data nodes are changed using IESG review or later) will probably require the
        > > > RFC-Editor (or IANA) to run some tooling to regenerate it and ensure that it
        > is
        > > > correct.
        > >
        > > Indeed.  We do have (and daily use) tooling to extract the content of
        > > <sourcecode elements from XML files.
        > > These typically run through a CI pipeline to do automated checks (well, some
        > of
        > > the pipelines are still manually triggered, but the checks are automatic).
        > > The extracted content can also be fed into other tools.
        > [Rob Wilton (rwilton)]
        > 
        > Yes, I think that this is what we need to get to or assume that we will have to.
        > I.e., some tooling that can generate this, and an agreement from (probably
        > IANA, or possibly the RFC editor) that they will be happy to run this tooling at
        > the appropriate stage in the pipeline and evoke the authors + designated
        > experts to check the output.
        > 
        > 
        > >
        > > > Hence for YANG modules that are not being directly used in
        > > > constrained environments then would it be better to ask IANA (if they are
        > > > willing, and if the tooling is easy) to generate it during AUTH-48?  Note, this
        > > > discussion will presumably require IANA's input.
        > >
        > > We can ask IANA to do the routine part.  I still think a designated expert
        > should
        > > look at the result.
        > [Rob Wilton (rwilton)]
        > Also agree.
        > 
        > 
        > >
        > > > (2) p 27, sec 6.5.3.  Recursive Allocation of YANG SID Range at Document
        > > > Adoption
        > > >
        > > >   *  If the document is a published RFC, then the allocation of SIDs
        > > >      for its referenced YANG modules is permanent.  The Expert Reviewer
        > > >      provides the generated ".sid" file to IANA for registration.  This
        > > >      process may be time-consuming during a bootstrap period (there are
        > > >      over 100 YANG modules to date, none of which have SID
        > > >      allocations), but should quiet down once needed entries are
        > > >      allocated.
        > > >
        > > > Would it not be easier just to go through all the published RFCs containing
        > > > YANG modules and allocate SID files for them?
        > >
        > > Yes!
        > > (The DE can do that and check the results, or IANA can do it after agreeing
        > with
        > > the DE on some tooling parameters.)
        > >
        > > Unfortunately, we first have to declare victory on fixing PYANG (or generating
        > > another tool) do to this generation in a reliable way.
        > > We are so close...
        > > On the list for IETF 118 hackathon…
        > [Rob Wilton (rwilton)]
        > 
        > Okay, Per Anderrson ([e-mail]) was planning on doing some
        > different pyang related hacking at this hackathon, so perhaps see if he is
        > interested in helping.  If you want you can also cc me on your plans and then I
        > may be able to help on Saturday, if I can find the time.  Joe Clarke might be
        > someone else to also reach out to.
        > 
        > For this document, the answer may be to just cut the text regarding the
        > bootstrap period, and just document want happens if a SID file doesn't already
        > exist.  The bootstrapping process, if it happens, probably doesn't need to
        > documented in an RFC.
        > 
        > Regards,
        > Rob
        > 
        > 
        > >
        > > Grüße, Carsten