From jan@go6.si Thu Aug 1 06:08:38 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0856121F8EC2 for ; Thu, 1 Aug 2013 06:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3CXj5za2-T8 for ; Thu, 1 Aug 2013 06:08:32 -0700 (PDT) Received: from nety.net (mail.pragma.si [91.239.96.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1377721F9DAA for ; Thu, 1 Aug 2013 06:06:18 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=::ffff:91.239.97.99; Message-ID: <51FA5D02.2010109@go6.si> Date: Thu, 01 Aug 2013 15:05:06 +0200 From: "Jan Zorz @ go6.si" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: softwires@ietf.org References: <51F798BB.8040800@viagenie.ca> <9C821C4C-5B63-4815-9802-5EA39834F49E@townsley.net> In-Reply-To: <9C821C4C-5B63-4815-9802-5EA39834F49E@townsley.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: jan@nety.net X-Info: aspam skipped due to (g_smite_skip_trusted) X-Encryption: SSL encrypted X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=11 Stars=0 Good=0 Friend=12 Surbl=0 Catch=0 r=0 ip=::ffff:91.239.97.99 X-IP-stats: Notspam Incoming Outgoing Last 0, First 1169, in=228321, out=3698, spam=0 Known=true ip=::ffff:91.239.97.99 Subject: Re: [Softwires] regarding discussion IETF87 tuesday regarding DHCP X-BeenThere: softwires@ietf.org 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: Thu, 01 Aug 2013 13:08:38 -0000 On 7/30/13 6:05 PM, Mark Townsley wrote: > The benefit of the "unified CPE" is not rooted in fewer DHCP options. > The real benefit is when there is a single feature for CPE vendors to > implement. The more feature fragmentation (our linksys folks called > this "splatter"), the less economy of scale, the greater cost, > overall, to everyone. With a single "unified" feature, there would be > no need to discover whether the CPE was LW46-only, MAP-E-only, or > MAP-T-only, or some other combination - It would always be all three, > because they would all be part of the same thing. Your DHCP options > would then be simple and static, and you would not have to match them > up with the type of CPE you had. +100 Keep It Simple. Cheers, Jan From mark@townsley.net Sun Aug 4 02:53:27 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0072C21F841B for ; Sun, 4 Aug 2013 02:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKAGYKE6c9lQ for ; Sun, 4 Aug 2013 02:53:22 -0700 (PDT) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id D252B21F9A87 for ; Sun, 4 Aug 2013 02:53:21 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id k13so1608043wgh.13 for ; Sun, 04 Aug 2013 02:53:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=ZxZ+QcAb2y2BARAgWIuWfFoan5nvaqVTruf/HN+AeWw=; b=lRViFhMDX40A782VnINIbz1r1XapJzoQjTizsvkU8t29YByUYU7eORewifRjf/Fgtn tWgryZhMwRWDRH5TisQZACIwZV9IOUkT44ev6ZFYbg+MZDybPufrQg13Ucmtk+B219pV QFOx2SmOXgiqF6vmIyh6ZLgm9b4h5WaOhm12mq+YTWOJdEAJLt19GDBPsfj5x0VJ/qqG Ubs06CbGrJvDfywm4W+HwluWY1iTIne08U0c3uU1q6WqIhE5pIYr3py0tkLDCmOHgYZN 4O6C0CUPmcoVsaIBx2csdBX1zEKi57Wpu7C/IJHcZq+LotrgxqhxYH19V8Wi9HYnvuYh 0nOA== X-Received: by 10.194.24.168 with SMTP id v8mr9839315wjf.28.1375610000891; Sun, 04 Aug 2013 02:53:20 -0700 (PDT) Received: from [100.87.27.66] (214.20.90.92.rev.sfr.net. [92.90.20.214]) by mx.google.com with ESMTPSA id dt17sm14212602wic.1.2013.08.04.02.53.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 04 Aug 2013 02:53:20 -0700 (PDT) References: <51F7A719.6030202@gmail.com> <31E009BB-61DF-4C95-9859-2A2F345E7837@cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: <31E009BB-61DF-4C95-9859-2A2F345E7837@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10B350) From: "Townsley.net" Date: Sun, 4 Aug 2013 11:53:07 +0200 To: "Rajiv Asati (rajiva)" X-Gm-Message-State: ALoCoQlNij4FszVvv7aS7Fzkm1apqqX/GJN8yYI3nlEQTaOMo6wPSUlFIeGlJBZaRKcbwgx0wJ7u Cc: Softwires-wg Subject: Re: [Softwires] Random comments about DHCP discussion X-BeenThere: softwires@ietf.org 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: Sun, 04 Aug 2013 09:53:27 -0000 Some deployments work fine with one or two rules (Satoru-San can confirm). O= thers need more. If you reach 100s you *might* be designing things wrong (a c= lassic starting point begins with folks assigning one map domain per BNG or D= Slam until they realize that's optimizing at the wrong place). I'd be happy t= o chat with you off list about that.=20 Not to suggest for a second that MAP would break with 100s of rules, or that= there are not good reasons to operate in that mode. 10000s should be fine t= oo, as it is all just dialing between 1:1 and 1:n tunnel state aggregation.=20= One and only one rule as we did in 6rd would be wrong for MAP, this is for c= ertain.=20 - Mark (Thumbtyped) On 30 juil. 2013, at 22:16, "Rajiv Asati (rajiva)" wrote:= > Tomek, >=20 >> They can be summarized as: It was impossible to get a clear confirmation >> that only a single MAP domain will ever be configured on a given >> network. >=20 > I can confirm that a single MAP domain is not found to be sufficient in th= e network for the deployment we have been involved in.=20 >=20 > We are talking about of 100s of domains in the network.=20 >=20 > Cheers, > Rajiv >=20 > Sent from my Phone >=20 > On Jul 30, 2013, at 7:44 AM, "Tomek Mrugalski" wrote: >=20 >> Here are some random comments about draft-ietf-softwire-map-dhcp-04 >> draft: >>=20 >> 1. These are the original reasons for using MAP (now Softwire46) >> container: >> http://www.ietf.org/mail-archive/web/softwires/current/msg04701.html >>=20 >> They can be summarized as: It was impossible to get a clear confirmation >> that only a single MAP domain will ever be configured on a given >> network. MAP design was fluctuating. Also, it is unclear what use cases >> may come out of Homenet, especially with regards to multiple >> provisioning domains. Keeping the S46 options in a separate container >> give us more likelihood of future compatibility with whatever may come >> our way (from Homenet, from MIF and multiple provisioning domains or >> somewhere else). >>=20 >> As I said before, none of the arguments on its own is strong enough to >> warrant a container, but taking them all together they are convincing >> enough (in my personal option, with my dhc chair hat off) to go with a >> container. Having said all that, I do not object removing the container. >>=20 >> 2. I brought the question on how to request sub-options in DHCPv6. It >> was discussed couple meetings ago in DHC session. The draft was named >> http://tools.ietf.org/id/draft-mrugalski-dhc-dhcpv6-suboptions-04.txt. >> The answer I got for the question "how to request sub-options in >> DHCPv6?" from DHC was "use regular, top level ORO". >>=20 >> 3. If you look at the evolution of map-dhcp draft, it is somewhat >> worrying. There used to be an enum field that clearly specified the mode >> (at that time it was only MAP-E or MAP-T, but it was trivial to extend >> the enum list to cover other cases). That was removed as requested. Now >> the argument is being made that the CPE does not know which mode it >> should run. Even more, options are being split to provide the capability >> to differentiate between modes. >>=20 >> 4. DHCPv6 server can discover DHCPv6 client's capabilities in two ways. >> The first and more obvious one is to draw conclusions from contents of >> ORO. The other one that is less common, but equally valid is to make the >> client send an option (note the difference: send an actual option, not >> option code in ORO). See rapid-commit option for example. If you choose >> to do that, I encourage you to read draft-ietf-dhc-option-guidelines, >> section 5.2 for a nice discussion how to use such an option. That's >> point is made with my dhc chair hat on. >>=20 >> 5. Ian insisted on having a way to communicate that a certain CPE is >> able to support only EA-len 0. I suppose you could make the same >> argument about trimming down other capabilities in an arbitrary way to >> have a subset of MAP/lw4over6/whatever-else-you-want to make its >> implementation simpler. Perhaps it would be useful to have the >> capability to communicate CPE capability? Although not very popular, it >> is possible for clients to send options they are requesting from the >> server with values used as hints. See 4th paragraph in section 17.1.1 of >> RFC3315 for details. Classic example is a client that sends IA_NA option >> with IAADDRESS in it with preferred and valid lifetimes set to values >> the client would like to get. That gives the server the information >> about client's preference. However, it should be clear that those values >> are hints only. Server is certainly allowed to ignore them completely. >> On a practical side, support for such capability is available, but >> rather uncommon in existing implementations. >>=20 >> Hope that helps, >> Tomek >>=20 >> _______________________________________________ >> 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 From rajiva@cisco.com Sun Aug 4 04:53:41 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30B3721F9A5F for ; Sun, 4 Aug 2013 04:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPUZmhRfk8t9 for ; Sun, 4 Aug 2013 04:53:36 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE3221F9B19 for ; Sun, 4 Aug 2013 04:53:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6095; q=dns/txt; s=iport; t=1375617216; x=1376826816; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=9LlyAnC5BWqMQBmvV7nA8mMjqG9e8hYb7oaL7KNDr+U=; b=X0GjGxhTSXL6MltOVbuF7ioUTp7jkq15giazQ8cQBPLmfUda3N1gZrcr wGKS2nYnhuHSPfr5tGGCgIe3xVmM9OR+HXsw1LYy2jqiIO90ZcHeYOdw6 9j8enZxkI5bgFvzlfHAX7o2vTAnDbU8jfwfyev0zuBvs25/dTimdnm26J c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAG9A/lGtJV2d/2dsb2JhbABagwY1rFGTFIEaFnSCJAEBAQMBAQEBNzQLEAIBCBgeECEGCyUCBA4FCYd1AwkGDK07DYhejSeBKRGBBTMCBYMZdAOVd4FpgSqKfoUngxeBcQ X-IronPort-AV: E=Sophos;i="4.89,812,1367971200"; d="scan'208";a="240247602" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 04 Aug 2013 11:53:27 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r74BrQMH007519 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 4 Aug 2013 11:53:26 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.225]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Sun, 4 Aug 2013 06:53:26 -0500 From: "Rajiv Asati (rajiva)" To: "Townsley.net" Thread-Topic: [Softwires] Random comments about DHCP discussion Thread-Index: AQHOjRorRwZeVGbONU6T2JBcD4/uEJl9qUcBgAeBLYD//83L7w== Date: Sun, 4 Aug 2013 11:53:25 +0000 Message-ID: <3EB9C140-118D-4899-B03C-17911E50D179@cisco.com> References: <51F7A719.6030202@gmail.com> <31E009BB-61DF-4C95-9859-2A2F345E7837@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Softwires-wg Subject: Re: [Softwires] Random comments about DHCP discussion X-BeenThere: softwires@ietf.org 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: Sun, 04 Aug 2013 11:53:41 -0000 If one needs to ensure clean v6 routing summarization (per PE, in case of a= BGP-free core), then one domain (per PE) is not realistic at all, nor opti= mal (from routing standpoint). =20 Sure, one can design MAP with just one domain and take the hit on v6 routin= g summarization. We just choose not to do it that way. It is a trade-off. W= e have had quite a discussion on this. =20 The network needs to be designed for v6 and transition technology like MAP = should be added on top, not the other way around, IMO. Cheers, Rajiv Sent from my Phone On Aug 4, 2013, at 5:53 AM, "Townsley.net" wrote: >=20 > Some deployments work fine with one or two rules (Satoru-San can confirm)= . Others need more. If you reach 100s you *might* be designing things wrong= (a classic starting point begins with folks assigning one map domain per B= NG or DSlam until they realize that's optimizing at the wrong place). I'd b= e happy to chat with you off list about that.=20 >=20 > Not to suggest for a second that MAP would break with 100s of rules, or t= hat there are not good reasons to operate in that mode. 10000s should be fi= ne too, as it is all just dialing between 1:1 and 1:n tunnel state aggregat= ion.=20 >=20 > One and only one rule as we did in 6rd would be wrong for MAP, this is fo= r certain.=20 >=20 > - Mark >=20 > (Thumbtyped) >=20 > On 30 juil. 2013, at 22:16, "Rajiv Asati (rajiva)" wro= te: >=20 >> Tomek, >>=20 >>> They can be summarized as: It was impossible to get a clear confirmatio= n >>> that only a single MAP domain will ever be configured on a given >>> network. >>=20 >> I can confirm that a single MAP domain is not found to be sufficient in = the network for the deployment we have been involved in.=20 >>=20 >> We are talking about of 100s of domains in the network.=20 >>=20 >> Cheers, >> Rajiv >>=20 >> Sent from my Phone >>=20 >> On Jul 30, 2013, at 7:44 AM, "Tomek Mrugalski" wrote: >>=20 >>> Here are some random comments about draft-ietf-softwire-map-dhcp-04 >>> draft: >>>=20 >>> 1. These are the original reasons for using MAP (now Softwire46) >>> container: >>> http://www.ietf.org/mail-archive/web/softwires/current/msg04701.html >>>=20 >>> They can be summarized as: It was impossible to get a clear confirmatio= n >>> that only a single MAP domain will ever be configured on a given >>> network. MAP design was fluctuating. Also, it is unclear what use cases >>> may come out of Homenet, especially with regards to multiple >>> provisioning domains. Keeping the S46 options in a separate container >>> give us more likelihood of future compatibility with whatever may come >>> our way (from Homenet, from MIF and multiple provisioning domains or >>> somewhere else). >>>=20 >>> As I said before, none of the arguments on its own is strong enough to >>> warrant a container, but taking them all together they are convincing >>> enough (in my personal option, with my dhc chair hat off) to go with a >>> container. Having said all that, I do not object removing the container= . >>>=20 >>> 2. I brought the question on how to request sub-options in DHCPv6. It >>> was discussed couple meetings ago in DHC session. The draft was named >>> http://tools.ietf.org/id/draft-mrugalski-dhc-dhcpv6-suboptions-04.txt. >>> The answer I got for the question "how to request sub-options in >>> DHCPv6?" from DHC was "use regular, top level ORO". >>>=20 >>> 3. If you look at the evolution of map-dhcp draft, it is somewhat >>> worrying. There used to be an enum field that clearly specified the mod= e >>> (at that time it was only MAP-E or MAP-T, but it was trivial to extend >>> the enum list to cover other cases). That was removed as requested. Now >>> the argument is being made that the CPE does not know which mode it >>> should run. Even more, options are being split to provide the capabilit= y >>> to differentiate between modes. >>>=20 >>> 4. DHCPv6 server can discover DHCPv6 client's capabilities in two ways. >>> The first and more obvious one is to draw conclusions from contents of >>> ORO. The other one that is less common, but equally valid is to make th= e >>> client send an option (note the difference: send an actual option, not >>> option code in ORO). See rapid-commit option for example. If you choose >>> to do that, I encourage you to read draft-ietf-dhc-option-guidelines, >>> section 5.2 for a nice discussion how to use such an option. That's >>> point is made with my dhc chair hat on. >>>=20 >>> 5. Ian insisted on having a way to communicate that a certain CPE is >>> able to support only EA-len 0. I suppose you could make the same >>> argument about trimming down other capabilities in an arbitrary way to >>> have a subset of MAP/lw4over6/whatever-else-you-want to make its >>> implementation simpler. Perhaps it would be useful to have the >>> capability to communicate CPE capability? Although not very popular, it >>> is possible for clients to send options they are requesting from the >>> server with values used as hints. See 4th paragraph in section 17.1.1 o= f >>> RFC3315 for details. Classic example is a client that sends IA_NA optio= n >>> with IAADDRESS in it with preferred and valid lifetimes set to values >>> the client would like to get. That gives the server the information >>> about client's preference. However, it should be clear that those value= s >>> are hints only. Server is certainly allowed to ignore them completely. >>> On a practical side, support for such capability is available, but >>> rather uncommon in existing implementations. >>>=20 >>> Hope that helps, >>> Tomek >>>=20 >>> _______________________________________________ >>> 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 From simon.perreault@viagenie.ca Sun Aug 4 09:11:14 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79A7521F9CFB for ; Sun, 4 Aug 2013 09:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNzXkPGEPsbS for ; Sun, 4 Aug 2013 09:11:10 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 913EF21F9CD9 for ; Sun, 4 Aug 2013 09:11:10 -0700 (PDT) Received: from porto.nomis80.org (87-231-137-212.rev.numericable.fr [87.231.137.212]) by jazz.viagenie.ca (Postfix) with ESMTPSA id C53A7403D1 for ; Sun, 4 Aug 2013 12:11:09 -0400 (EDT) Message-ID: <51FE7D1C.1090806@viagenie.ca> Date: Sun, 04 Aug 2013 18:11:08 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: softwires@ietf.org References: <51F7A719.6030202@gmail.com> <31E009BB-61DF-4C95-9859-2A2F345E7837@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Softwires] Random comments about DHCP discussion X-BeenThere: softwires@ietf.org 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: Sun, 04 Aug 2013 16:11:14 -0000 Le 2013-08-04 11:53, Townsley.net a écrit : > Some deployments work fine with one or two rules (Satoru-San can confirm). Others need more. If you reach 100s you *might* be designing things wrong (a classic starting point begins with folks assigning one map domain per BNG or DSlam until they realize that's optimizing at the wrong place). I'd be happy to chat with you off list about that. > [...] > One and only one rule as we did in 6rd would be wrong for MAP, this is for certain. > On 30 juil. 2013, at 22:16, "Rajiv Asati (rajiva)" wrote: >> I can confirm that a single MAP domain is not found to be sufficient in the network for the deployment we have been involved in. >> >> We are talking about of 100s of domains in the network. You two seem to be talking about different things. Mark seems to be saying that multiple FRULEs is necessary, while Rajiv seems to be concerned with multiple BRULEs. So far it has been clear that multiple FRULEs are necessary. The question (multiple MAP domains) refers to multiple BRULEs. If we want multiple BRULEs, then we need to be able to associate FRULEs with the corresponding BRULE. One way to do that would be to create a container option, another would be to tag them with identifiers. Both alternatives are not very attractive. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From otroan@employees.org Mon Aug 5 02:08:36 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF5E821F9D5F for ; Mon, 5 Aug 2013 02:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eM9P54bz7ho5 for ; Mon, 5 Aug 2013 02:08:27 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id B8FFF21F9005 for ; Mon, 5 Aug 2013 02:08:01 -0700 (PDT) Received: from dhcp-lys01-vla250-10-147-112-79.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 0CFE05F9C; Mon, 5 Aug 2013 02:07:59 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ole Troan In-Reply-To: <51FE7D1C.1090806@viagenie.ca> Date: Mon, 5 Aug 2013 11:07:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <12963F39-1549-489A-83CB-E6BFE491B938@employees.org> References: <51F7A719.6030202@gmail.com> <31E009BB-61DF-4C95-9859-2A2F345E7837@cisco.com> <51FE7D1C.1090806@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1508) Cc: softwires@ietf.org Subject: Re: [Softwires] Random comments about DHCP discussion X-BeenThere: softwires@ietf.org 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: Mon, 05 Aug 2013 09:08:36 -0000 guys, > You two seem to be talking about different things. Mark seems to be = saying that multiple FRULEs is necessary, while Rajiv seems to be = concerned with multiple BRULEs. >=20 > So far it has been clear that multiple FRULEs are necessary. The = question (multiple MAP domains) refers to multiple BRULEs. If we want = multiple BRULEs, then we need to be able to associate FRULEs with the = corresponding BRULE. One way to do that would be to create a container = option, another would be to tag them with identifiers. Both alternatives = are not very attractive. do we need to reopen this debate? this issue has been discussed = previously and the MAP base document has passed WGLC. MAP does support multiple rules, and multiple domains. it would be unfortunate if the DHCP provisioning mechanism would not = support multiple domains. cheers, Ole= From otroan@employees.org Mon Aug 5 03:17:14 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5DD21F8F4F for ; Mon, 5 Aug 2013 03:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRdMYQ5VgPat for ; Mon, 5 Aug 2013 03:17:08 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id CCE0B21F938E for ; Mon, 5 Aug 2013 03:17:07 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADB7/1GQ/khM/2dsb2JhbABagwa/foEfFnSCJQEFOj8QC0ZXBogjtHePZjMHgxl0A5QJlSaDGTqBLiQ X-IronPort-AV: E=Sophos;i="4.89,817,1367971200"; d="scan'208";a="16820046" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-4.cisco.com with ESMTP; 05 Aug 2013 10:16:59 +0000 Received: from dhcp-lys01-vla250-10-147-112-79.cisco.com (dhcp-lys01-vla250-10-147-112-79.cisco.com [10.147.112.79]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r75AGuD3022976 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 5 Aug 2013 10:16:57 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ole Troan In-Reply-To: <51DEB538.20207@gmail.com> Date: Mon, 5 Aug 2013 12:16:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51DEB538.20207@gmail.com> To: Tom Taylor X-Mailer: Apple Mail (2.1508) Cc: softwires@ietf.org Subject: Re: [Softwires] Ambiguity in MAP-E receiving rules X-BeenThere: softwires@ietf.org 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: Mon, 05 Aug 2013 10:17:14 -0000 >>=20 > [PTT] Is there any point to having the CPE generate logs? Who would = look at them -- the operator or the customer? If logging is useful on = the CPE, that should be reflected in our logging drafts, but if not, = not. >=20 >> [ian] It may be useful to have the option of sending an ICMP error = message >> for troubleshooting. What about if we have a 'should' requirement for >> logging the error on the CPE and a 'may' for sending an ICMP error = message? RFC5969 has the following text: In order to prevent spoofing of IPv6 addresses, the 6rd BR and CE MUST validate the embedded IPv4 source address of the encapsulated IPv6 packet with the IPv4 source address it is encapsulated by according to the configured parameters of the 6rd domain. If the two source addresses do not match, the packet MUST be dropped and a counter incremented to indicate that a potential spoofing attack may be underway. section 8.1 already say MUST drop for packets to an IPv4 address not = belonging to it. I suggest we add that for ports too: old text: In order to prevent spoofing of IPv4 addresses, the MAP node MUST validate the embedded IPv4 source address of the encapsulated IPv6 packet with the IPv4 source address it is encapsulated by according to the parameters of the matching mapping rule. If the two source addresses do not match, the packet MUST be dropped and a counter incremented to indicate that a potential spoofing attack may be underway. Additionally, a CE MUST allow forwarding of packets sourced by the configured BR IPv6 address. new text: In order to prevent spoofing of IPv4 addresses, the MAP node MUST validate the embedded IPv4 source address and transport layer port of = the encapsulated IPv6 packet with the IPv4 source address and transport layer port it is = encapsulated by according to the parameters of the matching mapping rule. If the two source addresses and transport layer ports do not match, the packet MUST be = silently discard and a counter incremented to indicate that a potential spoofing attack may be underway. Additionally, a CE MUST allow forwarding of packets sourced by the configured BR IPv6 address. cheers, Ole= From rajiva@cisco.com Mon Aug 5 13:00:24 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD80521F9E40 for ; Mon, 5 Aug 2013 13:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2oA3f6yxO3Mj for ; Mon, 5 Aug 2013 13:00:19 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id B030121F99B8 for ; Mon, 5 Aug 2013 13:00:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1514; q=dns/txt; s=iport; t=1375732819; x=1376942419; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=jyMR+FW8In/Ti06c9wUvatiOt/YxCgwHmJiuGDNGOzw=; b=iVm43ldiPXkkAA45YoIzUyVoEj75wg6D9mctd0Drz3EYfIUjn1HzYG/9 uTk0dvuIM+wCOckxEZiBqk13zv1//IqWyrAHjB4rUSGjtbPc4Xt6JaAAA 8loehFIfIMVlBfcjnqUEg5wSfh4FAVyMyxB7znxRfqLVOnl7y46/TP5p4 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAJYDAFKtJXG//2dsb2JhbABbgwY1UL51gSEWdIIkAQEBBAEBATc0CwwGAQgOAwMBAgsUNwsdCAIEAQ0FCIgIDLUqBI9oMQcGgxN0A6kvgxeCKg X-IronPort-AV: E=Sophos;i="4.89,820,1367971200"; d="scan'208";a="243709058" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 05 Aug 2013 20:00:16 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r75K0GRv008975 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Aug 2013 20:00:16 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.225]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Mon, 5 Aug 2013 15:00:16 -0500 From: "Rajiv Asati (rajiva)" To: Ole Troan , Simon Perreault Thread-Topic: [Softwires] Random comments about DHCP discussion Thread-Index: AQHOjRorRwZeVGbONU6T2JBcD4/uEJl9qUcBgAeBLYCAAGmeAIABHBkAgABzLQA= Date: Mon, 5 Aug 2013 20:00:16 +0000 Message-ID: In-Reply-To: <12963F39-1549-489A-83CB-E6BFE491B938@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.82.222.46] Content-Type: text/plain; charset="us-ascii" Content-ID: <054D21FC02EF8948A74F6353892D368D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org" Subject: Re: [Softwires] Random comments about DHCP discussion X-BeenThere: softwires@ietf.org 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: Mon, 05 Aug 2013 20:00:24 -0000 I agree with Ole.=20 Whether a given network deployment needs multiple domains (per CPE or per network) should be left for the operator to decide. Protocol should accommodate that. Cheers, Rajiv -----Original Message----- From: Ole Troan Date: Monday, August 5, 2013 5:07 AM To: Simon Perreault Cc: Softwires-wg list Subject: Re: [Softwires] Random comments about DHCP discussion >guys, > >> You two seem to be talking about different things. Mark seems to be >>saying that multiple FRULEs is necessary, while Rajiv seems to be >>concerned with multiple BRULEs. >>=20 >> So far it has been clear that multiple FRULEs are necessary. The >>question (multiple MAP domains) refers to multiple BRULEs. If we want >>multiple BRULEs, then we need to be able to associate FRULEs with the >>corresponding BRULE. One way to do that would be to create a container >>option, another would be to tag them with identifiers. Both alternatives >>are not very attractive. > >do we need to reopen this debate? this issue has been discussed >previously and the MAP base document has passed WGLC. >MAP does support multiple rules, and multiple domains. > >it would be unfortunate if the DHCP provisioning mechanism would not >support multiple domains. > >cheers, >Ole >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires From rajiva@cisco.com Mon Aug 5 13:00:37 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5E121F9425 for ; Mon, 5 Aug 2013 13:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5vfQQCi7mtyV for ; Mon, 5 Aug 2013 13:00:32 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 86AAC21F9703 for ; Mon, 5 Aug 2013 13:00:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2782; q=dns/txt; s=iport; t=1375732828; x=1376942428; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Oq1w9og+KcJQohmiSM5zMaunK6+7em/oBy+jmCZ3mnE=; b=QoyRs5Ify5P7A9VbEjrcI/FU7M7wYaON5wVAuSingE59xGKH0O0cGX1L k+Q4R8ZINTP1dnKOt9qolwtTzjMUuCUSPLYYwMgtTKISoucRi1CzrxprP x/3penP+vz4Wnd8pyyNl2kDoVxu1juJZEAHILk1S3S57Y+b1L6Vu+si/j E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAJYDAFKtJV2a/2dsb2JhbABbgwY1UL51gSEWdIIkAQEBBAEBATc0CwwGAQgOAwMBAgsUMQYLHQgCBAENBQiHdgMPDKxDDYhaBI0ngkExBwaDE3QDlAmBbo4RhSeDF4FqJBw X-IronPort-AV: E=Sophos;i="4.89,820,1367971200"; d="scan'208";a="243709149" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 05 Aug 2013 20:00:28 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r75K0RoB024590 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Aug 2013 20:00:27 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.225]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Mon, 5 Aug 2013 15:00:27 -0500 From: "Rajiv Asati (rajiva)" To: Ole Troan , Tom Taylor Thread-Topic: [Softwires] Ambiguity in MAP-E receiving rules Thread-Index: AQHOkcT5TPeMmw3iMUWs1kv06FM8gZmHGggA Date: Mon, 5 Aug 2013 20:00:27 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.82.222.46] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org" Subject: Re: [Softwires] Ambiguity in MAP-E receiving rules X-BeenThere: softwires@ietf.org 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: Mon, 05 Aug 2013 20:00:37 -0000 The updated text looks reasonable to me. -----Original Message----- From: Ole Troan Date: Monday, August 5, 2013 6:16 AM To: Tom Taylor Cc: Softwires-wg list Subject: Re: [Softwires] Ambiguity in MAP-E receiving rules >>>=20 >> [PTT] Is there any point to having the CPE generate logs? Who would >>look at them -- the operator or the customer? If logging is useful on >>the CPE, that should be reflected in our logging drafts, but if not, not. >>=20 >>> [ian] It may be useful to have the option of sending an ICMP error >>>message >>> for troubleshooting. What about if we have a 'should' requirement for >>> logging the error on the CPE and a 'may' for sending an ICMP error >>>message? > >RFC5969 has the following text: > In order to prevent spoofing of IPv6 addresses, the 6rd BR and CE > MUST validate the embedded IPv4 source address of the encapsulated > IPv6 packet with the IPv4 source address it is encapsulated by > according to the configured parameters of the 6rd domain. If the two > source addresses do not match, the packet MUST be dropped and a > counter incremented to indicate that a potential spoofing attack may > be underway. > >section 8.1 already say MUST drop for packets to an IPv4 address not >belonging to it. >I suggest we add that for ports too: > >old text: > > In order to prevent spoofing of IPv4 addresses, the MAP node MUST > validate the embedded IPv4 source address of the encapsulated IPv6 > packet with the IPv4 source address it is encapsulated by according > to the parameters of the matching mapping rule. If the two source > addresses do not match, the packet MUST be dropped and a counter > incremented to indicate that a potential spoofing attack may be > underway. Additionally, a CE MUST allow forwarding of packets > sourced by the configured BR IPv6 address. > >new text: > > In order to prevent spoofing of IPv4 addresses, the MAP node MUST > validate the embedded IPv4 source address and transport layer port of >the encapsulated IPv6 > packet with the IPv4 source address and transport layer port it is >encapsulated by according > to the parameters of the matching mapping rule. If the two source > addresses and transport layer ports do not match, the packet MUST be >silently discard and a counter > incremented to indicate that a potential spoofing attack may be > underway. Additionally, a CE MUST allow forwarding of packets > sourced by the configured BR IPv6 address. > > > >cheers, >Ole >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires From simon.perreault@viagenie.ca Tue Aug 6 01:19:11 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB0921F9FF3 for ; Tue, 6 Aug 2013 01:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZpONTXX05Oxz for ; Tue, 6 Aug 2013 01:19:10 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7F021F9C41 for ; Tue, 6 Aug 2013 01:19:06 -0700 (PDT) Received: from porto.nomis80.org (unknown [37.160.232.221]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 5FBA940447; Tue, 6 Aug 2013 04:19:03 -0400 (EDT) Message-ID: <5200B171.7020404@viagenie.ca> Date: Tue, 06 Aug 2013 10:18:57 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Ole Troan References: <51F7A719.6030202@gmail.com> <31E009BB-61DF-4C95-9859-2A2F345E7837@cisco.com> <51FE7D1C.1090806@viagenie.ca> <12963F39-1549-489A-83CB-E6BFE491B938@employees.org> In-Reply-To: <12963F39-1549-489A-83CB-E6BFE491B938@employees.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: softwires@ietf.org Subject: Re: [Softwires] Random comments about DHCP discussion X-BeenThere: softwires@ietf.org 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: Tue, 06 Aug 2013 08:19:11 -0000 Le 2013-08-05 11:07, Ole Troan a écrit : >> You two seem to be talking about different things. Mark seems to be saying that multiple FRULEs is necessary, while Rajiv seems to be concerned with multiple BRULEs. >> >> So far it has been clear that multiple FRULEs are necessary. The question (multiple MAP domains) refers to multiple BRULEs. If we want multiple BRULEs, then we need to be able to associate FRULEs with the corresponding BRULE. One way to do that would be to create a container option, another would be to tag them with identifiers. Both alternatives are not very attractive. > > do we need to reopen this debate? this issue has been discussed previously and the MAP base document has passed WGLC. > MAP does support multiple rules, and multiple domains. > > it would be unfortunate if the DHCP provisioning mechanism would not support multiple domains. Agreed, and it would be similar for multiple LW4o6 domains, or both a MAP and a LW4o6 domain on the same connection. I just wanted to ensure we were all discussing the same thing. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From internet-drafts@ietf.org Mon Aug 12 05:37:34 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D87721F8A53; Mon, 12 Aug 2013 05:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DluYkX+iJcge; Mon, 12 Aug 2013 05:37:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A62921F92B7; Mon, 12 Aug 2013 05:17:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130812121654.30206.92319.idtracker@ietfa.amsl.com> Date: Mon, 12 Aug 2013 05:16:54 -0700 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-map-08.txt X-BeenThere: softwires@ietf.org 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: Mon, 12 Aug 2013 12:37:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Softwires Working Group of the IETF. Title : Mapping of Address and Port with Encapsulation (MAP) Author(s) : Ole Troan Wojciech Dec Xing Li Congxiao Bao Satoru Matsushima Tetsuya Murakami Tom Taylor Filename : draft-ietf-softwire-map-08.txt Pages : 30 Date : 2013-08-12 Abstract: This document describes a mechanism for transporting IPv4 packets across an IPv6 network using IP encapsulation, and a generic mechanism for mapping between IPv6 addresses and IPv4 addresses and transport layer ports. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-map There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-map-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-map-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mohamed.boucadair@orange.com Mon Aug 12 06:58:36 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95E6211E8103 for ; Mon, 12 Aug 2013 06:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ADbH9L6yhQR for ; Mon, 12 Aug 2013 06:58:32 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 6E07C21F8749 for ; Mon, 12 Aug 2013 06:53:25 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id B2B851D002D for ; Mon, 12 Aug 2013 15:53:24 +0200 (CEST) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 9AF704C066 for ; Mon, 12 Aug 2013 15:53:24 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Mon, 12 Aug 2013 15:53:24 +0200 From: To: "softwires@ietf.org" Date: Mon, 12 Aug 2013 15:53:22 +0200 Thread-Topic: I-D Action: draft-ietf-softwire-map-08.txt Thread-Index: Ac6XWNc75vo2WG0QRPuy+J8k7E+65QACd35Q Message-ID: <94C682931C08B048B7A8645303FDC9F36EEC7E980D@PUEXCB1B.nanterre.francetelecom.fr> References: <20130812121654.30206.92319.idtracker@ietfa.amsl.com> In-Reply-To: <20130812121654.30206.92319.idtracker@ietfa.amsl.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.8.12.130336 Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-map-08.txt X-BeenThere: softwires@ietf.org 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: Mon, 12 Aug 2013 13:58:36 -0000 Ole, all, I have two comments about the new version: * The document does not cite the unified CPE I-D. I think Senthil already r= aised this point to the authors, but it seems this was not taken into accou= nt. I suggest adding that document as a normative reference. =20 * I-D.ietf-softwire-map-dhcp is to be listed as an example to achieve provi= sioning (other means can be supported). This ref can be cited as informativ= e and not normative one. Cheers, Med >-----Message d'origine----- >De=A0: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org= ] >De la part de internet-drafts@ietf.org >Envoy=E9=A0: lundi 12 ao=FBt 2013 14:17 >=C0=A0: i-d-announce@ietf.org >Cc=A0: softwires@ietf.org >Objet=A0: I-D Action: draft-ietf-softwire-map-08.txt > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Softwires Working Group of the IETF. > > Title : Mapping of Address and Port with Encapsulation >(MAP) > Author(s) : Ole Troan > Wojciech Dec > Xing Li > Congxiao Bao > Satoru Matsushima > Tetsuya Murakami > Tom Taylor > Filename : draft-ietf-softwire-map-08.txt > Pages : 30 > Date : 2013-08-12 > >Abstract: > This document describes a mechanism for transporting IPv4 packets > across an IPv6 network using IP encapsulation, and a generic > mechanism for mapping between IPv6 addresses and IPv4 addresses and > transport layer ports. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-softwire-map > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-softwire-map-08 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-map-08 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From bingxuere@gmail.com Mon Aug 12 07:10:32 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAAD721F9F1F for ; Mon, 12 Aug 2013 07:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGnGxFTSobAp for ; Mon, 12 Aug 2013 07:10:32 -0700 (PDT) Received: from mail-vb0-x233.google.com (mail-vb0-x233.google.com [IPv6:2607:f8b0:400c:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 576B221F9D2A for ; Mon, 12 Aug 2013 07:03:27 -0700 (PDT) Received: by mail-vb0-f51.google.com with SMTP id x16so5724093vbf.24 for ; Mon, 12 Aug 2013 07:03:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=6amp1I0WMWo5aAEsLDjWIa47hJlnCRvPWhTWRH+O2As=; b=CosYnQ5WD8qCOd9iPMQFygeNxdLAb0jZH9EHvNjmmw4mXETQ1j8ux1Pqu+Dmv59W+y taDZ06bSqJejp6SoJiwKjzYBtBsRC/WliiIGZGUtm5DqG6+lySEiKIzwzph/4lEc4zN4 YIh+rS9Vh7Q4xdKieL3XoLjow4hMI6617r5VDTlzRS2TfksIoQxm887qqi9mPafDq2zX h1RX4OURrOxH8a/VjhzbsT/Wif6Xs8ABeQiJqCiOhW8NWQ0vFMdShSPU6Mm1QaO9ETKL 9bV0oewYBK0yQxy1PxQLcuGbqbz8xAIDMJrtI9G+OHLWqEssioDV6wwdJmLlLzOES4ve 5gSQ== X-Received: by 10.221.56.194 with SMTP id wd2mr12970530vcb.7.1376316205474; Mon, 12 Aug 2013 07:03:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.187.66 with HTTP; Mon, 12 Aug 2013 07:02:45 -0700 (PDT) In-Reply-To: <2FEEDE52-3C39-4680-91A0-E8999840920B@huawei.com> References: <2FEEDE52-3C39-4680-91A0-E8999840920B@huawei.com> From: Qiong Date: Mon, 12 Aug 2013 22:02:45 +0800 Message-ID: To: Tina TSOU Content-Type: multipart/alternative; boundary=001a11337ef686aa2b04e3c096dd Cc: Softwires-wg , Yong Cui Subject: Re: [Softwires] Adopting 6rd and MAP Multicast Drafts X-BeenThere: softwires@ietf.org 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: Mon, 12 Aug 2013 14:10:32 -0000 --001a11337ef686aa2b04e3c096dd Content-Type: text/plain; charset=UTF-8 Dear all, I also support the adoption. Best wishes Qiong On Wed, Jul 31, 2013 at 2:58 AM, Tina TSOU wrote: > Dear all, > I support the adoption. > > Thank you, > Tina > > On Jul 30, 2013, at 7:25 AM, "Behcet Sarikaya" > wrote: > > Hi all, > > Today in Softwire session there was not enough time for us to present our > drafts on 6rd and MAP multicast support: > http://tools.ietf.org/id/draft-sarikaya-softwire-6rdmulticast-05.txt > and > http://tools.ietf.org/id/draft-sarikaya-softwire-map-multicast-00.txt > > Both drafts are the only drafts presenting the solution and they are > mature enough. > > Suresh recommended Cathy and myself to ask for support from the working > group on these two drafts. > > We hereby ask the WG to support the adoption of these drafts. > > > Thanks, > > Cathy and Behcet > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > -- ============================================== Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =============================================== --001a11337ef686aa2b04e3c096dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear all,

I also support the adop= tion.=C2=A0

Best wishes
Qiong


On Wed, Jul 31, 2013 at 2:58 AM, Tina TSOU <Tina.Tsou.Zou= ting@huawei.com> wrote:
Dear all,
I support the adoption.

Thank you,
Tina

On Jul 30, 2013, at 7:25 AM, "Behcet Sarikaya" <sarikaya2012@gmail.com>= ; wrote:

Hi all,

Today in Softwire session there was not enough time for us to present our d= rafts on 6rd and MAP multicast support:
http://tools.ietf.org/id/draft-sarikaya-softwire-6r= dmulticast-05.txt
and
http://tools.ietf.org/id/draft-sarikaya-softwire-m= ap-multicast-00.txt

Both drafts are the only drafts presenting the solution and they are mature= enough.

Suresh recommended Cathy and myself to ask for support from the working gro= up on these two drafts.

We hereby ask the WG to support the adoption of these drafts.


Thanks,

Cathy and Behcet

_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires




--
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Sun
C= hina Telecom Beijing Research Institude


Open source code:
lig= htweight 4over6: http://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--001a11337ef686aa2b04e3c096dd-- From cuiyong@gmail.com Mon Aug 12 14:14:22 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 065CA21F9EB0 for ; Mon, 12 Aug 2013 14:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ep9n6hYVWpnr for ; Mon, 12 Aug 2013 14:14:21 -0700 (PDT) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB1A21F9E91 for ; Mon, 12 Aug 2013 14:14:21 -0700 (PDT) Received: by mail-ob0-f171.google.com with SMTP id tb18so9650670obb.30 for ; Mon, 12 Aug 2013 14:14:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=a6k77gvm5AXo7J+nx6fRR5V8r6Tm9GWLL3a0krkZX/4=; b=erlKOwAx6/Mw/Fh/VN206ZvCheqVm3S/OQjDjtPbcH6s790nMgBD1b67ovocMkrs88 FsLX8idUBYLeks2bAgttpH9CjBPRPTz/672MaNz5x75uCI4HGUHQj0NCIPa0rQ7XfhYC eJfVrDFRx7/xTXtKsM6W4Pvce86t0oE7fI2FWX8Q9iXV3Fadg2bDbwesFCx4FITknyH9 EcqhYFaQWiLxHGUAbhC885oQdt1aJfr9Z8baNMenvnKLkPEzUBoR8X7h0SSrLM5WMBKK cuqvj7JjhggQT0SSf/NEeYiPY8I8PjqDfMTLS2mKNpv7EvAazE9MVn379DWfYSXiXFUh w5fg== MIME-Version: 1.0 X-Received: by 10.60.155.166 with SMTP id vx6mr934353oeb.28.1376342060871; Mon, 12 Aug 2013 14:14:20 -0700 (PDT) Sender: cuiyong@gmail.com Received: by 10.182.72.98 with HTTP; Mon, 12 Aug 2013 14:14:20 -0700 (PDT) In-Reply-To: References: <2FEEDE52-3C39-4680-91A0-E8999840920B@huawei.com> Date: Tue, 13 Aug 2013 05:14:20 +0800 X-Google-Sender-Auth: hsVjUV1xZrJ5PKCUAUgkSOCBKQ0 Message-ID: From: Yong Cui To: Qiong Content-Type: text/plain; charset=ISO-8859-1 Cc: Softwires-wg Subject: Re: [Softwires] Adopting 6rd and MAP Multicast Drafts X-BeenThere: softwires@ietf.org 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: Mon, 12 Aug 2013 21:14:22 -0000 Thank you for your support on this document. However, we have already had 13 wg documents. If we would like to make our WG more focus, we don't think it's the right time to adopt more documents now. Therefore, I would like to ask the WG to focus on the most important WG documents first. After we submit some of these WG documents and they can pass the IESG evaluation, we can then resume the CFA on new documents. In the meanwhile, you are also welcome to discuss the detailed technologies on both WG documents and new ones. Yong 2013/8/12 Qiong : > Dear all, > > I also support the adoption. > > Best wishes > Qiong > > > On Wed, Jul 31, 2013 at 2:58 AM, Tina TSOU > wrote: >> >> Dear all, >> I support the adoption. >> >> Thank you, >> Tina >> >> On Jul 30, 2013, at 7:25 AM, "Behcet Sarikaya" >> wrote: >> >> Hi all, >> >> Today in Softwire session there was not enough time for us to present our >> drafts on 6rd and MAP multicast support: >> http://tools.ietf.org/id/draft-sarikaya-softwire-6rdmulticast-05.txt >> and >> http://tools.ietf.org/id/draft-sarikaya-softwire-map-multicast-00.txt >> >> Both drafts are the only drafts presenting the solution and they are >> mature enough. >> >> Suresh recommended Cathy and myself to ask for support from the working >> group on these two drafts. >> >> We hereby ask the WG to support the adoption of these drafts. >> >> >> Thanks, >> >> Cathy and Behcet >> >> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >> > > > > -- > ============================================== > Qiong Sun > China Telecom Beijing Research Institude > > > Open source code: > lightweight 4over6: http://sourceforge.net/projects/laft6/ > PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/ > =============================================== > From satoru.matsushima@gmail.com Mon Aug 12 23:05:36 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E010A11E80E3 for ; Mon, 12 Aug 2013 23:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QBwUEo0-w2NN for ; Mon, 12 Aug 2013 23:05:36 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id A315511E80D5 for ; Mon, 12 Aug 2013 23:05:32 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id fp13so5526596lab.10 for ; Mon, 12 Aug 2013 23:05:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=J1ZhlJ6WrNTFLoE8ahFkmvjVDoLRh73uEOcxMZyDfV8=; b=LFlyjOhSbnhi7duvrJ7Qb7DfEnGjSw7GmGtWBgefCkvSo2MQ0Og0r3jESsy6IPf4hD LFW1BMpooeQgvhFO3FVrHDUJErnPu3Au4D4AsUL9x2WAshRewIupK28LDkvylLXp2j3A G+DyC0a7btBB5gbqaco0FPOUHHPIMZ3eonDPYaXKKanZ3IYAE2NFltmGdIEWDb41SG/x /FTpP/34LLmoiclA4dTH9tqaBCBg7vkMq/fFdzLZRFo+6mk2u6HJ/pXOt/frK19/vyHZ ADI+edGVZ63qddCqZ2vi3VIABCEm8xednnebgG7yBsAe71SbgDWf7Xbr9idANeKgoeiW Vzuw== MIME-Version: 1.0 X-Received: by 10.112.210.136 with SMTP id mu8mr2243667lbc.25.1376373922786; Mon, 12 Aug 2013 23:05:22 -0700 (PDT) Received: by 10.112.172.232 with HTTP; Mon, 12 Aug 2013 23:05:22 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EEC7E980D@PUEXCB1B.nanterre.francetelecom.fr> References: <20130812121654.30206.92319.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EEC7E980D@PUEXCB1B.nanterre.francetelecom.fr> Date: Tue, 13 Aug 2013 15:05:22 +0900 Message-ID: From: Satoru Matsushima To: mohamed.boucadair@orange.com Content-Type: multipart/alternative; boundary=001a11c3c704bef35e04e3ce0647 Cc: "softwires@ietf.org" Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-map-08.txt X-BeenThere: softwires@ietf.org 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: Tue, 13 Aug 2013 06:05:37 -0000 --001a11c3c704bef35e04e3ce0647 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Med, thank you for your comments. When I did review the current version of unified cpe draft, I couldn't find any kind of stuff on which the map draft should depend so please point things out more specific to what unified cpe draft want map to be. cheers, --satoru On Mon, Aug 12, 2013 at 10:53 PM, wrote: > Ole, all, > > I have two comments about the new version: > > * The document does not cite the unified CPE I-D. I think Senthil already > raised this point to the authors, but it seems this was not taken into > account. I suggest adding that document as a normative reference. > > * I-D.ietf-softwire-map-dhcp is to be listed as an example to achieve > provisioning (other means can be supported). This ref can be cited as > informative and not normative one. > > Cheers, > Med > > >-----Message d'origine----- > >De : i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org= ] > >De la part de internet-drafts@ietf.org > >Envoy=E9 : lundi 12 ao=FBt 2013 14:17 > >=C0 : i-d-announce@ietf.org > >Cc : softwires@ietf.org > >Objet : I-D Action: draft-ietf-softwire-map-08.txt > > > > > >A New Internet-Draft is available from the on-line Internet-Drafts > >directories. > > This draft is a work item of the Softwires Working Group of the IETF. > > > > Title : Mapping of Address and Port with Encapsulation > >(MAP) > > Author(s) : Ole Troan > > Wojciech Dec > > Xing Li > > Congxiao Bao > > Satoru Matsushima > > Tetsuya Murakami > > Tom Taylor > > Filename : draft-ietf-softwire-map-08.txt > > Pages : 30 > > Date : 2013-08-12 > > > >Abstract: > > This document describes a mechanism for transporting IPv4 packets > > across an IPv6 network using IP encapsulation, and a generic > > mechanism for mapping between IPv6 addresses and IPv4 addresses and > > transport layer ports. > > > > > >The IETF datatracker status page for this draft is: > >https://datatracker.ietf.org/doc/draft-ietf-softwire-map > > > >There's also a htmlized version available at: > >http://tools.ietf.org/html/draft-ietf-softwire-map-08 > > > >A diff from the previous version is available at: > >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-map-08 > > > > > >Please note that it may take a couple of minutes from the time of > >submission > >until the htmlized version and diff are available at tools.ietf.org. > > > >Internet-Drafts are also available by anonymous FTP at: > >ftp://ftp.ietf.org/internet-drafts/ > > > >_______________________________________________ > >I-D-Announce mailing list > >I-D-Announce@ietf.org > >https://www.ietf.org/mailman/listinfo/i-d-announce > >Internet-Draft directories: http://www.ietf.org/shadow.html > >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --001a11c3c704bef35e04e3ce0647 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Med, thank you for your comments.

When I did review the current version of unified cpe draft, I couldn= 9;t find any kind of stuff on which the map draft should depend so please p= oint things out more specific to what unified cpe draft want map to be.

cheers,
--satoru


On Mon, Aug = 12, 2013 at 10:53 PM, <mohamed.boucadair@orange.com> wrote:
Ole, all,

I have two comments about the new version:

* The document does not cite the unified CPE I-D. I think Senthil already r= aised this point to the authors, but it seems this was not taken into accou= nt. I suggest adding that document as a normative reference.

* I-D.ietf-softwire-map-dhcp is to be listed as an example to achieve provi= sioning (other means can be supported). This ref can be cited as informativ= e and not normative one.

Cheers,
Med

>-----Message d'origine-----
>De=A0: i-d-announce-bo= unces@ietf.org [mailto:i-d-announce-bounces@ietf.org]
>De la part de internet-draf= ts@ietf.org
>Envoy=E9=A0: lundi 12 ao=FBt 2013 14:17
>=C0=A0: i-d-announce@ietf.org<= /a>
>Cc=A0: softwires@ietf.org
>Objet=A0: I-D Action: draft-ietf-softwire-map-08.txt
>
>
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
> This draft is a work item of the Softwires Working Group of the IETF.<= br> >
> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Mapping of Address and Port wi= th Encapsulation
>(MAP)
> =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Ole Troan
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Wojciech Dec
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Xing Li
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Congxiao Bao
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Satoru Matsushima > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Tetsuya Murakami > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Tom Taylor
> =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-softwire-map-08.txt > =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 30
> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-08-12
>
>Abstract:
> =A0 This document describes a mechanism for transporting IPv4 packets<= br> > =A0 across an IPv6 network using IP encapsulation, and a generic
> =A0 mechanism for mapping between IPv6 addresses and IPv4 addresses an= d
> =A0 transport layer ports.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-softwire-map
>
>There's also a htmlized version available at:
>http://tools.ietf.org/html/draft-ietf-softwire-map-08
>
>A diff from the previous version is available at:
>http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire= -map-08
>
>
>Please note that it may take a couple of minutes from the time of
>submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp:/= /ftp.ietf.org/internet-drafts/
>
>_______________________________________________
>I-D-Announce mailing list
>I-D-Announce@ietf.org
>https://www.ietf.org/mailman/listinfo/i-d-announce
>Internet-Draft directories: http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
___________________________________= ____________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

--001a11c3c704bef35e04e3ce0647-- From otroan@employees.org Tue Aug 13 00:34:22 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB3F621F99B8 for ; Tue, 13 Aug 2013 00:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MWokdn2wne8t for ; Tue, 13 Aug 2013 00:34:22 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id 4D30821F8904 for ; Tue, 13 Aug 2013 00:34:22 -0700 (PDT) Received: from dhcp-lys01-vla250-10-147-112-207.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id DC48C5E85; Tue, 13 Aug 2013 00:34:19 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ole Troan In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EEC7E980D@PUEXCB1B.nanterre.francetelecom.fr> Date: Tue, 13 Aug 2013 09:34:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <86841AD5-1864-4177-BEE1-4181DDE085EF@employees.org> References: <20130812121654.30206.92319.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EEC7E980D@PUEXCB1B.nanterre.francetelecom.fr> To: mohamed.boucadair@orange.com X-Mailer: Apple Mail (2.1508) Cc: "softwires@ietf.org" Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-map-08.txt X-BeenThere: softwires@ietf.org 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: Tue, 13 Aug 2013 07:34:22 -0000 Med, > I have two comments about the new version: >=20 > * The document does not cite the unified CPE I-D. I think Senthil = already raised this point to the authors, but it seems this was not = taken into account. I suggest adding that document as a normative = reference. the unified CPE document depends on MAP, not the other way around.=20 > * I-D.ietf-softwire-map-dhcp is to be listed as an example to achieve = provisioning (other means can be supported). This ref can be cited as = informative and not normative one. true, the reason it is listed as normative is because we have a SHOULD = for DHCP: "A CE that allows IPv6 configuration by DHCP SHOULD implement this = option." cheers, Ole From mohamed.boucadair@orange.com Tue Aug 13 02:10:22 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E46611E812C for ; Tue, 13 Aug 2013 02:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5WAR2k8qb0Wo for ; Tue, 13 Aug 2013 02:10:10 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id EA15D21F99F3 for ; Tue, 13 Aug 2013 02:10:09 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 1E13322D79B; Tue, 13 Aug 2013 11:10:09 +0200 (CEST) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id F403635C058; Tue, 13 Aug 2013 11:10:08 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Tue, 13 Aug 2013 11:10:08 +0200 From: To: Satoru Matsushima Date: Tue, 13 Aug 2013 11:10:07 +0200 Thread-Topic: [Softwires] I-D Action: draft-ietf-softwire-map-08.txt Thread-Index: Ac6X6xnbAROEWjHyRa69pB2cNX2zqQAGU9aw Message-ID: <94C682931C08B048B7A8645303FDC9F36EEC7E9914@PUEXCB1B.nanterre.francetelecom.fr> References: <20130812121654.30206.92319.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EEC7E980D@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36EEC7E9914PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.7.26.63617 Cc: "softwires@ietf.org" Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-map-08.txt X-BeenThere: softwires@ietf.org 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: Tue, 13 Aug 2013 09:10:24 -0000 --_000_94C682931C08B048B7A8645303FDC9F36EEC7E9914PUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Satoru, Provisioning-related discussion should be included in the unified CPE not i= n each individual document. This is true for MAP, lw4o6, etc. Ensuring a coherency among ongoing specification documents will require a c= oordination effort among existing documents. Cheers, Med De : Satoru Matsushima [mailto:satoru.matsushima@gmail.com] Envoy=E9 : mardi 13 ao=FBt 2013 08:05 =C0 : BOUCADAIR Mohamed OLNC/OLN Cc : softwires@ietf.org Objet : Re: [Softwires] I-D Action: draft-ietf-softwire-map-08.txt Hi Med, thank you for your comments. When I did review the current version of unified cpe draft, I couldn't find= any kind of stuff on which the map draft should depend so please point thi= ngs out more specific to what unified cpe draft want map to be. cheers, --satoru On Mon, Aug 12, 2013 at 10:53 PM, > wrote: Ole, all, I have two comments about the new version: * The document does not cite the unified CPE I-D. I think Senthil already r= aised this point to the authors, but it seems this was not taken into accou= nt. I suggest adding that document as a normative reference. * I-D.ietf-softwire-map-dhcp is to be listed as an example to achieve provi= sioning (other means can be supported). This ref can be cited as informativ= e and not normative one. Cheers, Med >-----Message d'origine----- >De : i-d-announce-bounces@ietf.org [= mailto:i-d-announce-bounces@ietf.org] >De la part de internet-drafts@ietf.org >Envoy=E9 : lundi 12 ao=FBt 2013 14:17 >=C0 : i-d-announce@ietf.org >Cc : softwires@ietf.org >Objet : I-D Action: draft-ietf-softwire-map-08.txt > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Softwires Working Group of the IETF. > > Title : Mapping of Address and Port with Encapsulation >(MAP) > Author(s) : Ole Troan > Wojciech Dec > Xing Li > Congxiao Bao > Satoru Matsushima > Tetsuya Murakami > Tom Taylor > Filename : draft-ietf-softwire-map-08.txt > Pages : 30 > Date : 2013-08-12 > >Abstract: > This document describes a mechanism for transporting IPv4 packets > across an IPv6 network using IP encapsulation, and a generic > mechanism for mapping between IPv6 addresses and IPv4 addresses and > transport layer ports. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-softwire-map > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-softwire-map-08 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-map-08 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires --_000_94C682931C08B048B7A8645303FDC9F36EEC7E9914PUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Satoru,

 

Provisioning-related discussion should be included in the unified CPE = not in each individual document. This is true for MAP, lw4o6, etc.

Ensuring a coherency among ongoing specifi= cation documents will require a coordination effort among existing document= s. =A0

 

=

Cheers,

Med=

 

De : Satoru Matsushi= ma [mailto:satoru.matsushima@gmail.com]
Envoy=E9 : mardi 13= ao=FBt 2013 08:05
=C0 : BOUCADAIR Mohamed OLNC/OLN
Cc=  : softwires@ietf.org
Objet : Re: [Softwires] I-D A= ction: draft-ietf-softwire-map-08.txt

 

Hi Med, tha= nk you for your comments.

&nbs= p;

When I did review the current v= ersion of unified cpe draft, I couldn't find any kind of stuff on which the= map draft should depend so please point things out more specific to what u= nified cpe draft want map to be.

 

cheers,=

--satoru

 

<= div>

On Mon, Aug 12, 2013 at 10:53 PM, <mohamed.boucadair@ora= nge.com> wrote:

Ole, all,

= I have two comments about the new version:

* The document does not c= ite the unified CPE I-D. I think Senthil already raised this point to the a= uthors, but it seems this was not taken into account. I suggest adding that= document as a normative reference.

* I-D.ietf-softwire-map-dhcp is = to be listed as an example to achieve provisioning (other means can be supp= orted). This ref can be cited as informative and not normative one.

= Cheers,
Med

>-----Message d'origine-----
>De : i-d-announce-bounces@ietf.org<= /a> [mailto:i-d-announce-b= ounces@ietf.org]
>De la part de internet-drafts@ietf.org
>Envoy=E9 : lundi 12 ao= =FBt 2013 14:17
>=C0 : = i-d-announce@ietf.org
>Cc : softwires@ietf.org
>Objet : I-D Action: draft-ietf-sof= twire-map-08.txt

>
><= br>>A New Internet-Draft is available from the on-line Internet-Drafts>directories.
> This draft is a work item of the Softwires Worki= ng Group of the IETF.
>
>       Title   &nb= sp;       : Mapping of Address and Port with Encapsulation>(MAP)
>       Author(s)       : O= le Troan
>                 &n= bsp;        Wojciech Dec
>       &= nbsp;                  Xing Li=
>                   &nb= sp;      Congxiao Bao
>         &n= bsp;                Satoru Matsushi= ma
>                   &= nbsp;      Tetsuya Murakami
>       &nb= sp;                  Tom Taylo= r
>       Filename        : draft-= ietf-softwire-map-08.txt
>       Pages     &= nbsp;     : 30
>       Date     &n= bsp;      : 2013-08-12
>
>Abstract:
> &nbs= p; This document describes a mechanism for transporting IPv4 packets
>= ;   across an IPv6 network using IP encapsulation, and a generic
&g= t;   mechanism for mapping between IPv6 addresses and IPv4 addresses a= nd
>   transport layer ports.
>
>
>The IETF da= tatracker status page for this draft is:
>https://datatra= cker.ietf.org/doc/draft-ietf-softwire-map
>
>There's also a= htmlized version available at:
>http://tools.ietf.org/html/= draft-ietf-softwire-map-08
>
>A diff from the previous vers= ion is available at:
>http://www.ietf.org/rfcdiff?ur= l2=3Ddraft-ietf-softwire-map-08
>
>
>Please note that= it may take a couple of minutes from the time of
>submission
>= until the htmlized version and diff are available at tools.ietf.org.
>
>Internet-D= rafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-dra= fts/
>
>_______________________________________________

>I-D-Announce mailing list>I-D-Announce@ietf.org>https://www.ietf.org/mailman/listinfo/i-d-announce
>I= nternet-Draft directories: http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org= /ietf/1shadow-sites.txt

__= _____________________________________________
Softwires mailing list
= Softwires@ietf.org
https://= www.ietf.org/mailman/listinfo/softwires

 

= --_000_94C682931C08B048B7A8645303FDC9F36EEC7E9914PUEXCB1Bnante_-- From mohamed.boucadair@orange.com Tue Aug 13 02:11:41 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8A8621E80FE for ; Tue, 13 Aug 2013 02:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.148 X-Spam-Level: X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0jgIfzxCpny for ; Tue, 13 Aug 2013 02:11:33 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 3815521E8104 for ; Tue, 13 Aug 2013 02:11:31 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 7D5AD18D3B8; Tue, 13 Aug 2013 11:11:27 +0200 (CEST) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 63F744C05D; Tue, 13 Aug 2013 11:11:27 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Tue, 13 Aug 2013 11:11:26 +0200 From: To: Ole Troan Date: Tue, 13 Aug 2013 11:11:25 +0200 Thread-Topic: [Softwires] I-D Action: draft-ietf-softwire-map-08.txt Thread-Index: Ac6X94meD+NfkZzpRYidJ8WMV1iVUgAC66mQ Message-ID: <94C682931C08B048B7A8645303FDC9F36EEC7E9915@PUEXCB1B.nanterre.francetelecom.fr> References: <20130812121654.30206.92319.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EEC7E980D@PUEXCB1B.nanterre.francetelecom.fr> <86841AD5-1864-4177-BEE1-4181DDE085EF@employees.org> In-Reply-To: <86841AD5-1864-4177-BEE1-4181DDE085EF@employees.org> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.6.28.101520 Cc: "softwires@ietf.org" Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-map-08.txt X-BeenThere: softwires@ietf.org 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: Tue, 13 Aug 2013 09:11:41 -0000 Hi Ole, The documents should be cross-references, that's clear.=20 If I recall well what was discussed (and which I assumed agreed) in Atlanta= , is the unified CPE draft governs the CE side for all softwire flavors. Th= e consequence is provisioning discussion in particular should be removed fr= om MAP, LW4ov6, etc documents ... instead be discussed exclusively in the u= nified CPE I-D.=20 I will refer to Suresh on this point since he was present during that discu= ssion and also because this is a action to preserve the coherency of the ov= erall ongoing specification efforts conducted by the WG. Cheers, Med >-----Message d'origine----- >De=A0: Ole Troan [mailto:otroan@employees.org] >Envoy=E9=A0: mardi 13 ao=FBt 2013 09:34 >=C0=A0: BOUCADAIR Mohamed OLNC/OLN >Cc=A0: softwires@ietf.org >Objet=A0: Re: [Softwires] I-D Action: draft-ietf-softwire-map-08.txt > >Med, > >> I have two comments about the new version: >> >> * The document does not cite the unified CPE I-D. I think Senthil alread= y >raised this point to the authors, but it seems this was not taken into >account. I suggest adding that document as a normative reference. > >the unified CPE document depends on MAP, not the other way around. > >> * I-D.ietf-softwire-map-dhcp is to be listed as an example to achieve >provisioning (other means can be supported). This ref can be cited as >informative and not normative one. > >true, the reason it is listed as normative is because we have a SHOULD for >DHCP: > "A CE that allows IPv6 configuration by DHCP SHOULD implement this >option." > >cheers, >Ole From fibrib@gmail.com Tue Aug 13 02:26:08 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C88511E812C for ; Tue, 13 Aug 2013 02:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VU3dYn76f4oh for ; Tue, 13 Aug 2013 02:26:07 -0700 (PDT) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 44C1B11E812D for ; Tue, 13 Aug 2013 02:26:07 -0700 (PDT) Received: by mail-ob0-f171.google.com with SMTP id tb18so10271191obb.30 for ; Tue, 13 Aug 2013 02:26:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=98zBbkWo1lb4ePSU6drZBHXJtDUN8ULoI2MkJKDRrow=; b=IlE8UceOyNeADdLFfzmfgUXCnqfC05hEg/gzzYVjlmjbho/UyqcIQNR8nxkiYvl7dH LYKEaN9YJjd8kg8UthrrM/ZhwnjJrneRcObmEz9dvDZwTLyKMyS6c+FK5x9ai7bEUoZS nLBnl5Me7Hq7ht3DfnANSHo4SBPAB89J7OPHyQcYofu9wTYIfNEjAu55fvnGrpj8+Wx/ zwLYRvsijubMGcv8UYp5mGv47uB7o+C4WS7WfsmTZIpU7GCTiQSmAEP9+0tKl3i1LHrS 7nkEeOiof2C62VGDyy5jMcBQSP1huVsE1mqRw6BX96TeUqBOdHQmBRzyP6lTH1D+vgDW j1tA== MIME-Version: 1.0 X-Received: by 10.182.65.34 with SMTP id u2mr1006922obs.53.1376385966762; Tue, 13 Aug 2013 02:26:06 -0700 (PDT) Received: by 10.76.24.34 with HTTP; Tue, 13 Aug 2013 02:26:06 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EEC7E9914@PUEXCB1B.nanterre.francetelecom.fr> References: <20130812121654.30206.92319.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EEC7E980D@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EEC7E9914@PUEXCB1B.nanterre.francetelecom.fr> Date: Tue, 13 Aug 2013 18:26:06 +0900 Message-ID: From: Maoke To: "mohamed.boucadair@orange.com" Content-Type: multipart/alternative; boundary=089e0158b00c9f704904e3d0d49b Cc: "softwires@ietf.org" Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-map-08.txt X-BeenThere: softwires@ietf.org 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: Tue, 13 Aug 2013 09:26:08 -0000 --089e0158b00c9f704904e3d0d49b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hi Med and others, IMHO, MAP doesn't depend on any specific provisioning methodology and even manual configuration works well. on the other hand, unified CPE should define a certain method that suitable for both MAP and lw4o6. This difference/relationship doesn't support the bi-directional mutual citation. - maoke 2013/8/13 > Hi Satoru,**** > > ** ** > > Provisioning-related discussion should be included in the unified CPE not > in each individual document. This is true for MAP, lw4o6, etc. **** > > Ensuring a coherency among ongoing specification documents will require a > coordination effort among existing documents. **** > > ** ** > > Cheers,**** > > Med**** > > ** ** > > *De :* Satoru Matsushima [mailto:satoru.matsushima@gmail.com] > *Envoy=E9 :* mardi 13 ao=FBt 2013 08:05 > *=C0 :* BOUCADAIR Mohamed OLNC/OLN > *Cc :* softwires@ietf.org > *Objet :* Re: [Softwires] I-D Action: draft-ietf-softwire-map-08.txt**** > > ** ** > > Hi Med, thank you for your comments.**** > > ** ** > > When I did review the current version of unified cpe draft, I couldn't > find any kind of stuff on which the map draft should depend so please poi= nt > things out more specific to what unified cpe draft want map to be.**** > > ** ** > > cheers,**** > > --satoru**** > > ** ** > > On Mon, Aug 12, 2013 at 10:53 PM, wrote:**= * > * > > Ole, all, > > I have two comments about the new version: > > * The document does not cite the unified CPE I-D. I think Senthil already > raised this point to the authors, but it seems this was not taken into > account. I suggest adding that document as a normative reference. > > * I-D.ietf-softwire-map-dhcp is to be listed as an example to achieve > provisioning (other means can be supported). This ref can be cited as > informative and not normative one. > > Cheers, > Med > > >-----Message d'origine----- > >De : i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org= ] > >De la part de internet-drafts@ietf.org > >Envoy=E9 : lundi 12 ao=FBt 2013 14:17 > >=C0 : i-d-announce@ietf.org > >Cc : softwires@ietf.org > >Objet : I-D Action: draft-ietf-softwire-map-08.txt**** > > > > > > >A New Internet-Draft is available from the on-line Internet-Drafts > >directories. > > This draft is a work item of the Softwires Working Group of the IETF. > > > > Title : Mapping of Address and Port with Encapsulation > >(MAP) > > Author(s) : Ole Troan > > Wojciech Dec > > Xing Li > > Congxiao Bao > > Satoru Matsushima > > Tetsuya Murakami > > Tom Taylor > > Filename : draft-ietf-softwire-map-08.txt > > Pages : 30 > > Date : 2013-08-12 > > > >Abstract: > > This document describes a mechanism for transporting IPv4 packets > > across an IPv6 network using IP encapsulation, and a generic > > mechanism for mapping between IPv6 addresses and IPv4 addresses and > > transport layer ports. > > > > > >The IETF datatracker status page for this draft is: > >https://datatracker.ietf.org/doc/draft-ietf-softwire-map > > > >There's also a htmlized version available at: > >http://tools.ietf.org/html/draft-ietf-softwire-map-08 > > > >A diff from the previous version is available at: > >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-map-08 > > > > > >Please note that it may take a couple of minutes from the time of > >submission > >until the htmlized version and diff are available at tools.ietf.org. > > > >Internet-Drafts are also available by anonymous FTP at: > >ftp://ftp.ietf.org/internet-drafts/ > > > >_______________________________________________**** > > >I-D-Announce mailing list > >I-D-Announce@ietf.org > >https://www.ietf.org/mailman/listinfo/i-d-announce > >Internet-Draft directories: http://www.ietf.org/shadow.html > >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt**** > > _______________________________________________ > 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 > > --089e0158b00c9f704904e3d0d49b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
hi Med and others,

IMHO, MAP doesn= 't depend on any specific provisioning methodology and even manual conf= iguration works well. on the other hand, unified CPE should define a certai= n method that suitable for both MAP and lw4o6. This difference/relationship= doesn't support the bi-directional mutual citation.

- maoke


<= br>
2013/8/13 <mohamed.boucadair@ora= nge.com>

Hi Satoru,<= /p>

=A0

Provisioning-related discussion should be included in the un= ified CPE not in each individual document. This is true for MAP, lw4o6, etc= .

Ensuring a coherency among ongoing specifica= tion documents will require a coordination effort among existing documents.= =A0

=A0

Cheers,

Med

=A0

De= =A0: Satoru Matsushima [mailto:satoru.matsushima= @gmail.com]
Envoy=E9=A0: mardi 13 ao=FBt 2013 08:05
=C0=A0: BOUCADAIR = Mohamed OLNC/OLN
Cc=A0: softwires@ietf.org
Objet=A0: Re: [Softwires] I= -D Action: draft-ietf-softwire-map-08.txt

=A0=

Hi Med, thank you for your comments.=

=A0

When I did review the current version of unified cpe draft, I couldn't = find any kind of stuff on which the map draft should depend so please point= things out more specific to what unified cpe draft want map to be.<= u>

=A0

cheers,

-= -satoru

=A0

On Mon, Aug 12, 2013 at 10= :53 PM, <mohamed.boucadair@orange.com> wrote:

Ole, all,

I have two comments about the new version:

* The do= cument does not cite the unified CPE I-D. I think Senthil already raised th= is point to the authors, but it seems this was not taken into account. I su= ggest adding that document as a normative reference.

* I-D.ietf-softwire-map-dhcp is to be listed as an example to achieve p= rovisioning (other means can be supported). This ref can be cited as inform= ative and not normative one.

Cheers,
Med

>-----Message = d'origine-----
>De=A0: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org]
= >De la part de internet-drafts@ietf.org
>Envoy=E9=A0: lundi 12 ao=FBt 2013 14:17
>=C0=A0: i-d-announce@ietf.org
>= ;Cc=A0: softwires@i= etf.org
>Objet=A0: I-D Action: draft-ietf-softwire-map-08.txt<= /u>

>
>
>A New Internet-Draft i= s available from the on-line Internet-Drafts
>directories.
> Th= is draft is a work item of the Softwires Working Group of the IETF.
>=
> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Mapping of Address and Port wi= th Encapsulation
>(MAP)
> =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : O= le Troan
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Wojciec= h Dec
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Xing Li > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Congxiao Bao
>= ; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Satoru Matsushima
&= gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Tetsuya Murakami
= > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Tom Taylor
> = =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-softwire-map-08.txt
> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 30
> =A0 =A0 =A0 Date = =A0 =A0 =A0 =A0 =A0 =A0: 2013-08-12
>
>Abstract:
> =A0 Th= is document describes a mechanism for transporting IPv4 packets
> =A0= across an IPv6 network using IP encapsulation, and a generic
> =A0 mechanism for mapping between IPv6 addresses and IPv4 addresses an= d
> =A0 transport layer ports.
>
>
>The IETF datatr= acker status page for this draft is:
>https://datatracker= .ietf.org/doc/draft-ietf-softwire-map
>
>There's also a htmlized version available at:
>http://tools.ietf.org/html/draft-ietf-softwire-map-08
>
>= ;A diff from the previous version is available at:
>http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire= -map-08
>
>
>Please note that it may take a couple of= minutes from the time of
>submission
>until the htmlized version and diff are available at = tools.ietf.org.
= >
>Internet-Drafts are also available by anonymous FTP at:
>= ftp://ftp= .ietf.org/internet-drafts/
>
>_______________________________________________

>I-D-Announce mailing list
><= a href=3D"mailto:I-D-Announce@ietf.org" target=3D"_blank">I-D-Announce@ietf= .org
>https://www.ietf.org/mailman/listinfo/i-d-announce
>I= nternet-Draft directories: http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

_______________________________________________Softwires mailing list
Softwires@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/softwires

=A0

<= /div>

_______________________________________________<= br> Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires


--089e0158b00c9f704904e3d0d49b-- From otroan@employees.org Tue Aug 13 02:46:10 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 039E921E80F9 for ; Tue, 13 Aug 2013 02:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kDXwA-o48sTn for ; Tue, 13 Aug 2013 02:46:04 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9E821E8097 for ; Tue, 13 Aug 2013 02:46:04 -0700 (PDT) Received: from dhcp-lys01-vla250-10-147-112-207.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 355725E61; Tue, 13 Aug 2013 02:45:56 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ole Troan In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EEC7E9915@PUEXCB1B.nanterre.francetelecom.fr> Date: Tue, 13 Aug 2013 11:45:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8FF0368A-D069-4BDA-9919-58FE22B81026@employees.org> References: <20130812121654.30206.92319.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EEC7E980D@PUEXCB1B.nanterre.francetelecom.fr> <86841AD5-1864-4177-BEE1-4181DDE085EF@employees.org> <94C682931C08B048B7A8645303FDC9F36EEC7E9915@PUEXCB1B.nanterre.francetelecom.fr> To: X-Mailer: Apple Mail (2.1508) Cc: "softwires@ietf.org" Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-map-08.txt X-BeenThere: softwires@ietf.org 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: Tue, 13 Aug 2013 09:46:10 -0000 Med, > The documents should be cross-references, that's clear.=20 >=20 > If I recall well what was discussed (and which I assumed agreed) in = Atlanta, is the unified CPE draft governs the CE side for all softwire = flavors. The consequence is provisioning discussion in particular should = be removed from MAP, LW4ov6, etc documents ... instead be discussed = exclusively in the unified CPE I-D.=20 >=20 > I will refer to Suresh on this point since he was present during that = discussion and also because this is a action to preserve the coherency = of the overall ongoing specification efforts conducted by the WG. the MAP document only specifies how a CE must function and what = parameters must be provisioned. there is no provisioning discussion = there to remove as far as I can see. MAP as a mechanism should stand on = its own. the unified CPE effort, if successful, is trying to create a coherent = picture of all the different mechanisms to make it possible to support = all of them in a single CPE. my understanding of the unified CPE effort = was that it was NOT going to define protocol, but only specify how = mechanisms co-exist. cheers, Ole= From sunqi.csnet.thu@gmail.com Tue Aug 13 03:11:25 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 504E011E811F for ; Tue, 13 Aug 2013 03:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GcaDMS0ueh0Y for ; Tue, 13 Aug 2013 03:11:24 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD6611E8138 for ; Tue, 13 Aug 2013 03:11:21 -0700 (PDT) Received: by mail-pa0-f52.google.com with SMTP id kq13so8600825pab.39 for ; Tue, 13 Aug 2013 03:11:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WMLxOtlI6BmJhaMe4WMJUYX+WvWwZJKO+7om6A8LvUk=; b=JzQpotzuGzE1czyi0wPYRQWZDwLv/8T9SPs2XqxPLKkqZIgbeU9tgXaqxiyN4914/L EG/EKO+KSPp6ZgObR5bEVFnltZjARCcsGISej3uGUVH/Nrvw6lwxWeezzbOdlmIahl9L UKOTmLKxajak0G0ykl9WdvphzDrYUHcO5GsdgWDvHqdILB2KjsIo4X9il0QBFWv71ni4 sC5eVq9U3/0KKjfyZxrZ0ba4IhQLStsVcSvKosMYBcR4vDTUH3NA6vfltIziPDJHjZBc zUiwU8z1hHKBz0r+bVHWiARmYoGzNLjs8srz1rWYoyZu/hlJrznA/HA4UonBbl57vn+k R9Zw== X-Received: by 10.66.243.196 with SMTP id xa4mr1161769pac.174.1376388680953; Tue, 13 Aug 2013 03:11:20 -0700 (PDT) Received: from [192.168.0.103] ([112.238.32.82]) by mx.google.com with ESMTPSA id nv6sm42932308pbc.6.2013.08.13.03.11.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 13 Aug 2013 03:11:20 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: Qi Sun In-Reply-To: <8FF0368A-D069-4BDA-9919-58FE22B81026@employees.org> Date: Tue, 13 Aug 2013 18:11:11 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <9B5FC5D7-45F6-4768-9B96-66114662FA09@gmail.com> References: <20130812121654.30206.92319.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EEC7E980D@PUEXCB1B.nanterre.francetelecom.fr> <86841AD5-1864-4177-BEE1-4181DDE085EF@employees.org> <94C682931C08B048B7A8645303FDC9F36EEC7E9915@PUEXCB1B.nanterre.francetelecom.fr> <8FF0368A-D069-4BDA-9919-58FE22B81026@employees.org> To: Ole Troan X-Mailer: Apple Mail (2.1084) Cc: "softwires@ietf.org" Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-map-08.txt X-BeenThere: softwires@ietf.org 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: Tue, 13 Aug 2013 10:11:25 -0000 Hi Ole , IMHO, the Unified CPE defines some functionalities and behaviors of CE = side, e.g. tunnel endpoint, NAT44, how to use these functions on CPE = etc., which MAP depends on.=20 As for the provisioning method, map-dhcp is one of the methods could be = used in MAP. The discussion is taking place in the Unified CPE for = provisioning. So I think it should be an informative reference in MAP = base draft. Best Regards, Qi On 2013-8-13, at =E4=B8=8B=E5=8D=885:45, Ole Troan wrote: > Med, >=20 >> The documents should be cross-references, that's clear.=20 >>=20 >> If I recall well what was discussed (and which I assumed agreed) in = Atlanta, is the unified CPE draft governs the CE side for all softwire = flavors. The consequence is provisioning discussion in particular should = be removed from MAP, LW4ov6, etc documents ... instead be discussed = exclusively in the unified CPE I-D.=20 >>=20 >> I will refer to Suresh on this point since he was present during that = discussion and also because this is a action to preserve the coherency = of the overall ongoing specification efforts conducted by the WG. >=20 > the MAP document only specifies how a CE must function and what = parameters must be provisioned. there is no provisioning discussion = there to remove as far as I can see. MAP as a mechanism should stand on = its own. >=20 > the unified CPE effort, if successful, is trying to create a coherent = picture of all the different mechanisms to make it possible to support = all of them in a single CPE. my understanding of the unified CPE effort = was that it was NOT going to define protocol, but only specify how = mechanisms co-exist. >=20 > cheers, > Ole > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From otroan@employees.org Tue Aug 13 04:16:05 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7ED021E8119 for ; Tue, 13 Aug 2013 04:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iScKethp15Yu for ; Tue, 13 Aug 2013 04:15:59 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id D4A9521F9A13 for ; Tue, 13 Aug 2013 04:15:46 -0700 (PDT) Received: from dhcp-lys01-vla250-10-147-112-207.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 447025F57; Tue, 13 Aug 2013 04:15:44 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ole Troan In-Reply-To: <9B5FC5D7-45F6-4768-9B96-66114662FA09@gmail.com> Date: Tue, 13 Aug 2013 13:15:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <77DB9DB1-90D8-447F-A4D2-D130FB277115@employees.org> References: <20130812121654.30206.92319.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EEC7E980D@PUEXCB1B.nanterre.francetelecom.fr> <86841AD5-1864-4177-BEE1-4181DDE085EF@employees.org> <94C682931C08B048B7A8645303FDC9F36EEC7E9915@PUEXCB1B.nanterre.francetelecom.fr> <8FF0368A-D069-4BDA-9919-58FE22B81026@employees.org> <9B5FC5D7-45F6-4768-9B96-66114662FA09@gmail.com> To: Qi Sun X-Mailer: Apple Mail (2.1508) Cc: "softwires@ietf.org" Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-map-08.txt X-BeenThere: softwires@ietf.org 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: Tue, 13 Aug 2013 11:16:05 -0000 Qi, > IMHO, the Unified CPE defines some functionalities and behaviors of CE = side, e.g. tunnel endpoint, NAT44, how to use these functions on CPE = etc., which MAP depends on.=20 >=20 > As for the provisioning method, map-dhcp is one of the methods could = be used in MAP. The discussion is taking place in the Unified CPE for = provisioning. So I think it should be an informative reference in MAP = base draft. so you are saying that draft-ietf-softwire-map cannot stand on its own, = but depend on text in unified CPE? if so, what is missing? which parts of the unified CPE draft should be = referenced? please propose text changes to the document. I am open to the possibility that I'm wrong of course, but I can't know = that for sure, before I see what text changes you propose. I'm not trying to be difficult (at least not more than usual), but the = document has passed WGLC, and we're restrictive about accepting changes. cheers, Ole= From mohamed.boucadair@orange.com Tue Aug 13 04:58:56 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66D9111E8166 for ; Tue, 13 Aug 2013 04:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id INOGz68MiOxq for ; Tue, 13 Aug 2013 04:58:51 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 292EE11E8165 for ; Tue, 13 Aug 2013 04:58:51 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 3E708325BB2; Tue, 13 Aug 2013 13:58:50 +0200 (CEST) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 0713027C069; Tue, 13 Aug 2013 13:58:50 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Tue, 13 Aug 2013 13:58:49 +0200 From: To: Ole Troan Date: Tue, 13 Aug 2013 13:58:48 +0200 Thread-Topic: [Softwires] I-D Action: draft-ietf-softwire-map-08.txt Thread-Index: Ac6YCe5sxEuCTIzrSeORsyUsnCkUdgAER+kQ Message-ID: <94C682931C08B048B7A8645303FDC9F36EEC7E9976@PUEXCB1B.nanterre.francetelecom.fr> References: <20130812121654.30206.92319.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EEC7E980D@PUEXCB1B.nanterre.francetelecom.fr> <86841AD5-1864-4177-BEE1-4181DDE085EF@employees.org> <94C682931C08B048B7A8645303FDC9F36EEC7E9915@PUEXCB1B.nanterre.francetelecom.fr> <8FF0368A-D069-4BDA-9919-58FE22B81026@employees.org> In-Reply-To: <8FF0368A-D069-4BDA-9919-58FE22B81026@employees.org> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.7.1.45418 Cc: "softwires@ietf.org" Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-map-08.txt X-BeenThere: softwires@ietf.org 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: Tue, 13 Aug 2013 11:58:56 -0000 Re-, It seems we agree on the provisioning part of the discussion. The MAP docum= ent should be sufficient in its own and should not make any assumption on h= ow configuration parameters are provisioned. This can be done manually or d= ynamically (e.g., dhcp). So, any reference to a provisioning means should b= e informative, and even better be removed in favor of a single pointer to t= he unified CPE, where all this is discussed.=20 Then, to the question why I'm asking for this I-D to be referenced as norma= tive and not informative, the answer is that the generic bootstrapping logi= c described in the unified CPE must be followed by all softwire solution fl= avors. That's the minimum bar I see if we really want all a consistency to = be ensured. Ideally, the CE part of all solutions should be documented in t= he unified CPE while the BR/lwAFTR parts in MAP and lw4o6 document, but I w= on't ask for that. Cheers, Med >-----Message d'origine----- >De=A0: Ole Troan [mailto:otroan@employees.org] >Envoy=E9=A0: mardi 13 ao=FBt 2013 11:46 >=C0=A0: BOUCADAIR Mohamed OLNC/OLN >Cc=A0: softwires@ietf.org >Objet=A0: Re: [Softwires] I-D Action: draft-ietf-softwire-map-08.txt > >Med, > >> The documents should be cross-references, that's clear. >> >> If I recall well what was discussed (and which I assumed agreed) in >Atlanta, is the unified CPE draft governs the CE side for all softwire >flavors. The consequence is provisioning discussion in particular should b= e >removed from MAP, LW4ov6, etc documents ... instead be discussed >exclusively in the unified CPE I-D. >> >> I will refer to Suresh on this point since he was present during that >discussion and also because this is a action to preserve the coherency of >the overall ongoing specification efforts conducted by the WG. > >the MAP document only specifies how a CE must function and what parameters >must be provisioned. there is no provisioning discussion there to remove a= s >far as I can see. MAP as a mechanism should stand on its own. > >the unified CPE effort, if successful, is trying to create a coherent >picture of all the different mechanisms to make it possible to support all >of them in a single CPE. my understanding of the unified CPE effort was >that it was NOT going to define protocol, but only specify how mechanisms >co-exist. > >cheers, >Ole From mohamed.boucadair@orange.com Tue Aug 13 05:12:39 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31A9421E80AE for ; Tue, 13 Aug 2013 05:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.188 X-Spam-Level: X-Spam-Status: No, score=-2.188 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUyEA2hOGlaG for ; Tue, 13 Aug 2013 05:12:20 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 2259611E8179 for ; Tue, 13 Aug 2013 05:12:20 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 1D29118CC3C; Tue, 13 Aug 2013 14:12:19 +0200 (CEST) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 03B4835C048; Tue, 13 Aug 2013 14:12:19 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Tue, 13 Aug 2013 14:12:18 +0200 From: To: Ole Troan Date: Tue, 13 Aug 2013 14:12:17 +0200 Thread-Topic: [Softwires] I-D Action: draft-ietf-softwire-map-08.txt Thread-Index: Ac6YFnfT9C1wndvZR72FKgLkcDv8swABxy3A Message-ID: <94C682931C08B048B7A8645303FDC9F36EEC7E9983@PUEXCB1B.nanterre.francetelecom.fr> References: <20130812121654.30206.92319.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EEC7E980D@PUEXCB1B.nanterre.francetelecom.fr> <86841AD5-1864-4177-BEE1-4181DDE085EF@employees.org> <94C682931C08B048B7A8645303FDC9F36EEC7E9915@PUEXCB1B.nanterre.francetelecom.fr> <8FF0368A-D069-4BDA-9919-58FE22B81026@employees.org> <9B5FC5D7-45F6-4768-9B96-66114662FA09@gmail.com> <77DB9DB1-90D8-447F-A4D2-D130FB277115@employees.org> In-Reply-To: <77DB9DB1-90D8-447F-A4D2-D130FB277115@employees.org> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.8.13.113330 Cc: "softwires@ietf.org" Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-map-08.txt X-BeenThere: softwires@ietf.org 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: Tue, 13 Aug 2013 12:12:39 -0000 Re-, Yes, there is a WGLC but this does not mean that the document as it is solv= es all raised issues. Senthil did already raised this point to the authors = of MAP and MAP-T drafts in June 19, but unless I'm mistaken I didn't saw a = follow up to his request.=20 I hope we can close this point ASAP so that the MAP document can move forwa= rd. Thanks. Cheers, Med >-----Message d'origine----- >De=A0: Ole Troan [mailto:otroan@employees.org] >Envoy=E9=A0: mardi 13 ao=FBt 2013 13:16 >=C0=A0: Qi Sun >Cc=A0: BOUCADAIR Mohamed OLNC/OLN; softwires@ietf.org >Objet=A0: Re: [Softwires] I-D Action: draft-ietf-softwire-map-08.txt > >Qi, > >> IMHO, the Unified CPE defines some functionalities and behaviors of CE >side, e.g. tunnel endpoint, NAT44, how to use these functions on CPE etc., >which MAP depends on. >> >> As for the provisioning method, map-dhcp is one of the methods could be >used in MAP. The discussion is taking place in the Unified CPE for >provisioning. So I think it should be an informative reference in MAP base >draft. > >so you are saying that draft-ietf-softwire-map cannot stand on its own, bu= t >depend on text in unified CPE? >if so, what is missing? which parts of the unified CPE draft should be >referenced? please propose text changes to the document. > >I am open to the possibility that I'm wrong of course, but I can't know >that for sure, before I see what text changes you propose. >I'm not trying to be difficult (at least not more than usual), but the >document has passed WGLC, and we're restrictive about accepting changes. > >cheers, >Ole From otroan@employees.org Tue Aug 13 05:18:41 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6970F21E8107 for ; Tue, 13 Aug 2013 05:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImhYWVYnF19v for ; Tue, 13 Aug 2013 05:18:35 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id 9942E21F9EC9 for ; Tue, 13 Aug 2013 05:18:34 -0700 (PDT) Received: from dhcp-lys01-vla250-10-147-112-207.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 192F45E5C; Tue, 13 Aug 2013 05:18:32 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ole Troan In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EEC7E9976@PUEXCB1B.nanterre.francetelecom.fr> Date: Tue, 13 Aug 2013 14:18:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7A1D5E0A-55FE-4CF6-9444-A1BE212BB451@employees.org> References: <20130812121654.30206.92319.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EEC7E980D@PUEXCB1B.nanterre.francetelecom.fr> <86841AD5-1864-4177-BEE1-4181DDE085EF@employees.org> <94C682931C08B048B7A8645303FDC9F36EEC7E9915@PUEXCB1B.nanterre.francetelecom.fr> <8FF0368A-D069-4BDA-9919-58FE22B81026@employees.org> <94C682931C08B048B7A8645303FDC9F36EEC7E9976@PUEXCB1B.nanterre.francetelecom.fr> To: X-Mailer: Apple Mail (2.1508) Cc: "softwires@ietf.org" Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-map-08.txt X-BeenThere: softwires@ietf.org 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: Tue, 13 Aug 2013 12:18:41 -0000 Med, > It seems we agree on the provisioning part of the discussion. The MAP = document should be sufficient in its own and should not make any = assumption on how configuration parameters are provisioned. This can be = done manually or dynamically (e.g., dhcp). So, any reference to a = provisioning means should be informative, and even better be removed in = favor of a single pointer to the unified CPE, where all this is = discussed.=20 >=20 > Then, to the question why I'm asking for this I-D to be referenced as = normative and not informative, the answer is that the generic = bootstrapping logic described in the unified CPE must be followed by all = softwire solution flavors. That's the minimum bar I see if we really = want all a consistency to be ensured. Ideally, the CE part of all = solutions should be documented in the unified CPE while the BR/lwAFTR = parts in MAP and lw4o6 document, but I won't ask for that. I see the relationship between the documents in the opposite way. there are 2-5 independent mechanisms. the unified CPE document describes = how these can be provisioned and ensures there is some consistency = between how a CPE can support all the mechanisms. the unified CPE = document was never intended to drive changes in the protocol = specifications of the mechanisms themselves. I'm not necessarily against removing the normative reference to the MAP = DHCP draft. I am against a reference to the unified DHCP document. = reason being as I stated above, there should not be a dependency from = MAP to DHCP. there is also the issue of not blocking MAP document = progress waiting for the progress of the unified CPE document. cheers, Ole= From mohamed.boucadair@orange.com Tue Aug 13 05:39:35 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA9D021F99A1 for ; Tue, 13 Aug 2013 05:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LI2IpYc0LQpf for ; Tue, 13 Aug 2013 05:39:31 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 7B84421F862B for ; Tue, 13 Aug 2013 05:39:31 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 6A4F63B56AE; Tue, 13 Aug 2013 14:39:28 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 49A294C015; Tue, 13 Aug 2013 14:39:28 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Tue, 13 Aug 2013 14:39:28 +0200 From: To: Ole Troan Date: Tue, 13 Aug 2013 14:39:27 +0200 Thread-Topic: [Softwires] I-D Action: draft-ietf-softwire-map-08.txt Thread-Index: Ac6YHz3Q3V5CsCwUQgCcKKvgOC6J6QAAWAew Message-ID: <94C682931C08B048B7A8645303FDC9F36EEC7E9992@PUEXCB1B.nanterre.francetelecom.fr> References: <20130812121654.30206.92319.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EEC7E980D@PUEXCB1B.nanterre.francetelecom.fr> <86841AD5-1864-4177-BEE1-4181DDE085EF@employees.org> <94C682931C08B048B7A8645303FDC9F36EEC7E9915@PUEXCB1B.nanterre.francetelecom.fr> <8FF0368A-D069-4BDA-9919-58FE22B81026@employees.org> <94C682931C08B048B7A8645303FDC9F36EEC7E9976@PUEXCB1B.nanterre.francetelecom.fr> <7A1D5E0A-55FE-4CF6-9444-A1BE212BB451@employees.org> In-Reply-To: <7A1D5E0A-55FE-4CF6-9444-A1BE212BB451@employees.org> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.6.28.101520 Cc: "softwires@ietf.org" Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-map-08.txt X-BeenThere: softwires@ietf.org 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: Tue, 13 Aug 2013 12:39:35 -0000 Re-, We both agree there is no justification to maintain the dhcp draft in the n= ormative section. I consider that point closed and will wait to see this fi= xed in the document. Given that this document does not rely on how provisio= ning is achieved and given the unified CPE is where this is supposed to be = discussed, I do still think any reference to provisioning should refer to t= he unified CPE.=20 It really does not make sense to not require the CE to follow the unified C= PE behavior (in particular http://tools.ietf.org/html/draft-ietf-softwire-u= nified-cpe-01#section-3.2) if we want a minimum of coherency among the solu= tions discussed so far.=20 I don't think that referring to the unified CPE draft will block the public= ation of the MAP document. This is not a technical reason BTW. If we maintain the same positive energy as we have started to do in the Atl= anta meeting, I do think that we will be able to deliver all these document= s as a package.=20 I hope this issue can be resolved ASAP. Cheers, Med >-----Message d'origine----- >De=A0: Ole Troan [mailto:otroan@employees.org] >Envoy=E9=A0: mardi 13 ao=FBt 2013 14:19 >=C0=A0: BOUCADAIR Mohamed OLNC/OLN >Cc=A0: softwires@ietf.org >Objet=A0: Re: [Softwires] I-D Action: draft-ietf-softwire-map-08.txt > >Med, > >> It seems we agree on the provisioning part of the discussion. The MAP >document should be sufficient in its own and should not make any assumptio= n >on how configuration parameters are provisioned. This can be done manually >or dynamically (e.g., dhcp). So, any reference to a provisioning means >should be informative, and even better be removed in favor of a single >pointer to the unified CPE, where all this is discussed. >> >> Then, to the question why I'm asking for this I-D to be referenced as >normative and not informative, the answer is that the generic bootstrappin= g >logic described in the unified CPE must be followed by all softwire >solution flavors. That's the minimum bar I see if we really want all a >consistency to be ensured. Ideally, the CE part of all solutions should be >documented in the unified CPE while the BR/lwAFTR parts in MAP and lw4o6 >document, but I won't ask for that. > >I see the relationship between the documents in the opposite way. >there are 2-5 independent mechanisms. the unified CPE document describes >how these can be provisioned and ensures there is some consistency between >how a CPE can support all the mechanisms. the unified CPE document was >never intended to drive changes in the protocol specifications of the >mechanisms themselves. > >I'm not necessarily against removing the normative reference to the MAP >DHCP draft. I am against a reference to the unified DHCP document. reason >being as I stated above, there should not be a dependency from MAP to DHCP= . >there is also the issue of not blocking MAP document progress waiting for >the progress of the unified CPE document. > >cheers, >Ole From otroan@employees.org Tue Aug 13 06:00:24 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80A3E21F9E6A for ; Tue, 13 Aug 2013 06:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U38HhoVVA7sQ for ; Tue, 13 Aug 2013 06:00:19 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id D5B4C21F9BAB for ; Tue, 13 Aug 2013 06:00:06 -0700 (PDT) Received: from dhcp-lys01-vla250-10-147-112-207.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id F0A6B5FBE; Tue, 13 Aug 2013 06:00:05 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ole Troan In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EEC7E9992@PUEXCB1B.nanterre.francetelecom.fr> Date: Tue, 13 Aug 2013 15:00:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <647A4750-13B0-48FC-8F1B-6851248DB941@employees.org> References: <20130812121654.30206.92319.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EEC7E980D@PUEXCB1B.nanterre.francetelecom.fr> <86841AD5-1864-4177-BEE1-4181DDE085EF@employees.org> <94C682931C08B048B7A8645303FDC9F36EEC7E9915@PUEXCB1B.nanterre.francetelecom.fr> <8FF0368A-D069-4BDA-9919-58FE22B81026@employees.org> <94C682931C08B048B7A8645303FDC9F36EEC7E9976@PUEXCB1B.nanterre.francetelecom.fr> <7A1D5E0A-55FE-4CF6-9444-A1BE212BB451@employees.org> <94C682931C08B048B7A8645303FDC9F36EEC7E9992@PUEXCB1B.nanterre.francetelecom.fr> To: X-Mailer: Apple Mail (2.1508) Cc: "softwires@ietf.org" Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-map-08.txt X-BeenThere: softwires@ietf.org 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: Tue, 13 Aug 2013 13:00:24 -0000 Med, > We both agree there is no justification to maintain the dhcp draft in = the normative section. I consider that point closed and will wait to see = this fixed in the document. Given that this document does not rely on = how provisioning is achieved and given the unified CPE is where this is = supposed to be discussed, I do still think any reference to provisioning = should refer to the unified CPE.=20 "not necessarily against...", is quite far from agree. ;-) MAP doesn't discuss the details of provisioning, but it does have a = SHOULD to implement the MAP DHCP option. the reason for this is so that = all MAP implementations at least support one provisioning mechanism in = common. does the unified CPE propose something conflicting with the current text = in MAP? (the temptation is of course to remove the normative reference, given = that progress on a 'unified' DHCP option is slow). > It really does not make sense to not require the CE to follow the = unified CPE behavior (in particular = http://tools.ietf.org/html/draft-ietf-softwire-unified-cpe-01#section-3.2)= if we want a minimum of coherency among the solutions discussed so far.=20= that's for the unified CPE document to say. > I don't think that referring to the unified CPE draft will block the = publication of the MAP document. This is not a technical reason BTW. no, it is not a technical reason. it is a design goal to keep MAP = independent of the other mechanisms, i.e. it must be possible to = implement routers that only support MAP and no other of the mechanisms. > If we maintain the same positive energy as we have started to do in = the Atlanta meeting, I do think that we will be able to deliver all = these documents as a package.=20 positive energy is good! might be a little misplaced here though. ;-) to me it looks like we've moved the contentious parts that led to all of = DS-lite, MAP-E, MAP-T, 4rd, LW46, Public 4over6 and no consensus to the = DHCP/unified CPE documents. cheers, Ole= From mohamed.boucadair@orange.com Tue Aug 13 06:46:21 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60BAB11E816E for ; Tue, 13 Aug 2013 06:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.21 X-Spam-Level: X-Spam-Status: No, score=-2.21 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Ep-J1lW0doN for ; Tue, 13 Aug 2013 06:46:17 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id AE23B21E8133 for ; Tue, 13 Aug 2013 06:46:16 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id CB9683B5742; Tue, 13 Aug 2013 15:46:13 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id B209427C046; Tue, 13 Aug 2013 15:46:13 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Tue, 13 Aug 2013 15:46:14 +0200 From: To: Ole Troan Date: Tue, 13 Aug 2013 15:46:11 +0200 Thread-Topic: [Softwires] I-D Action: draft-ietf-softwire-map-08.txt Thread-Index: Ac6YJQ0cbjWJ+bOeRw+p2ovLOScF4QABhlRw Message-ID: <94C682931C08B048B7A8645303FDC9F36EEC7E99B8@PUEXCB1B.nanterre.francetelecom.fr> References: <20130812121654.30206.92319.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EEC7E980D@PUEXCB1B.nanterre.francetelecom.fr> <86841AD5-1864-4177-BEE1-4181DDE085EF@employees.org> <94C682931C08B048B7A8645303FDC9F36EEC7E9915@PUEXCB1B.nanterre.francetelecom.fr> <8FF0368A-D069-4BDA-9919-58FE22B81026@employees.org> <94C682931C08B048B7A8645303FDC9F36EEC7E9976@PUEXCB1B.nanterre.francetelecom.fr> <7A1D5E0A-55FE-4CF6-9444-A1BE212BB451@employees.org> <94C682931C08B048B7A8645303FDC9F36EEC7E9992@PUEXCB1B.nanterre.francetelecom.fr> <647A4750-13B0-48FC-8F1B-6851248DB941@employees.org> In-Reply-To: <647A4750-13B0-48FC-8F1B-6851248DB941@employees.org> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.8.13.121523 Cc: "softwires@ietf.org" Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-map-08.txt X-BeenThere: softwires@ietf.org 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: Tue, 13 Aug 2013 13:46:21 -0000 Re-, It seems we are in disagreement here. Looking to have more feedback for the= list. Thanks for engaging. Cheers, Med >-----Message d'origine----- >De=A0: Ole Troan [mailto:otroan@employees.org] >Envoy=E9=A0: mardi 13 ao=FBt 2013 15:00 >=C0=A0: BOUCADAIR Mohamed OLNC/OLN >Cc=A0: softwires@ietf.org >Objet=A0: Re: [Softwires] I-D Action: draft-ietf-softwire-map-08.txt > >Med, > >> We both agree there is no justification to maintain the dhcp draft in th= e >normative section. I consider that point closed and will wait to see this >fixed in the document. Given that this document does not rely on how >provisioning is achieved and given the unified CPE is where this is >supposed to be discussed, I do still think any reference to provisioning >should refer to the unified CPE. > >"not necessarily against...", is quite far from agree. ;-) >MAP doesn't discuss the details of provisioning, but it does have a SHOULD >to implement the MAP DHCP option. the reason for this is so that all MAP >implementations at least support one provisioning mechanism in common. > >does the unified CPE propose something conflicting with the current text i= n >MAP? >(the temptation is of course to remove the normative reference, given that >progress on a 'unified' DHCP option is slow). > >> It really does not make sense to not require the CE to follow the unifie= d >CPE behavior (in particular http://tools.ietf.org/html/draft-ietf-softwire= - >unified-cpe-01#section-3.2) if we want a minimum of coherency among the >solutions discussed so far. > >that's for the unified CPE document to say. > >> I don't think that referring to the unified CPE draft will block the >publication of the MAP document. This is not a technical reason BTW. > >no, it is not a technical reason. it is a design goal to keep MAP >independent of the other mechanisms, i.e. it must be possible to implement >routers that only support MAP and no other of the mechanisms. > >> If we maintain the same positive energy as we have started to do in the >Atlanta meeting, I do think that we will be able to deliver all these >documents as a package. > >positive energy is good! might be a little misplaced here though. ;-) >to me it looks like we've moved the contentious parts that led to all of >DS-lite, MAP-E, MAP-T, 4rd, LW46, Public 4over6 and no consensus to the >DHCP/unified CPE documents. > >cheers, >Ole From satoru.matsushima@gmail.com Tue Aug 13 07:17:54 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9D4221E813B for ; Tue, 13 Aug 2013 07:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QS3fIjokHZIm for ; Tue, 13 Aug 2013 07:17:54 -0700 (PDT) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id F016121F9DC9 for ; Tue, 13 Aug 2013 07:17:53 -0700 (PDT) Received: by mail-pd0-f179.google.com with SMTP id v10so4960485pde.24 for ; Tue, 13 Aug 2013 07:17:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7M9mMSKrqQCvqE6hpwFjMa3oiQSIxYNTl7NJdNRIABA=; b=YBBA03vSwXFmq25zqxxCAUHLT/1UN8wZD/PFc0nsNF9U0MiQo/QprNuXVO4ueGEh/U pBDqGE/uVzyqd7AVWagnwo2nMCXn+Vyz7sV1Dw3ZaPNqD6YbZqOkbkgqqXXLAQO+nF6X 6q3wRwlpsYFn/MgSpRIwedvWNphnXkXv0AHoqtrz5/drw8sLVeQt8FbEAfHZdF/NtNde QEQ7qBP00xUijcW7lE2zdWfAnE8mNNW5s2kBcCHYTKEoY6toSUNQMgeamNdhP3u6fqYd QpdI7CnEDKqQxPL6EpVi/w+GRtyy61HItJat4bD4MYsi/CPN84PMlnyOHb7UeEK3m2LI I9QA== X-Received: by 10.68.255.69 with SMTP id ao5mr4827210pbd.66.1376403473530; Tue, 13 Aug 2013 07:17:53 -0700 (PDT) Received: from [192.168.3.3] (softbank126044192158.bbtec.net. [126.44.192.158]) by mx.google.com with ESMTPSA id iu7sm44231975pbc.8.2013.08.13.07.17.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 13 Aug 2013 07:17:50 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Satoru Matsushima In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EEC7E99B8@PUEXCB1B.nanterre.francetelecom.fr> Date: Tue, 13 Aug 2013 23:17:42 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <10F93518-EDAD-40D0-8575-DE7E351B821C@gmail.com> References: <20130812121654.30206.92319.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EEC7E980D@PUEXCB1B.nanterre.francetelecom.fr> <86841AD5-1864-4177-BEE1-4181DDE085EF@employees.org> <94C682931C08B048B7A8645303FDC9F36EEC7E9915@PUEXCB1B.nanterre.francetelecom.fr> <8FF0368A-D069-4BDA-9919-58FE22B81026@employees.org> <94C682931C08B048B7A8645303FDC9F36EEC7E9976@PUEXCB1B.nanterre.francetelecom.fr> <7A1D5E0A-55FE-4CF6-9444-A1BE212BB451@employees.org> <94C682931C08B048B7A8645303FDC9F36EEC7E9992@PUEXCB1B.nanterre.francetelecom.fr> <647A4750-13B0-48FC-8F1B-6851248DB941@employees.org> <94C682931C08B048B7A8645303FDC9F36EEC7E99B8@PUEXCB1B.nanterre.francetelecom.fr> To: X-Mailer: Apple Mail (2.1508) Cc: "softwires@ietf.org" Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-map-08.txt X-BeenThere: softwires@ietf.org 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: Tue, 13 Aug 2013 14:17:54 -0000 Med, I didn't think that unified CPE draft is to govern specific solution. = But I find out that MAP must refer unified CPE draft as a normative ref = in the case of MAP IS the unified solution, make sense? cheers, --satoru On 2013/08/13, at 22:46, wrote: > Re-, >=20 > It seems we are in disagreement here. Looking to have more feedback = for the list. >=20 > Thanks for engaging. >=20 > Cheers, > Med >=20 >> -----Message d'origine----- >> De : Ole Troan [mailto:otroan@employees.org] >> Envoy=E9 : mardi 13 ao=FBt 2013 15:00 >> =C0 : BOUCADAIR Mohamed OLNC/OLN >> Cc : softwires@ietf.org >> Objet : Re: [Softwires] I-D Action: draft-ietf-softwire-map-08.txt >>=20 >> Med, >>=20 >>> We both agree there is no justification to maintain the dhcp draft = in the >> normative section. I consider that point closed and will wait to see = this >> fixed in the document. Given that this document does not rely on how >> provisioning is achieved and given the unified CPE is where this is >> supposed to be discussed, I do still think any reference to = provisioning >> should refer to the unified CPE. >>=20 >> "not necessarily against...", is quite far from agree. ;-) >> MAP doesn't discuss the details of provisioning, but it does have a = SHOULD >> to implement the MAP DHCP option. the reason for this is so that all = MAP >> implementations at least support one provisioning mechanism in = common. >>=20 >> does the unified CPE propose something conflicting with the current = text in >> MAP? >> (the temptation is of course to remove the normative reference, given = that >> progress on a 'unified' DHCP option is slow). >>=20 >>> It really does not make sense to not require the CE to follow the = unified >> CPE behavior (in particular = http://tools.ietf.org/html/draft-ietf-softwire- >> unified-cpe-01#section-3.2) if we want a minimum of coherency among = the >> solutions discussed so far. >>=20 >> that's for the unified CPE document to say. >>=20 >>> I don't think that referring to the unified CPE draft will block the >> publication of the MAP document. This is not a technical reason BTW. >>=20 >> no, it is not a technical reason. it is a design goal to keep MAP >> independent of the other mechanisms, i.e. it must be possible to = implement >> routers that only support MAP and no other of the mechanisms. >>=20 >>> If we maintain the same positive energy as we have started to do in = the >> Atlanta meeting, I do think that we will be able to deliver all these >> documents as a package. >>=20 >> positive energy is good! might be a little misplaced here though. ;-) >> to me it looks like we've moved the contentious parts that led to all = of >> DS-lite, MAP-E, MAP-T, 4rd, LW46, Public 4over6 and no consensus to = the >> DHCP/unified CPE documents. >>=20 >> cheers, >> Ole > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From fibrib@gmail.com Tue Aug 13 19:31:38 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D08321E808F for ; Tue, 13 Aug 2013 19:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmQtjEmRnitO for ; Tue, 13 Aug 2013 19:31:37 -0700 (PDT) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 8546121E81B0 for ; Tue, 13 Aug 2013 19:31:37 -0700 (PDT) Received: by mail-ob0-f170.google.com with SMTP id eh20so11458724obb.29 for ; Tue, 13 Aug 2013 19:31:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+w2wHo60UFftsAMt4rW+s5gwaZGqyUQAfASNz9n3M+g=; b=Wl/KGgawqfOIosU73GKox2kvXwwnFjNZgtXUWeUFV21XZ1A9MhwehP+N+Z4dQTDDQ8 s2eo6/gZMW+UxkP/hMtzRY5tmY9LBGheKRMDqXT8MUhRKmZ+3UGWAtVVFSpp2LaBUAEq I5MaqRNnWoxR1lsFoEiu8wK62TdSZXcF/iGZxQs/6r72zngwtPNDtWc0cqxqkOE4R1Hb KKhZHgwwAA0iMiPqmYToBQ/UdEhGF58dabmzn5wmjmnB+iRPCb9KEX7xI+LYWYzDVyjf HQG+K+Ich6SjDeFd81Mtvl1QDTc8kh2SjthlER/aUC8SKqIz5e+mqWXc/ifg4WSpImMN opow== MIME-Version: 1.0 X-Received: by 10.60.36.133 with SMTP id q5mr7250516oej.31.1376447497008; Tue, 13 Aug 2013 19:31:37 -0700 (PDT) Received: by 10.76.24.34 with HTTP; Tue, 13 Aug 2013 19:31:36 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EEC7E99B8@PUEXCB1B.nanterre.francetelecom.fr> References: <20130812121654.30206.92319.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EEC7E980D@PUEXCB1B.nanterre.francetelecom.fr> <86841AD5-1864-4177-BEE1-4181DDE085EF@employees.org> <94C682931C08B048B7A8645303FDC9F36EEC7E9915@PUEXCB1B.nanterre.francetelecom.fr> <8FF0368A-D069-4BDA-9919-58FE22B81026@employees.org> <94C682931C08B048B7A8645303FDC9F36EEC7E9976@PUEXCB1B.nanterre.francetelecom.fr> <7A1D5E0A-55FE-4CF6-9444-A1BE212BB451@employees.org> <94C682931C08B048B7A8645303FDC9F36EEC7E9992@PUEXCB1B.nanterre.francetelecom.fr> <647A4750-13B0-48FC-8F1B-6851248DB941@employees.org> <94C682931C08B048B7A8645303FDC9F36EEC7E99B8@PUEXCB1B.nanterre.francetelecom.fr> Date: Wed, 14 Aug 2013 11:31:36 +0900 Message-ID: From: Maoke To: "mohamed.boucadair@orange.com" Content-Type: multipart/alternative; boundary=089e01293f101c7c0604e3df280d Cc: "softwires@ietf.org" Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-map-08.txt X-BeenThere: softwires@ietf.org 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, 14 Aug 2013 02:31:38 -0000 --089e01293f101c7c0604e3df280d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable my technical understanding on this issue: 1. (the reason of using unified CPE) unified CPE is a sort of CPE that is used by an ISP that wants to A. simultaneously deploy MAP and lw4o6 and 4rd (and/or something else, out-of-scope or not?) there and here respectively but doesn't want to distinguish the device distribution among those subscribers; B. potentially deploy MAP or lw4o6 according to backbone strategy but currently hasn't be sure there will be no change in the future and therefore doesn't like to leave limitations at the subscribers' side. C. deploy either MAP or lw4o6 but doesn't care what to distribute to the subscribers as long as compatibility is ensured. 2. (the reason of not using unified CPE) for some ISPs, they may not use unified CPE because A. they are clearly know they only need either MAP or lw4o6 and does want to use the MAP- or lw4o6-specific devices with MAP- or lw4o6-oriented optimization, with the low cost corresponding to supporting only one protocol; B. they are concerning the future extensions of MAP, e.g. the inter-domain operation (making a cross-ISP MAP domain), where the MAP-specific implementation is needed while current unified CPE is unsure of supporting that. for the 2B, i don't argue it is a problem that currently the unified CPE doesn't cover any topic of cross-ISP provisioning at all. i do accept it is an issue out of the scope of the unified CPE --- including this topic, too early to discuss for most people, into unified CPE draft may delay its progress much more. but i worry, if citing unified CPE, the MAP as an architecture specification might become restricted so that inter-domain (and potentially other) extensions may not be available. we have logically checked current MAP does work in an inter-domain environment (of course, currently only through manual configuration) and we don't like this feature is hurt by any extra, not much necessary references. unified CPE is about an implementation while MAP draft is architecture specification. generally speaking, an architecture specification should stand on itself rather than depending upon any specific implementation. if the citation is DEFINITELY needed for any non-technical reason, the above explanation on the understanding must also be included in order to avoid any misleading or restrictions on extensive usage. cheers, - maoke 2013/8/13 > Re-, > > It seems we are in disagreement here. Looking to have more feedback for > the list. > > Thanks for engaging. > > Cheers, > Med > > >-----Message d'origine----- > >De : Ole Troan [mailto:otroan@employees.org] > >Envoy=E9 : mardi 13 ao=FBt 2013 15:00 > >=C0 : BOUCADAIR Mohamed OLNC/OLN > >Cc : softwires@ietf.org > >Objet : Re: [Softwires] I-D Action: draft-ietf-softwire-map-08.txt > > > >Med, > > > >> We both agree there is no justification to maintain the dhcp draft in > the > >normative section. I consider that point closed and will wait to see thi= s > >fixed in the document. Given that this document does not rely on how > >provisioning is achieved and given the unified CPE is where this is > >supposed to be discussed, I do still think any reference to provisioning > >should refer to the unified CPE. > > > >"not necessarily against...", is quite far from agree. ;-) > >MAP doesn't discuss the details of provisioning, but it does have a SHOU= LD > >to implement the MAP DHCP option. the reason for this is so that all MAP > >implementations at least support one provisioning mechanism in common. > > > >does the unified CPE propose something conflicting with the current text > in > >MAP? > >(the temptation is of course to remove the normative reference, given th= at > >progress on a 'unified' DHCP option is slow). > > > >> It really does not make sense to not require the CE to follow the > unified > >CPE behavior (in particular > http://tools.ietf.org/html/draft-ietf-softwire- > >unified-cpe-01#section-3.2) if we want a minimum of coherency among the > >solutions discussed so far. > > > >that's for the unified CPE document to say. > > > >> I don't think that referring to the unified CPE draft will block the > >publication of the MAP document. This is not a technical reason BTW. > > > >no, it is not a technical reason. it is a design goal to keep MAP > >independent of the other mechanisms, i.e. it must be possible to impleme= nt > >routers that only support MAP and no other of the mechanisms. > > > >> If we maintain the same positive energy as we have started to do in th= e > >Atlanta meeting, I do think that we will be able to deliver all these > >documents as a package. > > > >positive energy is good! might be a little misplaced here though. ;-) > >to me it looks like we've moved the contentious parts that led to all of > >DS-lite, MAP-E, MAP-T, 4rd, LW46, Public 4over6 and no consensus to the > >DHCP/unified CPE documents. > > > >cheers, > >Ole > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --089e01293f101c7c0604e3df280d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
my technical understanding on this issue:

1. (the reason of using unified CPE) unified CPE is a so= rt of CPE that is used by an ISP that wants to
=A0=A0=A0 A. = simultaneously deploy MAP and lw4o6 and 4rd (and/or something else, out-of-= scope or not?) there and here respectively but doesn't want to distingu= ish the device distribution among those subscribers;
=A0=A0=A0 B. potentially deploy MAP or lw4o6 according to backbo= ne strategy but currently hasn't be sure there will be no change in the= future and therefore doesn't like to leave limitations at the subscrib= ers' side.
=A0=A0=A0 C. deploy either MAP or lw4o6 but doesn't care wha= t to distribute to the subscribers as long as compatibility is ensured.

2. (the reason of not using unified CPE) for som= e ISPs, they may not use unified CPE because
=A0=A0=A0 A. they are clearly know they only need either MAP or = lw4o6 and does want to use the MAP- or lw4o6-specific devices with MAP- or = lw4o6-oriented optimization, with the low cost corresponding to supporting = only one protocol;
=A0=A0=A0 B. they are concerning the future extensions of MAP, e= .g. the inter-domain operation (making a cross-ISP MAP domain), where the M= AP-specific implementation is needed while current unified CPE is unsure of= supporting that.

for the 2B, i don't argue it is a problem that currently= the unified CPE doesn't cover any topic of cross-ISP provisioning at a= ll. i do accept it is an issue out of the scope of the unified CPE --- incl= uding this topic, too early to discuss for most people, into unified CPE dr= aft may delay its progress much more.

but i worry, if citing unified CPE, the MAP as an architecture specific= ation might become restricted so that inter-domain (and potentially other) = extensions may not be available. we have logically checked current MAP does= work in an inter-domain environment (of course, currently only through man= ual configuration) and we don't like this feature is hurt by any extra,= not much necessary references. unified CPE is about an implementation whil= e MAP draft is architecture specification. generally speaking, an architect= ure specification should stand on itself rather than depending upon any spe= cific implementation.

if the citation is DEFINITELY needed for any non-technical reason, the = above explanation on the understanding=A0 must also be included in order to= avoid any misleading or restrictions on extensive usage.

cheers,
- maoke



2013/8/13 <mo= hamed.boucadair@orange.com>
Re-,

It seems we are in disagreement here. Looking to have more feedback for the= list.

Thanks for engaging.

Cheers,
Med

>-----Message d'origine-----
>De=A0: Ole Troan [mailto:otroan= @employees.org]
>Envoy=E9=A0: mardi 13 ao=FBt 2013 15:00
>=C0=A0: BOUCADAIR Mohamed OLNC/OLN
>Cc=A0: softwires@ietf.org
>Objet=A0: Re: [Softwires] I-D Action: draft-ietf-softwire-map-08.txt >
>Med,
>
>> We both agree there is no justification to maintain the dhcp draft= in the
>normative section. I consider that point closed and will wait to see th= is
>fixed in the document. Given that this document does not rely on how >provisioning is achieved and given the unified CPE is where this is
>supposed to be discussed, I do still think any reference to provisionin= g
>should refer to the unified CPE.
>
>"not necessarily against...", is quite far from agree. ;-) >MAP doesn't discuss the details of provisioning, but it does have a= SHOULD
>to implement the MAP DHCP option. the reason for this is so that all MA= P
>implementations at least support one provisioning mechanism in common.<= br> >
>does the unified CPE propose something conflicting with the current tex= t in
>MAP?
>(the temptation is of course to remove the normative reference, given t= hat
>progress on a 'unified' DHCP option is slow).
>
>> It really does not make sense to not require the CE to follow the = unified
>CPE behavior (in particular http://tools.ietf.org/html/draft-ietf-so= ftwire-
>unified-cpe-01#section-3.2) if we want a minimum of coherency among the=
>solutions discussed so far.
>
>that's for the unified CPE document to say.
>
>> I don't think that referring to the unified CPE draft will blo= ck the
>publication of the MAP document. This is not a technical reason BTW. >
>no, it is not a technical reason. it is a design goal to keep MAP
>independent of the other mechanisms, i.e. it must be possible to implem= ent
>routers that only support MAP and no other of the mechanisms.
>
>> If we maintain the same positive energy as we have started to do i= n the
>Atlanta meeting, I do think that we will be able to deliver all these >documents as a package.
>
>positive energy is good! might be a little misplaced here though. ;-) >to me it looks like we've moved the contentious parts that led to a= ll of
>DS-lite, MAP-E, MAP-T, 4rd, LW46, Public 4over6 and no consensus to the=
>DHCP/unified CPE documents.
>
>cheers,
>Ole
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

--089e01293f101c7c0604e3df280d-- From ian.farrer@telekom.de Wed Aug 14 08:21:07 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2FB21F9655 for ; Wed, 14 Aug 2013 08:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pjpckLxayD4 for ; Wed, 14 Aug 2013 08:21:03 -0700 (PDT) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) by ietfa.amsl.com (Postfix) with ESMTP id C8F1221F9654 for ; Wed, 14 Aug 2013 08:21:02 -0700 (PDT) Received: from he110890.emea1.cds.t-internal.com ([10.134.92.131]) by tcmail91.telekom.de with ESMTP/TLS/AES128-SHA; 14 Aug 2013 17:21:00 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by he110890 ([10.134.92.131]) with mapi; Wed, 14 Aug 2013 17:21:00 +0200 From: To: , Date: Wed, 14 Aug 2013 17:20:57 +0200 Thread-Topic: [Softwires] I-D Action: draft-ietf-softwire-map-08.txt Thread-Index: Ac6ZAeG5aNrV1wZyS1iChcOOS8c+cQ== Message-ID: In-Reply-To: <7A1D5E0A-55FE-4CF6-9444-A1BE212BB451@employees.org> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: softwires@ietf.org Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-map-08.txt X-BeenThere: softwires@ietf.org 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, 14 Aug 2013 15:21:07 -0000 Hi Ole, I'm a little late to the conversation, but picking up on http://www.ietf.org/mail-archive/web/softwires/current/msg05636.html Cheers, Ian > >I'm not necessarily against removing the normative reference to the MAP >DHCP draft. I am against a reference to the unified DHCP document. reason >being as I stated above, there should not be a dependency from MAP to >DHCP. there is also the issue of not blocking MAP document progress >waiting for the progress of the unified CPE document. [ian] There is no Unified DHCP document. The Unified CPE doc describes generic logic for using parameters, rather than how those parameters are provisioned. Section 3.3 does describe how this is applied using DHCP as an example (based on softwire-map-dhcp), though it states that other methods may be used. It states that DHCP provisioning should be implemented. Is this the (technical) problem between the two? If we align the requirement for implementing DHCP based provisioning between the two drafts, does that fix the first issue above? > >cheers, >Ole >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires From swmike@swm.pp.se Thu Aug 15 00:10:24 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4072E21F99A1 for ; Thu, 15 Aug 2013 00:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rZURazy2lDU for ; Thu, 15 Aug 2013 00:10:23 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 9C1BE21F99AD for ; Thu, 15 Aug 2013 00:10:23 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id CC77FA1; Thu, 15 Aug 2013 09:10:21 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id C3EA99C; Thu, 15 Aug 2013 09:10:21 +0200 (CEST) Date: Thu, 15 Aug 2013 09:10:21 +0200 (CEST) From: Mikael Abrahamsson To: Maoke In-Reply-To: Message-ID: References: <20130812121654.30206.92319.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EEC7E980D@PUEXCB1B.nanterre.francetelecom.fr> <86841AD5-1864-4177-BEE1-4181DDE085EF@employees.org> <94C682931C08B048B7A8645303FDC9F36EEC7E9915@PUEXCB1B.nanterre.francetelecom.fr> <8FF0368A-D069-4BDA-9919-58FE22B81026@employees.org> <94C682931C08B048B7A8645303FDC9F36EEC7E9976@PUEXCB1B.nanterre.francetelecom.fr> <7A1D5E0A-55FE-4CF6-9444-A1BE212BB451@employees.org> <94C682931C08B048B7A8645303FDC9F36EEC7E9992@PUEXCB1B.nanterre.francetelecom.fr> <647A4750-13B0-48FC-8F1B-6851248DB941@employees.org> <94C682931C08B048B7A8645303FDC9F36EEC7E99B8@PUEXCB1B.nanterre.francetelecom.fr> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "softwires@ietf.org" Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-map-08.txt X-BeenThere: softwires@ietf.org 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: Thu, 15 Aug 2013 07:10:24 -0000 On Wed, 14 Aug 2013, Maoke wrote: > my technical understanding on this issue: > > 1. (the reason of using unified CPE) unified CPE is a sort of CPE that is > used by an ISP that wants to > A. simultaneously deploy MAP and lw4o6 and 4rd (and/or something else, > out-of-scope or not?) there and here respectively but doesn't want to > distinguish the device distribution among those subscribers; > B. potentially deploy MAP or lw4o6 according to backbone strategy but > currently hasn't be sure there will be no change in the future and > therefore doesn't like to leave limitations at the subscribers' side. > C. deploy either MAP or lw4o6 but doesn't care what to distribute to > the subscribers as long as compatibility is ensured. D. Customer buys a retail box that should be plug and play in any provider network regardless of what mechanism the provider supports. -- Mikael Abrahamsson email: swmike@swm.pp.se From sarikaya2012@gmail.com Fri Aug 23 12:54:09 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD9E611E810E for ; Fri, 23 Aug 2013 12:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1du4KypDOmv for ; Fri, 23 Aug 2013 12:54:08 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) by ietfa.amsl.com (Postfix) with ESMTP id 59C1111E8106 for ; Fri, 23 Aug 2013 12:54:08 -0700 (PDT) Received: by mail-lb0-f169.google.com with SMTP id u10so808853lbi.14 for ; Fri, 23 Aug 2013 12:54:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=uGbsZpgvZmrICk2s+vlsD+G8dzUlXg5ullhRa1yfphM=; b=fWR4gS7YVFlW2YIgkRUuZ4v0zxK+kfyw+/MXpEn5ZqfKyjqM7L+pqhrfRvL0fbAnW8 RsTxTvHOZz/1wyicMj1J7xdoE3KVj6yPTTJs07jWfu1YaHwUB4/1lO1SArFyAgbr2YE8 WWmGELR30fv8MKzknzNe6mLoHlQc9CGZyQwek6WXF64/D6zPQ4sjEAAH1Mqucmj30aRs 1hlGyXdv25DvWh4BCVxAA+bxUs2CmnEv3fuGnHlbj6yHchYVAk3l7L6DQxmOrrD2Zeit tHPel31GUQvYB7FxRjBNIThXfxBbBt3snFLYAKlQTgGlZOk7QF5SybTPrGtn54HKigrO NsJQ== MIME-Version: 1.0 X-Received: by 10.112.126.37 with SMTP id mv5mr438577lbb.20.1377287647148; Fri, 23 Aug 2013 12:54:07 -0700 (PDT) Received: by 10.114.98.227 with HTTP; Fri, 23 Aug 2013 12:54:07 -0700 (PDT) In-Reply-To: References: <2FEEDE52-3C39-4680-91A0-E8999840920B@huawei.com> Date: Fri, 23 Aug 2013 14:54:07 -0500 Message-ID: From: Behcet Sarikaya To: Yong Cui Content-Type: multipart/alternative; boundary=001a11c373e4f6411b04e4a2c4b3 Cc: Softwires-wg Subject: Re: [Softwires] Adopting 6rd and MAP Multicast Drafts X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 19:54:09 -0000 --001a11c373e4f6411b04e4a2c4b3 Content-Type: text/plain; charset=ISO-8859-1 Dear Yong, Thanks for your mail. I understand your concern. However I don't see any reason why we should stop this CFA. Let people support (or not), the chairs might wish to act on it some time later. Regards, Behcet On Mon, Aug 12, 2013 at 4:14 PM, Yong Cui wrote: > Thank you for your support on this document. > > However, we have already had 13 wg documents. If we would like to make > our WG more focus, we don't think it's the right time to adopt more > documents now. > > Therefore, I would like to ask the WG to focus on the most important > WG documents first. After we submit some of these WG documents and > they can pass the IESG evaluation, we can then resume the CFA on new > documents. > > In the meanwhile, you are also welcome to discuss the detailed > technologies on both WG documents and new ones. > > Yong > > 2013/8/12 Qiong : > > Dear all, > > > > I also support the adoption. > > > > Best wishes > > Qiong > > > > > > On Wed, Jul 31, 2013 at 2:58 AM, Tina TSOU > > > wrote: > >> > >> Dear all, > >> I support the adoption. > >> > >> Thank you, > >> Tina > >> > >> On Jul 30, 2013, at 7:25 AM, "Behcet Sarikaya" > >> wrote: > >> > >> Hi all, > >> > >> Today in Softwire session there was not enough time for us to present > our > >> drafts on 6rd and MAP multicast support: > >> http://tools.ietf.org/id/draft-sarikaya-softwire-6rdmulticast-05.txt > >> and > >> http://tools.ietf.org/id/draft-sarikaya-softwire-map-multicast-00.txt > >> > >> Both drafts are the only drafts presenting the solution and they are > >> mature enough. > >> > >> Suresh recommended Cathy and myself to ask for support from the working > >> group on these two drafts. > >> > >> We hereby ask the WG to support the adoption of these drafts. > >> > >> > >> Thanks, > >> > >> Cathy and Behcet > >> > >> > >> _______________________________________________ > >> Softwires mailing list > >> Softwires@ietf.org > >> https://www.ietf.org/mailman/listinfo/softwires > >> > > > > > > > > -- > > ============================================== > > Qiong Sun > > China Telecom Beijing Research Institude > > > > > > Open source code: > > lightweight 4over6: http://sourceforge.net/projects/laft6/ > > PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/ > > =============================================== > > > --001a11c373e4f6411b04e4a2c4b3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear Yong,


Thanks for= your mail. I understand your concern.

However I don't see= any reason why we should stop this CFA. Let people support (or not), the c= hairs might wish to act on it some time later.

Regards,

Behcet
=

On Mon, Aug 12, 2013 at 4:14 PM, Yong Cu= i <yong@csnet1.cs.tsinghua.edu.cn> wrote:
Thank you for your support on this document.=

However, we have already had 13 wg documents. If we would like to make
our WG more focus, we don't think it's the right time to adopt more=
documents now.

Therefore, I would like to ask the WG to focus on the most important
WG documents first. After we submit some of these WG documents and
they can pass the IESG evaluation, we can then resume the CFA on new
documents.

In the meanwhile, you are also welcome to discuss the detailed
technologies on both WG documents and new ones.

Yong

2013/8/12 Qiong <bingxuere@gmail.= com>:
> Dear all,
>
> I also support the adoption.
>
> Best wishes
> Qiong
>
>
> On Wed, Jul 31, 2013 at 2:58 AM, Tina TSOU <Tina.Tsou.Zouting@huawei.com>
> wrote:
>>
>> Dear all,
>> I support the adoption.
>>
>> Thank you,
>> Tina
>>
>> On Jul 30, 2013, at 7:25 AM, "Behcet Sarikaya" <sarikaya2012@gmail.com>
>> wrote:
>>
>> Hi all,
>>
>> Today in Softwire session there was not enough time for us to pres= ent our
>> drafts on 6rd and MAP multicast support:
>> http://tools.ietf.org/id/draft-sarikaya-so= ftwire-6rdmulticast-05.txt
>> and
>> http://tools.ietf.org/id/draft-sarikaya-s= oftwire-map-multicast-00.txt
>>
>> Both drafts are the only drafts presenting the solution and they a= re
>> mature enough.
>>
>> Suresh recommended Cathy and myself to ask for support from the wo= rking
>> group on these two drafts.
>>
>> We hereby ask the WG to support the adoption of these drafts.
>>
>>
>> Thanks,
>>
>> Cathy and Behcet
>>
>>
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
>>
>
>
>
> --
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Qiong Sun
> China Telecom Beijing Research Institude
>
>
> Open source code:
> lightweight 4over6: http://sourceforge.net/projects/laft6/
> PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/ > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >

--001a11c373e4f6411b04e4a2c4b3-- From internet-drafts@ietf.org Wed Aug 28 02:31:43 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6694911E8272; Wed, 28 Aug 2013 02:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KvD9jVhnApig; Wed, 28 Aug 2013 02:31:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9AA11E821D; Wed, 28 Aug 2013 02:31:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130828093135.18340.66756.idtracker@ietfa.amsl.com> Date: Wed, 28 Aug 2013 02:31:35 -0700 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-dslite-mib-03.txt X-BeenThere: softwires@ietf.org 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, 28 Aug 2013 09:31:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Softwires Working Group of the IETF. Title : DS-Lite Management Information Base (MIB) Author(s) : Yu Fu Sheng Jiang Jiang Dong Yuchi Chen Filename : draft-ietf-softwire-dslite-mib-03.txt Pages : 30 Date : 2013-08-28 Abstract: This memo defines a portion of the Management Information Base (MIB) for using with network management protocols in the Internet community. In particular, it defines managed objects for DS-Lite. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-dslite-mib-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-dslite-mib-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From eleven.fuyu@huawei.com Thu Aug 29 00:23:56 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D4DD11E8101 for ; Thu, 29 Aug 2013 00:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dfthlEWPNR-d for ; Thu, 29 Aug 2013 00:23:49 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 81F7311E80FF for ; Thu, 29 Aug 2013 00:23:29 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AWR82283; Thu, 29 Aug 2013 07:23:26 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 29 Aug 2013 08:22:57 +0100 Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 29 Aug 2013 08:23:11 +0100 Received: from NKGEML505-MBX.china.huawei.com ([169.254.1.85]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.01.0323.007; Thu, 29 Aug 2013 15:23:07 +0800 From: "Fuyu (Eleven)" To: Softwires WG Thread-Topic: [Softwires] I-D Action: draft-ietf-softwire-dslite-mib-03.txt Thread-Index: AQHOo9GBjKambUXuM0K/uVDmOjM9eZmrZ9hA Date: Thu, 29 Aug 2013 07:23:06 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [Softwires] FW: I-D Action: draft-ietf-softwire-dslite-mib-03.txt X-BeenThere: softwires@ietf.org 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: Thu, 29 Aug 2013 07:23:56 -0000 Hi, Softwirers, The authors have submitted a new version of DS-Lite MIB.=20 Some warnings have been fixed in this version as compiling it in the most s= trict Severity level. Please review the latest version and give your comments. Thanks and Best Regards Yu -----Original Message----- From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Beh= alf Of internet-drafts@ietf.org Sent: Wednesday, August 28, 2013 5:32 PM To: i-d-announce@ietf.org Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-dslite-mib-03.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Softwires Working Group of the IETF. Title : DS-Lite Management Information Base (MIB) Author(s) : Yu Fu Sheng Jiang Jiang Dong Yuchi Chen Filename : draft-ietf-softwire-dslite-mib-03.txt Pages : 30 Date : 2013-08-28 Abstract: This memo defines a portion of the Management Information Base (MIB) for using with network management protocols in the Internet community. In particular, it defines managed objects for DS-Lite. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-dslite-mib-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-dslite-mib-03 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires