Warren Kumari <war...@kumari.net> writes: > Thank you all. > > Having heard no objections, we will go with Rob's proposed text. > > Lada / Petr, please fold in this change, and then poke me LOUDLY and I'll > hit the "Go!" button...
Done in -05. Thanks, Lada > > Thanks all, > W > > On Wed, Jun 16, 2021 at 7:00 AM Benno Overeinder <be...@nlnetlabs.nl> wrote: > >> Thank you Rob. >> >> I am the document shepherd, but reply with no hats. >> >> I understand the concern, and I am fine with the proposed change. > > >> Best, >> >> -- Benno >> >> >> On 10/06/2021 18:05, Rob Wilton (rwilton) wrote: >> > Hi DNS Ops, >> > >> > Warren, Lada and I discussed this further today. Warren and I think >> that mapping IANA deprecated to YANG deprecated is the right behaviour >> here, and Lada is fine with either outcome. >> > >> > The main concern of mapping from IANA 'deprecated' to YANG 'status >> obsolete' is that it would force a hard transition if any DNS classes or >> RR's ever needed to be deprecated. I.e., when a server picks up a new >> version of the generated YANG types file it would be obliged to immediately >> remove support for the 'status obsolete' definition with no grace period >> and no option to continue using it (RFC 7950 describes this is a SHOULD >> NOT, but this constraint is effectively stronger in the versioning related >> drafts currently progressing in the NETMOD WG). >> > >> > So, the following change is proposed: >> > >> > OLD: >> > "status": Include only if a class or type registration has been >> > deprecated or obsoleted. In both cases, use the value "obsolete" >> > as the argument of the "status" statement. >> > >> > NEW: >> > "status": Include only if a class or type registration >> has been >> > deprecated or obsoleted. IANA "deprecated" maps to YANG >> > status "deprecated", and IANA "obsolete" maps to YANG status >> > "obsolete". >> > >> > Does anyone in the WG strongly object to this change? If so, please let >> us know by Wed's 16th. >> > >> > Regards, >> > Rob >> > >> > >> >> -----Original Message----- >> >> From: Ladislav Lhotka <ladislav.lho...@nic.cz> >> >> Sent: 10 June 2021 12:37 >> >> To: Rob Wilton (rwilton) <rwil...@cisco.com>; The IESG <i...@ietf.org>; >> >> Warren Kumari <war...@kumari.net>; michelle.cot...@iana.org >> >> Cc: draft-ietf-dnsop-iana-class-type-y...@ietf.org; >> dnsop-cha...@ietf.org; >> >> dnsop@ietf.org; be...@nlnetlabs.nl >> >> Subject: RE: Robert Wilton's Discuss on >> draft-ietf-dnsop-iana-class-type-yang- >> >> 03: (with DISCUSS and COMMENT) >> >> >> >> "Rob Wilton (rwilton)" <rwil...@cisco.com> writes: >> >> >> >>> Hi Lada, >> >>> >> >>> I've also copied Michelle on - since I think that it would be helpful >> for IANA >> >> to at least be aware of this discussion. >> >>> >> >>> Sorry for being slow to get back to you. I've expanded on my discuss >> >> comment below, but it may be helpful for you, Warren, I, possibly >> Michelle, >> >> to have a quick chat to see if we can resolve it. >> >>> >> >>> >> >>> >> >>>> -----Original Message----- >> >>>> From: Ladislav Lhotka <ladislav.lho...@nic.cz> >> >>>> Sent: 03 June 2021 14:17 >> >>>> To: Rob Wilton (rwilton) <rwil...@cisco.com>; The IESG <i...@ietf.org >> > >> >>>> Cc: draft-ietf-dnsop-iana-class-type-y...@ietf.org; >> dnsop-cha...@ietf.org; >> >>>> dnsop@ietf.org; be...@nlnetlabs.nl >> >>>> Subject: Re: Robert Wilton's Discuss on >> draft-ietf-dnsop-iana-class-type- >> >> yang- >> >>>> 03: (with DISCUSS and COMMENT) >> >>>> >> >>>> Hi Rob, >> >>>> >> >>>> On 03. 06. 21 13:16, Robert Wilton via Datatracker wrote: >> >>>> >> >>>> ... >> >>>> >> >>>>> >> ---------------------------------------------------------------------- >> >>>>> DISCUSS: >> >>>>> >> ---------------------------------------------------------------------- >> >>>>> >> >>>>> Hi, >> >>>>> >> >>>>> One issue that I think we should should discuss and resolve (sorry >> for >> >> the >> >>>> late >> >>>>> discuss ballot): >> >>>>> >> >>>>> In section 4, it states: >> >>>>> >> >>>>> "status": Include only if a class or type registration has been >> >>>>> deprecated or obsoleted. In both cases, use the value >> "obsolete" >> >>>>> as the argument of the "status" statement. >> >>>>> >> >>>>> I know that we have had some previous discussion on this on Netmod, >> >> but, >> >>>> if >> >>>>> draft-ietf-netmod-yang-module-versioning-02 gets standardized then it >> >> will >> >>>>> effectively evolve YANG's "status deprecated" into "must implement or >> >>>>> explicitly deviate" and YANG's "status obsolete" into "must not >> >> implement". >> >>>> It >> >>>>> wasn't clear to me that marking one of these fields as being >> deprecated >> >> in >> >>>> an >> >>>>> IANA registry would mean that existing implementations must stop >> >> using it >> >>>> if >> >>>>> they migrate to a new version of the generated YANG module. Hence, I >> >>>> think >> >>>>> that at this stage, it may be safer to map IANA "deprecated" into >> YANG's >> >>>>> "status deprecated"? >> >>>>> >> >>>> >> >>>> Yes, this was discussed repeatedly in NETMOD and DNSOP WGs. I think >> >> we >> >>>> currently have to use RFC 7950 for the status definitions, and so in >> YANG >> >>>> >> >>>> o "deprecated" indicates an obsolete definition, but it permits >> >>>> new/continued implementation in order to foster >> interoperability >> >>>> with older/existing implementations. >> >>>> >> >>>> This is incompatible with the meaning of "deprecated" in IANA >> >>>> registries, which is per RFC 8126: "use is not recommended". >> >>> >> >>> I don't think that there is a perfect answer here, and I think that >> for the >> >>> moment we are looking for the least bad option. >> >>> >> >>> The YANG and IANA definitions of deprecated are obviously different, >> >>> but it isn't clear to me how different they actual are from those >> definitions. >> >>> >> >>> E.g., in neither case do they indicate why they are going away (e.g., >> >>> because they are no longer used, or there is a better way, or there is >> a >> >>> security issue). >> >>> >> >>> I would also argue that "use is not recommended" applies to the YANG >> >>> "deprecated" as well, and generally matches what I understand what >> >> deprecated means. >> >> >> >> One strong case that was mentioned in DNSOP discussions was a >> >> compromised crypto algorithm. It will be marked as deprecated in IANA >> >> registries, and it is highly undesirable to "foster interoperability" >> by using it. >> >> >> >> In fact, this I-D started with mapping IANA deprecated/obsolete to the >> same >> >> term in YANG (which is what RFC 7224 does), but we were forced to >> change it >> >> due to the above objection. >> >> >> >>> >> >>> But ultimately there are two choices here: >> >>> >> >>> (1) Map both IANA deprecated and obsolete to YANG obsolete as your >> >> draft >> >>> proposes. If the text in draft-ietf-netmod-yang-module-versioning-02 >> gets >> >>> standardized then this means that there will be no way to indicate a >> DNS >> >>> class type that shouldn't be used anymore and is going away. Either >> it is >> >>> "current" and can/should be implemented, or it is "obsolete" and it >> cannot >> >> be >> >>> used once the server pulls in the new revision of the types YANG >> file. I.e., >> >>> there isn't even a mechanism to deviate it to indicate that it is still >> >> supported, >> >>> there is no possible transition window. >> >> >> >> Maybe the RFC can then be updated to reflect this evolution? In our >> view, >> >> mapping both terms to "obsolete" in YANG is currently the safest option. >> >> >> >>> >> >>> (2) Map IANA deprecated -> YANG deprecated. IANA obsolete -> YANG >> >>> obsolete. With vanilla RFC 7950, the server may or may not >> >>> implement the deprecated value, and it can use a deviation to be >> >>> explicit. If draft-ietf-netmod-yang-module-versioning-02 gets >> >>> standardized: The server is expected to implement it or use a >> >> >> >> You probably mean "The server is expected NOT to implement it or ...", >> >> right? >> >> >> >>> deviation. I.e., there is still a mechanism to allow a server to >> >>> implement if they need to, but equally they can also choose not to >> >>> implement it. >> >>> >> >>> I'm still of the opinion that (2) is the least bad option out of the >> two above. >> >> >> >> Our YANG module probably doesn't have anything as critical as crypto >> >> algorithms, so it might work. I am a bit worried about the reaction of >> DNSOP >> >> WG though: it will open another round of discussion, and some people >> might >> >> fiercely oppose this change. This seemingly simple I-D was started >> already >> >> almost 3 years ago. :-/ >> >> >> >>> >> >>> A third possibility, a variant of (2), would be to map IANA deprecated >> to >> >> YANG >> >>> deprecated, but also update the type description to indicate that "Per >> the >> >>> IANA [XXX] definition of 'deprecated', use is not recommended. New >> >>> implementation should not use it; existing implementations should phase >> >>> out support for it." >> >> >> >> This would be possible, too, but my concern about further delays still >> >> applies, so I would prefer to avoid any changes. >> >> >> >> Pragmatically, I don't think that a DNS CLASS or RR TYPE will ever >> become >> >> deprecated (obsolete is OK), so it might be a non-issue anyway. >> >> >> >> Cheers, Lada >> >> >> >>> >> >>> >> >>> >> >>>> >> >>>> I agree that this discrepancy should be solved in a new version of >> YANG, >> >>>> possibly along the lines of >> draft-ietf-netmod-yang-module-versioning-02, >> >>>> but we can't wait for that with this draft. >> >>> >> >>> Agreed. I'm not suggesting that we wait. >> >>> >> >>> Regards, >> >>> Rob >> >>> >> >>> >> >>>> >> >>>>> >> >>>>> >> ---------------------------------------------------------------------- >> >>>>> COMMENT: >> >>>>> >> ---------------------------------------------------------------------- >> >>>>> >> >>>>> Hi, >> >>>>> >> >>>>> Thanks for this document. I think that documenting this fields in >> YANG >> >> is a >> >>>> good thing. >> >>>>> >> >>>>> One minor nit: >> >>>>> >> >>>>> In an couple of places you have used 'analogically' but perhaps meant >> >>>> 'analogously' instead? >> >>>> >> >>>> Yes, I will change all occurrences. >> >>>> >> >>>> Thanks, Lada >> >>>> >> >>>>> >> >>>>> Thanks, >> >>>>> Rob >> >>>>> >> >>>>> >> >>>>> >> >>>> >> >>>> -- >> >>>> Ladislav Lhotka >> >>>> Head, CZ.NIC Labs >> >>>> PGP Key ID: 0xB8F92B08A9F76C67 >> >> >> >> -- >> >> Ladislav Lhotka >> >> Head, CZ.NIC Labs >> >> PGP Key ID: 0xB8F92B08A9F76C67 >> > >> > _______________________________________________ >> > DNSOP mailing list >> > DNSOP@ietf.org >> > https://www.ietf.org/mailman/listinfo/dnsop >> > >> >> > > -- > The computing scientist’s main challenge is not to get confused by the > complexities of his own making. > -- E. W. Dijkstra -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
