Good idea - future-proofing is great in theory, but it sounds like there's a lot of non-consensus on the DNSOP side that we might end up adding something that is superseded anyway.
Rory From: Patrick McManus [mailto:pmcma...@mozilla.com] Sent: Thursday, April 5, 2018 1:54 PM To: Martin Thomson <martin.thom...@gmail.com> Cc: Ted Lemon <mel...@fugue.com>; dnsop <dnsop@ietf.org>; DoH WG <d...@ietf.org>; Paul Vixie <p...@redbarn.org>; Ray Bellis <r...@bellis.me.uk> Subject: [Doh] re original_transport indicator Hi All, We've had quite a thread re the -05 optional parameter to the dns-udpwireformat registration. The parameter is defined as having no meaning for DoH, but was included to accommodate a use case the dnsop wg is considering. Future proofing, if you like. Upon consideration (and a read of 6838), I think including this in doh is premature because Media Type registrations can be updated by mechanisms laid out in RFC6838 and in this case such an update could occur without impacting existing DoH deployments. (i.e. it does not need to be future proofed). Therefore the definition of the parameter should accompany the work that makes use of it if a future standards document chooses to go down that path. As a bonus we avoid unused clutter if it doesn't happen. I also get the feeling that there isn't yet strong consensus on the anticipated use case or the exact form it needs to take - we should let that process work itself out separately before registration. I've chatted with Paul, and our recommendation is to remove the original_transport parameter from DoH and encourage dnsop to update the registration if/when a different standard needs to make use of it. thoughts? -Patrick
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
