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

Benjamin Kaduk <kaduk@mit.edu> Mon, 29 April 2019 03:00 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5148120295; Sun, 28 Apr 2019 20:00:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 hGmeJKWRIDbl; Sun, 28 Apr 2019 20:00:11 -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 8AFCD120294; Sun, 28 Apr 2019 20:00:10 -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 x3T304G3025484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 28 Apr 2019 23:00:05 -0400
Date: Sun, 28 Apr 2019 22:00:03 -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>
Message-ID: <20190429030003.GJ60332@kduck.mit.edu>
References: <155501965074.14152.2835369201856309773@ietfa.amsl.com> <FFD7F554-4E88-49E5-9D16-DF0B64BC5FF5@cisco.com> <20190420035612.GR51586@kduck.mit.edu> <7820A8E4-692B-43D2-9611-437CC440EBC7@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <7820A8E4-692B-43D2-9611-437CC440EBC7@cisco.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/2HdHqzmEFcN-WjRvXsNiBCTV2nE>
Subject: Re: [netconf] Secdir last call review of draft-ietf-netconf-restconf-notif-13
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Apr 2019 03:00:13 -0000

On Wed, Apr 24, 2019 at 05:53:02PM +0000, Reshad Rahman (rrahman) wrote:
> On 2019-04-19, 11:56 PM, "Benjamin Kaduk" <kaduk@mit.edu>; wrote:
> 
>     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.
> 
> What we had in mind is a "super-user" who could be given access to subscriptions of other users. Is this obvious or should I can add text to that effect at the end the bullet below? Something along the lines of "For example, a RESTCONF username with the required administrative permissions could be allowed to invoke RPCs modify-subscription, resync-subscription and delete-subscription on a subscription which was created by another username.".
> 
>    o  In addition to any required access permissions (e.g., NACM), RPCs
>       modify-subscription, resync-subscription and delete-subscription
>       SHOULD only be allowed by the same RESTCONF username [RFC8040]
>       which invoked establish-subscription.

I think it might help to have such text, though I would suggest a slightly
pithier "Such a restriction generally serves to preserve users' privacy, but
exceptions might be made for administrators that may need to modify or
delete other users' subscriptions."

Thanks,

Ben