Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-rfc8109bis

[Tim Wicinski]

All

The Working Group Last Call has completed, and thank you all for your
comments.  We consider the document to have consensus to move forward.

The authors (Paul) will upload the latest version with the changes
suggested, and we will move this forward.

thanks
tim


On Mon, Jan 8, 2024 at 8:54 PM Tim Wicinski  wrote:

> All
>
>
> This starts a Working Group Last Call for draft-ietf-dnsop-rfc8109bis
> "Initializing a DNS Resolver with Priming Queries"
>
> Current versions of the draft is available here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8109bis/
>
> The Current Intended Status of this document is: Best Current Practice
>
> Please review the draft and offer relevant comments.
>
> For WGLC, we need *positive support and constructive comments*; lack of
> objection is not enough.
> So if you think this draft should be published as an RFC, please say so.
>
> If you feel the document is *not* ready for publication, please speak out
> with your reasons.
>
>
> This starts a two week Working Group Last Call process, and ends on:
> January 22, 2024
>
> thanks
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-rfc8109bis

[Tim Wicinski]

All

This is a followup on our Working Group Last Call
for draft-ietf-dnsop-rfc8109bis is ongoing until Monday January 22, 2024.

There has been support for publication, but we are always looking for more
feedback.
The comments raised appear to have been resolved by the authors. If someone
feels we missed something, please speak up.

thanks
tim


On Mon, Jan 8, 2024 at 8:54 PM Tim Wicinski  wrote:

> All
>
>
> This starts a Working Group Last Call for draft-ietf-dnsop-rfc8109bis
> "Initializing a DNS Resolver with Priming Queries"
>
> Current versions of the draft is available here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8109bis/
>
> The Current Intended Status of this document is: Best Current Practice
>
> Please review the draft and offer relevant comments.
>
> For WGLC, we need *positive support and constructive comments*; lack of
> objection is not enough.
> So if you think this draft should be published as an RFC, please say so.
>
> If you feel the document is *not* ready for publication, please speak out
> with your reasons.
>
>
> This starts a two week Working Group Last Call process, and ends on:
> January 22, 2024
>
> thanks
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-rfc8109bis

[George Michaelson]

I support publication. The remainder feel like nits which would get
resolved in editor queue.

I discussed the priming issue with Paul H privately and I think his
response covered my concerns. Basically, if you run hyperlocal root,
it subsumes the functionality of the cache priming activity, but it
doesn't need to be explicit in this document, its a redundency, and
adding language to address this is like patching 8806 as a side
effect, which we don't need to do: in fact, it has risks. Better to
leave it out.

-G

On Tue, Jan 9, 2024 at 11:55 AM Tim Wicinski  wrote:
>
> All
>
>
> This starts a Working Group Last Call for draft-ietf-dnsop-rfc8109bis
> "Initializing a DNS Resolver with Priming Queries"
>
> Current versions of the draft is available here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8109bis/
>
> The Current Intended Status of this document is: Best Current Practice
>
> Please review the draft and offer relevant comments.
>
> For WGLC, we need *positive support and constructive comments*; lack of 
> objection is not enough.
> So if you think this draft should be published as an RFC, please say so.
>
> If you feel the document is *not* ready for publication, please speak out 
> with your reasons.
>
>
> This starts a two week Working Group Last Call process, and ends on: January 
> 22, 2024
>
> thanks
> ___
> 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] Working Group Last Call for draft-ietf-dnsop-rfc8109bis

[Roy Arends]

Let me try that again with proper indentation.

> On 9 Jan 2024, at 01:54, Tim Wicinski  wrote:
> 
> All
> 
> 
> This starts a Working Group Last Call for draft-ietf-dnsop-rfc8109bis
> "Initializing a DNS Resolver with Priming Queries"
> 
> Current versions of the draft is available here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8109bis/
> 
> The Current Intended Status of this document is: Best Current Practice
> 
> Please review the draft and offer relevant comments.
> 
> For WGLC, we need *positive support and constructive comments*; lack of 
> objection is not enough.
> So if you think this draft should be published as an RFC, please say so.
> 
> If you feel the document is *not* ready for publication, please speak out 
> with your reasons.
> 
> 
> This starts a two week Working Group Last Call process, and ends on: January 
> 22, 2024
> 
> thanks

Thanks Tim,

I support this documents. Furthermore, here are some comments:

2. Description of Priming

Priming is described in Sections 5.3.2 and 5.3.3 of [RFC1034]. The
scenario used in that description, that of a recursive server that is
also authoritative, is no longer as common.

The term “Priming” is not used in RFC1034. What is used in RFC1034 is the term 
SBELT ("safety belt” structure), defined in 5.3.2. The reference is more useful 
when the term SBELT is included.

3.3. DNSSEC with Priming Queries

The resolver MAY set the DNSSEC OK (DO) bit. At the time of
publication, there is little use to performing DNSSEC validation on
the priming query. At the time this document is pulished, all root

“published”

server names end in "root-servers.net" and the  and A RRsets for
the root server names reside in the "root-servers.net" zone. All
root servers are also authoritative for this zone, allowing priming
responses to include the appropriate root name server A and 
RRsets. But, because the "root-servers.net" zone is not signed at
the time this document is pulished, these RRsets cannot be validated.

“published"

A machine-in-the-middle attack on the priming query could direct a
resolver to a rogue root name server. Note, however, that a
validating resolver will not accept responses from rogue root servers
if they are different from the real responses because the resolver
has a trust anchor for the root and the answers from the root are
signed.  Thus, if there is a machine-in-the-middle attack on the
priming query, the results for a validating resolver could be a
denial of service, or the attacker seeing queries while returning
good answers, but not the resolver's accepting the bad responses.

This is misleading. Not all answers from the root are signed. Some content in 
the root zone is signed, delegation point NS records are not. This attack will 
be successful when rogue root-servers change delegation information to unsigned 
zones. This needs to be more precise.

If the "root-servers.net" zone is later signed, or if the root
servers are named in a different zone and that zone is signed, having
DNSSEC validation for the priming queries might be valuable. The
benefits and costs of resolvers validating the responses will depend
heavily on the naming scheme used.

Not necessarily. This attack will be successful when rogue root-servers change 
delegation information to unsigned zones (see above) and is not dependent on a 
naming scheme.

4. Priming Responses

A priming query is a normal DNS query. Thus, a root server cannot
distinguish a priming query from any other query for the root NS
RRset. Thus, the root server's response will also be a normal DNS
response.

Apologies for sounding pedantic, but what is “a normal DNS query” or a “normal 
DNS response” ? 

If there is no definition, maybe the following works for you:

The term “Priming” reflects the intent of the resolver. A root server cannot 
distinguish a priming query from any other root type NS query. The root 
server's response will therefore be an ordinary DNS response.

4.2. Completeness of the Response

At the time this document is pulished, there are 13 root servers.

“published"

There are 13 hostnames, or root server identifiers. "13 root servers" implies 
that there are 13 physical boxes.

Each has one IPv4 address and one IPv6 address. Not even counting
the NS RRset, the combined size of all the A and  RRsets exceeds
the original 512-octet payload limit from [RFC1035].

Remove “Not even counting the NS RRset, ”. The remainder of the sentence says 
enough.

In the event of a response where the Additional section omits certain
root server address information, re-issuing of the priming query does
not help with those root name servers that

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-rfc8109bis

[Roy Arends]

> On 9 Jan 2024, at 01:54, Tim Wicinski  wrote:
> 
> All
> 
> 
> This starts a Working Group Last Call for draft-ietf-dnsop-rfc8109bis
> "Initializing a DNS Resolver with Priming Queries"
> 
> Current versions of the draft is available here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8109bis/
> 
> The Current Intended Status of this document is: Best Current Practice
> 
> Please review the draft and offer relevant comments.
> 
> For WGLC, we need *positive support and constructive comments*; lack of 
> objection is not enough.
> So if you think this draft should be published as an RFC, please say so.
> 
> If you feel the document is *not* ready for publication, please speak out 
> with your reasons.
> 
> 
> This starts a two week Working Group Last Call process, and ends on: January 
> 22, 2024

Thanks Tim,

I support this documents. Furthermore, here are some comments:

2. Description of Priming

Priming is described in Sections 5.3.2 and 5.3.3 of [RFC1034]. The
scenario used in that description, that of a recursive server that is
also authoritative, is no longer as common.

The term “Priming” is not used in RFC1034. What is used in RFC1034 is the term 
SBELT ("safety belt” structure), defined in 5.3.2. The reference is more useful 
when the term SBELT is included.

3.3. DNSSEC with Priming Queries

The resolver MAY set the DNSSEC OK (DO) bit. At the time of
publication, there is little use to performing DNSSEC validation on
the priming query. At the time this document is pulished, all root

“published”

server names end in "root-servers.net" and the  and A RRsets for
the root server names reside in the "root-servers.net" zone. All
root servers are also authoritative for this zone, allowing priming
responses to include the appropriate root name server A and 
RRsets. But, because the "root-servers.net" zone is not signed at
the time this document is pulished, these RRsets cannot be validated.

“published"

A machine-in-the-middle attack on the priming query could direct a
resolver to a rogue root name server. Note, however, that a
validating resolver will not accept responses from rogue root servers
if they are different from the real responses because the resolver
has a trust anchor for the root and the answers from the root are
signed.  Thus, if there is a machine-in-the-middle attack on the
priming query, the results for a validating resolver could be a
denial of service, or the attacker seeing queries while returning
good answers, but not the resolver's accepting the bad responses.

This is misleading. Not all answers from the root are signed. Some content in 
the root zone is signed, delegation point NS records are not. This attack will 
be successful when rogue root-servers change delegation information to unsigned 
zones. This needs to be more precise.

If the "root-servers.net" zone is later signed, or if the root
servers are named in a different zone and that zone is signed, having
DNSSEC validation for the priming queries might be valuable. The
benefits and costs of resolvers validating the responses will depend
heavily on the naming scheme used.

Not necessarily. This attack will be successful when rogue root-servers change 
delegation information to unsigned zones (see above) and is not dependent on a 
naming scheme.

4. Priming Responses

A priming query is a normal DNS query. Thus, a root server cannot
distinguish a priming query from any other query for the root NS
RRset. Thus, the root server's response will also be a normal DNS
response.

Apologies for sounding pedantic, but what is “a normal DNS query” or a “normal 
DNS response” ? 

If there is no definition, maybe the following works for you:

The term “Priming” reflects the intent of the resolver. A root server cannot 
distinguish a priming query from any other root type NS query. The root 
server's response will therefore be an ordinary DNS response.
 
4.2. Completeness of the Response

At the time this document is pulished, there are 13 root servers.

“published"

There are 13 hostnames, or root server identifiers. "13 root servers" implies 
that there are 13 physical boxes.

Each has one IPv4 address and one IPv6 address. Not even counting
the NS RRset, the combined size of all the A and  RRsets exceeds
the original 512-octet payload limit from [RFC1035].

Remove “Not even counting the NS RRset, ”. The remainder of the sentence says 
enough.

In the event of a response where the Additional section omits certain
root server address information, re-issuing of the priming query does
not help with those root name servers that respond with a fixed order
of addresses in the Additional section. Instead, the recursive
resolver needs to issue direct queries for A and  RRsets for the
remaining names. At the time this document is pulished, these RRsets

“published”

would be authoritatively available from the root name servers.

5. Post-Priming Strategies

When a resolver has a zone's NS RRset in cache, and it get

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-rfc8109bis

[Paul Wouters]

On Mon, 8 Jan 2024, Tim Wicinski wrote:


Subject: [DNSOP] Working Group Last Call for draft-ietf-dnsop-rfc8109bis



From my previous comments (still unaddressed, were my comments rejected?)


there are 13 root servers.

I would really like to see this changed. We keep trying to tell people
that are not DNS insiders that the world does not depend on just 13
physical machines. This will cause that confusion to strengthen again.


It is in DNS master file format

Maybe use "zone file presentation format" instead of "master file format"


This still stands as well.

Perhaps a recommendation could be to check with ZONEMD and do an AXFR,
eg recomend implementing RFC 8806 - "Running a Root Server Local to a 
Resolver".
Comes with added bonuses on top of a signature on all the root glue.

I still think this would also still be good to mention.


 [[ This section talks about sending the DO bit, but does not actually
talk about validating the response to the priming query.  This became
important after the root KSK rollover in 2018 because some resolvers
apparently were validating and only had the old KSK, but were still
sending RFC 8145 telemetry even after failing to validate their
priming response. ]]


I said before:

Nothing much can be done here other than advising implementers to check
if the obtained DNSKEY RRset no longer contains any KSK that is
configured as part of the software, and then doing some kind of
exponential back-off to slow down the query rate?

The comment was removed but no text was added for this ? Should there be?

I also wrote before:

So now I do think the document is ready, but I think it would be nice to
mention ZONEMD and local root configurations as methods to protect
against spoofed glue.

So, nothing blocking I guess, but some "really nice to get fixed" items remain.

Paul

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Working Group Last Call for draft-ietf-dnsop-rfc8109bis

[Tim Wicinski]

All


This starts a Working Group Last Call for draft-ietf-dnsop-rfc8109bis
"Initializing a DNS Resolver with Priming Queries"

Current versions of the draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8109bis/

The Current Intended Status of this document is: Best Current Practice

Please review the draft and offer relevant comments.

For WGLC, we need *positive support and constructive comments*; lack of
objection is not enough.
So if you think this draft should be published as an RFC, please say so.

If you feel the document is *not* ready for publication, please speak out
with your reasons.


This starts a two week Working Group Last Call process, and ends on:
January 22, 2024

thanks
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Working Group Last Call for draft-ietf-dnsop-rfc8109bis (Second Time!)

[Tim Wicinski]

Hi All

We had so much fun the first timeActually this chair wishes to thank Mr
Abley and Mr Huston for catching our error so quickly, and we apologize for
any and all inconvenience.

I did go back and looked at the history AND also reread the document.
I do wish to point out that there are 4 places where "published" is spelled
"pulished".  The authors are aware of this, have made the changes in there
copy.

Current Diff

https://author-tools.ietf.org/iddiff?url1=draft-ietf-dnsop-rfc8109bis-00&url2=draft-ietf-dnsop-rfc8109bis-01&difftype=--html

We Chairs are back and catching up, and want to get things moving again.

This starts a Working Group Last Call for draft-ietf-dnsop-rfc8109bis
"Initializing a DNS Resolver with Priming Queries"

Current versions of the draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8109bis/

The Current Intended Status of this document is: Best Current Practice
and it Obsoletes 8109

Please review the draft and offer relevant comments.
If this does not seem appropriate please speak out.
If someone feels the document is *not* ready for publication, please speak
out with your reasons.

This starts a two week Working Group Last Call process, and ends on: 24
October 2023

thanks
tim, et al
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-rfc8109bis

[Tim Wicinski]

All

We chairs heard back from the authors and we're pulling this working group
last call.

I want to share some background - Paul and I talked at 117 and he said the
document is ready, and I trust Paul
implicitly in these matters.  Then when the dnsdir review came back as it
was I was like "OK".

Second, and I wrote to Peter/Nils in other emails, when I was rescanning
dnssec-bootstrapping I saw a few small nits,
I was ok, but then I realized that dnssec-bootstrapping was updating two
standard track documents.
One thing I've noticed shepherding documents is that the IESG "process" can
be painfully onerous at times, and I wanted to double check myself.

We've chatted about how the updates should be structured, and I was
using 8767,  8020 and 9077 as recent examples.
But maybe the working group can sort this out during the working group
last call.

In either case, we've pulled 8109-bis, Paul owes me a cup of tea, and we
push something *very soon*

thanks for being patient

tim

On Thu, Sep 14, 2023 at 7:49 AM Peter Thomassen  wrote:

> Hi Benno,
>
> On 9/14/23 10:14, Benno Overeinder wrote:
> > As Tim mentioned, the chairs paused WGLC or WG Call for Adoptions in
> August and are now starting the chairs action points in September.  Your
> draft-ietf-dnsop-dnssec-bootstrapping document is scheduled immediately
> after this WGLC.  We will contact you and Nils next week before sending the
> WGLC to the DNSOP mailing list.
>
> I must have missed Tim's mention regarding August; besides, the confusion
> really was more about the order of things (in the light of the order
> announce after IETF 117), and less about a break overall.
>
> Thank you very much for the clarification!
>
> > Apologies for the delays.  While balancing the work in the DNSOP WG,
> your draft was delayed during the summer months.
> Sure, no question about that at all! We certainly appreciate the work
> you're doing!
>
> Cheers,
> Peter
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-rfc8109bis

[Peter Thomassen]

Hi Benno,

On 9/14/23 10:14, Benno Overeinder wrote:

As Tim mentioned, the chairs paused WGLC or WG Call for Adoptions in August and 
are now starting the chairs action points in September.  Your 
draft-ietf-dnsop-dnssec-bootstrapping document is scheduled immediately after 
this WGLC.  We will contact you and Nils next week before sending the WGLC to 
the DNSOP mailing list.


I must have missed Tim's mention regarding August; besides, the confusion 
really was more about the order of things (in the light of the order announce 
after IETF 117), and less about a break overall.

Thank you very much for the clarification!


Apologies for the delays.  While balancing the work in the DNSOP WG, your draft 
was delayed during the summer months.

Sure, no question about that at all! We certainly appreciate the work you're 
doing!

Cheers,
Peter

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-rfc8109bis

[Benno Overeinder]

Hi Nils and Peter,

Thanks for your email regarding the process.

On 14/09/2023 09:53, Peter Thomassen wrote:
Unlike draft-ietf-dnsop-rfc8109bis which has been adopted only in June 
2023, draft-ietf-dnsop-dnssec-bootstrapping has been sitting there, with 
several implementations and without any modifications (beyond minor 
editorial), for over a year.


The authors have been interacting with the chairs a few times since the 
beginning of the year, to see if anything needs to be done for the draft 
to advance. In the process, we have been told (in May) that an 
announcement for WGLC readiness would be sent to the WG list, and later 
that WGLC would be started before IETF 118. Once IETF 118 was over, the 
draft was listed first in the Chairs Actions. Now it's been postponed 
again.


We'd like to take the opportunity of this WGLC thread to express our 
confusion about the situation. We would be grateful if the chairs could 
clarify the situation, and identify, on the list, any potential issues 
that might keep draft-ietf-dnsop-dnssec-bootstrapping from advancing so 
that they can be addressed properly (if any).


As Tim mentioned, the chairs paused WGLC or WG Call for Adoptions in 
August and are now starting the chairs action points in September.  Your 
draft-ietf-dnsop-dnssec-bootstrapping document is scheduled immediately 
after this WGLC.  We will contact you and Nils next week before sending 
the WGLC to the DNSOP mailing list.


Apologies for the delays.  While balancing the work in the DNSOP WG, 
your draft was delayed during the summer months.



Best,

-- Benno


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-rfc8109bis

[Peter Thomassen]

Missing reference:
[1]: https://mailarchive.ietf.org/arch/msg/dnsop/vHltEr8mlxsy2nyscqcCF2ZGz8U/

On 9/14/23 09:53, Peter Thomassen wrote:

Hi Tim,

On 9/13/23 23:05, Tim Wicinski wrote:

We Chairs are back and catching up, and want to get things moving again.

This starts a Working Group Last Call for draft-ietf-dnsop-rfc8109bis
"Initializing a DNS Resolver with Priming Queries"

Current versions of the draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8109bis/ 


While others have commented that this draft is not ready for WGLC, Nils and I 
would like to note that the Chairs Actions after IETF 117 [1] listed an order 
for upcoming WGLC, with this draft listed second and 
draft-ietf-dnsop-dnssec-bootstrapping listed first.

Unlike draft-ietf-dnsop-rfc8109bis which has been adopted only in June 2023, 
draft-ietf-dnsop-dnssec-bootstrapping has been sitting there, with several 
implementations and without any modifications (beyond minor editorial), for 
over a year.

The authors have been interacting with the chairs a few times since the 
beginning of the year, to see if anything needs to be done for the draft to 
advance. In the process, we have been told (in May) that an announcement for 
WGLC readiness would be sent to the WG list, and later that WGLC would be 
started before IETF 118. Once IETF 118 was over, the draft was listed first in 
the Chairs Actions. Now it's been postponed again.

We'd like to take the opportunity of this WGLC thread to express our confusion 
about the situation. We would be grateful if the chairs could clarify the 
situation, and identify, on the list, any potential issues that might keep 
draft-ietf-dnsop-dnssec-bootstrapping from advancing so that they can be 
addressed properly (if any).

Thanks,
Nils and Peter



--
Like our community service? 💛
Please consider donating at

https://desec.io/

deSEC e.V.
Kyffhäuserstr. 5
10781 Berlin
Germany

Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-rfc8109bis

[Peter Thomassen]

Hi Tim,

On 9/13/23 23:05, Tim Wicinski wrote:

We Chairs are back and catching up, and want to get things moving again.

This starts a Working Group Last Call for draft-ietf-dnsop-rfc8109bis
"Initializing a DNS Resolver with Priming Queries"

Current versions of the draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8109bis/ 


While others have commented that this draft is not ready for WGLC, Nils and I 
would like to note that the Chairs Actions after IETF 117 [1] listed an order 
for upcoming WGLC, with this draft listed second and 
draft-ietf-dnsop-dnssec-bootstrapping listed first.

Unlike draft-ietf-dnsop-rfc8109bis which has been adopted only in June 2023, 
draft-ietf-dnsop-dnssec-bootstrapping has been sitting there, with several 
implementations and without any modifications (beyond minor editorial), for 
over a year.

The authors have been interacting with the chairs a few times since the 
beginning of the year, to see if anything needs to be done for the draft to 
advance. In the process, we have been told (in May) that an announcement for 
WGLC readiness would be sent to the WG list, and later that WGLC would be 
started before IETF 118. Once IETF 118 was over, the draft was listed first in 
the Chairs Actions. Now it's been postponed again.

We'd like to take the opportunity of this WGLC thread to express our confusion 
about the situation. We would be grateful if the chairs could clarify the 
situation, and identify, on the list, any potential issues that might keep 
draft-ietf-dnsop-dnssec-bootstrapping from advancing so that they can be 
addressed properly (if any).

Thanks,
Nils and Peter

--
https://desec.io/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-rfc8109bis

[Geoff Huston]

> On 14 Sep 2023, at 6:33 am, Tim Wicinski  wrote:
> 
> 
> Geoff
> 
> We had a DNS directorate review done 
> https://datatracker.ietf.org/doc/review-ietf-dnsop-rfc8109bis-00-dnsdir-early-ma-2023-08-29/
> And perhaps I was basing my vibes off of the review plus the authors. That is 
> on me.  But also, we chairs sometimes see the need to use the working
> group last call to put more eyes onto a document. 
> 
> tim
> 

Thanks for the clarification Tim.

Sigh. In my opinion a document that contains explicitly noted open/unresolved 
questions is not ready!

Geoff

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-rfc8109bis

[Tim Wicinski]

Geoff

We had a DNS directorate review done
https://datatracker.ietf.org/doc/review-ietf-dnsop-rfc8109bis-00-dnsdir-early-ma-2023-08-29/
And perhaps I was basing my vibes off of the review plus the authors. That
is on me.  But also, we chairs sometimes see the need to use the working
group last call to put more eyes onto a document.

tim



On Wed, Sep 13, 2023 at 5:30 PM Geoff Huston  wrote:

>
>
> > On 14 Sep 2023, at 6:25 am, Tim Wicinski  wrote:
> >
> >
> >
> > On Wed, Sep 13, 2023 at 5:20 PM Joe Abley  wrote:
> > Hi Tim,
> >
> > Op 13 sep. 2023 om 23:06 heeft Tim Wicinski  het
> volgende geschreven:
> > 
> >>
> >> This starts a Working Group Last Call for draft-ietf-dnsop-rfc8109bis
> >> "Initializing a DNS Resolver with Priming Queries"
> >>
> >> Current versions of the draft is available here:
> >> https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8109bis/
> >
> > This draft seems to still have open questions in sections 3.1 and 3.3.
> Are those intended to be taken out before the document proceeds, or do they
> need discussion from the working group before the last call?
> >
> >
> > Joe
> >
> >
> > Joe
> >
> > One of our hopes is during this WGLC we can address these issues.  But
> yes, they are open.
>
> My preference would be for a largely complete document to be Last Called.
> It might also be help to have a DNS Directorate review performed at this
> point to assist in both highlighting and working with the draft authors to
> resolve these incomplete areas.
>
> Geoff
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-rfc8109bis

[Geoff Huston]

> On 14 Sep 2023, at 6:25 am, Tim Wicinski  wrote:
> 
> 
> 
> On Wed, Sep 13, 2023 at 5:20 PM Joe Abley  wrote:
> Hi Tim,
> 
> Op 13 sep. 2023 om 23:06 heeft Tim Wicinski  het volgende 
> geschreven:
> 
>> 
>> This starts a Working Group Last Call for draft-ietf-dnsop-rfc8109bis
>> "Initializing a DNS Resolver with Priming Queries"
>> 
>> Current versions of the draft is available here:
>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8109bis/
> 
> This draft seems to still have open questions in sections 3.1 and 3.3. Are 
> those intended to be taken out before the document proceeds, or do they need 
> discussion from the working group before the last call?
> 
> 
> Joe
> 
> 
> Joe
> 
> One of our hopes is during this WGLC we can address these issues.  But yes, 
> they are open. 

My preference would be for a largely complete document to be Last Called. It 
might also be help to have a DNS Directorate review performed at this point to 
assist in both highlighting and working with the draft authors to resolve these 
incomplete areas.

Geoff
 
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-rfc8109bis

[Geoff Huston]

> On 14 Sep 2023, at 6:20 am, Joe Abley  wrote:
> 
> Hi Tim,
> 
> Op 13 sep. 2023 om 23:06 heeft Tim Wicinski  het volgende 
> geschreven:
> 
>> 
>> This starts a Working Group Last Call for draft-ietf-dnsop-rfc8109bis
>> "Initializing a DNS Resolver with Priming Queries"
>> 
>> Current versions of the draft is available here:
>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8109bis/
> 
> This draft seems to still have open questions in sections 3.1 and 3.3. Are 
> those intended to be taken out before the document proceeds, or do they need 
> discussion from the working group before the last call?
> 

and section 5 contains an open question. The draft is obviously not ready to 
complete this WG Last Call imho.

Geoff

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-rfc8109bis

[Tim Wicinski]

On Wed, Sep 13, 2023 at 5:20 PM Joe Abley  wrote:

> Hi Tim,
>
> Op 13 sep. 2023 om 23:06 heeft Tim Wicinski  het
> volgende geschreven:
> 
>
> This starts a Working Group Last Call for draft-ietf-dnsop-rfc8109bis
> "Initializing a DNS Resolver with Priming Queries"
>
> Current versions of the draft is available here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8109bis/
>
>
> This draft seems to still have open questions in sections 3.1 and 3.3. Are
> those intended to be taken out before the document proceeds, or do they
> need discussion from the working group before the last call?
>
>
> Joe
>
>
Joe

One of our hopes is during this WGLC we can address these issues.  But yes,
they are open.

thanks
tim
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-rfc8109bis

[Joe Abley]

Hi Tim,

Op 13 sep. 2023 om 23:06 heeft Tim Wicinski  het volgende 
geschreven:

> This starts a Working Group Last Call for draft-ietf-dnsop-rfc8109bis
> "Initializing a DNS Resolver with Priming Queries"
> 
> Current versions of the draft is available here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8109bis/

This draft seems to still have open questions in sections 3.1 and 3.3. Are 
those intended to be taken out before the document proceeds, or do they need 
discussion from the working group before the last call?


Joe


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Working Group Last Call for draft-ietf-dnsop-rfc8109bis

[Tim Wicinski]

Hi All

We Chairs are back and catching up, and want to get things moving again.

This starts a Working Group Last Call for draft-ietf-dnsop-rfc8109bis
"Initializing a DNS Resolver with Priming Queries"

Current versions of the draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8109bis/

The Current Intended Status of this document is: Best Current Practice
and it Obsoletes 8109

Please review the draft and offer relevant comments.
If this does not seem appropriate please speak out.
If someone feels the document is *not* ready for publication, please speak
out with your reasons.

This starts a two week Working Group Last Call process, and ends on: 27
September 2023

thanks
tim
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop