Subject: Re: [OPSAWG] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019

From: Peter Gutmann <[email-masked]>
Date: Tue, 5 Nov 2019 01:44:06 +0000

I actually think it's a pretty good summary, and delivers exactly what's
promised in the title.  OTOH I can also see that it's going to get bikeshedded
to death, and will probably never be editable into a form where people won't
complain about it no matter how many changes are made.  Alternatively, it'll
end up watered down to a point where no-one can complain any more but it won't
say anything terribly useful by then.

Perhaps it could be published as is with a comment that it represents the
opinions of the authors?  Although given that it's Informational and not
Standards-track or a BCP, that should be a given anyway.

Peter.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 4 Nov 2019 18:34:58 -0800

> Standards-track or a BCP, that should be a given anyway.

Actually, no. Most IETF documents, even informational ones, bear a
statement that they have IETF Consensus.

See: https://tools.ietf.org/html/rfc5741#section-3.2.1

-Ekr

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 4 Nov 2019 21:39:28 -0500

If the authors want to publish it as an RFC so as to comment on other 
RFCs, they could approach the Independent Stream Editor.  That sort of 
publication is one of the explicit purposes of the Independent Stream.

Yours,
Joel

On 11/4/2019 9:34 PM, Eric Rescorla wrote:
> 
> 
> On Mon, Nov 4, 2019 at 5:44 PM Peter Gutmann <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> <https://tools.ietf.org/html/rfc5741#section-3..2.1>
> 
> -Ekr
> 
> 
>     Peter.
> 
> 
> 
> 
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg
>

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 5 Nov 2019 02:40:48 +0000

Eric Rescorla <[email-masked]> writes:

>Actually, no. Most IETF documents, even informational ones, bear a statement
>that they have IETF Consensus.

Ah, OK.  In that case publish it with a statement that commentators couldn't
agree on what it should say, which I think is better than watering it down to
a level where commentators can't disagree with what it says.  It's an
interesting document which makes good points, and worth putting out there
while it still has good points to make.

Peter.

---

From: Joe Touch <[email-masked]>
Date: Mon, 4 Nov 2019 18:48:09 -0800

> On Nov 4, 2019, at 6:39 PM, Joel M. Halpern <[email-masked]> wrote:
> 
> If the authors want to publish it as an RFC so as to comment on other RFCs, they could approach the Independent Stream Editor.  That sort of publication is one of the explicit purposes of the Independent Stream.

That only happens if the WG and IESG say this is out of scope for the IETF. I.e., the ISE isn’t an end-run.

IMO, given the fact that this is squarely within TSVWG and there’s no consensus, the way forward is clear.

Not every ID turns into an RFC, nor should it.

Joe

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 4 Nov 2019 23:06:10 -0500

Actually Joe, the rules clearly allow the case wehre an Independent 
Stream I-D disagrees with the IETF rough consensus.  Many such have been 
published.  Some of them were held so that they were not published until 
the relevant IETF work was published.

To be explicit, while the IESG can request that the ISE not publish 
something, and can provide a note they wish to have included if it is 
published, they do not have the power to enforce a do-not-publish if the 
ISE disagrees.
And Joe, you have lived aspects of this more closely than I have, so I 
am sure you are aware of it.

Yours,
Joel

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 5 Nov 2019 10:26:39 +0000

Thanks for the various comments on process.

I expect both editors and the Chairs to work with our AD to confirm the 
intended scope, and then to decide on the next steps. This author wants 
to clarify how IETF transport protocols have been designed and have 
been/are being used.

Gorry (as one of the editors of this document).

On 05/11/2019 02:39, Joel M. Halpern wrote:
>> On Mon, Nov 4, 2019 at 5:44 PM Peter Gutmann 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Ian Swett <[email-masked]>
Date: Sat, 23 Nov 2019 20:48:17 -0500

I think it's ok to publish a document with the stated goals, but I think
this needs to be done with great care and the current document implies some
value judgements and implications I don't think are fully justified by the
document.  A 3rd author with a slightly different perspective may help
achieve the right balance.

In section 2, I believe you should note that the reason transport headers
have been exposed in the past is largely an accident, and what is exposed
may not be optimal for network monitoring and management purposes.  For
example, TCPs ACKs are a suboptimal way to measure network RTT unless
timestamps are available. And tracking losses requires substantial state
and assumptions about the loss detection algorithm on the part of the
observer.

The section(2.1) on transport ossification and middleboxes is well done,
thanks!

*Detailed points: *

2: Context and Rationale
 "To achieve stable Internet operations, the IETF transport community
   has to date relied heavily on the results of measurements and the
   insights of the network operations.."

The use of 'stable' here implies that without these measurements the
internet would be unstable.  I understand what you're trying to say, but
this needs a reword to avoid the implied collapse of the internet.  I'd
suggest you remove the word stable from this document, as it occurs 2 other
times in similar context.

2.3

I think this section is too vague.  The phrase "can be used" is used
frequently, but without a clear understanding of what the transport headers
are used for.  After reading further, some of this is defined in section
3.1.2, so maybe a forward reference is in order.

3.1.2:

"Throughput and Goodput" - Throughput seems to overlap with "Traffic Rate
and Volume".   I'd suggest reorganizing these into two items, one for
Goodput and one for Throughput/Traffic Rate/etc.

6.5:

"Concealing transport header..." Do you mean encrypting, or is there some
other method you have in mind?  This word is used 9 times in the document
and I don't think it's a good word choice.

7:

 "To achieve stable Internet operations, the IETF transport community
   has, to date, relied heavily on measurement and insights of the
   network operations community to understand the trade-offs, and to
   inform selection of appropriate mechanisms, to ensure a safe,
   reliable, and robust Internet (e.g., [RFC1273],[RFC2914])."

I don't believe RFC2914 should be grouped with RFC1273.  2914 is about
principles, and 1273 is about measurement.  Based on my reading, 2914 does
not provide evidence that measurement is necessary in order to achieve the
desired principles.

Also, one of these RFCs is almost 20 years old and the other is almost 30.
I don't think these are good support for the thesis that network operators
measurement abilities have been critical to what you're claiming, even if
it is still true today.

Thanks, Ian

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Sun, 24 Nov 2019 12:52:03 +0000

Hi Ian, Gorry and Colin,

please see a few hard-earned comments below, marked [acm],

Al

From: ippm [mailto:[email-masked]] On Behalf Of Ian Swett
Sent: Saturday, November 23, 2019 8:48 PM
To: Gorry Fairhurst <[email-masked]>
Cc: [email-masked]; [email-masked]; IETF IPPM WG ([email-masked]) <[email-masked]>; Peter Gutmann <[email-masked]>; tsvwg-chairs <[email-masked]>; [email-masked]; Joel M. Halpern <[email-masked]>; [email-masked]
Subject: Re: [ippm] [OPSAWG] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019

I think it's ok to publish a document with the stated goals, but I think this needs to be done with great care and the current document implies some value judgements and implications I don't think are fully justified by the document.  A 3rd author with a slightly different perspective may help achieve the right balance.
[acm]
It’s a difficult but worthwhile thing to achieve NPOV on a controversial topic.

IMO, this can be approached by asking all commenters to provide text for the memo
on the topic of interest, which will reveal their value judgements and opinions
for the reviewing community. Editing proceeds by taking many POV into account,
in the form of text contributions revised many times, not opinion only.

<snip lots of previous messages>
>> <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>>
>> See: https://tools.ietf.org/html/rfc5741#section-3.2.1<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc5741-23section-2D3.2.1&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=T5LgsMBzFOs4KRdiWIxX5pZQ7xbWAXguLkH3gX1DSrg&s=eHy4w8lVF3_5RVNdiWQacTXxIH9Qu1CQ0UQ6bD7yR0M&e=>
>> <https://tools.ietf.org/html/rfc5741#section-3..2.1<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc5741-23section-2D3..2.1&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=T5LgsMBzFOs4KRdiWIxX5pZQ7xbWAXguLkH3gX1DSrg&s=2njzfTabCITEFOP4yCl2iIYxUCu0gutlNauGYi81O9A&e=>>
>>
>> -Ekr
>>
>>
>>     Peter.
[acm] Actually, this is the relevant classification:

4.2.2 Informational

An "Informational" specification is published for the general information of the Internet community, and does not represent an Internet community consensus or recommendation.
From https://ietf.org/standards/process/informational-vs-experimental/
Choosing between Informational and Experimental Status
This document reproduces the rules for classifying documents as Informational and Experimental from RFC 2026, and amplifies those rules with guidelines relevant to ongoing IESG evaluations. It is not intended to change any of the underlying principles.
and it’s a déjà vu moment for me.

>> [email-masked]<mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/opsawg<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_opsawg&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=T5LgsMBzFOs4KRdiWIxX5pZQ7xbWAXguLkH3gX1DSrg&s=LFPzdVpELMweE5JzhSlf-MCi-1_TfUGwvjXeSB1OT84&e=>
>>