[DNSOP] Clarifying referrals (#35)

Dear colleagues, In github tracker issue #35 (https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis/issues/35), we have an item about the way Referral is defined in RFC 7719. The issue mostly comes from the (as usual incisive) observations of Tony Finch. I think he's right. I think a change

Re: [DNSOP] [Ext] Re: draft-wkumari-dnsop-internal and DNAME

On Nov 12, 2017, at 10:51, Kim Davies wrote: We haven't studied what would be involved, but I feel confident in predicting the whole exercise would be non-trivial. It seems to me that you could implement this using lawyers as easily as you could using developers; it is after all arguably a sta

Re: [DNSOP] Agenda for IETF100

Please keep us posted on the logistics On Sunday, November 12, 2017, Melinda Shore wrote: > On 11/10/17 8:16 PM, Stephane Bortzmeyer wrote: > > Any news on that? The monday session collides with DIN which is really > > unfortunate for me because they talk a lot about name resolution > > (Namecoi

Re: [DNSOP] [Ext] Re: draft-wkumari-dnsop-internal and DNAME

Quoting Stephane Bortzmeyer on Friday November 10, 2017: > > > I'll note that from a technical/mechanical perspective, ICANN's and > > Verisign's root zone management systems already know how to deal > > with delegations. A DNAME in the root would require an unknown level > > of development by bot

Re: [DNSOP] Agenda for IETF100

On 11/10/17 8:16 PM, Stephane Bortzmeyer wrote: > Any news on that? The monday session collides with DIN which is really > unfortunate for me because they talk a lot about name resolution > (Namecoin, Ethereum Name Service). I may face a hard choice. We've had to cancel the dinrg session on Monday

[DNSOP] About draft-ietf-dnsop-extended-error

[About -00] Excellent idea, I strongly support the project. I intend to use it to register 451 for DNS censorship , following RFC 7725. (I'm serious.) > This document discusses extended *errors*, but