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
