Subject: [Mip4] Re: [issue43] draft-ietf-mip4-experimental-messages

From: Alpesh <[email-masked]>
Date: Tue, 10 Feb 2004 10:20:22 -0800

Henrik -

Regarding this issue if we should define experimental subtypes for 
existing option types,
our position is that this is not needed.

The definition of experimental options permits the usage of experimental 
subtypes.

Also, reserving experimental subtypes for existing options may not be a 
good idea as some
 implementations may already be using unallocated numbers (past 
experience).

Our opinion is that we should move forward by closing this issue.

Thanks
Alpesh

Henrik Levkowetz wrote:

>This comment from Henrik Levkowetz <[email-masked]> has been added to issue 43:
>
>draft: draft-ietf-mip4-experimental-messages -> draft-ietf-mip4-experimental-messages
>
>We would like to move forward with draft-ietf-mip4-experimental-messages.
>
>There is currently one open issue, reflected here:
>
> <http://www.mip4.org/issues/tracker/mip4/issue43>
>
>The possible positions seems to be either of:
>  * "Yes, add experimental sub-type number"
>  * "No, do not add experimental sub-type number"
>
>I'd like to get a little bit more feedback from the list on this issue,
>please comment on this, indicating your preference.
>
>	Henrik
>_________________________________________________
>Mip4 issue tracker <[email-masked]>
><http://www.mip4.org/issues/tracker/mip4/issue43>
>_________________________________________________
>
>  
>

-- 
Mip4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mip4

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 13 Feb 2004 08:50:17 +0100

Hi Alpesh,

> our position is that this is not needed.

Yes, I know :-)  However, I believe they may be needed
..
> The definition of experimental options permits the usage of experimental 

For new extensions, yes, but not in a straightforward manner for existing
extensions.
..
>  implementations may already be using unallocated numbers (past 

Do you have evidence of unallocated subtypes being used currently?  We
made a strong effort to clean up this area last year.

> Our opinion is that we should move forward by closing this issue.

I don't quite understand why you resist the idea of allocate an
experimental subtype number - on my part I see it as beneficial, and I
would like to understand why you see it as harmful; then we should be
able to make forward progress on this issue :-)

	Henrik

---

From: Kent Leung <[email-masked]>
Date: Fri, 13 Feb 2004 07:47:36 -0800

I guess we're trying to draw the line between functional purpose such
as experimental types vs. ease of coding purpose such as
experimental subtypes.  Seems like the experimental type provides
the capability needed for any research and development experiments.
Not sure if there's a need to go beyond functional capability?  We're
open to subtype support if there's more consensus in the WG.  So
far, we haven't seen a clear functional need.  Others can chime in?

I think we can get quick resolution on this issue when others feel one
way or the other and voice their opinions.

Thanks.

Kent