Re: [Tsv-art] Tsvart telechat review of draft-ietf-6man-rfc6434-bis-08

Spencer Dawkins at IETF <> Thu, 12 July 2018 21:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CCC741311AD; Thu, 12 Jul 2018 14:46:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id p9giZhe0xDuK; Thu, 12 Jul 2018 14:46:34 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 209F413119F; Thu, 12 Jul 2018 14:46:34 -0700 (PDT)
Received: by with SMTP id x15-v6so11997340ybm.2; Thu, 12 Jul 2018 14:46:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EI3lhK9Ai0hKJn7TBqPtBp+pA7gC13OAHiA7qu6a250=; b=R/akjQmv+WBSlUMDc0yDYwumaSamU9L1XJU7W4vlnEjvdGQFCGzpbyui8cBwir2vww /2SKCSFLNPuseZBf4xrY45KDsGHlTt1TvvOa0ruxoNXZHgs2XBysBslS5ofgcswhpyED F1V9RmUP7ENB7rU0Jx/s1+Ige2L1lhtJnyx8dCm+9PQVHs/SuXsaqUiEmHZzJBM/n2Ri uwIvj5qxvTPXzoWe5XHIRoEVjgHeHXxZLY2I5C5WoKX+31a8bcrHWystuOZTH19LfNp8 WH29HJf/TNwHZz8t9MoSzWUuk/OPw1D3fOwdAfBjM7LAoJJ/JKZqA6OwZNraIn2ofOho mHIQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EI3lhK9Ai0hKJn7TBqPtBp+pA7gC13OAHiA7qu6a250=; b=tzkHnk8lb2wwTb2t3Ls+HVBc6u+64UPwYP/pZJVI9hyfnM6q7Cot3BVte/+9eGnl+w SVUvrl5y8bNdbi4cAtN6FS7VQju5PdptPxUrhwersHebIiiWRtirybEAueHPlRFaf+kn 0TnawhQVShWMmN98J5mdFkJCU23Rdbgl1rR3GXTq8CCI9zE60Y9BUm4EWFQbuBsSReep 6fvcI4LV7Wg9ZAuF17KUZzhIkWRoP/vo8JtkHask7Ka92my7iXhkRUGNkttfToV46yaU OqQYaCJXvDL8fhzpa8fJbrTeJFumI6iIgYU79sVlaEIj3/ml0SHWLBdiaxUQjkN7euZV uzjA==
X-Gm-Message-State: AOUpUlGLVpNfVXypWSP17yzm7rRR9biafjkcNGEDNNifb5qU9ezaRkt3 yXhWb9dCccqu5M9SvYC2p5AfK8Nq0FgnRJmzsIA=
X-Google-Smtp-Source: AAOMgperfHN+X+RLbmzWEAe26Yq9wkHW3VccxJcWJ0xOxTHtELvqeAE8rSf2hCbfgWfTnaLLgkRJGWCIGLUDn3XaIrk=
X-Received: by 2002:a25:2557:: with SMTP id l84-v6mr2131922ybl.110.1531431992984; Thu, 12 Jul 2018 14:46:32 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Spencer Dawkins at IETF <>
Date: Thu, 12 Jul 2018 16:46:21 -0500
Message-ID: <>
To: Mirja Kuehlewind <>
Cc:, Magnus Westerlund <>, IPv6 List <>,, "Black, David" <>,, Brian E Carpenter <>
Content-Type: multipart/alternative; boundary="000000000000f08af50570d44bdb"
Archived-At: <>
Subject: Re: [Tsv-art] Tsvart telechat review of draft-ietf-6man-rfc6434-bis-08
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Transport Area Review Team <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 12 Jul 2018 21:46:37 -0000

This might or might not be a helpful observation ... but you know me.
On Thu, Jul 12, 2018 at 3:48 PM Mirja Kuehlewind (IETF) <>

> The wg is actually cc’ed in this thread :-) Maybe it would be easy enough
> to double-check with the group at the meeting next week..? I don’t think
> this would require another wg last call or anything but that actually lies
> in the judgment of the chairs (and responsible AD).

Without reference to how, when, or where the conversation about SHOULD ->
MUST happens, it's worth noting that as long as our only AQM recommendation
was RFC 2309/RED, and RED wasn't being widely used for various reasons, a
SHOULD for upper layers being able to access and set ECN bits was
aspirational - not wrong, but not strongly motivated, ISTM.

Given that we've obsoleted the recommendation to use RED, produced a BCP
for AQM behaviors, produced PIE and CoDel as Experimental, reclaimed the
ECT(1) bit for experimentation, and are actively working on L4S, it may be
worth having the conversation about SHOULD -> MUST at this point in the
process, rather than the next time IPv6 Node Requirements are considered.

But do the right thing, of course.


> > Am 12.07.2018 um 16:23 schrieb Timothy Winters <>du>:
> >
> >
> > On Thu, Jul 12, 2018 at 3:59 PM Mirja Kuehlewind (IETF) <
>> wrote:
> > Hi Timothy,
> >
> > thanks, this looks already better. However, I’m afraid that saying
> "Nodes SHOULD implement [RFC3168]“ doesn’t say much because (and correct me
> if I’m wrong) RFC3168 does actually not say much about the role of IP end
> nodes. So maybe it would be better to be more explicit and say something
> like "Nodes SHOULD support [RFC3168] by implementing an interface for the
> upper layer to access and set the ECN bits in the IP header.“ Does that
> work for you?
> > That works for me and will be the new text in draft 09.
> >
> > Also regarding the question for small footprint nodes: given all you
> need to do in your implementation is providing an interface, I would
> actually think that a MUST is not really a burden here. Actually it would
> be said if we end up in an all-ECN world (yes, this is still just a dream)
> and then suddenly the small footprint nodes, which could probably highly
> benefit from ECN, would be the only devices that are not ECN capable.
> > Since this is a change from SHOULD to MUST we would need to get the
> working group thoughts on this change, if you really feel that all IP nodes
> should have an interface to upper layer access to ECN bits in the header.