[calsify] Re: Ketan Talaulikar's Discuss on draft-ietf-calext-ical-tasks-13: (with DISCUSS and COMMENT)

[Michael Douglass <[e-mail]>]

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 
> <[e-mail]> 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
>     <[e-mail]> 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 [e-mail]
> To unsubscribe send an email [e-mail]