Carsten Bormann <[email protected]> wrote:
    >> If someone creates an implementation of this document using a
    >> SID-aware, YANG-driven code generator, then they had better use the
    >> values in the document, not the the values derived through the
    >> yang-sid process.  (Or they'd better check!)

    > How would that be different if yang-cbor/sid were already published?

In that case, we would submit our sid file, IANA would process it, and we'd
get SID definitions, and we could be sure that it would be stable.
(Or rather, that's at least, making it stable is not our problem)

    >> We expected that draft-ietf-core-yang-cbor and draft-ietf-core-sid to
    >> have been published already, and maybe at that point, since we are
    >> stuck with a normative reference to them, we would be able to see that
    >> IANA isn't going to renumber of our keys on us, and we could remove
    >> this language sometime at or before AUTH48... but…

    > I would expect specifications to include a SID file together with the
    > YANG spec.

Would you?  I supposed, but we haven't done that as yet.
I can easily add our SID file.

I don't know.  It's a question that I've asked multiple times, and the
answers have been very hand-wavey.   Does ietf-core-sid say we are going to
do that?  I don't see that anywhere.

Section 3 says:

   Registration of the ".sid" file associated to a YANG module is
   optional but recommended to promote interoperability between devices
   and to avoid duplicate allocation of SIDs to a single YANG module.
   Different registries might have different requirements for the
   registration and publication of the ".sid" files.  For a diagram of
   one of the possibilities, please refer to the activity diagram on
   Figure 1 in Appendix C.

The diagram doesn't explicitly say that I include the sid file.
It was stated IANA would be creating and maintaining SID files for anything
previously published.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email protected]  http://www.sandelman.ca/        |   ruby on rails    [





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




Attachment: signature.asc
Description: PGP signature

_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima

Reply via email to