Re: [Trans] Policy for adding to IANA registries requested in 6962-bis

On Tue, 13 Dec 2016, Rob Stradling wrote:

> https://tools.ietf.org/html/rfc5226 section 4.1 says (emphasis mine):
>   "Expert Review (or Designated Expert) - approval by a Designated
>          Expert is required.  The *required documentation* and review
>          criteria for use by the Designated Expert should be provided
>          when defining the registry."
>
> So I think we should specify both Expert Review and Specification Required, 
> just as (for example) https://tools.ietf.org/html/rfc6844 section 7.2 does:
>   "Addition of tag identifiers requires a public specification and
>    Expert Review as set out in..."

Sounds good.

> Separately, should we reserve some values in either or both of these 
> registries for Private Use or for Experimental Use?

Yes please.

>>  * Specification requirement for SCT & STH extensions: new values for
>>  these extensions are meaningless without specifying what they do - how
>>  should clients behave when encountering them.
>
> +1 (and for the VersionedTransType registry we just added too)
>
> Separately, should we reserve some values in any of these registries for 
> Private Use or for Experimental Use?

Yes.

>>  * First-come-first-served for Log IDs: I can't see how an expect review
>>  could be meaningful, given log operators requesting those IDs can't
>>  really prove competence to "own" log IDs, so requiring a "minimal amount
>>  of clerical information" seems enough.
>
> +1

It would be nice to have some kind of rules or documentation, and at
least have an Expert around to block strange or excessive requests?

Stephen: how would you see this happening?

Paul

>>  Eran
>>
>>  On Mon, Dec 12, 2016 at 3:44 PM, Eran Messeri <eranm@google.com
>>  <mailto:eranm@google.com>> wrote:
>>
>>      No policy has been specified in 6962-bis for adding values to the
>>      IANA registries requested.
>>
>>      In https://github.com/google/certificate-transparency-rfcs/pull/215
>>      <https://github.com/google/certificate-transparency-rfcs/pull/215> I
>>      propose the following policies, all based on definitions in RFC5226:
>>      * Hash algorithms and Signature algorithms: Expert Review
>>      * SCT extensions and STH extensions: Specification Required
>>      * Log ID 1, Log ID 2: First Come First Served.
>>
>>      Feedback welcome, since, as far as I recall, this topic was not
>>      discussed on the list previously.
>>
>>      Eran
>> 
>> 
>> 
>>
>>  _______________________________________________
>>  Trans mailing list
>>  Trans@ietf.org
>>  https://www.ietf.org/mailman/listinfo/trans
>> 
>
> -- 
> Rob Stradling
> Senior Research & Development Scientist
> COMODO - Creating Trust Online
> Office Tel: +44.(0)1274.730505
> Office Fax: +44.(0)1274.730909
> www.comodo.com
>
> COMODO CA Limited, Registered in England No. 04058690
> Registered Office:
>   3rd Floor, 26 Office Village, Exchange Quay,
>   Trafford Road, Salford, Manchester M5 3EQ
>
> This e-mail and any files transmitted with it are confidential and intended 
> solely for the use of the individual or entity to whom they are addressed. 
> If you have received this email in error please notify the sender by replying 
> to the e-mail containing this attachment. Replies to this email may be 
> monitored by COMODO for operational or business reasons. Whilst every 
> endeavour is taken to ensure that e-mails are free from viruses, no liability 
> can be accepted and the recipient is requested to use their own virus 
> checking software.
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>
>