[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.)