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

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

noticed that mext wg ml was never copied.

Regards, 
Ahmad 

 


________________________________

	From: Muhanna, Ahmad (RICH1:2H10) 
	Sent: Tuesday, January 06, 2009 10:17 AM
	To: 'Yungui Wang'; 'Arnaud Ebalard'
	Subject: RE: [MEXT] Reviews of
draft-ietf-mext-binding-revocation-02
	
	
	Hi Yungui,
	It also seems that I never replied to your email. 
	This suggestion makes sense and we can incorporate that too.

	Regards, 
	Ahmad 

	 


________________________________

		From: Yungui Wang [mailto:[e-mail]] 
		Sent: Tuesday, December 23, 2008 1:25 AM
		To: Muhanna, Ahmad (RICH1:2H10); Arnaud Ebalard
		Subject: Re: [MEXT] Reviews of
draft-ietf-mext-binding-revocation-02
		
		
		Hi Ahmad,
		 
		
		Just a nit. Following common usage, maybe the failed
status code can be defined over 127.
		 
		B.R.
		Yungui
		 

			----- Original Message ----- 
			From: Ahmad Muhanna <mailto:[e-mail]>

			To: Arnaud Ebalard <mailto:[e-mail]>  
			Cc: Julien Laganier
<mailto:[e-mail]>  ; IETF MEXT WG ML
<mailto:[e-mail]>  
			Sent: Tuesday, December 23, 2008 9:56 AM
			Subject: Re: [MEXT] Reviews of
draft-ietf-mext-binding-revocation-02

			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
			

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