Stephen Farrell has entered the following ballot position for draft-ietf-dnsop-edns-client-subnet-06: 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-client-subnet/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Section 11.3, I like that we're recommending that ECS be disabled by default, but want to check one thing. This says: "Due to the high cache pressure introduced by ECS, the feature SHOULD be disabled in all default configurations." Does that mean that all servers SHOULD disable this by default or does this only apply to some servers? If the former, it should probably be (re-)stated somewhere early on and more prominently and not only stated far down in the document like this. If the latter, then I think you need to be more precise and I'd like to know why we're not preferring the more privacy friendly option as our default. So I hope your answer is "yeah, all servers and sure we can state that earlier as well" :-) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - abstract: I think it'd be good if the abstract noted that this was documenting a deployed option and not necessarily recommending this as the best thing ever. There's text in the write-up and intro that does that nicely that could work if reduced to one sentence, e.g. maybe something like: "This documents an EDNS0 option that is in active use on the Internet today that is intended to be revised in the near future to improve it's security and privacy features." - Thanks for section 2. - 7.2.2 says "Because a client that did not use an ECS option might not be able to understand it, the server MUST NOT provide one in its response." That seems like a bit of a pity - one comment I was going to make was that it might be good to include this (or something) in a response so that a client that didn't ask for ECS could be informed that some DNS server is doing ECS. Would that actually break things? - section 10 has RFC1918 as a SHOULD but doesn't refer to e.g. RFC6598 at all. RFC6890 has a MAY associated with it, but does refer to 6598. And what about stuff like RFC7534, which isn't mentioned? Is that all correct and up to date? - 11.1, 4th para: "Users" isn't really right. People don't know about any of this stuff really. "Clients" would be more accurate _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
