Simple Procedures for Detecting Network Attachment in IPv6
RFC 6059
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2015-10-14
|
17 | (System) | Notify list changed from dna-chairs@ietf.org, draft-ietf-dna-simple@ietf.org to (None) |
2012-08-22
|
17 | (System) | post-migration administrative database adjustment to the No Objection position for Lars Eggert |
2012-08-22
|
17 | (System) | post-migration administrative database adjustment to the No Objection position for Tim Polk |
2012-08-22
|
17 | (System) | post-migration administrative database adjustment to the No Objection position for Ralph Droms |
2012-08-22
|
17 | (System) | post-migration administrative database adjustment to the No Objection position for Dan Romascanu |
2012-08-22
|
17 | (System) | post-migration administrative database adjustment to the No Objection position for Russ Housley |
2010-11-30
|
17 | Cindy Morgan | State changed to RFC Published from RFC Ed Queue. |
2010-11-30
|
17 | Cindy Morgan | [Note]: changed to 'RFC 6059' |
2010-11-30
|
17 | (System) | RFC published |
2010-09-14
|
17 | Amy Vezza | State changed to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
2010-09-13
|
17 | (System) | IANA Action state changed to No IC from In Progress |
2010-09-13
|
17 | (System) | IANA Action state changed to In Progress |
2010-09-13
|
17 | Amy Vezza | IESG state changed to Approved-announcement sent |
2010-09-13
|
17 | Amy Vezza | IESG has approved the document |
2010-09-13
|
17 | Amy Vezza | Closed "Approve" ballot |
2010-09-10
|
17 | (System) | Removed from agenda for telechat - 2010-09-09 |
2010-09-09
|
17 | Jari Arkko | State changed to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed by Jari Arkko |
2010-09-09
|
17 | Amy Vezza | State changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation by Amy Vezza |
2010-09-09
|
17 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded by Gonzalo Camarillo |
2010-09-08
|
17 | Peter Saint-Andre | [Ballot Position Update] New position, No Objection, has been recorded by Peter Saint-Andre |
2010-09-08
|
17 | David Harrington | [Ballot Position Update] New position, No Objection, has been recorded by David Harrington |
2010-09-08
|
17 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded by Sean Turner |
2010-09-08
|
17 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded by Robert Sparks |
2010-09-08
|
17 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded by Stewart Bryant |
2010-09-08
|
17 | Ralph Droms | [Ballot comment] (edited 2010-09-08) I cleared my DISCUSS. I think this text in section 2.4 is superfluous, as ND and/or DHCP are completed regardless of … [Ballot comment] (edited 2010-09-08) I cleared my DISCUSS. I think this text in section 2.4 is superfluous, as ND and/or DHCP are completed regardless of the outcome of the simple DNA procedure: If previously encountered routers are not present then either IPv6 Stateless Address Autoconfiguration and/or DHCPv6 is used for configuration. In section 5.3, change "neighbor discovery" to "Neighbor Solicitation"? |
2010-09-08
|
17 | Ralph Droms | [Ballot discuss] Therefore, I think the changes to DHCPv6 need to be taken out of the document. There is still the issue of the relationship … [Ballot discuss] Therefore, I think the changes to DHCPv6 need to be taken out of the document. There is still the issue of the relationship between this document and RFC 4861, as this document changes the way in which RS messages are sent at startup. I think the changes to RFC 4861 should be taken out of the doc, as well. The benefit of DNA can be gained from the simple use of NS/NA to see if the link can be identified through a previously-discovered default router. |
2010-09-08
|
17 | Ralph Droms | [Ballot Position Update] Position for Ralph Droms has been changed to No Objection from Discuss by Ralph Droms |
2010-09-07
|
17 | Jari Arkko | Placed on agenda for telechat - 2010-09-09 by Jari Arkko |
2010-09-07
|
17 | Jari Arkko | [Note]: 'Back on the agenda after 2nd Last Call (feel free to defer if too quick) (no document shepherd)' added by Jari Arkko |
2010-09-07
|
17 | Jari Arkko | State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Jari Arkko |
2010-08-25
|
17 | (System) | New version available: draft-ietf-dna-simple-17.txt |
2010-08-24
|
17 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2010-08-16
|
17 | Amanda Baber | IANA understands that this document does not require any actions. |
2010-08-10
|
17 | Amy Vezza | Last call sent |
2010-08-10
|
17 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2010-08-10
|
16 | (System) | New version available: draft-ietf-dna-simple-16.txt |
2010-08-10
|
17 | Jari Arkko | State Changes to Last Call Requested from IESG Evaluation::AD Followup by Jari Arkko |
2010-08-10
|
17 | Jari Arkko | Last Call was requested by Jari Arkko |
2010-08-09
|
17 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2010-08-09
|
15 | (System) | New version available: draft-ietf-dna-simple-15.txt |
2010-08-09
|
17 | Jari Arkko | In IETF-78, we agreed with Bernard and Ralph on what to do. Expecting Suresh to revise the document (reminder sent today). |
2010-04-26
|
17 | Jari Arkko | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::External Party by Jari Arkko |
2010-04-26
|
17 | Jari Arkko | Suresh tells me that he is going to review his changes once more and possibly submit a new version, at that point the draft is … Suresh tells me that he is going to review his changes once more and possibly submit a new version, at that point the draft is ready for re-review by me, Bernard, and Ralph. |
2010-02-14
|
14 | (System) | New version available: draft-ietf-dna-simple-14.txt |
2010-02-05
|
17 | Jari Arkko | State Changes to IESG Evaluation::External Party from IESG Evaluation::AD Followup by Jari Arkko |
2010-02-05
|
17 | Jari Arkko | waiting for a number of reviewers to comment on the new version |
2010-02-04
|
13 | (System) | New version available: draft-ietf-dna-simple-13.txt |
2010-01-22
|
17 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2010-01-22
|
12 | (System) | New version available: draft-ietf-dna-simple-12.txt |
2010-01-18
|
17 | Jari Arkko | Sent a reminder to Suresh about the new document version. |
2009-12-09
|
17 | Ralph Droms | [Ballot comment] The authors should take a pass over the entire document to confirm that all descriptions of the purpose of this mechanism is to … [Ballot comment] The authors should take a pass over the entire document to confirm that all descriptions of the purpose of this mechanism is to determine if the host has reattached to *any* previously attached link, rather than determining if the host has reattached to the link the host just left. For example: 4. Host Operations When a host has an existing configuration for IP address prefixes and next hop routing, it may be disconnected from its link-layer, and then subsequently reconnect the link-layer on the same interface. When the link-layer becomes available again, it is important to determine whether the existing addressing and routing configuration are still valid. In order to determine this, the host performs the detecting network attachment procedure. This document describes more than just detecting change; it describes how to find any link the host to which the host might have been previously connected. In the Introduction: Why do "Hosts require procedures to simply and reliably identify if they have moved to a different IP network" I think all of the text in the first paragraph of the introduction is more or less at odds with the rest of the document. Moving to a different IP network is not what this document is about. The machinery in this document identifies if a host reattaches to a link to which it has been previously attached. It accomplishes that result by determining if it has reachability to a router it has previously used as a default router. If the host determines it has been previously attached to its current link, it reuses the previously used addresses and other configuration information. Similarly, section 2.1 has several goals that mention "link change" when, in fact, Simple DNA is all about determining link reattachment. In section 2.5, if assumption 1 does not hold, a host may make an incorrect determination of which link it has attached to. In section 4, the second paragraph describes reattaching to the same link, while Simple DNA determines whether the host has reattached to *any* link to which it has previously been attached. There should be some text somewhere about when info is cached in the SDAT and when info is flushed from the SDAT. |
2009-12-09
|
17 | Ralph Droms | [Ballot discuss] I have updated my DISCUSS and COMMENT for this document, as explained below. In an e-mail discussion, I posted the following summary of … [Ballot discuss] I have updated my DISCUSS and COMMENT for this document, as explained below. In an e-mail discussion, I posted the following summary of how DNA should work: * Send NS for each candidate link to the default router for that link * Initiate RS/RA exchange as specified in RFC 4861 * Initiate DHCPv6 exchange as specified in RFC 3315 * If an NA is received, used cached info for corresponding link from SDAT * Process any received RAs as specified in RFC 4861 * Use info from DHCPv6 exchange as specified in RFC 3315 * Info from RA and/or DHCPv6 overrides any reused cached info based on NA Bernard Aboba agreed with this summary. The salient point here is that DNA should not modify the behavior of DHCPv6 whatsover. Therefore, I think the changes to DHCPv6 need to be taken out of the document. There is still the issue of the relationship between this document and RFC 4861, as this document changes the way in which RS messages are sent at startup. I think the changes to RFC 4861 should be taken out of the doc, as well. The benefit of DNA can be gained from the simple use of NS/NA to see if the link can be identified through a previously-discovered default router. |
2009-11-20
|
17 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Yaron Sheffer. |
2009-11-20
|
17 | Jari Arkko | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Jari Arkko |
2009-11-20
|
17 | Jari Arkko | Waiting authors to respond to Ralph's issues. |
2009-11-19
|
17 | Cindy Morgan | State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Cindy Morgan |
2009-11-19
|
17 | Ralph Droms | [Ballot comment] The authors should take a pass over the entire document to confirm that all descriptions of the purpose of this mechanism is to … [Ballot comment] The authors should take a pass over the entire document to confirm that all descriptions of the purpose of this mechanism is to determine if the host has reattached to *any* previously attached link, rather than determining if the host has reattached to the link the host just left. For example: 4. Host Operations When a host has an existing configuration for IP address prefixes and next hop routing, it may be disconnected from its link-layer, and then subsequently reconnect the link-layer on the same interface. When the link-layer becomes available again, it is important to determine whether the existing addressing and routing configuration are still valid. In order to determine this, the host performs the detecting network attachment procedure. This document describes more than just detecting change; it describes how to find any link the host to which the host might have been previously connected. In the Introduction: Why do "Hosts require procedures to simply and reliably identify if they have moved to a different IP network" I think all of the text in the first paragraph of the introduction is more or less at odds with the rest of the document. Moving to a different IP network is not what this document is about. The machinery in this document identifies if a host reattaches to a link to which it has been previously attached. It accomplishes that result by determining if it has reachability to a router it has previously used as a default router. If the host determines it has been previously attached to its current link, it reuses the previously used addresses and other configuration information. Similarly, section 2.1 has several goals that mention "link change" when, in fact, Simple DNA is all about determining link reattachment. Section 2.2: When a host moves to a completely new link that is previously unknown, the performance of the Simple DNA protocol will be identical to that using standard neighbor discovery procedures [RFC4861]. But, section 4.6 suggests initiating DHCPv6 before receiving an RA, which reduces latency in completing DHCPv6 transaction for address assignment on a new link. Section 2.4: Since simple DNA does not modify the DHCPv6 protocol or state machine, the operation of DHCPv6 is unchanged. Not true. Simple DNA hanges the timing of DHCPv6 transmission and uses Solicit when Confirm would be appropriate. In section 2.5, if assumption 1 does not hold, a host may make an incorrect determination of which link it has attached to. In section 4, the second paragraph describes reattaching to the same link, while Simple DNA determines whether the host has reattached to *any* link to which it has previously been attached. In section 4.5.2, is there any difference between this RS message contents and the RS message contents specified in RFC 4861? If there is no difference, just reference the appropriate section of RFC 4861. There should be some text somewhere about when info is cached in the SDAT and when info is flushed from the SDAT. |
2009-11-19
|
17 | Ralph Droms | [Ballot discuss] Discuss-discuss: I'm inclined to agree with Tim that this document updates RFC 4861. In addition to the change Tim noted, this document … [Ballot discuss] Discuss-discuss: I'm inclined to agree with Tim that this document updates RFC 4861. In addition to the change Tim noted, this document also specifies fast transmission of an RS without the initial delay specified in section 6.3.7 of RFC 4861. Similarly, this document calls for the transmission of an initial DHCPv6 message without the initial delay specified in section 17.1.2 of RFC 3315. The document also modifies the retransmission rules for several messages. And, although I hate to raise this issue, this document suggests that a DHCPv6 transaction is initiated before the hsot has seen the M/O bits in an RA. In section 4.1, I think each table entry should include: o Link-local IPv6 address of the router that advertised the prefix. o Link-layer (MAC) address of the router that advertised the prefix. o One or more IPv6 addresses; for each address include: * flag to indicate whether the address was obtained through SLAAC or DHCPv6 * preferred lifetime * valid lifetime * other configuration information if address was obtained through DHCPv6: - DUID - IA_ID - flag indicating IA_NA/IA_TA - other configuration information (DNS recursive servers, NTP servers, etc.) o One or more prefixes assigned to the link * preferred lifetime * valid lifetime * on-link flag In section 4.2: o Sending of neighbor discovery or DHCPv6 probes is incorrect ("or"). The host always sends NS probes and RS requests; it *may* send a DHCPv6 confirmation early as an optimization. In section 4.4: For the purpose of sending neighbor solicitations to previous routers, the host first identifies the set of operable IPv6 addresses (candidate set) that it wishes to use. If the addresses obtained from a previous router are no longer valid, the host does not include these addresses in the candidate set for NS based probing. s/operable/valid/ At this point, the host does not know what link it is attached to, so it cannot determine which addresses are operable. Also, the second sentence in this paragraph is redundant assuming the change to "valid" is made. More abstractly, I would rewrite this paragraph and the following paragraph to allow for multiple addresses on an interface: For the purpose of sending Neighbor Solicitation messages to previous routers, the host first identifies the set of candidate routers to probe. Any router in the SDAT for which there is at least one valid address is in the set of candidate routers. For each router in the candidate set, the host obtains the link-local and MAC addresses of the router from the SDAT. The host then sends a unicast Neighbor Solicitation to the router's link-local address. In the next paragraph, make "Router Solicitations" singular. The first paragraph in this section has a MUST requirement that the host only send one Router Solicitation. In section 4.5.1, I am baffled by the last paragraph. No DHCPv6 address is used anywhere else in the probe NS message and I can think of no reason why "The probing node SHOULD include a Source link-layer address option in the probe messages if the address was obtained using DHCPv6". Section 4.6 is somewhat problematic, in that a host is expected to use a Confirm message if it already has assigned addresses and a Solicit message if not. Thinking about the problem a little, I would suggest turning the solution around as follows: * Send a Solicit message * Compare the addresses in the Advertise message to the addresses in the SDAT * If a match is found, assume connection to the corresponding link; otherwise * Complete the DHCPv6 message exchange with a Request and wait for the Reply Otherwise, the host will need to send a Confirm message for each of candidate links and a Solicit message in case it is attached to a new link. In section 4.7, 2nd para, if the host receives an RA, why wouldn't it just use the current info in the RA; why would it try to reuse any cached info from a previous attachment? Also in the same para, what does it mean to receive a "DHCPv6 message [...] which contains prefixes that intersect with those previously advertised by a known router"? A DHCPv6 message contains assigned addresses and other configuration information, but no prefixes. I'm guessing the idea is to use the DHCPv6 response as an optimization, in case it is received before any NA or RA messages. If I have that right, then the check would have to be that the set of addresses in the DHCPv6 message matches the set of previously assigned addresses associated with the probed router. |
2009-11-19
|
17 | Lars Eggert | [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Discuss by Lars Eggert |
2009-11-19
|
17 | Lars Eggert | [Ballot comment] I believe the majority of the SHOULDs in this ID should become MUSTs. Some examples below. Please check them all. (To … [Ballot comment] I believe the majority of the SHOULDs in this ID should become MUSTs. Some examples below. Please check them all. (To clarify: I'm not asking you to blindly change all the SHOULDs to MUSTs - I'd like you to simply look at each instance of a SHOULD and ask yourself if you can come up with a valid case where it may be useful to go against the SHOULD, and where you can't find one, make it a MUST.) Section 2.2., paragraph 1: > The Simple DNA protocol provides substantial benefits in some > scenarios and does not provide any benefit at all in certain other > scenarios. Compared to what? Section 4.1., paragraph 1: > In order to correctly perform the procedure described in this > document the host needs to maintain a data structure called the > Simple DNA address table (SDAT). This data structure is maintained > by the host on a per interface basis. Why per-interface? Can't this be shared among all interfaces? Section 4.3., paragraph 2: > After the indication is received, the host considers all currently > configured (non-tentative) IP addresses to be deprecated until the > change detection process completes. It SHOULD also set all Neighbor > Cache entries for the routers on its Default Router List to STALE. Why SHOULD and not MUST? Section 4.4., paragraph 1: > When a host receives a link-layer "up" indication, it SHOULD > immediately send both a Router Solicitation and if it retains at > least one valid IPv6 address, one or more unicast Neighbor > Solicitations. Why not MUST? Section 4.4., paragraph 4: > The host SHOULD NOT send > unicast Neighbor Solicitations to a test node corresponding to an > IPv6 address that is no longer valid. Why not MUST NOT? Section 4.6., paragraph 3: > Where an > existing valid address is being tested for operability, this address > should be placed in the Identity Association's IAADDR element, and > the DUID associated with that address should be copied to the DHCP > SOLICIT from the SDAT. should -> MUST? (2x) Section 4.7., paragraph 2: > On reception of a Router Advertisement or advertising DHCPv6 message > (a REPLY or ADVERTISE) which contains prefixes that intersect with > those previously advertised by a known router, the host utilizes the > configuration associated with the detected network. What exactly does "intersect" mean? Do you mean "all prefixes returned must match the prefixes in the SDAT associated with a router" or "at least one returned prefix must match one of the prefixes associated with a router in the SDAT?" Section 4.7., paragraph 3: > When the host receives an advertisement containing only prefixes > which are disjoint from known advertised prefixes, the host MUST > determine whether the solicited advertisement corresponds to any of > the routers probed via NS. Do you mean "disjoint" as in "doesn't match *any* of the prefixes associated with *any* router in the SDAT? Section 4.7., paragraph 4: > If it does, then the host SHOULD conclude > that the IPv6 addresses corresponding to that router are no longer > valid. Since any NS probes to that router will no longer provide > useful information, further probing of that router SHOULD be aborted. I think these need to be MUSTs, or else explain when it wouldn't be. Section 4.7., paragraph 6: > When the host receives a Router Advertisement in reply to the Router > Solicitation it sent, the host SHOULD look for a Neighbor Cache entry > for the sending router and SHOULD mark that router's Neighbor Cache > Entry as REACHABLE if one was found. The host SHOULD add a new > Neighbor Cache Entry in the REACHABLE state for the sending router if > one does not currently exist. I think all of the SHOULDs need to be MUSTs. |
2009-11-19
|
17 | Lars Eggert | [Ballot discuss] Section 2.4., paragraph 1: > Detecting Network Attachment is performed by hosts after detecting a > link-layer "up" indication. The host … [Ballot discuss] Section 2.4., paragraph 1: > Detecting Network Attachment is performed by hosts after detecting a > link-layer "up" indication. The host simultaneously sends multicast > Router Solicitations (RSs) and unicast Neighbor Solicitations (NSs) > in order to determine whether previously encountered routers are > present on the link. DISCUSS: Section 4.9 has appropriate text on handling retransmissions of a single probe. What I'm missing is some text that recommends an upper bound for how many previous networks should be probed for. Clearly, probing for hundreds of previously known networks will results in thousands of packets that will all be sent without any sort of congestion control, which would be a problem. Similarly, probing for a small number of previously known networks will be fine. Can we add a recommendation that says that you should limit yourself to probing for at most X (10?) previous network locations? |
2009-11-19
|
17 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley |
2009-11-19
|
17 | Tim Polk | [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Undefined by Tim Polk |
2009-11-19
|
17 | Tim Polk | [Ballot Position Update] Position for Tim Polk has been changed to Undefined from Discuss by Tim Polk |
2009-11-19
|
17 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund |
2009-11-18
|
17 | Pasi Eronen | [Ballot Position Update] New position, No Objection, has been recorded by Pasi Eronen |
2009-11-18
|
17 | Ross Callon | [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon |
2009-11-18
|
17 | Ralph Droms | [Ballot comment] In the Introduction: Why do "Hosts require procedures to simply and reliably identify if they have moved to a different IP … [Ballot comment] In the Introduction: Why do "Hosts require procedures to simply and reliably identify if they have moved to a different IP network" I think all of the text in the first paragraph of the introduction is more or less at odds with the rest of the document. Moving to a different IP network is not what this document is about. The machinery in this document identifies if a host reattaches to a link to which it has been previously attached. It accomplishes that result by determining if it has reachability to a router it has previously used as a default router. If the host determines it has been previously attached to its current link, it reuses the previously used addresses and other configuration information. Similarly, section 2.1 has several goals that mention "link change" when, in fact, Simple DNA is all about determining link reattachment. Section 2.2: When a host moves to a completely new link that is previously unknown, the performance of the Simple DNA protocol will be identical to that using standard neighbor discovery procedures [RFC4861]. But, section 4.6 suggests initiating DHCPv6 before receiving an RA, which reduces latency in completing DHCPv6 transaction for address assignment on a new link. Section 2.4: Since simple DNA does not modify the DHCPv6 protocol or state machine, the operation of DHCPv6 is unchanged. Not true. Simple DNA hanges the timing of DHCPv6 transmission and uses Solicit when Confirm would be appropriate. In section 2.5, if assumption 1 does not hold, a host may make an incorrect determination of which link it has attached to. In section 4, the second paragraph describes reattaching to the same link, while Simple DNA determines whether the host has reattached to *any* link to which it has previously been attached. In section 4.5.2, is there any difference between this RS message contents and the RS message contents specified in RFC 4861? If there is no difference, just reference the appropriate section of RFC 4861. There should be some text somewhere about when info is cached in the SDAT and when info is flushed from the SDAT. |
2009-11-18
|
17 | Ralph Droms | [Ballot discuss] Discuss-discuss: I'm inclined to agree with Tim that this document updates RFC 4861. In addition to the change Tim noted, this document … [Ballot discuss] Discuss-discuss: I'm inclined to agree with Tim that this document updates RFC 4861. In addition to the change Tim noted, this document also specifies fast transmission of an RS without the initial delay specified in section 6.3.7 of RFC 4861. Similarly, this document calls for the transmission of an initial DHCPv6 message without the initial delay specified in section 17.1.2 of RFC 3315. The document also modifies the retransmission rules for several messages. And, although I hate to raise this issue, this document suggests that a DHCPv6 transaction is initiated before the hsot has seen the M/O bits in an RA. In section 4.1, I think each table entry should include: o Link-local IPv6 address of the router that advertised the prefix. o Link-layer (MAC) address of the router that advertised the prefix. o One or more IPv6 addresses; for each address include: * flag to indicate whether the address was obtained through SLAAC or DHCPv6 * preferred lifetime * valid lifetime * other configuration information if address was obtained through DHCPv6: - DUID - IA_ID - flag indicating IA_NA/IA_TA - other configuration information (DNS recursive servers, NTP servers, etc.) o One or more prefixes assigned to the link * preferred lifetime * valid lifetime * on-link flag In section 4.2: o Sending of neighbor discovery or DHCPv6 probes is incorrect ("or"). The host always sends NS probes and RS requests; it *may* send a DHCPv6 confirmation early as an optimization. In section 4.4: For the purpose of sending neighbor solicitations to previous routers, the host first identifies the set of operable IPv6 addresses (candidate set) that it wishes to use. If the addresses obtained from a previous router are no longer valid, the host does not include these addresses in the candidate set for NS based probing. s/operable/valid/ At this point, the host does not know what link it is attached to, so it cannot determine which addresses are operable. Also, the second sentence in this paragraph is redundant assuming the change to "valid" is made. More abstractly, I would rewrite this paragraph and the following paragraph to allow for multiple addresses on an interface: For the purpose of sending Neighbor Solicitation messages to previous routers, the host first identifies the set of candidate routers to probe. Any router in the SDAT for which there is at least one valid address is in the set of candidate routers. For each router in the candidate set, the host obtains the link-local and MAC addresses of the router from the SDAT. The host then sends a unicast Neighbor Solicitation to the router's link-local address. In the next paragraph, make "Router Solicitations" singular. The first paragraph in this section has a MUST requirement that the host only send one Router Solicitation. In section 4.5.1, I am baffled by the last paragraph. No DHCPv6 address is used anywhere else in the probe NS message and I can think of no reason why "The probing node SHOULD include a Source link-layer address option in the probe messages if the address was obtained using DHCPv6". Section 4.6 is somewhat problematic, in that a host is expected to use a Confirm message if it already has assigned addresses and a Solicit message if not. Thinking about the problem a little, I would suggest turning the solution around as follows: * Send a Solicit message * Compare the addresses in the Advertise message to the addresses in the SDAT * If a match is found, assume connection to the corresponding link; otherwise * Complete the DHCPv6 message exchange with a Request and wait for the Reply Otherwise, the host will need to send a Confirm message for each of candidate links and a Solicit message in case it is attached to a new link. In section 4.7, 2nd para, if the host receives an RA, why wouldn't it just use the current info in the RA; why would it try to reuse any cached info from a previous attachment? Also in the same para, what does it mean to receive a "DHCPv6 message [...] which contains prefixes that intersect with those previously advertised by a known router"? A DHCPv6 message contains assigned addresses and other configuration information, but no prefixes. I'm guessing the idea is to use the DHCPv6 response as an optimization, in case it is received before any NA or RA messages. If I have that right, then the check would have to be that the set of addresses in the DHCPv6 message matches the set of previously assigned addresses associated with the probed router. |
2009-11-18
|
17 | Amy Vezza | State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Amy Vezza |
2009-11-18
|
17 | Tim Polk | [Ballot comment] From Yaron's secdir review: 4.1: DUID - is this the host’s DUID or the router's? Per RFC 3315, both have such a … [Ballot comment] From Yaron's secdir review: 4.1: DUID - is this the host’s DUID or the router's? Per RFC 3315, both have such a value. 4.3: "all currently configured IP addresses" - but only for this physical interface, right? 4.8: why is no DAD performed? Someone else might have joined the network while I was disconnected, and has a duplicate of my address. |
2009-11-18
|
17 | Tim Polk | [Ballot discuss] There are three issues that I would like to see addressed before moving to No Objection. (1) [Note: this is in direct conflict … [Ballot discuss] There are three issues that I would like to see addressed before moving to No Objection. (1) [Note: this is in direct conflict with Russ's discuss!] Brian Carpenter suggested that the "Updates 4861" be removed in his Gen-ART review. I believe this document does update 4861. Specifically Section 6.2.6 of RFC 4861 states: In all cases, Router Advertisements sent in response to a Router Solicitation MUST be delayed by a random time between 0 and MAX_RA_DELAY_TIME seconds. Section 2.4 of draft-ietf-dna-simple states: As a result, in addition to implementing simple DNA, it is desirable that routers adopt procedures which allow for fast unicast Router Advertisement (RA) messages. My interpretation of this statement is that a shorter delay is recommended, which would be an update to 4861. (Am I misinterpreting this text?) (2) Assuming my interpretation regarding the update to 4861 is correct, I believe that the shorter delay has implications for congestion control and for security (specifcally DoS attacks). These implications need to be addressed in the document - the latter should be addressed in the security considerations. (3) Yaron Sheffer suggested the following addition to the security considerations The DNA procedure does not in itself provide positive, secure authentication of the router(s) on the network, or authentication of the network itself, as e.g. would be provided by mutual authentication at the link layer. Therefore when such assurance is not available, the host MUST NOT make any security-sensitive decisions based on the DNA procedure. In particular, it MUST NOT decide it has rejoined a network known to be physically secure, and proceed to abandon cryptographic protection. I believe that something along that line would be a sensible addition. |
2009-11-18
|
17 | Tim Polk | [Ballot Position Update] New position, Discuss, has been recorded by Tim Polk |
2009-11-18
|
17 | Lisa Dusseault | [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault |
2009-11-18
|
17 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica |
2009-11-18
|
17 | Cullen Jennings | [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings |
2009-11-17
|
17 | Ralph Droms | [Ballot comment] In section 4.4: 4.4. Sending Neighbor Discovery probes When a host receives a link-layer "up" indication, it SHOULD immediately send both … [Ballot comment] In section 4.4: 4.4. Sending Neighbor Discovery probes When a host receives a link-layer "up" indication, it SHOULD immediately send both a Router Solicitation ^^^ I think the text "as specified in section 6.3.7 of RFC 4861" should be added here, to confirm that the delay rules should be followed. === Also in section 4.4, the text constraining the candidate set to valid addresses is redundantly in both paragraphs; I suggest deleting the first and changing the second to a MUST NOT requirement: For the purpose of sending neighbor solicitations to previous routers, the host first identifies the set of operable IPv6 addresses (candidate set) that it wishes to use. If the addresses obtained from a previous router are no longer valid, the host does not include these addresses in the candidate set for NS based probing. For each of the addresses in the candidate set, the host looks up the SDAT to find out the link-local and MAC addresses of the router that advertised the prefix used to form the address. It then sends an unicast Neighbor Solicitations to each router's link-local address it obtained from the lookup on the SDAT. The host SHOULD NOT send unicast Neighbor Solicitations to a test node corresponding to an IPv6 address that is no longer valid. And, it would be a little more clear to explicitly explain "IPv6 address for which the valid lifetime has expired". |
2009-11-17
|
17 | Ralph Droms | [Ballot discuss] n section 4.1, I think the host also has to record the IAID along with the DUID, to make sure the DHCP server … [Ballot discuss] n section 4.1, I think the host also has to record the IAID along with the DUID, to make sure the DHCP server associates the SOLICIT with previous DHCPv6 message exchanges with this host. In section 4.7.1: On reception of a Router Advertisement or advertising DHCPv6 message (a REPLY or ADVERTISE) which contains prefixes that intersect with those previously advertised by a known router, the host utilizes the configuration associated with the detected network. does the DHCPv6 client continue with the DHCPv6 message exchange in the case where an ADVERTISE is received or does it simply terminate and reuse the previous DHCPv6 configuration? And, what does the host do if it receives a REPLY message indicating it is on a previously visited link but the information in the IA_NA/IA_TA doesn't exactly match the previous information? |
2009-11-17
|
17 | Ralph Droms | [Ballot Position Update] New position, Discuss, has been recorded by Ralph Droms |
2009-11-17
|
17 | Ralph Droms | [Ballot comment] In section 4.4: 4.4. Sending Neighbor Discovery probes When a host receives a link-layer "up" indication, it SHOULD immediately send both … [Ballot comment] In section 4.4: 4.4. Sending Neighbor Discovery probes When a host receives a link-layer "up" indication, it SHOULD immediately send both a Router Solicitation ^^^ I think the text "as specified in section 6.3.7 of RFC 4861" should be added here, to confirm that the delay rules should be followed. === Also in section 4.4, the text constraining the candidate set to valid addresses is redundantly in both paragraphs; I suggest deleting the first and changing the second to a MUST NOT requirement: For the purpose of sending neighbor solicitations to previous routers, the host first identifies the set of operable IPv6 addresses (candidate set) that it wishes to use. If the addresses obtained from a previous router are no longer valid, the host does not include these addresses in the candidate set for NS based probing. For each of the addresses in the candidate set, the host looks up the SDAT to find out the link-local and MAC addresses of the router that advertised the prefix used to form the address. It then sends an unicast Neighbor Solicitations to each router's link-local address it obtained from the lookup on the SDAT. The host SHOULD NOT send unicast Neighbor Solicitations to a test node corresponding to an IPv6 address that is no longer valid. Also, it would be a little more clear to explicitly explain "IPv6 address for which the valid lifetime has expired". ==== |
2009-11-17
|
17 | Dan Romascanu | [Ballot Position Update] Position for Dan Romascanu has been changed to No Objection from Discuss by Dan Romascanu |
2009-11-17
|
17 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded by Adrian Farrel |
2009-11-16
|
17 | Russ Housley | [Ballot discuss] As already reported in the Gen-ART Review by Brian Carpenter, the "Updates: 4861" should be removed from the cover page. This … [Ballot discuss] As already reported in the Gen-ART Review by Brian Carpenter, the "Updates: 4861" should be removed from the cover page. This specification makes normative references to RFC 4861, it does not update it. An RFC Editor Note seems like a fine solution. |
2009-11-16
|
17 | Russ Housley | [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley |
2009-11-15
|
17 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded by Alexey Melnikov |
2009-11-03
|
17 | Lars Eggert | [Ballot comment] Section 2.2., paragraph 1: > The Simple DNA protocol provides substantial benefits in some > scenarios and does not provide any … [Ballot comment] Section 2.2., paragraph 1: > The Simple DNA protocol provides substantial benefits in some > scenarios and does not provide any benefit at all in certain other > scenarios. Compared to what? Section 4.1., paragraph 1: > In order to correctly perform the procedure described in this > document the host needs to maintain a data structure called the > Simple DNA address table (SDAT). This data structure is maintained > by the host on a per interface basis. Why per-interface? Can't this be shared among all interfaces? Section 4.3., paragraph 2: > After the indication is received, the host considers all currently > configured (non-tentative) IP addresses to be deprecated until the > change detection process completes. It SHOULD also set all Neighbor > Cache entries for the routers on its Default Router List to STALE. Why SHOULD and not MUST? Section 4.4., paragraph 1: > When a host receives a link-layer "up" indication, it SHOULD > immediately send both a Router Solicitation and if it retains at > least one valid IPv6 address, one or more unicast Neighbor > Solicitations. Why not MUST? Section 4.4., paragraph 4: > The host SHOULD NOT send > unicast Neighbor Solicitations to a test node corresponding to an > IPv6 address that is no longer valid. Why not MUST NOT? Section 4.6., paragraph 3: > Where an > existing valid address is being tested for operability, this address > should be placed in the Identity Association's IAADDR element, and > the DUID associated with that address should be copied to the DHCP > SOLICIT from the SDAT. should -> MUST? (2x) Section 4.7., paragraph 2: > On reception of a Router Advertisement or advertising DHCPv6 message > (a REPLY or ADVERTISE) which contains prefixes that intersect with > those previously advertised by a known router, the host utilizes the > configuration associated with the detected network. What exactly does "intersect" mean? Do you mean "all prefixes returned must match the prefixes in the SDAT associated with a router" or "at least one returned prefix must match one of the prefixes associated with a router in the SDAT?" Section 4.7., paragraph 3: > When the host receives an advertisement containing only prefixes > which are disjoint from known advertised prefixes, the host MUST > determine whether the solicited advertisement corresponds to any of > the routers probed via NS. Do you mean "disjoint" as in "doesn't match *any* of the prefixes associated with *any* router in the SDAT? Section 4.7., paragraph 4: > If it does, then the host SHOULD conclude > that the IPv6 addresses corresponding to that router are no longer > valid. Since any NS probes to that router will no longer provide > useful information, further probing of that router SHOULD be aborted. I think these need to be MUSTs, or else explain when it wouldn't be. Section 4.7., paragraph 6: > When the host receives a Router Advertisement in reply to the Router > Solicitation it sent, the host SHOULD look for a Neighbor Cache entry > for the sending router and SHOULD mark that router's Neighbor Cache > Entry as REACHABLE if one was found. The host SHOULD add a new > Neighbor Cache Entry in the REACHABLE state for the sending router if > one does not currently exist. I think all of the SHOULDs need to be MUSTs. |
2009-11-03
|
17 | Lars Eggert | [Ballot discuss] DISCUSS: I believe the majority of the SHOULDs in this ID should become MUSTs. Some examples below. Please check them all. Section … [Ballot discuss] DISCUSS: I believe the majority of the SHOULDs in this ID should become MUSTs. Some examples below. Please check them all. Section 2.4., paragraph 1: > Detecting Network Attachment is performed by hosts after detecting a > link-layer "up" indication. The host simultaneously sends multicast > Router Solicitations (RSs) and unicast Neighbor Solicitations (NSs) > in order to determine whether previously encountered routers are > present on the link. DISCUSS: Section 4.9 has appropriate text on handling retransmissions of a single probe. What I'm missing is some text that recommends an upper bound for how many previous networks should be probed for. Clearly, probing for hundreds of previously known networks will results in thousands of packets that will all be sent without any sort of congestion control, which would be a problem. Similarly, probing for a small number of previously known networks will be fine. Can we add a recommendation that says that you should limit yourself to probing for at most X (10?) previous network locations? |
2009-11-03
|
17 | Lars Eggert | [Ballot Position Update] New position, Discuss, has been recorded by Lars Eggert |
2009-10-30
|
17 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2009-10-26
|
11 | (System) | New version available: draft-ietf-dna-simple-11.txt |
2009-10-26
|
10 | (System) | New version available: draft-ietf-dna-simple-10.txt |
2009-10-22
|
17 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Yaron Sheffer |
2009-10-22
|
17 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Yaron Sheffer |
2009-10-21
|
17 | Amanda Baber | IANA comments: As described in the IANA Considerations section, we understand this document to have NO IANA Actions. |
2009-10-21
|
17 | Dan Romascanu | [Ballot discuss] The OPS-DIR review performed by Bernard Aboba raised a number of technical and editorial issues that need to be answered before approving this … [Ballot discuss] The OPS-DIR review performed by Bernard Aboba raised a number of technical and editorial issues that need to be answered before approving this document. Moreover, it states that the version of the document sent to IETF last call (now in IESG review) does not incorporate fixes to issues listed in the WG issue tracker as "fixed". This raises the possibility that changes from WG last call were not properly applied or even that the wrong version of the document may have been sent to IETF last call. |
2009-10-21
|
17 | Dan Romascanu | [Ballot discuss] The OPS-DIR review oerformed by Bernard Aboba raised a number of technical and editorial issues that need to be answered before approving this … [Ballot discuss] The OPS-DIR review oerformed by Bernard Aboba raised a number of technical and editorial issues that need to be answered before approving this document. Moreover, it states that the version of the document sent to IETF last call (now in IESG review) does not incorporate fixes to issues listed in the WG issue tracker as "fixed". This raises the possibility that changes from WG last call were not properly applied or even that the wrong version of the document may have been sent to IETF last call. |
2009-10-21
|
17 | Dan Romascanu | [Ballot Position Update] New position, Discuss, has been recorded by Dan Romascanu |
2009-10-16
|
17 | Jari Arkko | Placed on agenda for telechat - 2009-11-19 by Jari Arkko |
2009-10-16
|
17 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2009-10-15
|
17 | Jari Arkko | State Changes to Last Call Requested from AD Evaluation::AD Followup by Jari Arkko |
2009-10-15
|
17 | Jari Arkko | Last Call was requested by Jari Arkko |
2009-10-15
|
17 | Jari Arkko | [Ballot Position Update] New position, Yes, has been recorded for Jari Arkko |
2009-10-15
|
17 | Jari Arkko | Ballot has been issued by Jari Arkko |
2009-10-15
|
17 | Jari Arkko | Created "Approve" ballot |
2009-10-15
|
17 | (System) | Ballot writeup text was added |
2009-10-15
|
17 | (System) | Last call text was added |
2009-10-15
|
17 | (System) | Ballot approval text was added |
2009-10-15
|
17 | Jari Arkko | looks good |
2009-09-17
|
17 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2009-09-17
|
09 | (System) | New version available: draft-ietf-dna-simple-09.txt |
2009-08-24
|
17 | Jari Arkko | reminder sent to the authors |
2009-07-17
|
17 | Jari Arkko | State Changes to AD Evaluation::Revised ID Needed from AD Evaluation::AD Followup by Jari Arkko |
2009-07-17
|
17 | Jari Arkko | Still needs revision based on Bernard's new comments. |
2009-07-14
|
17 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2009-07-14
|
08 | (System) | New version available: draft-ietf-dna-simple-08.txt |
2009-07-09
|
17 | Jari Arkko | State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Jari Arkko |
2009-07-09
|
17 | Jari Arkko | I have reviewed this draft. Overall, the draft was easy to read and well written. I have no problem with the specified algorithms. However, the … I have reviewed this draft. Overall, the draft was easy to read and well written. I have no problem with the specified algorithms. However, the draft appears to contain a fair amount of extra material on Fast RAs and the full-blown dna-protocol that WG worked earlier on. These need to be removed; the specification can and should stand on its own, and not depend on these other components. In addition, there are a few small technical issues. Here are my specific comments: Substantial: > The probing node SHOULD include a Source link-layer address option in the probe messages. If the node believes that the source address of the NS may not be unique on the newly attached link, it MAY omit the Source link-layer address option in the probe messages. I would like to understand this better. How does a general purpose operating system implementation deal with the above? How does it know that "the source address of the NS may not be unique"? AFAICT, if you omit the SLLA and no link change happened, then most likely the router will remember your NC anyway, and be able to respond. However, if it does not remember you, a new NS/NA would be required, but DNA would still succeed, albeit a bit slower. However, if the host did move to a new link, then including the SLLA might cause disruption for another host that already holds the same address but uses a different link layer address. Why is the recommendation written as it is above? Is the assumption that colliding addresses are so rare that the optimization makes sense? On the other hand, it would appear that even without the SLLA DNA would still work in most cases. In any case, I don't think we can require general purpose implementations to assess the likelihood of collisions. Perhaps it would be easier to require that by default, no SLLA is included and that only through specific configuration option the SLLA use can be turned on and DNA made to operate faster/more reliably. > For the purpose of sending neighbor solicitations to previous > routers, the host first needs to pick a subset of operable IPv6 > addresses (candidate set) that it wishes to use. How this subset of > addresses is picked is based on host configuration. e.g. The host > may select configured addresses from each of zero, one or two > previously connected links. Please specify a default strategy. E.g., "How this subset of addresses is picked is based on host configuration. By default the host should select configured addresses from two previously connected links." > Where flooding may cause performance issues within the LAN, host SHOULD limit the number of unicast solicitations. Again, the guidance for general purpose implementations in inadequate. Please specify a default strategy. I believe limiting the number of unicast solicitations to some small number (4?) by default is adequate (there are a number of messages on a new link even on DNAv4 and regular ND). > The probing node SHOULD NOT include a Source link-layer address > option if it has not performed duplicate address detection [RFC4862], > for the source address of the NS, on the newly attached link. > Performed DAD, when? Presumably it has been performed when the address first configured, no? And since DNA is the first thing that runs after a link change, DAD has not been run at this point either. So what does your recommendation really mean here? Never include SLLA? In any case, at this point we do not yet *know* if we are on a newly attached link or not. Therefore, we do not know if we've run DAD in the past on this link. Please clarify. > Hosts checking their network attachment are unsure of their address > status, and may be using Tentative link-layer addressing information > in their router or neighbour solicitations. > > A router which desires to support hosts' DNA operations MUST process > Tentative Options from unicast source addressed Router and Neighbour > Solicitations, as described in [I-D.ietf-dna-tentative]. This is the first time dna-tentative is referenced in this document. I wonder if there's really a need to have a normative reference, or even mention this. > 7. Constants > > > These constants are described as in [I-D.ietf-dna-protocol]. > > UNICAST_RA_INTERVAL > > Definition: The interval corresponding to the maximum average > rate of Router Solicitations that the router is prepared to > service with unicast responses. This is the interval at which > the token bucket controlling the unicast responses is > replenished. > > Value: 50 milliseconds > > MAX_UNICAST_RA_BURST > > Definition: The maximum size burst of Router Solicitations that > the router is prepared to service with unicast responses. This > is the maximum number of tokens allowed in the token bucket > controlling the unicast responses. > > Value: 20 > None of these appear to have anything to do with the Simple DNA procedure. Please remove. The only item that I can see be of relevance in this section is SEND_NA_GRACE_TIME. > When providing fast responses to router solicitations, it is possible > to cause collisions with other signaling packets on contention based > media. This can cause repeated packet loss or delay when multiple > routers are present on the link. > > As such the fast router advertisement system is NOT RECOMMENDED in > this form for media which are susceptible to collision loss. Such > environments may be better served using the procedures defined in > [I-D.ietf-dna-protocol]. This does not appear to have anything to do with Simple DNA either (router-side fast responses are not a subject of this specification). Delete? > The host MAY delay SEND_NA_GRACE_TIME after transmission before > adopting a new default router, if it is operating on a network where > there is significant threat of RA spoofing. I would simply say that this delay MAY be imposed when the host's current default router is a SEND-secured one. This prevents the downgrade from SEND to non-SEND, but does not require any configuration, and it doesn't slow things down when you were already using a non-SEND router. > It is easy for hosts soliciting without SEND to deplete a SEND > router's fast advertisement token buckets, and consume additional > bandwidth. As such, a router MAY choose to preserve a portion of > their token bucket to serve solicitations with SEND signatures. Again, this has very little to do with this specification. Move this to the fast RA spec instead. Editorial: Move draft-ietf-dna-protocol to informative references. > After the indication is received, the host considers all currently configured (non-tentative) IP addresses to as deprecated until the change detection process completes. s/to as/to be/ > addresses is picked is based on host configuration. e.g. The host s/The/the/ > If systems do not meet these assumptions or if systems seek deterministic change detection operations they are directed to follow the complete dna procedure as defined in [I-D.ietf-dna-protocol]. I would just delete this. I do not think we want to make what sounds like a fairly strong recommendation. Section 4.5.1 mentions that there are no options, while Setion 4.5.2 does not. > message contains an Identity Addociation for either a Temporary Association? |
2009-07-03
|
07 | (System) | New version available: draft-ietf-dna-simple-07.txt |
2009-06-16
|
17 | Jari Arkko | State Changes to AD Evaluation from Publication Requested by Jari Arkko |
2009-06-16
|
17 | Amy Vezza | Title : Simple procedures for Detecting Network Attachment in IPv6 Filename: draft-ietf-dna-simple-06.txt PROTO Information ================= Technical Summary ================= Working Group Summary ===================== The dna working … Title : Simple procedures for Detecting Network Attachment in IPv6 Filename: draft-ietf-dna-simple-06.txt PROTO Information ================= Technical Summary ================= Working Group Summary ===================== The dna working group reached consensus on this document during the face to face meetings and on the DNA mailing list. There was strong support for the document from key contributors to the WG and no opposition. Protocol Quality ================ This document and has been reviewed by the dna working group and the required changes have been incorporated into the document. PROTO Questionnare ================== 1.a) Have the chairs personally reviewed this version of the Internet Draft (ID), and in particular, do they believe this ID is ready to forward to the IESG for publication? -> Yes. 1.b) Has the document had adequate review from both key WG members and key non-WG members? Do you have any concerns about the depth or breadth of the reviews that have been performed? -> Yes. There have been no comments from the 6man working group list, and since this is an update to neighbor discovery (RFC4861), this is concerning. 1.c) Do you have concerns that the document needs more review from a particular (broader) perspective (e.g., security, operational complexity, someone familiar with AAA, etc.)? -> No. 1.d) Do you have any specific concerns/issues with this document that you believe the ADs and/or IESG should be aware of? For example, perhaps you are uncomfortable with certain parts of the document, or have concerns whether there really is a need for it. In any event, if your issues have been discussed in the WG and the WG has indicated it that it still wishes to advance the document, detail those concerns in the write-up. -> No. 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? -> Strong support from key contributors to the WG and no opposition from the WG members at large. 1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email to the Responsible Area Director. -> No. 1.g) Have the chairs verified that the document adheres to all of the ID nits? (see http://www.ietf.org/ID-Checklist.html). -> Yes. 1.h) Is the document split into normative and informative references? Are there normative references to IDs, where the IDs are not also ready for advancement or are otherwise in an unclear state? (note here that the RFC editor will not publish an RFC with normative references to IDs, it will delay publication until all such IDs are also ready for publication as RFCs.) -> The document is split into normative and informative references. There are no normative references to IDs, which are not ready for advancement. |
2009-06-16
|
17 | Amy Vezza | Draft Added by Amy Vezza in state Publication Requested |
2009-06-16
|
17 | Amy Vezza | [Note]: '(no document shepherd)' added by Amy Vezza |
2009-02-24
|
06 | (System) | New version available: draft-ietf-dna-simple-06.txt |
2008-11-03
|
05 | (System) | New version available: draft-ietf-dna-simple-05.txt |
2008-10-28
|
04 | (System) | New version available: draft-ietf-dna-simple-04.txt |
2008-10-03
|
03 | (System) | New version available: draft-ietf-dna-simple-03.txt |
2008-07-13
|
02 | (System) | New version available: draft-ietf-dna-simple-02.txt |
2008-07-03
|
01 | (System) | New version available: draft-ietf-dna-simple-01.txt |
2008-04-04
|
00 | (System) | New version available: draft-ietf-dna-simple-00.txt |