Re: [DNSOP] WGLC for draft-ietf-dnsop-tcp-requirements

[Suzanne Woolf]

Hi,

The WGLC resulted in some good discussion of (mostly) small improvements to the 
text, which the authors are responding to. 

The chairs will be discussing advancement of this document in our next meeting. 
Thanks to everyone who commented.


Suzanne 
for the chairs

> On Apr 18, 2021, at 7:17 PM, Suzanne Woolf  wrote:
> 
> Dear colleagues,
> 
> 
> This message starts the Working Group Last Call for 
> draft-ietf-dnsop-tcp-requirements 
> (https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/ 
> )
> 
> Since this draft has not been recently discussed in the WG, we figure people 
> might need to swap it back in, and we’re requesting BCP status. So the WGLC 
> will end in three weeks (instead of the usual two), on 3 May.
> 
> Substantive comments to the list, please. It’s fine for minor edits to go 
> direct to the authors.
> 
> We’d like to advance this but it needs some active support, so we need to 
> hear from folks who have found it useful, especially implementers.
> 
> 
> Thanks,
> Suzanne
> For the chairs
> 

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

Re: [DNSOP] WGLC for draft-ietf-dnsop-tcp-requirements

[Tony Finch]

John Kristoff  wrote:
>
> However, I think we'd be reluctant to say much about minimal-answers
> here in a context that suggests it is some sort of DDoS mitigation
> mechanism and that you need it because... "TCP".  Maybe there is some
> adjustments to the text somewhere that can help highlight that certain
> RRsets or settings may lead to more TCP traffic?

There's this paragraph:

   Often, reducing the EDNS0 UDP packet size leads to a successful
   response.  That is, the necessary data fits within the smaller
   message size.  However, when the data does not fit, the server sets
   the truncated flag in its response, indicating the client should
   retry over TCP to receive the whole response.  This is undesirable
   from the client's point of view because it adds more latency and
   potentially undesirable from the server's point of view due to the
   increased resource requirements of TCP.

which is followed by discussion of various ways of reducing response sizes
to avoid fragmentation and truncation. I thought that minimal-responses
and minimal-any could also be mentioned as useful ways to avoid large
responses. The anti-DDoS aspect of minimal-any isn't the main point in
this context.

> IETF RFC 2136 (UPDATE) is already referenced in our draft, section
> 2.2.  Is this insufficient?

Oh yes, that's the kind of text I was expecting :-)

I guess I had forgotten about it by the time I got to the appendix and
thought it must have been missing because RFC 2136 isn't listed in the
appendix.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Lundy: Northeast 4 to 6 becoming variable 4 or less. Smooth or slight,
but moderate until later in west. Rain then showers. Good,
occasionally moderate at first.

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

Re: [DNSOP] WGLC for draft-ietf-dnsop-tcp-requirements

[John Kristoff]

On Thu, 22 Apr 2021 20:23:19 +0100
Tony Finch  wrote:

> I needed minimal-any when my auth servers were being hammered by lots of
> recursive servers making ANY requests; the responses were being truncated
> because my servers have for a long time been configured to avoid
> fragmentation, and the retries over TCP caused an overload.

Hi Tony,

Minimal answers I think is an interesting and in a more general context
I'm interested in exploring it as an operational practice (e.g. I think
it can help relieve some of the burden and problems of parent/child
inconsistency).

However, I think we'd be reluctant to say much about minimal-answers
here in a context that suggests it is some sort of DDoS mitigation
mechanism and that you need it because... "TCP".  Maybe there is some
adjustments to the text somewhere that can help highlight that certain
RRsets or settings may lead to more TCP traffic?


Thanks for taking on a bulk of replies so far.  I tend to like to
digest them first, before replying to them in rapid succession so
you're beating me to it.  I can do some of the follow up work in the
repo where I find things that are not yet addressed.

> > > Should RFC 2136 UPDATE be mentioned? (sections 2.1, 6.2, 7.8, 7.9) TBH I'm
> > > not sure how much UDP is used, but I certainly rely on 60+ KB updates.  
> >
> > I probably don't have enough direct experience with UPDATE to say.  If
> > it is largely over TCP then I think it should be included.  
> 
> I listed the main section numbers that mention TCP. One point in RFC 2136
> that's notable from an operational point of view is that an UPDATE client
> has to use TCP if it wants to be sure to get a response. Unlike QUERY,
> UPDATE is not idempotent so UPDATE-over-UDP can't be retried when there is
> packet loss. (But `nsupdate` still uses UDP for small changes; I run it
> over localhost which is reliable enough.)

IETF RFC 2136 (UPDATE) is already referenced in our draft, section
2.2.  Is this insufficient?

John

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

Re: [DNSOP] WGLC for draft-ietf-dnsop-tcp-requirements

[Donald Eastlake]

Hi,

Thanks for the quick response. See below.

On Fri, Apr 23, 2021 at 1:36 PM Wessels, Duane  wrote:
>
> > On Apr 22, 2021, at 11:50 AM, Donald Eastlake  wrote:
> >
> > Hi,
> >
> > This is a good document and I support publication.
> >
> > However, I do have some comments. I scanned the Last Call comments by
> > others, and they mostly seem like improvements, but some of my
> > comments below may duplicate others for which I apologize in advance.
> >
> >
> > Section 3, last paragraph: Cut out wishy-washy superfluous words. Be bold!
> > OLD
> > vice-versa.  However, it is the aim of this document to argue that
> > BETTER
> > vice-versa.  However, this document argues that
> > BEST
> > vice-versa.  However,
>
> Done!
>
> >
> > Although Cookies are mentioned in this draft with a reference to the
> > RFC 7873, it would be good to work in the point that the Cookies RFC
> > recommends use of TCP whenever Cookies are not available as a way to
> > get some of the benefits of Cookies. Thus, if I remember correctly,
> > someone following that RFC would use Cookies or, when they are not
> > available, TCP.
>
> The appendix entry for RFC 7873 said:
>
> [RFC 7873] mentions DNS over TCP as a reasonable fallback mechanism when 
> DNS Cookies
> are not available.
>
> The phrase "reasonable fallback" doesn't sit quite right with me so I changed 
> it to
> "...as an alternative mechanism...".  Does that work for you or were you 
> suggesting
> that this point be made in the body of the document rather than only in the 
> appendix?

Well, ideally it would be in the body of the document but it looks
like it would take a moderate amount of work to do that. I am
satisfied with the rewording in the appendix.

> > Section 9, last paragraph: Don't be so negative :-)
> > "not unlike" -> "similar to"
>
> Done.
>
> >
> > Make the name of Section 2 a bit more explicit, something like
> > "History of DNS over TCP"
>
> Yes, done.
>
> >
> > Section 1.1: Update as per RFC 8174.
>
> Done.
>
> >
> > Lots of references are good but I find it disturbing that all
> > technical references are shown as Informational. I think a lot of them
> > should be moved to Normative.
>
> I wondered about that as well.  I moved many of the standards track RFCs to 
> the normative section.  I will highlight this change when the next version is 
> posted and I hope someone lets us know if any of those are not appropriate 
> there.

Sounds good. Probably not a serious problem as I think all the
references that maybe should be normative are already standards track
so there won't be any down-references... Probably Document Shepherds
review and AD review will catch any further changes needed here.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com

> DW

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

Re: [DNSOP] WGLC for draft-ietf-dnsop-tcp-requirements

[Wessels, Duane]

> On Apr 22, 2021, at 11:50 AM, Donald Eastlake  wrote:
> 
> 
> Hi,
> 
> This is a good document and I support publication.
> 
> However, I do have some comments. I scanned the Last Call comments by
> others, and they mostly seem like improvements, but some of my
> comments below may duplicate others for which I apologize in advance.
> 
> 
> Section 3, last paragraph: Cut out wishy-washy superfluous words. Be bold!
> OLD
> vice-versa.  However, it is the aim of this document to argue that
> BETTER
> vice-versa.  However, this document argues that
> BEST
> vice-versa.  However,

Done!

> 
> 
> Although Cookies are mentioned in this draft with a reference to the
> RFC 7873, it would be good to work in the point that the Cookies RFC
> recommends use of TCP whenever Cookies are not available as a way to
> get some of the benefits of Cookies. Thus, if I remember correctly,
> someone following that RFC would use Cookies or, when they are not
> available, TCP.

The appendix entry for RFC 7873 said:

[RFC 7873] mentions DNS over TCP as a reasonable fallback mechanism when 
DNS Cookies
are not available.

The phrase "reasonable fallback" doesn't sit quite right with me so I changed 
it to
"...as an alternative mechanism...".  Does that work for you or were you 
suggesting
that this point be made in the body of the document rather than only in the 
appendix?



> 
> Section 9, last paragraph: Don't be so negative :-)
> "not unlike" -> "similar to"

Done.

> 
> 
> Make the name of Section 2 a bit more explicit, something like
> "History of DNS over TCP"

Yes, done.


> 
> 
> Section 1.1: Update as per RFC 8174.

Done.

> 
> 
> Lots of references are good but I find it disturbing that all
> technical references are shown as Informational. I think a lot of them
> should be moved to Normative.

I wondered about that as well.  I moved many of the standards track RFCs to the 
normative section.  I will highlight this change when the next version is 
posted and I hope someone lets us know if any of those are not appropriate 
there.

DW




smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] WGLC for draft-ietf-dnsop-tcp-requirements

[Tony Finch]

Wessels, Duane  wrote:
>

Thanks for looking through my suggestions! All the changes look good.
A few follow-up points:

> Oops, correcting myself here.  It needs to be RFC 2541 because that is the
> one that mentions TCP.

Aha, that makes sense

> > 2.4:
> >
> > Last 2 paragraph s re. avoiding fragmentation, it might be worth
> > suggesting minimal-any [RFC 8482].
>
> I did add 8482 to the Appendix as you also suggested below.  I'm a
> little reluctant to add a reference in section 2.4 since I think the
> primary motivation for 8482 was about DDoS amplification, rather than
> fragmentation.  But I could still be convinced otherwise.

I needed minimal-any when my auth servers were being hammered by lots of
recursive servers making ANY requests; the responses were being truncated
because my servers have for a long time been configured to avoid
fragmentation, and the retries over TCP caused an overload.

I tend to think of all settings that reduce response size as tools for
avoiding fragmentation. Which makes me realise that BIND's
minimal-responses setting is probably also worth a mention. (I dunno if
other servers have a similar knob?)

> > A:
> >
> > Should RFC 2136 UPDATE be mentioned? (sections 2.1, 6.2, 7.8, 7.9) TBH I'm
> > not sure how much UDP is used, but I certainly rely on 60+ KB updates.
>
> I probably don't have enough direct experience with UPDATE to say.  If
> it is largely over TCP then I think it should be included.

I listed the main section numbers that mention TCP. One point in RFC 2136
that's notable from an operational point of view is that an UPDATE client
has to use TCP if it wants to be sure to get a response. Unlike QUERY,
UPDATE is not idempotent so UPDATE-over-UDP can't be retried when there is
packet loss. (But `nsupdate` still uses UDP for small changes; I run it
over localhost which is reliable enough.)

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
East Forties: Northwesterly 3 to 5. Moderate. Showers. Good.

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

Re: [DNSOP] WGLC for draft-ietf-dnsop-tcp-requirements

[Donald Eastlake]

Hi,

This is a good document and I support publication.

However, I do have some comments. I scanned the Last Call comments by
others, and they mostly seem like improvements, but some of my
comments below may duplicate others for which I apologize in advance.


Section 3, last paragraph: Cut out wishy-washy superfluous words. Be bold!
OLD
vice-versa.  However, it is the aim of this document to argue that
BETTER
vice-versa.  However, this document argues that
BEST
vice-versa.  However,


Although Cookies are mentioned in this draft with a reference to the
RFC 7873, it would be good to work in the point that the Cookies RFC
recommends use of TCP whenever Cookies are not available as a way to
get some of the benefits of Cookies. Thus, if I remember correctly,
someone following that RFC would use Cookies or, when they are not
available, TCP.


Section 9, last paragraph: Don't be so negative :-)
"not unlike" -> "similar to"


Make the name of Section 2 a bit more explicit, something like
"History of DNS over TCP"


Section 1.1: Update as per RFC 8174.


Lots of references are good but I find it disturbing that all
technical references are shown as Informational. I think a lot of them
should be moved to Normative.


Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com

On Sun, Apr 18, 2021 at 7:17 PM Suzanne Woolf  wrote:
>
> Dear colleagues,
>
>
> This message starts the Working Group Last Call for 
> draft-ietf-dnsop-tcp-requirements 
> (https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/)
>
> Since this draft has not been recently discussed in the WG, we figure people 
> might need to swap it back in, and we’re requesting BCP status. So the WGLC 
> will end in three weeks (instead of the usual two), on 3 May.
>
> Substantive comments to the list, please. It’s fine for minor edits to go 
> direct to the authors.
>
> We’d like to advance this but it needs some active support, so we need to 
> hear from folks who have found it useful, especially implementers.
>
>
> Thanks,
> Suzanne
> For the chairs
>
> ___
> 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] WGLC for draft-ietf-dnsop-tcp-requirements

[Wessels, Duane]

> On Apr 21, 2021, at 4:39 PM, Wessels, Duane 
>  wrote:
> 
>> 2.2:
>> 
>>  DNSSEC originally specified in [RFC2541]
>> 
>> I thought this should be RFC 2535 rather than the operational guidelines?
> 
> Sure, 2535 works for me.
> 

Oops, correcting myself here.  It needs to be RFC 2541 because that is the
one that mentions TCP.  The text has been updated like this:

   and the second was the set of extensions
   collectively known as DNSSEC, whose operational considerations are
   originally given in [RFC2541]....while the latter
   warned "... larger keys increase the size of KEY and SIG RRs.  This
   increases the chance of DNS UDP packet overflow and the possible
   necessity for using higher overhead TCP in responses."


DW



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] WGLC for draft-ietf-dnsop-tcp-requirements

[Peter van Dijk]

On Wed, 2021-04-21 at 23:47 +, Wessels, Duane wrote:
> >   application.  Applications must be coded and configured to make use
> >   of this filter.
> > 
> > While it's good to point out that this feature exists, I do not think
> > mandating it makes sense - implementers and operators might have other
> > preferences for handling open-but-as-yet-unused TCP connections. (Also
> > the lowercase 'must' is confusing.)
> 
> It was not intended as a requirement, but rather to note that the application 
> needs to do some work to utilize them.

Ah! That makes a lot more sense, yes.

>   Hows this?
> 
>These features are implemented as low-level socket options.
>It is necessary for applications to be specifically coded and
>configured to make use of them.

To my non-native eyes this still smells like 'you should do this'.

How about:

These features are implemented as low-level socket options, and they
are not activated automatically. If applications wish to use these
features, they will need to make specific calls to set the right
options, and administrators may need to configure the applications to
make these calls.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

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

Re: [DNSOP] WGLC for draft-ietf-dnsop-tcp-requirements

[Wessels, Duane]

> On Apr 19, 2021, at 9:34 AM, Peter van Dijk  
> wrote:
> 
>> This message starts the Working Group Last Call for 
>> draft-ietf-dnsop-tcp-requirements 
>> (https://secure-web.cisco.com/1GUztR-Nd5B-MpjncjmDNOnqlKoeK5-09UeTvbL1dFyQqc0x3GpwWIzNUMvS9B4MsWztiWQY9T4fEg5m6LLL1pIw6mIP3Glh5Dv0eS5QuBH0_Er0tAvzCWC4zQmflkrgxR33_ZI_bjrpDA44xWmAs5GaN2Xu6HgIlfNUxBYXJzJjwsgJ_xviwCeTT7debqaByK_Oko0XxsVpateA6jVRS5dByfqyYMX03JeB_kJbfBGxtfsoWTcBVWSYTpsCG7_KrY8EWi3H9J7_369rrwCogbQ/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-dnsop-dns-tcp-requirements%2F)
> 
> This is a good document.
> 
> One comment here:
> 
>   The FreeBSD, OpenBSD, and NetBSD operating systems have an "accept
>   filter" feature ([accept_filter]) that postpones delivery of TCP
>   connections to applications until a complete, valid request has been
>   received.  The dns_accf(9) filter ensures that a valid DNS message
>   is received.  If not, the bogus connection never reaches the
>   application.  Applications must be coded and configured to make use
>   of this filter.
> 
> While it's good to point out that this feature exists, I do not think
> mandating it makes sense - implementers and operators might have other
> preferences for handling open-but-as-yet-unused TCP connections. (Also
> the lowercase 'must' is confusing.)

It was not intended as a requirement, but rather to note that the application 
needs to do some work to utilize them.  Hows this?

   These features are implemented as low-level socket options.
   It is necessary for applications to be specifically coded and
   configured to make use of them.


> Suggested extra text:
> 
>> The Linux TCP_DEFER_ACCEPT feature, while more limited in scope, can
> provide some of the same benefits as the BSD accept filter feature.

Added, thanks.

DW




smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] WGLC for draft-ietf-dnsop-tcp-requirements

[Wessels, Duane]

> On Apr 19, 2021, at 8:45 AM, Tony Finch  wrote:
> 
> Suzanne Woolf  wrote:
>> 
>> This message starts the Working Group Last Call for
>> draft-ietf-dnsop-tcp-requirements
> 
> I have read the draft and I am keen to see it published. Just the other
> day I was having a discussion about whether TCP support is really needed,
> and I wanted something stronger than RFC 7766 to point to.
> 
> The draft is readable and comprehensive. I like it.
> 
> Some minor and pedantic nits:
> 
> 2.2:
> 
>   DNSSEC originally specified in [RFC2541]
> 
> I thought this should be RFC 2535 rather than the operational guidelines?

Sure, 2535 works for me.


> 
> 2.3:
> 
>   This unsigned 16-bit field specifies, in bytes, the maximum
>   (possibly fragmented) DNS message size a node is capable of
>   receiving.
> 
> I suggest adding "over UDP" to the end of the sentence (since the EDNS
> buffer size doesn't restrict messages over other transports).

Done.


> 
> 2.4:
> 
> Last 2 paragraph s re. avoiding fragmentation, it might be worth
> suggesting minimal-any [RFC 8482].

I did add 8482 to the Appendix as you also suggested below.  I'm a little 
reluctant to
add a reference in section 2.4 since I think the primary motivation for 8482 
was about
DDoS amplification, rather than fragmentation.   But I could still be convinced 
otherwise.



> 
> 4.3:
> 
>   the Linux kernel provides a number of "sysctl" parameters related to
>   TIME_WAIT, such as net.ipv4.tcp_fin_timeout, net.ipv4.tcp_tw_recycle,
>   and net.ipv4.tcp_tw_reuse.
> 
> I believe that net.ipv4.tcp_tw_recycle is problematic and has been removed
> https://secure-web.cisco.com/1zq_T2G9VjiDGyCD0UqiwfZ7i0Jc_JcoiRaUvHdWj_Nfh6pjxxQygRKERClmruWq9Yie54GznGNn-TR0ijjBYdidyWjP-mbPF5EWAwdDtalD86OTC3Z--zQWHcwkJtpdtD_iHBJqo4tRAddX5cQM8cJpMFTDMKKcXx-upQpjW14N1FwLeCniHz9apzZbWcIvZ_xlx3UDB4cvVJmNXzOZni24brGiihUnUPzUOipM8mAlwkq7ZuVgFJYRfKCc4DjCjiBYP9m5stLbRNYinc72Nlw/https%3A%2F%2Fvincent.bernat.ch%2Fen%2Fblog%2F2014-tcp-time-wait-state-linux%23netipv4tcp_tw_recycle

I removed tcp_tw_recycle.

> 
> 4.4:
> 
>   Although DNS-over-TLS utilizes TCP port
>   853 instead of port 53, this document applies equally well to DNS-
>   over-TLS.
> 
> Um, how much of this document applies to DoT? Just the tuning advice, or
> the requirement that TLS MUST be supported like TCP MUST be?
> 
> 5:
> 
> re "DDoS mitigation techniques" would it be worth citing DNS RRL here as
> well as in section 9?

Hows this?

   message sizes, lack of EDNS(0) support, DDoS mitigation techniques
   (including [RRL]), or perhaps some future capability that is as yet



> 
> 10:
> 
>   Since DNS over both UDP and TCP use the same underlying message
>   format, the use of one transport instead of the other does change the
>   privacy characteristics of the message content
> 
> Missing "not"?

Yes indeed.

> 
> A:
> 
> Should RFC 2136 UPDATE be mentioned? (sections 2.1, 6.2, 7.8, 7.9) TBH I'm
> not sure how much UDP is used, but I certainly rely on 60+ KB updates.

I probably don't have enough direct experience with UPDATE to say.  If it is 
largely
over TCP then I think it should be included.


> 
> Also RFC 8482 section 4.4 talks about possible different behaviour for ANY
> queries over UDP compared to TCP.

RFC 8482 has been added to the appendix.

> 
> A.8:
> 
>   [RFC3226] strongly argued in favor of UDP messages over TCP largely
> 
> I had to read this twice! How about "instead of" instead of "over"?

yes, agreed.

> 
> A.14:
> 
> I think there should be a note that RFC 5966 has been obsoleted by RFC
> 7766, with a cross-reference to A.21.

Done.


DW




smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] WGLC for draft-ietf-dnsop-tcp-requirements

[Wessels, Duane]

> On Apr 19, 2021, at 4:31 AM, Joe Abley  wrote:
> 
> 
> Hi Suz,
> 
> On 18 Apr 2021, at 19:17, Suzanne Woolf  wrote:
> 
>> This message starts the Working Group Last Call for 
>> draft-ietf-dnsop-tcp-requirements 
>> (https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/)
> 
> I have read draft-ietf-dnsop-dns-tcp-requirements-07 and have the following 
> comments, in flagrant defiance of George's advice to ship the document based 
> mainly on considerations of age. :-)

Thanks Joe!

> 
> I think these are all fairly minor.
> 
> 
> Abstract, Section 4.4 "DNS-over-TLS"
> 
> The abstract includes the sentence "This includes both DNS over unencrpted 
> TCP, as well as over an encrypted TLS session." The later section 4.4 says 
> "this document applies equally well to DNS-over-TLS'.
> 
> The inclusion of DoT looks like an afterthought that has not been entirely 
> afterthought-through. The procedural updates to 1034 in section 3 clearly 
> don't apply to RFC 7858; the justifiable confusion about transports in the 
> DNS (the main topic of this document) also doesn't apply to 7858 which only 
> specifies use of TLS, not DTLS.
> 
> I suggest that this document is really only concerned with strengthening the 
> requirements around the use of TCP transport as described in 1034 and 1035 
> and that mentioning any other transport is unhelpful and arguably introduces 
> more confusion. I think that sentence should be changed in the abstract to 
> reflect that and section 4.4 should be removed. I would not be surprised to 
> hear that this DoT text was added precisely to address some other earlier 
> reviewer's opinion to the contrary, but this is what I think.

IIRC, DNS-over-TLS was added to this draft following a working group discussion 
at IETF 104.  I can easily be convinced to remove it, but I would like to hear 
more people supporting its removal.  I know Tony Finch also already raised 
questions about including DNS-over-TLS.


> 2.3 EDNS0
> 
> RFC 6891 uses the notation EDNS(0), not EDNS0. Since 6891 obsoletes 2671 it 
> seems reasonable to adopt its notation. I suggest going all search and 
> replace on that.

Okay, done.

> 
> 2.4 Fragmentation and Truncation
> 
> The second paragraph does not mention another fundamental problem with 
> stateless protocols over IPv6 when datagrams require truncation, which is 
> that the requirement in v6 to fragment and resent from the source is not 
> possible when the source has not retained any state regarding to the response 
> that was just sent. While I had my hands in the patient I also added a small 
> reference to tunnel encaps in IPv4.
> 
> OLD:
> 
>For IPv4-connected hosts, the de-facto MTU is often the Ethernet
>payload size of 1500 bytes.  This means that the largest unfragmented
>UDP DNS message that can be sent over IPv4 is likely 1472 bytes.  For
>IPv6, the situation is a little more complicated.  First, IPv6
>headers are 40 bytes (versus 20 without options in IPv4).  Second, it
>seems as though some people have mis-interpreted IPv6's required
>minimum MTU of 1280 as a required maximum.  Third, fragmentation in
>IPv6 can only be done by the host originating the datagram.  The need
>to fragment is conveyed in an ICMPv6 "packet too big" message.  The
>originating host indicates a fragmented datagram with IPv6 extension
>headers.  Unfortunately, it is quite common for both ICMPv6 and IPv6
>extension headers to be blocked by middleboxes.  According to
>[HUSTON] some 35% of IPv6-capable recursive resolvers were unable to
>receive a fragmented IPv6 packet.
> 
> NEW:
> 
>For IPv4-connected hosts, the MTU is often the Ethernet payload
>size of 1500 bytes.  This means that the largest unfragmented
>UDP DNS message that can be sent over IPv4 is likely 1472 bytes,
>although tunnel encapsulation may reduce that maximum message
>size in some cases.
> 
>For IPv6, the situation is a little more complicated.  First,
>IPv6 headers are 40 bytes (versus 20 without options in IPv4).
>Second, it seems as though some people have mis-interpreted
>IPv6's required minimum MTU of 1280 as a required maximum.  Third,
>fragmentation in IPv6 can only be done by the host originating
>the datagram.  The need to fragment is conveyed in an ICMPv6
>"packet too big" message.  The originating host indicates a
>fragmented datagram with IPv6 extension headers.  Unfortunately,
>it is quite common for both ICMPv6 and IPv6 extension headers
>to be blocked by middleboxes. According to [HUSTON] some 37% of
>IPv6-capable recursive resolvers were unable to receive a
>fragmented IPv6 packet.  Even if the originating host does receive
>a signal that fragmentation is required, the stateless nature
>of the DNS protocol is such that the host does not generally
>retain a copy of the message concerned and hence is unable to  
>fragment and re-send 

Re: [DNSOP] WGLC for draft-ietf-dnsop-tcp-requirements

[Tim Wicinski]

(no hats on)

I've read this, and I agree it should move forward.
Should there be a reference to RFC8499 in here as well?

(with chairs hat on)

Mr Finch made some editorial nits that I concur with.  I also ran the Nits
tool and found several outdated references,
among other things.  I've requested that the authors fix these up before it
ends up heading to the IESG.

tim



On Sun, Apr 18, 2021 at 7:17 PM Suzanne Woolf 
wrote:

> Dear colleagues,
>
>
> This message starts the Working Group Last Call
> for draft-ietf-dnsop-tcp-requirements (
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/)
>
> Since this draft has not been recently discussed in the WG, we figure
> people might need to swap it back in, and we’re requesting BCP status. So
> the WGLC will end in three weeks (instead of the usual two), on 3 May.
>
> Substantive comments to the list, please. It’s fine for minor edits to go
> direct to the authors.
>
> We’d like to advance this but it needs some active support, so we need to
> hear from folks who have found it useful, especially implementers.
>
>
> Thanks,
> Suzanne
> For the chairs
>
> ___
> 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] WGLC for draft-ietf-dnsop-tcp-requirements

[Brian Dickson]

On Sun, Apr 18, 2021 at 4:17 PM Suzanne Woolf 
wrote:

> Dear colleagues,
>
>
> This message starts the Working Group Last Call
> for draft-ietf-dnsop-tcp-requirements (
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/)
>
> Since this draft has not been recently discussed in the WG, we figure
> people might need to swap it back in, and we’re requesting BCP status. So
> the WGLC will end in three weeks (instead of the usual two), on 3 May.
>
> Substantive comments to the list, please. It’s fine for minor edits to go
> direct to the authors.
>
> We’d like to advance this but it needs some active support, so we need to
> hear from folks who have found it useful, especially implementers.
>

I have found it useful, and am strongly in favor of advancing this as a BCP.
I concur with the on-list comments from everyone on updates, too.

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

Re: [DNSOP] WGLC for draft-ietf-dnsop-tcp-requirements

[Joe Abley]

On 19 Apr 2021, at 12:40, Peter van Dijk  wrote:

> This note on statelessness is good, but I don't think it should be tied to 
> IPv6. Packets get lost in IPv4 too, especially when they are big, and even if 
> such evens trigger a report in the form of an ICMP message, the same 
> lack-of-state problem applies.

In IPv4, datagrams that need to be transmitted over a link with an MTU is too 
low are fragmented by the router attached to the link, assuming DF=0. There is 
no signal sent back to the source in that case. In IPv6 that doesn't happen.

In the v4 case a large DNS message (large enough to require fragmentation along 
the path) can be transmitted without the source having to retain any state. 
That's not true in v6.

So I think the v4 and v6 cases are different. That's why I attached that 
comment to the v6 case.

DNS messages can be lost in both v4 and v6 for a variety of other reasons, I 
agree.

> https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/ even 
> proposes setting DONTFRAG socket options, and some servers out there already 
> send IPv4 replies with the DF bit set (the two I can verify immediately are 
> OpenDNS, and whatever is running on the router my provider gave me, but most 
> likely there are others too).

Setting DF=1 does seem like it would avoid the differences I was trying to 
allude to above, I agree. With DF=1 fragmentation (or not-fragmentation) is 
just another reason for a packet to get dropped.


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

Re: [DNSOP] WGLC for draft-ietf-dnsop-tcp-requirements

[Peter van Dijk]

On Mon, 2021-04-19 at 07:31 -0400, Joe Abley wrote:
> NEW:
> 
>For IPv4-connected hosts, the MTU is often the Ethernet payload
>size of 1500 bytes.  This means that the largest unfragmented
>UDP DNS message that can be sent over IPv4 is likely 1472 bytes,
>although tunnel encapsulation may reduce that maximum message
>size in some cases.
> 
>For IPv6, the situation is a little more complicated.  First,
>IPv6 headers are 40 bytes (versus 20 without options in IPv4).
>Second, it seems as though some people have mis-interpreted
>IPv6's required minimum MTU of 1280 as a required maximum.  Third,
>fragmentation in IPv6 can only be done by the host originating
>the datagram.  The need to fragment is conveyed in an ICMPv6
>"packet too big" message.  The originating host indicates a
>fragmented datagram with IPv6 extension headers.  Unfortunately,
>it is quite common for both ICMPv6 and IPv6 extension headers
>to be blocked by middleboxes. According to [HUSTON] some 37% of
>IPv6-capable recursive resolvers were unable to receive a
>fragmented IPv6 packet.  Even if the originating host does receive
>a signal that fragmentation is required, the stateless nature
>of the DNS protocol is such that the host does not generally
>retain a copy of the message concerned and hence is unable to  
>fragment and re-send anyway. 

This note on statelessness is good, but I don't think it should be tied to 
IPv6. Packets get lost in IPv4 too, especially when they are big, and even if 
such evens trigger a report in the form of an ICMP message, the same 
lack-of-state problem applies.

https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/ even 
proposes setting DONTFRAG socket options, and some servers out there already 
send IPv4 replies with the DF bit set (the two I can verify immediately are 
OpenDNS, and whatever is running on the router my provider gave me, but most 
likely there are others too).

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

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

Re: [DNSOP] WGLC for draft-ietf-dnsop-tcp-requirements

[Peter van Dijk]

> This message starts the Working Group Last Call for 
> draft-ietf-dnsop-tcp-requirements 
> (https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/)

This is a good document.

One comment here:

   The FreeBSD, OpenBSD, and NetBSD operating systems have an "accept
   filter" feature ([accept_filter]) that postpones delivery of TCP
   connections to applications until a complete, valid request has been
   received.  The dns_accf(9) filter ensures that a valid DNS message
   is received.  If not, the bogus connection never reaches the
   application.  Applications must be coded and configured to make use
   of this filter.

While it's good to point out that this feature exists, I do not think
mandating it makes sense - implementers and operators might have other
preferences for handling open-but-as-yet-unused TCP connections. (Also
the lowercase 'must' is confusing.)

Suggested extra text:

> The Linux TCP_DEFER_ACCEPT feature, while more limited in scope, can
provide some of the same benefits as the BSD accept filter feature.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

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

Re: [DNSOP] WGLC for draft-ietf-dnsop-tcp-requirements

[Tony Finch]

Suzanne Woolf  wrote:
>
> This message starts the Working Group Last Call for
> draft-ietf-dnsop-tcp-requirements

I have read the draft and I am keen to see it published. Just the other
day I was having a discussion about whether TCP support is really needed,
and I wanted something stronger than RFC 7766 to point to.

The draft is readable and comprehensive. I like it.

Some minor and pedantic nits:

2.2:

   DNSSEC originally specified in [RFC2541]

I thought this should be RFC 2535 rather than the operational guidelines?

2.3:

   This unsigned 16-bit field specifies, in bytes, the maximum
   (possibly fragmented) DNS message size a node is capable of
   receiving.

I suggest adding "over UDP" to the end of the sentence (since the EDNS
buffer size doesn't restrict messages over other transports).

2.4:

Last 2 paragraph s re. avoiding fragmentation, it might be worth
suggesting minimal-any [RFC 8482].

4.3:

   the Linux kernel provides a number of "sysctl" parameters related to
   TIME_WAIT, such as net.ipv4.tcp_fin_timeout, net.ipv4.tcp_tw_recycle,
   and net.ipv4.tcp_tw_reuse.

I believe that net.ipv4.tcp_tw_recycle is problematic and has been removed
https://vincent.bernat.ch/en/blog/2014-tcp-time-wait-state-linux#netipv4tcp_tw_recycle

4.4:

   Although DNS-over-TLS utilizes TCP port
   853 instead of port 53, this document applies equally well to DNS-
   over-TLS.

Um, how much of this document applies to DoT? Just the tuning advice, or
the requirement that TLS MUST be supported like TCP MUST be?

5:

re "DDoS mitigation techniques" would it be worth citing DNS RRL here as
well as in section 9?

10:

   Since DNS over both UDP and TCP use the same underlying message
   format, the use of one transport instead of the other does change the
   privacy characteristics of the message content

Missing "not"?

A:

Should RFC 2136 UPDATE be mentioned? (sections 2.1, 6.2, 7.8, 7.9) TBH I'm
not sure how much UDP is used, but I certainly rely on 60+ KB updates.

Also RFC 8482 section 4.4 talks about possible different behaviour for ANY
queries over UDP compared to TCP.

A.8:

   [RFC3226] strongly argued in favor of UDP messages over TCP largely

I had to read this twice! How about "instead of" instead of "over"?

A.14:

I think there should be a note that RFC 5966 has been obsoleted by RFC
7766, with a cross-reference to A.21.


(that's all I spotted)

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Mull of Galloway to Mull of Kintyre including the Firth of Clyde and
North Channel: Southeasterly 3 to 5 at first in west, otherwise
southwesterly 2 to 4, becoming variable 3 or less. Smooth or slight,
occasionally moderate near Mull of Kintyre. Occasional rain. Good,
occasionally moderate.

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

Re: [DNSOP] WGLC for draft-ietf-dnsop-tcp-requirements

[Joe Abley]

On 18 Apr 2021, at 19:17, Suzanne Woolf  wrote:

> We’d like to advance this but it needs some active support, so we need to 
> hear from folks who have found it useful, especially implementers.

I didn't mention explicitly before, sorry, but I think this is a good document, 
it's useful and it should be published.


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

Re: [DNSOP] WGLC for draft-ietf-dnsop-tcp-requirements

[Joe Abley]

Hi John,

On 19 Apr 2021, at 07:57, John Kristoff  wrote:

> On Mon, 19 Apr 2021 07:31:49 -0400
> Joe Abley  wrote:
> 
>> NEW:
>> 
>>   The specification of the DNS allows both UDP and TCP to be used 
>>   as transport protocols for exchanging unencrypted DNS messages.
>>   However, for various reasons, the availability of TCP transport
>>   has sometimes been interpreted as being optional.  This document 
>>   clarifies the need to provide TCP transport for both clients and
>>   servers and strengthens the requirement of DNS implementations
>>   to support both.
> 
> Thanks for your careful read and thoughtful comments.  I would just
> point out that there is already a document that specifically requires
> this of the implementations, IETF RFC 7766.  This draft was
> specifically aimed at operators, which have that document had
> sidestepped "this document makes no specific requirements for
> operators".  So maybe a simple "implementations" to "operators" change
> of your text would work?

Oh, I missed that, sorry. Yes, I agree, "operators" makes sense.

Someone is going to ask whether this document, as a BCP, can update 1123 which 
pre-dates such designations as standard track. That person is not going to be 
me, however.


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

Re: [DNSOP] WGLC for draft-ietf-dnsop-tcp-requirements

[John Kristoff]

On Mon, 19 Apr 2021 07:31:49 -0400
Joe Abley  wrote:

> NEW:
> 
>The specification of the DNS allows both UDP and TCP to be used 
>as transport protocols for exchanging unencrypted DNS messages.
>However, for various reasons, the availability of TCP transport
>has sometimes been interpreted as being optional.  This document 
>clarifies the need to provide TCP transport for both clients and
>servers and strengthens the requirement of DNS implementations
>to support both.

Hi Joe,

Thanks for your careful read and thoughtful comments.  I would just
point out that there is already a document that specifically requires
this of the implementations, IETF RFC 7766.  This draft was
specifically aimed at operators, which have that document had
sidestepped "this document makes no specific requirements for
operators".  So maybe a simple "implementations" to "operators" change
of your text would work?

John

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

Re: [DNSOP] WGLC for draft-ietf-dnsop-tcp-requirements

[Joe Abley]

Hi Suz,

On 18 Apr 2021, at 19:17, Suzanne Woolf  wrote:

> This message starts the Working Group Last Call for 
> draft-ietf-dnsop-tcp-requirements 
> (https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/ 
> )

I have read draft-ietf-dnsop-dns-tcp-requirements-07 and have the following 
comments, in flagrant defiance of George's advice to ship the document based 
mainly on considerations of age. :-)

I think these are all fairly minor.


Abstract, Section 4.4 "DNS-over-TLS"

The abstract includes the sentence "This includes both DNS over unencrpted TCP, 
as well as over an encrypted TLS session." The later section 4.4 says "this 
document applies equally well to DNS-over-TLS'.

The inclusion of DoT looks like an afterthought that has not been entirely 
afterthought-through. The procedural updates to 1034 in section 3 clearly don't 
apply to RFC 7858; the justifiable confusion about transports in the DNS (the 
main topic of this document) also doesn't apply to 7858 which only specifies 
use of TLS, not DTLS.

I suggest that this document is really only concerned with strengthening the 
requirements around the use of TCP transport as described in 1034 and 1035 and 
that mentioning any other transport is unhelpful and arguably introduces more 
confusion. I think that sentence should be changed in the abstract to reflect 
that and section 4.4 should be removed. I would not be surprised to hear that 
this DoT text was added precisely to address some other earlier reviewer's 
opinion to the contrary, but this is what I think.

While we're at it, I think this document *requires* the practice of permitting 
TCP transport; it doesn't simply encourage it. So how about:

OLD:

   This document encourages the practice of permitting DNS messages to
   be carried over TCP on the Internet.  This includes both DNS over
   unencrypted TCP, as well as over an encrypted TLS session.  The
   document also considers the consequences with this form of DNS
   communication and the potential operational issues that can arise
   when this best current practice is not upheld.

NEW:

   The specification of the DNS allows both UDP and TCP to be used 
   as transport protocols for exchanging unencrypted DNS messages.
   However, for various reasons, the availability of TCP transport
   has sometimes been interpreted as being optional.  This document 
   clarifies the need to provide TCP transport for both clients and
   servers and strengthens the requirement of DNS implementations
   to support both.


2.3 EDNS0

RFC 6891 uses the notation EDNS(0), not EDNS0. Since 6891 obsoletes 2671 it 
seems reasonable to adopt its notation. I suggest going all search and replace 
on that.


2.4 Fragmentation and Truncation

The second paragraph does not mention another fundamental problem with 
stateless protocols over IPv6 when datagrams require truncation, which is that 
the requirement in v6 to fragment and resent from the source is not possible 
when the source has not retained any state regarding to the response that was 
just sent. While I had my hands in the patient I also added a small reference 
to tunnel encaps in IPv4.

OLD:

   For IPv4-connected hosts, the de-facto MTU is often the Ethernet
   payload size of 1500 bytes.  This means that the largest unfragmented
   UDP DNS message that can be sent over IPv4 is likely 1472 bytes.  For
   IPv6, the situation is a little more complicated.  First, IPv6
   headers are 40 bytes (versus 20 without options in IPv4).  Second, it
   seems as though some people have mis-interpreted IPv6's required
   minimum MTU of 1280 as a required maximum.  Third, fragmentation in
   IPv6 can only be done by the host originating the datagram.  The need
   to fragment is conveyed in an ICMPv6 "packet too big" message.  The
   originating host indicates a fragmented datagram with IPv6 extension
   headers.  Unfortunately, it is quite common for both ICMPv6 and IPv6
   extension headers to be blocked by middleboxes.  According to
   [HUSTON] some 35% of IPv6-capable recursive resolvers were unable to
   receive a fragmented IPv6 packet.

NEW:

   For IPv4-connected hosts, the MTU is often the Ethernet payload
   size of 1500 bytes.  This means that the largest unfragmented
   UDP DNS message that can be sent over IPv4 is likely 1472 bytes,
   although tunnel encapsulation may reduce that maximum message
   size in some cases.

   For IPv6, the situation is a little more complicated.  First,
   IPv6 headers are 40 bytes (versus 20 without options in IPv4).
   Second, it seems as though some people have mis-interpreted
   IPv6's required minimum MTU of 1280 as a required maximum.  Third,
   fragmentation in IPv6 can only be done by the host originating
   the datagram.  The need to fragment is conveyed in an ICMPv6
   "packet too big" message.  The originating host indicates a
   fragmented datagram with IPv6 extension 

Re: [DNSOP] WGLC for draft-ietf-dnsop-tcp-requirements

[George Michaelson]

It's time to ship. I mean sure, if somebody who does detailed reading
has a killer problem I can see we'd talk it out but we're 7 revisions
in, its 4 years later, and it seems rational to document the
expectation this is modern DNS, and we do TCP as a MUST SUPPORT, Auth
and recursive.

Its overdue.

so +1 to ship

-G

On Mon, Apr 19, 2021 at 9:17 AM Suzanne Woolf  wrote:
>
> Dear colleagues,
>
>
> This message starts the Working Group Last Call for 
> draft-ietf-dnsop-tcp-requirements 
> (https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/)
>
> Since this draft has not been recently discussed in the WG, we figure people 
> might need to swap it back in, and we’re requesting BCP status. So the WGLC 
> will end in three weeks (instead of the usual two), on 3 May.
>
> Substantive comments to the list, please. It’s fine for minor edits to go 
> direct to the authors.
>
> We’d like to advance this but it needs some active support, so we need to 
> hear from folks who have found it useful, especially implementers.
>
>
> Thanks,
> Suzanne
> For the chairs
>
> ___
> 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] WGLC for draft-ietf-dnsop-tcp-requirements

[Suzanne Woolf]

Dear colleagues,


This message starts the Working Group Last Call for 
draft-ietf-dnsop-tcp-requirements 
(https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/ 
)

Since this draft has not been recently discussed in the WG, we figure people 
might need to swap it back in, and we’re requesting BCP status. So the WGLC 
will end in three weeks (instead of the usual two), on 3 May.

Substantive comments to the list, please. It’s fine for minor edits to go 
direct to the authors.

We’d like to advance this but it needs some active support, so we need to hear 
from folks who have found it useful, especially implementers.


Thanks,
Suzanne
For the chairs

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

Re: [DNSOP] WGLC for draft-ietf-dnsop-tcp-requirements

[Suzanne Woolf]

Hi,

I was reminded off-list that Warren is not in fact an author on this document— 
apologies for a bad cut-and-paste from the last WGLC I ran.

Warren is handling tcp-requirements as our AD, as usual.


Best,
Suzanne
(My mistake alone, co-chairs are blame-free!)

> On Jan 12, 2020, at 12:38 PM, Suzanne Woolf  wrote:
> 
> Dear colleagues,
> 
> 
> This message starts the Working Group Last Call for 
> draft-ietf-dnsop-tcp-requirements 
> (https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/ 
> )
> 
> Since this draft has not been recently discussed in the WG, we figure people 
> might need to swap it back in, and we’re requesting BCP status. So the WGLC 
> will end in three weeks (instead of the usual two), on 2 February. We will 
> have agenda time in Vancouver, if needed, to go over any open issues.
> 
> Our AD (Warren Kumari) is an author on this document, so we’ll be following 
> the IETF convention that he won’t be shepherding it in the IESG. His co-AD, 
> Barry Leiba, will shepherd it
> 
> Substantive comments to the list, please. It’s fine for minor edits to go 
> direct to the authors.
> 
> 
> Best,
> Suzanne
> (For the chairs)

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

[DNSOP] WGLC for draft-ietf-dnsop-tcp-requirements

[Suzanne Woolf]

Dear colleagues,


This message starts the Working Group Last Call for 
draft-ietf-dnsop-tcp-requirements 
(https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/ 
)

Since this draft has not been recently discussed in the WG, we figure people 
might need to swap it back in, and we’re requesting BCP status. So the WGLC 
will end in three weeks (instead of the usual two), on 2 February. We will have 
agenda time in Vancouver, if needed, to go over any open issues.

Our AD (Warren Kumari) is an author on this document, so we’ll be following the 
IETF convention that he won’t be shepherding it in the IESG. His co-AD, Barry 
Leiba, will shepherd it

Substantive comments to the list, please. It’s fine for minor edits to go 
direct to the authors.


Best,
Suzanne
(For the chairs)___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop