> 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. Thanks, cheers, Brian
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
