Thanks Alex. Would be better to add a line on the truncation. I shall look back again on the next draft.
From: Alex Mayrhofer [mailto:[email protected]] Sent: Friday, November 6, 2015 03:13 To: [email protected]; Tim Wicinski <[email protected]>; Kumar Ashutosh <[email protected]> Subject: AW: RE: [dns-privacy] Call for Adoption: draft-mayrhofer-edns0-padding Hello Ashu, Thanks for the review - responses as follows: (sorry for the crappy style, this is from mobile) - First point: the keywords here are 'if a Responder detects'... Which means that if it's unaware of the option or elects to not check it, it doesn't need to respond with a FORMERR. But if it does check the option, it MUST respond with an formerr. - Proxies: as far as I understand, EDNS is always hop to hop. So both legs of a proxy could process the option independently. A recursor might want to do padding downstream to stub resolvers, but might not pad upstream to Auth servers. - One option: I believe this is correct, but I'm happy to be learn more? EDNS options can be used several times in a single opt RR record, so thistext restricts the padding option use to a single occurrence. - padding MUST NOT be done if that wounded to truncation. I believe this is stated indirectly in the draft already. Do you feel this should be expressed differently? Thanks again for the review! Alex ---- Kumar Ashutosh schrieb ---- Hi I reviewed the draft and here are a few comments: “The PADDING octects MUST be set to 0x00. If a Responder detects non- 0x00 octects in the padding of a query, a FORMERR (RCODE=1) MUST be returned.” ==> Is MUST necessary here? There might be existing responders that may be agnostic to this and not parse this option code. They may not return Formerr. For quick adoption changing this to SHOULD or providing option to ignore this will be useful. ==> What is the guidance for the proxy systems used in front of DNS servers (load balancer or traffic managers)? Should they be validating this option for correctness or be plain tunnels? ==> What if the packet does not have space to pad? Do we have a Padding option with length 0? Or we truncate messages? The 'Padding' option MUST occur at most once per OPT meta-RR. ==> Is not there only one OPT RR per packet? There can be multiple option IDs but RR is only one. Just checking if the statement above is semantically correct. Also, +1 for approval Thanks Ashu Microsoft From: dns-privacy [mailto:[email protected]] On Behalf Of Alex Mayrhofer Sent: Thursday, November 5, 2015 9:21 AM To: [email protected]<mailto:[email protected]>; Tim WIcinski <[email protected]<mailto:[email protected]>> Subject: Re: [dns-privacy] Call for Adoption: draft-mayrhofer-edns0-padding I've submitted a -00 WG version of the draft, which is now pending WG Chairs approval. Hope I got everything right, since the draft was edited from a phone onboard a ferry with crappy wifi and while coloring a pirates book with a 3yo ;-) Alex ---- Tim Wicinski schrieb ---- During the meeting on Monday, it was obvious the Working Group wanted to make this an official EDNS option. We reached out to the author and while he is traveling for an extended period of time, he is happy to work on edits (with a small delay built in, but nothing this impatient chair finds too onerous). This starts a Call for Adoption fordraft-mayrhofer-edns0-padding The draft is available here: https://datatracker.ietf.org/doc/draft-mayrhofer-edns0-padding<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fdatatracker.ietf.org%2fdoc%2fdraft-mayrhofer-edns0-padding&data=01%7c01%7caskuma%40064d.mgd.microsoft.com%7cbb1a31c363bf4815fe0c08d2e59452e0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=UUwYipRiIk3lqr3B9inboeib9O%2f4UKEZvRqIyOQE5lA%3d>/ Please review this draft to see if you think it is suitable for adoption by DPRIVE, and comments to the list, clearly stating your view. Please also indicate if you are willing to contribute text, review, etc. This call for adoption ends 17 November, 2015 12:00 UTC Thanks, tim wicinski _______________________________________________ dns-privacy mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/dns-privacy<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2fdns-privacy&data=01%7c01%7caskuma%40064d.mgd.microsoft.com%7cbb1a31c363bf4815fe0c08d2e59452e0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=8tnOYM9kthGyTUJgo9FESY64rdDR64UX8f2%2fTDR9Z%2fo%3d>
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
