Subject: AD review of draft-ietf-6man-dns-options-bis

From: Jari Arkko <[email-masked]>
Date: Wed, 09 Jun 2010 12:12:21 -0700

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

---

From: Jaehoon Paul Jeong <[email-masked]>
Date: Wed, 9 Jun 2010 17:11:17 -0500

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-masked] [mailto:[email-masked]] On Behalf Of Jari Arkko
>Sent: Wednesday, June 09, 2010 2:12 PM
>To: [email-masked]; 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.
>

=> RFC 1035 is placed in the normative reference section in 03-version I-D.

>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.
>
>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

--
===========================
Paul (Jaehoon) Jeong
Software Engineer, Ph.D
Brocade
6000 Nathan Ln N, Plymouth, MN 55442
Mobile: +1.651.587.7774
Email: [email-masked]
URI: http://www.cs.umn.edu/~jjeong/

---

From: Jari Arkko <[email-masked]>
Date: Wed, 09 Jun 2010 16:19:13 -0700

Paul,

Thanks for the very quick turnaround on the changes! The changes look
good to me. Please submit the document.

Jari

Jaehoon Paul Jeong kirjoitti:

Hi Jari,

However,

Thanks.
Best Regards,
Paul

Jari