Hi Jari, I reflected your comments with 03-version I-D that will be submitted if you are satisfied with the changes: - 03-version I-D: http://www-users.cs.umn.edu/~jjeong/publications/ietf-internet-draft/draft-ietf-6man-dns-options-bis-03.txt
- Difference between 02-version I-D and 03-version I-D: http://www-users.cs.umn.edu/~jjeong/publications/ietf-internet-draft/wdiff%20draft-ietf-6man-dns-options-bis-02_txt%20draft-ietf-6man-dns-options-bis-03_txt.htm >From: [email protected] [mailto:[email protected]] On Behalf Of Jari >Arkko >Sent: Wednesday, June 09, 2010 2:12 PM >To: [email protected]; IETF IPv6 Mailing List >Subject: AD review of draft-ietf-6man-dns-options-bis > >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. => RFC 1035 is placed in the normative reference section in 03-version I-D. >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 new text is as follows: Domain Names of DNS Search List One or more domain names of DNS search list that MUST be encoded using the technique described in Section 3.1 of [RFC1035]. By this technique, each domain name is represented as a sequence of labels ending in a zero octet, defined as domain name representation. For more than one domain name, the corresponding domain name representations are concatenated as they are. Note that for the simple decoding, the domain names MUST NOT be encoded in a compressed form, as described in Section 4.1.4 of [RFC1035]. Because the size of this field MUST be a multiple of 8 octets, for the minimum multiple including the domain name representations, the remaining octets other than the encoding parts of the domain name representations MUST be padded with zeros. >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. => The new text is proposed as follows: However, since any valid SEND router can still insert RDNSS and DNSSL options, SEND cannot verify which one is or is not authorized to send the options. >If you can update the document with regards to these points, please do so. => If you are comfortable with these changes, I will submit 03-version. Thanks. Best Regards, Paul >Jari -- =========================== Paul (Jaehoon) Jeong Software Engineer, Ph.D Brocade 6000 Nathan Ln N, Plymouth, MN 55442 Mobile: +1.651.587.7774 Email: [email protected] URI: http://www.cs.umn.edu/~jjeong/ -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
