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 protected]> wrote: > > > On Wed, Mar 15, 2017 at 10:28 PM, Richard Barnes <[email protected]> wrote: > >> 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. >> > > 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 :) >
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
