Subject: [Trans] Fresh issues!

From: Richard Barnes <[email-masked]>
Date: Wed, 15 Mar 2017 18:33:58 -0400

Hey all,

I just submitted a whole crop of new issues (>10% of all WG issues to
date!) on 6962-bis:

https://trac.ietf.org/trac/trans/report/1

While these issues are numerous and some of them are non-trivial, none of
them are fundamental and I think most of them are pretty clearly
justified.  So hopefully it will be easy to make progress here.

I'd like to call out a few as especially critical, which basically encode
the objections EKR and I have been raising lately:

https://trac.ietf.org/trac/trans/ticket/162
https://trac.ietf.org/trac/trans/ticket/163

I will be off next week, but glad to meet up with folks at the IETF to
triage / fix issues.

--Richard

---

From: Ryan Sleevi <[email-masked]>
Date: Wed, 15 Mar 2017 21:46:11 -0400

That's a whole lot of issues, and some of them questionably justified. It
also seems non-ideal to suggest that these issues be closed without
discussion on the list, as that's not very transparent.

Given WGLC has completed, and it seems some of them fundamentally redefine
the protocol or implementation, do you have a suggested priority of issues
to discuss, from those you view as most clearly justified to least clearly
justified?

---

From: Richard Barnes <[email-masked]>
Date: Wed, 15 Mar 2017 22:28:47 -0400

> discussion on the list, as that's not very transparent.

I certainly didn't mean to imply that these would be closed without
discussion.  The idea of meeting up was just to get concrete proposals in
front of the WG faster.

> to discuss, from those you view as most clearly justified to least clearly

I think you're over-stating the impacts here.  The overall shape of the
protocol is untouched by these proposals, and many of them are just cleanup
for a document that's made it through 25 revisions.

But I'm happy to provide some taxonomy / plan of attack.  I'll send
something around tomorrow.

--Richard

---

From: Melinda Shore <[email-masked]>
Date: Wed, 15 Mar 2017 18:39:45 -0800

I appreciate that there's going to be a lot of concern
about a big pile of issues being opened up at this stage
in the process.  Nothing is going to be closed without
working group discussion (which means on the mailing list,
not just in a meeting) unless it's truly trivial -
something on the scale of misplaced punctuation.  I'm
going to go through the new issues tonight and make sure
that we've got a handle on how to get these whacked down
in a timely way.  We should probably figure on having
a side meeting at some point during the week - we'll try
to track down a room once we've got some idea of when
and how many people.

Melinda

---

From: Ryan Sleevi <[email-masked]>
Date: Wed, 15 Mar 2017 22:48:40 -0400

https://trac.ietf.org/trac/trans/ticket/162
https://trac.ietf.org/trac/trans/ticket/170
https://trac.ietf.org/trac/trans/ticket/171
https://trac.ietf.org/trac/trans/ticket/174
https://trac.ietf.org/trac/trans/ticket/176
https://trac.ietf.org/trac/trans/ticket/185

Are all pretty substantially impacting changes. That's just a few I looked
through of which meaningfully change how either a client or server is
designed and implemented.

I'll use https://trac.ietf.org/trac/trans/ticket/185 as an example, which I
suspect is something you'd consider trivial (but I may have read wrong). As
a client, this forces an additional indirection through a URL lookup
service to take advantage of this. It further forces the need for policy
regarding how such URLs are constructed and advertised - because as we all
know, despite (or because of, depending on your view) RFC 3986, URLs are
far messier in the real world, and untangling that mess just shifts the
problem to policy. It touches on operational issues, such as whether or not
this remains static for the duration of the log or variable.

I wasn't trying to suggest we shouldn't discuss these, just that I can see
a number of them are, from a client implementor hat, pretty significant,
and some of them are pretty underjustified or undesirable (e.g.
https://trac.ietf.org/trac/trans/ticket/171 ).

I'll save the substantive comments for the individual discussions, and
greatly appreciate the view to highlight what you believe are most to least
pressing matters to resolve :)

---

From: Rob Stradling <[email-masked]>
Date: Thu, 16 Mar 2017 11:00:39 +0000

Melinda,

You'll recall that (a few months ago) both Eran and I promised that we 
would make no further changes to 6962-bis.  But if you'd like me to 
resume co-authoring duties, I'd be happy to do so.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Eran Messeri <[email-masked]>
Date: Thu, 16 Mar 2017 12:26:17 +0000

Same here - I also think that going over the issues Richard has filed to
determine which ones can be addressed in a timely way, without
significantly changing fundamental aspects of 6962-bis.

On Thu, Mar 16, 2017 at 11:00 AM, Rob Stradling <[email-masked]>
wrote:

> would make no further changes to 6962-bis.  But if you'd like me to resume
> co-authoring duties, I'd be happy to do so.
>
>
> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>

---

From: Melinda Shore <[email-masked]>
Date: Thu, 16 Mar 2017 07:48:25 -0800

On 3/16/17 4:26 AM, Eran Messeri wrote:
> On Thu, Mar 16, 2017 at 11:00 AM, Rob Stradling
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     You'll recall that (a few months ago) both Eran and I promised that
>     we would make no further changes to 6962-bis.  But if you'd like me
>     to resume co-authoring duties, I'd be happy to do so.

Excellent - thanks to you both.  I think it would also be
helpful to identify which of the new issues can be addressed
in a new document and which require changes to the -bis
draft.

Melinda

---

From: Richard Barnes <[email-masked]>
Date: Thu, 16 Mar 2017 18:58:51 -0400

Alright, here's some taxonomy:

https://docs.google.com/spreadsheets/d/1TS8fgwLrW2js1Q4genXRSzEOOCihw9rJPNq5Zc7a4To/edit?usp=sharing

I've binned the issues into a few classes: Editorial, Architecture, Data
Model, HTTP API, and TLS Connections.  I've filled in estimates of
priorities (personal) and effort (in units of code, spec text, WG time).

I've also highlighted exactly what the impact would be on any current
implementations of 6962-bis as it is.  I think this primarily serves to
illustrate that the impacts are localized, e.g., to the parsing of specific
objects, as opposed to changing the overall pattern of behavior of any of
the participants in the protocol.  The largest impacts are adding an HTTP
request, to fetch an STH or a URL directory.

As far as plan of attack, I might propose a two-part plan:

1. The editors and I go ahead and write up PRs for the editorial and data
model issues, since these should either be non-controversial or pretty
straightforward to come to resolution on.  These also constitute the
largest text changes, so they'll be good to get out of the way.

2. We discuss the remainder at the IETF meeting and try to agree on
direction, then create PRs as necessary to make things concrete and get
toward consensus.

Melinda: With regard to your questions about what of this needs to be in
-bis and what could move to a client behaviors document: If we're going to
have a client behavior document, I would propose we delete Section 8.2
entirely in favor of that document (and probably the remainder of Section 8
as well).  That section doesn't add much beyond saying "use the mechanisms
defined above", and that would resolve the CONN issues in my batch.

On Wed, Mar 15, 2017 at 10:48 PM, Ryan Sleevi <[email-masked]> wrote:

> I'll use https://trac.ietf.org/trac/trans/ticket/185 as an example, which
> I suspect is something you'd consider trivial (but I may have read wrong).
> As a client, this forces an additional indirection through a URL lookup

---

From: Melinda Shore <[email-masked]>
Date: Fri, 17 Mar 2017 11:20:45 -0800

On 3/16/17 2:58 PM, Richard Barnes wrote:
> -bis and what could move to a client behaviors document: If we're going
> to have a client behavior document, I would propose we delete Section
> 8.2 entirely in favor of that document (and probably the remainder of
> Section 8 as well).  That section doesn't add much beyond saying "use
> the mechanisms defined above", and that would resolve the CONN issues in
> my batch.

Okay, we'll try to get a sense of how much agreement there
would be to doing so.  The two-part bottleneck on any of this is
whether or not there's consensus that we need a client behavior
draft and whether or not we've got editors who are on top of
client issues.

Also, to reiterate a general principle in this working group, our
expectation is that 6962-bis does not have to be complete but it
does have to be correct.

Melinda