Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
Dear Cameron, Yes, I know it is tempting to have such section but it won't help in making a decision and, furthermore, it may maintain a tension between stateless and stateful camps. We tried in the document to be neutral as much as possible and avoid claiming stateless is superior to stateful or stateful is superior to stateless. I personally think both stateful and stateless solutions are needed. It is up to each service provider, taking into account its own environment and constraint, to select the flavour of solutions which fit its needs. The selection may even be complex given the diversity of networks and services managed by (large) service providers. Cheers, Med De : Cameron Byrne [mailto:cb.li...@gmail.com] Envoyé : samedi 11 février 2012 15:31 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : softwires@ietf.org Objet : Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation On Feb 10, 2012 2:20 AM, mohamed.boucad...@orange.commailto:mohamed.boucad...@orange.com wrote: Dear WG members, I would like to close this document so that we can meet the following item from the WG Charter: 4. Developments for stateless legacy IPv4 carried over IPv6 - develop a solution motivation document to be published as an RFC - develop a protocol specification response to the solution motivation document; this work item will not be taken through Working Group last call until the solution motivation document has been published or approved for publication Except the a comment asking to include a new section to compare stateful vs. stateless, no further comments have been received. I didn't considered adding the proposed new section because IMO it is out of scope of this document. That section can justify in its own a dedicated draft. I find this omission disappointing. There is a common assumption that stateless is superior to stateful, but it is not quantified anywhere. It seems all this stateless work hinges on this assumption without any quantification. Honestly, the omission makes me believe the case of stateless being superior is dubious. Cb As for the next step, I see two options: (1) Either issue a WG LC, or (2) Withdraw the document and update the WG charter. WG members, please advise. Cheers, Med ___ Softwires mailing list Softwires@ietf.orgmailto:Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
2012/2/13, Ole Trøan otr...@employees.org: Cameron, RFC1958 gives the fundamental principles. search for state. Yes. But do you think it is achievable for pure stateless? BR, Dapeng cheers, Ole On Feb 13, 2012, at 5:02 , Cameron Byrne wrote: On Feb 12, 2012 7:14 PM, Satoru Matsushima satoru.matsush...@gmail.com wrote: On 2012/02/11, at 15:30, Cameron Byrne wrote: --snip-- I find this omission disappointing. There is a common assumption that stateless is superior to stateful, but it is not quantified anywhere. It seems all this stateless work hinges on this assumption without any quantification. Honestly, the omission makes me believe the case of stateless being superior is dubious. Cb Do you think that it is productive productive analysis that comparison of stateless between stateful? Current motivation draft stands not to beat other solutions, it stands for justifying to start stateless solution work on the WG so some proponents of stateless solution took a pen. My question is that if the comparison is productive for something, who should work for it, and who should read it. I assumed this explanation and comparison would be easy for the stateless experts. I looked to this as a learning opportunity for me. I agree with you and RD, there are many good solutions that fit this problem space and I do not intend to slow progress. If it is difficult and the differences in merit cannot be easily quantified between stateful and stateless , I accept that as an answer. I suggested they be compared since opposites frequently help define each other. Black helps define white just as cold helps define hot. I had assumed this was true for this case as well. Perhaps I was wrong. Thanks again for your contribution. Cb cheers, --satoru ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires -- -- Best Regards, Dapeng Liu ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
[Softwires] RFC 6519 on RADIUS Extensions for Dual-Stack Lite
A new Request for Comments is now available in online RFC libraries. RFC 6519 Title: RADIUS Extensions for Dual-Stack Lite Author: R. Maglione, A. Durand Status: Standards Track Stream: IETF Date: February 2012 Mailbox:roberta.magli...@telecomitalia.it, adur...@juniper.net Pages: 11 Characters: 22574 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-softwire-dslite-radius-ext-07.txt URL:http://www.rfc-editor.org/rfc/rfc6519.txt Dual-Stack Lite is a solution to offer both IPv4 and IPv6 connectivity to customers that are addressed only with an IPv6 prefix. Dual-Stack Lite requires pre-configuration of the Dual-Stack Lite Address Family Transition Router (AFTR) tunnel information on the Basic Bridging BroadBand (B4) element. In many networks, the customer profile information may be stored in Authentication, Authorization, and Accounting (AAA) servers, while client configurations are mainly provided through the Dynamic Host Configuration Protocol (DHCP). This document specifies a new Remote Authentication Dial-In User Service (RADIUS) attribute to carry the Dual-Stack Lite AFTR tunnel name; the RADIUS attribute is defined based on the equivalent DHCPv6 OPTION_AFTR_NAME option. This RADIUS attribute is meant to be used between the RADIUS server and the Network Access Server (NAS); it is not intended to be used directly between the B4 element and the RADIUS server. [STANDARDS-TRACK] This document is a product of the Softwires Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
