Subject: RE: [Mip4] [issue43] Experimental (sub) option type for existing options?

From: Tsirtsis George <[email-masked]>
Date: Wed, 7 Jan 2004 10:43:15 -0500

How is this covering Vendor-specific types? It looks like it is about
experimental sub-types....or am I missing the point?

George

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Alpesh
> Sent: Tuesday, January 06, 2004 6:29 PM
> To: [email-masked]
> Subject: [Mip4] [issue43] Experimental (sub) option type for existing
> options?
> 
> 
> 
> This has been entered in the issue tracker as issue 43.
> 
> owner: Alpesh <[email-masked]>:
> 
> category: Technical
> draft: draft-ietf-mip4-experimental-messages
> priority: Should fix
> status: No discussion
> title: Experimental (sub) option type for existing options?
> 
> Hi -
> 
> We have one open issue for this draft - 
> 
> Description: Should we define an experimental sub-type for 
> existing options?
> 
> One school of thought is that this is not needed as the 
> experiemental extension
> types permits us to achieve this. By using the experimental 
> extension type, one
> can use all the sub-types in that type for experimentation. 
> 
> Other school of thought is that for existing options, if any 
> experimentation is
> needed we can use an experimental sub-type from that type. 
> Once ready for
> standardization almost no code change is required to change 
> that experimental
> sub-type to use a standard sub-type.
> 
> We need the WG comments to resolve this issue and move on to 
> the next level.
> Your prompt attention in this regards is highly appreciated. 
> Please let me know
> if you need further clarification.
> 
> Thanks
> Alpesh
> _________________________________________________
> 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
> 

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

---

From: Tsirtsis George <[email-masked]>
Date: Wed, 7 Jan 2004 12:34:21 -0500

OK, this is clear enough.
Thanks
George

> From: Kent Leung [mailto:[email-masked]]
> Sent: Wednesday, January 07, 2004 5:05 PM
> To: Tsirtsis George
> Cc: [email-masked]
> Subject: RE: [Mip4] [issue43] Experimental (sub) option type for
> existing options?
> 
> 
> This is not about vendor specific types.  Here's a quick summary of
> the goals of the experimental and vendor specific drafts/RFC.
> 
> 1) Experimental messages and extensions (only type defined) to support
>      research and experimentation.
> 
>      The issue here is should there be a universal 
> experimental subtype
>      for extensions as well (this means the same subtype number is
>      reserved for experiments in all extension types)?  I 
> don't think we
>      need this since experimental type should suffice from 
> the functional
>      perspective.
> 
> 2) Vendor specific extensions are defined to support vendor 
> capabilities
>      to standard messages.
> 
>      If vendors need messages, the experimental messages 
> would be ideal
>      to use for experimentation and inter-operation.  Once 
> the idea has been
>      baked and determined to be useful for deployment, then 
> it should be
>      proposed to WG to obtain IANA message types for real 
> world deployment.
> 
> Just my perception of the differences and objectives of the 
> experimental
> and vendor draft/RFC.
> 
> Kent
> 
> At 10:43 AM 1/7/2004 -0500, Tsirtsis George wrote:

---

From: Kent Leung <[email-masked]>
Date: Wed, 07 Jan 2004 09:04:42 -0800

The issue here is should there be a universal experimental subtype
     for extensions as well (this means the same subtype number is
     reserved for experiments in all extension types)?  I don't think we
     need this since experimental type should suffice from the functional
     perspective.

2) Vendor specific extensions are defined to support vendor capabilities
     to standard messages.

     If vendors need messages, the experimental messages would be ideal
     to use for experimentation and inter-operation.  Once the idea has been
     baked and determined to be useful for deployment, then it should be
     proposed to WG to obtain IANA message types for real world deployment.

Just my perception of the differences and objectives of the experimental
and vendor draft/RFC.

Kent