Re: [MEXT] Reviews of draft-ietf-mext-binding-revocation-02

[[e-mail] (Arnaud Ebalard)]

Hi Ahmad,

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

>> it's not what I meant. I meant that "[RFC3775]" sits there in 
>> the middle of the sentence. Is it expected?
>
> [Ahmad]
> I see what you meant.
>
> What about the following:
>
>    This section defines the Binding Revocation Message format using a
>    MH Type <IANA-TBD> as illustrated in Figure 4. The value in the
>    Binding Revocation Type field defines whether the Binding
>    Revocation message is a BRI or BRA. If the Binding Revocation type
>    field is set to 1, the Binding Revocation Message is a Binding
>    Revocation Indication message as in Section 6.1. However, if the
>    value is 2, it is a Binding Revocation Acknowledgement message as
>    in Section 6.2.

fine with me. thanks.


>> >> >           0  success.
>> >> >           1  partial success.
>> >> >           2  Binding Does NOT Exist.
>> >> >           3  IPv4 HoA Binding Does NOT Exist.
>> >> >           4  Global Revocation NOT Authorized.
>> >> >           5  CAN NOT Identify Binding.
>> >> >           6  Revocation Failed, MN is Attached.
>> >> 
>> >> The Binding Revocation Trigger values in Section 6.1 look more 
>> >> self-explanatory. They are also mainly informational, right?
>> >
>> > [Ahmad]
>> > Yes, it is mainly informational. However, whenever any R. Trigger 
>> > value means a specific action is needed on the side of the 
>> receiving 
>> > mobility node, IMO, it needs to be documented. If we missed any of 
>> > these, we can go back and do it.
>> >
>> >> 
>> >> Here, it is not clear what "partial success" (1) or "Revocation 
>> >> failed, MN is attached" mean, and what both entities should expect 
>> >> when those are sent. Maybe the rationale that were associated with 
>> >> those values when the list was first created should be included in 
>> >> the document, along with the expected behaviors (Are those status 
>> >> value just
>> >> informational?)
>> >>  
>> >> Or did I missed some other section that provides that in the draft?
>> >
>> > [Ahmad]
>> > I agree it is mainly informational but some of these status is 
>> > appropriate with certain scenarios. I believe those status values 
>> > meanings and use are mentioned when these specific scenario are 
>> > discussed later on.
>> 
>> I may have missed them but "partial success" and "Revocation 
>> failed, MN is attached" (at least) are not.
>
> [Ahmad]
> Sure. We will make sure that all of these values are described and
> documented in the new revision.
>
> In the meantime, in bthe case of "Partial success", it is the case when
> the MAG for example, receives a BRI that impact multiple bindings while
> some of them have been released already, for example. The MAG may set
> the status to success or partial success. 
>
> In the case of "Revocation failed, MN is attached", in the case of
> inter-MAG HO, the LMA may send a BRI message with a Revocation Trigger
> value of "Inter-MAG HO". In this case, the MAG may need to ensure that
> the MN is no longer attached. If the MN is still attached, then the MAG
> could send a BRA with this status value.
>
> For example, one of the bullets under section 10.1.1. says:
>
>       If the Revocation Trigger field value in the received Binding
>       Revocation Indication message indicates an inter-MAG handover and
>       the (A) bit is set, the MAG use the mobility option(s) included in
>       the BRI message to identify the mobile node binding.  The mobile
>       access gateway MAY validate that the mobile node is no longer
>       attached to the mobile access gateway before sending a successful
>       Binding Revocation Acknowledgement message to the LMA.  However,
>       if the Revocation Trigger field is set to "Inter-MAG - Unknown
>       Handoff", the MAG MUST validate that the mobile node is no longer
>       attached to the MAG before sending a successful BRA message and
>       deleting the resources associated with the mobile node binding. 
>
> We could add some text to the above to read as follows:
>
>       .....................................................  However,
>       if the Revocation Trigger field is set to "Inter-MAG - Unknown
>       Handoff" and the (A) bit is set, the MAG MUST validate that the 
>       mobile node is no longer attached to the MAG before sending a 
>       successful BRA message and deleting the resources associated 
>       with the mobile node binding. Otherwise, if the MAG verified that 
>       the MN is still attached, the MAG MUST set the status field in the
>
>       BRA to "Revocation failed - MN is attached"

Thanks for the clarification. But note that I'm not familiar enough w/
PMIPv6 to be helpful and comment that.

Cheers,

a+
_______________________________________________
MEXT mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mext