> On 12. Dec 2023, at 21:09, Brian Trammell (IETF) <[email protected]> wrote: > > > >> On 12 Dec 2023, at 19:12, Michael Welzl <[email protected]> wrote: >> >> >> >>> On Dec 12, 2023, at 6:48 PM, Tommy Pauly <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Hi Lars, >>> >>> Responses inline. >>> >>> >>>> On Dec 12, 2023, at 3:38 AM, Lars Eggert <[email protected] >>>> <mailto:[email protected]>> 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 <[email protected] >>>> <mailto:[email protected]>> wrote: >>>>>> On Sep 7, 2023, at 3:59 AM, Lars Eggert via Datatracker >>>>>> <[email protected] <mailto:[email protected]>> 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/
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
