[Id-event] Robert Wilton's No Objection on draft-ietf-secevent-http-poll-11: (with COMMENT)
Robert Wilton via Datatracker <noreply@ietf.org> Mon, 22 June 2020 16:51 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: id-event@ietf.org
Delivered-To: id-event@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A7EC83A0D5D; Mon, 22 Jun 2020 09:51:01 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Robert Wilton via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-secevent-http-poll@ietf.org, secevent-chairs@ietf.org, id-event@ietf.org, Yaron Sheffer <yaronf.ietf@gmail.com>, yaronf.ietf@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.3.2
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Robert Wilton <rwilton@cisco.com>
Message-ID: <159284466166.18019.3296058026904481529@ietfa.amsl.com>
Date: Mon, 22 Jun 2020 09:51:01 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/id-event/dpYHeStzIFS9bY6f18E3COJerWE>
Subject: [Id-event] Robert Wilton's No Objection on draft-ietf-secevent-http-poll-11: (with COMMENT)
X-BeenThere: id-event@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 22 Jun 2020 16:51:02 -0000
Robert Wilton has entered the following ballot position for draft-ietf-secevent-http-poll-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-secevent-http-poll/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi, I found that document easy to read/understand (despite not really knowing what "SET"s are). However, I did have a query about the algorithm: It seems to me that if a client fails to acknowledge a SET (e.g. due to a bug, or perhaps a message is lost) then it has to wait until the server times out waiting for the SET acknowledgement before the server hopefully resends it. However, I would normally expect that a client should automatically acknowledge all SETs in the order that it receives them because it doesn't seem to have a good reason not to do so. Hence, I was wondering whether it would be useful to have an option to allow clients to request that the next "maxEvents" SETs also include any unacknowledged SETs? This would allow clients to potentially recover lost SETs more quickly and more robustly? I.e. for the case where a client expects to acknowledge all existing received SETs before/when requesting more. Regards, Rob
- [Id-event] Robert Wilton's No Objection on draft-… Robert Wilton via Datatracker
- Re: [Id-event] Robert Wilton's No Objection on dr… Mike Jones