When the RFP is coming from Best Buy for a consumer device, you want fewer alternatives.
- Mark On Aug 19, 2011, at 9:25 AM, Rajiv Asati (rajiva) wrote: > +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 _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
