On Thu, Jun 17, 2021 at 4:38 AM Rob Wilton (rwilton) <[email protected]> wrote:
> Discuss cleared. Thanks all for accommodating. > > ... and I just approved publication. Thanks all. W > 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 > -- The computing scientist’s main challenge is not to get confused by the complexities of his own making. -- E. W. Dijkstra
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
