Subject: Re: [MEXT] Scope of generic notification

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 28 May 2008 16:08:59 -0700 (PDT)

If this is about MH Type defined in RFC 3775 as an 8-bit field not being enough and that we need to define a MH Subtype, we should state that clearly. So I would support defining such a subtype and letting IANA to assign values.

Why create confusion on trying to define things like notification/ generic, etc. message?

Regards,

Behcet

----- Original Message ----
From: Ahmad Muhanna <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>; [email-masked]
Cc: Julien Laganier <[email-masked]>
Sent: Wednesday, May 28, 2008 4:11:11 PM
Subject: Re: [MEXT] Scope of generic notification

Hi Marcello,

I believe defining the scope of the Generic Notification Message is
important in order to avoid a very broad definition which could capture
all of the existing and future MH type messages.

IMO, the scope of the Generic Notification Message should be as follows:

"
A Notification Message of a simple event that is generic in nature and
does not cause an immediate change to the state of the mobile node BCE.
This also means that the notification message may indicate that the
receiving node needs to acknowledge/respond to the Notification message.
"

In order to help advancing the discussion, the above definition could be
used in a question form and people on the mailing list could:
positively, neutral or negatively support.

Cheers!

Regards,
Ahmad

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of marcelo bagnulo braun
> Sent: Wednesday, May 28, 2008 8:13 AM
> To: [email-masked]
> Cc: Julien Laganier
> Subject: [MEXT] Scope of generic notification
> 
> Hi all,
> 
> In our new charter we have a new item on a generic 
> notification mechanism. 
> During discussion over the last weeks, it seems to me that 
> the WG needs to make a decision about what is the scope of 
> the generic notification
> 
> In summary, we need to decide which is the scope of the 
> generic notification and what is the scope of the existing MH types.
> Essentially, what need to be as clear as possible are the 
> criteria for using the generic notification and which is the 
> criteria for using a MH type.
> 
> We would kindly ask the WG to comment on this, so we can make 
> a decision
> 
> Next, i include some background information about how i see 
> this, but feel free to completely ignore it.
> 
> I guess that one way to scope the generic notification, we 
> could first define what is the goal of the generic 
> notification. From Sri's draft, for instance, my 
> understanding is that the generic notification goal is to 
> allow a mean to provide asynchronous messages. (i am not sure 
> what asynchronous means in this context, but i assume that it 
> means not included in a BU/BA exchange??).
> 
> If that is the case, i don't see why we need this, since we 
> can always use another mobility header and define new 
> messages to be exchanged. 
> From Vijay's email, i understand that one of the goals is to 
> save MH types, since they are a scarce resource. That seems 
> reasonable. 
> Raj mentioned that Generic notification is to be used for non 
> critical things. Other mentioned that this should only be 
> used for send and discard things.
> 
> 
> Now, the next question then is when to use a new MH header 
> and when to use the generic notification. I think the generic 
> notification document needs to explicitly define its scope.
> 
> I guess that the elements that should be taken into account 
> for the definition of the scope are the message exchange 
> supported by the generic notification, the security mode, 
> others?. In the message exchange, the question is whether the 
> generic notification is just a notification, a notification 
> plus an ACK, reliable delivery (i.e. 
> retransmission till the sender receives an ACK), or a more 
> complex message exchange i.e. more than one message 
> retransmitted in each direction.
> 
> Now, one option would be to define the generic notification 
> so broad that it is a mere extension of the MH type, so that 
> we can encode more values in there, without much definition 
> of the message format.
> 
> Another option would be to define a query/response message 
> format and scope the generic notification to this type of 
> simple interactions.
> 
> A third option would be to define a reliable delivery, whith 
> tiemouts and retransmissions (slightly more complex than the 
> previous one)
> 
> Other options that support more complex message exchange 
> could also be conceived.
> 
> So, bottom line we need to clearly define the scope of the 
> generic notification and when to use MH types for extnesions. 
> This include the type of message exchange supported, the type 
> of information conveyed (critical or just infoormation), 
> security and so on. I think this is a high level disucssion 
> that the WG needs to have before we can move forward with the 
> generic notification and also with the binding revocation, 
> since once we define what is the scope of generic 
> notification and the MH type usage, we will be able to 
> conclude in which category the binding revocation falls.
> 
> Regards, marcelo
> 
> 
> 
> 
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext
> 
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 28 May 2008 18:17:17 -0500

Hi Behcet,
 
Actually, if the below scope is accepted, we probably do not need a new
subtype filed to be defined and consequently, Generic Notification and
Binding Revocation can advance in parallel using separate MH types.
Again, it is quite important not to overload a single message to achieve
many different functionalities.
 
Cheers!

Regards, 
Ahmad 

________________________________

	From: Behcet Sarikaya [mailto:[email-masked]] 
	Sent: Wednesday, May 28, 2008 6:09 PM
	To: Muhanna, Ahmad (RICH1:2H10)
	Cc: [email-masked]
	Subject: Re: [MEXT] Scope of generic notification

	If this is about MH Type defined in RFC 3775 as an 8-bit field
not being enough and that we need to define a MH Subtype, we should
state that clearly. So I would support defining such a subtype and
letting IANA to assign values.
	
	Why create confusion on trying to define things like
notification/ generic, etc. message?
	
	Regards,
	
	Behcet

	----- Original Message ----
	From: Ahmad Muhanna <[email-masked]>
	To: marcelo bagnulo braun <[email-masked]>; [email-masked]
	Cc: Julien Laganier <[email-masked]>
	Sent: Wednesday, May 28, 2008 4:11:11 PM
	Subject: Re: [MEXT] Scope of generic notification
	
	Hi Marcello,
	
	I believe defining the scope of the Generic Notification Message
is
	important in order to avoid a very broad definition which could
capture
	all of the existing and future MH type messages.
	
	IMO, the scope of the Generic Notification Message should be as
follows:
	
	"
	A Notification Message of a simple event that is generic in
nature and
	does not cause an immediate change to the state of the mobile
node BCE.
	This also means that the notification message may indicate that
the
	receiving node needs to acknowledge/respond to the Notification
message.
	"
	
	In order to help advancing the discussion, the above definition
could be
	used in a question form and people on the mailing list could:
	positively, neutral or negatively support.
	
	Cheers!

	Regards,
	Ahmad