tldr - suggest cutting sections 4 and 5 completely and advancing with what’s
left!
> On 28 Jul 2021, at 9:25 am, Shumon Huque wrote:
>
>
> For sibling glue, part of our rationale was indeed to cover the cases where
> it is required for resolution (and not just an optimization). Those configs
I had it said to me, that "lies" about the ns.bar.example are not a
problem because if they can tell you a DNSSEC verified truth about the
primary request, you don't care who told you.
That can only be truly not a concern, if the primary is DNSSEC
verified. So, for the non-DNSSEC, it feels like a
It appears that Paul Wouters said:
>On Tue, 27 Jul 2021, John R Levine wrote:
>
>> Well, OK. How about this?
>>
>> foo.example NS ns.bar.example
>> ns.foo.example 2001:0DB8::000b::1
>>
>> bar.example NS ns.abc.example
>> ns.bar.example 2001:0DB8::000b::2
On Wed, 28 Jul 2021, Ralf Weber wrote:
However requiring authorities to put unnecessary data in the additional section
(the sibbling glue) is not something I support.
First, as Mark said, sibling glue is sometimes needed.
Second, the server will most likely not know whether or not the glue
is
On Tue, 27 Jul 2021, John R Levine wrote:
Well, OK. How about this?
foo.example NS ns.bar.example
ns.foo.example 2001:0DB8::000b::1
bar.example NS ns.abc.example
ns.bar.example 2001:0DB8::000b::2
abc.example NS ns.def.example
take the following delegations in the parent zone example.
foo.example NS ns.bar.example
ns.foo.example 2001:0DB8::000b::1
bar.example NS ns.foo.example
ns.bar.example 2001:0DB8::000b::2
Well, OK. How about this?
foo.example N
John,
take the following delegations in the parent zone example.
foo.example NS ns.bar.example
ns.foo.example 2001:0DB8::000b::1
bar.example NS ns.foo.example
ns.bar.example 2001:0DB8::000b::2
If you don’t return sibling glue a query for
Just to make sure we're talking about the same thing, the definition of
sibling glue is glue from another zone delegated from the same parent.
That's not what the example in 4.1 of the draft shows. It has foo.test
depending on ns1.bar.test, so the server adds the A record for
ns1.bar.test.
It
On Tue, Jul 27, 2021 at 4:35 PM Shumon Huque wrote:
> Folks,
>
> While we have the attention of DNSOP folks this week, I'd like to ask for
> review of this draft (I meant to send it earlier in time for f2f discussion
> on Tuesday, but better late than never).
>
>
> https://datatracker.ietf.org/do
On Tue, Jul 27, 2021 at 8:32 PM John R Levine wrote:
> >> We say that authoritative servers MUST return all the glue, which is
> true
> >> for real glue, but not true for sibling glue (unless the sibling is in
> >> a loop which is not something to encourage.) Let's not confuse people,
> please.
We say that authoritative servers MUST return all the glue, which is true
for real glue, but not true for sibling glue (unless the sibling is in
a loop which is not something to encourage.) Let's not confuse people, please.
Just to make sure we're talking about the same thing, the definition of
Folks,
While we have the attention of DNSOP folks this week, I'd like to ask for
review of this draft (I meant to send it earlier in time for f2f discussion
on Tuesday, but better late than never).
https://datatracker.ietf.org/doc/html/draft-huque-dnsop-blacklies-ent-01
Excerpt:
On Tue, Jul 27, 2021 at 11:43 AM Puneet Sood wrote:
> A readability suggestion
> * Move the description of all types of glue upfront before getting
> into recommendations.
> - real glue
> - sibling glue
> - loops with sibling
> - orphaned glue
> * Describe the recommendations for including glue.
On Tue, Jul 27, 2021 at 4:16 PM John Levine wrote:
> It appears that Puneet Sood said:
> >Couple of comments and a readability suggestion
> >
> >* +1 to Geoff Huston's request to provide justification for why
> >sibling glue is desirable in a response. Also would prefer to not make
> >it mandat
Moin!
On 27 Jul 2021, at 23:19, Mark Andrews wrote:
>> On 28 Jul 2021, at 06:15, John Levine wrote:
>> We say that authoritative servers MUST return all the glue, which is true
>> for real glue, but not true for sibling glue (unless the sibling is in
>> a loop which is not something to encourage
> On 28 Jul 2021, at 06:15, John Levine wrote:
>
> It appears that Puneet Sood said:
>> Couple of comments and a readability suggestion
>>
>> * +1 to Geoff Huston's request to provide justification for why
>> sibling glue is desirable in a response. Also would prefer to not make
>> it manda
On Tue, Jul 27, 2021 at 1:29 PM Joe Abley wrote:
> On 27 Jul 2021, at 16:15, John Levine wrote:
>
> >> * Section 5: Promoted or orphan glue
> >> The considerations for handling orphan glue will be different for a
> >> TLD vs a lower level zone within a domain. I would think that orphan
> >> glue
On 27 Jul 2021, at 16:15, John Levine wrote:
>> * Section 5: Promoted or orphan glue
>> The considerations for handling orphan glue will be different for a
>> TLD vs a lower level zone within a domain. I would think that orphan
>> glue in a TLD context should go away when a zone is deleted/expire
It appears that Puneet Sood said:
>Couple of comments and a readability suggestion
>
>* +1 to Geoff Huston's request to provide justification for why
>sibling glue is desirable in a response. Also would prefer to not make
>it mandatory in a referral response. ...
I would prefer we completely rem
Dear Authors and WG,
This document made me grumpy.
Pointing out nits and similar in documents is one of the few times
that I get to feel superior, and demonstrate my outstanding missing
comma detection abilities... I feel that I've been robbed of this
opportunity in this document -- I only found
Hi all,
As mentioned during the DNSOP WG session yesterday, the Applied
Networking Research Workshop (ANRW 2021) also takes place this week.
On Wednesday 28 July there will be a session on DNS Privacy, see the
programme https://irtf.org/anrw/2021/program.html and scroll down to the
session:
Dear colleagues,
The internet-draft draft-ietf-dnsop-private-use-tld, adopted by the WG late
last year, includes text that would create entries in the IANA Special-Use
Domain Names registry for certain ISO 3166-1 two-letter codes that have been
labeled by the appropriate ISO agency as “user-as
Donald Eastlake writes:
> Looks like initial query from IAB to ISO is
> https://datatracker.ietf.org/liaison/1720/
There has not been a response to that statement at this time. The
chairs have received a note from the IAB liaison to ISO/TC46 that
explains the situation to date. I expect them t
23 matches
Mail list logo
