Softwire Hub and Spoke Deployment Framework with Layer Two Tunneling Protocol Version 2 (L2TPv2)
draft-ietf-softwire-hs-framework-l2tpv2-13
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
13 | (System) | post-migration administrative database adjustment to the No Objection position for Pasi Eronen |
2012-08-22
|
13 | (System) | post-migration administrative database adjustment to the No Objection position for Tim Polk |
2012-08-22
|
13 | (System) | post-migration administrative database adjustment to the No Objection position for Dan Romascanu |
2012-08-22
|
13 | (System) | post-migration administrative database adjustment to the No Objection position for Russ Housley |
2009-05-15
|
13 | Cindy Morgan | State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan |
2009-05-14
|
13 | (System) | IANA Action state changed to No IC from In Progress |
2009-05-14
|
13 | (System) | IANA Action state changed to In Progress |
2009-05-14
|
13 | Amy Vezza | IESG state changed to Approved-announcement sent |
2009-05-14
|
13 | Amy Vezza | IESG has approved the document |
2009-05-14
|
13 | Amy Vezza | Closed "Approve" ballot |
2009-05-14
|
13 | Amy Vezza | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza |
2009-05-14
|
13 | Ralph Droms | [Ballot Position Update] New position, Yes, has been recorded by Ralph Droms |
2009-04-21
|
13 | Dan Romascanu | [Ballot comment] |
2009-04-13
|
13 | Dan Romascanu | [Ballot Position Update] Position for Dan Romascanu has been changed to No Objection from Discuss by Dan Romascanu |
2009-04-13
|
13 | (System) | New version available: draft-ietf-softwire-hs-framework-l2tpv2-13.txt |
2009-04-07
|
13 | Ralph Droms | Responsible AD has been changed to Ralph Droms from Mark Townsley |
2009-04-06
|
13 | Dan Romascanu | [Ballot discuss] Updated DISCUSS, taking out one of the issues, clarifiedin discussions with the editors. Presently, not all the scenarios described in the document are … [Ballot discuss] Updated DISCUSS, taking out one of the issues, clarifiedin discussions with the editors. Presently, not all the scenarios described in the document are properly supported by AAA. As a result, the document redefines existing uses of RADIUS standard attributes, as well as suggests implementation of documents that are currently still Internet Drafts. Section 8 updates several existing RADIUS standards RFCs, including: * RFC 2868, by defining new interpretations of the Tunnel-Client-Endpoint and Tunnel-Server-Endpoint attributes in situations where addressing attributes are not present. * RFC 2865, by defining new interpretations of the Framed-IP-Address and Framed-IP-Netmask attributes. Is this really appropriate for a framework document? > 8.1. Softwire Endpoints 8.1.1. IPv6 Softwires If the RADIUS server includes a Framed-Interface-Id attribute [RFC3162], the Softwire Concentrator must send it to the Softwire Initiator in the Interface-Identifier field of its IPV6CP Configuration Request message. If the Framed-IPv6-Prefix attribute [RFC3162] is included, that prefix must be used in the router advertisements sent to the SI. If Framed-IPv6-Prefix is not present but Framed-IPv6-Pool is, the SC must choose a prefix with that pool to send RAs. If none of the attributes above are included but the AAA server returns the Tunnel-Client-Endpoint and Tunnel-Server-Endpoint attributes [RFC2868] with the correct address family, these must be used in the IPV6CP Interface-Identifier and for the Router Advertisements. The above paragraph defines new interpretations of these attributes. > 8.1.2. IPv4 Softwires If the Framed-IP-Address attribute [RFC2865] is present, the Softwire Concentrator must provide that address to the Softwire Initiator during IPCP address negotiation. That is, when the Softwire Initiator requests an IP address from the Softwire Concentrator, the address provided should be the Framed-IP-Address. If the Framed-IP-Address attribute is not present and the Tunnel- Client-Endpoint and Tunnel-Server-Endpoint attributes [RFC2868] are present and of the correct address family, these should be used in the IPCP IP-Address configuration option. The above paragraph defines new interpretations of these attributes. > 8.2. Delegated Prefixes > 8.2.2. IPv4 Prefixes The combination of the Framed-IP-Address and Framed-IP-Netmask attributes [RFC2865] may be used by the Softwire Concentrator to delegate an IPv4 prefix to the Softwire Initiator. The above paragraph defines new interpretations of these attributes. |
2009-03-27
|
13 | Tim Polk | [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Undefined by Tim Polk |
2009-03-27
|
13 | Tim Polk | [Ballot Position Update] Position for Tim Polk has been changed to Undefined from Discuss by Tim Polk |
2009-03-18
|
13 | Dan Romascanu | RFC 2866, by referencing draft-stevant-softwire-accounting, which redefines the format of the NAS-IP-Address attribute (which only supports IPv4 addresses; NAS-IPv6-Address is used to contain … RFC 2866, by referencing draft-stevant-softwire-accounting, which redefines the format of the NAS-IP-Address attribute (which only supports IPv4 addresses; NAS-IPv6-Address is used to contain IPv6 addresses). Is this really appropriate for a framework document? From draft-stevant-software-accounting-01.txt: A RADIUS accounting entry, as defined in [RFC2867], also includes the NASIPAddress attribute, which gives the IP address of the NAS used as the softwire endpoint. Based on this information, an operator can decide if this softwire is based on IPv4 or IPv6. In the case of provider only deploying IPv6 over IPv4 and IPv4 over IPv6 softwires, the nature of the traffic reported in the accounting information depends of the address family of NASIPAddress (if NASIPAddress is IPv4, accounted traffic is IPv6, if NASIPAddress is IPv6, accounted traffic is IPv4). However, this solution requires extra checking when building accounting report and obviously does not work in case of IPvX over IPvX softwires. |
2009-03-18
|
13 | Dan Romascanu | [Ballot discuss] Presently, not all the scenarios described in the document are properly supported by AAA. As a result, the document redefines existing uses of … [Ballot discuss] Presently, not all the scenarios described in the document are properly supported by AAA. As a result, the document redefines existing uses of RADIUS standard attributes, as well as suggests implementation of documents that are currently still Internet Drafts. Section 8 updates several existing RADIUS standards RFCs, including: * RFC 2868, by defining new interpretations of the Tunnel-Client-Endpoint and Tunnel-Server-Endpoint attributes in situations where addressing attributes are not present. * RFC 2865, by defining new interpretations of the Framed-IP-Address and Framed-IP-Netmask attributes. Is this really appropriate for a framework document? > 8.1. Softwire Endpoints 8.1.1. IPv6 Softwires If the RADIUS server includes a Framed-Interface-Id attribute [RFC3162], the Softwire Concentrator must send it to the Softwire Initiator in the Interface-Identifier field of its IPV6CP Configuration Request message. If the Framed-IPv6-Prefix attribute [RFC3162] is included, that prefix must be used in the router advertisements sent to the SI. If Framed-IPv6-Prefix is not present but Framed-IPv6-Pool is, the SC must choose a prefix with that pool to send RAs. If none of the attributes above are included but the AAA server returns the Tunnel-Client-Endpoint and Tunnel-Server-Endpoint attributes [RFC2868] with the correct address family, these must be used in the IPV6CP Interface-Identifier and for the Router Advertisements. The above paragraph defines new interpretations of these attributes. > 8.1.2. IPv4 Softwires If the Framed-IP-Address attribute [RFC2865] is present, the Softwire Concentrator must provide that address to the Softwire Initiator during IPCP address negotiation. That is, when the Softwire Initiator requests an IP address from the Softwire Concentrator, the address provided should be the Framed-IP-Address. If the Framed-IP-Address attribute is not present and the Tunnel- Client-Endpoint and Tunnel-Server-Endpoint attributes [RFC2868] are present and of the correct address family, these should be used in the IPCP IP-Address configuration option. The above paragraph defines new interpretations of these attributes. > 8.2. Delegated Prefixes 8.2.1. IPv6 Prefixes If the attribute Delegated-IPv6-Prefix [RFC4818] is present in the RADIUS Access-Accept message, it must be used by the Softwire Concentrator for the delegation of the IPv6 prefix. Since the prefix delegation is performed by DHCPv6 and the attribute is linked to a username, the SC must associate the DHCP Unique Identifier (DUID) of a DHCPv6 request to the tunnel it came from and its user. Interaction between RADIUS, PPP and DHCPv6 server may follow the mechanism proposed in [I-D.ietf-dhc-v6-relay-radius]. In this case, during the Softwire authentication phase, PPP collects the RADIUS attributes for the user such as Delegated-IPv6-Prefix. A specific DHCPv6 relay is assigned to the Softwire. The DHCPv6 relay fills in these attributes in the Relay agent RADIUS Attribute Option (RRAO) DHCPv6 option, before forwarding the DHCPv6 requests to the DHCPv6 server. The above paragraph makes what would appear to be a normative reference to an I-D - however this document is listed as informational reference. > 8.2.2. IPv4 Prefixes The combination of the Framed-IP-Address and Framed-IP-Netmask attributes [RFC2865] may be used by the Softwire Concentrator to delegate an IPv4 prefix to the Softwire Initiator. The above paragraph defines new interpretations of these attributes. |
2009-03-18
|
13 | Dan Romascanu | [Ballot comment] |
2009-03-18
|
13 | Dan Romascanu | [Ballot discuss] Presently, not all the scenarios described in the document are properly supported by AAA. As a result, the document redefines existing uses of … [Ballot discuss] Presently, not all the scenarios described in the document are properly supported by AAA. As a result, the document redefines existing uses of RADIUS standard attributes, as well as suggests implementation of documents that are currently still Internet Drafts. Section 8 updates several existing RADIUS standards RFCs, including: * RFC 2868, by defining new interpretations of the Tunnel-Client-Endpoint and Tunnel-Server-Endpoint attributes in situations where addressing attributes are not present. * RFC 2865, by defining new interpretations of the Framed-IP-Address and Framed-IP-Netmask attributes. * RFC 2866, by referencing draft-stevant-softwire-accounting, which redefines the format of the NAS-IP-Address attribute (which only supports IPv4 addresses; NAS-IPv6-Address is used to contain IPv6 addresses). Is this really appropriate for a framework document? From draft-stevant-software-accounting-01.txt: A RADIUS accounting entry, as defined in [RFC2867], also includes the NASIPAddress attribute, which gives the IP address of the NAS used as the softwire endpoint. Based on this information, an operator can decide if this softwire is based on IPv4 or IPv6. In the case of provider only deploying IPv6 over IPv4 and IPv4 over IPv6 softwires, the nature of the traffic reported in the accounting information depends of the address family of NASIPAddress (if NASIPAddress is IPv4, accounted traffic is IPv6, if NASIPAddress is IPv6, accounted traffic is IPv4). However, this solution requires extra checking when building accounting report and obviously does not work in case of IPvX over IPvX softwires. > 8.1. Softwire Endpoints 8.1.1. IPv6 Softwires If the RADIUS server includes a Framed-Interface-Id attribute [RFC3162], the Softwire Concentrator must send it to the Softwire Initiator in the Interface-Identifier field of its IPV6CP Configuration Request message. If the Framed-IPv6-Prefix attribute [RFC3162] is included, that prefix must be used in the router advertisements sent to the SI. If Framed-IPv6-Prefix is not present but Framed-IPv6-Pool is, the SC must choose a prefix with that pool to send RAs. If none of the attributes above are included but the AAA server returns the Tunnel-Client-Endpoint and Tunnel-Server-Endpoint attributes [RFC2868] with the correct address family, these must be used in the IPV6CP Interface-Identifier and for the Router Advertisements. The above paragraph defines new interpretations of these attributes. > 8.1.2. IPv4 Softwires If the Framed-IP-Address attribute [RFC2865] is present, the Softwire Concentrator must provide that address to the Softwire Initiator during IPCP address negotiation. That is, when the Softwire Initiator requests an IP address from the Softwire Concentrator, the address provided should be the Framed-IP-Address. If the Framed-IP-Address attribute is not present and the Tunnel- Client-Endpoint and Tunnel-Server-Endpoint attributes [RFC2868] are present and of the correct address family, these should be used in the IPCP IP-Address configuration option. The above paragraph defines new interpretations of these attributes. > 8.2. Delegated Prefixes 8.2.1. IPv6 Prefixes If the attribute Delegated-IPv6-Prefix [RFC4818] is present in the RADIUS Access-Accept message, it must be used by the Softwire Concentrator for the delegation of the IPv6 prefix. Since the prefix delegation is performed by DHCPv6 and the attribute is linked to a username, the SC must associate the DHCP Unique Identifier (DUID) of a DHCPv6 request to the tunnel it came from and its user. Interaction between RADIUS, PPP and DHCPv6 server may follow the mechanism proposed in [I-D.ietf-dhc-v6-relay-radius]. In this case, during the Softwire authentication phase, PPP collects the RADIUS attributes for the user such as Delegated-IPv6-Prefix. A specific DHCPv6 relay is assigned to the Softwire. The DHCPv6 relay fills in these attributes in the Relay agent RADIUS Attribute Option (RRAO) DHCPv6 option, before forwarding the DHCPv6 requests to the DHCPv6 server. The above paragraph makes what would appear to be a normative reference to an I-D - however this document is listed as informational reference. > 8.2.2. IPv4 Prefixes The combination of the Framed-IP-Address and Framed-IP-Netmask attributes [RFC2865] may be used by the Softwire Concentrator to delegate an IPv4 prefix to the Softwire Initiator. The above paragraph defines new interpretations of these attributes. |
2009-03-12
|
13 | Pasi Eronen | [Ballot Position Update] Position for Pasi Eronen has been changed to No Objection from Discuss by Pasi Eronen |
2009-03-09
|
13 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley |
2009-03-08
|
12 | (System) | New version available: draft-ietf-softwire-hs-framework-l2tpv2-12.txt |
2009-02-10
|
13 | Pasi Eronen | [Ballot discuss] [updated for version -11] I have reviewed draft-ietf-softwire-hs-framework-l2tpv2-11, and found it surprisingly easy to understand, and very clearly written. I have a … [Ballot discuss] [updated for version -11] I have reviewed draft-ietf-softwire-hs-framework-l2tpv2-11, and found it surprisingly easy to understand, and very clearly written. I have a couple of (mostly minor) concerns that I'd like to discuss before recommending approval of the document: - Figures 9 and 10 should also show the IPsec-related steps (marked as "Optional"). - The details of how RFC43xx IPsec is used to protect L2TP are in the softwire-security-requirements draft -- that probably should be a normative reference? (I'm assuming the intent is that the security-requirements draft meets the "For IPsec, default profiles must be defined" requirement from RFC 4925). |
2009-02-09
|
13 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2009-02-09
|
11 | (System) | New version available: draft-ietf-softwire-hs-framework-l2tpv2-11.txt |
2009-01-16
|
13 | (System) | Removed from agenda for telechat - 2009-01-15 |
2009-01-15
|
13 | Cindy Morgan | State Changes to IESG Evaluation::Revised ID Needed from Waiting for AD Go-Ahead by Cindy Morgan |
2009-01-15
|
13 | (System) | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko by IESG Secretary |
2009-01-15
|
13 | Jari Arkko | [Ballot comment] > If Framed-IPv6-Prefix is not present but Framed-IPv6-Pool is, the SC > must choose a prefix with that pool to send RAs. from … [Ballot comment] > If Framed-IPv6-Prefix is not present but Framed-IPv6-Pool is, the SC > must choose a prefix with that pool to send RAs. from that pool? |
2009-01-15
|
13 | David Ward | [Ballot Position Update] New position, Recuse, has been recorded by David Ward |
2009-01-15
|
13 | Ross Callon | [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon |
2009-01-15
|
13 | Tim Polk | [Ballot discuss] This is a discuss- discuss. To be clear, I am not asking for any changes to the document at this time. I would … [Ballot discuss] This is a discuss- discuss. To be clear, I am not asking for any changes to the document at this time. I would like to discuss the following issue to see if any change is appropriate. The security considerations section begins with: A detailed discussion of Softwire security is contained in [I-D.ietf-softwire-security-requirements]. This is a very useful reference, with nearly 12 pages devoted to the "Hubs and Spokes Security Guidelines". This justifies the relatively brief nature of the remaining security considerations text. However, [I-D.ietf-softwire-security-requirements] expired in August 2008. Without [I-D.ietf-softwire-security-requirements], the security considerations in this document are clearly inadequate. What is the prognosis for [I-D.ietf-softwire-security-requirements]? That is how long before it will be ready for an IETF Last Call? I am wondering whether some of the most important points from [I-D.ietf-softwire-security-requirements] need to be replicated here, or if others feel that would be overkill... |
2009-01-15
|
13 | Tim Polk | [Ballot Position Update] New position, Discuss, has been recorded by Tim Polk |
2009-01-15
|
13 | Jon Peterson | [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson |
2009-01-15
|
13 | Pasi Eronen | [Ballot discuss] I have reviewed draft-ietf-softwire-hs-framework-l2tpv2-10, and found it surprisingly easy to understand, and very clearly written. I have a couple of (mostly minor) … [Ballot discuss] I have reviewed draft-ietf-softwire-hs-framework-l2tpv2-10, and found it surprisingly easy to understand, and very clearly written. I have a couple of (mostly minor) concerns that I'd like to discuss before recommending approval of the document: - L2TP runs over UDP in a rather strange way, and the SCCRP message (reply from SC to SI) can come from different IP address and port than where the SCCRQ (1st message from SI to SC) was sent to. This obviously doesn't work with NATs that do "Address-Dependent Filtering" or "Address and Port-Dependent Filtering" (in RFC 4787 terminology). Should this document say something about the situation? Or even mandate that the addresses/ports in SCCRP must be the addresses/ports in SCCRQ reversed? (This issue is mentioned in the security requirements draft when talking about IPsec, as it complicates IPsec interaction -- but it applies even when not using IPsec). - Figures 9 and 10 should also show the IPsec-related steps (marked as "Optional"). - The details of how RFC43xx IPsec is used to protect L2TP are in the softwire-security-requirements draft -- that probably should be a normative reference? (I'm assuming the intent is that the security-requirements draft meets the "For IPsec, default profiles must be defined" requirement from RFC 4925). |
2009-01-15
|
13 | Pasi Eronen | [Ballot Position Update] New position, Discuss, has been recorded by Pasi Eronen |
2009-01-15
|
13 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund |
2009-01-15
|
13 | Dan Romascanu | [Ballot comment] 1. 4.3. Authentication Authorization Accounting RFC 2865 "Remote Authentication Dial In User Service (RADIUS)" … [Ballot comment] 1. 4.3. Authentication Authorization Accounting RFC 2865 "Remote Authentication Dial In User Service (RADIUS)" [RFC2865]. Updated by RFC2868, RFC3575, RFC5080. 2. Please avoid using the acronym OAM for Operations and Management. OAM stands for too many things that are close but not the same, and we intent to start recommending that the acronyms are used in the IETF in a consistent manner. Section 2.7 is OK, just get rid of the acronyms. |
2009-01-15
|
13 | Dan Romascanu | [Ballot comment] 4.3. Authentication Authorization Accounting RFC 2865 "Remote Authentication Dial In User Service (RADIUS)" [ … |
2009-01-15
|
13 | Dan Romascanu | [Ballot discuss] 1. It is not clear what is the scope of section 4 - Standardization Status. Are all the RFCs listed in this section … [Ballot discuss] 1. It is not clear what is the scope of section 4 - Standardization Status. Are all the RFCs listed in this section required for the interoperability and correct operation of Softwire implementations? In this case I would expect this to be clearly mentioned and that all references belong to the Norative References section. Some are currently listed as Informative. 2. Section 4.3 makes reference to two RFCs (1471, 1473) that include MIB documents written in SMIv1. The use of SMIv1 is allowed under certain conditions - the principal from a syntactic point of view being that the module translates easily in SMIv2 which is conditioned by the fact that they do not include deprecated SYNTAX elements like Opaque or IPAddress. Were these aspects checked wrt. to RFC 1471 and RFC 1473? Also related to the same two RFCs - the informational model described there refers to a version of PPP which was sinced updated by RFC 1548 and then by RFC 1661. Is this information model still valid? 3. Presently, not all the scenarios described in the document are properly supported by AAA. As a result, the document redefines existing uses of RADIUS standard attributes, as well as suggests implementation of documents that are currently still Internet Drafts. Section 8 updates several existing RADIUS standards RFCs, including: * RFC 2868, by defining new interpretations of the Tunnel-Client-Endpoint and Tunnel-Server-Endpoint attributes in situations where addressing attributes are not present. * RFC 2865, by defining new interpretations of the Framed-IP-Address and Framed-IP-Netmask attributes. * RFC 2866, by referencing draft-stevant-softwire-accounting, which redefines the format of the NAS-IP-Address attribute (which only supports IPv4 addresses; NAS-IPv6-Address is used to contain IPv6 addresses). Is this really appropriate for a framework document? From draft-stevant-software-accounting-01.txt: A RADIUS accounting entry, as defined in [RFC2867], also includes the NASIPAddress attribute, which gives the IP address of the NAS used as the softwire endpoint. Based on this information, an operator can decide if this softwire is based on IPv4 or IPv6. In the case of provider only deploying IPv6 over IPv4 and IPv4 over IPv6 softwires, the nature of the traffic reported in the accounting information depends of the address family of NASIPAddress (if NASIPAddress is IPv4, accounted traffic is IPv6, if NASIPAddress is IPv6, accounted traffic is IPv4). However, this solution requires extra checking when building accounting report and obviously does not work in case of IPvX over IPvX softwires. > 8.1. Softwire Endpoints 8.1.1. IPv6 Softwires If the RADIUS server includes a Framed-Interface-Id attribute [RFC3162], the Softwire Concentrator must send it to the Softwire Initiator in the Interface-Identifier field of its IPV6CP Configuration Request message. If the Framed-IPv6-Prefix attribute [RFC3162] is included, that prefix must be used in the router advertisements sent to the SI. If Framed-IPv6-Prefix is not present but Framed-IPv6-Pool is, the SC must choose a prefix with that pool to send RAs. If none of the attributes above are included but the AAA server returns the Tunnel-Client-Endpoint and Tunnel-Server-Endpoint attributes [RFC2868] with the correct address family, these must be used in the IPV6CP Interface-Identifier and for the Router Advertisements. The above paragraph defines new interpretations of these attributes. > 8.1.2. IPv4 Softwires If the Framed-IP-Address attribute [RFC2865] is present, the Softwire Concentrator must provide that address to the Softwire Initiator during IPCP address negotiation. That is, when the Softwire Initiator requests an IP address from the Softwire Concentrator, the address provided should be the Framed-IP-Address. If the Framed-IP-Address attribute is not present and the Tunnel- Client-Endpoint and Tunnel-Server-Endpoint attributes [RFC2868] are present and of the correct address family, these should be used in the IPCP IP-Address configuration option. The above paragraph defines new interpretations of these attributes. > 8.2. Delegated Prefixes 8.2.1. IPv6 Prefixes If the attribute Delegated-IPv6-Prefix [RFC4818] is present in the RADIUS Access-Accept message, it must be used by the Softwire Concentrator for the delegation of the IPv6 prefix. Since the prefix delegation is performed by DHCPv6 and the attribute is linked to a username, the SC must associate the DHCP Unique Identifier (DUID) of a DHCPv6 request to the tunnel it came from and its user. Interaction between RADIUS, PPP and DHCPv6 server may follow the mechanism proposed in [I-D.ietf-dhc-v6-relay-radius]. In this case, during the Softwire authentication phase, PPP collects the RADIUS attributes for the user such as Delegated-IPv6-Prefix. A specific DHCPv6 relay is assigned to the Softwire. The DHCPv6 relay fills in these attributes in the Relay agent RADIUS Attribute Option (RRAO) DHCPv6 option, before forwarding the DHCPv6 requests to the DHCPv6 server. The above paragraph makes what would appear to be a normative reference to an I-D - however this document is listed as informational reference. > 8.2.2. IPv4 Prefixes The combination of the Framed-IP-Address and Framed-IP-Netmask attributes [RFC2865] may be used by the Softwire Concentrator to delegate an IPv4 prefix to the Softwire Initiator. The above paragraph defines new interpretations of these attributes. |
2009-01-15
|
13 | Dan Romascanu | [Ballot Position Update] New position, Discuss, has been recorded by Dan Romascanu |
2009-01-14
|
13 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert |
2009-01-14
|
13 | Lars Eggert | [Ballot comment] Very clear document. Two minor comments: Section 1., paragraph 1: > The Softwires Working Group has selected Layer Two Tunneling Protocol > … [Ballot comment] Very clear document. Two minor comments: Section 1., paragraph 1: > The Softwires Working Group has selected Layer Two Tunneling Protocol > version 2 (L2TPv2) as the phase 1 protocol to be deployed in the > Softwire "Hubs and Spokes" solution space. This document describes > the framework for the L2TPv2 "Hubs and Spokes" solution, and the > implementation details specified in this document should be followed > to achieve interoperability among different vendor implementations. Referring to WGs and their decision process in RFCs isn't terribly useful, because WGs are ephemeral. I'd suggest to rephrase this to talk about the technology itself. Section 4., paragraph 0: > 4. Standardization Status > > This section groups various Internet standards documents and other > publications used in Softwires. I don't understand the purpose of this section. Is this supposed to be a reading list of related work, provided for the convenience of implementors? If so, the section title is confusing. |
2009-01-14
|
13 | Cullen Jennings | [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings |
2009-01-14
|
13 | Chris Newman | [Ballot Position Update] New position, No Objection, has been recorded by Chris Newman |
2009-01-14
|
13 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica |
2009-01-12
|
13 | Russ Housley | [Ballot discuss] The email thread discussing the Last Call comments raised by David Black in his Gen-ART Review indicate that a draft -11 will … [Ballot discuss] The email thread discussing the Last Call comments raised by David Black in his Gen-ART Review indicate that a draft -11 will get needed to resolve the comments. That revised draft has not been posted yet. |
2009-01-12
|
13 | Russ Housley | [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley |
2009-01-12
|
13 | Mark Townsley | Placed on agenda for telechat - 2009-01-15 by Mark Townsley |
2008-12-15
|
13 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2008-12-11
|
13 | Amanda Baber | IANA Last Call comments: As described in the IANA Considerations section, we understand this document to have NO IANA Actions. |
2008-12-06
|
13 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Larry Zhu |
2008-12-06
|
13 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Larry Zhu |
2008-12-01
|
13 | Amy Vezza | Last call sent |
2008-12-01
|
13 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2008-11-27
|
13 | Mark Townsley | [Ballot Position Update] New position, Yes, has been recorded for Mark Townsley |
2008-11-27
|
13 | Mark Townsley | Ballot has been issued by Mark Townsley |
2008-11-27
|
13 | Mark Townsley | Created "Approve" ballot |
2008-11-27
|
13 | Mark Townsley | State Changes to Last Call Requested from AD Evaluation by Mark Townsley |
2008-11-27
|
13 | Mark Townsley | Last Call was requested by Mark Townsley |
2008-11-27
|
13 | (System) | Ballot writeup text was added |
2008-11-27
|
13 | (System) | Last call text was added |
2008-11-27
|
13 | (System) | Ballot approval text was added |
2008-11-13
|
13 | Mark Townsley | State Changes to AD Evaluation from Publication Requested by Mark Townsley |
2008-11-03
|
13 | Cindy Morgan | PROTO questionnaire for: draft-ietf-softwire-hs-framework-l2tpv2-10 prepared by: Alain Durand Alain_Durand@cable.comcast.com 1.a) Have the chairs personally reviewed this version of the Internet … PROTO questionnaire for: draft-ietf-softwire-hs-framework-l2tpv2-10 prepared by: Alain Durand Alain_Durand@cable.comcast.com 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? Which chair is the WG Chair Shepherd for this document? Alain Durand 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, internationalization, XML, 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? There is strong WG consensus behind this document and no one that has expressed concerns about its progression. 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. (It should be separate email because this questionnaire will be entered into the tracker). No. 1.g) Have the chairs verified that the document checks out against all the ID nits? (see http://www.ietf.org/ID-Checklist.html ). Boilerplate checks are not enough; this check needs to be thorough. Yes. 1.h) Has the document split its references into normative and informative? Are there normative references to IDs, where the IDs are not also ready for advancement or are otherwise in an unclear state? The RFC Editor will not publish an RFC with normative references to IDs (will delay the publication until all such IDs are also ready for RFC publicatioin). If the normative references are behind, what is the strategy for their completion? On a related matter, are there normative references that are downward references, as described in BCP 97, RFC 3967 RFC 3967 [RFC3967]? Listing these supports the Area Director in the Last Call downref procedure specified in RFC 3967. The references are split into normative and informative. Technical Summary This document describes the framework of the Softwire "Hub and Spoke" solution with the Layer 2 Tunneling Protocol version 2 (L2TPv2). The implementation details specified in this document should be followed to achieve interoperability among different vendor implementations. Working Group Summary The SOFTWIRE WG supports the development and advancement of this document. Protocol Quality This document was thoroughly reviewed by WG chairs and WG members, including those with expertise in IPv4 to IPv6 transitions and interworking. Alain Durand is the WG chair shepherd. Mark Townsley is the responsible Area Director. |
2008-11-03
|
13 | Cindy Morgan | Draft Added by Cindy Morgan in state Publication Requested |
2008-10-29
|
10 | (System) | New version available: draft-ietf-softwire-hs-framework-l2tpv2-10.txt |
2008-07-10
|
09 | (System) | New version available: draft-ietf-softwire-hs-framework-l2tpv2-09.txt |
2008-01-29
|
08 | (System) | New version available: draft-ietf-softwire-hs-framework-l2tpv2-08.txt |
2007-09-27
|
07 | (System) | New version available: draft-ietf-softwire-hs-framework-l2tpv2-07.txt |
2007-08-17
|
06 | (System) | New version available: draft-ietf-softwire-hs-framework-l2tpv2-06.txt |
2007-06-29
|
05 | (System) | New version available: draft-ietf-softwire-hs-framework-l2tpv2-05.txt |
2007-06-11
|
04 | (System) | New version available: draft-ietf-softwire-hs-framework-l2tpv2-04.txt |
2007-02-15
|
03 | (System) | New version available: draft-ietf-softwire-hs-framework-l2tpv2-03.txt |
2006-11-20
|
02 | (System) | New version available: draft-ietf-softwire-hs-framework-l2tpv2-02.txt |
2006-08-29
|
01 | (System) | New version available: draft-ietf-softwire-hs-framework-l2tpv2-01.txt |
2006-06-20
|
00 | (System) | New version available: draft-ietf-softwire-hs-framework-l2tpv2-00.txt |