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

["Brian Trammell (IETF)" <[e-mail]>]

hi Ted,

I still think that, as a statement of principles, this document is pretty much Ready To Go. The concrete signal and path property analysis ekr requested at the retreat in Montreal, on the other hand, seems like a thing PANRG could take up (indeed, see question 1 in draft-trammell-panrg-questions).

I'd be interested to get your opinion on the relationship between this and draft-trammell-wire-image, which we started to have a concise reference for what it is we mean when we say "wire image", but turns out, I think, to be quite complementary to this document in ways that it might make sense to consider merging them. Thoughts?

Cheers,

Brian


> On 1 Dec 2017, at 00:40, Ted Hardie <[e-mail]> 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]>
> 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]>
> 
> 
> 
> 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
> Status:         https://datatracker.ietf.org/doc/draft-hardie-path-signals/
> Htmlized:       https://tools.ietf.org/html/draft-hardie-path-signals-02
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-hardie-path-signals-02
> Diff:           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.
> 
> The IETF Secretariat
> 
> 
> _______________________________________________
> Stackevo mailing list
> [e-mail]
> https://www.iab.org/mailman/listinfo/stackevo