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

[Ian Swett <[e-mail]>]

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


On Tue, Nov 5, 2019 at 5:27 AM Gorry Fairhurst <[e-mail]> wrote:

> 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:
> > 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
> >> <[e-mail] <mailto:[e-mail]>> wrote:
> >>
> >>     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.
> >>
> >>
> >> 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
> >> <https://tools.ietf.org/html/rfc5741#section-3..2.1>
> >>
> >> -Ekr
> >>
> >>
> >>     Peter.
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> OPSAWG mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/opsawg
> >>
>
>