Re: [DNSOP] [Ext] AD Review of draft-ietf-dnsop-rfc8109bis
I'm not a big fan of "whereas" clauses, partially because I'm related to rather large number of lawyers. Does anyone object to the following? Since the priming response is not a referral, root server addresses in the priming response are not considered glue records. Thus, RFC 9471 does not apply to the priming response and root servers are not required to set the TC bit if not all root server addresses fit within message size constraints. There are no requirements on the number of root server addresses that a root server must include in a priming response. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] AD Review of draft-ietf-dnsop-rfc8109bis
Paul, Here is some specific proposed text to address the concern that I raised: Whereas the priming response is not a referral, and whereas root server addresses in the priming response are therefore not considered glue records, RFC 9471 does not apply to the priming response. Root servers are not required to set the TC bit in a priming response if not all root server addresses fit within message size constraints. There are no requirements on the number of root server addresses that a root server must include in a priming response. DW > On Feb 6, 2024, at 1:39 PM, Paul Hoffman wrote: > > Caution: This email originated from outside the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > > I have submitted -03, which covers the issues you raised in your AD review. > Note that Duane and Mark had more to say on the topic of TC from the roots, > but there was no agreement nor specific text proposed. > > --Paul Hoffman > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://secure-web.cisco.com/1U98vDfdUh-VITwB6fwCdeqAzIC9TAvh0PR_dhvmt312mdwsd3QwvIEi-5zkK2xu5FUXbFHbmHJcNnRuHmVo-Jx9ivcmH95-tpEO5qRBER-_VrCnmKhOgfexsfCYyO_ZNUJQFVBawYfduf9BON3TGTLvMpU0Sd5rZ3VrOwCT36kCNdYxsZlsoo1N0zj3wxa6taF1TiJRt2miLLyya4F70bPtuGI4WU5INGMxnDlLyMgKX0cjpJMtvwupkhZD-UTik4mNpuD08puUESib8l0rMhwAnUCz9FfA-rz4dNa-Deqc/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdnsop > smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] AD Review of draft-ietf-dnsop-rfc8109bis
> On 7 Feb 2024, at 09:57, Brian Dickson wrote: > > > > On Thu, Feb 1, 2024 at 12:03 PM Mark Andrews wrote: > There is nothing to prevent us saying that responses to priming queries > SHOULD/MUST set TC if all of the addresses of the root servers won’t fit in > the response or that the root server address should be looked up as if they > are glue in the root zone. The rules in RFC 1034 don’t handle priming queries > well in a number of ways. > > 1) all the addresses should be returned or TC should be set. > 2) the address of the root servers should be looked up as glue in the root > zone if not found elsewhere > 3) the addresses of the root servers should be included as glue in the root > zone if not otherwise there. > > > I just (finally) gave this a second look/thought. > > I think Mark A's assertion/summary isn't quite 100% correct, based on the > following particular details: > - The concept of a DNS zone (from classic 103[345] RFCs) is a contiguous > portion of the DNS tree. > - The root server names are underneath 'root-servers.net'. > - There is a delegation to 'net' from the root zone. > - The servers themselves (as identified by their IP addresses) are > authoritative for both '.' (root zone) and 'root-servers.net' > - Thus, it is NOT the case that responses from the "root servers" to queries > don't require the TC bit to be set if the entire set of authoritative A/ > records does not fit in the Additional section. > - A careful parsing/analysis would suggest instead, that the A/ records > are in fact in-bailiwick (or whatever we call it these days) from the > 'root-servers.net' zone. > - As such, if the entire set of A/ records does not fit, there are two > alternative approaches: > - Set TC > - Add a referral to the 'net' zone with its glue (not 100% sure this is > correct, but that's what I think would need to happen to satisfy > resolvability of the NS names to A/ addresses). > > Apologies if my analysis is wrong or the terminology is wrong or the > suggested referral is incorrect... > > Brian RFC 1034 really doesn’t handle "priming queries" well. ‘dig ns . @$rootserver’, in the general case, will not return address records for the servers as they are not part of the data above the bottom of zone cuts. This has always been the case even when the server where known by their original names as they where in delegated name spaces. It just happened to work because the implementations where buggy and leaked GLUE or just obscured addresses into ANSWERS rather than only returning GLUE in DELEGATIONS as is specified. This leaking has been cleanup in most implementations. The current work around to get addresses in the additional section, with the Internet's root servers, is to also server root-servers.net but that doesn’t ensure that all the addresses are returned and doesn’t result in TC=1 being set. Applying the same work around to the pre root-servers.net root zone would have required the root servers serving 13(?) other zones to get the address records. Now I think we want the priming response to indicate when the additional section couldn’t fit the address records in (i.e. set TC=1). It may also be useful for the general NS query case. I also think that we need a mechanism other than serving additional zones to supply the address records (e.g. add addresses records to the root zone for the root and have the root servers retrieve them). Both of these things require protocol CHANGES. Setting TC=1 shouldn’t cause problems for resolvers as they should all be expecting it for any query they make. The root NS RRset could be bigger than 500 bytes and the resolvers should handle that. There may be some broken ones that don’t. Mark > -- > Mark Andrews > > > On 2 Feb 2024, at 06:15, Wessels, Duane > > wrote: > > > > > > > >>> On Jan 31, 2024, at 5:57 PM, Paul Hoffman wrote: > >>> > >>> As Mark just clarified. This isn't glue, so perhaps the text just needs > >>> updating. > >> > >> The current text is: > >> > >> If some root server addresses are omitted from the Additional section, > >> there is no expectation that the TC bit in the > >> response will be set to 1. At the time that this document is written, many > >> of the > >> root servers are not setting the TC bit when omitting addresses from the > >> Additional section. > >> > >> Note that updates > >> with respect to the use of the TC bit. > >> It says "If message size constraints prevent the inclusion of all glue > >> records for in-domain name servers, > >> the server must set the TC (Truncated) flag to inform the client that the > >> response is incomplete > >> and that the client should use another transport to retrieve the full > >> response." > >> > >> Maybe we should add to the second paragraph: > >> > >> Note, however, the root server addresses are not glue records, so setting > >> the TC bit in truncated responses from > >> the root
Re: [DNSOP] [Ext] AD Review of draft-ietf-dnsop-rfc8109bis
A note to those with opinions about what the root server operators (RSOs) should do: the draft authors would like the eventual RFC to be accurate, not aspirational. The RSOs are free to implement and deploy what they want within their own internal rules that are not covered in this document. Nothing in this document should be read to indicate what an RSO should do; if any text does, it is an error that we should correct (please send text diffs). --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] AD Review of draft-ietf-dnsop-rfc8109bis
On Thu, Feb 1, 2024 at 12:03 PM Mark Andrews wrote: > There is nothing to prevent us saying that responses to priming queries > SHOULD/MUST set TC if all of the addresses of the root servers won’t fit in > the response or that the root server address should be looked up as if they > are glue in the root zone. The rules in RFC 1034 don’t handle priming > queries well in a number of ways. > > 1) all the addresses should be returned or TC should be set. > 2) the address of the root servers should be looked up as glue in the root > zone if not found elsewhere > 3) the addresses of the root servers should be included as glue in the > root zone if not otherwise there. > > I just (finally) gave this a second look/thought. I think Mark A's assertion/summary isn't quite 100% correct, based on the following particular details: - The concept of a DNS zone (from classic 103[345] RFCs) is a contiguous portion of the DNS tree. - The root server names are underneath 'root-servers.net'. - There is a delegation to 'net' from the root zone. - The servers themselves (as identified by their IP addresses) are authoritative for both '.' (root zone) and 'root-servers.net' - Thus, it is NOT the case that responses from the "root servers" to queries don't require the TC bit to be set if the entire set of authoritative A/ records does not fit in the Additional section. - A careful parsing/analysis would suggest instead, that the A/ records are in fact in-bailiwick (or whatever we call it these days) from the ' root-servers.net' zone. - As such, if the entire set of A/ records does not fit, there are two alternative approaches: - Set TC - Add a referral to the 'net' zone with its glue (not 100% sure this is correct, but that's what I think would need to happen to satisfy resolvability of the NS names to A/ addresses). Apologies if my analysis is wrong or the terminology is wrong or the suggested referral is incorrect... Brian > -- > Mark Andrews > > > On 2 Feb 2024, at 06:15, Wessels, Duane 40verisign@dmarc.ietf.org> wrote: > > > > > > > >>> On Jan 31, 2024, at 5:57 PM, Paul Hoffman > wrote: > >>> > >>> As Mark just clarified. This isn't glue, so perhaps the text just needs > >>> updating. > >> > >> The current text is: > >> > >> If some root server addresses are omitted from the Additional > section, there is no expectation that the TC bit in the > >> response will be set to 1. At the time that this document is written, > many of the > >> root servers are not setting the TC bit when omitting addresses from > the Additional section. > >> > >> Note that updates > with respect to the use of the TC bit. > >> It says "If message size constraints prevent the inclusion of all glue > records for in-domain name servers, > >> the server must set the TC (Truncated) flag to inform the client that > the response is incomplete > >> and that the client should use another transport to retrieve the full > response." > >> > >> Maybe we should add to the second paragraph: > >> > >> Note, however, the root server addresses are not glue records, so > setting the TC bit in truncated responses from > >> the root servers is not required by RFC 9471. > >> > >> Does this solve your and Warren's issues? > > > > > > I have to confess that “root server addresses are not glue records” is a > very subtle point that was lost on me, and > > maybe lost on a lot of us, as evidenced by this discussion. > > > > I’m not particularly comfortable with the terseness of the statement > above. The terminology RFC doesn’t really help here because it doesn’t > provide a definition of what glue is glue or what is not glue. It just > references semi-conflicting statements in other RFCs. > > > > So I think if 8109bis is going to make the statement that root server > addresses are not glue, it deserves more explanation of why that is the > case. > > > > I also worry that it creates a new problem, which is what sort of > truncation policy applies to a priming response? If RFC 9471 does not > apply, does RFC 2181 Section 9 apply? Is a priming response with zero root > server IP addresses acceptable? > > > > DW > > > > > > ___ > > 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 mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] AD Review of draft-ietf-dnsop-rfc8109bis
I have submitted -03, which covers the issues you raised in your AD review. Note that Duane and Mark had more to say on the topic of TC from the roots, but there was no agreement nor specific text proposed. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] AD Review of draft-ietf-dnsop-rfc8109bis
There is nothing to prevent us saying that responses to priming queries SHOULD/MUST set TC if all of the addresses of the root servers won’t fit in the response or that the root server address should be looked up as if they are glue in the root zone. The rules in RFC 1034 don’t handle priming queries well in a number of ways. 1) all the addresses should be returned or TC should be set. 2) the address of the root servers should be looked up as glue in the root zone if not found elsewhere 3) the addresses of the root servers should be included as glue in the root zone if not otherwise there. -- Mark Andrews > On 2 Feb 2024, at 06:15, Wessels, Duane > wrote: > > > >>> On Jan 31, 2024, at 5:57 PM, Paul Hoffman wrote: >>> >>> As Mark just clarified. This isn't glue, so perhaps the text just needs >>> updating. >> >> The current text is: >> >> If some root server addresses are omitted from the Additional section, >> there is no expectation that the TC bit in the >> response will be set to 1. At the time that this document is written, many >> of the >> root servers are not setting the TC bit when omitting addresses from the >> Additional section. >> >> Note that updates with >> respect to the use of the TC bit. >> It says "If message size constraints prevent the inclusion of all glue >> records for in-domain name servers, >> the server must set the TC (Truncated) flag to inform the client that the >> response is incomplete >> and that the client should use another transport to retrieve the full >> response." >> >> Maybe we should add to the second paragraph: >> >> Note, however, the root server addresses are not glue records, so setting >> the TC bit in truncated responses from >> the root servers is not required by RFC 9471. >> >> Does this solve your and Warren's issues? > > > I have to confess that “root server addresses are not glue records” is a very > subtle point that was lost on me, and > maybe lost on a lot of us, as evidenced by this discussion. > > I’m not particularly comfortable with the terseness of the statement above. > The terminology RFC doesn’t really help here because it doesn’t provide a > definition of what glue is glue or what is not glue. It just references > semi-conflicting statements in other RFCs. > > So I think if 8109bis is going to make the statement that root server > addresses are not glue, it deserves more explanation of why that is the case. > > I also worry that it creates a new problem, which is what sort of truncation > policy applies to a priming response? If RFC 9471 does not apply, does RFC > 2181 Section 9 apply? Is a priming response with zero root server IP > addresses acceptable? > > DW > > > ___ > 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] [Ext] AD Review of draft-ietf-dnsop-rfc8109bis
> On Jan 31, 2024, at 5:57 PM, Paul Hoffman wrote: > >> As Mark just clarified. This isn't glue, so perhaps the text just needs >> updating. > > The current text is: > > If some root server addresses are omitted from the Additional section, > there is no expectation that the TC bit in the > response will be set to 1. At the time that this document is written, many of > the > root servers are not setting the TC bit when omitting addresses from the > Additional section. > > Note that updates with > respect to the use of the TC bit. > It says "If message size constraints prevent the inclusion of all glue > records for in-domain name servers, > the server must set the TC (Truncated) flag to inform the client that the > response is incomplete > and that the client should use another transport to retrieve the full > response." > > Maybe we should add to the second paragraph: > > Note, however, the root server addresses are not glue records, so setting the > TC bit in truncated responses from > the root servers is not required by RFC 9471. > > Does this solve your and Warren's issues? I have to confess that “root server addresses are not glue records” is a very subtle point that was lost on me, and maybe lost on a lot of us, as evidenced by this discussion. I’m not particularly comfortable with the terseness of the statement above. The terminology RFC doesn’t really help here because it doesn’t provide a definition of what glue is glue or what is not glue. It just references semi-conflicting statements in other RFCs. So I think if 8109bis is going to make the statement that root server addresses are not glue, it deserves more explanation of why that is the case. I also worry that it creates a new problem, which is what sort of truncation policy applies to a priming response? If RFC 9471 does not apply, does RFC 2181 Section 9 apply? Is a priming response with zero root server IP addresses acceptable? DW smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] AD Review of draft-ietf-dnsop-rfc8109bis
On Wed, Jan 31, 2024 at 8:57 PM, Paul Hoffman wrote: > On Jan 31, 2024, at 17:39, Paul Wouters wrote: > > On Wed, 31 Jan 2024, Paul Hoffman wrote: > > On Jan 31, 2024, at 15:15, Paul Wouters wrote: > > Can they write a draft with why they are going against the RFC? > > Yes, that is possible. However, I think it would be unfair to the DNS > community to hold up draft-ietf-dnsop-rfc8109bis waiting for that to > happen, and it would be a bad policy to make draft-ietf-dnsop-rfc8109bis > less honest about the current and possible future waiting for that to > happen. > > As Mark just clarified. This isn't glue, so perhaps the text just needs > updating. > > The current text is: > > If some root server addresses are omitted from the Additional section, > there is no expectation that the TC bit in the response will be set to 1. > At the time that this document is written, many of the root servers are not > setting the TC bit when omitting addresses from the Additional section. > > Note that updates > with respect to the use of the TC bit. It says "If message size constraints > prevent the inclusion of all glue records for in-domain name servers, the > server must set the TC (Truncated) flag to inform the client that the > response is incomplete and that the client should use another transport to > retrieve the full response." > > Maybe we should add to the second paragraph: > > Note, however, the root server addresses are not glue records, so setting > the TC bit in truncated responses from the root servers is not required by > RFC 9471. > > Does this solve your and Warren's issues? > Oh. Erm… yes! That's a short, simple and elegant solution, and works for me…. I was expecting this to require much more text changes, but this works. Nice! > It raises another question why some root servers do set the TC bit though. > > If I read 1035 correctly, it specified the TC bit for all truncation, not > just for truncated glue records. > Yup. RFC9471 updates RFC1034 to say: "NEW: | Copy the NS RRs for the subzone into the authority section of the | reply. Put whatever NS addresses are available into the | additional section, using glue RRs if the addresses are not | available from authoritative data or the cache. If all glue RRs | for in-domain name servers do not fit, set TC=1 in the header. Go | to step 4. " This says that all glue has to fit before setting TC. I personally still think of "TrunCation" as meaning what the English word means: 1. shorten the duration or extent of. 2. shorten by cutting off the top or end. 3. (botany) (of a leaf, feather, or other part) ending abruptly as if cut off across the base or tip. Or as it said in 1035: "TC TrunCation - specifies that this message was truncated due to length greater than that permitted on the transmission channel." … but I understand that I can be in the rough…. Whatever the case, it seems like there is some confusion / lack of agreement on what all RFC9471 means… W > --Paul Hoffman > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] AD Review of draft-ietf-dnsop-rfc8109bis
On Thu, 1 Feb 2024, Paul Hoffman wrote: Maybe we should add to the second paragraph: Note, however, the root server addresses are not glue records, so setting the TC bit in truncated responses from the root servers is not required by RFC 9471. Does this solve your and Warren's issues? Works for me, thanks! Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] AD Review of draft-ietf-dnsop-rfc8109bis
On Jan 31, 2024, at 17:39, Paul Wouters wrote: > > On Wed, 31 Jan 2024, Paul Hoffman wrote: > >> On Jan 31, 2024, at 15:15, Paul Wouters wrote: >>> Can they write a draft with why they are going against the RFC? >> >> Yes, that is possible. However, I think it would be unfair to the DNS >> community to hold up draft-ietf-dnsop-rfc8109bis waiting for that to happen, >> and it would be a bad policy to make draft-ietf-dnsop-rfc8109bis less honest >> about the current and possible future waiting for that to happen. > > As Mark just clarified. This isn't glue, so perhaps the text just needs > updating. The current text is: If some root server addresses are omitted from the Additional section, there is no expectation that the TC bit in the response will be set to 1. At the time that this document is written, many of the root servers are not setting the TC bit when omitting addresses from the Additional section. Note that updates with respect to the use of the TC bit. It says "If message size constraints prevent the inclusion of all glue records for in-domain name servers, the server must set the TC (Truncated) flag to inform the client that the response is incomplete and that the client should use another transport to retrieve the full response." Maybe we should add to the second paragraph: Note, however, the root server addresses are not glue records, so setting the TC bit in truncated responses from the root servers is not required by RFC 9471. Does this solve your and Warren's issues? > It raises another question why some root servers do set the TC > bit though. If I read 1035 correctly, it specified the TC bit for all truncation, not just for truncated glue records. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] AD Review of draft-ietf-dnsop-rfc8109bis
On Wed, 31 Jan 2024, Paul Hoffman wrote: On Jan 31, 2024, at 15:15, Paul Wouters wrote: Can they write a draft with why they are going against the RFC? Yes, that is possible. However, I think it would be unfair to the DNS community to hold up draft-ietf-dnsop-rfc8109bis waiting for that to happen, and it would be a bad policy to make draft-ietf-dnsop-rfc8109bis less honest about the current and possible future waiting for that to happen. As Mark just clarified. This isn't glue, so perhaps the text just needs updating. It raises another question why some root servers do set the TC bit though. It seems more that the DNS protocols are unclear and not that root-server operators are purposefully going against an RFC. So that's the good news :) Paul W. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] AD Review of draft-ietf-dnsop-rfc8109bis
On Jan 31, 2024, at 15:15, Paul Wouters wrote: > Can they write a draft with why they are going against the RFC? Yes, that is possible. However, I think it would be unfair to the DNS community to hold up draft-ietf-dnsop-rfc8109bis waiting for that to happen, and it would be a bad policy to make draft-ietf-dnsop-rfc8109bis less honest about the current and possible future waiting for that to happen. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] AD Review of draft-ietf-dnsop-rfc8109bis
On Wed, 31 Jan 2024, Paul Hoffman wrote: Nope. The tone is because some root server operators want the ability to continue to not set the TC bit due to root server operational independence. We have to be honest about what is happening, and what the rules are. The rules are defined in the RFCs for the DNS protocol? If some root server operation is concerned about this, where were they during discussions on RFC 9471 ? Can they write a draft with why they are going against the RFC? Paul W ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] AD Review of draft-ietf-dnsop-rfc8109bis
On Jan 31, 2024, at 11:38, Warren Kumari wrote: > > Hi there, authors (and WG), > > Thank you for this document — I have some questions / comments before I can > progress it. > > Firstly, the (presumably) easy one: > The document says: > "This document, when published, obsoletes RFC 8109." - can you add something > along the lines of "Section 1.1 contains a list of changes from RFC 8109" or > similar…. Sure. > > Now the harder one… > Sec 4.2: > "If some root server addresses are omitted from the Additional section, there > is no expectation that the TC bit in the response will be set to 1. At the > time that this document is written, many of the root servers are not setting > the TC bit when omitting addresses from the Additional section. > > Note that [RFC9471] updates [RFC1035] with respect to the use of the TC bit. > It says "If message size constraints prevent the inclusion of all glue > records for in-domain name servers, the server must set the TC (Truncated) > flag to inform the client that the response is incomplete and that the client > should use another transport to retrieve the full response." " > > IMO, this text is confusing…. > It sounds like it is saying "RFC9471 says you must set TC if you truncate the > glue. The root server folk are ignoring RFC9471, bad root server folk…" > > I have read the discussion in the WGLC ( inc > https://mailarchive.ietf.org/arch/msg/dnsop/wtjuoVqkKmww988Hyq2QDq_nKpA/ and > am assuming it was rewritten as "If some root server addresses are omitted > from the Additional section…".), but I don't really think that really > addresses my concern — it's easy to miss the subtleties and the "all glue > records" vs "some addresses" bit is tricky. > > It's also true that "At the time that this document is written, many of the > root servers are not setting the TC bit when omitting addresses from the > Additional section." — RFC9471 was only published at the end of September, > there is an open BIND bug to update this behavior (I think! - > https://gitlab.isc.org/isc-projects/bind9/-/issues/4540 ), and is planned to > change in 9.19.x (I think!) > > So, while what it written is all technically correct[0], the tone feels > weird. I think that some of this is because ot the timing of when this and > RFC9471 were written. Nope. The tone is because some root server operators want the ability to continue to not set the TC bit due to root server operational independence. We have to be honest about what is happening, and what the rules are. > RFC8109 was published 7 years ago, and I'm hoping that rfc8109bis will > survive at least that long. Yep, if not longer. > I don't know how we address my concern, but it feels like, in e.g 6 years, > this text will have aged poorly... Or it might still be accurate. We cannot tell ahead of time. > Can you see about some more massaging of this text? Not without suggestions from you or the WG about how to massage while being honest. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
