On Thu, 10 Oct 2019, Ladislav Lhotka wrote:
They should not actually be reading the RFC but get the latest revision of the
module from this page:
https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml
You are asking for text to go into an RFC, which you then say they
(implementors) should not read. Clearly then the text should not go
into the RFC.
I do admit that this may not be clear to everybody. What we are really missing
is a well-known and authoritative repository of YANG modules, at least those
produced by IETF and managed by IANA.
Right. This is why I was hoping the IESG would have made some progress
on this, as they said they were working on "this".
Would it help to reclassify the RFC as historic as soon as IANA takes over the
responsibility for such a module?
I doubt it. Since developers that need to implement some RFC number have
no idea about the historic status. They tend to not even know the
difference between experimental, standard, informational.
I think this claim is both an unquantifed appeal to authority and unfair. The
technical debt of doing this happens 10+ years from now, when people are
implementing obsolete record types because a modern DNS Yang RFC references
these record types, and might be missing new record types because the
modern DNS Yang RFC did not yet have this new record type listed.
I really don't understand. What DNS Yang RFC are you referring to? I am not
aware of any.
Your draft.
We are open to all reasonable suggestions.
My suggestion was a link the proper IANA registries, which _are_ updated
by other RFCs to place things into obsolete/deprecated and receive new
entries based on other new RFCs.
As you said the implementors need to go to the IANA/YANG module place, a
link to that would be more useful than including a current snapshot of
the IANA registries.
Paul
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
