Subject: [Stackevo] Updates to draft-iab-protocol-transitions

From: Dave Thaler <[email-masked]>
Date: Sat, 18 Feb 2017 00:04:48 +0000

I've made a bunch of edits to attempt to address feedback from various folks.
Here's a summary of who provided feedback during IETF Call for Comments:

*         Brian Carpenter - no change (see previous email I sent today)

*         Joe Touch - Joe's comment was about wanting more discussion of extensibility.  I have added a new Section 2 (Extensibility) with more text.

*         Tom Herbert - Tom just seconded what Joe said, so also covered by the new subsection on Extensibility.

*         Dave Crocker - lots of comments including both editorial (accepted) and substantial ones that resulted in text changes.  He also commented on the case studies provided by Lee (IPv6) and Martin (HTTP) which Lee and Martin should look at and weigh in on whether changes are needed as I did not change those appendices.

*         Eliot Lear - Wanted more on rationale for transition plan attributes (I beefed up the Contingency Plan section as a result, which Eliot and Dave Crocker both said was insufficient).  Eliot's main detailed comments were on the HTTP case study, which Martin responded to.  Martin should say whether any changes are needed as a result.  Eliot also had some editorial points which I did accept.

*         S. Moonesamy - asked a couple of questions, and Ted already gave a good email response to one (that requires no draft changes as far as I know).  Another question is basically a duplicate of one of Dave Crocker's, about the IPv6 case study.   Hence so far I have made no changes to address SM's questions.

Let me know if I've missed anyone who provided feedback.  Changes so far can be seen by diffing the github version against the published draft -05:
https://tools.ietf.org//rfcdiff?url1=https://tools.ietf.org/id/draft-iab-protocol-transitions-05.txt&url2=https://raw.githubusercontent.com/dthaler/ietf/master/iab/draft-iab-protocol-transitions.txt<https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-iab-protocol-transitions-05.txt&url2=https://raw.githubusercontent.com/dthaler/ietf/master/iab/draft-iab-protocol-transitions.txt>

I will file issue tracker issues for each one, and respond there with what was changed.

Dave

---

From: Eliot Lear <[email-masked]>
Date: Tue, 21 Feb 2017 17:02:21 +0100

Hi Dave and thanks.  Again, I think it's a job done well.

Martin and I probably differ a bit on the HTTP case.  What I tried to
convey, more as an observation than anything, is that HTTP is in a state
of transition in at least two dimensions: from 1.1->2 and from HTTP to
HTTP and CoaP, leading to a potential change in your original
observation in 5218 regarding where it sits on the successOmeter ;-) 
One thing you or the board might want to consider is referring this
document to Constantine Dovrolis or Roch Guerin for consideration by one
of their grad students in this area.

The second point I would ask you to just take more more look at is
whether to move the examples into the front of the document as and when
they support your points.  That lays plain which examples are relevant
and perhaps which ones (if any) are extraneous to your message.  To be
sure it is editorial, but I hope you will agree it is a useful
suggestion.  I only mention it again because I don't think you indicated
a resolution.

Best regards,

Eliot

On 2/18/17 1:04 AM, Dave Thaler wrote:
>
> I’ve made a bunch of edits to attempt to address feedback from various
> folks.
>
> Here’s a summary of who provided feedback during IETF Call for Comments:
>
> ·         Brian Carpenter – no change (see previous email I sent today)
>
> ·         Joe Touch – Joe’s comment was about wanting more discussion
> of extensibility.  I have added a new Section 2 (Extensibility) with
> more text.
>
> ·         Tom Herbert – Tom just seconded what Joe said, so also
> covered by the new subsection on Extensibility.
>
> ·         Dave Crocker – lots of comments including both editorial
> (accepted) and substantial ones that resulted in text changes.  He
> also commented on the case studies provided by Lee (IPv6) and Martin
> (HTTP) which Lee and Martin should look at and weigh in on whether
> changes are needed as I did not change those appendices.
>
> ·         Eliot Lear – Wanted more on rationale for transition plan
> attributes (I beefed up the Contingency Plan section as a result,
> which Eliot and Dave Crocker both said was insufficient).  Eliot’s
> main detailed comments were on the HTTP case study, which Martin
> responded to.  Martin should say whether any changes are needed as a
> result.  Eliot also had some editorial points which I did accept.
>
> ·         S. Moonesamy – asked a couple of questions, and Ted already
> gave a good email response to one (that requires no draft changes as
> far as I know).  Another question is basically a duplicate of one of
> Dave Crocker’s, about the IPv6 case study.   Hence so far I have made
> no changes to address SM’s questions.
>
>  
>
> Let me know if I’ve missed anyone who provided feedback.  Changes so
> far can be seen by diffing the github version against the published
> draft -05:
>
> https://tools.ietf.org//rfcdiff?url1=https://tools.ietf.org/id/draft-iab-protocol-transitions-05.txt&url2=https://raw.githubusercontent.com/dthaler/ietf/master/iab/draft-iab-protocol-transitions.txt
> <https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-iab-protocol-transitions-05.txt&url2=https://raw.githubusercontent.com/dthaler/ietf/master/iab/draft-iab-protocol-transitions.txt>
>
>  
>
> _______________________________________________
> Stackevo mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/stackevo

---

From: Dave Thaler <[email-masked]>
Date: Tue, 21 Feb 2017 22:44:53 +0000

From: Stackevo [mailto:[email-masked]] On Behalf Of Eliot Lear
Sent: Tuesday, February 21, 2017 8:02 AM
To: Dave Thaler <[email-masked]>; Stackevo <[email-masked]>; Internet Architecture Board <[email-masked]>
Subject: Re: [Stackevo] Updates to draft-iab-protocol-transitions

Thanks, although the case studies were mostly written by others and I edited them somewhat.

Martin and I probably differ a bit on the HTTP case.  What I tried to convey, more as an observation than anything, is that HTTP is in a state of transition in at least two dimensions: from 1.1->2 and from HTTP to HTTP and CoaP, leading to a potential change in your original observation in 5218 regarding where it sits on the successOmeter ;-)

Martin, can you propose what changes should be made to the HTTP case study to address Eliot’s feedback, and Dave Crocker’s which was:
>>    A number of other features or characteristics of HTTP were identified
>>    as potentially undesirable.  Several such features were considered
>>    for removal during the design process.  This included trailers, the
>>    1xx series of responses, certain modes of request forms, and the
>>    unsecured (http://) variant of the protocol.  For each of these, the
>>    risk to the successful deployment of the new version was considered
>>    to be too great to justify removing the feature.  However, deployment
>>    of the unsecured variant of HTTP/2 remains extremely limited.
>
> I'm not understanding the basis for having the 'However' here.
>
> How does that sentence connect with the preceding text?  For that
> matter, what is the 'unsecured variant'?

One thing you or the board might want to consider is referring this document to Constantine Dovrolis or Roch Guerin for consideration by one of their grad students in this area.

Sure, though of course that does affect the text in the document, just a possible follow-up action item about it.

The second point I would ask you to just take more more look at is whether to move the examples into the front of the document as and when they support your points.  That lays plain which examples are relevant and perhaps which ones (if any) are extraneous to your message.  To be sure it is editorial, but I hope you will agree it is a useful suggestion.  I only mention it again because I don't think you indicated a resolution.

Right now the format follows the rule in RFC 5218 which was that case studies belong in the Appendix and the body of the document gives the conclusions/recommendations/things to think about.   Examples are ok in the body of the document as long as they’re brief and necessary to understand
the recommendation or issue to consider.   So if there are cases where a point would be strengthened by referring to a case study, it’s fine to add a sentence or
phrase about it, but we don’t want to move them entirely.

Thanks again for all your helpful feedback.

Best regards,

Eliot

On 2/18/17 1:04 AM, Dave Thaler wrote:
I’ve made a bunch of edits to attempt to address feedback from various folks.
Here’s a summary of who provided feedback during IETF Call for Comments:

·         Joe Touch – Joe’s comment was about wanting more discussion of extensibility.  I have added a new Section 2 (Extensibility) with more text.

·         Tom Herbert – Tom just seconded what Joe said, so also covered by the new subsection on Extensibility.

·         Dave Crocker – lots of comments including both editorial (accepted) and substantial ones that resulted in text changes.  He also commented on the case studies provided by Lee (IPv6) and Martin (HTTP) which Lee and Martin should look at and weigh in on whether changes are needed as I did not change those appendices.

·         Eliot Lear – Wanted more on rationale for transition plan attributes (I beefed up the Contingency Plan section as a result, which Eliot and Dave Crocker both said was insufficient).  Eliot’s main detailed comments were on the HTTP case study, which Martin responded to.  Martin should say whether any changes are needed as a result.  Eliot also had some editorial points which I did accept.

·         S. Moonesamy – asked a couple of questions, and Ted already gave a good email response to one (that requires no draft changes as far as I know).  Another question is basically a duplicate of one of Dave Crocker’s, about the IPv6 case study.   Hence so far I have made no changes to address SM’s questions.

Let me know if I’ve missed anyone who provided feedback.  Changes so far can be seen by diffing the github version against the published draft -05:
https://tools.ietf.org//rfcdiff?url1=https://tools.ietf.org/id/draft-iab-protocol-transitions-05.txt&url2=https://raw.githubusercontent.com/dthaler/ietf/master/iab/draft-iab-protocol-transitions.txt<https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-iab-protocol-transitions-05.txt&url2=https://raw.githubusercontent.com/dthaler/ietf/master/iab/draft-iab-protocol-transitions.txt>

Dave

Stackevo mailing list

[email-masked]<mailto:[email-masked]>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 22 Feb 2017 14:04:08 +1100

On 22 February 2017 at 09:44, Dave Thaler <[email-masked]> wrote:
> convey, more as an observation than anything, is that HTTP is in a state of
> transition in at least two dimensions: from 1.1->2 and from HTTP to HTTP and
> CoaP, leading to a potential change in your original observation in 5218
> regarding where it sits on the successOmeter ;-)
>
> Martin, can you propose what changes should be made to the HTTP case study

I think that Eliot has identified a much broader view of the problem.
If I might try to split things a little finer.

The multi-dimensional aspect is one that I'm not really prepared to
throw text at given how far down the road this document is already.
Not only do we have 1.1->2->maybe QUIC.  We're still learning things
from the deployment of HTTP/2 and we know very little about QUIC.
What I think we know, I tried to capture and would prefer to get very
specific feedback on that text (like what Dave provided below).

But then the notion that there are also new things that are HTTP-like
that have aspirations of some degree of "interoperability" with HTTP
is a huge open question and one that would be very interesting for the
program to tackle.  It's very early though, and I'd be reluctant to
publish anything until we have a better understanding.  For instance,
It would be very interesting to have a study of what sort of impact
CoAP has had once we have a little more experience of how it interacts
with HTTP (maybe some people have that experience, but I don't).

Eliot's earlier point about how your characterization of the protocol
you are "replacing" has an impact on the way the replacement built
from that characterization is structured and adopted is a very general
point, not limited to HTTP in any way.  As an example from HTTP/2
might illustrate.  We decided that http:// and https:// were equal
citizens in the spec.  The market decided to treat http:// with the
contempt (that it deserves) and we still see very little deployment of
that variant.

That we necessarily have a narrow view of a wildly successful protocol
than exists across all its uses might be worth trying to capture. That
our designs for a replacement might intentionally or inadvertently
exclude certain uses of the existing protocol is definitely something
that affects the disenfranchised for sure.  Whether we consider that
to be a problem might depend on the desired end state.  The intent
with HTTP/2 (and QUIC now) was never to replace the old protocol, thus
we can claim success much more easily.  In comparison, IPv4 being in
existence in any significant way is an affront to IPv6.

Let me see if I can formulate a section on this point.  It might be
that I have enough of a handle on it that I can provide something
useful.

> to address Eliot’s feedback, and Dave Crocker’s which was:

The "however" is poor, I agree.  The point is that while the feature
(transport over unencrypted TCP) was retained, the market has done the
job of excising the unwanted feature on its own.  That probably
deserves more text than I gave it.

I will try to construct an edit that makes this clearer.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 22 Feb 2017 06:58:17 +0100

Hi Martin and thanks for your comments.  One overall question relating
to the program: how do people on the board envision this work
continuing?  Also, I hope however it continues that Dave will be
involved ;-)  Now please see below on just one point:

> with HTTP (maybe some people have that experience, but I don't).
As a data point, and it is nothing more than that, I have been working
with a number of partners on draft-ietf-anima-boostrapping-keyinfra. 
For those who are working on other things, this draft is intended for
manufacturers to provide a trusted introduction between a Thing and a
local operational network such that the thing ends up with a local trust
anchor and a valid local device certificate.  The mechanism makes use of
EST to accomplish some of its final steps.  All goodness when we reuse
work, but EST runs over HTTP, and we've gotten a fair amount of demand
to switch HTTP to CoAP.  I think that is largely due to library size and
COGS.

Here's the weird thing: if CoAP succeeds reasonably well, we as vendors
would want to manage the tail regarding this particular use case re HTTP
in order to trim the code base, as well as to keep attention on a single
path, which improves security.  Tricky, tho.  EST has comparatively
limited deployment, but it exists in some h/w that will be around for a
VERY long time.

Eliot

---

From: Martin Thomson <[email-masked]>
Date: Wed, 22 Feb 2017 17:32:27 +1100

> limited deployment, but it exists in some h/w that will be around for a

This doesn't seem like a unique problem, even though the numbers are
bigger along certain dimensions.  For better or worse, we shackle
ourselves to the fates of protocols when we decide to use them.  Just
as the vendor of the device needs to choose a CPU supplier, we
collectively have to choose the right(?) protocol.

CoAP has a lot of positives, but then so does HTTP.  Both stacks might
also serve other purposes in more capable devices.  I personally don't
know how to make that decision and am glad that I don't have to.
That's why they pay you the big bucks, I guess.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 22 Feb 2017 17:35:43 +1100

> involved ;-)  Now please see below on just one point:

It seems to me that the best way to conclude this would be to have
Dave complete this particular document.  In my opinion that should be
achievable before he passes his pointy IAB hat to the new blood.

Beyond that, we have a few more things - seeds if you will - for later
work and new people.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 22 Feb 2017 07:44:39 +0100

> collectively have to choose the right(?) protocol.

Absolutely.  But what's interesting about this case was the engineering
and economic drive for reuse of HTTP (a *result* of wild success) and
the disruptive impact CoAP is having. 

> That's why they pay you the big bucks, I guess.

Indeed.  We file it under "best laid plans of mice and men", and
probably sort it through SKUs in the medium term.

Eliot

---

From: Dave Thaler <[email-masked]>
Date: Wed, 22 Feb 2017 17:51:46 +0000

[trimming to Stackevo program since this is getting away from the topic of the protocol transitions doc]

FYI,
https://tools.ietf.org/html/draft-montenegro-httpbis-h2ot-00#section-2 has a comparison among
HTTP, CoAP, MQTT etc in the context of IoT.

-----Original Message-----
From: Stackevo [mailto:[email-masked]] On Behalf Of Martin Thomson
Sent: Tuesday, February 21, 2017 10:32 PM
To: Eliot Lear <[email-masked]>
Cc: Stackevo <[email-masked]>; Internet Architecture Board <[email-masked]>; Dave Thaler <[email-masked]>
Subject: Re: [Stackevo] [IAB] Updates to draft-iab-protocol-transitions

On 22 February 2017 at 16:58, Eliot Lear <[email-masked]> wrote:
> Here's the weird thing: if CoAP succeeds reasonably well, we as 
> vendors would want to manage the tail regarding this particular use 
> case re HTTP in order to trim the code base, as well as to keep 
> attention on a single path, which improves security.  Tricky, tho.  
> EST has comparatively limited deployment, but it exists in some h/w 
> that will be around for a VERY long time.

This doesn't seem like a unique problem, even though the numbers are bigger along certain dimensions.  For better or worse, we shackle ourselves to the fates of protocols when we decide to use them.  Just as the vendor of the device needs to choose a CPU supplier, we collectively have to choose the right(?) protocol.

CoAP has a lot of positives, but then so does HTTP.  Both stacks might also serve other purposes in more capable devices.  I personally don't know how to make that decision and am glad that I don't have to.
That's why they pay you the big bucks, I guess.