Re: [DNSOP] [dns-privacy] [Doh] New: draft-bertola-bcp-doh-clients
All, I am saying this with my dprive WG chair hat on... As Eliot points out, this conversation has deteriorated beyond repair. I will now politely ask that these non-technical discussions cease on the dprive mailing list. I would recommend that everyone document their concerns with DoH and bring them to the side meeting being proposed by Stephane. Regards, Brian On 3/13/19 1:04 AM, Eliot Lear wrote: > Gentlemen, > > This conversation has gone to the zoo. What is or is not political doesn’t > matter at this stage in the game, and neither is arguing over rights over > bits. If people want to do that I suggest doing so in the HRPC WG and with a > draft in hand. Flaming back and forth without an objective of actually > modifying text or developing a work proposal is quite pointless. > > What is important is to document the technical ramifications of the changes > brought about by DoH. To move things forward, can we simply go through the > drafts in the side meeting, and indicate what administrators might do about > any perceived negative effects? Whether those effects seem negative to you > only matters if there is a proposal for the IETF to take on new work to > “correct” them. > > Eliot > >> On 13 Mar 2019, at 03:59, Christian Huitema wrote: >> >> >> >> On 3/12/2019 2:11 PM, Paul Vixie wrote: I don't see why, based on your argument, your concerns trump his. Can you explain? >>> he's trying to achieve a political aim using technology. that is not the >>> purpose for which the internet engineering task force, or the internet >>> itself, >>> was convened. it is not why our employers pay our travel costs. and it is >>> not >>> why the rest of the world trusts our outputs. >> >> Sorry, but no. I am vying for network transparency, and I believe that if >> filtering is to be enforced, it should be controlled by the user. You are >> claiming that safety mandates giving the network operator full control over >> name resolution. Both of these positions come from specific visions about >> how the network should work. Neither is more a political goal than the other. >> >> -- Christian Huitema >> >> ___ >> Doh mailing list >> d...@ietf.org >> https://www.ietf.org/mailman/listinfo/doh > > > > ___ > dns-privacy mailing list > dns-priv...@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy > signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Brian Haberman's No Objection on draft-ietf-dnsop-onion-tld-00: (with COMMENT)
Brian Haberman has entered the following ballot position for draft-ietf-dnsop-onion-tld-00: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-onion-tld/ -- COMMENT: -- I agree with Stephen's points that the long debate has utility and that there were some proposed text changes that appear to be missing. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Jari Arkko's No Record on draft-ietf-dnsop-onion-tld-00: (with COMMENT)
Hi Jari, On 9/2/15 4:09 PM, Jari Arkko wrote: > Jari Arkko has entered the following ballot position for > draft-ietf-dnsop-onion-tld-00: No Record > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-onion-tld/ > > > > -- > COMMENT: > -- > > The two last references need to be normative ones, I believe. I would > like to suggest a note to the IETF list (if not already happened) that > this is being changed (alongside with any down ref implications) and only > then approving the document. > *If* we make this change (I am not sure we need to), I don't think there are any down ref implications. The two Tor documents do not have any track associated with them. Brian signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Brian Haberman's No Record on draft-ietf-dnsop-root-loopback-04: (with COMMENT)
Brian Haberman has entered the following ballot position for draft-ietf-dnsop-root-loopback-04: No Record When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-root-loopback/ -- COMMENT: -- I can't decide if I should ballot Yes because this document does a good job of describing how to deploy this approach or Abstain because the fragility introduced in this approach appears to be untenable. In the meantime, can someone explain why this document is stating a requirement to deploy this approach with IPv4 only? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Brian Haberman's No Record on draft-ietf-dnsop-root-loopback-04: (with COMMENT)
Hi Paul, On 9/30/15 10:54 AM, Paul Hoffman wrote: > On 30 Sep 2015, at 6:53, Brian Haberman wrote: > >> -- >> COMMENT: >> -- >> >> I can't decide if I should ballot Yes because this document does a good >> job of describing how to deploy this approach or Abstain because the >> fragility introduced in this approach appears to be untenable. >> >> In the meantime, can someone explain why this document is stating a >> requirement to deploy this approach with IPv4 only? > > Yes. Given that this is running on loopback, it doesn't matter if the > service is running on either the v4 or v6 loopback address. Unless a > system running this service has absolutely no v4 at all (it doesn't even > need to be offering v4 service to customers), the v4 loopback address is > sufficient. > > There seems to be wide disagreement about what is the v6 loopback > address: some of these addresses exist on some v6 systems but not > others, or so we were told. If there is a v6 loopback address that is > universally deployed (as 127/8 is for v4), we can add it, although it > won't actually make this more deployable. > > --Paul Hoffman I am not sure how much clearer the definition of IPv6 loopback could be (https://tools.ietf.org/html/rfc4291#section-2.5.3). Of course, if it is an implementation issue, there is not much the IETF can do. Thanks for the quick response. Regards, Brian signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Brian Haberman's No Record on draft-ietf-dnsop-root-loopback-04: (with COMMENT)
Hi Paul, On 9/30/15 11:18 AM, Paul Hoffman wrote: > On 30 Sep 2015, at 8:12, Brian Haberman wrote: > >>>> -- >>>> COMMENT: >>>> -- >>>> >>>> I can't decide if I should ballot Yes because this document does a good >>>> job of describing how to deploy this approach or Abstain because the >>>> fragility introduced in this approach appears to be untenable. >>>> >>>> In the meantime, can someone explain why this document is stating a >>>> requirement to deploy this approach with IPv4 only? >>> >>> Yes. Given that this is running on loopback, it doesn't matter if the >>> service is running on either the v4 or v6 loopback address. Unless a >>> system running this service has absolutely no v4 at all (it doesn't even >>> need to be offering v4 service to customers), the v4 loopback address is >>> sufficient. >>> >>> There seems to be wide disagreement about what is the v6 loopback >>> address: some of these addresses exist on some v6 systems but not >>> others, or so we were told. If there is a v6 loopback address that is >>> universally deployed (as 127/8 is for v4), we can add it, although it >>> won't actually make this more deployable. >>> >>> --Paul Hoffman >> >> I am not sure how much clearer the definition of IPv6 loopback could be >> (https://tools.ietf.org/html/rfc4291#section-2.5.3). Of course, if it >> is an implementation issue, there is not much the IETF can do. >> >> Thanks for the quick response. > > If the WG agrees that 0:0:0:0:0:0:0:1 is always present, we can > certainly add that to the document. I now cannot find any on-list > mention of why this isn't useful in all v6-capable systems, so it might > have been a hallway conversation. It seems like the WG can cover both address families by simply making these changes: OLD: o The system MUST be able to run an authoritative server on one of the IPv4 loopback addresses (that is, an address in the range 127/8). NEW: o The system MUST be able to run an authoritative server on one of the loopback addresses (that is, an address in the range 127/8 for IPv4 or ::1 in IPv6). OLD: 2. Start the authoritative server with the root zone on a loopback address that is not in use. This would typically be 127.0.0.1, but if that address is in use, any address in 127/8 is acceptable. NEW: 2. Start the authoritative server with the root zone on a loopback address. This would typically be 127.0.0.1 in IPv4 or ::1 in IPv6. Why does the document say that the address should not be in use? Brian signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Brian Haberman's Yes on draft-ietf-dnsop-root-loopback-04: (with COMMENT)
Brian Haberman has entered the following ballot position for draft-ietf-dnsop-root-loopback-04: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-root-loopback/ -- COMMENT: -- Thanks for writing a clear document that describes the approach and the potential pitfalls. As I noted earlier, I think this approach is untenable given the fragility it will introduce. Any chance we will see a management item in the near future marking the resulting RFC Obsolete? -- old comments below -- I can't decide if I should ballot Yes because this document does a good job of describing how to deploy this approach or Abstain because the fragility introduced in this approach appears to be untenable. In the meantime, can someone explain why this document is stating a requirement to deploy this approach with IPv4 only? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Brian Haberman's Discuss on draft-ietf-dnsop-edns-tcp-keepalive-04: (with DISCUSS)
Brian Haberman has entered the following ballot position for draft-ietf-dnsop-edns-tcp-keepalive-04: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-tcp-keepalive/ -- DISCUSS: -- I support the publication of this document, but I have a point I want to discuss to help with the clarity of the spec. Section 3.2.1 says that clients send this option with the first query sent on a TCP connection and Section 3.2.2 says it should honor the timeout provided by the server and close the socket when appropriate. What is not discussed is how the client should manage the timer with respect to the reception of multiple query responses that may, or may not, include edns-tcp-keepalive option. Section 3.3.2 says the server MAY send the option, so it is up to the server to decide when to include the option and the corresponding timeout value. Should the client's timer simply reflect the value sent in the latest response? The smallest remaining time? I think a few sentences on client timer management would be beneficial. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Brian Haberman's Discuss on draft-ietf-dnsop-edns-tcp-keepalive-04: (with DISCUSS)
Hi Sara, On 1/5/16 12:08 PM, Sara Dickinson wrote: > >> On 4 Jan 2016, at 18:18, Brian Haberman >> wrote: >> >> -- >> >> DISCUSS: >> -- >> >> >> I support the publication of this document, but I have a point I want to >> discuss to help with the clarity of the spec. >> >> Section 3.2.1 says that clients send this option with the first >> query sent on a TCP connection and Section 3.2.2 says it should >> honor the timeout provided by the server and close the socket when >> appropriate. What is not discussed is how the client should manage >> the timer with respect to the reception of multiple query responses >> that may, or may not, include edns-tcp-keepalive option. Section >> 3.3.2 says the server MAY send the option, so it is up to the >> server to decide when to include the option and the corresponding >> timeout value. Should the client's timer simply reflect the value >> sent in the latest response? The smallest remaining time? >> >> I think a few sentences on client timer management would be >> beneficial. > > Hi, > > Thanks for the feedback. The intention in section 3.2.2 was that the > client should update the timeout whenever receiving a new value in > any response. Would it be enough to clarify by changing the last > sentence in the second paragraph to: > > “It SHOULD honour the timeout received in that response (overriding > any previous timeout) and initiate close of the connection before the > timeout expires.” Yes, the above would make it clearer on how the client manages the timeout value. I will clear the DISCUSS based on the proposed change above. On an unrelated note, why is the inclusion of this option, when supported, only a MAY in 3.3.2? I would think that if the option is supported and enabled, its inclusion would be a SHOULD. Regards, Brian signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Brian Haberman's No Objection on draft-ietf-dnsop-edns-tcp-keepalive-04: (with COMMENT)
Brian Haberman has entered the following ballot position for draft-ietf-dnsop-edns-tcp-keepalive-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-tcp-keepalive/ -- COMMENT: -- Thanks for the quick resolution to my DISCUSS point. The proposed change is recorded below for posterity. OLD: It SHOULD honour the timeout and initiate close of the connection before the timeout expires. NEW: It SHOULD honour the timeout received in that response (overriding any previous timeout) and initiate close of the connection before the timeout expires. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Brian Haberman's Yes on draft-ietf-dnsop-5966bis-05: (with COMMENT)
Brian Haberman has entered the following ballot position for draft-ietf-dnsop-5966bis-05: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-5966bis/ -- COMMENT: -- While I am not a fan of standards-track requirements documents, I understand the history of 5966 and support the publication of this document. I do have a couple of comments for your consideration. 1. Is it worth mentioning in the Intro that another drive towards more TCP-based DNS exchanges may be the desire to re-use existing security associations for DNS privacy solutions? 2. Is there a reference to back up the statement "However, transport of UDP packets that exceed the size of the path MTU causes IP packet fragmentation, which has been found to be unreliable in many circumstances."? It would be good to be able to gauge just how unreliable this issue has become. 3. I agree with Martin's suggested re-wording in Section 8. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Alvaro Retana's Discuss on draft-ietf-dnsop-5966bis-05: (with DISCUSS)
Hi Allison, On 1/7/16 2:26 PM, Mankin, Allison wrote: > Alvaro, > > Thanks for the update! I did quickly learn my error on this. It shows > how we skim familiar things like Last Calls - I had expected it was PS and > I didn¹t see the IS designation there at all. > > I wasn¹t able to be on the Webex for the telechat today. > > What happens now? A two week PS Last Call? (a question for JoelŠ) As an AD (at least for the next 3 months), I don't think we need a new LC. Rather, we can fix the meta data, announce the fix to the community, and continue processing the document. Brian > > Onward and upward, > > Allison > > On 1/7/16, 2:19 PM, "Alvaro Retana (aretana)" wrote: > >> On 1/6/16, 11:55 AM, "Mankin, Allison" wrote: >> >> Allison: >> >> Hi! >> >>> I think you've found an XML editing bug on our part. >> >> No, actually the problem is not in the document, but in how the "Intended >> RFC Status" was set on the datatracker page: >> https://datatracker.ietf.org/doc/draft-ietf-dnsop-5966bis/ >> >> Alvaro. >> signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Brian Haberman's Yes on draft-ietf-dnsop-edns-chain-query-06: (with COMMENT)
Brian Haberman has entered the following ballot position for draft-ietf-dnsop-edns-chain-query-06: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-chain-query/ -- COMMENT: -- Modulo the missing privacy issues in section 8, I support the publication of this document and the resulting experimentation to reduce the latency of DNSSEC validation. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
