Re: [DNSOP] Call for Adoption: draft-andrews-dnsop-glue-is-not-optional
In article you write: >Not convinced the situation should be this black and white - eg perhaps >partial glue would be enough >not to require TC=1 or behaviour for resolvers could be a little more advanced >to try with partial >before going to TCP. > >If my request seem stupid, the draft needs clarification for stupid people >like me :) The draft, which I hope we adopt, could use clarification if that seems like a good idea. Imagine you have foo.example with two nameservers, ns1.foo.example and ns2.foo.example. Client looks up something.foo.example, server returns a referral with two NS records but only has room for one A record for ns1. The Internet is having a bad day and ns1 is unreachable while ns2 is fine. Since there's no TC=1 the client has no idea that requerying would return the A record for ns2, so it wrongly assumes ns2 has no A record and the domain is kaput. It can't separately requery for ns2, since who would it ask? It's fine to return a partial result with TC=1, that's always been the case. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-andrews-dnsop-glue-is-not-optional
On Monday, 18 May 2020 17:49:04 UTC Tim Wicinski wrote: > ... > > This starts a Call for Adoption for draft-andrews-dnsop-glue-is-not-optional > > The draft is available here: > https://datatracker.ietf.org/doc/draft-andrews-dnsop-glue-is-not-optional/ > > Please review this draft to see if you think it is suitable for adoption > by DNSOP, and comments to the list, clearly stating your view. +1. long overdue after false starts by me and others. > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends: 1 June 2020 i'm willing to review. -- Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-pusateri-dnsop-update-timeout
All This call for adoption ended last week and the chairs were very much on the fence over adopting this document. We went to our AD to help decide this and after some poking, this was what we received: I too would like to have seen more support, but I do think that the selection and "strength" of the support messages makes this OK; I tend to side with Warren's view on this, so we're going to adopt this document for now, and we'll see how the working group works on it. tim On Tue, Apr 28, 2020 at 5:17 PM Paul Wouters wrote: > On Tue, 28 Apr 2020, Wes Hardaker wrote: > > >> We are looking for *explicit* support for adoption. > > > > I support it, though I'd feel more comfortable hearing from operators > > that want to deploy it. I suspect there are many, but that's just > suspicion. > > I think you really mean IPAM vendors? Like is this something Infoblox, > bind, Bluecat and BT and Microsoft would want to incorporate into their > enterprise products? > > Paul > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] A quick update on ICANN SSAC and .internal...
Hi all, I'd like to provide an update -- back in July 2017 I published https://tools.ietf.org/html/draft-wkumari-dnsop-internal-00 . This was presented at IETF100 (slides: https://datatracker.ietf.org/meeting/100/materials/slides-100-dnsop-sessa-draft-wkumari-dnsop-internal-00), and my reading of the feedback was that I should take this to ICANN (Jim, Joe, Andrew, Olaf, Ed Chung) -- feedback starts at: https://youtu.be/DjbBQDMGf9s?t=7921 I followed the DNSOP direction, and ICANN SSAC is currently working on an advisory on this topic (which SSAC hopes to have published soon). Due to confidentiality expectations[0], I have refrained from / limited my discussions on this, but the fact that SSAC is working on this is in the slidedeck from ICANN 67 - https://static.ptbl.co/static/attachments/237788/1583951065.pdf?1583951065 . W [0]:I checked with the SSAC Admin committee before sending this to make sure it was OK. -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-andrews-dnsop-glue-is-not-optional
In favour of adoption but like to see text from both AUTH and recursive behaviour. Not convinced the situation should be this black and white - eg perhaps partial glue would be enough not to require TC=1 or behaviour for resolvers could be a little more advanced to try with partial before going to TCP. If my request seem stupid, the draft needs clarification for stupid people like me :) Paul Sent from my iPhone > On May 18, 2020, at 14:30, Brian Dickson > wrote: > > > > >> On Mon, May 18, 2020 at 10:50 AM Tim Wicinski wrote: >> >> All, >> >> As we stated in the meeting and in our chairs actions, we're going to run >> regular call for adoptions over next few months. >> We are looking for *explicit* support for adoption. >> >> >> This starts a Call for Adoption for draft-andrews-dnsop-glue-is-not-optional >> >> The draft is available here: >> https://datatracker.ietf.org/doc/draft-andrews-dnsop-glue-is-not-optional/ >> >> Please review this draft to see if you think it is suitable for adoption >> by DNSOP, and comments to the list, clearly stating your view. >> >> Please also indicate if you are willing to contribute text, review, etc. >> > > I support adoption by the WG, believe it is suitable, and am willing to > review and contribute text. > > Brian > > >> This call for adoption ends: 1 June 2020 >> >> 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
Re: [DNSOP] Call for Adoption: draft-andrews-dnsop-glue-is-not-optional
On Mon, May 18, 2020 at 10:50 AM Tim Wicinski wrote: > > All, > > As we stated in the meeting and in our chairs actions, we're going to run > regular call for adoptions over next few months. > We are looking for *explicit* support for adoption. > > > This starts a Call for Adoption for > draft-andrews-dnsop-glue-is-not-optional > > The draft is available here: > https://datatracker.ietf.org/doc/draft-andrews-dnsop-glue-is-not-optional/ > > Please review this draft to see if you think it is suitable for adoption > by DNSOP, and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > I support adoption by the WG, believe it is suitable, and am willing to review and contribute text. Brian > This call for adoption ends: 1 June 2020 > > 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] The DNSOP WG has placed draft-andrews-dnsop-glue-is-not-optional in state "Call For Adoption By WG Issued"
The DNSOP WG has placed draft-andrews-dnsop-glue-is-not-optional in state Call For Adoption By WG Issued (entered by Tim Wicinski) The document is available at https://datatracker.ietf.org/doc/draft-andrews-dnsop-glue-is-not-optional/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Call for Adoption: draft-andrews-dnsop-glue-is-not-optional
All, As we stated in the meeting and in our chairs actions, we're going to run regular call for adoptions over next few months. We are looking for *explicit* support for adoption. This starts a Call for Adoption for draft-andrews-dnsop-glue-is-not-optional The draft is available here: https://datatracker.ietf.org/doc/draft-andrews-dnsop-glue-is-not-optional/ Please review this draft to see if you think it is suitable for adoption by DNSOP, and 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: 1 June 2020 Thanks, tim wicinski DNSOP co-chair ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements
All Thanks for all the feedback on this call for adoption. DNSOP will be adopting this document to work on thanks tim On Tue, May 12, 2020 at 1:19 AM Loganaden Velvindron wrote: > On Mon, May 4, 2020 at 11:10 PM Tim Wicinski wrote: > > > > > > > > All, > > > > As we stated in the meeting and in our chairs actions, we're going to run > > regular call for adoptions over next few months. > > We are looking for *explicit* support for adoption. > > > > > > This starts a Call for Adoption for > draft-mglt-dnsop-dnssec-validator-requirements > > > > The draft is available here: > https://datatracker.ietf.org/doc/draft-mglt-dnsop-dnssec-validator-requirements/ > > > I support adoption of the draft and i'm willing to review it. > > > > Please review this draft to see if you think it is suitable for adoption > > by DNSOP, and 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: 18 May 2020 > > > > 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
Re: [DNSOP] I-D Action: draft-ietf-dnsop-iana-class-type-yang-01.txt
Dear Lada, et al. Thanks for the update, I support your proposal. BR, Normen > On 15. May 2020, at 11:31, Ladislav Lhotka wrote: > > Hi, > > this revision fixes only formal and cosmetic issues. > > The authors believe the document is now ready for WGLC. The question > whether or not to remove appendix A (with the XSLT stylesheet) before > publication can be addressed in later stages, perhaps after te second > IANA review. > > Thanks, Lada > > On 15. 05. 20 11:10, 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 : YANG Types for DNS Classes and Resource Record Types >>Authors : Ladislav Lhotka >> Petr Spacek >> Filename: draft-ietf-dnsop-iana-class-type-yang-01.txt >> Pages : 13 >> Date: 2020-05-15 >> >> Abstract: >> This document introduces the YANG module "iana-dns-class-rr-type" >> that contains derived types reflecting two IANA registries: DNS >> CLASSes and Resource Record (RR) TYPEs. These YANG types are >> intended as a minimum basis for future data modeling work. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-dnsop-iana-class-type-yang/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-dnsop-iana-class-type-yang-01 >> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-iana-class-type-yang-01 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-iana-class-type-yang-01 >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> 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 >> > > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > ___ > 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
