IETF Logo Mail Archive

Re: [Id-event] Barry Leiba's No Objection on draft-ietf-secevent-http-push-12: (with COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Thu, 25 June 2020 22:13 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: id-event@ietfa.amsl.com
Delivered-To: id-event@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2713A1065; Thu, 25 Jun 2020 15:13:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 tU9t3WsR2BdD; Thu, 25 Jun 2020 15:13:16 -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 39E023A1082; Thu, 25 Jun 2020 15:13:16 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 05PMD8fU003445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 25 Jun 2020 18:13:11 -0400
Date: Thu, 25 Jun 2020 15:13:07 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>
Cc: Barry Leiba <barryleiba@computer.org>, The IESG <iesg@ietf.org>, "secevent-chairs@ietf.org" <secevent-chairs@ietf.org>, Yaron Sheffer <yaronf.ietf@gmail.com>, "draft-ietf-secevent-http-push@ietf.org" <draft-ietf-secevent-http-push@ietf.org>, "id-event@ietf.org" <id-event@ietf.org>
Message-ID: <20200625221307.GB58278@kduck.mit.edu>
References: <CH2PR00MB06782E27377CB39E690B549DF5920@CH2PR00MB0678.namprd00.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CH2PR00MB06782E27377CB39E690B549DF5920@CH2PR00MB0678.namprd00.prod.outlook.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/id-event/0MKBydca6IB4jvyUCQcw_yYkvCI>
Subject: Re: [Id-event] Barry Leiba's No Objection on draft-ietf-secevent-http-push-12: (with COMMENT)
X-BeenThere: id-event@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." <id-event.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/id-event>, <mailto:id-event-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/id-event/>
List-Post: <mailto:id-event@ietf.org>
List-Help: <mailto:id-event-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/id-event>, <mailto:id-event-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jun 2020 22:13:29 -0000

Thanks for the updates, Mike.  Just one note...

On Thu, Jun 25, 2020 at 05:54:32AM +0000, Mike Jones wrote:
> Thanks for your review, Barry.  https://tools.ietf.org/html/draft-ietf-secevent-http-push-13 is intended to address your comments.  Detailed replies are inline, prefixed by "Mike>".
> 
> -----Original Message-----
> From: Barry Leiba via Datatracker <noreply@ietf.org> 
> Sent: Wednesday, June 24, 2020 1:41 PM
> To: The IESG <iesg@ietf.org>
> Cc: draft-ietf-secevent-http-push@ietf.org; secevent-chairs@ietf.org; id-event@ietf.org; Yaron Sheffer <yaronf.ietf@gmail.com>; yaronf.ietf@gmail.com
> Subject: Barry Leiba's No Objection on draft-ietf-secevent-http-push-12: (with COMMENT)
> 
[...]
> — Section 7.1 —
> 
>    Future assignments are to be made
>    through the Specification Required registration policy
> 
> Please provide some brief guidance to the designated experts.  Thanks.
> 
> Mike> Done - mostly copying applicable guidance from the JWT spec [RFC 7519]

Unfortunately, the RFC 7519 guidance is perhaps a bit lacking, in that
while it says the experts should consider several factors (duplication of
existing functionality, general vs. specific applicability, etc.), it
doesn't say very clearly which direction any given factor should move the
experts in.  For example, while I expect near-universal agreement that
duplicating existing functionality should receive pushback, the agreement
may be less clear that proposals that are only useful by a single
application should get pushback.

I think we've done a little better with our guidance to experts in more
recent RFCs, but my spot-checking failed to find one that I liked.

-Ben

v2.23.0 | Report a Bug | By Email