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 >> <[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. I am in full agreement with this.
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
