On 14/03/2018 22:07, Paul Wouters wrote:
> While I was initially afraid of abuse of this feature, the document has > addressed this issue very well. So as long as implementors follow the > specification, I think this document poses no privacy risk. > > I'm in favour of adoption. > > Some nits: > > Section 3.1: > > Stub resolvers, client-side proxy devices, and recursive resolvers > MUST NOT add the XPF RR to DNS requests. > > Can this be extended to say what these should do when receiving or > forwarding these?g I think it would suffice to replace "client proxy devices" with "client side proxies or forwarders". > Section 3.2: > > If a server finds this RR anywhere other than in the Additional > Section of a request it MUST return a REFUSED response. > > If the value of the RR's IP version field is not understood by the > server it MUST return a REFUSED response. > > Why return REFUSED instead of FORMERR for these ? That's fair, those are arguably "illegal packets" rather than "policy rejected". There's perhaps also an omission here w.r.t the "Protocol" field which is not mentioned in this context. > Servers MUST NOT send this RR in DNS responses. > > Can this be extended to include "not forward these packets" as well? I don't think that fits here. If the server is being used as a front-end forwarder for a server farm than adding XPF would be appropriate. > Setion 3.4: > > Why SHOULD and not MUST? Can you give an example of when the SHOULD can > be ignored? When the server doesn't implement XPF? I think this wording was there to prevent a charge of imposing retrospective mandates. We could perhaps change that to say that "an XPF-capable server MUST ..." > Section 3.5: > > The XPF RR is formatted like any standard RR, but none of the fields > except RDLENGTH and RDATA have any meaning in this specification. > > If these fields don't matter, can we mandate a setting for these? I > guess we can because you do :) So maybe this text can be omitted or > changed to reflect that? OK, will look at that. > My petpeeve: using +---+---+---+---+---+---+---+ instead of > +---------+-----------+ > I find the overuse of +-+-+ reduces readability. That's one for the WG, I think, on adoption. With sub-octet fields present it makes the size of those fields completely explicit. I also personally find it much more legible than the 32-bits per line using '+-+-...' that e.g. RFC 791 (IP) uses. It may be hard to reach consensus :p > Implementations MUST support IPv4 (4) and IPv6 (6). > > I would not say this. In the happy future where we are mostly/only v6, > we wouldn't want to issue an update to this RFC just to kill this sentence. I appreciate the sentiment, but I think it highly unlikely that the original IPv4 specification will ever be rendered completely historic. If that does ever happen, the RFC that does it can just update this one without requiring a -bis. > Section 3.6: > > This could use an example. OK. > Section 4: > > It could mention DNS-COOKIES as one way to avoid spoofing issues. That sounds like a good idea. thanks for the review! Ray _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
