Re: [Softwires] MAP documents - next steps

Rémi Després <> Wed, 01 February 2012 16:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 974A511E80A0 for <>; Wed, 1 Feb 2012 08:43:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.3
X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zbzDYzx6y2Lk for <>; Wed, 1 Feb 2012 08:43:00 -0800 (PST)
Received: from ( [IPv6:2a01:e0c:1:1599::10]) by (Postfix) with ESMTP id 96DDA11E8071 for <>; Wed, 1 Feb 2012 08:42:57 -0800 (PST)
Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by (Postfix) with ESMTP id EDE33940238; Wed, 1 Feb 2012 17:42:48 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="iso-8859-1"
From: Rémi Després <>
In-Reply-To: <>
Date: Wed, 01 Feb 2012 17:42:47 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Mark Townsley <>
X-Mailer: Apple Mail (2.1084)
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: Wed, 01 Feb 2012 16:43:00 -0000

Le 2012-02-01 à 15:13, Mark Townsley a écrit :

> 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. 

Well, this seems similar to taking the new 4rd document and analyzing what is missing or is unnecessary.

Except for the fact that double RF46145 is replaced by the self-contained Header mapping variant, more transparent, but about which there is an ongoing discussion with Maoke, the last 4rd-U draft is, in my understanding, largely what you are looking for.

It avoids all the complexity of GMA port-mapping, a nice piece of technology but near to 5 pages that don't seem to serve real needs (a fixed PSID is enough in practice AFAIK). 

Avoiding to review the unified draft because of some NIH syndrome would be IMHO a way to miss a good opportunity for progress.

I do look forward to technical comments on draft-despres-softwire-4rd-U.


> - Mark
> On Jan 30, 2012, at 12:31 PM, Ole Trøan wrote:
>> hi,
>> the MAP (Mapping of address and port) design team has now written and published the following sets of drafts.
>> the base document (port mapping algorithm):
>> the encapsulation document (MAP-E):
>> the translation document (MAP-T):
>> the DHCP option (MAP-DHCP):
>> there is a MAP deployment document coming soon.
>> the solution described in this set of documents, are written to satisfy the following from the softwires charter:
>> 4. Developments for stateless legacy IPv4 carried over IPv6 
>>    - develop a solution motivation document to be published as an RFC 
>>    - develop a protocol specification response to the solution 
>>      motivation document; this work item will not be taken through 
>> in the design team's view, this set of documents are ready to be adopted as working group documents.
>> comments?
>> for the MAP design team,
>> Ole
>> _______________________________________________
>> Softwires mailing list
> _______________________________________________
> Softwires mailing list