Re: [Gen-art] Gen-ART Review of draft-ietf-straw-b2bua-rtcp-15

Lorenzo Miniero <> Tue, 29 November 2016 11:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 743E2129B59 for <>; Tue, 29 Nov 2016 03:48:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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 iYIx7J0g0oEu for <>; Tue, 29 Nov 2016 03:48:23 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id A3AF11299BB for <>; Tue, 29 Nov 2016 03:43:07 -0800 (PST)
Received: from lminiero.lan ([]) by with bizsmtp id Dnj51u01F2MLHNd01nj6L2; Tue, 29 Nov 2016 12:43:06 +0100
Date: Tue, 29 Nov 2016 12:43:05 +0100
From: Lorenzo Miniero <>
To: Russ Housley <>
Message-ID: <20161129124305.5dd5fc85@lminiero.lan>
In-Reply-To: <>
References: <> <>
Organization: Meetecho
X-Mailer: Claws Mail 3.13.1 (GTK+ 2.24.29; x86_64-redhat-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=a1; t=1480419786; bh=0XJadYDi8hJTxn+a4UBYOFeD9yrN1VvFd5+lAx0UrdE=; h=Date:From:To:Subject:MIME-Version:Content-Type; b=WToIfP5jM+BIK6QDtAI1zf8/qXzPZ1887bGwztOg0G12oOJdUVv6tFxZ+KeZD7h6s LYWvPBVvYOr9onduRfW3SJUt+fmgI/KGaXui67V87m2G0BO96pzCe8LK0gzJIuvvQq c03HlKbhNdZ6fUjgnqGwh61Zf1BtOjahr/nInLnQoEvvGPXAeBVVNViXpQoFXGtlJF 647kkP02kzvLA6pj0Vr7H/7G0DPAE1l/fcp2LgEtqy7osa5jU9QhVIzp4lrRyow059 5sarg0jHaTZ3nSDJAMv7Om0N0qJmqyyrx69DUUnlQQyppYYtrX04bL+hdYFgI4fpK/ kyzT3pGsJNyQQ==
Archived-At: <>
Cc:, IETF Gen-ART <>
Subject: Re: [Gen-art] Gen-ART Review of draft-ietf-straw-b2bua-rtcp-15
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 29 Nov 2016 11:48:25 -0000

On Fri, 25 Nov 2016 15:30:30 -0500
Russ Housley <> wrote:

> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair. Please wait for direction from your
> document shepherd or AD before posting a new version of the draft.
> For more information, please see the FAQ at
> <>.

Hi Russ,

thanks for this new review!

> Document: draft-ietf-straw-b2bua-rtcp-15
> Reviewer: Russ Housley
> Review Date: 2016-11-25
> IETF LC End Date: 2016-10-10
> IESG Telechat date: 2016-12-01
> Summary: Almost Ready
> Major Concerns
> I wonder if this ought to be a standards-track document.
> I recognize that the STRAW WG charter calls for a standards-track
> document, but it only contains a handfull of MUST statements that are
> not repeats from another RFC.  Maybe this document should become a
> Best Current Practice (BCP) instead of a standards-track document.

We actually discussed this in your previous review as well. I can't
find the final points or decision on this in that discussion, but I
explained there how the WG came to the conclusion it was ok for this to
be standards track. You can find the related WG discussion here: 

which lead to no objection to keep the document's scope as it is. Not
sure how we should proceed on this at this point: I still believe a
standards-track document is more appropriate.

> Minor Concerns
> In Section 3.1, it says:
>    ...  However, certain SDP attributes may
>    lead to call failures when forwarded by a media relay.  Such
>    attributes SHOULD NOT be forwarded.  One notable example is the
>    'rtcp' [RFC3605] attribute, that UAC may make use of to explicitly
>    state the port they're willing to use for RTCP.  ...
> This SHOULD NOT statement is vague.  One example of an attribute that
> should not be forwarded is given, and the previous sentence provides
> some specific attributes that should be forwarded.  While I see why it
> is difficult to not be vague, some better advice to the implementer
> could be very helpful

This point was also addressed in your original review, and I tried to
fix it and make it clearer with this text change here:

Do you believe it's still ambiguous as it is? Do you have any
suggestion on how to improve the text and fix this? Maybe mentioning a
couple of attributes we talk about subsequently with something like
"Other examples are attributes like X and Y, for reasons that will
become clearer in latter sections"?