Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt

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 <ianfarrer@gmx.com> 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 <otroan@employees.org> 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
> > Softwires@ietf.org
> > https://www.ietf.org/mailman/listinfo/softwires
>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
>