Folks, This poll is not a WG poll. We have not decided on such a poll in Orlando, please check the minutes.
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. Regards, Behcet On Fri, Apr 19, 2013 at 2:35 PM, Rahman, Akbar < [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]] On > Behalf Of Stig Venaas > Sent: Friday, April 19, 2013 2:36 PM > To: [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] > >> > >> > >> ------------------------------------------------------------------------ > >> > >> 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 > >> > > > > _______________________________________________ > > multimob mailing list > > [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 >
_______________________________________________ multimob mailing list [email protected] https://www.ietf.org/mailman/listinfo/multimob
