Subject: [MEXT] Scope of generic notification

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 28 May 2008 15:12:48 +0200

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

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Wed, 28 May 2008 16:25:42 -0400

Hello Marcelo,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of marcelo bagnulo braun
 
> We would kindly ask the WG to comment on this, so we can make 

The generic notification draft should support all of the following

- A simple notification message which you just send and forget about it.
Does not affect the state of the binding cache
- A notification message that requires an ack. You re-transmit until you
get an ack or when you timeout
- A notification message that does affect the binding cache state
- Enable the use of IPsec protection for the notification message if
required

My understanding is that the current generic notification draft supports
all of the above. 

> things. 

I disagree with this.

> needs to explicitly define its scope.

I think we may have to go with case-by-case basis. It would be hard to
set the criteria now.

Vijay

---

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

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

> Sent: Wednesday, May 28, 2008 8:13 AM
> To: [email-masked]
> Cc: Julien Laganier
> Subject: [MEXT] Scope of generic notification
> 
> Hi all,
> 
> 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.
> 
> 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
> 
> 
> 
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 29 May 2008 00:14:34 +0200

Hi Vijay,

thank you for the input

Vijay Devarapalli escribió:
>> the WG needs to 

so, are you saying that any new functionality that uses this type of 
message exchange should use the generic notification and not a new MH?

>> critical 
>> and when to 
I find this hard to accept
I mean, how are going to decide later? based on what if we don't define 
a criteria? It should be possible to at least provide some guidance on 
this. I am not saying we can define an selection algorithm, but some 
guidance must be provided imho

In other words, i guess you do have some abstract gut feeling on when to 
use one and when to use the other one. this basically relies on some 
conception of what the scope of the generic notification is. My proposal 
is to try to make the excersise to state this ideas explicltly, so we 
can all agree on this. I mean, past disucssion seems to show to me that 
different people have very different ideas on what the generic 
notification should be used for. Just specifying the format will not 
solve this confusion and would result in problems in the future, since 
people have different conception on this. We are better off if we state 
the applicability of the generic up front now and include it in the document

regards, marcelo

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Wed, 28 May 2008 18:33:54 -0400

> message exchange should use the generic notification and not a new MH?

No. The generic notification message would support all of the above.
Applications that make use of the generic notification message can
decide whether they want an explicit acknowledgement (for example by
setting the 'ack' flag) or IPsec protection (for example by having the
SPD entries configured).

> use one and when to use the other one. 

Right.

> this basically relies on some 
> can all agree on this. 

Ok, I will bite. How about the following for the criteria?

- The generic notification message can be used anytime you want to
indicate/convey/modify something related to an existing session. Here I
am assuming that a session corresponds to one instance of a binding
cache entry for a particular mobile node.

- The generic notification message can be used to trigger another node
to setup a session. This would mean the trigger is sent to the recipient
(mobile node or a MAG) to send a binding update (or a proxy binding
update) and setup a session.

Vijay

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 29 May 2008 02:20:01 +0200

Hi Marcelo and all,

On 2008-05-28 15:12 marcelo bagnulo braun said the following:
...
> category the binding revocation falls.

I'm going to be a bit contrary here, as follows:

I would expect the binding revocation to be a poster child, an excellent
excellent example of something we know we want to do, which ought to fit
well within a generic notifiation mechanism.

If it is the case that the generic notification mechanism as currently
proposed doesn't suit this use case, I think it's quite wrong to try to
work out the scope of the current mechanism, and then decide whether it
is suitable for binding revocation; what should be done is to look again
at the proposed generic notification mechanism and see what it really
should look like in order to be well suited to carry the binding revocation.

If we have a notification mechanism which isn't suited for our primary
example of a needed and wanted notification (the binding revocation), we
can hardly call it generic, can we?

	Henrik

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 28 May 2008 23:21:40 -0500

Hi Vijay,

Please see inline.

Regards,
Ahmad

> Applications that make use of the generic notification 
> message can decide whether they want an explicit 
> acknowledgement (for example by setting the 'ack' flag) or 
> IPsec protection (for example by having the SPD entries configured).

[Ahmad]
Hmmm..
How would all of the above be supported in a single shot?
For example, how would this generic notification mechanism support the
first very simple usecase "A simple notification message which you just
send and forget about it", for example, your prepaid balance is $25.09.
which MAY NOT require IPsec protection while at the same time support
usecase 2 Which impact the BCE and require IPsec protection, while both
use the same MH type?

> 
> > >> 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 mean, how are going to decide later? based on what if we don't 
> > define a criteria? It should be possible to at least provide some 
> > guidance on this. I am not saying we can define an selection 
> > algorithm, but some guidance must be provided imho
> > 
> > In other words, i guess you do have some abstract gut 
> feeling on when 
> > to use one and when to use the other one.
> 
> Right.
> 
> - The generic notification message can be used anytime you 
> want to indicate/convey/modify something related to an 
> existing session. Here I am assuming that a session 
> corresponds to one instance of a binding cache entry for a 
> particular mobile node.
> 
> - The generic notification message can be used to trigger 
> another node to setup a session. This would mean the trigger 
> is sent to the recipient (mobile node or a MAG) to send a 
> binding update (or a proxy binding

[Ahmad]
On one hand, you said that "this should be addressed in a case-by-case
because it would be hard to set the criteria now". In other words, you
probably meant to say that it would be very difficult to capture the
scope of this generic notification mechanism and its limitations at the
present time. On the other hand, you just presented this very generic
and broad scope that made me think it would be easier if you specify
what has been left out. What I mean, if you define for us what is not
included, we probably would understand what is included in this scope
and luckily would be able to interpret what "indicate/convey/modify" and
their combinations mean.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 29 May 2008 13:17:19 +0200

Henrik Levkowetz escribió:
>> 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.
>

Well, actually, my question is even one step before that.
First of all, i am not talking about any generic notification draft, 
just wnat to understadn what is the idea people have in mind when they 
talk about generic notification.

You seem to have a clear idea, since you think that the binding 
revocation is one partcular case of generic notification, is that right?

I was not even assuming that, (not that i have a problem with neither) 
just want to understand what the scope of a generic notification should be

So, what is the idea that you have about the generic notification that 
makes you think that the binding revocation should fit in there?
> can hardly call it generic, can we?
I fully agree with this, but i before that, i would like to agree on 
what is the scope of the generic notification and when nw MH types 
should be used.

Once we have a clear view on the scope of each one, then we can see if 
the binding revocation fits in the the generic notification scope or in 
the new MH type scope, makes sense?

regards, marcelo

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 29 May 2008 15:16:34 +0200

Hi Marcelo,

> makes you think that the binding revocation should fit in there?

Starting from the most basic idea, registration requests are initiated
by the mobile node, to update a state at the home agent (and potentially
the communicating nodes, but that's a refinement).  Notifications are
initiated by the home agent (and possibly other nodes, but that's a
refinement) to update state at the mobile node (and possibly other nodes,
but again that's a refinement).

So a generic notification mechanism provides a complement to the reg.
requests which makes it possible for other nodes than the mobile node
to _initiate_ communication, rather than having to wait for the mobile
node to do so.

> what is the scope of the generic notification and when nw MH types 

Here you seem to assume that a generic notification mechanism doesn't
use the MH.  I don't necessarily see it that way.

> the new MH type scope, makes sense?

Nope.  You still assume that there are two mechanisms; I think that's not
a situation I'd prefer to have.  If we are going to use MH (which I strongly
wish we hadn't defined at all in the first place) then maybe a notification
mechanism should use the MH also.  Things should be as simple as possible,
but not simpler.  Two communication mechanisms instead of one is already
a noticeable complication.  Maybe it's offset by other simplicities, but
I would prefer not to start off with an assumption that there has to be
two.

	Henrik

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 29 May 2008 15:37:52 +0200

Henrik Levkowetz escribió:
>>>> 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 
>> just wnat to understadn what is the idea people have in mind when 
>> they talk about generic notification.
>>
>> I was not even assuming that, (not that i have a problem with 
>> neither) just want to understand what the scope of a generic 
>> notification should be
>>
>> So, what is the idea that you have about the generic notification 
>> that makes you think that the binding revocation should fit in there?
>

so basically for you, any communication that is not initiated by the MN 
should use the generic notification, is that correct?

If that is the case, then it seems a quite well defined scope for 
generic notification to me...

> use the MH.  I don't necessarily see it that way.
I may have phrased this in the wrong way.

I assume that the generic notification will use one MH type for econding it.

But once that we have defined the generic notification with a given MH 
type assigned to it, then for any new message that we want to exchange 
we then have the option or either using the generic notification or to 
use a new MH type for this.

My question is then when to use the generic notification (with the MH 
type assigned to the generic notification) and when to use a new MH 
type, makes sese now or am i still missing something?

>
>> Once we have a clear view on the scope of each one, then we can see 
>> if the binding revocation fits in the the generic notification scope 
>> or in the new MH type scope, makes sense?
>
I don't think i udnerstand your point here.

I assume that when you need to define a new information that you want to 
signal between MIPv6 entities, you will have the option of using a new 
MH type for doing it, or to use the generic notification. What is the 
assumption that i am making that could be omited?

Regards, marcelo

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 29 May 2008 15:47:43 +0200

Hi Marcelo,

...
> generic notification to me...

Ok, good.

> I assume that the generic notification will use one MH type for econding it.

Aha.  That wasn't clear to me.  Ok.

> use a new MH type for this.

Umm... Yes.  But if we have to use a new MH type for a communication between
peers where the generic notification mechanism is available, that would likely
indicate a failure in designing the generic notification mechanism, no?

> type, makes sese now or am i still missing something?

No, I think I got you now.  But to me that would mean that if you have to
use a new MH type because the generic notification mechanism won't work,
then you have failed to define the generic notification mechanism
appropriately.

If you wish to use a new MH type because the semantics is fundamentally
different than what's been envisaged for the generic notification, that's
fine.  I have a hard time seeing that applying to binding revocation,
though...

> assumption that i am making that could be omited?

I think I understand you better now, so maybe none -- except for the
reservation noted earlier (above) about not being able to use the
generic notification if it's available being a design failure indication.

Best,

	Henrik

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 29 May 2008 09:11:48 -0500

Hi Henrik,
Please see inline.

Regards,
Ahmad

> Behalf Of Henrik Levkowetz
> Sent: Thursday, May 29, 2008 8:17 AM
> To: marcelo bagnulo braun
> Cc: Julien Laganier; [email-masked]
> Subject: Re: [MEXT] Scope of generic notification
> 
> Hi Marcelo,
> 
> >> I would expect the binding revocation to be a poster child, an 
> >> excellent excellent example of something we know we want 
> to do, which 
> >> ought to fit well within a generic notifiation mechanism.
> > 
> Starting from the most basic idea, registration requests are 
> initiated by the mobile node, to update a state at the home 
> agent (and potentially the communicating nodes, but that's a 
> refinement).  Notifications are initiated by the home agent 
> (and possibly other nodes, but that's a
> refinement) to update state at the mobile node (and possibly 
> other nodes, but again that's a refinement).
> 
> requests which makes it possible for other nodes than the 
> mobile node to _initiate_ communication, rather than having 
> to wait for the mobile node to do so.

[Ahmad]
It seems that you are using MIP4 terminologies here, but that is fine as long as we take it in the context of MEXT.
Looking at the paragraph above, I have the following comments/questions:

1. It seems to me that there is something missing. How a generic notification MECHANISM is complement to reg. requests?

2. In order to understand this a little better, could you explain what is "generic"? , i.e. message, the mechanism, etc. 

3. Why we need to call it notification, is there anything specific to this name for example?

> 
> >> If it is the case that the generic notification mechanism as 
> >> currently proposed doesn't suit this use case, I think it's quite 
> >> wrong to try to work out the scope of the current 
> mechanism, and then 
> >> decide whether it is suitable for binding revocation; what 
> should be 
> >> done is to look again at the proposed generic notification 
> mechanism 
> >> and see what it really should look like in order to be 
> well suited to 
> >> carry the binding revocation.
> >>
> >> If we have a notification mechanism which isn't suited for our 
> >> primary example of a needed and wanted notification (the binding 
> >> revocation), we can hardly call it generic, can we?
> >>
> Here you seem to assume that a generic notification mechanism 
> doesn't use the MH.  I don't necessarily see it that way.
> 
> > the binding revocation fits in the the generic notification 
> scope or 
> > in the new MH type scope, makes sense?
> 
> Nope.  You still assume that there are two mechanisms; I 
> think that's not a situation I'd prefer to have.  If we are 
> going to use MH (which I strongly wish we hadn't defined at 
> all in the first place) then maybe a notification mechanism 
> should use the MH also. 

[Ahmad]
It seems that you think that "generic" and "notification" refer to the mechanism rather than the message. Is that true?

> Things should be as simple as 
> possible, but not simpler.  Two communication mechanisms 
> instead of one is already a noticeable complication.  

[Ahmad]
Please correct me if I am wrong. It seems to me here that what you have in mind, as you probably mentioned earlier, as the primary target for your understanding of the generic notification mechanism, is binding revocation. Please note, I used "mechanism" here to be consistent of what I understood from what you said. If that is not accurate please let me know.

> Maybe 
> it's offset by other simplicities, but I would prefer not to 
> start off with an assumption that there has to be two.
> 
> 
> 	Henrik
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 29 May 2008 16:23:45 +0200

> indicate a failure in designing the generic notification mechanism, no?
well, it depends on what do you think it is scope for generic 
notification hence this discussion.

You can envisage that generic notification is only for non reliable 
delivery of information. So, you can scope it that way, and the it is 
very clear: any information flowing from the HA that needs no reliable 
ddelivery, you should use generic notification. Else you should use a 
new MH type. (that is merely an example)

OTOH, you can define the scope being much broader, that i think is what 
you have in mind i.e. any information cnoveyed from the HA to the MN 
should use the generic notification. New MH types are reserved for 
information sent from the MN i guess then. We should then define the 
generic notification format in a much more general way, that can 
accomodate all kind of message exchange initiated by the HA and all king 
of security and so on.

I understand that your preference is that the generic notiication 
emssage should be able to accomodate any information exchange initiated 
by the HA, is that correct?

I am perfectly ok with any of these or other options. My only point is 
that the WG should define what the scope of the generic notification is

> fine.  I have a hard time seeing that applying to binding revocation,
I would leave the binding revocation discussion out of this for now. 
Once we agreed on what the scope of the generic notification should be, 
it should be fairly easy to understand if the binding revocation should 
use it or not i guess

>>>> if the binding revocation fits in the the generic notification 
>>>> scope or in the new MH type scope, makes sense?
>> I assume that when you need to define a new information that you want 
>> to signal between MIPv6 entities, you will have the option of using a 
>> new MH type for doing it, or to use the generic notification. What is 
>> the assumption that i am making that could be omited?
>

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 29 May 2008 17:45:13 +0200

Hi Marcelo,

> by the HA, is that correct?

No, I think I've still not quite managed to get across what I'm trying
to say.  I'm not advocating any specific property of the generic notification
mechanism, except that it should be generic.  I'm advocating that it should
(in addition to being somewhat generic) be *useful* for the use case (or
cases) we know about today.  More below.

> it should be fairly easy to understand if the binding revocation should 

No no no.  This is the point.  We can define a beautiful mechanism
which could be useless, or only useful for things which isn't really
needed by anybody.  I don't think that's what we should do, though.

How many specific examples do we have of proposed messages with real
deployment needs behind them?

Discussing the properties of a message mechanism out of context of the
specific examples which we know are needed today may lead to a beautiful
but useless design.  Discussing the properties of the message mechanism
in the context of known use cases is vital, in order to get something with
a reasonable chance of actually being appropriate and useful.  Divorcing
the generic notification mechanism from the most obvious potential use
case for the mechanism doesn't make sense to me.

Regards,

	Henrik

---

From: ariel silverstone <[email-masked]>
Date: Thu, 29 May 2008 12:18:38 -0400

To me, the following comment below is key:

"
>> though..."

1) I believe it should stay generic, unless we are aiming to solve a problem so different that we need to create what would become a new standard.
2) We should do something that is extensible - in this context I mean that we will have an option to set a flag to refer to another field.
3) This inline (vs. out of band) discussion is not atypical to all communications format.  When I think of the use cases, especially by network devices, I believe we should stick with the inline option.

Ariel Silvestone

> Date: Thu, 29 May 2008 17:45:13 +0200
> From: [email-masked]
> To: [email-masked]
> CC: [email-masked]; [email-masked]

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 29 May 2008 11:32:31 -0500

Hi Henrik,

Allow me to jump in to address some of your comments/concern.

Regards,
Ahmad

> > emssage should be able to accomodate any information exchange 
> > initiated by the HA, is that correct?
> 
> No, I think I've still not quite managed to get across what 
> I'm trying to say.  I'm not advocating any specific property 
> of the generic notification mechanism, except that it should 
> be generic.  I'm advocating that it should (in addition to 
> being somewhat generic) be *useful* for the use case (or

[Ahmad]
Until the scope of that generic mechanism is quite understood and
documented, we need to move forward. As many people already mentioned,
there is a sensitive 3GPP Rel-8 dependency on draft,
http://www.ietf.org/internet-drafts/draft-muhanna-mext-binding-revocatio
n-01.txt, I guess it is hard to believe that this work needs to be
delayed until people define the specific properties of such generic
mechanism.

> > Once we agreed on what the scope of the generic notification should 
> > be, it should be fairly easy to understand if the binding 
> revocation 
> > should use it or not i guess
> 
> No no no.  This is the point.  We can define a beautiful 
> mechanism which could be useless, or only useful for things 
> which isn't really needed by anybody.  I don't think that's 
> what we should do, though.
> 
> How many specific examples do we have of proposed messages 
> with real deployment needs behind them?
> 
> Discussing the properties of a message mechanism out of 
> context of the specific examples which we know are needed 
> today may lead to a beautiful but useless design.  

[Ahmad]
That is why there is a defined scope for the Binding revocation which
has been captured as a MEXT wg item and addressed by the draft-muhanna.
Do you see any problem with the proposed mechanism or the way Revocation
is defined and addressed in that draft? 

> Discussing 
> the properties of the message mechanism in the context of 
> known use cases is vital, in order to get something with a 
> reasonable chance of actually being appropriate and useful. 

[Ahmad]
Hmmm... This is exactly the problem that this thread is trying to
resolve with this "generic" notion.
We have a well defined usecases for Binding Revocation that have been
identified and addressed already by draft-muhanna. On the other hand,
you seem to suggest that we need to define a mechanism that is "generic"
but yet has an "unknown scope" which in addition can address other
"unknown usecases" which could be defined in the future and share some
semantics of such generic mechanism.

Does that make any sense?

> Divorcing the generic notification mechanism from the most 
> obvious potential use case for the mechanism doesn't make sense to me.
> 
> 
> Regards,
> 
> 	Henrik
>

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Thu, 29 May 2008 13:50:47 -0400

> How would all of the above be supported in a single shot?

The current generic notification draft does support all of the above.

> usecase 2 Which impact the BCE and require IPsec protection, 

In this case, you are right. Even if one notification message requires
IPsec protection, you would end up using IPsec protection on all
notification messages. I don't necessarily see that as a bad thing,
though. 

Vijay

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 29 May 2008 20:03:06 +0200

> deployment needs behind them?
Does anyone has some input on this question?

Regards, marcelo

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 29 May 2008 14:10:01 -0500

> > first very simple usecase "A simple notification message which you 
> > just send and forget about it", for example, your prepaid 
> balance is 
> > $25.09.
> > usecase 2 Which impact the BCE and require IPsec protection, while 
> > both use the same MH type?
> 
> In this case, you are right. Even if one notification message 
> requires IPsec protection, you would end up using IPsec 
> protection on all notification messages. I don't necessarily 
> see that as a bad thing, though. 

[Ahmad]
Thanks.

But this is a gainst the basic concept of getting a broad and generic
mechanism that is able to address all of the above. I disagree. This is
a restriction that defeat the purpose of the notion of a generic
mechanism that is flexible enough to satisfy all the different usecases
needs. IPsec is good when it is required.

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Thu, 29 May 2008 15:37:36 -0400

> From: Ahmad Muhanna [mailto:[email-masked]] 
> Sent: Thursday, May 29, 2008 12:10 PM
> To: Vijay Devarapalli; marcelo bagnulo braun
> Subject: RE: [MEXT] Scope of generic notification
> 
> > > 
> > > [Ahmad]
> > > Hmmm..

You are mixing up stuff. I was talking about the posibility of using the
generic notification message with or without IPsec protection. The
current draft supports both. You are talking about being able to send
two separate generic notifications messages at the same time, one with
and other without IPsec protection. I agree this is not possible
currently, since we only have the MH Type as the selector, and not the
subtype field in the generic notification message. 

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 29 May 2008 15:32:21 -0500

> Does anyone has some input on this question?

Hi Marcello,
Please let me address this question as follows:

I am not sure if this question relevant to this scope definition.

On one hand, we are not able to agree on the Generic Notification mechanism scope because we do not have a full understanding of this mechanism to start with, nonetheless to come up with all of its usecases. On the other hand, if people think that there is not many messages out there that require a real deployment need, then why all of this debate about protection the MH type field and why not allowing the use of different MH types as needed?

Moreover, I would tend to say that the more appropriate question is to understand what is the real deployment need for such "Generic Notification Mechanism" and if there is any dependency on it out there? That is probably a more relevant question, IMO.

Regards,
Ahmad

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 29 May 2008 15:44:40 -0500

> You are 
> talking about being able to send two separate generic 
> notifications messages at the same time, one with and other 
> without IPsec protection. I agree this is not possible 
> currently, since we only have the MH Type as the selector, 
> and not the subtype field in the generic notification message. 

[Ahmad]
Okay. IMO, this is not a good thing and against the basic claim of
having a mechanism that is being generic.
But I guess we are not far a part, you categorized it as "that is not a
bad thing:)

---

From: "Benjamin Lim" <[email-masked]>
Date: Fri, 30 May 2008 12:08:49 +0800

Hi,
 
My $0.02 take on this discussion.

To me, the purpose of the generic notification draft seems to try to
preserve the scarce resource of MH type we have (though I seriously do not
think we have even utilized around 10% of the MH type, but preparing early
is always a good thing)
 
If that is the case, then the scope of the generic notification draft is
very clear cut. To define a format to allow future notification messages to
be extended into it. 
For example,
 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Proto |  Header Len   |   MH Type     |   Reserved    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Checksum            |   Notify type     |     Notify Len       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
.
.
.                       Message Data
.
.
.
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
In this case, future notification messages would just use this template in
generic notification to define their specific action. For example, binding
revocation will define the notification type, length and whatever message
data (BRI, BRA) for the use of revoking bindings.
 
I believe a simple format like this should not take more than a month to get
it into the standard tracks in order not to delay the current revocation
draft (since there is an industrial dependency on this draft at the moment).
 
Further, on the question posted below,
 
> Does anyone has some input on this question?
 
Offhand, one example I can think of is that operators might have preferences
for a multi-interface MN to send its signaling message over specific
interface base on the link condition at the HA. I.e. HA notifies MN to use
3G link to send all control messages (e.g. BU) as MN's WLAN link is
currently unstable.
 
Regards,
Benjamin Lim 

> Sent: Wednesday, May 28, 2008 9:13 PM
> To: [email-masked]
> Cc: Julien Laganier

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 30 May 2008 08:09:36 +0200

Vijay Devarapalli escribió:
>>> The current generic notification draft does support all of 
>>>       
>> the above.
>>     
>>>> For example, how would this generic notification mechanism 
>>>>         
>>> support the 
>>>       
>>>> first very simple usecase "A simple notification message 
>>>>         
>> which you 
>>     
>>>> which MAY NOT require IPsec protection while at the same 
>>>>         
>>> time support 
>>>       
>>>> usecase 2 Which impact the BCE and require IPsec 
>>>>         
>> protection, while 
>>     

But, i think the scope of discussion is not apropriate. I mean, 
limitations of exisitng drafts are not relevant, since we don't have a 
WG document yet for none of the items, so, if we think there is some 
functionality is needed, and if this functionality is possible, we will 
certainly find people to write it down on a draft

So, the discussion should not be about what existing draft support or 
not, but what can be actually done in general

So, for me the questions are:
- would a generic notification mechanism need to send both IPSec 
protected and non protected messages at the same time?
- if yes, is it possible to build this?

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 30 May 2008 08:15:15 +0200

Hi Ahmad,

Ahmad Muhanna escribió:
>> with real 
i guess there is a need cause the WG has decided that we needed to work 
on this.

i would expect that people that have supported working on this has a 
clear view on what this is needed for and what are the use cases.

regards, marcelo

---

From: Julien Laganier <[email-masked]>
Date: Fri, 30 May 2008 10:59:20 +0200

Hello Ahmad,

On Thursday 29 May 2008, Ahmad Muhanna wrote:
> > No. The generic notification message would support all of the
> > above. Applications that make use of the generic notification
> For example, how would this generic notification mechanism support
> the first very simple usecase "A simple notification message which
> you just send and forget about it", for example, your prepaid balance
> is $25.09. which MAY NOT require IPsec protection while at the same
> time support usecase 2 Which impact the BCE and require IPsec
> protection, while both use the same MH type?

For this specific issue, a simple solution would be for the generic 
notification mechanism to use two MH types, one for which SPD requires 
IPsec, and one for which the SPD allows bypassing IPsec.

--julien

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 30 May 2008 07:48:22 -0500

Hello Julien,
Please se inline.

Regards,
Ahmad

> From: julien laganier [mailto:[email-masked]] On 
> Behalf Of Julien Laganier
> Sent: Friday, May 30, 2008 3:59 AM
> To: Muhanna, Ahmad (RICH1:2H10)
> Cc: Vijay Devarapalli; marcelo bagnulo braun; [email-masked]
> message can 
> > > setting the 'ack' flag) or IPsec protection (for example 
> by having 
> > > the SPD entries configured).
> >
> > [Ahmad]
> > Hmmm..
> > $25.09. which MAY NOT require IPsec protection while at the 
> same time 
> > support usecase 2 Which impact the BCE and require IPsec 
> protection, 
> For this specific issue, a simple solution would be for the 
> generic notification mechanism to use two MH types, one for 
> which SPD requires IPsec, and one for which the SPD allows 
> bypassing IPsec.
[Ahmad]

I understand this to mean that the simple Notification message "No
response is required" would have a MH type different than the more
complex notification message "which may impact the BCE". That will do
it. In this case, I assume that these two MH types messages can be
handled separately. 

Thanks.

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 30 May 2008 08:15:19 -0500

Hi marcelo,

> > On one hand, we are not able to agree on the Generic 
> Notification mechanism scope because we do not have a full 
> understanding of this mechanism to start with, nonetheless to 
> come up with all of its usecases. On the other hand, if 
> people think that there is not many messages out there that 
> require a real deployment need, then why all of this debate 
> about protection the MH type field and why not allowing the 
> use of different MH types as needed?
> >
> > Moreover, I would tend to say that the more appropriate 
> question is to understand what is the real deployment need 
> for such "Generic Notification Mechanism" and if there is any 
> dependency on it out there? That is probably a more relevant 
> question, IMO.
> >
> >   
> i guess there is a need cause the WG has decided that we 
> needed to work on this.
> 
> i would expect that people that have supported working on 
> this has a clear view on what this is needed for and what are 
> the use cases.
[Ahmad]
I agree.

Actually I am one of those who supported and still do support the generic notification message work item. At the time, my understanding and the understanding of many others of the scope was what I mentioned earlier. A mechanism to communicate a simple event which does not immediately impact the state of the BCE. It also was in the scope to allow the sender to request the receiver for a response or an ack.

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 30 May 2008 08:24:25 -0500

Hi Marcelo,

> 
> But, i think the scope of discussion is not apropriate. I 
> mean, limitations of exisitng drafts are not relevant, since 
> we don't have a WG document yet for none of the items, so, if 
> we think there is some functionality is needed, and if this 
> functionality is possible, we will certainly find people to 
> write it down on a draft
> 
> So, the discussion should not be about what existing draft 
> support or not, but what can be actually done in general
> 
> - would a generic notification mechanism need to send both 
> IPSec protected and non protected messages at the same time?

[Ahmad]
Yes. I see this as a valid scenario.

> - if yes, is it possible to build this?
[Ahmad]
The sky is the limit:) Yet, another selector to be standardized and
defined to allow SPD IPsec to be configured and enforced using the
subtype field. An unnecessary complication that, IMO, not needed. In
other words, Is it worth the effort, I believe it is not.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 30 May 2008 15:52:19 +0200

> Actually I am one of those who supported and still do support the generic notification message work item. At the time, my understanding and the understanding of many others of the scope was what I…
I think Henrik is asking for much more concrete use cases than this one, 
i.e. what actual functionality you have in mind for this... people have 
talked about notification about prepaid status and so on. I guess that 
is what Henrik is asking for

thanks, marcelo

---

From: Brian Haley <[email-masked]>
Date: Fri, 30 May 2008 10:11:21 -0400

>> which SPD requires IPsec, and one for which the SPD allows 

I was about to send the same response, using two MH types seems like a 
good solution to me.

> it. In this case, I assume that these two MH types messages can be

I don't think we should restrict what you consider a simple notification 
message to one MH type or another.  We can use the same sub-types in 
either message, but obviously some messages must use IPsec as you said.

-Brian

---

From: Julien Laganier <[email-masked]>
Date: Fri, 30 May 2008 16:26:13 +0200

Hello Ahmad,

> it. In this case, I assume that these two MH types messages can be

Just to make sure: what I meant is that differentiation between 
notification messages requiring IPsec and those who don't can be based 
on using two different MH types. As for differentiation between 
notification messages of type "No response is required" vs. "which may 
impact the BCE", that can be handled via the notification message 
subtype.

Regards.

--julien

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 30 May 2008 09:29:48 -0500

Hi Brian,

> >> notification mechanism to use two MH types, one for which SPD 
> >> requires IPsec, and one for which the SPD allows bypassing IPsec.
> 
> I was about to send the same response, using two MH types 
> seems like a good solution to me.
> 
> > [Ahmad]
> > 
> I don't think we should restrict what you consider a simple 
> notification message to one MH type or another.  We can use 
> the same sub-types in either message, but obviously some 
> messages must use IPsec as you said.

[Ahmad]
I was merely using that as an example. But I agree. 

Thanks.

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 30 May 2008 09:34:33 -0500

Hi Julien,

> Just to make sure: what I meant is that differentiation 
> between notification messages requiring IPsec and those who 
> don't can be based on using two different MH types. As for 
> differentiation between notification messages of type "No 
> response is required" vs. "which may impact the BCE", that 
> can be handled via the notification message subtype.

[Ahmad]
Thanks for the clarification. Agreed.

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 30 May 2008 09:41:51 -0500

Hi Marcelo,

> >> understanding of this mechanism to start with, nonetheless 
> to come up 
> >> with all of its usecases. On the other hand, if people think that 
> >> there is not many messages out there that require a real 
> deployment 
> >> need, then why all of this debate about protection the MH 
> type field 
> >> and why not allowing the use of different MH types as needed?
> >>     
> for such 
> >> "Generic Notification Mechanism" and if there is any 
> dependency on it 
> >> out there? That is probably a more relevant question, IMO.
> >>     
> >>>   
> >>>       
> >> i guess there is a need cause the WG has decided that we needed to 
> >> work on this.
> >>
> this has a 
> > Actually I am one of those who supported and still do 
> support the generic notification message work item. At the 
> time, my understanding and the understanding of many others 
> of the scope was what I mentioned earlier. A mechanism to 
> communicate a simple event which does not immediately impact 
> the state of the BCE. It also was in the scope to allow the 
> sender to request the receiver for a response or an ack.
> >
> >
> >   
> I think Henrik is asking for much more concrete use cases 
> than this one, i.e. what actual functionality you have in 
> mind for this... people have talked about notification about 
> prepaid status and so on. I guess that is what Henrik is asking for

[Ahmad]
It may be not the best day for me to come up with usecases:)
However, as you mentioned the prepaid was one of the usecases that we
discussed. I am sure others can identify more usecases.

---

From: "Sri Gundavelli" <[email-masked]>
Date: Fri, 30 May 2008 10:03:23 -0700

Catching up on this thread bit late ...

Hi Marcelo,

What is the scope of a Generic Notification Message ?

Any events exchanged by the mobility entities during a mobility
session (after the session is setup and when there is a relation),
Generic Notification message can be used for exchanging those
events.

What is the benefit ? If we define a common frame work, exchange
semantics, transport, security, retransmissions in one place,
all events merely use this mechanism and define the data want to
exchange and specify the receiver action. Their work can focus on
the application semantics and not on how the events are exchanged.

Lets look at the impact of this on Firewall drafts. For each MH type,
firewall filter def will change. If we keep this contained to
Generic Notification draft, all the events related to a mobility
session and exchanged during a session, can all use this framework
and no change on that aspect.

Lets look at the security considerations, now we need to define SPD
and PAD entries for each MH type. We can avoid all of this, if the
Revocation or other events, simply use this mechanism.

SDO bodies like 3GPP can allocate on of the subtype from this 
numbering space and can focus on the application data and with out
getting into the details of transport semantics.

Mobile IPv4 has adopted Generic Notification draft and the general
direction as I understand is to use this for new events.

Bottom line, the scope of the Notification draft is

- Exchange of events related to a mobility session and during a
  mobility session. 

- Use of new MH types for new events should be allowed, only if the
  Generic Notification draft is not sufficient or has limitations
  to support those event semantics. If there is a good reason, sure.

In general this should be sufficient for all events. But, if some
one desperately wants to use a new MH type for their event and for
what ever reason, that's fine. Just that the document will bloat in
size, it will have to address all the security, firewall and
transport semantics.

Sri

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 30 May 2008 21:06:08 +0200

Hi Sri,

So, your view is that the generic notification should be as general as 
possible and should be able to support reliable delivery, message 
exchange from the HA and from the MN or for any other party involved, 
with different type of security (IPSec protected and non IPSec 
protected), for critical and for non critical things and so on?

Regards, marcelo

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 30 May 2008 13:56:23 -0700 (PDT)

Hi Marcelo,

Yes. It should provide all the general semantics required for
mobility entities to exchange events associated with the
established mobility session.

Regards
Sri

On Fri, 30 May 2008, marcelo bagnulo braun wrote:

> possible and should be able to support reliable delivery, message exchange 
> from the HA and from the MN or for any other party involved, with different 
> type of security (IPSec protected and non IPSec protected), for critical and 
> for non critical things and so on?
>
> Regards, marcelo
>
>
> Sri Gundavelli escribió:
>> >  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
>> > 
>>  SDO bodies like 3GPP can allocate on of the subtype from this numbering
>>  space and can focus on the application data and with out