Re: [secdir] Secdir review of draft-ietf-sipcore-refer-explicit-subscription-02

"Ben Campbell" <ben@nostrum.com> Tue, 23 June 2015 14:33 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD4B01B2C78; Tue, 23 Jun 2015 07:33:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 bPPI03Npv2dy; Tue, 23 Jun 2015 07:33:18 -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 CBD6E1A0211; Tue, 23 Jun 2015 07:33:18 -0700 (PDT)
Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t5NEX7FT009225 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 23 Jun 2015 09:33:18 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23]
From: Ben Campbell <ben@nostrum.com>
To: Vincent Roca <vincent.roca@inria.fr>
Date: Tue, 23 Jun 2015 09:33:07 -0500
Message-ID: <87B34D50-F69C-4436-A470-A5F56FF4EE42@nostrum.com>
In-Reply-To: <DCB97AA2-6243-4266-B145-B6B6834AE627@inria.fr>
References: <2E90B73E-0309-4C49-B208-C2E30A0B6B22@inria.fr> <55882D28.3020701@nostrum.com> <DCB97AA2-6243-4266-B145-B6B6834AE627@inria.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.1r5084)
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/0YvEWdEku933iQw1mCOgGzCxg0s>
Cc: draft-ietf-sipcore-refer-explicit-subscription@tools.ietf.org, secdir@ietf.org, IESG <iesg@ietf.org>
Subject: Re: [secdir] Secdir review of draft-ietf-sipcore-refer-explicit-subscription-02
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Jun 2015 14:33:20 -0000

On 23 Jun 2015, at 3:02, Vincent Roca wrote:

> Ben made a similar comment. The first 2119 requirement you point to 
> needs to move up into the protocol definition part of the document.
>>> The second is restating text that’s in RFC3261, and we don't need 
>>> to repeat the 2119 here - I'll clarify the language to say "use the 
>>> mechanisms the base specification provides".
>
>
>
> VR: IMHO repeating normative vocabulary is not an issue as long as it 
> is used homogeneously in the whole document,
> whereas the opposite would be an issue.

While this is small enough to not matter either way, in general I prefer 
not to have multiple occurrences of the same normative statement, unless 
one clearly refers to the other. Even if they are in sync, it can cause 
confusion for people trying to reference authoritative text, and an 
opportunity for error in future updates.