IETF Logo Mail Archive

Re: [Taps] Lars Eggert's Discuss on draft-ietf-taps-interface-22: (with DISCUSS and COMMENT)

"Philipp S. Tiesel" <philipp@tiesel.net> Wed, 13 December 2023 13:31 UTC

Return-Path: <philipp@tiesel.net>
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA34EC14F614 for <taps@ietfa.amsl.com>; Wed, 13 Dec 2023 05:31:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.903
X-Spam-Level:
X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhLjW909p9ui for <taps@ietfa.amsl.com>; Wed, 13 Dec 2023 05:31:43 -0800 (PST)
Received: from einhorn-mail-out.in-berlin.de (einhorn.in-berlin.de [192.109.42.8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD69FC14F610 for <taps@ietf.org>; Wed, 13 Dec 2023 05:31:42 -0800 (PST)
X-Envelope-From: philipp@tiesel.net
Received: from x-berg.in-berlin.de (x-change.in-berlin.de [IPv6:2a0a:4580:1018:0:0:0:0:40]) by einhorn.in-berlin.de with ESMTPS id 3BDDVHog3345922 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 13 Dec 2023 14:31:18 +0100
Received: from x-berg.in-berlin.de ([217.197.86.42] helo=smtpclient.apple) by x-berg.in-berlin.de with esmtpa (Exim 4.94.2) (envelope-from <philipp@tiesel.net>) id 1rDPKX-0005nl-Ll; Wed, 13 Dec 2023 14:31:17 +0100
From: "Philipp S. Tiesel" <philipp@tiesel.net>
Message-Id: <6534A3CF-B8BC-4EF3-9D09-DB236F694F88@tiesel.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A97DEC05-9E18-471A-A39F-17780397D3AE"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.200.91.1.1\))
Date: Wed, 13 Dec 2023 14:31:07 +0100
In-Reply-To: <3616DE8F-F3BA-4EFD-8EC7-57044E19DDFD@trammell.ch>
Cc: Michael Welzl <michawe@ifi.uio.no>, Tommy Pauly <tpauly@apple.com>, Lars Eggert <lars@eggert.org>, Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>, The IESG <iesg@ietf.org>, draft-ietf-taps-interface@ietf.org, taps-chairs@ietf.org, taps@ietf.org, Anna Brunström <anna.brunstrom@kau.se>
To: "Brian Trammell (IETF)" <ietf@trammell.ch>
References: <169408439315.13814.3746604129872399062@ietfa.amsl.com> <A1CF408B-C691-4003-A989-D0F3284B4E2F@apple.com> <181529E6-CFDC-4969-AABE-502E1C8A1325@eggert.org> <2FF2518E-C6E6-4BFF-9521-05AB8FE036F0@apple.com> <C681ED45-0047-4D32-8349-B9A0853C2B52@ifi.uio.no> <3616DE8F-F3BA-4EFD-8EC7-57044E19DDFD@trammell.ch>
X-Mailer: Apple Mail (2.3774.200.91.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/qABUtOpYOPTAdwY12yDy1059N0s>
Subject: Re: [Taps] Lars Eggert's Discuss on draft-ietf-taps-interface-22: (with DISCUSS and COMMENT)
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IETF Transport Services \(TAPS\) Working Group" <taps.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/taps>, <mailto:taps-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/taps/>
List-Post: <mailto:taps@ietf.org>
List-Help: <mailto:taps-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/taps>, <mailto:taps-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Dec 2023 13:31:48 -0000


> On 12. Dec 2023, at 21:09, Brian Trammell (IETF) <ietf@trammell.ch> wrote:
> 
> 
> 
>> On 12 Dec 2023, at 19:12, Michael Welzl <michawe@ifi.uio.no> wrote:
>> 
>> 
>> 
>>> On Dec 12, 2023, at 6:48 PM, Tommy Pauly <tpauly@apple.com <mailto:tpauly@apple.com>> wrote:
>>> 
>>> Hi Lars,
>>> 
>>> Responses inline.
>>> 
>>> 
>>>> On Dec 12, 2023, at 3:38 AM, Lars Eggert <lars@eggert.org <mailto:lars@eggert.org>> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> thanks for the replies. I'll trim my response to only those items where I still have questions.
>>>> 
>>>> On Nov 14, 2023, at 19:17, Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org <mailto:tpauly=40apple.com@dmarc.ietf.org>> wrote:
>>>>>> On Sep 7, 2023, at 3:59 AM, Lars Eggert via Datatracker <noreply@ietf.org <mailto:noreply@ietf.org>> wrote:
>>>>>> ### Section 4.1, paragraph 8
>>>>>> ```
>>>>>>    *  For IETF protocols, the name of a Protocol-specific Property
>>>>>>       SHOULD be specified in an IETF document published in the RFC
>>>>>>       Series.
>>>>>> ```
>>>>>> For IETF protocols, i.e., protocols published on the IETF RFC stream,
>>>>>> those names must IMO be also specified in IETF-stream RFCs. I see no
>>>>>> reason to let other RFC streams make definitions for IETF protocols.
>>>>> 
>>>>> This now reads: "For IETF protocols, the name of a Protocol-specific Property SHOULD be specified in an IETF document published in the RFC Series after IETF review.”
>>>> 
>>>> why is this not a MUST, i.e., when would it be appropriate to not specify this in an IETF-stream RFC?
>>> 
>>> Yeah, I think this could be a MUST.
>>> 
>>> Brian, Michael, what do you think?
>> 
>> I dug into the issues and found this:  https://github.com/ietf-tapswg/api-drafts/issues/1330
>> where we have closed this as “overtaken by events” - so I struggle to find the discussion that led to the specific sentence that was added. I believe we just left the SHOULD as it was, and fixed this to refer to "the RFC series after IETF review".
>> 
>> History and github issues aside, I completely agree, a MUST would make more sense here. Let’s do this.
>> 
>> Cheers,
>> Michael
> 
> I vaguely recall some discussion of this… but on review, +1 to this being a MUST.
> 

The SHOULD was there to capture experimental use that already is being deployed while the RFC is lacking behind. 
I have no strong feelings whether this should be a SHOULD or MUST … 

Hypothetical test: does anyone think a MUST would have been a problem for QUIC specific properties in the time between the BoF and the RFC publishing if TAPS would have been around already then?

AVE!
   Philipp S. Tiesel

--  
Philipp S. Tiesel
https://philipp.tiesel.net/

v2.35.0 | Report a Bug | By Email | System Status