IPv6 Router Advertisement Options for DNS Configuration
draft-ietf-6man-dns-options-bis-08

[Ballot discuss]
There has been discussion of the Gen-ART Review by Ben Campbell from
  2010-06-21.  There seems to be agreement on the way to resolve the
  concerns that were raised, but a revision has not been posted (yet).

[Ballot comment]
INTRODUCTION, paragraph 4:
>    This document specifies IPv6 Router Advertisement options to allow
>    IPv6 routers to advertise a list of DNS recursive server addresses
>    and a DNS search list to IPv6 hosts.

  Please add one sentence that says that this obsoleted RFC5006 and what
  the differences are.


Section 5.3.2., paragraph 2:
>    Second, if different DNS information is provided on different network
>    interfaces, this can lead to inconsistent behavior.  The IETF is
>    working on solving this problem for both DNS and other information in
>    Multiple Interfaces (MIF) working group.

  RFCs are permanent, and referring to ephemeral WGs will be a bit
  confusing a few years down the road. Suggest to talk about the IETF
  instead and maybe informally refer to some documents from the MIF WG
  by reference.

[Ballot discuss]
I am worried about putting DNS information in the RA while the rogue RA problem is still unsolved. If someone could convince me that SeND solves the rogue RA problem and mandated SeND authentication, I would be glad to clear this discuss.

I think that I am agreeing with Stuart's discuss.

[Ballot discuss]
Should this document (particularly in 5.3.1) say anything about handling values learned via DHCP when the host has more than one interface (specifically, multiple DHCP servers responding which may not be under the same administrative authority)?

[Ballot comment]
The following statement seems arguable at best:

"This is because learning DNS information via the RA options cannot be worse than learning bad router information via the RA options."

[Ballot comment]
1. Same comment as DBH - I do not understand what are the 'certain reasons in network management' mentioned in 6.2 and 6.3 and I would suggest that these are either explained or taken out.

2. I do not believe that the title of the document after approval needs to carry RFC 5006bis as the fact that it obsoletes RFC 5006 will be part of the first page header.

[Ballot comment]
n section 6.2, I do not understand the text "from being used any more for certain reasons in network management,". Can you clarify the reasons and the relation to network management?

[Ballot discuss]
There has been discussion of the Gen-ART Review by Ben Campbell from
  2010-06-21.  There seems to be agreement on the way to resolve the
  concerns that were raised, but a revision has not been posted (yet).

IANA comments:

IANA understands that, upon approval of this document, a single action
is required.

In the IPv6 Neighbor Discovery Option Formats registry located at
http://www.iana.org/assignments/icmpv6-parameters
a single new value is to be registered.

Type: Description: Reference:
------- --------------------------------- ----------------
(TBD) DNSSL Option [RFC-ietf-6man-dns-options-bis-02.txt

AD review:

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

This is the document writeup for advancing the following to Proposed Standard:

Title          : IPv6 Router Advertisement Options for DNS Configuration RFC 5006-bis
Author(s)      : S. Park, et al.
Filename        : draft-ietf-6man-dns-options-bis-02.txt
Pages          : 16
Date            : 2010-05-24

as a Proposed Standard.  A 6MAN working group Last Call completed on June 7, 2010.  The current draft resolves issues raised prior to the last call.

(1.a) Who is the Document Shepherd for this document? Has the
      Document Shepherd personally reviewed this version of the
      document and, in particular, does he or she believe this
      version is ready for forwarding to the IESG for publication?

Bob Hinden is the document shepherd.  I have reviewed the document and believe it is ready for IESG reivew and publication.

(1.b) Has the document had adequate review both from key WG members
      and from key non-WG members? Does the Document Shepherd have
      any concerns about the depth or breadth of the reviews that
      have been performed? 

The document has been reviewed by the working group.  A 6MAN working group Last Call completed on June 7, 2010.  The current draft resolves issues raised prior to the last call.


(1.c) Does the Document Shepherd have concerns that the document
      needs more review from a particular or broader perspective,
      e.g., security, operational complexity, someone familiar with
      AAA, internationalization or XML?

No.

(1.d) Does the Document Shepherd have any specific concerns or
      issues with this document that the Responsible Area Director
      and/or the IESG should be aware of? For example, perhaps he
      or she is uncomfortable with certain parts of the document, or
      has concerns whether there really is a need for it. In any
      event, if the WG has discussed those issues and has indicated
      that it still wishes to advance the document, detail those
      concerns here. Has an IPR disclosure related to this document
      been filed? If so, please include a reference to the
      disclosure and summarize the WG discussion and conclusion on
      this issue.

No concerns.

(1.e) How solid is the WG consensus behind this document? Does it
      represent the strong concurrence of a few individuals, with
      others being silent, or does the WG as a whole understand and
      agree with it? 

The approach this document takes was discussed at the last IETF meeting and I think there is general support in the working group.  There has been a lot of operational pull for this approach.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
      discontent? If so, please summarise the areas of conflict in
      separate email messages to the Responsible Area Director. (It
      should be in a separate email because this questionnaire is
      entered into the ID Tracker.)

None that I am aware of.

(1.g) Has the Document Shepherd personally verified that the
      document satisfies all ID nits? (See the
      Internet-Drafts Checklist and http://tools.ietf.org/tools/idnits/). 
      Boilerplate checks are
      not enough; this check needs to be thorough. Has the document
      met all formal review criteria it needs to, such as the MIB
      Doctor, media type and URI type reviews?

Yes, it passes ID nits.  No MIB, media types, or URI are defined.

(1.h) Has the document split its references into normative and
      informative? Are there normative references to documents that
      are not ready for advancement or are otherwise in an unclear
      state? If such normative references exist, what is the
      strategy for their completion? Are there normative references
      that are downward references, as described in [RFC3967]? If
      so, list these downward references to support the Area
      Director in the Last Call procedure for them [RFC3967].

There are normative and informative references.  No reference issues with advancing.  Looking at the document again, I think that RFC1035 should be moved to the normative list.


(1.i) Has the Document Shepherd verified that the document IANA
      consideration section exists and is consistent with the body
      of the document? If the document specifies protocol
      extensions, are reservations requested in appropriate IANA
      registries? Are the IANA registries clearly identified? If
      the document creates a new registry, does it define the
      proposed initial contents of the registry and an allocation
      procedure for future registrations? Does it suggest a
      reasonable name for the new registry? See [RFC5226]. If the
      document describes an Expert Review process has Shepherd
      conferred with the Responsible Area Director so that the IESG
      can appoint the needed Expert during the IESG Evaluation?

Looks fine.

(1.j) Has the Document Shepherd verified that sections of the
      document that are written in a formal language, such as XML
      code, BNF rules, MIB definitions, etc., validate correctly in
      an automated checker?

N/A


(1.k) The IESG approval announcement includes a Document
      Announcement Write-Up. Please provide such a Document
      Announcement Write-Up? Recent examples can be found in the
      "Action" announcements for approved documents. The approval
      announcement contains the following sections:

Technical Summary

This document specifies IPv6 Router Advertisement options to allow IPv6 routers to advertise a list of DNS recursive server addresses and a DNS search list to IPv6 hosts.

Working Group Summary


The working group discussed this approach of IPv6 host DNS configuration and believes there is an need for an RA based solution to complement what can be done with DHCPv6.  This document standardizes what was first defined in RFC5006 and also defines an RA option for a DNS search list.

Document Quality

I believe there is a BSD and Linux implementation, but it is not in a current distribution.  A number of operators have requested this option so it is reasonable to think that vendors will support it once it is standardized.

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Bob Hinden is the document shepherd. I have reviewed the document and believe it is ready for IESG reivew and publication.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

The document has been reviewed by the working group. A 6MAN working group Last Call completed on June 7, 2010. The current draft resolves issues raised prior to the last call.


(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

No.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

No concerns.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

The approach this document takes was discussed at the last IETF meeting and I think there is general support in the working group. There has been a lot of operational pull for this approach.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

None that I am aware of.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See the
Internet-Drafts Checklist and http://tools.ietf.org/tools/idnits/).
Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

Yes, it passes ID nits. No MIB, media types, or URI are defined.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

There are normative and informative references. No reference issues with advancing. Looking at the document again, I think that RFC1035 should be moved to the normative list.


(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

Looks fine.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

N/A


(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary

This document specifies IPv6 Router Advertisement options to allow IPv6 routers to advertise a list of DNS recursive server addresses and a DNS search list to IPv6 hosts.

Working Group Summary


The working group discussed this approach of IPv6 host DNS configuration and believes there is an need for an RA based solution to complement what can be done with DHCPv6. This document standardizes what was first defined in RFC5006 and also defines an RA option for a DNS search list.

Document Quality

I believe there is a BSD and Linux implementation, but it is not in a current distribution. A number of operators have requested this option so it is reasonable to think that vendors will support it once it is standardized.