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 |