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/
