Discuss cleared. Thanks all for accommodating. Regards, Rob
> -----Original Message----- > From: Ladislav Lhotka <[email protected]> > Sent: 17 June 2021 07:24 > To: Warren Kumari <[email protected]>; Benno Overeinder > <[email protected]> > Cc: Rob Wilton (rwilton) <[email protected]>; [email protected]; dnsop- > [email protected]; [email protected]; The IESG > <[email protected]>; Paul Wouters <[email protected]>; [email protected] > Subject: Re: [DNSOP] Mapping IANA deprecated to YANG status deprecated > [was RE: Robert Wilton's Discuss on draft-ietf-dnsop-iana-class-type-yang-03: > (with DISCUSS and COMMENT)] > > Warren Kumari <[email protected]> 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 <[email protected]> > 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 <[email protected]> > >> >> Sent: 10 June 2021 12:37 > >> >> To: Rob Wilton (rwilton) <[email protected]>; The IESG > <[email protected]>; > >> >> Warren Kumari <[email protected]>; [email protected] > >> >> Cc: [email protected]; > >> [email protected]; > >> >> [email protected]; [email protected] > >> >> Subject: RE: Robert Wilton's Discuss on > >> draft-ietf-dnsop-iana-class-type-yang- > >> >> 03: (with DISCUSS and COMMENT) > >> >> > >> >> "Rob Wilton (rwilton)" <[email protected]> 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 <[email protected]> > >> >>>> Sent: 03 June 2021 14:17 > >> >>>> To: Rob Wilton (rwilton) <[email protected]>; The IESG > <[email protected] > >> > > >> >>>> Cc: [email protected]; > >> [email protected]; > >> >>>> [email protected]; [email protected] > >> >>>> 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 > >> > [email protected] > >> > 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 [email protected] https://www.ietf.org/mailman/listinfo/dnsop
