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

"Brian Trammell (IETF)" <ietf@trammell.ch> Tue, 12 December 2023 20:09 UTC

Return-Path: <ietf@trammell.ch>
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 7559FC14F5FA for <taps@ietfa.amsl.com>; Tue, 12 Dec 2023 12:09:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.804
X-Spam-Level:
X-Spam-Status: No, score=-2.804 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trammell.ch
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 d6Jic0vejpik for <taps@ietfa.amsl.com>; Tue, 12 Dec 2023 12:09:39 -0800 (PST)
Received: from smtp-42ae.mail.infomaniak.ch (smtp-42ae.mail.infomaniak.ch [84.16.66.174]) (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 64D72C14E513 for <taps@ietf.org>; Tue, 12 Dec 2023 12:09:37 -0800 (PST)
Received: from smtp-2-0000.mail.infomaniak.ch (unknown [10.5.36.107]) by smtp-3-3000.mail.infomaniak.ch (Postfix) with ESMTPS id 4SqV7z4kxQzMq31s; Tue, 12 Dec 2023 20:09:35 +0000 (UTC)
Received: from unknown by smtp-2-0000.mail.infomaniak.ch (Postfix) with ESMTPA id 4SqV7y0CzrzMpnPj; Tue, 12 Dec 2023 21:09:33 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=trammell.ch; s=20191114; t=1702411775; bh=PK29e3AqDdfP9JWSRqOjZUxc1kuYpAU3K5ZJ2UGcOdc=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=JDYB9Uu8O1JCnRW5zQw4Sajguvah1/NUIwjWMWoFkTBcADvsIRp/ZflX1NrH3jyh8 +daxOE5mWjxnKle5pmVYT3h5DcWApeOV6knQWzMMA9OYhz5UXC/1z7dE+M/fMPEuoj KFdgDtJtUApzOYsjj0Lw85YkiFWOgvG6qMOsFMeg=
From: "Brian Trammell (IETF)" <ietf@trammell.ch>
Message-Id: <3616DE8F-F3BA-4EFD-8EC7-57044E19DDFD@trammell.ch>
Content-Type: multipart/alternative; boundary="Apple-Mail=_4CC01DEC-38B3-43B6-9075-841963D7E1A8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.200.91.1.1\))
Date: Tue, 12 Dec 2023 21:09:23 +0100
In-Reply-To: <C681ED45-0047-4D32-8349-B9A0853C2B52@ifi.uio.no>
Cc: 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: Michael Welzl <michawe@ifi.uio.no>
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>
X-Mailer: Apple Mail (2.3774.200.91.1.1)
X-Infomaniak-Routing: alpha
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/1or3_qkM3GeJM2rYBOj3IvxbO1E>
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: Tue, 12 Dec 2023 20:09:45 -0000


> 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.

Thanks, cheers,

Brian