Re: [Softwires] MAP documents - next steps

Wojciech Dec <> Sat, 04 February 2012 17:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 743D821F84DE for <>; Sat, 4 Feb 2012 09:23:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.298
X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fD5umX7o4fep for <>; Sat, 4 Feb 2012 09:23:40 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 86B9821F84F9 for <>; Sat, 4 Feb 2012 09:23:40 -0800 (PST)
Received: by qafi29 with SMTP id i29so1282570qaf.10 for <>; Sat, 04 Feb 2012 09:23:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DBiGXWURaoNFmZbiV6A5EPDgK4WDtkKyc1Dk4oH+GrQ=; b=f4L4vtAQozk1PUswNIY9KmHsax3rUPQ3rTpv4408x7+v8jStJP+6LgKKfVrb0eRxW9 uO8XvEptzFrNVcWppiaaOhLIYsImalKT1aXESIPmODzMfEfCW5GiU7r43MhmEcX8UYua 9hVZwEs2soxvnDH22ez/fl/S/P7T4b1DIlpv8=
MIME-Version: 1.0
Received: by with SMTP id by15mr14213606qab.29.1328376220001; Sat, 04 Feb 2012 09:23:40 -0800 (PST)
Received: by with HTTP; Sat, 4 Feb 2012 09:23:39 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
Date: Sat, 04 Feb 2012 18:23:39 +0100
Message-ID: <>
From: Wojciech Dec <>
To: Ole Trøan <>
Content-Type: multipart/alternative; boundary="20cf303b41adb8a64104b826b0f5"
Cc: softwires WG <>
Subject: Re: [Softwires] MAP documents - next steps
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 04 Feb 2012 17:23:41 -0000

Fully agree with Ole.
We've been back and forth on the one-draft, many-drafts, too-many-drafts
discussion so many times, and it's not productive. We have a broad group of
individuals who are interested in pursuing the drafts. Given that this is a
WG that is meant to operate for its participants, as opposed to against
them (as has been the case), having progress in the form of document
adoption would be a good step forward.


On 1 February 2012 15:33, Ole Trøan <> wrote:

> Mark,
> > While I appreciate the functional modularity in understanding the
> solution space, I do wish that DT had come up with a way to make this one
> document to present to the world rather than four. I fear organ rejection
> when tossing a list of RFCs for one function to the CPE industry.
> >
> > In current form, each document has more or less than 10 pages of
> substantive text, with considerable overlap between them (how many
> "framework" and "architecture" sections do we really need for what are
> really just two variants of something 95% the same?). As further evidence
> of the problem, there are no less than 19 references to
> mdt-softwire-mapping-address-and-port from
> draft-mdt-softwire-map-translation-00. One page has 5 references alone.
> It's is like reading a single book with every other page in a different
> binding.
> >
> > Could we not eliminate the overlap, and just boil this down to one less
> than 40 page document? In fact, I bet if you tried you could get it down to
> half that. Looks like Remi's new document is on the right track in this
> regard.
> >
> > I'm in favor of the chairs stating that we will adopt a WG document
> based on the text in these documents, but I would like to see a stipulation
> that they be combined into one (perhaps two but with only the DHCP option
> separate) and the overlap eliminated among MAP, T and E eliminated.
> with regards to document organization we've been over that a few times. my
> understanding of the Beijing interim meeting was to have the organization
> of documents we have now. largely because there were discussions on
> different document status for the different documents. e.g. experimental
> versus standards track.
> yes, it is certainly possible to merge the 3 documents (MAP, T, E), with
> separate sections that only apply to encapsulation and some that apply to
> translation. what I feat is that you will pollute the text with lots of
> "does not apply in the translation case", "fragmentation issues are
> slightly different", and so on.
> this is obviously something the working group has to decide on, but I
> don't think that needs to be done before adopting this document set.
> cheers,
> Ole
> _______________________________________________
> Softwires mailing list