[AVTCORE] AD Evaluation draft-ietf-avtcore-rfc5285-bis-08
"Ben Campbell" <ben@nostrum.com> Thu, 23 March 2017 22:22 UTC
Return-Path: <ben@nostrum.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96FC6127097; Thu, 23 Mar 2017 15:22:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.881
X-Spam-Level:
X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 db_i7MFKaEb3; Thu, 23 Mar 2017 15:22:32 -0700 (PDT)
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 A1B8212950B; Thu, 23 Mar 2017 15:22:32 -0700 (PDT)
Received: from [10.0.1.39] (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 v2NMMUeI099029 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 23 Mar 2017 17:22:31 -0500 (CDT) (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.39]
From: Ben Campbell <ben@nostrum.com>
To: draft-ietf-avtcore-rfc5285-bis.all@ietf.org, IETF AVTCore WG <avt@ietf.org>
Date: Thu, 23 Mar 2017 17:22:30 -0500
Message-ID: <AF706FC8-E536-4441-A6A1-96DAA26EE91D@nostrum.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=_MailMate_D630AF98-3504-4985-96B6-19DC8A7B0E3D_="
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.6r5347)
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/YeTfqpX8xA6bKtmVphpwEbyD6W0>
X-Mailman-Approved-At: Fri, 24 Mar 2017 02:34:36 -0700
Subject: [AVTCORE] AD Evaluation draft-ietf-avtcore-rfc5285-bis-08
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Mar 2017 22:22:35 -0000
Hi, This is my AD evaluation of draft-ietf-avtcore-rfc5285-bis-08. These are mostly editorial, but I'd like to resolve at least the substantive comments prior to IETF last call. Thanks! Ben. - Substantive: -- 6, paragraph 3, "... unless the transmitter has some (out of band) knowledge..." Why bother with that exception? It seems like the negotiation is easy enough. If people write code assuming that out-of-band knowledge will be available, interoperability will suffer. -- 9, 2nd paragraph: 3264 does not require integrity protection to be _used_, just _provided_ (read: MUST implement). Does this mean to promote that to "MUST use"? If so, please be clear that this is a new requirement. But from a practical perspective, do you believe people will really follow a "MUST use"? Is it a MUST (BUT WE KNOW YOU WON”T) [RFC6919] ? - Editorial: -- 3, third paragraph: This changes the "... mechanism may be available..." from the original to "... mechanism can be available...". I think "may be" is more correct here. -- 4.1.1, first paragraph, first sentence: This is a statement of principle, and as such shouldn't use 2119 keywords. -- 4.1.2, 2nd paragraph: s/len/length ; or "len field" (2 occurances) -- 4.1.2, 3rd paragraph, sentence starting with "Only the extension..." “Only…MUST” constructs are ambiguous. The can be interpreted to say the MUST only applies to the matching set, and the rest are undefined. Please recast as “MUST NOT ”. (Note that this construct appears elsewhere in the draft, but I think the other occurrences are in the original text. I don't expect this update to fix those.) --- "A transmitter MAY be aware...": That's a statement of fact; the MAY should not be capitalized. -- 4.2, first sentence, first paragraph: The REQUIRED seems to be talking about an external requirement from RTP. If so, it should not be normative here. -- 7, 11th paragraph, "Local identifiers in the valid range inclusive in an offer or answer MUST NOT be used more than once per media section" The MUST NOT was not capitalized in 5285, probably because it was the 4th time the requirement was mentioned :-). I don't think it needs to be promoted here. -- 9, 1st paragraph: I don’t think this is an appropriate use of a 2119 MUST. (It wasn’t capitalized in the original.)
- [AVTCORE] AD Evaluation draft-ietf-avtcore-rfc528… Ben Campbell