I have re-reviewed this document now that Bob passed it on to me for submission to IESG and IETF level reviews.

I found three remaining issues:

1) RFC 1035 should be moved to be a normative reference.

2) The encoding of DNS search lists is underspecified:

 Domain Names of DNS Search List
           One or more domain names of DNS search list that MUST
           be encoded in the non-compressed form, using the
           technique described in Section 3.1 of [RFC1035].  The
           size of this field is a multiple of 8 octets.  The
           remaining octets other than the encoding parts for
           the domain names are padded with zeros.
  

This does not specify how multiple domain names can exist in the search list. Do you start start over with another one, as soon as one domain name ends with the zero byte as specified in RFC 1035?

The reference merely talks about encoding a sequence of labels (= one domain name), not sequences of domain names.

3) There's an error in the security considerations section:
However,
   since any valid SEND node can still insert RDNSS and DNSSL options,
   SEND cannot verify who is or is not authorized to send the options.
  
I'm not sure this is correct. SEND does not allow just any SEND node to send RAs; only routers can do that. RFC 3971, Section 6.1.

If you can update the document with regards to these points, please do so.

Jari



--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to