Re: [Softwires] MAP documents - next steps

Xing Li <> Fri, 03 February 2012 02:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1018621F850C for <>; Thu, 2 Feb 2012 18:13:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -98.902
X-Spam-Status: No, score=-98.902 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, MIME_8BIT_HEADER=0.3, RCVD_ILLEGAL_IP=1.908, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id onbjjlfYV4ah for <>; Thu, 2 Feb 2012 18:13:04 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id D9E8A21F8504 for <>; Thu, 2 Feb 2012 18:13:03 -0800 (PST)
Received: from [] (unknown []) by centos (Coremail) with SMTP id AQAAf3DbAAMeQitPVpcHAA--.33008S2; Fri, 03 Feb 2012 10:10:39 +0800 (CST)
Message-ID: <>
Date: Fri, 03 Feb 2012 10:12:58 +0800
From: Xing Li <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; zh-CN; rv: Gecko/20120129 Thunderbird/3.1.18
MIME-Version: 1.0
To: Ole Trøan <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Coremail-Antispam: 1UD129KBjvJXoW7AFy7Gw1UWryUXF1DGryxAFb_yoW8KFy3pr W0kw12kFnxAr1Iyw18Zw1Fvr1Fvrs5JrW3Ja45tr4ku345Ga48Kr47t34Y9ayUur4rZF1j vrWqkFy5Ca1DZrJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUqab7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28EF7xvwVC0I7IYx2 IY67AKxVWUCVW8JwA2z4x0Y4vE2Ix0cI8IcVCY1x0267AKxVWxJVW8Jr1l84ACjcxK6I8E 87Iv67AKxVW8Jr0_Cr1UM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzx vE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWU GVWUXwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcVAKI4 8JMxk0xIA0c2IEe2xFo4CEbIxvr21l42xK82IYc2Ij64vIr41lx2IqxVAqx4xG67AKxVWU JVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7V AKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j 6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWrJr0_WFyUJwCI42IY6I8E87Iv67AKxVWUJVW8Jw CI42IY6I8E87Iv6xkF7I0E14v26r1j6r4UYxBIdaVFxhVjvjDU0xZFpf9x07beJ5wUUUUU =
X-CM-SenderInfo: p0lqwqxfhu0vvwohv3gofq/
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: Fri, 03 Feb 2012 02:13:05 -0000

于 2012/2/1 22:33, Ole Trøan 写道:
> 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.

I agree with Ole.



> cheers,
> Ole
> _______________________________________________
> Softwires mailing list