Subject: [Mip6] Re: WG LC: draft-ietf-mip6-experimental-messages-01 and draft-ietf-mip6-vsm-01

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 21 Jun 2007 11:18:42 -0700

Raj,

Basavaraj Patil wrote:
> This is a working group last call for the following two working group
> documents: 
> 
> 1. Mobile IPv6 Experimental Messages
>    <draft-ietf-mip6-experimental-messages-01.txt>
> 
> Status intended: Experimental

Shouldn't the first document also be Standards Track? It sets aside
mobility header messages type and options. Its true that these values
are for experimental purposes, but the document itself shouldn't be
experimental.

Vijay

> 
> 2. Mobile IPv6 Vendor Specific Option  <draft-ietf-mip6-vsm-01.txt>
> 
> Status intended: Standards track
> 
> The last call ends on June 14th, 07.
> 
> Please review the I-Ds and send your comments to the mailing list.
> 
> -Basavaraj
> 

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: Jari Arkko <[email-masked]>
Date: Fri, 22 Jun 2007 07:50:20 +0300

Vijay,

> are for experimental purposes, but the document itself shouldn't be

Technically, it does not HAVE to be, because RFC 3775 allows
code point allocation (what you do here) either with Standards
Action or by IESG Approval. However, I think Proposed Standard
makes more sense here, and it is also what the both the
document itself and your charter says -- so lets go with that.

A quick comment on -experimental-messages: Why does
the document need to define the format? If you compare
to other similar allocations, say RFC 4727, they simply
allocate the number and reference the generic definition
of the object as the only guideline. Here you are saying
something about the first two bytes of the message,
for instance. Is there a reason for that?

Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 21 Jun 2007 21:56:44 -0700

> document itself and your charter says -- so lets go with that.

Ok.

> for instance. Is there a reason for that?

Just following RFC 3775 and RFC 3963. We show the format for
any mobility header message that we define.

Vijay

---

From: Jari Arkko <[email-masked]>
Date: Fri, 22 Jun 2007 08:01:41 +0300

Vijay,

> any mobility header message that we define.

Hmm. But you don't actually define them, you just allocate
them and then leave it to the particular experiment
to use it in whatever way and format you like. I would
understand this if it was a question of something that
needs a common new header -- like vendor specific
attributes in some protocols start with a vendor id
and vendor's own number for the attribute. It makes
sense to standardize that, so that code can understand
at least which vendor the stuff comes from. I'm not
sure we have a similar reason here.

(I don't see harm in defining what you have done,
just asking why you are doing it.)

Jari

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 21 Jun 2007 23:19:39 -0700 (PDT)

> just asking why you are doing it.)

If what we are standardising is a reserved MHType, I
think the Vendor Id is critical. If two vendors, HA and
MN vendor, implement two different features under
standards track, using the same reserved MHType. Now,
if they connect both the systems, it will break the
code and create problems.

Having a vendor id and a application sub-type, will give
the implementations the option to skip messages that they
dont understand. This is more in the lines of 3025. So,
vendors can do the experiments using their vendor id
and their specific application sub-type.

Sri

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 21 Jun 2007 23:28:48 -0700

> and their specific application sub-type.

The vendor specific mobility option does have a "Vendor ID"
string. See http://www.ietf.org/internet-drafts/draft-ietf-mip6-vsm-01.txt

Jari is talking about the experimental mobility header message
and option. There is no vendor id used there.

Vijay

---

From: Jari Arkko <[email-masked]>
Date: Fri, 22 Jun 2007 09:31:24 +0300

Sri,

We are only defining vendor-specific options (in the -vsm
draft), not vendor-specific messages. I only used the
attribute example as an example of where you would
have to define the contents. We do not have a vendor-
specific message proposal on the table, and I don't
think we should do that either, for interoperability
reasons.

Vendor-specific = non-standard mechanism but
possibly deployed and permanent

Experimental = non-standard, research-oriented
mechanism, on purpose not deployed and not
permanent

However, the -vsm draft should comply with what
you wrote. However, it only has a vendor id, not
vendor's option id. I think adding the option Id
too would make debugging easier. Vijay, can
we add that?

Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 21 Jun 2007 23:48:16 -0700

Hi Jari,

> sure we have a similar reason here.

We can take specific examples.

 From RFC 3775, Binding Refresh Request

                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                     |          Reserved             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                                                               .
     .                        Mobility options                       .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 From RFC 4068, Fast Neighbor Advertisement

                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                     |            Reserved           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     .                                                               .
     .                        Mobility Options                       .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

> just asking why you are doing it.)

The above does not mean that we have to continue doing the same.
I am fine either way.

Vijay

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 21 Jun 2007 23:56:24 -0700 (PDT)

Hi Jari,

Ok. If implementations are not allowed to release/deploy
features that use experimental message/options. It
should be fine. I see the text in the Introduction.
Thanks for the clarification.

Sri

---

From: Jari Arkko <[email-masked]>
Date: Fri, 22 Jun 2007 10:24:26 +0300

Vijay,

> From RFC 3775, Binding Refresh Request

Right. But there's a difference between a message
for a given purpose and a message reserved for
any purpose. In the former case you need specific
fields, because you have a specific task in hand.
In the latter case... you don't. You could define
some generic fields, like what we discussed in
the VSA case, but even those fields do not appear
to be relevant for an experimental message.

> The above does not mean that we have to continue doing the same.

Right. I do not think this is a problem either way,
either. I have expressed my opinion which is that
we do not need the contents definition.  (FYI: That
is something that I'm saying only as an individual;
if the WG has consensus to bring the definitions
anyway I wouldn't block it in AD review.)

Jari

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 22 Jun 2007 11:55:37 +0200

> are for experimental purposes, but the document itself shouldn't be

I think as long as these options are reserved by IANA the document could 
be experimental/informational/stdtrack/bcp whatever.

Alex

>> Please review the I-Ds and send your comments to the mailing list.

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________