Hi Behcet, Stig,

Indeed the aim was just to collect feedback, as editors of the document, from 
the WG in order to progress the draft. This is not a minor discussion because 
the impact on the document is relevant.

It was my fault to choose wrong wording for the mail subject. Sorry for that.

Best regards,
Luis

-----Mensaje original-----
De: [email protected] [mailto:[email protected]] En nombre de 
Stig Venaas
Enviado el: sábado, 20 de abril de 2013 0:34
Para: [email protected]
CC: [email protected]; Behcet Sarikaya
Asunto: Re: [multimob] WG Poll about the inclusion or not of flag A mechanism 
in draft-ietf-multimob-handover-optimization

On 4/19/2013 1:44 PM, Behcet Sarikaya wrote:
> Folks,
>
> This poll is not a WG poll. We have not decided on such a poll in
> Orlando, please check the minutes.

I guess WG Poll is not the right title. It's not a formal poll. It's just the 
author trying to get input from the WG.

> We have 4 WG drafts and each draft has so many features/options. How
> would we cope with the situation if we had a poll on each?
>
> The author on his own has posted the mail with his own formulation of
> the questions. I repeat this is not a WG poll.
>
> My recommendation to WG is to review the WG drafts and help the
> authors improve the drafts.

Right, and as part of this, we need to provide our views on this important 
issue, so that we have a draft reflecting the WGs opinions.
I think this was the main outstanding issue from our discussion in Orlando.

Stig

> Regards,
>
> Behcet
>
> On Fri, Apr 19, 2013 at 2:35 PM, Rahman, Akbar
> <[email protected] <mailto:[email protected]>>
> wrote:
>
>     Hi Stig/Carlos,
>
>
>     I vote ofr Stig's proposal of making the flag A mechanism optional
>     but keeping it in the I-D (option 3).  My only caveat would be if
>     this requires a lot of work on the part of the Authors to update the
>     I-D as I think we should wrap up this document sooner rather than
>     later.  If Option 3 requires too much documentation effort then I
>     vote for option 2.
>
>
>
>     Akbar
>
>     -----Original Message-----
>     From: [email protected] <mailto:[email protected]>
>     [mailto:[email protected]
>     <mailto:[email protected]>] On Behalf Of Stig Venaas
>     Sent: Friday, April 19, 2013 2:36 PM
>     To: [email protected] <mailto:[email protected]>
>     Subject: Re: [multimob] WG Poll about the inclusion or not of flag A
>     mechanism in draft-ietf-multimob-handover-optimization
>
>     It would be great to get input from more people in the WG on this issue.
>
>     Stig
>
>     On 4/10/2013 10:48 AM, Stig Venaas wrote:
>      > Hi
>      >
>      > I'm responding here with my personal view, and hopefully also the
>     same
>      > as I was saying in the meeting.
>      >
>      > On 4/10/2013 12:49 AM, LUIS MIGUEL CONTRERAS MURILLO wrote:
>      >> Dear all,
>      >>
>      >> After the Orlando meeting discussions on the flag A mechanism
>     described
>      >> in draft-ietf-multimob-handover-optimization-02 for mitigating the
>      >> internal signaling within the network in case of reactive
>     handover, we
>      >> would like to consult WG members about your preference:
>      >>
>      >> Option 1.- To include the flag A mechanism as an integral (and
>      >> mandatory) part of the solution, as described in the draft today.
>      >>
>      >> Option 2.- To consider the flag A mechanism as an option to reduce
>      >> signaling in the core, then removing the reference to this mechanism
>      >> from the draft. The final document would consider that the LMA
>     always
>      >> queries the pMAG by default, but mentioning that some mechanism
>      >> (out-of-scope) could be used to reduce this signaling (by
>     avoiding to
>      >> query the pMAG).
>      >
>      > Wouldn't a 3rd option be to keep it in the draft, but not make the A
>      > flag mandatory to implement/enable? I think that may require
>     additional
>      > work though, because you may need to know whether the A flag is being
>      > used. Basically you need to know that A flag not set, doesn't
>     mean that
>      > there is no subscription when A-flag support isn't enabled.
>      >
>      > My concern is that the A-flag mechanism may not be worth the
>     effort, or
>      > even worse, if clients often switch between having multicast
>      > subscriptions and not (basically that A is frequently often updated).
>      > If the A flag is mostly stable, then I think it is useful.
>      >
>      > So at least my thinking is that unless we know with some
>     certainty what
>      > the usage pattern is, then it is better to make it optional. If
>     we agree
>      > on making it optional, then the question is whether we still want
>     it in
>      > this document (option 2 or 3).
>      >
>      > Hope we can get the input of several people in the group and try to
>      > figure out what the best option is.
>      >
>      > Stig
>      >
>      >> Thanks in advance,
>      >>
>      >> Best regards,
>      >>
>      >> Luis
>      >>
>      >> ________________________________
>      >>
>      >> Luis M. Contreras
>      >>
>      >> Technology / Global CTO / Telefónica
>      >>
>      >> Efficiency Projects / Telefónica I+D
>      >>
>      >> Distrito Telefónica, Edificio Sur 3, Planta 3
>      >>
>      >> 28050 Madrid
>      >>
>      >> España / Spain
>      >>
>      >> [email protected] <mailto:[email protected]>
>      >>
>      >>
>      >>
>     ------------------------------------------------------------------------
>      >>
>      >> Este mensaje se dirige exclusivamente a su destinatario. Puede
>     consultar
>      >> nuestra política de envío y recepción de correo electrónico en
>     el enlace
>      >> situado más abajo.
>      >> This message is intended exclusively for its addressee. We only
>     send and
>      >> receive email on the basis of the terms set out at:
>      >> http://www.tid.es/ES/PAGINAS/disclaimer.aspx
>      >>
>      >>
>      >> _______________________________________________
>      >> multimob mailing list
>      >> [email protected] <mailto:[email protected]>
>      >> https://www.ietf.org/mailman/listinfo/multimob
>      >>
>      >
>      > _______________________________________________
>      > multimob mailing list
>      > [email protected] <mailto:[email protected]>
>      > https://www.ietf.org/mailman/listinfo/multimob
>
>     _______________________________________________
>     multimob mailing list
>     [email protected] <mailto:[email protected]>
>     https://www.ietf.org/mailman/listinfo/multimob
>     _______________________________________________
>     multimob mailing list
>     [email protected] <mailto:[email protected]>
>     https://www.ietf.org/mailman/listinfo/multimob
>
>
>
>
> _______________________________________________
> multimob mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/multimob
>

_______________________________________________
multimob mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/multimob

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar 
nuestra política de envío y recepción de correo electrónico en el enlace 
situado más abajo.
This message is intended exclusively for its addressee. We only send and 
receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
_______________________________________________
multimob mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/multimob

Reply via email to