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

Lorenzo Miniero <lorenzo@meetecho.com> Tue, 11 October 2016 16:46 UTC

Return-Path: <lorenzo@meetecho.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 4FB4C129659 for <gen-art@ietfa.amsl.com>; Tue, 11 Oct 2016 09:46:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.621
X-Spam-Level:
X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable 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 KebEUnfqfXOn for <gen-art@ietfa.amsl.com>; Tue, 11 Oct 2016 09:46:23 -0700 (PDT)
Received: from smtpcmd05149.aruba.it (smtpweb149.aruba.it [62.149.158.149]) by ietfa.amsl.com (Postfix) with ESMTP id 49149129656 for <gen-art@ietf.org>; Tue, 11 Oct 2016 09:46:23 -0700 (PDT)
Received: from lminiero ([93.44.60.74]) by smtpcmd05.ad.aruba.it with bizsmtp id uGmN1t0061c60R101GmNUA; Tue, 11 Oct 2016 18:46:23 +0200
Date: Tue, 11 Oct 2016 18:46:21 +0200
From: Lorenzo Miniero <lorenzo@meetecho.com>
To: Russ Housley <housley@vigilsec.com>
Message-ID: <20161011184621.4c9cd624@lminiero>
In-Reply-To: <1EC0E6E8-02F1-4CB8-88B0-2A399FC61E30@vigilsec.com>
References: <EE7359A5-ACD3-4CD1-B1B0-E01579203FFE@gmail.com> <1EC0E6E8-02F1-4CB8-88B0-2A399FC61E30@vigilsec.com>
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
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/jVEWXqJQrAA1rLNSZ6ORVuJ4eDk>
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-13
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: Tue, 11 Oct 2016 16:46:27 -0000

Hello Russ,

sorry for this late reply... thanks for reviewing the document! As to
the points you raised in your review, I've added a couple of comments
inline.


On Mon, 3 Oct 2016 15:26:30 -0400
Russ Housley <housley@vigilsec.com>; 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-13
> Reviewer: Russ Housley
> Review Date: 2016-10-03
> IETF LC End Date: 2016-10-10
> IESG Telechat date: unknown
> 
> 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.
> 


The standards-track scope of the document was also addressed and
discussed on the STRAW ML before LC, you can find the related
discussion here:

    https://www.ietf.org/mail-archive/web/straw/current/msg00579.html 

which lead to no objection to keep the document's scope as it is. Do
you believe the scope should change nevertheless?


> 
> Minor Concerns: In Section 3.1, it says:
> 
>    ... It SHOULD NOT, though, forward SDP
>    attributes that may lead to call failures (e.g., candidates,
>    fingerprints, crypto, etc.) for different reasons out of scope to
>    this document. ...
> 
> This SHOULD NOT statement if a bit vague.  The previous sentence lists
> specific attributes, and I see why that might be difficult to match
> here, but it does not tell an implementer what attributes to not
> forward.
> 


The SHOULD NOT statement is indeed a bit vague, but that's due to the
dynamic nature of SDP attributes, and the fact that new ones could be
added at any time. We tried to clarify what we meant by listing some of
the categories that, messed with improperly, could cause issues (the
candidates, fingerprints, crypto we mention in brackets), but an
exhaustive list is unfortunately impossible. Do you believe that making
the enumeration in brackets clearer, e.g.:

	(e.g., attributes listing candidates, fingerprints, crypto,
	etc.)

would make the sentence clearer, or do you still think that would need
work? Do you have any suggestion on how to improve the text here?

Thanks!
Lorenzo