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
