[Tsvwg] ECN nonce snag in TCP ESTATS MIB

Matt Mathis <mathis@psc.edu> Wed, 13 December 2006 19:18 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuZcH-0007v4-N3; Wed, 13 Dec 2006 14:18:09 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuZcH-0007uz-48 for tsvwg@ietf.org; Wed, 13 Dec 2006 14:18:09 -0500
Received: from mailer1.psc.edu ([128.182.58.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuZcE-0006v1-N8 for tsvwg@ietf.org; Wed, 13 Dec 2006 14:18:09 -0500
Received: from tesla.psc.edu (tesla.psc.edu [128.182.58.233]) by mailer1.psc.edu (8.13.8/8.13.3) with ESMTP id kBDJI6fh019484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Dec 2006 14:18:06 -0500 (EST)
Received: from localhost.psc.edu (localhost.psc.edu [127.0.0.1]) by tesla.psc.edu (8.13.1/8.13.1) with ESMTP id kBDJI52w000594; Wed, 13 Dec 2006 14:18:05 -0500
Date: Wed, 13 Dec 2006 14:18:05 -0500
From: Matt Mathis <mathis@psc.edu>
To: Transport WG <tsvwg@ietf.org>
Message-ID: <Pine.LNX.4.58.0612131113420.12485@tesla.psc.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Cc: TCP ESTATS MIB team <tcp-estats@ucar.edu>
Subject: [Tsvwg] ECN nonce snag in TCP ESTATS MIB
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Folks, this needs TSVWG input....

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.    The problem is with one object:

tcpEStatsPathECNNonceRcvd  OBJECT-TYPE
       SYNTAX          ZeroBasedCounter32
       MAX-ACCESS      read-only
       STATUS          current
       DESCRIPTION
          "Number of ECN Nonces (NS bits) received."
       REFERENCE
          "RFC3540, Robust Explicit Congestion Notification (ECN)
           Signaling with Nonces"
       ::= { tcpEStatsPathEntry 34 }

The recently posted doc is draft-ietf-tsvwg-tcp-mib-extension-13.txt
The current working draft is at:
http://www.psc.edu/~mathis/TcpExtendedMib/draft-ietf-tsvwg-tcp-mib-extension-13bis.txt
With an html word diff at:
http://www.psc.edu/~mathis/TcpExtendedMib/draft-ietf-tsvwg-tcp-mib-extension-13bis.wdiff.html


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?

Thanks,
--MM--
-------------------------------------------
Matt Mathis      http://www.psc.edu/~mathis
Work:412.268.3319    Home/Cell:412.654.7529
-------------------------------------------
Evil is defined by mortals who think they know
"The Truth" and use force to apply it to others.