Re: [MEXT] Acknowledgements for Revocation Messages

["Ahmad Muhanna" <[e-mail]>]

Hi Jari,

> -----Original Message-----
> From: Jari Arkko [mailto:[e-mail]] 
> Sent: Thursday, September 17, 2009 5:38 AM
> To: Muhanna, Ahmad (RICH1:2H10)
> Cc: Vijay Devarapalli; [e-mail]
> Subject: Re: Acknowledgements for Revocation Messages
> 
> Ahmad,
> 
> > IMO, they are not technical issues that breaks the 
> protocol. I believe 
> > we received good comments from Ben to clarify few points about the 
> > protocol handling and setting of the Acknowledge (A) bit. These 
> > clarifications have been agreed upon and the next revision will 
> > captured all of these clarifications.
> >   
> 
> That's good, but the point is that there were and possibly 
> are clarifications. Draft -12 says, for instance about bulk 
> revocation:
> 
> "If the local mobility anchor processes the Binding 
> Revocation Indication message successfully and the 
> Acknowledge (A) bit is set, the local mobility anchor 
> responds to the mobile access gateway by sending Binding 
> Revocation Acknowledgement message."
> 
> Does this mean that if an error is detected, no Ack is sent? 
> Maybe this is specified somewhere else, but on quick read I 
> didn't find that. 
> Obviously, we need an Ack in this case...
[Ahmad]
Sure.

> 
> If you think about the situation as a table, have you 
> specified what happens with a all combinations of
> - success / error in processing the message
> - A bit set / not set
> - G bit set / not set

[Ahmad]
Sure, let me verify that and make sure that all scenarios are covered.
If not, will add a subsection for sending BRA similar to section 9.5.4
and share with you and list before publishing.

Regards,
Ahmad
> 
> >> I'm not sure I like the rules that mix G and A bits; I 
> would rather 
> >> keep separate things separate.
> >>     
> > [Ahmad]
> > Hmmm... I am not sure we should call it mixing:) Because what would 
> > you call the following text in RFC3775:
> > "
> >    ..............................................  
> .............. After
> >    selecting a new primary care-of address, the mobile node 
> MUST send a
> >    Binding Update containing that care-of address to its home agent.
> >    The Binding Update MUST have the Home Registration (H) and
> >    Acknowledge (A) bits set .."
> >
> > Is that mixing the (H) and (A) bits?
> >   
> 
> It is... but in my opinion not a great example to follow.
> 
> > In simple words, I respectfully disagree. Let me explain why.
> > As I mentioned above, Binding Revocation mechanism addresses a wide 
> > range of usecases with various severity and consequences. Some of 
> > which are documented in the draft and many others are not. WHY when 
> > the LMA/HA would like to revoke a BCE of an important 
> fellow needs to 
> > handle that as when revoking the BCE of 
> > NO-ONE-KNOWS-ABOUT-COPPER=USER-X? Sending a BRI message 
> with the (A) 
> > bit cleared in certain cases, reduces signaling, 
> retransmission, and makes a lot of sense.
> >   
> 
> Fair enough. That's a use case for the A bit.
> 
> To explain my personal position a little bit better: I feel 
> that the use cases that I've seen are more in the class of 
> nice to have than something that would be absolutely 
> required. The added complexity is not in my opinion worth the trouble.
> 
> Jari
> 
>