Subject: [MEXT] An unanswered question about "MIPv6 Generic Signaling Message" (MGSM)

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 14 Jul 2008 09:25:52 -0700

Hello folks,

A while back, I asked the following question:

> Could you provide some examples of messages that
> would NOT fit as subtypes of  the proposed generic
> signaling message?

Does anyone have an answer to this question?  I feel like I must be
missing some basic point here.

Thanks in advance,
Charlie P.

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

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 21 Jul 2008 15:07:09 -0700

Hello again folks,

Apparently, any message could fit as a subtype
of the proposed generic signaling message.

This means that the proposal is too generic.

I can't see any justification for this, given that
so few of the basic message types have been
used.  There is no real indication that we are
ever going to run out.

If we had used 100 or even 50 of the message
types already, I could see some justification
for this extraordinarily generic approach.  As it
is, I think we ought to continue to utilize the
basic message type space, and avoid the
message overhead and the complication of
yet another subtype space.

Does anyone have any comparable example
from another working group, where there
was a desire to create a completely generic
message type with subtypes, when the basic
type numbering space was hardly touched?

Regards,
Charlie P.

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 21 Jul 2008 15:54:27 -0700 (PDT)

Hi Charlie,

There is a long thread on this topic and was discussed
in the WG extensively prior to entering this work into
the charter. Few points:

- Its not just about saving MH Types. That is a very
minor aspect.

- The goal is to create a message that can be used
for different event types. All the considerations related
to transport, session identification, firewall considerations,
security considerations, IPv4/NAT traversals ..etc, all
should be specified just for this message and all of this
apply to all the events.

- Any new message has to only define the reciever
actions for that specific message, without the need
to define any of the above considerations for each
and every message.

- There was a recent discussion on the validity of the
Auth Option in a message other than a BU/BA and it
was considered not valid. Defining new options for a
MGSM message will allow its use for all events.

- It appears this is just about saving MH types, its
not. When we start defining a new event, that draft
has to deal with all the above considerations. If
that event leverages the Generic Notification work,
the focus of the draft is contained to the event
details and sender/receiver considerations. If we can
see the flow

  Session is created
   Event-1
   Event-2
  Session is terminated

All those events associated within a session have common
properties, there is no reason to float new messages,
there is some value in using this generic message.

Hope this helps.

Regards
Sri

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 22 Jul 2008 11:23:28 -0700

Hello Sri,

Your message caused me to go back and re-read a
LOT of messages on this subject.  Eventually, I had to
stop before getting through all of them.  It's a challenging
assignment, which I reckon few people would complete.

Nevertheless I got a very good feel for the main ideas.
Your message seemed to indicate that my concerns had
already been discussed and were missing the point of
the MGSM draft.  I did find some messages in support
of that position, but I found quite numerous messages with
general questions about the approach.  So in my mind
the question is really not at all settled.

Furthermore, the IPv6 draft I was able to find has
expired.  Maybe there is another one that I did not
find yet.  Or, maybe your comments were really more
oriented towards the IPv4 version of the draft.

> should be specified just for this message and all of this

Those considerations are not covered in the IPv6
draft.  But, what the heck, let's just assume that they
could be.  But, on the other hand, they are not
covered in the IPv4 document either.  Actually,
it seems that the transport considerations are limited
to retransmissions, and only the IPv6 document
has that.  Or, maybe you intended some of them
to be covered implicitly by enabling the use of
certain mobility extensions.  But that was not
stated either, in either the IPv4 or the IPv6 draft.

> - Its not just about saving MH Types. That is a very

O.K. 
> to define any of the above considerations for each

Until we have the considerations, that's sort of a
moot point.  Plus, once we have them, it might turn
out that they don't all apply to all messages.  But, again,
if they do, they belong in the base document.

> MGSM message will allow its use for all events.

Well, it would be easier and better to define the use of
the Auth Option for various messages as they are
specified.  In fact, limiting the Binding Authentication Data
to only BU/BA was already against my better judgment,
and I acceded only because of the threat of drastically
more delay by the IESG.  Do you think the IESG would
be more friendly towards enabling the use of the Auth
Option for a _completely_ generic message format??(?)

I really don't see that.

> details and sender/receiver considerations. If we can

This doesn't narrow it down at all!

> there is some value in using this generic message.

I also don't believe any part of this (sorry to be
so skeptical, but I hope you don't mind if I state
my honest opinion).

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 22 Jul 2008 12:24:26 -0700

Hello again Sri,

I found the new draft:
http://tools.ietf.org/id/draft-haley-mext-generic-notification-message-00.txt

I scanned through it, and it doesn't seem to be very much
different regarding the issues that I raised in my email from
earlier this morning.  I still didn't find any discussion about
firewalls or NATs, for instance.

Regards,
Charlie P.

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 22 Jul 2008 16:00:31 -0700 (PDT)

Hi Charlie,

> But the IPv6 draft does not support your following text:

Ok. The draft requires additional considerations. Thats a
fair comment and agreed. No questions there. If the IPv6
or the IPv4 draft failed to do a good job, it should not
imply the requirement or the need for a generic message
disappears. Your feedback can help us improve the draft.

> Option for a _completely_ generic message format??(?)

Absolutely. I believe so. An option that is defined for a
Generic Notification message will be valid for all notification
messages that leverages that semantic. IESG should not have
a problem with it. There is no need to define MN-Id, Auth
Option, IPv4 HoA option for all events and ratify their
use for future events. Once defined for generic notification
message, its valid for all events that uses that mechanism.
We could have avoided the issue related to Auth Option, had we
defined the Generic Notification message earlier and made it
valid for that message.

I dont see much value in repeating all the common considerations
for every notification that we define. What out of the above
considertions will really change between an LMA going-down event
or some other event. If I relate to SNMP, SMI, we will be defining
different Trap PDU formats for every event. Why should every draft
that defines an event associated with a mobility session, go into
the details of defining IPsec PAD considerations or how the message
should be transported ...etc. Why should every event should have an
impact on a firewall considerations ?

There is a mobility session that got created and that session can
be identified using parameters X,Y,Z (based on CMIP or PMIP, HoA
or MN-Id...), considerations are fixed. Transport and IPsec/PAD
considerations are fixed. What is not fixed is the event properties,
event meta-data and the receiver and sender actions. Why should
we not abstract the common properties and provide a generic
container and offer generic semantics. If SDO like 3GPP wants to
use its vendor specific events, the same semantics can be used.

Regards
Sri

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 23 Jul 2008 00:24:54 -0500

Hello Charlie, 
Please allow me to comment on one of your points below.

Regards,
Ahmad

> > - It appears this is just about saving MH types, its not. When we 
> > start defining a new event, that draft has to deal with all 
> the above 
> > considerations. If that event leverages the Generic 
> Notification work, 
> > the focus of the draft is contained to the event details and 
> > sender/receiver considerations. If we can see the flow
> >
> >  Session is created
> >   Event-1
> >   Event-2
> >  Session is terminated
> 
> properties, 
> > there is no reason to float new messages, there is some 
> value in using 
> > this generic message.
> 
> I also don't believe any part of this (sorry to be so 
> skeptical, but I hope you don't mind if I state my honest opinion).

[Ahmad]
I believe the wg chairs declared consensus on the topic "Mobile IPv6
Generic Signaling Message" which I supported and still respect despite
some attempts to always refer to other than what has been agreed on.
Probably different understanding of the meaning of "Agreement or
Consensus". 

Putting this aside, I totally agree with what you just said.

I share the same opinion. It does not make sense that we can come up
with this generic signaling message that is so generic to capture every
event that would ever be needed for a mobility session. The proof for
this is: if we go back not far, but less than 3 months, we will find
different versions of the scope of this generic container thing
documented on this ml and still evolving:)

Not only that, but, for example, the fact that a BU with lifetime of
zero is considered OUTSIDE the scope of this Generic signaling while a
revocation message which accomplish the same impact on the BCE is?!

This concept of PLUG-N-PLAY signaling framework:) IMO, does not
necessarily stand on strong legs! I believe some of us just missed the
MIP6 BU/BA with few years, otherwise, we would have had all kind of
messages in a single generic container with one security requirement:)

In relation to the Auth protocol, thus far all the discussion is related
to messages that impact sessions that were created using a Client MIP6
BU/BA. But I believe you are making a very good point, that the security
requirement can not be captured as part of the generic message. On the
contrary, it should be specific to the event itself. Simply because the
generic framework is supposed to be so generic that captures all
possible signaling/events that would ever happen to a mobility session
and can concentrate on, for example, retransmission of the message.
(Although, different events may require different retransmission
timeouts) 

Therefore, those events can not have the same security requirements. I
believe your point is also related to the discussion regarding secure
vs. a non-secure message, but your comment rang a strong sounding bell
and somehow connected the dots! During that discussion it was suggested
to use two MH to be assigned to IPsec and Non-IPsec messages hoping by
that we be generic enough to have one security which fit the generic
signaling message framework. BTW: other interpretations believe those MH
types are for Secure and Non-secure (means no security measures at all).

Best Regards,
Ahmad

> >> Apparently, any message could fit as a subtype of the proposed 
> >> generic signaling message.
> >>
> >> I can't see any justification for this, given that so few of the 
> >> basic message types have been used.  There is no real 
> indication that 
> >> we are ever going to run out.
> >>
> >> If we had used 100 or even 50 of the message types 
> already, I could 
> >> see some justification for this extraordinarily generic 
> approach.  As 
> >> it is, I think we ought to continue to utilize the basic 
> message type 
> >> space, and avoid the message overhead and the complication of yet 
> >> another subtype space.
> >>
> >> Does anyone have any comparable example from another 
> working group, 
> >> where there was a desire to create a completely generic 
> message type 
> >> with subtypes, when the basic type numbering space was hardly 
> >> touched?
> >>
> >> Regards,
> >> Charlie P.
> >>
> >>
> >>
> would NOT fit 
> >>> > as subtypes of  the proposed generic  signaling message?
> >>>