Subject: [mile] Reconsidering enumerated attribute extensions

From: "Roman D. Danyliw" <[email-masked]>
Date: Mon, 23 Feb 2015 20:38:32 +0000

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

---

From: Lagadec Philippe <[email-masked]>
Date: Tue, 24 Feb 2015 08:57:02 +0000

Hello,

I vote for option #3: 
I think it is useful to keep the possibility of adding private extensions to all enumerations, and also to keep as much backwards compatibility with IODEFv1 as possible for existing implementations.

Regards,

Philippe.

-----Original Message-----
From: mile [mailto:[email-masked]] On Behalf Of Roman D. Danyliw
Sent: 23 February 2015 21:39
To: [email-masked]
Subject: [mile] Reconsidering enumerated attribute extensions

Hello!

Roman

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

---

From: Jerome Athias <[email-masked]>
Date: Tue, 24 Feb 2015 14:34:45 +0100

Hi,

I would concur for option #3
Meantime, could the IODEF Enumeration Reference Format
(draft-ietf-mile-enum-reference-format) be reused somehow?

Best regards

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Wed, 25 Feb 2015 00:11:19 +0900

Hi,

+1 to the option #3

Thank you.

Take

> From: mile [mailto:[email-masked]] On Behalf Of Jerome Athias
> Sent: Tuesday, February 24, 2015 10:35 PM
> To: Lagadec Philippe
> Cc: [email-masked]
> Subject: Re: [mile] Reconsidering enumerated attribute extensions
> 
> Hi,
> 
> > I think it is useful to keep the possibility of adding private
extensions
> to all enumerations, and also to keep as much backwards compatibility with
> IODEFv1 as possible for existing implementations.
> >
> > Regards,
> >
> > Philippe.
> >
> > 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:
> >
> > ** Where is the text? See version -00 to -09 of the draft and the
original
> RFC5070
> > ** Pros: commonly accepted extensions get standardized through a well
defined
> mechanism

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Tue, 24 Feb 2015 21:16:58 +0000

+1 for (3)

-----Original Message-----
From: mile [mailto:[email-masked]] On Behalf Of Roman D. Danyliw
Sent: Monday, February 23, 2015 3:39 PM
To: [email-masked]
Subject: [mile] Reconsidering enumerated attribute extensions

Hello!

Roman

---

From: Daisuke MIYAMOTO <[email-masked]>
Date: Wed, 25 Feb 2015 17:18:06 +0900

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