[DNSOP] draft-fujiwara-dnsop-avoid-fragmentation-01
Dear dnsop WG, Please review draft-fujiwara-dnsop-avoid-fragmentation-01. https://tools.ietf.org/html/draft-fujiwara-dnsop-avoid-fragmentation-01 Main differences are: - New Co-author - Refer RFC 8085 UDP Usage Guidelines - SHOULD send DNS responses with IP_DONTFRAG / IPV6_DONTFRAG [RFC3542] - Use actual path MTU information, or the default maximum DNS/UDP payload size - Added text about how to retrieve path MTU value in appendix getsockopt() IP_MTU and IPV6_MTU (Linux only) - default maximum DNS/UDP payload size >= 1220, and <= 1400 - Request to zone operator: Use smaller contents (number of RRs, DNSSEC key) -- Kazunori Fujiwara, JPRS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoptions: draft-lhotka-dnsop-iana-class-type-yang
On Tue, 2019-10-08 at 09:47 -0400, Bob Harold wrote: > > On Tue, Oct 8, 2019 at 9:23 AM Normen Kowalewski wrote: > > Dear Paul, Benno, > > > > thanks for your replies. > > > > > On 7. Oct 2019, at 19:31, Paul Wouters wrote: > > > > > > On Mon, 7 Oct 2019, Benno Overeinder wrote: > > > > > >> Questions to WG: > > >> > > >> 1) iana-class-type-yang document to OPSAWG? > > > > > > I would assume most people here will the same about the document, > > > wherever it is discussed ? So this option seems odd. > > > > > > > We should IMHO be as close to the DNS experts as possible, to me that feels > > rather like DNSOP than like OPSAWG. > > A "YANG doctors” expert review is part of the publication process, so this > > will happen anyway. It’s also worth nothing that one author is one of these > > experts himself. > > > > > > >> 2) follow-up work on YANG data models for DNS servers in DNSOP? > > > > > > Speaking for myself, as long as we are not populating RFCs with > > > obsoleted DNS data or just create RFC with copies of IANA registries, > > > I'm fine with helping on a document. But not if it is a blind copy > > > and paste from IANA (whether at DNSOP or OPSAWG) > > > > > > Paul > > > > In order for the IANA registry to be re-used by other YANG modules, a YANG > > modelled version of the registry is needed. There is precedence for doing > > this for other registries. e.g. The IANA ifType registry has a corresponding > > YANG module in RFC8343. A number of other registries also have corresponding > > YANG modules published or in draft (iana-identity-mib, bfd-parameters, smi- > > numbers). > > > > Updating and maintaining the contents of the IANA registry as a whole is an > > orthogonal question to creating a YANG representation of an existing > > registry and should be handled as a separate task. > > > > Finally, one reason why we would like to see this draft adopted is because > > we’d like to use it within a real world DNS server implementation. > > > > BR, > > > > Normen > > We don't want to have to update the RFC every time the registry is updated. > Could the RFC just describe exactly how to to convert the registry to YANG? > Then it won't need updates. Only the initial version of the YANG module will be published as an RFC, and IANA will then handle all future updates on their own. This is explained in the I-D itself (last paragraph of the Introduction) and has already been discussed in this mailing list. The IANA Considerations sections then gives details about converting new registry entries into the corresponding YANG types. Several years of experience with the interface type registry (RFC 7224) shows that this process works quite smoothly. Lada > > -- > Bob Harold > -- 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 Adoptions: draft-lhotka-dnsop-iana-class-type-yang
Errmmm, sincere apologies for that typo. I did think it is worth *noting* that one author is one of these experts himself, quite the opposite of *nothing*. BR, Normen > On 8. Oct 2019, at 15:23, Normen Kowalewski wrote: > > It’s also worth nothing that one author is one of these experts himself. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoptions: draft-lhotka-dnsop-iana-class-type-yang
On Tue, Oct 8, 2019 at 9:23 AM Normen Kowalewski wrote: > Dear Paul, Benno, > > thanks for your replies. > > > On 7. Oct 2019, at 19:31, Paul Wouters wrote: > > > > On Mon, 7 Oct 2019, Benno Overeinder wrote: > > > >> Questions to WG: > >> > >> 1) iana-class-type-yang document to OPSAWG? > > > > I would assume most people here will the same about the document, > > wherever it is discussed ? So this option seems odd. > > > > We should IMHO be as close to the DNS experts as possible, to me that > feels rather like DNSOP than like OPSAWG. > A "YANG doctors” expert review is part of the publication process, so this > will happen anyway. It’s also worth nothing that one author is one of these > experts himself. > > > >> 2) follow-up work on YANG data models for DNS servers in DNSOP? > > > > Speaking for myself, as long as we are not populating RFCs with > > obsoleted DNS data or just create RFC with copies of IANA registries, > > I'm fine with helping on a document. But not if it is a blind copy > > and paste from IANA (whether at DNSOP or OPSAWG) > > > > Paul > > In order for the IANA registry to be re-used by other YANG modules, a YANG > modelled version of the registry is needed. There is precedence for doing > this for other registries. e.g. The IANA ifType registry has a > corresponding YANG module in RFC8343. A number of other registries also > have corresponding YANG modules published or in draft (iana-identity-mib, > bfd-parameters, smi-numbers). > > Updating and maintaining the contents of the IANA registry as a whole is > an orthogonal question to creating a YANG representation of an existing > registry and should be handled as a separate task. > > Finally, one reason why we would like to see this draft adopted is because > we’d like to use it within a real world DNS server implementation.. > > BR, > > Normen > We don't want to have to update the RFC every time the registry is updated. Could the RFC just describe exactly how to to convert the registry to YANG? Then it won't need updates. -- Bob Harold ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoptions: draft-lhotka-dnsop-iana-class-type-yang
Dear Paul, Benno, thanks for your replies. > On 7. Oct 2019, at 19:31, Paul Wouters wrote: > > On Mon, 7 Oct 2019, Benno Overeinder wrote: > >> Questions to WG: >> >> 1) iana-class-type-yang document to OPSAWG? > > I would assume most people here will the same about the document, > wherever it is discussed ? So this option seems odd. > We should IMHO be as close to the DNS experts as possible, to me that feels rather like DNSOP than like OPSAWG. A "YANG doctors” expert review is part of the publication process, so this will happen anyway. It’s also worth nothing that one author is one of these experts himself. >> 2) follow-up work on YANG data models for DNS servers in DNSOP? > > Speaking for myself, as long as we are not populating RFCs with > obsoleted DNS data or just create RFC with copies of IANA registries, > I'm fine with helping on a document. But not if it is a blind copy > and paste from IANA (whether at DNSOP or OPSAWG) > > Paul In order for the IANA registry to be re-used by other YANG modules, a YANG modelled version of the registry is needed. There is precedence for doing this for other registries. e.g. The IANA ifType registry has a corresponding YANG module in RFC8343. A number of other registries also have corresponding YANG modules published or in draft (iana-identity-mib, bfd-parameters, smi-numbers). Updating and maintaining the contents of the IANA registry as a whole is an orthogonal question to creating a YANG representation of an existing registry and should be handled as a separate task. Finally, one reason why we would like to see this draft adopted is because we’d like to use it within a real world DNS server implementation. BR, Normen ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoptions: draft-lhotka-dnsop-iana-class-type-yang
Paul Wouters writes: > On Mon, 7 Oct 2019, Benno Overeinder wrote: > >> Questions to WG: >> >> 1) iana-class-type-yang document to OPSAWG? > > I would assume most people here will the same about the document, > wherever it is discussed ? So this option seems odd. > >> 2) follow-up work on YANG data models for DNS servers in DNSOP? > > Speaking for myself, as long as we are not populating RFCs with > obsoleted DNS data or just create RFC with copies of IANA registries, > I'm fine with helping on a document. But not if it is a blind copy > and paste from IANA (whether at DNSOP or OPSAWG) I still have difficulties to understand this objection. IANA registries (presumably) serve some purpose, and the only way for using them in YANG data models currently is to translate them to YANG. If something is felt to be broken in IANA registries, then it should be corrected there in the first place. Making a YANG module as an improved version of an IANA registry sounds like a bad idea to me, also because it would be difficult to coordinate future updates. Or do you have another suggestion? Lada > > Paul -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
