On 3/13/19 8:28 AM, Eric Rescorla wrote:
On Tue, Mar 12, 2019 at 11:36 PM Adam Roach via Datatracker
<[email protected] <mailto:[email protected]>> wrote:
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
Thanks to everyone who worked on updating this protocol to reflect
experience
gathered from the initial CT protocol. I have one blocking
comment, and a small
number of editorial suggestions.
---------------------------------------------------------------------------
§5:
> Clients are configured with a base URL for a log and construct URLs
> for requests by appending suffixes to this base URL. This structure
> places some degree of restriction on how log operators can deploy
> these services, as noted in [RFC7320]. However, operational
> experience with version 1 of this protocol has not indicated that
> these restrictions are a problem in practice.
The synthesis of URLs by a protocol in this fashion is prohibited
by BCP 190:
Scheme definitions define the presence, format, and semantics of a
path component in URIs; all other specifications MUST NOT
constrain,
or define the structure or the semantics for any path component.
Unless the intention of this document is to update BCP 190 to
change this
normative requirement, we can't publish it in its current form.
Note that doing
so would require a change of venue, as updates to BCP 190 would
not be covered
by the current TRANS charter.
Please see BCP 190 section 3 for alternate approaches. All three
approaches
could be made to work for CT, and I would be happy to explain how
to do so if
clarification is desired.
While I agree that this is forbidden by BCP 190, this structure is
inherited from
RFC 6962, which predated 7320, so making that change seems like it's going
to be fairly disruptive. This seems like it is falling into our
discussion the other
day about what must be changed in -bis documents.
I think the timing of this document is fortuitous, in that it can help
inform that conversation. In particular, this situation helps me better
understand why both you and Benjamin raised objections to the high-level
proposal that unchanged parts of -bis documents shouldn't be subject to
DISCUSS positions. The take-away that I plan to bring to that
conversation is that such a decision needs to be informed by (a) scope
of changes between a document and its -bis, and (b) scope of changes
required to satisfy a potential DISCUSS position.
In cases like this one, where a not-even-remotely-backwards-compatible
suite of protocol changes is being made to a protocol in a document
update whose diff [1] is basically the entire document, I don't think
the principle of ignoring existing flaws in a previous document really
applies. I get that both of those predicates are somewhat subjective
evaluations, and that drawing a line in a process document might be
difficult; but I think that any standard, however subjective, that you
would be willing to sign on to would place this document outside the
category of "bis versions that are making small, incremental changes to
existing documents."
If the remedy for the flaw were a major overhaul rather than a
relatively minor tweak, it would again shift the evaluation a bit;
however, the naïve band-aid solution of moving CT endpoints to live
under "/.well-known/ct" is a trivial change, both for this document and
for implementations (in fact, for implementations, it can generally be
accomplished with a configuration tweak rather than writing new code).
To be clear, this is a textbook example of the kind of situation URI
templates were designed for, but that would require substantially more
work than simply moving it into the .well-known tree. Either approach
would address the URI ownership issue.
/a
____
[1]
https://www.ietf.org/rfcdiff?url1=rfc6962&url2=draft-ietf-trans-rfc6962-bis-31
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
