Subject: Re: [mile] Reconsidering enumerated attribute extensions

From: "Roman D. Danyliw" <[email-masked]>
Date: Tue, 24 Mar 2015 19:16:27 +0000

Based on all of this feedback, the -11 version of the draft includes the option to have both public and private extensions.  Public extensions use the IANA registries introduced in the -10 draft.  The private extensions will used the "ext-" attributes.

Practically, the "ext-" attributes dropped in -10 were added back into -11.

Roman

________________________________________
From: Daisuke MIYAMOTO [[email-masked]]
Sent: Wednesday, February 25, 2015 3:18 AM
To: Roman D. Danyliw; [email-masked]
Subject: Re: [mile] Reconsidering enumerated attribute extensions

Option (3) is the best for me. Thank you for your clarifying pros and cons!

On 2015/02/24 5:38, Roman D. Danyliw wrote:
> Hello!
>
> In the -10 draft of draft-ietf-mile-rfc5070bis, a new attribute extension mechanism was introduced per Issue #3 [1] using an IANA registry.  This draft updated Section 5.1 and deprecated the old technique that used "@ext-*" attributes.  This planned change triggered discussion in Hawaii [2] which necessitated further discussion on the list.
>
> There are at least three options to adding enumerated values not specified in the schema.  The possible courses of action with some analysis are as follows:
>
> (1) Extend attributes using ONLY the @ext-* attribute
> ** Where is the text? See version -00 to -09 of the draft and the original RFC5070
> ** Background: came from RFC5070
> ** Pros: private extensions are possible
> ** Cons: commonly accepted extensions never get standardized
>
> (2) Extend the attributes using ONLY an IANA registry
> ** Where is the text? See version -10 (current draft)
> ** Background: came from formative discussions during MILE chartering; consistent with other IETF mechanisms
> ** Pros: commonly accepted extensions get standardized through a well defined mechanism
> ** Pros: XML validation is can check all of the values
> ** Cons: private extensions are not possible
> ** Cons: need to periodically rebuild the schema from IANA registry
>
> (3) Extend the attributes with BOTH the @ext-* and the IANA registry
> ** Where is the text? Combine Section 5.1 of the -09 and -10 drafts
> ** Pros: private extensions are possible
> ** Pros: commonly accepted extensions are standardized
> ** Cons: need to periodically rebuild the schema from IANA registry
> ** Cons: more optional attributes in the schema
>
> What does the working group think?  Are there more options to consider?
>
> Option #3 seems to present the most flexibility.
>
> Roman
>
> [1] http://trac.tools.ietf.org/wg/mile/trac/ticket/3
> [2] http://www.ietf.org/proceedings/91/minutes/minutes-91-mile
>
> _______________________________________________
> mile mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mile
>