[Trans] overview of remaining(?) DISCUSS items for draft-ietf-trans-rfc6962-bis-33

[Paul Wouters <[e-mail]>]

On Wed, 18 Sep 2019, Rob Stradling wrote:

> No comments received after a week, so I'm going to merge PR 312 now and
> publish -33.

Looking at the DISCUSS items, I see some minor items that seems to
require some small edits. Can the authors answers these DISCUSS
questions cited below and let us know if they will do another revision
or whether they consider all DISCUSS items below resolved?

Paul



Alissa Cooper:

 	= Section 10.3 =

 	This section needs to state what the registry policy is for the code
 	points not already registered (presumably Expert Review given 10.3.1,
 	but it needs to be explicit).

 	= Section 10.6.1 =

 	FCFS registries by definition can require additional information to be
 	provided in order to get something registered. For avoidance of
 	confusion I think the assignment policy should be listed as First Come
 	First Served and the requirement that parameters be included in the
 	application can use a normative MUST in the last paragraph if there is
 	concern that the parameters won't be supplied.

 	However, I also wonder what will be done with the parameters that are
 	supplied. Is IANA expected to just maintain them privately, or to
 	publish them?

 	What is expected to appear in the 'Log' column in the registry?

And let me add my own question regarding 10.6.1. Should we expect these
registry entries can change over time? If so, is it definied anywhere what
consumers are supposed to do or how they are supposed to find out, that a
log base url has changed? Shouldn't such a change be done using a new OID?

Benjamin Kaduk:

 	Sections 4.11 and 4.12 have arrays of NodeHash to carry consistency and
 	inclusion proofs, respectively, with minimum array size of 1.  However,
 	Sections 2.1.4.1 and 2.1.3.1 (respectively) seem to admit the
 	possibility of zero-length proofs in degenerate cases

Mirja Kühlewind:

 	There was a presentation at maprg IETF 103 about the question if CT
 	helps attackers to find new domains. I think this risk should at least
 	be mentioned in the security considerations section.

To answer Mirja, the work to discuss these were going to appear in the
threat model draft. Unfortunately, this document got stuck due to
unworkable differences between the author and the WG. While I don't
object to adding a sentence covering your DISCUSS, I do not believe the
WG should try to cherry-pick content of the threat document at this
stage. So I think we should limit the Security Considerations to the
specific bis document specification, and not include issues that cover
the whole the CT ecosystem.

Alexey Melnikov:

 	I think you need to register [log client message type URN] in <https://www.iana.org/assignments/params/params.xhtml#params-1>

 	Also, can you clarify whether error need an IANA registry?