Hello all, It appears that confirming on this list the vote made in Quebec would be useful. Please see below.
Le 16 août 2011 à 17:03, <[email protected]> <[email protected]> a écrit : > ... there was a vote in favour of adopting this document as a WG document > but as you know this vote should be confirmed in the ML. I have seen drafts becoming WG drafts after votes during meetings but, fair enough, let's see if, after the unanimous vote in the meeting, there are serious objections to it now. > A call for adoption should normally be issued by the chairs according to the > IETF procedure. > > As for the content of the next iteration of the document, we have two options > so far: > > (1) Put back some sections which have been removed in -02, Support. Some of them were worth having, IMHO. > add a new section to discuss dynamic vs. static, > handle the comments received from J. Arkko, etc. Sure. Doing this while the draft is already a WG draft seems to me normal after the vote result (but no objection to doing it right away if found better. > Or > > 2) An alternative structure has been proposed off-line by A. Durand: discuss > dynamic vs. static and stateful vs. dynamic. Offline discussions are of course completely free, and useful, but a WG consensus can only be built in the open, i.e. on the WG mailing list. I am aware of at least part of the offline discussion you refer to, and therefore suppose you meant "dynamic vs static AND stateful vs _stateless_". Several pointed out, in that discussion, that the stateless & dynamic combination doesn't really make sense. In any case, this discussion hasn't been pursued on the WG list. > The analysis would elaborate the pros and cons of each solution (static > stateless, static stateful, dynamic stateful,...). This document would be an > analysis document and not a motivation document anymore. This document has no > milestone in the charter IMHO. Note the charter mentions the following: > > "Aug 2011 - Adopt stateless legacy IPv4 solution motivation document as a > Working Group document" > > > I personally think the first option is straightforward So do I, => +1 That is IMHO the only acceptable option in view of the vote result. > but I'm open to the opinions of the working group members on how to proceed. Let's see then. Regards to all, RD > > Cheers, > Med > > > -----Message d'origine----- > De : Rémi Després [mailto:[email protected]] > Envoyé : mardi 16 août 2011 16:30 > À : BOUCADAIR Mohamed OLNC/NAD/TIP > Cc : Nejc Škoberne; > [email protected]; > [email protected] > Objet : Re: [Softwires] draft-operators-softwire-stateless-4v6-motivation > > Hi Med, > > At the last meeting, a vote was taken to decide whether this draft should > become a WG draft. > The answer has been a crystal clear yes, with the common understanding that, > as such, it would have to be improved and competed based on WG reactions. > > IMHO, making it a WG document asap will facilitate discussions like this one: > thet will point to the right document. > > Is there any sort term plan to do what was approved? > > Kind regards, > RD > > > > > Le 16 août 2011 à 13:48, <[email protected]> > <[email protected]> a écrit : > >> Dear Nejc, >> >> Thank you for the comments. Please see my answers inline. >> >> Cheers, >> Med >> >> >> -----Message d'origine----- >> De : [email protected] [mailto:[email protected]] De la >> part de Nejc Škoberne >> Envoyé : mardi 16 août 2011 12:25 >> À : [email protected] >> Cc : [email protected] >> Objet : [Softwires] draft-operators-softwire-stateless-4v6-motivation >> >> Hello, >> >> I have some comments on your draft, see inline. >> >> Regards, >> Nejc >> >> --------------- >> 2. Terminology >> >> >> >> This document makes use of the following terms: >> >> Stateful 4/6 solution (or stateful solution in short): denotes a >> solution where the network maintains user-session >> states relying on the activation of a NAT >> function in the Service Providers' network >> [I-D.ietf-behave-lsn-requirements]. The NAT >> function is responsible for sharing the same IPv4 >> address among several subscribers and to maintain >> user-session state. >> >> Stateless 4/6 solution (or stateless solution in short): denotes a >> solution which does not require any user-session >> state (seeSection 2.3 of [RFC1958]) to be >> maintained by any IP address sharing function in >> the Service Provider's network. This category of >> solutions assumes a dependency between an IPv6 >> prefix and IPv4 address. In an IPv4 address >> sharing context, dedicated functions are required >> to be enabled in the CPE router to restrict the >> source IPv4 port numbers. Within this document, >> "port set" and "port range" terms are used >> interchangeably. >> >> [NS: If we consider a "stateful A+P" solution, we don't necessarily >> have a dependency between an IPv6 prefix and IPv4 address. Also, we >> don't have any user-session state in the Service Provider's network. >> >> Med: Fully agree. FWIW, this is what we called "Binding Table A+P Mode" in >> http://tools.ietf.org/html/draft-ymbk-aplusp-10#section-4.4. >> >> We do, however, have some user state (in order to do stateful tunneling, >> for example). Maybe this is included in "user-session" in your >> terminology, but then I think it would be appropriate to define the >> term "user-session" clearly.] >> >> Med: We assumed the definition of state as mentioned in RFC1958; but I agree >> the terminology should be much more clearer. >> >> ... >> >> 3.1.5. Bandwidth Saving >> >> >> >> In same particular network scenarios (e.g., wireless network ), >> spectrum is very valuable and scarce resource. Service providers >> usually wish to eliminate unnecessary overhead to save bandwidth >> consumption in such environment. Service providers need to consider >> optimizing the form of packet processing when encapsulation is used. >> Since existing header compression techniques are stateful, it is >> expected that stateless solution minimize overhead introduced by the >> solution. >> >> [NS: I don't understand this section, but that may be just me. >> Maybe is there a better way to explain the point?] >> >> Med: We have several co-authors who are not either in favour or maintaining >> this section. This text will be removed. >> >> ... >> >> >> 3.3.1. Implicit Host Identification >> >> >> >> Service Providers do not offer only IP connectivity services but also >> added value services (a.k.a., internal services). Upgrading these >> services to be IPv6-enabled is not sufficient because of legacy >> devices. In some deployments, the delivery of these added-value >> services relies on implicit identification mechanism based on the >> source IPv4 address. Due to address sharing, implicit identification >> will fail [I-D.ietf-intarea-shared-addressing-issues]; replacing >> implicit identification with explicit authentication will be seen as >> a non acceptable service regression by the end users (less Quality of >> Experience (QoE)). >> >> When a stateless solution is deployed, implicit identification for >> internal services is likely to be easier to implement: the implicit >> identification should be updated to take into account the port range >> and the IPv4 address. Techniques as those analyzed in >> [I-D.boucadair-intarea-nat-reveal-analysis] are not required for the >> delivery of these internal services if a stateless solution is >> deployed. >> >> [NS: I don't think this is true only for stateless >> solutions. If we have a stateful solution with static port allocation >> (as you mention in section 3.1.3), then implementing such an implicit >> host identification which uses also port information, is doable as >> well.] >> >> Med: I Agree. But then you loose other benefits of the stateful: have an >> aggressive address sharing ratio. >> _______________________________________________ >> Softwires mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/softwires > > _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
