Sorry, but I'll insist for a number of reasons: 1. It is technically valid 2. The solutions are clearly closely related. Not stating that in any way would be ridiculous. 3. It presents (introduces) the context of the draft, and as I said MAP-E should do likewise. It is not a detailed pro/con. 4. It is the right thing to do, esp in IETF standard track drafts for which a higher bar applies (or should).
On 4 March 2014 10:54, Ian Farrer <[email protected]> wrote: > This could certainly save a spending the rest of the week micro-editing > wording, so I'd be happy with it. > > An extremely tentative further suggestion: > > Should there be a draft which discusses the available softwire solutions > more throughly (we would tackle this only after we've got the WGCLs > completed, so there's something to actually compare)? > > A basket of vipers, I'm sure, but it wold give somewhere for a much more > complete analysis of the pros and cons rather than a line and a half of > analysis in the technology specific drafts. > > Ian > > > Discretion is the better part of valour. > > I would be happy with this as a possible solution. > > I think that there's a need for an overall softwire doc that tackles the > > On 4 Mar 2014, at 09:42, Ole Troan <[email protected]> wrote: > > >> If, as you say, Ian is happy to make the change that you've proposed, > then I have no problem with that. However, let's not needlessly delay > both of these drafts arguing about marketing boilerplate. The text as > written is not a sufficiently glowing recommendation of MAP, but it doesn't > need to be, for two reasons. First, this is not a draft about MAP. > Secondly, everybody already knows what they intend to implement anyway, so > getting this text exactly perfect will make not one iota of difference in > regards to who implements what. > > > > I have had success in the past by removing contentious text. I think > that could work here, just remove this paragraph: > > > > "It does not offer direct, meshed IPv4 connectivity between subscribers > without packets traversing the AFTR. > > If this type of meshed interconnectivity is required, > [I-D.ietf-softwire-map] provides a suitable solution." > > > > or alternatively, the last sentence. > > > > cheers, > > Ole > > _______________________________________________ > > 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
