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

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

Hi Arnaud,

> Subject: Re: [MEXT] Reviews of draft-ietf-mext-binding-revocation-02
> 
> Hi,
> 
> "Ahmad Muhanna" <[e-mail]> writes:
> 
> 
> >> >    administrative reason.  This mechanism enables the 
> home domain to
> >> >    dynamically allow the user to act upon the revocation 
> message in
> >> >    order to not have an unexpectedly interrupted mobile
> >> IPv6 services.
> >> 
> >> Well, when it receives the information, it's already too 
> late, isn't 
> >> it?
> >
> > [Ahmad]
> > What is meant here, the MN will have an instant but graceful 
> > indication that its mobility service is being revoked. At 
> that time, 
> > the MN will be able to make an out of scope communication to 
> > check/enable/etc. the service with its provider, for example. This 
> > case is meant to replace/"be compared" the case when the HA deletes 
> > the binding and the tunnel without informing the MN.
> 
> What about that instead of the last sentence:
> 
> "This mechanism enables the home domain to dynamically allow 
> the user to  act upon the revocation message in order to 
> recover its interrupted  mobile IPv6 services."

[Ahmad]
Ok.

> 
> 
> >>      Last question on that paragraph: The last sentence start with
> >>      "If". Why? I mean, this is mandated by 3775. Is it for PMIPv6?
> >> 
> >> > 6.  Binding Revocation Message
> >> > 
> >> >    This section defines a Binding Revocation Message that
> >> use a MH type
> >> >    <IANA-TBD> with a Binding Revocation type field that
> >> follow the MH
> >> >    format described in section 6.1.  [RFC3775].  The value in the
> >> 
> >>                                  ^^^^^^^^^^^^^^^^
> >>                           6.1 of [RFC3775] or just 6.1?
> >> 
> > [Ahmad]
> > Sure we can reference [RFC3775].
> 
> 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.

> 
> 
> >> >            Figure 6: Binding Revocation Acknowledgement Message
> >> > 
> >> > 
> >> >    Status
> >> > 
> >> >       8-bit unsigned integer indicating the result of 
> processing the
> >> >       Binding Revocation Indication message by the
> >> receiving mobility
> >> >       entity.  The following status values are currently defined.
> >> > 
> >> >           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"

Regards,
Ahmad

> 
> >> General comment: in the draft, the few times "Type 2 Header" 
> >> is used, it should probably be replaced by "Type 2 Routing Header" 
> >> for consistency.
> >
> > [Ahmad]
> > Sure.
> 
> ack. thanks
> 
> Cheers,
> 
> a+
> 
> 
_______________________________________________
MEXT mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mext