Subject: Re: [MEXT] Scope of generic notification

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 28 May 2008 13:14:51 -0700 (PDT)

Hi Marcelo,
  Using the so-called generic notification mechanisms if we are defining some control messages then we need to define what these messages are for, i.e. message semantics. Once we do that we realize that they need to be in most cases defined in separate documents and hence they are no longer generic.
  My 2 cents.

Regards,

Behcet

----- Original Message ----
From: marcelo bagnulo braun <[email-masked]>
To: [email-masked]
Cc: Julien Laganier <[email-masked]>
Sent: Wednesday, May 28, 2008 8:12:48 AM
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

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Wed, 28 May 2008 20:28:19 -0400

Hi Vijay,

I am trying to understand the scope here.

AFAICT, Generic Notification is, as it says, for generic usage. I can
see it being useful in certain scenarios.

However, it does not specify message trigger, events and semantics of
the _specific_ protocol say between an HA and MN; it should not. If I
have a Request/Reply sequence, it is not clear how/why I might be able
to make use of this.. So, I am not sure why such a Request/Reply
protocol should use, if any, what is specified in the GN draft.
 
Thanks,

-Rajeev

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Vijay Devarapalli
> Sent: Wednesday, May 28, 2008 1:26 PM
> To: marcelo bagnulo braun; [email-masked]
> Cc: Julien Laganier
> Subject: Re: [MEXT] Scope of generic notification
> 
> Hello Marcelo,
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On
> > Behalf Of marcelo bagnulo braun
> 
> 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.
> I think we may have to go with case-by-case basis. It would be hard to
> set the criteria now.
> 
> Vijay

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Wed, 28 May 2008 20:47:08 -0400

> AFAICT, Generic Notification is, as it says, for generic usage. 

?? Not sure I follow. The way I see it, the generic notification message
is a container to carry different types of notifications messages
(identified by the Subtype field). What is "generic usage"??

> the _specific_ protocol say between an HA and MN; it should not. 

The trigger and the semantics of the notification message identified by
the "Subtype" field need to be specified as part of the protocol that is
using the generic notification message.

?> If I
> protocol should use, if any, what is specified in the GN draft.

If the "Request/Reply protocol" that you have in mind is trying to
convey something about an existing session, then you should be using the
generic notification message as the container.

Vijay

> "This email message and any attachments are confidential 
> information of Starent Networks, Corp. The information 
> transmitted may not be used to create or change any 
> contractual obligations of Starent Networks, Corp.  Any 
> review, retransmission, dissemination or other use of, or 
> taking of any action in reliance upon this e-mail and its 
> attachments by persons or entities other than the intended 
> recipient is prohibited. If you are not the intended 
> recipient, please notify the sender immediately -- by 
> replying to this message or by sending an email to 
> [email-masked] -- and destroy all copies of 
> this message and any attachments without reading or 
> disclosing their contents. Thank you."
>

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Wed, 28 May 2008 22:39:03 -0400

> (identified by the Subtype field). What is "generic usage"??

[RKo:>] I meant for generic notification purposes.

> using the generic notification message.

[RKo:>] That's okay. However, I see a concern wrt *scope*. What's the
defense against "why don't you just use Generic Notification"? 

> generic notification message as the container.

[RKo:>] This is exactly what I am concerned about. "Convey" is vague,
and could be interpreted non-uniformly. I don't think we need a
"framework" that everyone must follow. If there is something useful in
the spec, people will use it; we should not enforce.  

I am against making every protocol concerned with session management
follow the generic notification model (because, very briefly, it is very
hard to capture, let alone foresee, all the protocol requirements in a
"generic" ID, no pun intended).

-Rajeev

> > > From: [email-masked] [mailto:[email-masked]] On
Behalf

---

From: "Mohamed Khalil" <[email-masked]>
Date: Thu, 29 May 2008 10:42:44 -0500

Hi Marcelo,

[MK] I agree with this as a scope for Generic Notification.

Regards

Mohamed