Re: [rmcat] AD review of draft-ietf-rmcat-sbd-09

Michael Welzl <> Tue, 06 February 2018 17:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 88F65126CF6 for <>; Tue, 6 Feb 2018 09:07:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.209
X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oYA1vrSCA-5F for <>; Tue, 6 Feb 2018 09:07:42 -0800 (PST)
Received: from ( [IPv6:2001:700:100:8210::71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6CEFB12D84F for <>; Tue, 6 Feb 2018 09:07:42 -0800 (PST)
Received: from ([]) by with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from <>) id 1ej6iZ-00083y-Ac; Tue, 06 Feb 2018 18:07:39 +0100
Received: from ([] helo=[]) by with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from <>) id 1ej6iW-000GMC-BC; Tue, 06 Feb 2018 18:07:39 +0100
From: Michael Welzl <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_D52F6E35-7A9A-4588-890A-538004A17995"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Tue, 6 Feb 2018 18:07:33 +0100
In-Reply-To: <>
Cc: Anna Brunstrom <>, "rmcat WG (" <>,
To: =?utf-8?Q?Mirja_K=C3=BChlewind?= <>
References: <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3273)
X-UiO-SPF-Received: Received-SPF: neutral ( is neither permitted nor denied by domain of client-ip=;; helo=[];
X-UiO-Spam-info: not spam, SpamAssassin (score=-4.9, required=5.0, autolearn=disabled, AWL=0.083, HTML_MESSAGE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 4F7412587CDEA5E524FB46F36C39F762838D03B5
Archived-At: <>
Subject: Re: [rmcat] AD review of draft-ietf-rmcat-sbd-09
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 06 Feb 2018 17:07:44 -0000


I’m cutting away some things and only answering on the part that speaks to me as one of the authors:

>>> We believe that Experimental status is more fitting; we looked at the checklist here, from which this seems a pretty clear decision to us:
> So I would like to add something here. I don't know why you think from this text that experimental is the better fit, but I think both are suitable and therefore I'm also fine to move on with experimental but I wanted to make sure that this has been considered.

1. If it can't be practiced, it's Informational.  => this is an algorithm, it can be practiced.
2. If it's not going to be changed no matter what the result is, it's Informational  => that’s not the case, see my answer below regarding “will never touch it again”.
3. (..)work that could be practiced, was developed in the IETF, has been dropped for some reason, but is being published for the record(..) Informational or Historic  => that’s also not the case.
4. If the IETF may publish something based on this on the standards track once we know how well this one works, it's Experimental  => again the point below, I do think this can go to standards track after more experience.
5. If the document contains implicit or explicit success/failure criteria, and it's clear that the outcome can be used as the basis for a recommendation to the IETF community, it's Experimental  => well there’s a section on expected feedback from experiments.

> So both informational and experimental do not need to have IETF consensus (but as I said they usually have); so no difference in this aspect. Experimental docs are usually specs that are not ready for proposed standard yet but experimentation in the Internet is needed to move forward. However, sbd is not really a spec, it's more a documentation of a mechansims. As such I think it could also be moved forward as informational.

I don’t see what makes you say that this isn’t really a spec? It should be, it’s meant to be a spec.

> The difference for me at this point is, are there any plans to move it forward to proposed standard as any point in the future, or do we keep this document as a documentation of the proposed mechanism and probably will never touch it again?

Well, it’s certainly my plan as one of the authors to move this forward to proposed standard at some point in the future. We’re actively working on this.

>> Ok, thanks for the feedback Michael. Then we stay with experimental.
> Assuming, we have a decision on the indented status (going for exp as the current version said). Would you like to submit another update before IETF last call, or should I just start the IETF last right away?

We’d like to do another update - there were some recommendations here: removing the reference to coupled-cc from the abstract, different boilerplate and your editorial comments. This may take a little bit (I’m not the only author).