Return-Path: X-Original-To: calsify@mail2.ietf.org Delivered-To: calsify@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 35D6836458E5; Tue, 17 Jun 2025 21:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYLV-gS9Hzd4; Tue, 17 Jun 2025 21:06:34 -0700 (PDT) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 4424236458DE; Tue, 17 Jun 2025 21:06:34 -0700 (PDT) Received: by mail-qk1-x730.google.com with SMTP id af79cd13be357-7d38d1eae03so614351485a.2; Tue, 17 Jun 2025 21:06:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1750219594; x=1750824394; darn=ietf.org; h=in-reply-to:from:content-language:references:cc:to:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=A8BH4srFb2B2cpdvh5qFaYx/NV1UpPKW0q94hd7wmNA=; b=FJ3HoBT9AtRBRDI8db4oi2MtK+h6mxPbFuG6ttjozcFpebzNW5tAZvK4d05jIxTE+f rQXQy4UPI85zZCPkRaVkzCNLrJBlYHCFcI3KucT5pV6QN9Tyi24EJIRfciTPxfntPxw+ kBDfKJKaNDwdtvYwSatCzQIGYGffn5/J/lydCp2Bo3Dp2SqkuUofmKaNkApt6uHntg9R jBAbhIPi/gLWLx3J5H+8Rd1ZVy0HCEFi3e4mxorovuAcOX+eMCUZuQJU/Y3zYPL5gCz+ RMe/hifhonmUPoIxyKkzZ6Q3T3dIKazewl6OjwyxPV2wtnXG4hzylr7pPfdbbQ75BdIQ 7urQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750219594; x=1750824394; h=in-reply-to:from:content-language:references:cc:to:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=A8BH4srFb2B2cpdvh5qFaYx/NV1UpPKW0q94hd7wmNA=; b=DLWUNbBgtQidvncAWe5S0U4j2QIxxUdzPpYG537M+25y/sWO2eNHCMM26Kw1YOSxhY s4dWhzoeTS5o2Q8En8oVdiVpVEDSxIREkZZPLX4wMjHStSaYPL4FRpSfD32xYbtI/xSV GGm+CnnCHmT6Wu5cHq6lOWX244nE6UN0tPVH5Ck4At8ZUBjbDl1dJTfulysj8u16Pd7s ACuTMulWyC3SVm9EppVXZ7CFTVDnMkEG28EVQcvOYqWcuGuN4tQgCofwc1b96f5YApn+ j4MpD29G4lSkw0tFTeb0asiEtOZ7lzmlU9GT6+18tr7eXtAktJ+iMlyqtAsA4Bx0jsXi lzqw== X-Forwarded-Encrypted: i=1; AJvYcCU84ZWL2i/fho4b2gIo5SdCwNOsgit56OBQ9jlJN4F043+pGm07NVPfcagKb2yMsyttuK47QYOXbA==@ietf.org, AJvYcCV1GhD+W60SWyJv5hKKLWDIbeUUl5O4CZuqLcKmPcoGe+DTRf6qrFNnUGneHg3O3nQLeNaOAfZTty5q0swkDbTtyDvyD1oCO79T7+siDQ==@ietf.org, AJvYcCXk8ZOKEHF76zCAmnNP4chVqVgLCUuDL9Hnmke8d6mjqGPjoWmx8S5vy3JMAxHTTpUQHMYCQFjV8gTVGEgB@ietf.org X-Gm-Message-State: AOJu0Yw9bBbi1L3Nk2lxufyZ8NLi47I3qRMApsmAPzCBpeoNFNZM7nWp sYU7aP91UWYsN402amYaVLGs+ojqKwO3uGYV0JUyjf7NGQVMVgpe38D5 X-Gm-Gg: ASbGncuq0JlE43f8nWclWcNfNx3X934kG43LlVuaj8mUePgvWU6klfLoXIPW0+D+Wfe oyfqE6Uc2Mw0rMs2Xqxhx+20XJxylN6dDcDdDCLjy7ktBQYu/gOMY91IcXwEY8huJwE3o149J2z EuuqVqXpphknHXqRbHVQOT0K9cKLB5meRVdeYgLcs0wXsgH0wWWGSbKhZiiRxRR52iV073KZY/5 aSA14Qi1X8k8H6Oin6xQqn+G5oZBjZxlL7L7hf9CPUTa5+fx+3mwOUVprvaXpuRIhhkJWMQ3I6h lJ6k3diQ8F+KNIv9XZ6pUeRDL3ZdgPHGBun1Gm+iGe//hqiE3z7OHmeKY//JVYYpoP6i/Xkou6T kYMZsazwf5w5BF6Xy9OPmyaw1ElC/K4VbgAKNFUvyAUIqTwMYU06kJA== X-Google-Smtp-Source: AGHT+IEqteiiazbxOM7miL4178DFrfa/vwSYXxfNauxhm2N0UchYSM2zgF+ICz9HHQ0B8miKpbrRSQ== X-Received: by 2002:a05:620a:4486:b0:7d3:e710:1d3 with SMTP id af79cd13be357-7d3e71008admr331697085a.7.1750219593676; Tue, 17 Jun 2025 21:06:33 -0700 (PDT) Received: from [192.168.1.36] (syn-074-070-070-237.res.spectrum.com. [74.70.70.237]) by smtp.googlemail.com with ESMTPSA id af79cd13be357-7d3b8df955esm723485885a.32.2025.06.17.21.06.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 17 Jun 2025 21:06:33 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------uNMFKh1UGpnjxkriwipxyLEB" Message-ID: Date: Wed, 18 Jun 2025 00:06:31 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Ketan Talaulikar , Michael Douglass References: <174660769567.834913.12155121044909527569@dt-datatracker-58d4498dbd-6gzjf> <83741ce3-32fd-4fd5-b831-76fe852a71ea@bedework.com> Content-Language: en-US From: Michael Douglass In-Reply-To: Message-ID-Hash: I7S2UV35GT2FHL6ASSY63Q5VHQV45WLD X-Message-ID-Hash: I7S2UV35GT2FHL6ASSY63Q5VHQV45WLD X-MailFrom: mikeadouglass@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-calsify.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: The IESG , draft-ietf-calext-ical-tasks@ietf.org, calext-chairs@ietf.org, calsify@ietf.org, murch@fastmailteam.com X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5Bcalsify=5D_Re=3A_Ketan_Talaulikar=27s_Discuss_on_draft-ietf-cal?= =?utf-8?q?ext-ical-tasks-13=3A_=28with_DISCUSS_and_COMMENT=29?= List-Id: Calendaring and Scheduling Standards Simplification Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. --------------uNMFKh1UGpnjxkriwipxyLEB Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sorry for the delay. I hope to have something out in a couple of days. Thanks - Mike On 6/17/25 07:34, Ketan Talaulikar wrote: > Hi Michael, > > I wanted to check in on this thread that we had. Please let me know if > you have got around to it and if you have any questions. > > Thanks, > Ketan > > > On Mon, May 12, 2025 at 12:23 PM Ketan Talaulikar > wrote: > > Hi Michael, > > May I suggest going through RFC8126 to understand the guidelines > for IANA considerations? You may be able to better relate to my > more detailed comments/suggestions with that background. > > I would be glad to assist further. > > Thanks, > Ketan > > > On Fri, May 9, 2025 at 9:57 PM Michael Douglass > wrote: > > Thank you for the comments. > > I'm out for a long weekend. > > I may need some assistance getting this correct... > > On 5/7/25 04:48, Ketan Talaulikar via Datatracker wrote: > > Ketan Talaulikar has entered the following ballot position for > > draft-ietf-calext-ical-tasks-13: Discuss > > > > 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/about/groups/iesg/statements/handling-ballot-positions/ > > for more information about how to handle DISCUSS and COMMENT > positions. > > > > > > The document, along with other ballot positions, can be > found here: > > https://datatracker.ietf.org/doc/draft-ietf-calext-ical-tasks/ > > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > > ---------------------------------------------------------------------- > > > > Thanks to the authors and the WG for the work on this document. > > > > I have one uber point about the IANA Considerations section > of the document > > that I would like to discuss. > > > > In order to better understand the context (i.e., where I am > coming from), I > > request the authors to read RFC8126 - specifically related > to what is required > > for a) creating new registries and b) new allocations from > registries. There is > > also the choice of the Registration Policy (that sometimes > need to go along > > with the DE guidance) - in this case, I believe the intent > is to follow section > > 8.2 of RFC5545 but the text is not clear enough (to me at > least). > > > > I understand that some of the language in the IANA section > may have been picked > > from RFC5545 but that predates RFC8126. It would be good if > the authors (and > > perhaps the WG?) align with the latest BCP 26. > > > > I am providing more detailed comments inline in the idnits > output for v13 of > > the document. A few of this points (I believe) are also > raised by Roman in his > > DISCUSS that I support. > > > > Most importantly, this section is for the IANA team and I > request them to step > > into this discussion and correct/clarify as appropriate. > > > > 1127    15.  IANA Considerations > > > > 1129    15.1.  New and updated iCalendar Elements Registration > > > > KT> I assume all these considerations pertain to the > iCalendar Elements > > Registries? If so, please clarify for the benefit of the > IANA team. > > > > 1131       This specification updates [RFC5545] by adding > and updating a number > > > > KT> Adding a new registry or elements in a registry does not > warrant an > > "updates" to an existing RFC which created the registry > group or registry. > > > > 1132       of elements according to the procedures and > templates specified in > > 1133       Section 8.2 of [RFC5545]. > > > > KT> Is the intention here to say that new registries > introduced by this > > document follow the registration policy and DE procedures in > sec 8.2 of > > RFC5545? If so, please say that. A follow-up question is > that it is not > > clear to me which of the templates should be used for requesting > > allocations from the new registries? I also do not see the > use or > > reference to templates for existing registries where new > allocations > > are being made. Or, is no template required for them? > > > > 1135    15.1.1.  Update of the Status registry > > > > 1137       This specification updates the Status registry > defined in > > 1138       [draft-ietf-calext-subscription-upgrade] with > additional values > > 1139       defined in this document. > > > > KT> This isn't an "update" of the registry since the > registry or its > > allocation policy is not changing. This is in fact a request > to IANA for > > allocation of additional values in an existing registry. I > also notice > > that the draft that is creating this registry is not clear > about which > > template to be used for making requests (or that there is no > template?). > > This comment applies to other registries where further > allocations are > > being made. > > > > 1141 +=========+=========+=========================+ > > 1142                  | Value   | Status  | Reference        >        | > > 1143 +=========+=========+=========================+ > > 1144                  | PENDING | Current | This Spec, > Section 11.2 | > > 1145 +---------+---------+-------------------------+ > > 1146                  | FAILED  | Current | This Spec, > Section 11.2 | > > 1147 +---------+---------+-------------------------+ > > > > 1149                       Table 1: Updated Status Value > Registry > > > > 1151    15.1.2.  Sub-State value registry > > > > 1153       The following table has been used to initialize > the Sub-State > > 1154       registry. > > > > KT> I believe here the instruction to IANA is to "create" a > new Sub-State > > registry with the initial values allocated as indicated in > the table below? > > If so, please say that. This applies for other registries > that are created. > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > > ---------------------------------------------------------------------- > > > > I have only one minor/nit comment about the draft header > that is reported by > > idnits and needs to be fixed: > > > >    == The 'Updates: ' line in the draft header should list > only the _numbers_ > >       of the RFCs which will be updated by this document (if > approved); it > >       should not include the word 'RFC' in the list. > > > > > > > > > _______________________________________________ > calsify mailing list --calsify@ietf.org > To unsubscribe send an email tocalsify-leave@ietf.org --------------uNMFKh1UGpnjxkriwipxyLEB Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Sorry for the delay. I hope to have something out in a couple of days.

Thanks - Mike

On 6/17/25 07:34, Ketan Talaulikar wrote:
Hi Michael,

I wanted to check in on this thread that we had. Please let me know if you have got around to it and if you have any questions.

Thanks,
Ketan


On Mon, May 12, 2025 at 12:23 PM Ketan Talaulikar <ketant.ietf@gmail.com> wrote:
Hi Michael,

May I suggest going through RFC8126 to understand the guidelines for IANA considerations? You may be able to better relate to my more detailed comments/suggestions with that background.

I would be glad to assist further.

Thanks,
Ketan


On Fri, May 9, 2025 at 9:57 PM Michael Douglass <mdouglass@bedework.com> wrote:
Thank you for the comments.

I'm out for a long weekend.

I may need some assistance getting this correct...

On 5/7/25 04:48, Ketan Talaulikar via Datatracker wrote:
> Ketan Talaulikar has entered the following ballot position for
> draft-ietf-calext-ical-tasks-13: Discuss
>
> 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/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-calext-ical-tasks/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Thanks to the authors and the WG for the work on this document.
>
> I have one uber point about the IANA Considerations section of the document
> that I would like to discuss.
>
> In order to better understand the context (i.e., where I am coming from), I
> request the authors to read RFC8126 - specifically related to what is required
> for a) creating new registries and b) new allocations from registries. There is
> also the choice of the Registration Policy (that sometimes need to go along
> with the DE guidance) - in this case, I believe the intent is to follow section
> 8.2 of RFC5545 but the text is not clear enough (to me at least).
>
> I understand that some of the language in the IANA section may have been picked
> from RFC5545 but that predates RFC8126. It would be good if the authors (and
> perhaps the WG?) align with the latest BCP 26.
>
> I am providing more detailed comments inline in the idnits output for v13 of
> the document. A few of this points (I believe) are also raised by Roman in his
> DISCUSS that I support.
>
> Most importantly, this section is for the IANA team and I request them to step
> into this discussion and correct/clarify as appropriate.
>
> 1127    15.  IANA Considerations
>
> 1129    15.1.  New and updated iCalendar Elements Registration
>
> KT> I assume all these considerations pertain to the iCalendar Elements
> Registries? If so, please clarify for the benefit of the IANA team.
>
> 1131       This specification updates [RFC5545] by adding and updating a number
>
> KT> Adding a new registry or elements in a registry does not warrant an
> "updates" to an existing RFC which created the registry group or registry.
>
> 1132       of elements according to the procedures and templates specified in
> 1133       Section 8.2 of [RFC5545].
>
> KT> Is the intention here to say that new registries introduced by this
> document follow the registration policy and DE procedures in sec 8.2 of
> RFC5545? If so, please say that. A follow-up question is that it is not
> clear to me which of the templates should be used for requesting
> allocations from the new registries? I also do not see the use or
> reference to templates for existing registries where new allocations
> are being made. Or, is no template required for them?
>
> 1135    15.1.1.  Update of the Status registry
>
> 1137       This specification updates the Status registry defined in
> 1138       [draft-ietf-calext-subscription-upgrade] with additional values
> 1139       defined in this document.
>
> KT> This isn't an "update" of the registry since the registry or its
> allocation policy is not changing. This is in fact a request to IANA for
> allocation of additional values in an existing registry. I also notice
> that the draft that is creating this registry is not clear about which
> template to be used for making requests (or that there is no template?).
> This comment applies to other registries where further allocations are
> being made.
>
> 1141                  +=========+=========+=========================+
> 1142                  | Value   | Status  | Reference               |
> 1143                  +=========+=========+=========================+
> 1144                  | PENDING | Current | This Spec, Section 11.2 |
> 1145                  +---------+---------+-------------------------+
> 1146                  | FAILED  | Current | This Spec, Section 11.2 |
> 1147                  +---------+---------+-------------------------+
>
> 1149                       Table 1: Updated Status Value Registry
>
> 1151    15.1.2.  Sub-State value registry
>
> 1153       The following table has been used to initialize the Sub-State
> 1154       registry.
>
> KT> I believe here the instruction to IANA is to "create" a new Sub-State
> registry with the initial values allocated as indicated in the table below?
> If so, please say that. This applies for other registries that are created.
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I have only one minor/nit comment about the draft header that is reported by
> idnits and needs to be fixed:
>
>    == The 'Updates: ' line in the draft header should list only the _numbers_
>       of the RFCs which will be updated by this document (if approved); it
>       should not include the word 'RFC' in the list.
>
>
>

_______________________________________________
calsify mailing list -- calsify@ietf.org
To unsubscribe send an email to calsify-leave@ietf.org
--------------uNMFKh1UGpnjxkriwipxyLEB--