+1. The RFP angle is an important one, Simon.
Cheers, Rajiv Sent from Phone.... On Aug 19, 2011, at 8:57 AM, "Simon Perreault" <[email protected]> wrote: > On 2011-08-19 05:19, Tetsuya Murakami wrote: >> draft-murakami-softwire-4rd >> draft-murakami-softiwire-4v6-translation >> >> I think it might be good to combine these 2 drafts to create one unified >> document for 4rd specification. > > The problem I see with this is: > > - We (the IETF) might need to specify both translation and encapsulation > protocols, because they have different applicability. (Still needs to be > decided.) > > - Operators will choose translation or encapsulation for each > deployment, probably not both. > > - Implementations of translation vs encapsulation will probably be very > different. I see this as leading to different "products" or "feature > sets" targeted to different markets. For example 3GPP products might > want to implement translation while broadband products might want to > implement encapsulation. > > So in the end, I see an operator A needing the 4rd-Translation solution > and operator B needing the 4rd-Encapsulation solution. This fits nicely > with two different RFCs, is more easily cited in RFPs, etc. > > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
