Subject: Re: [MEXT] NEMO support in Binding Revocation draft

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 19 Aug 2009 04:41:46 -0500

Hi Tina,
 
I am not sure if we need to say that it is NOT supported in the
abstract. 
Binding revocation is a generic mechanism that can be supported in all
IPv6 mobility cases. However, for the current NEMO, there is no usecase
to use Binding Revocation. 
 
So, I am not certain if we need to mention this in the abstract of the
draft. 
May be we can get some feedback from the wgs.
 
Comments please?
 
I changed the subject to be issue specific.

Regards, 
Ahmad 

________________________________

	From: Tina TSOU [mailto:[email-masked]] 
	Sent: Wednesday, August 19, 2009 4:09 AM
	To: [email-masked]; Muhanna, Ahmad (RICH1:2H10)
	Cc: [email-masked]
	Subject: Re: Comments on draft-ietf-mext-binding-revocation-08

	Hi Ahmad,

	I know the history of it. The NEMO MNP is carried by DHCP
option, and the way BU/BU carrying MNP was out. Therefore it is not in
the Binding Revocation.

	I just wanna comment that since NEMO is not included, should it
be spelled out in the draft that the MIP6 extension in the Abstract does
not include NEMO?

	Though I'm wondering there is no deployment for the time being,
even no running code. There might be deployment in the future.

	I don't have strong opinion whether excluding the NEMO in the
draft.

	B. R.
	Tina
	http://tinatsou.weebly.com/contact.html

		----- Original Message ----- 
		From: Ahmad Muhanna <mailto:[email-masked]>  
		To: Tina TSOU <mailto:[email-masked]>  ;
[email-masked] 
		Cc: [email-masked] 
		Sent: Wednesday, August 19, 2009 2:57 PM
		Subject: RE: Comments on
draft-ietf-mext-binding-revocation-08

		Hello Tina,
		 
		Initially the NEMO case was part of the Binding
Revocation presentations that were made in, at least, two IETF meetings.
However, based on further discussion on the MEXT/Netlmm mailing lists,
the wg failed to find a use for Binding Revocation in the case of NEMO
for the following reasons:
		 
		1. The MNP is allocated via a mechanism other than the
BU/BA signaling. In other words, DHCP could be an option. Therefore, the
argument was made that there is no justification for the home agent to
send a Binding Revocation Indication message in order to revoke a
specific MNP.
		 
		2. On the other hand, at any time the MR would like to
revoke a specific MNP binding to its home address, the MR can send a BU
with the remaining MNPs that still valid and the home agent will update
the MR BCE accordingly. In addition, the MR can send a de-registration
to de-register all MNPs is a single message.
		 
		3. In the case that BU/BA is used for allocating MNP(s)
to a specific MR with a specific HoA, then Binding Revocation makes
sense, but, at the time of discussing this issue that mechanism for MNP
allocation was NOT available or standardized.
		 
		I hope this addresses your concern.

		Regards, 
		Ahmad 

________________________________

			From: Tina TSOU [mailto:[email-masked]] 
			Sent: Tuesday, August 18, 2009 9:31 PM
			To: [email-masked]
			Cc:
[email-masked]
			Subject: Comments on
draft-ietf-mext-binding-revocation-08

			Hi,
			I think it is good shaped and can be moved
forward except the NEMO case. 
			 
			As the draft describes "These semantics are
generic enough and can be used by mobility entities in the case of
Mobile IPv6 and its extensions. ..."
			 
			As we know, the NEMO can be one of Mobile IPv6
extensions. However, I don't see any note about it. Therefore, I wonder
if the draft is also applied for the NEMO case (RFC3963). 

			B. R.
			Tina
			http://tinatsou.weebly.com/contact.html

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 19 Aug 2009 12:52:31 +0200

Maybe we can say something in the abstract about the fact that this
revocation works ok when HA revokes the revoked thing (HoA?) from the
Mobile Host and also works if it revokes if from a Mobile Router.

This is somehow suggested already when the abstract says: "terminate a
mobile node's mobility session" because a MN could be by definition an
MH or a MR.

TO be more explicit, we could probably say instead of:
"This mechanism allows
  the mobility entity which initiates the revocation procedure to
  request its corresponding one to terminate either one, multiple or
  all specified binding cache entries."

New:
"This mechanism allows
  the mobility entity which initiates the revocation procedure to
  request its corresponding one (a Mobile Host, a Mobile Router or a
  MAG) to terminate either one, multiple or
  all specified binding cache entries."

As two side notes: (1) there is a problem  with the last part of the
phrase, because an MN doesn't hold a binding cache but a binding update
list (does a MAG hold a BC?); (2) the use of the word "corresponding"
may lead to think to CN - it's not.

Or we could add some NEMO phrase in the section 11 "Mobile Node
Operation" to say "Mobile Node (Mobile Host or Mobile Router)".

I still disagree to allocate and transmit/delegate the MNP from HA to MR
with a BU (and thus still oppose to revoke it with the Binding
Revocation Indication.)

Yours,

Alex

Ahmad Muhanna a écrit :
> abstract. Binding revocation is a generic mechanism that can be 
> supported in all IPv6 mobility cases. However, for the current NEMO,
>  there is no usecase to use Binding Revocation.
> 
> So, I am not certain if we need to mention this in the abstract of 
> the draft. May be we can get some feedback from the wgs.
> 
> Comments please?
> 
> Regards, Ahmad
> ------------------------------------------------------------------------
>  *From:* Tina TSOU [mailto:[email-masked]] *Sent:* Wednesday, August
>  19, 2009 4:09 AM *To:* [email-masked]; Muhanna, Ahmad (RICH1:2H10)
>  *Cc:* [email-masked] *Subject:* 
> Re: Comments on draft-ietf-mext-binding-revocation-08
> 
> Hi Ahmad,
> 
> I know the history of it. The NEMO MNP is carried by DHCP option, and
>  the way BU/BU carrying MNP was out. Therefore it is not in the 
> Binding Revocation.
> 
> 
> 
> I just wanna comment that since NEMO is not included, should it be 
> spelled out in the draft that the MIP6 extension in the Abstract does
>  not include NEMO?
> 
> Though I’m wondering there is no deployment for the time being, even 
> no running code. There might be deployment in the future.
> 
> I don’t have strong opinion whether excluding the NEMO in the draft.
> 
> 
> 
> 
> 
> B. R. Tina http://tinatsou.weebly.com/contact.html
> 
> ----- Original Message ----- *From:* Ahmad Muhanna 
> <mailto:[email-masked]> *To:* Tina TSOU <mailto:[email-masked]>
>  ; [email-masked] <mailto:[email-masked]> *Cc:* 
> <mailto:[email-masked]> *Sent:* 
> Wednesday, August 19, 2009 2:57 PM *Subject:* RE: Comments on 
> Initially the NEMO case was part of the Binding Revocation 
> presentations that were made in, at least, two IETF meetings. 
> However, based on further discussion on the MEXT/Netlmm mailing 
> lists, the wg failed to find a use for Binding Revocation in the case
>  of NEMO for the following reasons:
> 
> 1. The MNP is allocated via a mechanism other than the BU/BA 
> signaling. In other words, DHCP could be an option. Therefore, the 
> argument was made that there is no justification for the home agent 
> to send a Binding Revocation Indication message in order to revoke a
>  specific MNP.
> 
> 2. On the other hand, at any time the MR would like to revoke a 
> specific MNP binding to its home address, the MR can send a BU with 
> the remaining MNPs that still valid and the home agent will update 
> the MR BCE accordingly. In addition, the MR can send a 
> de-registration to de-register all MNPs is a single message.
> 
> 3. In the case that BU/BA is used for allocating MNP(s) to a specific
>  MR with a specific HoA, then Binding Revocation makes sense, but, at
>  the time of discussing this issue that mechanism for MNP allocation
>  was NOT available or standardized.
> 
> Regards, Ahmad
> ------------------------------------------------------------------------
>  *From:* Tina TSOU [mailto:[email-masked]] *Sent:* Tuesday, August 
> 18, 2009 9:31 PM *To:* [email-masked] *Cc:* 
> [email-masked] *Subject:* Comments
>  on draft-ietf-mext-binding-revocation-08
> 
> Hi, I think it is good shaped and can be moved forward except the 
> NEMO case.
> 
> As the draft describes "These semantics are generic enough and can be
>  used by mobility entities in the case of Mobile IPv6 and its 
> extensions. ..."
> 
> As we know, the NEMO can be one of Mobile IPv6 extensions. However, I
>  don't see any note about it. Therefore, I wonder if the draft is 
> also applied for the NEMO case (RFC3963).
> 
> 
> B. R. Tina http://tinatsou.weebly.com/contact.html
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> 
> 
> 
> _______________________________________________ MEXT mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/mext

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 19 Aug 2009 09:15:28 -0500

Hi Alex,
Thanks for the feedback.

Please see more inline.

Regards,
Ahmad

> -----Original Message-----
> From: Alexandru Petrescu [mailto:[email-masked]] 
> Sent: Wednesday, August 19, 2009 5:53 AM
> To: Muhanna, Ahmad (RICH1:2H10)
> Cc: Tina TSOU; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: Re: [MEXT] NEMO support in Binding Revocation draft
> 
> Maybe we can say something in the abstract about the fact 
> that this revocation works ok when HA revokes the revoked 
> thing (HoA?) from the Mobile Host and also works if it 
> revokes if from a Mobile Router.
> 
> This is somehow suggested already when the abstract says: 
> "terminate a mobile node's mobility session" because a MN 
> could be by definition an MH or a MR.
> 
> As two side notes: (1) there is a problem  with the last part 
> of the phrase, because an MN doesn't hold a binding cache but 
> a binding update list (does a MAG hold a BC?); 

[Ahmad]
Good point. What about if we use the generic term binding(s) only, as the following:
"
   ..............................................  This mechanism allows
   the mobility entity which initiates the revocation procedure to
   request its corresponding one to terminate either one, multiple or
   all specified binding(s).
"
This way we are referring to the binding(s) generically. Because, sometime, especially when the MAG sends a BRI with the (G) bit set, the recipient is the LMA which maintains Binding cache entries.

> (2) the use of 
> the word "corresponding"

[Ahmad]
I am not sure about this one, especially, we avoided on purpose the use of "node" and used "the corresponding one" to avoid any confusion.

> 
> Or we could add some NEMO phrase in the section 11 "Mobile 
> Node Operation" to say "Mobile Node (Mobile Host or Mobile Router)".
[Ahmad]
Le me understand this one. Are you saying that the HA should still be able to send a BRI message to revoke the MR HoA binding, for any reason, e.g., administrative. ? BUT for sure Not to include a specific MNP.
Is my understanding correct?

> 
> I still disagree to allocate and transmit/delegate the MNP 
> from HA to MR with a BU (and thus still oppose to revoke it 
> with the Binding Revocation Indication.)
[Ahmad]
No problem. 
Sure. We are not trying to change that. Just to make sure that the wording in Binding Revocation is accurate if applied to NEMO.

> > draft. May be we can get some feedback from the wgs.
> > 
> > Comments please?
> > 
> option, and  
> > the way BU/BU carrying MNP was out. Therefore it is not in 
> the Binding 
> > Revocation.
> > 
> > 
> > 
> > Though I'm wondering there is no deployment for the time 
> being, even 
> > I don't have strong opinion whether excluding the NEMO in the draft.
> > 
> > 
> > 
> > 
> > 
> > the wg failed to find a use for Binding Revocation in the case  of 
> > NEMO for the following reasons:
> > 
> > the remaining MNPs that still valid and the home agent will 
> update the 
> > MR BCE accordingly. In addition, the MR can send a 
> de-registration to 
> > de-register all MNPs is a single message.
> > 
> *Subject:* Comments  
> > Hi, I think it is good shaped and can be moved forward 
> except the NEMO 
> > case.
> > 
> > don't see any note about it. Therefore, I wonder if the 
> draft is also 
> > applied for the NEMO case (RFC3963).
> > 
> >

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 24 Aug 2009 11:27:32 +0200

Ahmad Muhanna a écrit :
> Hi Alex, Thanks for the feedback.
> 
> Please see more inline.
> 
> Regards, Ahmad
> 
> 
>> -----Original Message----- From: Alexandru Petrescu 
>> [mailto:[email-masked]] Sent: Wednesday, August 19, 
>> 2009 5:53 AM To: Muhanna, Ahmad (RICH1:2H10) Cc: Tina TSOU; 
>> [email-masked]; 
>>  revocation works ok when HA revokes the revoked thing (HoA?) from 
>> the Mobile Host and also works if it revokes if from a Mobile 
>> Router.
>> 
>> "terminate a mobile node's mobility session" because a MN could be 
>> by definition an MH or a MR.
>> 
>> TO be more explicit, we could probably say instead of: "This 
>> mechanism allows the mobility entity which initiates the revocation
>>  procedure to request its corresponding one to terminate either
>> one, multiple or all specified binding cache entries."
>> 
>> New: "This mechanism allows the mobility entity which initiates the
>>  revocation procedure to request its corresponding one (a Mobile 
>> Host, a Mobile Router or a MAG) to terminate either one, multiple 
>> or all specified binding cache entries."
>> 
>> As two side notes: (1) there is a problem  with the last part of 
>> the phrase, because an MN doesn't hold a binding cache but a 
>> binding update list (does a MAG hold a BC?);
> 
> [Ahmad] Good point. What about if we use the generic term binding(s) 
> only, as the following: " 
> all specified binding(s). "
> 
> This way we are referring to the binding(s) generically. Because,
> sometime, especially when the MAG sends a BRI with the (G) bit set,
> the recipient is the LMA which maintains Binding cache entries.

I agree with the intention to talk bindings (instead of binding cache
entry), it's clearer in this case.

But to say "request its corresponding one" doesn't sound very ok to my
non-native English reading.  "request a node"?

Anyways, this is final editing stuff... I trust the Editor is very good 
at these things.

>> (2) the use of the word "corresponding" may lead to think to CN - 
>> it's not.
> 
> [Ahmad] I am not sure about this one, especially, we avoided on 
> purpose the use of "node" and used "the corresponding one" to avoid 
> any confusion.

IT's as you wish, but "corresponding node" is too similar to
"Correspondent Node".

> [Ahmad] Le me understand this one. Are you saying that the HA should 
> still be able to send a BRI message to revoke the MR HoA binding, for
>  any reason, e.g., administrative. ? BUT for sure Not to include a 
> specific MNP. Is my understanding correct?
> 
>> I still disagree to allocate and transmit/delegate the MNP from HA 
>> to MR with a BU (and thus still oppose to revoke it with the 
>> Binding Revocation Indication.)
> [Ahmad] No problem. Sure. We are not trying to change that. Just to 
> make sure that the wording in Binding Revocation is accurate if 
> applied to NEMO.

Ok.

Alex

---

From: "Laganier, Julien" <[email-masked]>
Date: Mon, 24 Aug 2009 08:07:42 -0700

FWIW,

> non-native English reading.  "request a node"?

s/corresponding one/peer
 
--julien

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 25 Aug 2009 00:47:38 -0500

> Subject: RE: [MEXT] NEMO support in Binding Revocation draft
> 
> > 

[Ahmad]
Thanks Julien. This is a good choice assuming that the MN qualifies to
be an HA peer.

All,
So basically we have a couple of minor wording to update; I guess we can
wait for the next revision to include these two minor changes.

Regards,
Ahmad