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... 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
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
