Re: [netconf] Secdir last call review of draft-ietf-netconf-restconf-notif-13

Benjamin Kaduk <kaduk@mit.edu> Sat, 20 April 2019 03:56 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2F0120497; Fri, 19 Apr 2019 20:56:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 J-wGQayb79jt; Fri, 19 Apr 2019 20:56:23 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 839361203DD; Fri, 19 Apr 2019 20:56:20 -0700 (PDT)
Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x3K3uDlZ029905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 19 Apr 2019 23:56:15 -0400
Date: Fri, 19 Apr 2019 22:56:13 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: "Reshad Rahman (rrahman)" <rrahman@cisco.com>
Cc: Aanchal Malhotra <aanchal4@bu.edu>, "secdir@ietf.org" <secdir@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "draft-ietf-netconf-restconf-notif.all@ietf.org" <draft-ietf-netconf-restconf-notif.all@ietf.org>, "netconf@ietf.org" <netconf@ietf.org>
Subject: Re: [netconf] Secdir last call review of draft-ietf-netconf-restconf-notif-13
Message-ID: <20190420035612.GR51586@kduck.mit.edu>
References: <155501965074.14152.2835369201856309773@ietfa.amsl.com> <FFD7F554-4E88-49E5-9D16-DF0B64BC5FF5@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <FFD7F554-4E88-49E5-9D16-DF0B64BC5FF5@cisco.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/1r7T2osKU9O1sdEVILNRiRDbnAk>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 20 Apr 2019 03:56:26 -0000

On Fri, Apr 12, 2019 at 09:29:35PM +0000, Reshad Rahman (rrahman) wrote:
> Hi Aanchal,
> 
> Thanks for the review. Please see inline.
> 
> On 2019-04-11, 5:54 PM, "netconf on behalf of Aanchal Malhotra via Datatracker" <netconf-bounces@ietf.org on behalf of noreply@ietf.org> wrote:
> 
>     Reviewer: Aanchal Malhotra
>     Review result: Ready
>     
>     The document is very clear and concise.  I just have one minor clarification question.
>     Section 3.4 Page 9 that says the following:
>     "In addition to any required ........SHOULD only be allowed......".  
>     
>     Is there a reason for using SHOULD instead of MUST? 
> 
> There may be reasons why an implementation decides not to enforce this restriction. Going by RFC2119 definitions, this is why we chose SHOULD instead of MUST.

If you have some reasons in mind, it is often helpful to list them as
examples of when the recommended behavior would not be followed.

Thank you Aanchal for the review!

-Ben