Subject: Re: [DMM] Call for adoption confirmation: draft-seite-dmm-rg-multihoming-02

From: <[email-masked]>
Date: Tue, 1 Dec 2015 15:32:16 +0100

Dear co-chairs,  all,
I join early adopters of the draft and agree that it should become WG document.

To the co-authors I propose to check whether all what I detected as nits/typos  really are ones:

p.3:

multihomed achitecture =>  multihomed architecture

using GRE as mobile tuneling => using GRE as mobile tunneling

Tunnel-2 (ober DSL) => Tunnel-2 (over DSL)

Fig.1:

Flow0=-4 => Flow-4

P.4:

Care-of-Adresse => Care-of-Address

one MAG/LMA link, i.e. IP-in-IP tunnel, tunnel can be used => one MAG/LMA link, i.e. IP-in-IP tunnel, can be used

This document overcome => This document overcomes

p.5:

delegated mobile network prefix. => delegated mobile network prefix (DMNP).

> BTW IMHO also the acronym for MAG Multipath-Binding (MMB) should be introduced anywhere around Fig. 2.

p.6:

ans thus => and thus

may require the RG and the to

   exchange interface metrics

=> may require the RG and the LMA/mobility anchor to

   exchange interface metrics

p.7:

on a flow basis => on a per-flow basis

care-addresses => care-of addresses

p.8:

Here the parameters to be explained/defined are missing – e.g.

If-ATT

    This 8-bit field identifies the Access-Technology type …

If-Label

    This 8-bit field represents the interface label …

Etc.

p.9:

from the Mobile Node Identifier Option

      Subtypes registry.

=> from the Mobile Node Identifier Option

      Subtypes registry at <http://www.iana.org/assignments/mobility-parameters>.

Or perhaps better: include direct reference to draft-ietf-dmm-4283mnids ??

Also I wonder whether not some more security considerations should be added like that a new risk emerges in case not all multipath tunnels, tunnel technologies, and used access links don’t exhibit similar high security ?

Thanks!

Best Regards
Dirk
From: dmm [mailto:[email-masked]] On Behalf Of Dapeng Liu
Sent: Mittwoch, 25. November 2015 17:22
To: dmm
Subject: [DMM] Call for adoption confirmation: draft-seite-dmm-rg-multihoming-02

Hello all,

In IETF94, we initiated the call for adoption for the draft:
draft-seite-dmm-rg-multihoming-02<http://tools.ietf.org/html/draft-seite-dmm-rg-multihoming-02>:  http://tools.ietf.org/html/draft-seite-dmm-rg-multihoming-02
Seems have got sufficient support during the meeting. We'd like to confirm the call for adoption in the mailing list for 2 weeks.
Please send your opinion and comments to the list before December 9.

Thanks,
------
Best Regards,
Dapeng&Jouni

--

------
Best Regards,
Dapeng Liu

---

From: <[email-masked]>
Date: Tue, 1 Dec 2015 16:39:11 +0000

Hi Dirk,

Tanks for the review, we will modify the doc accordingly.

Pierrick

De : dmm [mailto:[email-masked]] De la part de [email-masked]
Envoyé : mardi 1 décembre 2015 15:32
À : [email-masked]; [email-masked]
Objet : Re: [DMM] Call for adoption confirmation: draft-seite-dmm-rg-multihoming-02

Dear co-chairs,  all,

p.3:

Fig.1:

Flow0=-4 => Flow-4

P.4:

p.5:

p.6:

ans thus => and thus

p.7:

p.8:

If-ATT

If-Label

Etc.

p.9:

      Subtypes registry.

Thanks!

Best Regards
Dirk

Hello all,

Thanks,
------
Best Regards,
Dapeng&Jouni

--

------
Best Regards,
Dapeng Liu

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 1 Dec 2015 11:18:28 -0600

Hi Jong-Hyouk,

On Mon, Nov 30, 2015 at 10:34 AM, Jong-Hyouk Lee <[email-masked]> wrote:
> Hi all
>
> I support the adoption of this draft as a WG draft even with the concerns
> pointed by Mingui. This draft has a merit of the introduction of the generic
> protocol extension allowing a multihomed MAG

No, the extension is for the RG, i.e. Residential Gateway which is a
broadband or fixed network element.

> to register more than one PCoA
> to the LMA. It is definitely useful for a multihomed environment.

Why would a MAG be multihomed? I am not aware of any proposals that
e..g  the serving gateway in 3GPP network where MAG is placed should
be multihomed.

Regards,
Behcet
>  Authors
> may update this draft to address Mingui’s comments if needed.
>
> J.
> --
> Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random
> Protocol Engineering Lab., Sangmyung University
>
> #email: [email-masked]
> #webpage: https://sites.google.com/site/hurryon
>
> On Nov 26, 2015, at 5:00 PM, Mingui Zhang <[email-masked]> wrote:
>
> Hi,
>
> I remember it was suggested to remove DSL, “Hybrid Access”, etc, and the
> suggestion was acknowledged. We haven’t seen an updated version yet. It is
> not ready to be adopted, I think.
>
> I have read the draft. I found the scope greatly shrinked from the 01 to 02.
> I guess the draft wants to fight through by providing a more generic
> protocol extension, while awaiting for real use cases. And, Hybrid Access
> could be treated as a potential use case (Actually, the DSL+LTE scenario is
> now intentionally inherited from the 00 version as a use case.).  If I guess
> right, I don’t think it’s a good starting point since it only covers a
> fragment of a possible solution. Besides the care of addresses, there are
> many other gaps that have not been touched: per-packet traffic
> classification and recombination, performance measurement, the bypass
> requirement, etc. From the draft, we cannot figure out a clear architectural
> overview. Section 3 doesn’t help much.
>
> Hence, I oppose its adoption.
>
> Thanks,
> Mingui
>
> Sent: Thursday, November 26, 2015 12:22 AM
> To: dmm
> draft-seite-dmm-rg-multihoming-02:
> http://tools.ietf.org/html/draft-seite-dmm-rg-multihoming-02
> Seems have got sufficient support during the meeting. We'd like to confirm
> the call for adoption in the mailing list for 2 weeks.
> _______________________________________________
> dmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmm
>
>
>
> _______________________________________________
> dmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmm
>

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 1 Dec 2015 16:41:25 -0800

As an individual contributor I support the adoption of this I-D. MCoA is 
a feature that we still lack..

The document itself still needs quite a bit of work. For example, I 
wonder if the caption for Figure 2 is correct. Also, Section 4.1. option 
fiels descriptions are somewhat broken it seems. And so on multiple 
small nits like unexpanded acronyms etc. However, these are mainly 
editorials. I have no problem with the technical solution.

- Jouni

11/25/2015, 8:22 AM, Dapeng Liu kirjoitti:
> draft-seite-dmm-rg-multihoming-02
> <http://tools.ietf.org/html/draft-seite-dmm-rg-multihoming-02>:
> Seems have got sufficient support during the meeting. We'd like to
> confirm the call for adoption in the mailing list for 2 weeks.

---

From: "Z.W. Yan" <[email-masked]>
Date: Wed, 2 Dec 2015 08:47:45 +0800

Hi, all,
+1
I support the adoption of this draft as a WG draft. It is important for the multihoming and flow mobility support.

2015-12-02 

Z.W. Yan 

发件人： Jong-Hyouk Lee 
发送时间： 2015-12-01  00:34:26 
收件人： dmm 
抄送： 
主题： Re: [DMM] Call for adoption confirmation:draft-seite-dmm-rg-multihoming-02 
 
Hi all

I support the adoption of this draft as a WG draft even with the concerns pointed by Mingui. This draft has a merit of the introduction of the generic protocol extension allowing a multihomed MAG to register more than one PCoA to the LMA. It is definitely useful for a multihomed environment. Authors may update this draft to address Mingui’s comments if needed. 

J.

Hi,
 
I remember it was suggested to remove DSL, “Hybrid Access”, etc, and the suggestion was acknowledged. We haven’t seen an updated version yet. It is not ready to be adopted, I think. 
 
I have read the draft. I found the scope greatly shrinked from the 01 to 02. I guess the draft wants to fight through by providing a more generic protocol extension, while awaiting for real use cases. And, Hybrid Access could be treated as a potential use case (Actually, the DSL+LTE scenario is now intentionally inherited from the 00 version as a use case.).  If I guess right, I don’t think it’s a good starting point since it only covers a fragment of a possible solution. Besides the care of addresses, there are many other gaps that have not been touched: per-packet traffic classification and recombination, performance measurement, the bypass requirement, etc. From the draft, we cannot figure out a clear architectural overview. Section 3 doesn’t help much.

Thanks,
Mingui

Hello all,
 
In IETF94, we initiated the call for adoption for the draft:
draft-seite-dmm-rg-multihoming-02:  http://tools.ietf.org/html/draft-seite-dmm-rg-multihoming-02
Seems have got sufficient support during the meeting. We'd like to confirm the call for adoption in the mailing list for 2 weeks.
Please send your opinion and comments to the list before December 9.

Thanks,
------
Best Regards,
Dapeng&Jouni

-- 

------
Best Regards,
Dapeng Liu

---

From: <[email-masked]>
Date: Wed, 2 Dec 2015 08:21:47 +0000

Hi Behcet,

This extension is for any use-case requiring a MAG to be multihomed. For sure,  multihomed RG can be one of them, but there is no reason to restrict MCoA to this use-case.

Pierrick

> -----Message d'origine-----
> De : dmm [mailto:[email-masked]] De la part de Behcet Sarikaya
> Envoyé : mardi 1 décembre 2015 18:18
> À : Jong-Hyouk Lee
> Cc : dmm
> > I support the adoption of this draft as a WG draft even with the
> > concerns pointed by Mingui. This draft has a merit of the introduction
> > of the generic protocol extension allowing a multihomed MAG
> 
> No, the extension is for the RG, i.e. Residential Gateway which is a broadband or
> fixed network element.
> 
> 
> Why would a MAG be multihomed? I am not aware of any proposals that e..g  the
> serving gateway in 3GPP network where MAG is placed should be multihomed.
> 
> 
> Regards,
> Behcet
> >  Authors
> > I remember it was suggested to remove DSL, “Hybrid Access”, etc, and
> > the suggestion was acknowledged. We haven’t seen an updated version
> > yet. It is not ready to be adopted, I think.
> >
> > protocol extension, while awaiting for real use cases. And, Hybrid
> > Access could be treated as a potential use case (Actually, the DSL+LTE
> > scenario is now intentionally inherited from the 00 version as a use
> > case.).  If I guess right, I don’t think it’s a good starting point
> > since it only covers a fragment of a possible solution. Besides the
> > care of addresses, there are many other gaps that have not been
> > touched: per-packet traffic classification and recombination,
> > performance measurement, the bypass requirement, etc. From the draft,
> > we cannot figure out a clear architectural overview. Section 3 doesn’t help much.
> >

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 2 Dec 2015 11:51:42 -0600

Hi Pierrick,

I hope you know how to read.
 I said noone so far said SGW should be multihomed, i.e. it should
send some of its traffic to fixed network.

In fact multihomed is wrong here as it is used for the hosts while we
are talking here about SGW or RG which have LAN and WAN side
interfaces.

I believe this draft is not ready for adoption.

Regards,

Behcet

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 2 Dec 2015 18:19:39 +0000

I support the adoption of draft-seite-dmm-rg-multihoming as. WG document. 

The ability for the MAG to register multiple transport end points with the LMA is a basic protocol semantic. How a system architecture uses this extension is a deployment consideration.

Sri

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 2 Dec 2015 13:02:23 -0600

Hi Jouni,

On Tue, Dec 1, 2015 at 6:41 PM, Jouni Korhonen <[email-masked]> wrote:
> As an individual contributor I support the adoption of this I-D. MCoA is a
> feature that we still lack..
>

Are you sure?

MCoA is solved in Netext Flow Mobility draft,

draft-ietf-netext-pmipv6-flowmob-14

is the latest draft.

BTW there was an issue in WG adoption call in IETF 93 in Yokohama. The
chair asked only those who accept. The chair unfortunately did not ask
those who oppose.

As you know, if the chair wishes to ask a single question then the
right one is any opposes.

Regards,

Behcet
> The document itself still needs quite a bit of work. For example, I wonder
> if the caption for Figure 2 is correct. Also, Section 4.1. option fiels
> descriptions are somewhat broken it seems. And so on multiple small nits
> like unexpanded acronyms etc. However, these are mainly editorials. I have
> no problem with the technical solution.
>
> - Jouni
>
>
>

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 2 Dec 2015 12:29:07 -0800

Behcet,

> draft-ietf-netext-pmipv6-flowmob-14

Sorry for my improper wording regarding which part of the MCoA I meant. 
I don't see how draft-ietf-netext-pmipv6-flowmob-14 would handle the 
case of registration when the Proxy-CoAs are from the same MAG. The 
netext draft specifically states Proxy-CoAs are from different MAGs.

But it was a good thing you brought this up. The two I-Ds need to be in 
sync.

> BTW there was an issue in WG adoption call in IETF 93 in Yokohama. The

IETF 94 I presume.. AFAIR we did not ask for adoption in IETF 93.

> right one is any opposes.

Obviously you are right here but I cannot really comment on this what 
happened in Yokohama since I was not on site or not even participating 
remotely.

Anyway, all adoption calls are confirmed on the mailing list and the 
"sense of the room" during the meeting merely serves as informative 
quidance for chairs.

- Jouni

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 3 Dec 2015 12:43:49 -0600

Hi Jouni,

On Wed, Dec 2, 2015 at 2:29 PM, Jouni Korhonen <[email-masked]> wrote:
> Sorry for my improper wording regarding which part of the MCoA I meant. I
> don't see how draft-ietf-netext-pmipv6-flowmob-14 would handle the case of
> registration when the Proxy-CoAs are from the same MAG.

I wonder why would that be needed?
MN doesn't need it.
So this draft seems to be addressing a non-problem.

Regards,

Behcet
> The netext draft
> specifically states Proxy-CoAs are from different MAGs.
>
> Anyway, all adoption calls are confirmed on the mailing list and the "sense
> of the room" during the meeting merely serves as informative quidance for
> chairs.
>
> - Jouni
>
>
>>
>> Regards,
>>
>> Behcet
>>>
>>> wonder

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 3 Dec 2015 11:38:10 -0800

Behcet,

> So this draft seems to be addressing a non-problem.

I'll let the WG to determine whether the feature is needed or not.

For me (as an individual contributor) the I-D gives a standard way to 
register multiple transport connections/tunnels between a MAG and a LMA, 
potentially over different technologies (wired, wireless, ..) on the 
transport network side without needing to rely on engineering solutions 
to achieve the same (yes - I could do a somewhat similar solution e.g. 
using MPLS but that would then be loaded with all kinds of assumptions 
that may or may not work in multi vendor and cross operator environment).

- JOuni

---

From: Lyle Bertz <[email-masked]>
Date: Thu, 3 Dec 2015 13:42:59 -0600

As an individual contributor I support the adoption of the draft as a WG
draft.

Lyle

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 3 Dec 2015 19:45:05 +0000

Ack. MAG's ability to register multiple IP transport end points is a basic
protocol semantic which is always present in enterprise architectures.

Problem with this thread it confuses the hell out of every thing. You
cannot explain and you cannot have a meaningful conversation. Pierrick
gave up and now I give up. But, this is not new; WG after WG, same folks
and same pattern.

Sri

On 12/3/15 11:38 AM, "dmm on behalf of Jouni Korhonen"
<[email-masked] on behalf of [email-masked]> wrote:

>>>> On Tue, Dec 1, 2015 at 6:41 PM, Jouni Korhonen
>>>><[email-masked]>
>>>> wrote:
>>>>>
>>>"sense

---

From: Alper Yegin <[email-masked]>
Date: Thu, 3 Dec 2015 22:25:14 +0200

I, obviously, support adoption of this I-D.

---

From: "Muley, Praveen V (Praveen)" <[email-masked]>
Date: Fri, 4 Dec 2015 08:44:45 +0000

Hi :

 As mentioned in Prague and Yokohama,  the use case defined is the broadband use case for hybrid access. Without having proper discussion on the use case it will improper to look for the solution as we MAY not even know the complete architecture issues involved in broadband access hybrid use case which is what the Figure 1 refers too.  So its too pre-mature (oppose) to adopt this as WG document.

       If the use case different than multihomed RG then please have that network diagram in document and explain properly the use case.  

If you are saying this solution can be used for multi-homed RG , first of all why would you solve that use case using layers of tunnel as there are some other better solutions which doesn't require tunneling overlay. Given that these RG is very cheap device the performance of these devices goes down dramatically so obviously doesn't address the fundamental requirement of increasing the bandwidth to the end user.

Why PMIP even if I have to use tunnel ?  There are many other better tunneling technologies like soft-GRE.   

One another point is how fast the failure of underlay tunnel on LTE and DSL detected by LMA to avoid blackholing of traffic. It will be good if you can touch base on this in your draft.  

-Praveen

-----Original Message-----
From: dmm [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, December 02, 2015 12:22 AM
To: [email-masked]; Jong-Hyouk Lee
Cc: dmm
Subject: Re: [DMM] Call for adoption confirmation: draft-seite-dmm-rg-multihoming-02

Hi Behcet,

Pierrick

> Envoyé : mardi 1 décembre 2015 18:18 À : Jong-Hyouk Lee Cc : dmm Objet 
> : Re: [DMM] Call for adoption confirmation: 
> > concerns pointed by Mingui. This draft has a merit of the 
> > introduction of the generic protocol extension allowing a multihomed 
> > MAG
> 
> e..g  the serving gateway in 3GPP network where MAG is placed should be multihomed.
> 
> 
> Regards,
> Behcet
> >  Authors
> > Access could be treated as a potential use case (Actually, the 
> > DSL+LTE scenario is now intentionally inherited from the 00 version 
> > as a use case.).  If I guess right, I don’t think it’s a good 
> > starting point since it only covers a fragment of a possible 
> > solution. Besides the care of addresses, there are many other gaps 
> > that have not been
> > performance measurement, the bypass requirement, etc. From the 
> > draft, we cannot figure out a clear architectural overview. Section 3 doesn’t help much.
> >

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: <[email-masked]>
Date: Fri, 4 Dec 2015 09:16:12 +0000

Hi,

I think there is big misunderstood here... this draft does not intend to define the BBF hybrid access architecture... not even to address this specific use-case. Few months ago, we had a consensus (including AD) to not focus on a specific use-case; we thus have removed all references to BBF use-case from this draft.  

As already said, this draft defines protocol extension. How to use this extension is part of system design and is out of the scope.

BTW, PMIP is not a tunneling but a control protocol, underlying tunneling can be GRE, IP-in-IP,...

Pierrick

> De : Muley, Praveen V (Praveen) [mailto:[email-masked]]
> Envoyé : vendredi 4 décembre 2015 09:45
> À : SEITE Pierrick IMT/OLN; [email-masked]; Jong-Hyouk Lee
> Cc : dmm
> Objet : RE: [DMM] Call for adoption confirmation: draft-seite-dmm-rg-multihoming-
> 02
> 
> Hi :
> 
>  As mentioned in Prague and Yokohama,  the use case defined is the broadband
> use case for hybrid access. Without having proper discussion on the use case it
> will improper to look for the solution as we MAY not even know the complete
> architecture issues involved in broadband access hybrid use case which is what
> the Figure 1 refers too.  So its too pre-mature (oppose) to adopt this as WG
> document.
> 
>        If the use case different than multihomed RG then please have that network
> diagram in document and explain properly the use case.
> 
> If you are saying this solution can be used for multi-homed RG , first of all why
> would you solve that use case using layers of tunnel as there are some other better
> solutions which doesn't require tunneling overlay. Given that these RG is very
> cheap device the performance of these devices goes down dramatically so
> obviously doesn't address the fundamental requirement of increasing the
> bandwidth to the end user.
> 
> One another point is how fast the failure of underlay tunnel on LTE and DSL
> detected by LMA to avoid blackholing of traffic. It will be good if you can touch
> base on this in your draft.
> 
> 

This draft only deals with mPCoAfailure detection is adressed 

> This extension is for any use-case requiring a MAG to be multihomed. For sure,
> multihomed RG can be one of them, but there is no reason to restrict MCoA to this
> use-case.
> 
> Pierrick
> 
> ______________________________________________________________________
> ___________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou
> copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le
> signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si
> ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged
> information that may be protected by law; they should not be distributed, used or
> copied without authorisation.

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 4 Dec 2015 12:01:36 +0100

Hi,

I support adoption.

One little note: the -rg- in filename makes think of Research Group.  It 
would make sense to change the filename to avoid the use of -rg-, if 
it's not too complicated.

Alex

---

From: <[email-masked]>
Date: Fri, 4 Dec 2015 11:06:36 +0000

Good point... moreover, "rg" means nothing here... 

> De : dmm [mailto:[email-masked]] De la part de Alexandre Petrescu
> Envoyé : vendredi 4 décembre 2015 12:02
> À : dmm
> One little note: the -rg- in filename makes think of Research Group.  It would make
> sense to change the filename to avoid the use of -rg-, if it's not too complicated.
> 
> Alex
>

---

From: Mingui Zhang <[email-masked]>
Date: Mon, 7 Dec 2015 03:29:29 +0000

Hi, 

Thanks for letting us know the draft does not intend to define the BBF hybrid access arch any more. And yes, I noticed the reference [WT-348] had been removed in the 02 version, but "Hybrid Access" is a term defined by BBF WT-348 so it should be removed from the text to avoid misleading.

> >  As mentioned in Prague and Yokohama,  the use case defined is the
> > broadband use case for hybrid access. Without having proper discussion
> > on the use case it will improper to look for the solution as we MAY
> > not even know the complete architecture issues involved in broadband
> > access hybrid use case which is what the Figure 1 refers too.
<snip>

Definitely. As the draft intends not to refer to BBF WT-348's "DSL+LTE" use-case, Figure 1 should be removed.  

Thanks,
Mingui

> Sent: Friday, December 04, 2015 5:16 PM
> To: Muley, Praveen V (Praveen); [email-masked]; Jong-Hyouk Lee
> Cc: dmm
> I think there is big misunderstood here... this draft does not intend to define
> the BBF hybrid access architecture... not even to address this specific use-case.
> Few months ago, we had a consensus (including AD) to not focus on a specific
> use-case; we thus have removed all references to BBF use-case from this draft.
> 
> As already said, this draft defines protocol extension. How to use this extension
> is part of system design and is out of the scope.
> 
> > De : Muley, Praveen V (Praveen)
> > [mailto:[email-masked]]
> > Envoyé : vendredi 4 décembre 2015 09:45 À : SEITE Pierrick IMT/OLN;
> > [email-masked]; Jong-Hyouk Lee Cc : dmm Objet : RE: [DMM] Call for
> > adoption confirmation: draft-seite-dmm-rg-multihoming-
> > 02
> >
> > Hi :
> >
> >  As mentioned in Prague and Yokohama,  the use case defined is the
> > broadband use case for hybrid access. Without having proper discussion
> > on the use case it will improper to look for the solution as we MAY
> > not even know the complete architecture issues involved in broadband
> > access hybrid use case which is what the Figure 1 refers too.  So its
> > too pre-mature (oppose) to adopt this as WG document.
> >
> >        If the use case different than multihomed RG then please have
> > that network diagram in document and explain properly the use case.
> >
> > If you are saying this solution can be used for multi-homed RG , first
> > of all why would you solve that use case using layers of tunnel as
> > there are some other better solutions which doesn't require tunneling
> > overlay. Given that these RG is very cheap device the performance of
> > these devices goes down dramatically so obviously doesn't address the
> > fundamental requirement of increasing the bandwidth to the end user.
> >
> > One another point is how fast the failure of underlay tunnel on LTE
> > and DSL detected by LMA to avoid blackholing of traffic. It will be
> > good if you can touch base on this in your draft.
> >
> >
> 
> > This extension is for any use-case requiring a MAG to be multihomed.
> > For sure, multihomed RG can be one of them, but there is no reason to
> > restrict MCoA to this use-case.
> >
> > Pierrick
> >
> > > On Mon, Nov 30, 2015 at 10:34 AM, Jong-Hyouk Lee
> > > <[email-masked]>
> > > wrote:
> > > > Hi all
> > > >
> > > > introduction of the generic protocol extension allowing a
> > > > multihomed MAG
> > >
> > > be
> > multihomed.
> > > > I remember it was suggested to remove DSL, “Hybrid Access”, etc,
> > > > and the suggestion was acknowledged. We haven’t seen an updated
> > > > version yet. It is not ready to be adopted, I think.
> > > >
> > > > I guess the draft wants to fight through by providing a more
> > > > generic protocol extension, while awaiting for real use cases.
> > > > And, Hybrid Access could be treated as a potential use case
> > > > (Actually, the
> > > > DSL+LTE scenario is now intentionally inherited from the 00
> > > > DSL+version
> > > > draft, we cannot figure out a clear architectural overview.
> > > > Section 3 doesn’t
> > help much.
> > > >
> > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> > exploites ou copies sans autorisation. Si vous avez recu ce message
> > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi
> > que les pieces jointes. Les messages electroniques etant susceptibles
> > d'alteration, Orange decline toute responsabilite si ce message a ete altere,
> deforme ou falsifie. Merci.
> >
> > This message and its attachments may contain confidential or
> > privileged information that may be protected by law; they should not
> > be distributed, used or copied without authorisation.
> ________________________________________________________________
> _________________________________________________________
> 
> electroniques etant susceptibles d'alteration, Orange decline toute
> responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> information that may be protected by law; they should not be distributed, used
> or copied without authorisation.

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Mon, 7 Dec 2015 06:07:04 +0000

> but "Hybrid Access" is a term defined by BBF WT-348 so it should be
>removed from the text to avoid misleading.

We will consider this feedback.

> As the draft intends not to refer to BBF WT-348's "DSL+LTE" use-case,
>Figure 1 should be removed.

The extension is not tied to any specific access technology and its
perfectly reasonable to refer to any access technology. We will make the
wording clear that its only an example.

Sri

On 12/6/15, 7:29 PM, "dmm on behalf of Mingui Zhang" <[email-masked]
on behalf of [email-masked]> wrote:

>Hi, 
>
>Thanks for letting us know the draft does not intend to define the BBF
>hybrid access arch any more. And yes, I noticed the reference [WT-348]
>had been removed in the 02 version, but "Hybrid Access" is a term defined
>by BBF WT-348 so it should be removed from the text to avoid misleading.
>
>> BTW, PMIP is not a tunneling but a control protocol, underlying
>>tunneling can
>> be GRE, IP-in-IP,...
>> 
>> Pierrick
>> 
>> > > > may update this draft to address Mingui¹s comments if needed.
>> > > >
>> > > > J.
>> > > > --
>> > > > I remember it was suggested to remove DSL, ³Hybrid Access², etc,
>> > > > and the suggestion was acknowledged. We haven¹t seen an updated
>> > > > as a use case.).  If I guess right, I don¹t think it¹s a good
>> > > > Section 3 doesn¹t
>> ______
>>exploites ou
>> If you have received this email in error, please notify the sender and
>>delete this
>> message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have
>>been
>> modified, changed or falsified.
>> Thank you.
>>

---

From: <[email-masked]>
Date: Tue, 8 Dec 2015 11:06:21 +0100

Hi Pierrick,
Thank you for the clarification!
May I recommend then to exchange also the multiple occurrences of RG in the draft text by - why not MAG?

Your approach which I think of as mainly opting towards future mobility management systems with multiple connections (e.g. backhauling of vehicular/nomadic access nodes or MRs) otherwise might be interpreted in a misleading direction ...

Having said this I also would appreciate to replace the expression 'hybrid' by 'multi-link' or 'multi-connected'. For an BBF-related aggregated access bundling often called 'hybrid access' (see e.g. BANANA activity) there are - as Mingui already pointed out - other solution proposals available which consider in detail the specific existing gaps.

IMHO I would also opting to replace the use case DSL+LTE by a more general one e.g. multiple wireless and cellular links as WiFi+LTE or LTE(provided by operator x) + LTE(provided by operator y) or even LTE+future 5G air interface ...
;-)

Thanks a lot!

Best Regards
Dirk

-----Original Message-----
From: dmm [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Freitag, 4. Dezember 2015 12:07
To: Alexandre Petrescu; dmm
Subject: Re: [DMM] Call for adoption confirmation: draft-seite-dmm-rg-multihoming-02

> De : dmm [mailto:[email-masked]] De la part de Alexandre 
> Petrescu Envoyé : vendredi 4 décembre 2015 12:02 À : dmm Objet : Re: 
> [DMM] Call for adoption confirmation: draft-seite-dmm-rg-multihoming-
> 02
> 
> Hi,
> 
> I support adoption.
> 
> One little note: the -rg- in filename makes think of Research Group.  
> It would make sense to change the filename to avoid the use of -rg-, if it's not too complicated.
> 
> Alex
>

---

From: Mingui Zhang <[email-masked]>
Date: Wed, 9 Dec 2015 02:53:56 +0000

Hi,

I am not alone who find Figure 1 is misleading. Lots of people around know 'DSL+LTE' is a peculiar use case of BBF WT-348. Now that the draft intends to provide a generic protocol extension for mobility management systems, please drop that use case. 

Looking at the structure of the doc, Figure 1 is obviously a good position to give a generic reference model rather than a specific example, not to mention a misleading one. 

In the text, 
   " Flow-1,2 and 3 are distributed either on
   Tunnel-1 (over LTE) or Tunnel-2 (ober DSL), while Flow-4 is spread on
   both Tunnel-1 and 2. "
s/ober/over/
So, this indicates the doc aims to support both per-flow and per-packet traffic distribution. This point could be explicitly stated. 

In the figure,
s/Flow0=-4/ Flow-4 /

I guess authors would produce an updated version to address the issues we've found.

Thanks,
Mingui

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, December 08, 2015 6:06 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [DMM] Call for adoption confirmation:
> Your approach which I think of as mainly opting towards future mobility
> management systems with multiple connections (e.g. backhauling of
> vehicular/nomadic access nodes or MRs) otherwise might be interpreted in a
> misleading direction ...
> 
> Having said this I also would appreciate to replace the expression 'hybrid' by
> 'multi-link' or 'multi-connected'. For an BBF-related aggregated access bundling
> often called 'hybrid access' (see e.g. BANANA activity) there are - as Mingui
> already pointed out - other solution proposals available which consider in detail
> the specific existing gaps.
> 
> IMHO I would also opting to replace the use case DSL+LTE by a more general
> one e.g. multiple wireless and cellular links as WiFi+LTE or LTE(provided by
> operator x) + LTE(provided by operator y) or even LTE+future 5G air interface ...
> ;-)
> 
> Thanks a lot!
> 
> Best Regards
> Dirk
>

---

From: Erunika <[email-masked]>
Date: Wed, 09 Dec 2015 13:13:03 +0900

Hi,

I also support the adoption.

However, I have a slight concern.I find Figure 1 little too specific and 
it might mislead the audience.
Maybe the wording should be changed in order to emphasize that this is 
just an instance.
Or else, I think the use case should be dropped.
However, having an example would be extremely helpful in understanding. 
So I would suggest the former.

Regards,
IRU

---

From: Jouni <[email-masked]>
Date: Tue, 8 Dec 2015 21:04:34 -0800

> On 08 Dec 2015, at 18:53, Mingui Zhang <[email-masked]> wrote:
> 
> Hi,
> 

I do not see why giving an example which happens to depict access technologies such as LTE and DSL would be somehow exclusive to some specific SDO. 

- Jouni

---

From: <[email-masked]>
Date: Wed, 9 Dec 2015 09:02:24 +0000

Hi,

> De : Mingui Zhang [mailto:[email-masked]]
> Envoyé : mercredi 9 décembre 2015 03:54
> À : [email-masked]; SEITE Pierrick IMT/OLN; [email-masked]
> Cc : [email-masked]
> I am not alone who find Figure 1 is misleading. Lots of people around know
> 'DSL+LTE' is a peculiar use case of BBF WT-348. 

Do you mean that using DSL and LTE together is a BBF trademark? ... come on. :-).. anyway, I don't care about using another example... why not WiFi and LTE... is it ok? Is there any SDO which claims exclusivity on this use-case ;-) ?

Now that the draft intends to
> provide a generic protocol extension for mobility management systems, please
> drop that use case.
> 
> Looking at the structure of the doc, Figure 1 is obviously a good position to give a
> generic reference model rather than a specific example, not to mention a
> misleading one.
> 
> In the text,
> So, this indicates the doc aims to support both per-flow and per-packet traffic
> distribution. This point could be explicitly stated.
> 

It is stated on section 3.2. but, you are right, it is maybe worth to clarify this in the introduction as well.

> I guess authors would produce an updated version to address the issues we've

Yes of course. Thanks for the comments.

> > Your approach which I think of as mainly opting towards future
> > mobility management systems with multiple connections (e.g.
> > backhauling of vehicular/nomadic access nodes or MRs) otherwise might
> > be interpreted in a misleading direction ...
> >
> > Having said this I also would appreciate to replace the expression
> > 'hybrid' by 'multi-link' or 'multi-connected'. For an BBF-related
> > aggregated access bundling often called 'hybrid access' (see e.g.
> > BANANA activity) there are - as Mingui already pointed out - other
> > solution proposals available which consider in detail the specific existing gaps.
> >
> > IMHO I would also opting to replace the use case DSL+LTE by a more
> > general one e.g. multiple wireless and cellular links as WiFi+LTE or
> > LTE(provided by operator x) + LTE(provided by operator y) or even LTE+future
> 5G air interface ...
> > ;-)
> >
> > Thanks a lot!
> >
> > Best Regards
> > Dirk
> >
> > > It would make sense to change the filename to avoid the use of -rg-,
> > > if it's not
> > too complicated.
> > >
> > > Alex
> > >
> > delete this message and its attachments.
> > been modified, changed or falsified.
> > Thank you.
> >

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorization.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange shall not be liable if this message was modified, changed or falsified.
Thank you.

---

From: <[email-masked]>
Date: Wed, 9 Dec 2015 09:19:52 +0000

Hi,

> De : dmm [mailto:[email-masked]] De la part de Erunika
> Envoyé : mercredi 9 décembre 2015 05:13
> À : [email-masked]
> However, I have a slight concern.I find Figure 1 little too specific and it might
> mislead the audience.
> Maybe the wording should be changed in order to emphasize that this is just an
> instance.

You're right. Next revision shall clarify this.

> So I would suggest the former.

Agreed. Thanks for your comments.

Pierrick

> > if it's not too complicated.
> >
> > Alex
> >

---

From: Mingui Zhang <[email-masked]>
Date: Wed, 9 Dec 2015 09:32:16 +0000

Hi Pierrick,

> Do you mean that using DSL and LTE together is a BBF trademark? ... come
> on. :-).. anyway, I don't care about using another example... why not WiFi and
> LTE... is it ok? Is there any SDO which claims exclusivity on this use-case ;-) ?

:-)

I would say "exclusivity" is exaggerated. The fact is that people already have that background knowledge so that they can easily get the impression that this is talking about the BBF use case. Also, the older versions did refer to WT-348 use case. 

There are alternative examples, as you've already suggested, that can be used in the placeholder. It would be easier to use them. 

Thanks,
Mingui

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, December 09, 2015 5:02 PM
> To: Mingui Zhang; [email-masked]; [email-masked]
> > De : Mingui Zhang [mailto:[email-masked]] Envoyé : mercredi 9
> > décembre 2015 03:54 À : [email-masked]; SEITE Pierrick
> > IMT/OLN; [email-masked] Cc : [email-masked] Objet : RE:
> > I am not alone who find Figure 1 is misleading. Lots of people around
> > know 'DSL+LTE' is a peculiar use case of BBF WT-348.
> 
> Do you mean that using DSL and LTE together is a BBF trademark? ... come
> on. :-).. anyway, I don't care about using another example... why not WiFi and
> LTE... is it ok? Is there any SDO which claims exclusivity on this use-case ;-) ?
> 
> > provide a generic protocol extension for mobility management systems,
> > please drop that use case.
> >
> > Looking at the structure of the doc, Figure 1 is obviously a good
> > position to give a generic reference model rather than a specific
> > example, not to mention a misleading one.
> >
> > In the text,
> > So, this indicates the doc aims to support both per-flow and
> > per-packet traffic distribution. This point could be explicitly stated.
> >
> 
> > > backhauling of vehicular/nomadic access nodes or MRs) otherwise
> > > might be interpreted in a misleading direction ...
> > >
> > > > It would make sense to change the filename to avoid the use of
> > > > -rg-, if it's not
> > > too complicated.
> > > >
> > > > Alex
> > > >
> > > > > Seems have got sufficient support during the meeting. We'd like
> > > > > to confirm the call for adoption in the mailing list for 2 weeks.
> > > confidentielles ou privilegiees et ne doivent donc pas etre
> > > diffuses, exploites ou copies sans autorisation. Si vous avez recu
> > > ce message par erreur, veuillez le signaler a l'expediteur et le
> > > detruire ainsi que les pieces jointes. Les messages electroniques
> > > etant susceptibles d'alteration, Orange decline toute responsabilite
> > > si ce message a ete altere,
> > > If you have received this email in error, please notify the sender
> > > and delete this message and its attachments.
> > > As emails may be altered, Orange is not liable for messages that
> > > have been modified, changed or falsified.
> > > Thank you.
> > >
> electroniques etant susceptibles d'alteration, France Telecom - Orange decline
> toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci
> 
> or copied without authorization.
> As emails may be altered, France Telecom - Orange shall not be liable if this
> message was modified, changed or falsified.
> Thank you.

---

From: <[email-masked]>
Date: Wed, 9 Dec 2015 09:44:27 +0000

Hi Dirk,

> De : [email-masked] [mailto:[email-masked]]

> Envoyé : mardi 8 décembre 2015 11:06

> À : SEITE Pierrick IMT/OLN; [email-masked]

> May I recommend then to exchange also the multiple occurrences of RG in the

> draft text by - why not MAG?

Sure, this doc must not refer to RG, MAG should be used instead . Thanks

> already pointed out - other solution proposals available which consider in detail the

> specific existing gaps.

Agreed. Let's use IETF terminology as per RFC4885 and talk about multihoming instead.

> IMHO I would also opting to replace the use case DSL+LTE by a more general one

> e.g. multiple wireless and cellular links as WiFi+LTE or LTE(provided by operator x)

> + LTE(provided by operator y) or even LTE+future 5G air interface ...

Even if I do not see why Wifi+LTE is more general than DSL+LTE,  I have no problem with using another example :-) we will change the example in next revision.

Thanks,

Pierrick

> From: dmm [mailto:[email-masked]] On Behalf Of

> [email-masked]<mailto:[email-masked]>

> Subject: Re: [DMM] Call for adoption confirmation: draft-seite-dmm-rg-

> multihoming-02

> > It would make sense to change the filename to avoid the use of -rg-, if it's not

> > > [email-masked]<mailto:[email-masked]>

> > [email-masked]<mailto:[email-masked]>

> If you have received this email in error, please notify the sender and delete this

> As emails may be altered, Orange is not liable for messages that have been

> [email-masked]<mailto:[email-masked]>

---

From: <[email-masked]>
Date: Wed, 9 Dec 2015 09:45:24 +0000

> Envoyé : mercredi 9 décembre 2015 10:32
> À : SEITE Pierrick IMT/OLN; [email-masked]; [email-masked]
> > Do you mean that using DSL and LTE together is a BBF trademark? ...
> > come on. :-).. anyway, I don't care about using another example... why
> > not WiFi and LTE... is it ok? Is there any SDO which claims exclusivity on this
> use-case ;-) ?
> 
> :-)
> 
> I would say "exclusivity" is exaggerated. The fact is that people already have that
> background knowledge so that they can easily get the impression that this is
> talking about the BBF use case. Also, the older versions did refer to WT-348 use
> case.
> 
> There are alternative examples, as you've already suggested, that can be used in
> the placeholder. It would be easier to use them.
> 

Ok, no problem. 

> > > De : Mingui Zhang [mailto:[email-masked]] Envoyé : mercredi
> > > 9 décembre 2015 03:54 À : [email-masked]; SEITE Pierrick
> > > I am not alone who find Figure 1 is misleading. Lots of people
> > > around know 'DSL+LTE' is a peculiar use case of BBF WT-348.
> >
> > Do you mean that using DSL and LTE together is a BBF trademark? ...
> > come on. :-).. anyway, I don't care about using another example... why
> > not WiFi and LTE... is it ok? Is there any SDO which claims exclusivity on this
> use-case ;-) ?
> >
> > > provide a generic protocol extension for mobility management
> > > systems, please drop that use case.
> > >
> > It is stated on section 3.2. but, you are right, it is maybe worth to
> > clarify this in the introduction as well.
> >
> >
> > > In the figure,
> > > s/Flow0=-4/ Flow-4 /
> > >
> > > > solution proposals available which consider in detail the specific
> > > > existing
> > gaps.
> > > >
> > > > general one e.g. multiple wireless and cellular links as WiFi+LTE
> > > > or LTE(provided by operator x) + LTE(provided by operator y) or
> > > > even
> > > > LTE+future
> > > 5G air interface ...
> > > > ;-)
> > > >
> > > > Thanks a lot!
> > > >
> > > > Best Regards
> > > > Dirk
> > > >
> > > > [email-masked]
> > > > > > Seems have got sufficient support during the meeting. We'd
> > > > > > like to confirm the call for adoption in the mailing list for 2 weeks.
> > > > etant susceptibles d'alteration, Orange decline toute
> > > > privileged information that may be protected by law; they should
> > > > not be distributed, used or copied without authorisation.
> > d'alteration, France Telecom - Orange decline toute responsabilite si
> > ce message a ete altere, deforme ou falsifie. Merci
> >
> > be distributed, used or copied without authorization.
> > As emails may be altered, France Telecom - Orange shall not be liable
> > if this message was modified, changed or falsified.
> > Thank you.

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 9 Dec 2015 16:17:34 +0000

> Ok, no problem.

Now, I guess, it significantly improves of odds of some new protocol that
folks plan to define to be adopted as THE solution for the target SDO :)

FWIW, we will absolutely make sure this extension stays relevant to any
pairs of access technologies, with no restrictions.

Sri

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 9 Dec 2015 23:39:19 +0000

> Please send your opinion and comments to the list before December 9.

I am generally open to exploring multipath binding support for PMIPv6. I do 
have some comments on the content of the draft.

The example call flow in the draft is extremely confusing. Figure 1 shows LTE 
and DSL as the access technologies and I am assuming the CPE/RG is where the 
MAG functionality is going to reside. If this is the case, why is WLAN being 
shown like an uplink technology? Can you please clarify?

Also the term "hybrid access" is used in the draft without being defined. I 
think it would make sense to define it, refer to an existing definition, or 
reword. I am guessing lot of the confusion people are having regarding the 
relationship this has to BBF work is related to the use of this term.

Thanks
Suresh

---

From: <[email-masked]>
Date: Thu, 10 Dec 2015 08:51:27 +0000

Hi Suresh,

> De : dmm [mailto:[email-masked]] De la part de Suresh Krishnan
> Envoyé : jeudi 10 décembre 2015 00:39
> À : Dapeng Liu; dmm
> I am generally open to exploring multipath binding support for PMIPv6. I do have
> some comments on the content of the draft.
> 
> The example call flow in the draft is extremely confusing. Figure 1 shows LTE and
> DSL as the access technologies and I am assuming the CPE/RG is where the MAG
> functionality is going to reside. If this is the case, why is WLAN being shown like
> an uplink technology? Can you please clarify?
> 

Access technologies are only examples but I agree we should keep the same example across the document to avoid confusion.

RG shall be removed, only MAG will be used in next release.

> Also the term "hybrid access" is used in the draft without being defined. I think it
> would make sense to define it, refer to an existing definition, or reword. I am
> guessing lot of the confusion people are having regarding the relationship this has
> to BBF work is related to the use of this term.
> 

Agreed. This term shall be removed.

Thanks

---

From: "Muley, Praveen V (Praveen)" <[email-masked]>
Date: Thu, 10 Dec 2015 09:21:39 +0000

Hi :

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, December 04, 2015 1:16 AM
To: Muley, Praveen V (Praveen); [email-masked]; Jong-Hyouk Lee
Cc: dmm
Subject: RE: [DMM] Call for adoption confirmation: draft-seite-dmm-rg-multihoming-02

Hi,

PM >> Thanks for clarification. In that case removing figure 1 and referring correct reference diagram will help.

PM >> It is important to explain what you are solving so that we  understand need for  protocol extension. Use case will also help knowing the completeness of the extension.

PM >>  I meant PMIP signaled tunnels.  More importantly the question why use PMIP for control plane signaling in the use of hybrid access (specifically BBF use case) and what is its value add over say soft-GRE which doesn't require any state maintenance. We know from wifi deployment that there are some signaling load issues.

Pierrick

> d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>

---

From: Dapeng Liu <[email-masked]>
Date: Mon, 14 Dec 2015 12:01:50 +0800

> right one is any opposes.
Hi Behcet,
As said during the meeting, the final call for adoption will be made on the
mailing list.  Not all the people who is interested in this work attended
the meeting. The question that asked during the meeting only to get
 general sense of the room for the adoption.

Thansk,
Dapeng

-- 

------
Best Regards,
Dapeng Liu