Re: [DNSOP] Alias mode processing in auths for draft-ietf-dnsop-svcb-https-01

2020-08-06 Thread Mark Andrews
> On 7 Aug 2020, at 11:54, Brian Dickson wrote: > > > > On Thu, Aug 6, 2020 at 4:11 PM Mark Andrews wrote: > > > What benefit is there in changing this now? Moving the SVBC chain (graph > actually) to the answer section. I know I can follow a graph much easier in > the additional secti

Re: [DNSOP] Question regarding RFC 8499

2020-08-06 Thread Evan Hunt
On Wed, Aug 05, 2020 at 01:04:22AM +, Paul Vixie wrote: > On Tuesday, 4 August 2020 23:11:34 UTC Michael De Roover wrote: > > i borrowed the initiator/responder terminology from iSCSI, and it seems > intuitive to me. this isn't a client/server situation, because a given host > might be both a

Re: [DNSOP] Alias mode processing in auths for draft-ietf-dnsop-svcb-https-01

2020-08-06 Thread Brian Dickson
On Thu, Aug 6, 2020 at 7:13 PM Ben Schwartz wrote: > Brian, > > I think arguing about the strength of the analogies to CNAME (Answer) vs > SRV (Additional) is going to be a slow path to consensus. Apart from that > analogy, I'm not sure I understand your motivating use case. Could you > write a

Re: [DNSOP] Alias mode processing in auths for draft-ietf-dnsop-svcb-https-01

2020-08-06 Thread Brian Dickson
On Thu, Aug 6, 2020 at 4:11 PM Mark Andrews wrote: > > > What benefit is there in changing this now? Moving the SVBC chain (graph > actually) to the answer section. I know I can follow a graph much easier > in the additional section than I can in the answer section with simple > depth limited r

Re: [DNSOP] [Ext] Starting a -bis document for RFC 8109: Initializing a DNS Resolver with Priming Queries

2020-08-06 Thread George Michaelson
No. thats good and clear. Priming is not just the concept of being correct, its specifically following a mandated in-band mechanism. It is a standard, and the bis requirements are not just "arrive at the state, don't care how" they are "arrive at the state by following this specific procedure" -oth

Re: [DNSOP] [Ext] Starting a -bis document for RFC 8109: Initializing a DNS Resolver with Priming Queries

2020-08-06 Thread Paul Hoffman
On Aug 6, 2020, at 3:32 PM, George Michaelson wrote: > > If I (insanely) ran a totally manual, out of band process to > periodically canvas the space and injected the knowns into the model > of "root" for my resolver, would I be able to say I am primed? Not by the standard, no. RFC 8109 was pass

Re: [DNSOP] Alias mode processing in auths for draft-ietf-dnsop-svcb-https-01

2020-08-06 Thread Mark Andrews
> On 7 Aug 2020, at 04:03, Brian Dickson wrote: > > > > On Thu, Aug 6, 2020 at 6:22 AM Mark Andrews wrote: > > > I really don’t know how this thread got started with clear and unambiguous > instructions to add all the records to the additional section. > > The possibility of changing wha

Re: [DNSOP] [Ext] Starting a -bis document for RFC 8109: Initializing a DNS Resolver with Priming Queries

2020-08-06 Thread George Michaelson
If I (insanely) ran a totally manual, out of band process to periodically canvas the space and injected the knowns into the model of "root" for my resolver, would I be able to say I am primed? I am trying to get to the point that the "how" part is only exemplary, explanatory. The requirement is th

Re: [DNSOP] Alias mode processing in auths for draft-ietf-dnsop-svcb-https-01

2020-08-06 Thread Brian Dickson
On Thu, Aug 6, 2020 at 6:22 AM Mark Andrews wrote: > > > I really don’t know how this thread got started with clear and unambiguous > instructions to add all the records to the additional section. > The possibility of changing what is specified in the draft, was what started this thread. Your re

Re: [DNSOP] Questions on draft-ietf-dnsop-delegation-only

2020-08-06 Thread Hugo Salgado
On 16:55 30/07, Patrick Mevzek wrote: > > Only if you take the "hosts as objects" case (where any hosts to be used as > to be provision like a domain but by just providing, in some cases, some IP > addresses), which is only one of the two, the other being "hosts as > attributes (of a domain object

Re: [DNSOP] [Ext] Starting a -bis document for RFC 8109: Initializing a DNS Resolver with Priming Queries

2020-08-06 Thread Paul Hoffman
On Aug 6, 2020, at 4:08 AM, Andrew McConachie wrote: > > What does it mean for a resolver to be primed, or for a resolver to not be > primed? For example, is a resolver considered primed only if it has all root > server names and IP addresses? 50%? At least 1? Excellent questions, two that the

Re: [DNSOP] Alias mode processing in auths for draft-ietf-dnsop-svcb-https-01

2020-08-06 Thread Mark Andrews
> On 6 Aug 2020, at 20:28, Pieter Lexis wrote: > > On 8/5/20 11:13 PM, Mark Andrews wrote: >>> On 6 Aug 2020, at 04:51, Pieter Lexis wrote: >>> On 8/5/20 8:03 PM, Brian Dickson wrote: (I am not sure of the question/issue of including the SOA, or where that would go, but I'll defer to

Re: [DNSOP] Starting a -bis document for RFC 8109: Initializing a DNS Resolver with Priming Queries

2020-08-06 Thread Andrew McConachie
Dear Peter, Matt and Paul, What does it mean for a resolver to be primed, or for a resolver to not be primed? For example, is a resolver considered primed only if it has all root server names and IP addresses? 50%? At least 1? Priming is the act of finding the list of root servers from a

Re: [DNSOP] Alias mode processing in auths for draft-ietf-dnsop-svcb-https-01

2020-08-06 Thread Pieter Lexis
On 8/5/20 11:13 PM, Mark Andrews wrote: >> On 6 Aug 2020, at 04:51, Pieter Lexis wrote: >> On 8/5/20 8:03 PM, Brian Dickson wrote: >>> (I am not sure of the question/issue of including the SOA, or where that >>> would go, but I'll defer to anyone who knows or has an opinion. My gut >>> says, do wh

Re: [DNSOP] I-D Action: draft-ietf-dnsop-avoid-fragmentation-01.txt

2020-08-06 Thread fujiwara
> From: Tony Finch > I've had a look through and I have a few comments. Thanks. > Regarding smallest MTUs, I understand from Geoff Huston that it's common > for IPv6 breakage to start at 1281 bytes. Then, without path MTU discovery, IPv6 default path MTU value should equal to the IPv6 minimum l