[Teep] Re: Ketan Talaulikar's Discuss on draft-ietf-teep-protocol-24: (with DISCUSS)

[Ketan Talaulikar <[e-mail]>]

Hi Hannes,

Thanks for sharing the update and the responses. It looks good to me, and I
will be clearing my DISCUSS ballot shortly.

However, here are a few comments/suggestions on the updated text:

1) Please fix the section references:
The registries in Sections *13.2 through 13.6 *are to be created within
this registry group.

2) On the DE guidance.

   -

   The request does not conflict with active IETF work in related areas.

I assume this needs to be qualified as "When the request is coming from
outside of the IETF, ..."?

3) I would urge the authors and the WG to reconsider whether they wanted to
expand the Standards Action range and perhaps do a 50-50% split between
Standards Action and Specification Required. I get the impression that the
Specification Required is meant to mainly cater to allocations from outside
the IETF and if so, please consider whether the range for IETF is
sufficient and if any such range preferences are required to be spelled out
in the registry or in DE guidance. Obviously I don't know enough about this
work to say anything further - so, this is just a point for your
consideration.

Thanks,
Ketan


On Fri, Feb 27, 2026 at 12:15 AM Hannes Tschofenig <
[e-mail]> wrote:

> Hi Ketan!
>
> Thank you for the careful review. We have updated the document to
> address the following items:
>
> - IANA Section
>
> We have made updates to the IANA consideration section and clarified
> initial allocations:
>
>   * Added text that the allocation tables define the initial allocations
> made by this document.
>   * Updated allocatable future ranges from "Reserved for future use" to
> "Unassigned".
>   * Kept "Reserved" only for values intentionally not to be allocated.
>
> We now provide Designated Expert guidance for all "Specification
> Required" ranges.
>
> - Registry ranges
>
> We updated the value ranges and made them more precise.
>
> Ciao
> Hannes
>
>
> Am 17.02.2026 um 17:16 schrieb Ketan Talaulikar via Datatracker:
> > Ketan Talaulikar has entered the following ballot position for
> > draft-ietf-teep-protocol-24: 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-teep-protocol/
> >
> >
> >
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > Thanks to the authors and the WG for their work on this document.
> >
> > I have a few discussion points related to the IANA considerations that
> should
> > be straightforward to address.
> >
> > 1) I believe this document needs to instruct the IANA to create a new
> registry
> > group - perhaps "Trusted Execution Environment Provisioning (TEEP)
> Protocol
> > Parameters" registry group? All the registries mentioned in sections 13.2
> > through 13.7 are then to be created within this new registry group?
> >
> > 2) When the IANA section says "Reserved for future use", I believe those
> are
> > "unassigned" (i.e., other docs/specs may ask for their allocation to
> IANA)?
> > While when "Reserved" is used, it is an instruction for IANA to not
> allocate
> > those values? Please check since some values that are "Reserved" (see
> below)
> > might actually be "deprecated" ? Also, please indicate that the
> allocations
> > given in the tables are the initial allocations being made by this
> document.
> >
> > 4       (Reserved)      This document
> >
> > 3) There are registries with "Specification Required" but no guidance
> has been
> > provided for DEs as required per RFC8126. Please provide DE guidance or
> > alternately use IETF Review policy instead of Specification Required if
> > allocations are going to done only from within the IETF.
> >
> > 4) For the TEEP CBOR Label Registry (section 13.5), is there an upper
> bound?
> > Can someone ask IANA for allocating a very high random number?
> >
> >
> >
> >
> >
> > _______________________________________________
> > TEEP mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
>