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

["Alexey Melnikov" <[e-mail]>]

On Wed, Mar 13, 2019, at 5:26 PM, Adam Roach wrote:
> 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.

I am in full agreement with this.