Subject: [eppext] Specification Required

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 29 Jan 2014 13:32:47 +0000

Reference this WG document:

http://tools.ietf.org/html/draft-ietf-eppext-reg-01

It's also helpful to review Section 4.1 of RFC 5226:

http://tools.ietf.org/html/rfc5226#section-4.1

Section 3.1 of reg-01 says that 'The "Specification Required" policy described in RFC 5226 [RFC5226] MUST be followed' and 'Note that the "Specification Required" policy implies review by a Designated Expert'. I want to explicitly call this out for discussion because it gets to the crux of how extensions will eventually be reviewed prior to registration by IANA. Is this the right approach? We could also require discussion on a mailing list; is it worth suggesting that [email-masked] be used for that purpose even after the WG completes its work and is closed?

There are other options for IANA registration policies, including Private Use, Experimental Use, Hierarchical Allocation, First Come First Served, Expert Review, RFC Required, IETF Review, Standards Action, and IESG Approval. I proposed "Specification Required" because I think it makes sense to have extensions documented in a publicly-visible specification *and* public review will help us prevent extension duplication.

Scott

---

From: Bernie Hoeneisen <[email-masked]>
Date: Wed, 29 Jan 2014 15:22:34 +0100 (CET)

Hi Scott et al.

As the IETF Designated Expert for ENUM I could shortly outline, how this 
works for ENUM. In fact, I see a lot of similarities in process between 
IANA registration of EPP Extensions and Enumservices.

[RFC 6117] defines the IANA registration process for Enumservices with 
policy "Specification Required" (which includes Expert Review).

Further comments inline.

On Wed, 29 Jan 2014, Hollenbeck, Scott wrote:

> Section 3.1 of reg-01 says that 'The "Specification Required" policy 
> described in RFC 5226 [RFC5226] MUST be followed' and 'Note that the 
> "Specification Required" policy implies review by a Designated Expert'. 
> I want to explicitly call this out for discussion because it gets to the 
> crux of how extensions will eventually be reviewed prior to registration 
> by IANA. Is this the right approach? We could also require discussion on 
> a mailing list; is it worth suggesting that [email-masked] be used for 
> that purpose even after the WG completes its work and is closed?

In ENUM we require [RFC 6117] discussion on the (kept-open ENUM) mailing 
list from the begining. This ensures gathering of early comments by the 
community, and thus leads to better quality of the specification at the 
time of Expert Review.

In addition, as IESG Designated Expert, I inform the ENUM mailing list 
about the start of the Expert Review process to allow for (late) comments 
on the to be reviewed version. After conclusion of the Expert Review, I 
also post its results to the ENUM mailing list. (While both these steps 
are not required, I consider it as good practice to keep the process as 
transparent and open as possible.)

> There are other options for IANA registration policies, including 
> Private Use, Experimental Use, Hierarchical Allocation, First Come First 
> Served, Expert Review, RFC Required, IETF Review, Standards Action, and 
> IESG Approval. I proposed "Specification Required" because I think it 
> makes sense to have extensions documented in a publicly-visible 
> specification *and* public review will help us prevent extension 
> duplication.

I agree with you and suggest to apply a similar policy and practices as 
used for Enumservices [RFC 6117].

cheers,
  Bernie

--

http://ucom.ch/
Tech Consulting for Internet Technology