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

From: Adam Roach via Datatracker <[email-masked]>
Date: Tue, 12 Mar 2019 23:36:41 -0700

Adam Roach has entered the following ballot position for
draft-ietf-trans-rfc6962-bis-31: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/

----------------------------------------------------------------------
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.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

§1.1:

>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>  document are to be interpreted as described in [RFC2119].

Consider using the boilerplate from RFC 8174.

---------------------------------------------------------------------------

§1.3:

>  This document revises and obsoletes the experimental CT 1.0 [RFC6962]
>  protocol, drawing on insights gained from CT 1.0 deployments and on
>  feedback from the community.

Given that *this* document is also experimental, it seems a bit odd to call out
RFC 6962 as experimental.

---------------------------------------------------------------------------

§2.1.1:

>  We have established a registry of acceptable hash algorithms (see

The use of first person here is awkward. Consider: "This document
establishes..."

---------------------------------------------------------------------------

§10.2:

>  | 0x01 - | Unassigned |                        | Specification      |
>  | 0xDF   |            |                        | Required and       |
>  |        |            |                        | Expert Review      |

The policy being cited here is confusing. It is unclear whether the intention is
that values can be registered under both §4.5 and §4.6 of RFC 8126. I suspect
the intention here is the policy specified in RFC 8126 §4.6 only, without
reference to the policy in §4.5. If so, please use the formal name
"Specification Required."

---------------------------------------------------------------------------

§10.4:

>  | 0x0008 -    | Unassigned           | Specification Required and   |
>  | 0xDFFF      |                      | Expert Review                |

Same comment as above.

---------------------------------------------------------------------------

§10.5:

>  | 0x0000 -      | Unassigned | n/a | Specification Required and     |
>  | 0xDFFF        |            |     | Expert Review                  |

Same comment as above.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 13 Mar 2019 06:28:04 -0700

> https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/

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.

-Ekr

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 13 Mar 2019 15:19:30 +0100

HI Ekr,

I actually have a related question. As this document is rather specifying a new version than “just” correcting an existing spec, it’s not really clear to me if the obsolete tag is the right choice here. I know some other protocols do this in a similar fashion, but I would rather recommend to only update the previous version RFC (in order to create a link to this new spec) or declare it historic if usage is not recommended anymore. I think that's also something we should discuss on the IESG.

Coming back to your original question about how much should be changed in a bis document. I think this is a valid question for bis doc that correct known errors. However, in case of this document that specifies a new version, I think it is the right thing to do to also align such a new version with the guidelines we follow at the time of publication.

Mirja

> On 13. Mar 2019, at 14:28, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> On Tue, Mar 12, 2019 at 11:36 PM Adam Roach via Datatracker <noreply@ietf..org> wrote:
> While I agree that this is forbidden by BCP 190, this structure is inherited from
> to be fairly disruptive. This seems like it is falling into our discussion the other

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 13 Mar 2019 07:44:12 -0700

On Wed, Mar 13, 2019 at 7:19 AM Mirja Kuehlewind <[email-masked]>
wrote:

> HI Ekr,
>
> I actually have a related question. As this document is rather specifying
> a new version than “just” correcting an existing spec, it’s not really
> clear to me if the obsolete tag is the right choice here. I know some other
> protocols do this in a similar fashion, but I would rather recommend to
> only update the previous version RFC (in order to create a link to this new
> spec) or declare it historic if usage is not recommended anymore. I think
> that's also something we should discuss on the IESG.
>

First let me say that I find these tags mostly useless and not worth the
energy that seems to go into maintaining them. With that said, I think
"this is a new version of this protocol and you should stop using the old
and and start using this one" is a pretty clear case for Obsoletes. And the
question of whether that's the intended sementic is a clear WG decision.
So, if the IESG wants people to follow a different practice, it really
needs to publish explicit guidance.

> Coming back to your original question about how much should be changed in
> a bis document. I think this is a valid question for bis doc that correct
> known errors. However, in case of this document that specifies a new
> version, I think it is the right thing to do to also align such a new
> version with the guidelines we follow at the time of publication.
>

Hmm... This does not seem like the policy we have been applying so far. I'd
be interested to see an IETF statement on this matter.

-Ekr

> > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html

---

From: Richard Barnes <[email-masked]>
Date: Wed, 13 Mar 2019 10:45:35 -0400

> that's also something we should discuss on the IESG.

Strongly disagree with this reasoning.  Much like with TLS 1.2 -> 1.3, we
want people to deploy the new version, not the old version.  The tool we
have to communicate "Don't use this old version" is "Obsoletes".

--Richard

> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 13 Mar 2019 10:53:28 -0400

Hi Mirja,

> On Mar 13, 2019, at 10:19 AM, Mirja Kuehlewind <[email-masked]> wrote:
> 
> HI Ekr,
> 

We have a statement that explains our current position: https://www.ietf.org/blog/iesg-statement-designating-rfcs-historic/

Alissa

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 13 Mar 2019 08:50:40 -0700

Thanks for pointing that out. I had forgotten. This in fact seems to
support use of Obsoletes here.

-Ekr

On Wed, Mar 13, 2019 at 7:53 AM Alissa Cooper <[email-masked]> wrote:

> > I actually have a related question. As this document is rather
> specifying a new version than “just” correcting an existing spec, it’s not
> really clear to me if the obsolete tag is the right choice here. I know
> some other protocols do this in a similar fashion, but I would rather
> recommend to only update the previous version RFC (in order to create a
> link to this new spec) or declare it historic if usage is not recommended
> anymore. I think that's also something we should discuss on the IESG.
>
> We have a statement that explains our current position:
> https://www.ietf.org/blog/iesg-statement-designating-rfcs-historic/
>
> Alissa
>
> >
> > Coming back to your original question about how much should be changed
> in a bis document. I think this is a valid question for bis doc that
> correct known errors. However, in case of this document that specifies a
> new version, I think it is the right thing to do to also align such a new

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 13 Mar 2019 16:55:54 +0100

Hi Ekr,

See below

> On 13. Mar 2019, at 16:50, Eric Rescorla <[email-masked]> wrote:
> 
> Thanks for pointing that out. I had forgotten. This in fact seems to support use of Obsoletes here.
> 
> -Ekr
> 
> 

Based on the statement you made in the other mail:

 "this is a new version of this protocol and you should stop using the old and and start using this one”

And what’s written in this statement:

"	• A document is labelled Historic when what it describes is no longer considered current: no longer recommended for use. “

I would think historic should be used.

Mirja

---

From: Adam Roach <[email-masked]>
Date: Wed, 13 Mar 2019 12:26:01 -0500

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:[email-masked]>> wrote:
>
>
>

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

---

From: "Alexey Melnikov" <[email-masked]>
Date: Wed, 13 Mar 2019 16:52:50 -0400

On Wed, Mar 13, 2019, at 5:26 PM, Adam Roach wrote:
>> On Tue, Mar 12, 2019 at 11:36 PM Adam Roach via Datatracker <noreply@ietf..org <mailto:[email-masked]>> wrote:
>>> 
> 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.