Re: [Stackevo] Fwd: New Version Notification for draft-hardie-path-signals-02.txt

[Eliot Lear <[e-mail]>]

Hi Ted,

Following up on Brian's comment, as I wrote to you the last time, I
really like this draft.  For some reason, Section 3.1.1 seems to have
suffered editorially and needs just a bit of work.

Eliot


On 01.12.17 00:40, Ted Hardie wrote:
> As discussed in the last meeting, I have updated this slightly and
> brought it back into circulation.  The changes are very small
> (updating a reference, slightly enlarged pointer to fingerprinting risk).
>
> Hack away,
>
> Ted
>
>
> ---------- Forwarded message ----------
> From: <[e-mail] <mailto:[e-mail]>>
> Date: Thu, Nov 30, 2017 at 3:39 PM
> Subject: New Version Notification for draft-hardie-path-signals-02.txt
> To: Ted Hardie <[e-mail] <mailto:[e-mail]>>
>
>
>
> A new version of I-D, draft-hardie-path-signals-02.txt
> has been successfully submitted by Ted Hardie and posted to the
> IETF repository.
>
> Name:           draft-hardie-path-signals
> Revision:       02
> Title:          Path signals
> Document date:  2017-11-30
> Group:          Individual Submission
> Pages:          8
> URL:           
> https://www.ietf.org/internet-drafts/draft-hardie-path-signals-02.txt
> <https://www.ietf.org/internet-drafts/draft-hardie-path-signals-02.txt>
> Status:       
>  https://datatracker.ietf.org/doc/draft-hardie-path-signals/
> <https://datatracker.ietf.org/doc/draft-hardie-path-signals/>
> Htmlized:     
>  https://tools.ietf.org/html/draft-hardie-path-signals-02
> <https://tools.ietf.org/html/draft-hardie-path-signals-02>
> Htmlized:     
>  https://datatracker.ietf.org/doc/html/draft-hardie-path-signals-02
> <https://datatracker.ietf.org/doc/html/draft-hardie-path-signals-02>
> Diff:         
>  https://www.ietf.org/rfcdiff?url2=draft-hardie-path-signals-02
> <https://www.ietf.org/rfcdiff?url2=draft-hardie-path-signals-02>
>
> Abstract:
>    TCP's state mechanics uses a series of well-known messages that are
>    exchanged in the clear.  Because these are visible to network
>    elements on the path between the two nodes setting up the transport
>    connection, they are often used as signals by those network elements.
>    In transports that do not exchange these messages in the clear, on-
>    path network elements lack those signals.  This document discusses
>    the nature of the signals as they are seen by on-path elements and
>    reflects on best practices for transports which encrypt their state
>    mechanics.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org
> <http://tools.ietf.org>.
>
> The IETF Secretariat
>
>
>
>
> _______________________________________________
> Stackevo mailing list
> [e-mail]
> https://www.iab.org/mailman/listinfo/stackevo