Brian, Bob, and others Honestly, the authors do not care a lot on this topic and we are all ears. OTOH, the version first version of the draft (still an individual submission) used the 'binary' format (as in RDNSS) and then we receive several negative reviews on this topic: wasting space (as there is no compression when there is a single FQDN) and more complex for the sender/receiver. OTOH, consistency with RFC 8106 would be nice.
-éric On 11/10/17 21:34, "Int-area on behalf of Brian E Carpenter" <[email protected] on behalf of [email protected]> wrote: On 12/10/2017 08:14, Bob Hinden wrote: ... >> btw, I'd note that RFC8106 uses the binary representation of domain >> names for the DNS search list option. I guess the pros and cons on >> text vs binary should be largely the same - an implementation of >> RFC8106 also needs to parse the value and is quite likely to dump it >> in the textual form, and the data length could be a concern as an RA >> option. If we were okay with the binary form in RFC8106, I don't see >> why we aren't for draft-bruneau-intarea-provisioning-domains. > > I agree. Further, I think there would have to a very good reason to do something different that how RFC8106 handles this. Having two different ways to encode DNS info in RA options seems like a very bad idea. + several I recently had occasion to parse some DNS RRs containing non-ASCII bytes, and life would have been so much easier if I'd been given binary instead of escape-coded ASCII. I haven't followed the details, but I do hope that if you stick to ASCII you will use the RFC 1035 convention for escaping non-ASCII bytes. That's what I would expect existing code to support. Brian _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
