Skip to main content

Distributing Address Selection Policy Using DHCPv6
draft-ietf-6man-addr-select-opt-13

Revision differences

Document history

Date Rev. By Action
2014-01-06
13 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2013-11-20
13 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2013-10-25
13 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2013-10-10
13 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2013-10-10
13 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2013-10-10
13 (System) IANA Action state changed to Waiting on Authors from In Progress
2013-10-10
13 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2013-10-10
13 Amy Vezza State changed to RFC Ed Queue from Approved-announcement sent
2013-10-10
13 (System) RFC Editor state changed to EDIT
2013-10-10
13 (System) Announcement was received by RFC Editor
2013-10-10
13 (System) IANA Action state changed to In Progress
2013-10-10
13 (System) IANA Action state changed to In Progress
2013-10-09
13 Amy Vezza State changed to Approved-announcement sent from Approved-announcement to be sent
2013-10-09
13 Amy Vezza IESG has approved the document
2013-10-09
13 Amy Vezza Closed "Approve" ballot
2013-10-09
13 Amy Vezza State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2013-10-09
13 Brian Haberman Ballot approval text was generated
2013-10-09
13 Brian Haberman Ballot writeup was changed
2013-10-09
13 Brian Haberman Changed consensus to Yes from Unknown
2013-10-08
13 Arifumi Matsumoto New version available: draft-ietf-6man-addr-select-opt-13.txt
2013-09-27
12 Ole Trøan IETF WG state changed to Submitted to IESG for Publication from Submitted to IESG for Publication
2013-09-27
12 Ole Trøan Annotation tag Revised I-D Needed - Issue raised by IESG set.
2013-09-23
12 Ted Lemon
[Ballot comment]
Update to the comment, sent to the authors on 9/21:

In reading your update to the draft, I realize that I failed to …
[Ballot comment]
Update to the comment, sent to the authors on 9/21:

In reading your update to the draft, I realize that I failed to communicate the problem here.  Let me try again.

Assume a host in state A, prior to having received any addr-select options.  Now, the host receives an addr-select option, and moves to state B.  The way the document is currently written, when the information in the addr-select option becomes stale, the host moves to state C, where C != A.  This is because in moving from state A to state B, information was lost.  I think it should move to state A, but in order for that to happen, the document needs to explain the details of the process.  If an implementor follows the text as currently written, the host will not be in state A after the addr-select information received from DHCP becomes stale.

So while I think the clarification you made to this section in the new version of the draft is good and helpful, it does not actually address the problem I am talking about above.

Old comment:

I think that you intend that the implementation should have a local configuration that is restored when the DHCP configuration expires.  Section 3.1 talks about how to handle local configurations, and section 3.2 talks about how to handle stale configurations, but you don't seem to talk about what to do when the actions taken in section 3.1 are deprecated.  So if in fact you intend that the local configuration be restored when the DHCP-supplied configuration has been deprecated, it would be good to make that clear.

Old DISCUSS position:

From the introduction:

  [RFC6724] describes default algorithms for selecting an address when
  a node has multiple destination and/or source addresses to choose
  from by using an address selection policy.  In Section 2 of RFC 6724,
  it is suggested that the default policy table may be administratively
  configured to suit the specific needs of a site.  This specification
  defines a new DHCPv6 option for such configuration.

There is an important distinction between "administratively configured" and "automatically configured through an unauthenticated remote protocol;" this introduction discusses the two as if they are equivalent, but of course they are not.  I don't think you should use this text from RFC 6724 to motivate this document.  To illustrate the problem I"m talking about, ask yourself this: do you think that the administrator of the Wifi hotspot you connect to in your local coffee shop ought to have administrative privileges on your laptop?

I suggest changing the text to this:

  [RFC6724] describes default algorithms for selecting an address when
  a node has multiple destination and/or source addresses to choose
  from by using an address selection policy.  This specification
  defines a new DHCPv6 option for configuring the default policy table.

You can clear this part of the discuss by convincing me that I am wrong to draw this distinction, or by accepting the proposed new text.

I would appreciate it if you could confirm that you analyzed possible attacks that could be done by influencing the source address selection policy on one interface to draw traffic away from another interface, and concluded that no such attacks were possible.  The issue I'm concerned about would be for example a DHCP-supplied configuration preventing a VPN from working properly, or capturing traffic intended for the VPN, or else a DHCP-supplied configuration drawing traffic from one interface to another.

I sat down and thought about it for a bit tonight and the attacks that I thought of don't seem to be possible, so I'm assuming the answer to this question is "yes, we thought about it, and no, there isn't an issue here."  So you can clear this part of the discuss simply by saying that, if it is in fact the case.  Otherwise, I'd appreciate it if you could think about it and report back, because you probably understand the problem space better than I do.
2013-09-23
12 Ted Lemon [Ballot Position Update] Position for Ted Lemon has been changed to No Objection from Discuss
2013-09-22
12 Sean Turner [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss
2013-09-20
12 (System) Sub state has been changed to AD Followup from Revised ID Needed
2013-09-20
12 Arifumi Matsumoto IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2013-09-20
12 Arifumi Matsumoto New version available: draft-ietf-6man-addr-select-opt-12.txt
2013-09-05
11 Tero Kivinen Closed request for Telechat review by SECDIR with state 'No Response'
2013-08-29
11 Cindy Morgan State changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2013-08-29
11 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2013-08-28
11 Ted Lemon
[Ballot discuss]
From the introduction:

  [RFC6724] describes default algorithms for selecting an address when
  a node has multiple destination and/or source …
[Ballot discuss]
From the introduction:

  [RFC6724] describes default algorithms for selecting an address when
  a node has multiple destination and/or source addresses to choose
  from by using an address selection policy.  In Section 2 of RFC 6724,
  it is suggested that the default policy table may be administratively
  configured to suit the specific needs of a site.  This specification
  defines a new DHCPv6 option for such configuration.

There is an important distinction between "administratively configured" and "automatically configured through an unauthenticated remote protocol;" this introduction discusses the two as if they are equivalent, but of course they are not.  I don't think you should use this text from RFC 6724 to motivate this document.  To illustrate the problem I"m talking about, ask yourself this: do you think that the administrator of the Wifi hotspot you connect to in your local coffee shop ought to have administrative privileges on your laptop?

I suggest changing the text to this:

  [RFC6724] describes default algorithms for selecting an address when
  a node has multiple destination and/or source addresses to choose
  from by using an address selection policy.  This specification
  defines a new DHCPv6 option for configuring the default policy table.

You can clear this part of the discuss by convincing me that I am wrong to draw this distinction, or by accepting the proposed new text.

I would appreciate it if you could confirm that you analyzed possible attacks that could be done by influencing the source address selection policy on one interface to draw traffic away from another interface, and concluded that no such attacks were possible.  The issue I'm concerned about would be for example a DHCP-supplied configuration preventing a VPN from working properly, or capturing traffic intended for the VPN, or else a DHCP-supplied configuration drawing traffic from one interface to another.

I sat down and thought about it for a bit tonight and the attacks that I thought of don't seem to be possible, so I'm assuming the answer to this question is "yes, we thought about it, and no, there isn't an issue here."  So you can clear this part of the discuss simply by saying that, if it is in fact the case.  Otherwise, I'd appreciate it if you could think about it and report back, because you probably understand the problem space better than I do.
2013-08-28
11 Ted Lemon
[Ballot comment]
I think that you intend that the implementation should have a local configuration that is restored when the DHCP configuration expires.  Section 3.1 …
[Ballot comment]
I think that you intend that the implementation should have a local configuration that is restored when the DHCP configuration expires.  Section 3.1 talks about how to handle local configurations, and section 3.2 talks about how to handle stale configurations, but you don't seem to talk about what to do when the actions taken in section 3.1 are deprecated.  So if in fact you intend that the local configuration be restored when the DHCP-supplied configuration has been deprecated, it would be good to make that clear.
2013-08-28
11 Ted Lemon [Ballot Position Update] New position, Discuss, has been recorded for Ted Lemon
2013-08-28
11 Sean Turner
[Ballot discuss]
Entirely possible I'm not getting it but is the recommendation in s3.1 is that the user's wishes be overridden?!  If I'm using CGAs …
[Ballot discuss]
Entirely possible I'm not getting it but is the recommendation in s3.1 is that the user's wishes be overridden?!  If I'm using CGAs or temporary addresses because I like privacy or to not be so correlated, then the default is to override what I set up?
2013-08-28
11 Sean Turner
[Ballot comment]
1) s2: Is another approach to also use CGAs?  Or is that lumped in with temporary addresses?

If this flag is set to …
[Ballot comment]
1) s2: Is another approach to also use CGAs?  Or is that lumped in with temporary addresses?

If this flag is set to 1, it does not change
client host behavior, that is, a client will prefer temporary
addresses [RFC4941].

Maybe:

If this flag is set to 1, it does not change
client host behavior, that is, a client will prefer temporary
addresses [RFC4941][RFC3972].

2) Any recommendations on which way to set the P flag?
2013-08-28
11 Sean Turner [Ballot Position Update] New position, Discuss, has been recorded for Sean Turner
2013-08-28
11 Richard Barnes [Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes
2013-08-27
11 Stewart Bryant
[Ballot comment]
Referring to flag A:

The text says:

a client SHOULD NOT automatically add rows to the policy table

and

automatic row addition SHOULD …
[Ballot comment]
Referring to flag A:

The text says:

a client SHOULD NOT automatically add rows to the policy table

and

automatic row addition SHOULD NOT be performed

which means that the implementation MAY do both of these if it chooses.

I just wanted to check that this was the intended behavior, rather than a MUST NOT, which could be legitimately specified behavior given that this is a new option.

=========

I agree with the comment that the prefix text in section 2 could be improved. Also it is a bit confusing to see reference to an IPv4 address in an IPv6 specification. An inline IPv4 example similar to the IPv6 example would be useful.

=========

We have to get to section 3 to find out that this ST document only describes advisory behavior.  ("This option's concept is to serve as a hint for a node about how to behave in the network. " This should really be much earlier in the text, and I think addresses my confusion about SHOULD NOT.

=========
2013-08-27
11 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant
2013-08-26
11 Joel Jaeggli [Ballot Position Update] Position for Joel Jaeggli has been changed to No Objection from No Record
2013-08-26
11 Joel Jaeggli
[Ballot comment]
I have concern about section 3.3

  2: Hosts that use advanced heuristics to deal with multiple received
      policies that …
[Ballot comment]
I have concern about section 3.3

  2: Hosts that use advanced heuristics to deal with multiple received
      policies that are defined outside the scope of this document
      SHOULD use Address Selection options.

  Implementations MAY provide configuration options to enable this
  protocol on a per interface basis.

  Implementations MAY store distributed address selection policies per
  interface.  They can be used effectively on implementations that
  adopt per-application interface selection.

It seems like hosts that are attached to two or more administrative domains really don't want to honor an address selection policy since that itself might be subject too the considerations in the security section.  I would expect that if you got two or more policies you'd would want to ignore them and revert to 3484/6724 (of your vendors preference) behavior whether they're authenticated or not. I suppose as someone applying policy it's not safe to assume that the default behavior will not be used even if you are specifying another one.

I don't really worry about devices that use send or secure dhcp mechanisms, they're fine probably it's the one's that roam (and by their nature have both the address selection problem) and a more ephemeral relationship to the networks to which they are attached.
2013-08-26
11 Joel Jaeggli Ballot comment text updated for Joel Jaeggli
2013-08-26
11 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2013-08-26
11 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2013-08-25
11 Adrian Farrel
[Ballot comment]
I have no objection to the publication of this document.

Is there not a concern that an authenticated DHCP server might use this …
[Ballot comment]
I have no objection to the publication of this document.

Is there not a concern that an authenticated DHCP server might use this
mechanism to direct traffic (perhaps to attract traffic) against locally
configured policy?  Presumably the first defence is that the local
policy (i.e., the default policy) can be set to not accept over-ride
from the DHCP server. Maybe this needs to be made a little clearer in
the document by strengthening the second paragraph in Section 3 and
stating it in the Introduction
2013-08-25
11 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel
2013-08-24
11 Pete Resnick
[Ballot comment]
Section 2, the definition of prefix-len. I ran out of brain power to think through the implications of this, so I'm asking you …
[Ballot comment]
Section 2, the definition of prefix-len. I ran out of brain power to think through the implications of this, so I'm asking you all to do so: I worry when I see the definition of an unsigned 8-bit field that says "the value ranges from 0 to 128", and then in the next paragraph it starts talking about doing calculations on that number. Are there any interesting buffer-overflow attacks lurking in there? Do we need specific instructions on what a client implementation should do if it sees a value greater than 128 in there? Maybe it makes no difference, but I wanted to be sure.
2013-08-24
11 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick
2013-08-23
11 Christer Holmberg Request for Telechat review by GENART Completed: Ready. Reviewer: Christer Holmberg.
2013-08-22
11 Jean Mahoney Request for Telechat review by GENART is assigned to Christer Holmberg
2013-08-22
11 Jean Mahoney Request for Telechat review by GENART is assigned to Christer Holmberg
2013-08-14
11 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2013-08-08
11 Tero Kivinen Request for Telechat review by SECDIR is assigned to Dan Harkins
2013-08-08
11 Tero Kivinen Request for Telechat review by SECDIR is assigned to Dan Harkins
2013-08-07
11 (System) IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2013-08-07
11 Pearl Liang
acker.
IANA Actions - YES

NOTE: Please use the following URL:

http://www.iana.org/assignments/dhcpv6-parameters

in section 6 "IANA Considerations" if you need to list the URL
in …
acker.
IANA Actions - YES

NOTE: Please use the following URL:

http://www.iana.org/assignments/dhcpv6-parameters

in section 6 "IANA Considerations" if you need to list the URL
in the document.  The use of above URL will always work and point
to the most current information.

Thank you,

Pearl Liang
ICANN/IANA

On Wed Aug 07 05:50:10 2013, iesg-secretary@ietf.org wrote:
> Evaluation for  can be found
> at
> http://datatracker.ietf.org/doc/draft-ietf-6man-addr-select-opt/
>
> Last call to expire on: 2013-05-15 00:00
>
>
>        Please return the full line with your position.
>
>                      Yes  No-Objection  Discuss  Abstain
> Brian Haberman      [ X ]    [  ]      [  ]    [  ]
>
>
> "Yes" or "No-Objection" positions from 2/3 of non-recused ADs,
> with no "Discuss" positions, are needed for approval.
>
> DISCUSSES AND COMMENTS
> ===========
> ?
> ---- following is a DRAFT of message to be sent AFTER approval ---
> From: The IESG
> To: IETF-Announce
> Cc: RFC Editor ,
>    6man mailing list ,
>    6man chair <6man-chairs@tools.ietf.org>
> Subject: Protocol Action: 'Distributing Address Selection Policy using
> DHCPv6' to Proposed Standard (draft-ietf-6man-addr-select-opt-10.txt)
>
> The IESG has approved the following document:
> - 'Distributing Address Selection Policy using DHCPv6'
>  (draft-ietf-6man-addr-select-opt-10.txt) as Proposed Standard
>
> This document is the product of the IPv6 Maintenance Working Group.
>
> The IESG contact persons are Brian Haberman and Ted Lemon.
>
> A URL of this Internet Draft is:
> http://datatracker.ietf.org/doc/draft-ietf-6man-addr-select-opt/
>
>
>
>
> Technical Summary:
>
>    RFC 6724 defines default address selection mechanisms for IPv6 that
>    allow nodes to select an appropriate address when faced with
> multiple
>    source and/or destination addresses to choose between.  The RFC
> 6724
>    allowed for the future definition of methods to administratively
>    configure the address selection policy information.  This document
>    defines a new DHCPv6 option for such configuration, allowing a site
>    administrator to distribute address selection policy overriding the
>    default address selection parameters and policy table, and thus
>    control the address selection behavior of nodes in their site.
>
> Working Group Summary:
>
> Was there anything in WG process that is worth noting? For example,
> was there controversy about particular points or were there decisions
> where the consensus was particularly rough?
>
>  Nothing in particular.
>
> Document Quality:
>
> Are there existing implementations of the protocol? Have a significant
> number of vendors indicated their plan to implement the specification?
> Are there any reviewers that merit special mention as having done a
> thorough review, e.g., one that resulted in important changes or a
> conclusion that the document had no substantive issues? If there was a
> MIB Doctor, Media Type or other expert review, what was its course
> (briefly)? In the case of a Media Type review, on what date was the
> request posted?
>
>  Ray Hunter has done a thorough review of the document,
>  in addition has the 6man chairs done a 'chair's review' of
>  the document.
>
>  The document has also been through a last call in the DHC WG.
>
> Personnel:
>
>  Ole Troan is the Document Shepherd.
>  Brian Haberman is the Responsible Area Director.
>
> RFC Editor Note
>
>  (Insert RFC Editor Note here or remove section)
>
> IRTF Note
>
>  (Insert IRTF Note here or remove section)
>
> IESG Note
>
>  (Insert IESG Note here or remove section)
>
> IANA Note
>
>  (Insert IANA Note here or remove section)
>
>
2013-08-07
11 Brian Haberman State changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup
2013-08-07
11 Brian Haberman Placed on agenda for telechat - 2013-08-29
2013-08-07
11 Brian Haberman Ballot has been issued
2013-08-07
11 Brian Haberman [Ballot Position Update] New position, Yes, has been recorded for Brian Haberman
2013-08-07
11 Brian Haberman Created "Approve" ballot
2013-08-07
11 Brian Haberman Ballot writeup was changed
2013-08-07
11 (System) Sub state has been changed to AD Followup from Revised ID Needed
2013-08-07
11 Arifumi Matsumoto IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2013-08-07
11 Arifumi Matsumoto New version available: draft-ietf-6man-addr-select-opt-11.txt
2013-05-23
10 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Dan Harkins.
2013-05-23
10 Brian Haberman State changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead
2013-05-21
10 Christer Holmberg Request for Last Call review by GENART Completed: Ready. Reviewer: Christer Holmberg.
2013-05-15
10 (System) State changed to Waiting for AD Go-Ahead from In Last Call
2013-05-07
10 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2013-05-07
10 Pearl Liang
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-6man-addr-select-opt-10.  Authors should
review the comments and/or questions below.  Please report any
inaccuracies and respond to any questions as soon …
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-6man-addr-select-opt-10.  Authors should
review the comments and/or questions below.  Please report any
inaccuracies and respond to any questions as soon as possible.

IANA has a comment/question about the action requested by the authors
in this document.

We understand that, upon approval of this document, there is a single
action which we must complete.

In the DHCP Option Codes subregistry of the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) located at:

http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml

two new Optioon Codes will be registered as follows:

Value: [ TBD-at-registrationh ]
Description: OPTION_ADDRSEL
Reference: [ RFC-to-be ]

Value: [ TBD-at-registrationh ]
Description: OPTION_ADDRSEL_TABLE
Reference: [ RFC-to-be ]

We note that the DHCPv6 Options Code subregistry is managed through
Expert Review as defined by RFC5226.

NOTE: We will initiate a request and send this to the designated expert
for review.

We understand that this is the only IANA action required upon approval
of this document.

Note:  The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.
2013-05-02
10 Jean Mahoney Request for Last Call review by GENART is assigned to Christer Holmberg
2013-05-02
10 Jean Mahoney Request for Last Call review by GENART is assigned to Christer Holmberg
2013-05-02
10 Tero Kivinen Request for Last Call review by SECDIR is assigned to Dan Harkins
2013-05-02
10 Tero Kivinen Request for Last Call review by SECDIR is assigned to Dan Harkins
2013-05-01
10 (System) IANA Review state changed to IANA - Review Needed from IANA OK - Actions Needed
2013-05-01
10 Amy Vezza IANA Review state changed to IANA - Review Needed
2013-05-01
10 Amy Vezza
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Distributing Address Selection Policy using …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Distributing Address Selection Policy using DHCPv6) to Proposed Standard


The IESG has received a request from the IPv6 Maintenance WG (6man) to
consider the following document:
- 'Distributing Address Selection Policy using DHCPv6'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-05-15. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  RFC 6724 defines default address selection mechanisms for IPv6 that
  allow nodes to select an appropriate address when faced with multiple
  source and/or destination addresses to choose between.  The RFC 6724
  allowed for the future definition of methods to administratively
  configure the address selection policy information.  This document
  defines a new DHCPv6 option for such configuration, allowing a site
  administrator to distribute address selection policy overriding the
  default address selection parameters and policy table, and thus
  control the address selection behavior of nodes in their site.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-6man-addr-select-opt/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-6man-addr-select-opt/ballot/


No IPR declarations have been submitted directly on this I-D.


2013-05-01
10 Amy Vezza State changed to In Last Call from Last Call Requested
2013-05-01
10 Brian Haberman Last call was requested
2013-05-01
10 Brian Haberman Last call announcement was generated
2013-05-01
10 Brian Haberman Ballot approval text was generated
2013-05-01
10 Brian Haberman Ballot writeup was generated
2013-05-01
10 Brian Haberman State changed to Last Call Requested from AD Evaluation::AD Followup
2013-04-29
10 (System) Sub state has been changed to AD Followup from Revised ID Needed
2013-04-29
10 Arifumi Matsumoto New version available: draft-ietf-6man-addr-select-opt-10.txt
2013-04-26
09 Brian Haberman State changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup
2013-04-26
09 Brian Haberman
Hi all,
    I have performed my usual AD review of draft-ietf-6man-addr-select-opt prior to it moving towards IETF Last Call.  The document is well-written …
Hi all,
    I have performed my usual AD review of draft-ietf-6man-addr-select-opt prior to it moving towards IETF Last Call.  The document is well-written and I only have a few comments.  Once we have resolved these, we can move the document along in the publication process...

1. Section 2

* The beginning of this section indicates that the Address Selection option contains zero or more policy table options.  It would be good to clarify that sending an Address Selection option with zero policy table options allows the operator to convey the values of the A & P flags.

* The descriptions of "precedence" and "label" should probably indicate their direct relationship to the policy table structure in RFC 6724.

2. In section 3, I was expecting better detail in *how* the information in the DHCP options is handled.  I am not aware of any other DHCP-provided information that is conditional based on the user's whim.  This seems like it could lead to hard to diagnose brokenness.

3. In section 6, I think it is better to point to the actual IANA registry where the options will be documented, rather than the RFC that created the registry.

Regards,
Brian
2013-04-25
09 (System) Sub state has been changed to AD Followup from Revised ID Needed
2013-04-25
09 Arifumi Matsumoto New version available: draft-ietf-6man-addr-select-opt-09.txt
2013-04-04
08 Brian Haberman State changed to AD Evaluation::Revised I-D Needed from AD Evaluation::External Party
2013-03-11
08 Brian Haberman State changed to AD Evaluation::External Party from AD Evaluation
2013-02-22
08 Brian Haberman State changed to AD Evaluation from Publication Requested
2013-02-20
08 Brian Haberman Intended Status changed to Proposed Standard
2013-02-20
08 Brian Haberman IESG process started in state Publication Requested
2013-02-18
08 Ole Trøan IETF state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2013-02-18
08 Ole Trøan Annotation tag Revised I-D Needed - Issue raised by WGLC cleared.
2013-02-05
08 Ole Trøan Changed protocol writeup
2013-01-15
08 Arifumi Matsumoto New version available: draft-ietf-6man-addr-select-opt-08.txt
2012-12-19
07 Ole Trøan IETF state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2012-12-19
07 Ole Trøan Annotation tag Revised I-D Needed - Issue raised by WGLC set.
2012-11-13
07 Arifumi Matsumoto New version available: draft-ietf-6man-addr-select-opt-07.txt
2012-10-10
06 Ole Trøan Annotation tag Doc Shepherd Follow-up Underway cleared.
2012-10-10
06 Ole Trøan Changed protocol writeup
2012-10-10
06 Ole Trøan IETF state changed to In WG Last Call from Submitted to IESG for Publication
2012-10-10
06 Ole Trøan IETF state changed to Submitted to IESG for Publication from Waiting for WG Chair Go-Ahead
2012-10-10
06 Ole Trøan IETF state changed to Waiting for WG Chair Go-Ahead from In WG Last Call
2012-10-10
06 Ole Trøan Annotation tag Doc Shepherd Follow-up Underway cleared.
2012-10-10
06 Ole Trøan Changed protocol writeup
2012-10-10
06 Ole Trøan Mistakenly changed state to IESG for publication. Should be in WGLC.
2012-10-10
06 Ole Trøan Submitted to the IESG.
2012-10-10
06 Ole Trøan Passed WGLC.
2012-10-10
06 Ole Trøan Changed shepherd to Ole Troan
2012-10-10
06 Ole Trøan IETF state changed to In WG Last Call from WG Document
2012-09-21
06 Ole Trøan In WG Last call ending October 24th.
2012-09-21
06 Arifumi Matsumoto New version available: draft-ietf-6man-addr-select-opt-06.txt
2012-08-22
05 Arifumi Matsumoto New version available: draft-ietf-6man-addr-select-opt-05.txt
2012-07-16
04 Arifumi Matsumoto New version available: draft-ietf-6man-addr-select-opt-04.txt
2012-02-21
03 (System) New version available: draft-ietf-6man-addr-select-opt-03.txt
2012-02-15
02 (System) New version available: draft-ietf-6man-addr-select-opt-02.txt
2011-12-30
03 (System) Document has expired
2011-06-28
01 (System) New version available: draft-ietf-6man-addr-select-opt-01.txt
2010-12-07
00 (System) New version available: draft-ietf-6man-addr-select-opt-00.txt