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?
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
