Re: [Tsvwg] ECN nonce snag in TCP ESTATS MIB

[Sally Floyd <[e-mail]>]

Matt -

> The document draft-ietf-tsvwg-tcp-mib-extension has been stalled due 
> to a
> "DOWNREF",  a normative reference from a standards track document to
> to a less mature document.  In this case to an Experimental Protocol, 
> RFC3540,
> Robust ECN Signaling with Nonces.
...
> There are two obvious approaches to fix this:
> 1) Pursue the downref procedure in RFC 3967.  This entails writing a
> justification for the downward reference and re-issuing the IETF last 
> call.
> 2) Deleting the object entirely.  Since this is a substantial 
> technical change
> to the document, it requires re-issuing the TSVWG LC and possibly the 
> IETF LC.
>
> I am willing to pursue either approach, however I think it would be 
> best to
> match the likely ultimate trajectory for RFC 3540.
>
> My questions:
> Are there any known implementations of RFC3540 in the field?
>
> Can somebody provide some pointers to either dependent or alternative
> nonce mechanisms?
>
> Given that RFC 3540 conflicts with RE-ECN, what is (your opinion of) 
> the
> likely trajectory for RFC 3540?

My apologies for the long delay in getting to this.  If this is still 
an open question,
my preference would be for (1), writing a justification for the 
downward reference,
and keeping the ECN nonce item in the TCP MIB.  I don't know of any 
implementations
of RFC 3540.  However, my own prediction would be that RFC 3540 would
eventually become Proposed Standard, regardless of the fact that RE-ECN
conflicts with the ECN Nonce.  For a first draft of mine on why RFC 3540
should go to Proposed Standard (not yet submitted as an 
internet-draft), you could see
the following:
   "http://www.icir.org/floyd/papers/draft-floyd-tsvwg-ecn-nonce-00a.txt"

- Sally
http://www.icir.org/floyd/