Thanks Akbar for your feedback. As I mentioned in a recent mail, our opinion is that option 3 would make the draft more complex. Probably would be better to simplify the draft to the basic handover optimization solution opening the door to further optional improvements (like the flag A mechanism) that could be analyzed and documented separately.
Let's see what others think about it. Best regards, Luis -----Mensaje original----- De: [email protected] [mailto:[email protected]] En nombre de Rahman, Akbar Enviado el: viernes, 19 de abril de 2013 21:36 Para: Stig Venaas; [email protected] Asunto: Re: [multimob] WG Poll about the inclusion or not of flag A mechanism in draft-ietf-multimob-handover-optimization 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 ________________________________ 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
