[DNSOP] Robert Wilton's Discuss on draft-ietf-dnsop-iana-class-type-yang-03: (with DISCUSS and COMMENT)
Robert Wilton has entered the following ballot position for draft-ietf-dnsop-iana-class-type-yang-03: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-iana-class-type-yang/ -- 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"? -- 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? Thanks, Rob ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] 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 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. > > -- > 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-salgado-dnsop-rrserial
Hi Davey. Thanks for your support. About the identification for resolvers, it's out of scope for this draft, but nothing prevents the use of RRSERIAL and NSID in the resolvers. Last paragraph of RFC5001 section 2.2 says so, and in version -01 of this draft there'll be a relaxation by declaring the use of rrserial in resolvers as undefined, thanks to Shane's comments. Of course the exact behavior needs to be defined more carefully, but RRSERIAL would be a first step on that path. Hugo On 12:13 03/06, Davey Song wrote: > Hi Hugo, > > I like this draft. And I will continue to review and comment when you have > new versions. > > Generally, it is helpful to figures out who answer my queries in the > troubleshooting process. So the draft is helpful if out-of-sync occurs > between authoritative servers, such as Hidden Masters, primary server, and > secondary servers. > > Some thoughts out of the scope of this draft： I think the out-of-sync > issue is more serious which occurs between the broken cache resolver and > the authoritative servers when the cache resolver violates the TTL. Maybe > my queries are hijacked to that broken server. IMHO, there is a piece > missing to help troubleshooting which cache resolver answered my query and > which version of the zone the cached response is associated with. > > The NSID option is proposed for authoritative sever. Maybe we can propose > an NSID for cache resolver？ Any suggestions? > > Best regards, > Davey > > > On Tue, 1 Jun 2021 at 00:15, Hugo Salgado wrote: > > > Dear group. > > Thanks for the call for adoption. We the authors are already working > > on -01 with the comments made a few weeks ago. I hope to send it in > > the next days for your review/approval. > > > > Hugo > > > > On 10:26 28/05, Tim Wicinski wrote: > > > All > > > > > > We had a lot of good discussion of this draft when it first came out, and > > > the chairs want to put up a call for adoption. > > > > > > If you have already stated adoption of this draft, we will count those so > > > there is no need to repeat yourself. > > > > > > > > > This starts a Call for Adoption for draft-salgado-dnsop-rrserial > > > > > > The draft is available here: > > > https://datatracker.ietf.org/doc/draft-salgado-dnsop-rrserial/ > > > > > > Please review this draft to see if you think it is suitable for adoption > > by > > > DNSOP, and send comments to the list, clearly stating your view. > > > > > > Please also indicate if you are willing to contribute text, review, etc. > > > > > > This call for adoption ends: 22 June 2021 > > > > > > Thanks, > > > tim wicinski > > > DNSOP co-chair > > > > > ___ > > > DNSOP mailing list > > > DNSOP@ietf.org > > > https://www.ietf.org/mailman/listinfo/dnsop > > > > ___ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop signature.asc Description: PGP signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-salgado-dnsop-rrserial
> nothing prevents the use of RRSERIAL and NSID in the > resolvers. Last paragraph of RFC5001 section 2.2 says so, Yes. Thanks for pointing it out. > and in > version -01 of this draft there'll be a relaxation by declaring the > use of rrserial in resolvers as undefined > I'm looking forward to that. Davey ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] I-D Action: draft-salgado-dnsop-rrserial-01.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : The "RRSERIAL" EDNS option for the SOA serial of a RR's zone Authors : Hugo Salgado Mauricio Vergara Ereche Filename: draft-salgado-dnsop-rrserial-01.txt Pages : 6 Date: 2021-06-03 Abstract: The "RRSERIAL" EDNS option allows a DNS querier to request a DNS authoritative server to add an EDNS option in the answer of such query with the SOA serial number field of the origin zone which contains the answered Resource Record. This "RRSERIAL" data allows to debug and diagnose problems by helping to recognize the data source of an answer in an atomic single query, by associating the response with a respective zone version. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-salgado-dnsop-rrserial/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-salgado-dnsop-rrserial-01.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-salgado-dnsop-rrserial-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-salgado-dnsop-rrserial-01.txt
Dear group. Version -01 has substantive changes according to the comments in the list. The most important: - qname is used to associate the serial's zone, and thus avoid associating it to the answer, that can be empty or multiple; - its use is not prohibited in resolvers, but remains undefined; - the length of the answer is defined as 0 for questions and 4 for answers; - added SERVFAIL use in addition to NOERROR (optional); - clarified use for NODATA; - an applicability consideration is added that advises against its use in zones that do not make sense of the SOA's serial; - a security consideration is added about the risk of not carrying dnssec signatures. Regards, Hugo On 08:48 03/06, internet-dra...@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain Name System Operations WG of the IETF. > > Title : The "RRSERIAL" EDNS option for the SOA serial of a > RR's zone > Authors : Hugo Salgado > Mauricio Vergara Ereche > Filename: draft-salgado-dnsop-rrserial-01.txt > Pages : 6 > Date: 2021-06-03 > > Abstract: >The "RRSERIAL" EDNS option allows a DNS querier to request a DNS >authoritative server to add an EDNS option in the answer of such >query with the SOA serial number field of the origin zone which >contains the answered Resource Record. > >This "RRSERIAL" data allows to debug and diagnose problems by helping >to recognize the data source of an answer in an atomic single query, >by associating the response with a respective zone version. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-salgado-dnsop-rrserial/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-salgado-dnsop-rrserial-01.html > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-salgado-dnsop-rrserial-01 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > signature.asc Description: PGP signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Francesca Palombini's Discuss on draft-ietf-dnsop-iana-class-type-yang-03: (with DISCUSS and COMMENT)
Hi Francesca, thanks for your comments, please see below. Francesca Palombini via Datatracker writes: ... > -- > DISCUSS: > -- > > Thank you for the work on this document. > > (This is a "let's talk" DISCUSS, which I don't expect to hold after the > telechat) I wonder if it wouldn't make sense to add a step where IANA gets the > help of the designated experts from each respective registry when elements are > added to the DNS class or RR type registries, either by the experts creating > the substatements to be added, or at least checking and confirming those > created by IANA. If you mean YANG expertise, then I believe it is already embodied in the XSLT stylesheet. In principle, IANA can run it after each change in the registry and get the new revision of the YANG module. > > A couple of minor comments below. > > Francesca > > > -- > COMMENT: > -- > > 1. - > >models along with standard management protocols such as NETCONF and >RESTCONF can be effectively used in DNS operations, too. In fact, > > FP: Please expand NETCONF and RESTCONF on first use. I can do it for NETCONF but (to my knowledge) RESTCONF is the name of the protocol and no expansion exists. > > 2. - > > FP: I believe it would be good to add a sentence in the terminology section > stating that DNS terminology is used throughout the document, and point to RFC > 8499 and/or RFC 1035. I think informatively would be enough. OK, will do. Thanks, Lada > > > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
