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

"Ben Campbell" <ben@nostrum.com> Wed, 30 November 2016 21:25 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 667EF129AFC; Wed, 30 Nov 2016 13:25:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.796
X-Spam-Level:
X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id po_GwltpOWUx; Wed, 30 Nov 2016 13:25:48 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 577EA129ABC; Wed, 30 Nov 2016 13:25:48 -0800 (PST)
Received: from [10.0.1.21] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uAULPjxJ014395 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 30 Nov 2016 15:25:46 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.21]
From: "Ben Campbell" <ben@nostrum.com>
To: "Russ Housley" <housley@vigilsec.com>
Date: Wed, 30 Nov 2016 15:25:45 -0600
Message-ID: <92BB4547-6C86-4BF9-BE5E-1A3C3BF17319@nostrum.com>
In-Reply-To: <4290FCC3-4840-4F17-9B9B-8889329B2C19@vigilsec.com>
References: <EE7359A5-ACD3-4CD1-B1B0-E01579203FFE@gmail.com> <4290FCC3-4840-4F17-9B9B-8889329B2C19@vigilsec.com>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.6r5310)
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/J9ATdX0pAKApXO0PG3UV3fvEGIg>
Cc: draft-ietf-straw-b2bua-rtcp.all@ietf.org, IETF Gen-ART <gen-art@ietf.org>
Subject: Re: [Gen-art] Gen-ART Review of draft-ietf-straw-b2bua-rtcp-15
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Nov 2016 21:25:50 -0000

Hi Russ, please see inline:

Thanks!

Ben.

On 25 Nov 2016, at 14:30, 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
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>;.
>
> 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.

You may recall you and I had a private email discussion back in October, 
after your LC review concerning the PS status. We discussed that the 
working group had also informational or BCP, but decided to stick with 
PS. (This came up in my AD evaluation as well.) Unless you strongly 
object, I am inclined to let them stick with PS.

>
>
> 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

While the authors attempted to clarify this, the current draft still got 
similar comments from Alissa and Alia in the IESG review. They've both 
proposed clarifying text--hopefully the combination will fix this.