Re: [Trans] Adam Roach's Discuss on draft-ietf-trans-rfc6962-bis-31: (with DISCUSS and COMMENT)

[Adam Roach <[e-mail]>]

On 3/13/19 8:28 AM, Eric Rescorla wrote:
>
>
> On Tue, Mar 12, 2019 at 11:36 PM Adam Roach via Datatracker 
> <noreply@ietf..org <mailto:[e-mail]>> 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