Re: [Softwires] MAP documents - next steps

Ole Trøan <> Wed, 01 February 2012 14:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F0F3311E823C for <>; Wed, 1 Feb 2012 06:33:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.385
X-Spam-Status: No, score=-3.385 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 23ypvF5yUWr5 for <>; Wed, 1 Feb 2012 06:33:56 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 2A2EE11E815D for <>; Wed, 1 Feb 2012 06:33:56 -0800 (PST)
Received: by werm10 with SMTP id m10so1220332wer.31 for <>; Wed, 01 Feb 2012 06:33:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=5H7SftP4cszcK9gjfN2bWsKEBBYsYCeHY2/Tnl+OZpo=; b=vuFEZhRtJDfa8tJKtb+4sN38Xhn5deKjs5KR+RQzRShM0afURqObM4u40+DUarOWfV 4ZIpJrFMjd2eZSc0sWXDmCBib6GeRLa2PAv53rshDk38fpm3U1yC+4HWrJKalteGWdOl PfRj0z40EFO6RHyGAq6oEVZIbVy4d4qqtYb/E=
Received: by with SMTP id w52mr2836157wei.57.1328106835272; Wed, 01 Feb 2012 06:33:55 -0800 (PST)
Received: from [] ( []) by with ESMTPS id d9sm45149817wiy.2.2012. (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Feb 2012 06:33:54 -0800 (PST)
Sender: Ole Troan <>
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset="iso-8859-1"
From: Ole Trøan <>
In-Reply-To: <>
Date: Wed, 01 Feb 2012 15:33:51 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Mark Townsley <>
X-Mailer: Apple Mail (2.1251.1)
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 14:33:57 -0000


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