[lamps] Re: [core] Re: Re: EST /.well-known/est registry

[Esko Dijk <[e-mail]>]

Chiming in:

indeed the key idea proposed is to have each registry entry on one line, 
including both a regular path segment and a short path segment 
equivalent. I like that. This emphasizes better that the functionality 
is equivalent across EST/EST-coaps. And it forces applicants to think 
about a EST-coaps equivalent. See Table 1 in 
draft-ietf-anima-constrained-voucher for an example of this side-by-side 
listing. Absence of a short equivalent would indicate EST-coaps doesn't 
support the resource at all.  And also, long/short names may be identical.

The thing that Michael seemed to be wrestling with is how to tie this to 
the even-shorter-path (numeric) registrations made in 
draft-ietf-core-uri-path-abbrev. Note that this already has numbers 
defined for some EST CoAP well-known paths.  On the one hand we don't 
want to repeat those numbers in the new IANA registry (since already 
registered in the other registry from draft-ietf-core-uri-path-abbrev). 
On the other hand, it's handy for users of this to have all the required 
info in one table.

I would still advice to keep these things separate, to avoid complexity.

Finally, Michael I think suggested that this draft, or this new IANA 
registry, could somehow mention the (mandatory?) support for 
draft-ietf-core-uri-path-abbrev at the EST-coaps server side. But I 
think that would  need an "RFC9148 bis" or as Hendrik said an "RFC7030 
bis" could also do this.  For example, 
draft-ietf-anima-constrained-voucher does require URI-path-abbrev 
support for cBRSKI, but this does not cover 'all EST-coaps servers' in 
general.

Esko


On 7/16/26 07:48, Brockhaus, Hendrik wrote:
> Michael
>
> Thank you for your quick review and pointing at RFC 8295 for further path segments to be added.
> However, I'm not sure if I fully understand your suggestions. I'm not a CORE expert either.
> My goal is simply to include in this new register only the path segments as defined in other RFCs. If any extension to the path segment registration, e.g., based on draft-ietf-core-uri-path-abbrev, is needed, I vote for doing so in a rfc7030bis.
> The three-column layout of the table is based on existing examples likehttps://www.iana.org/assignments/brski-parameters/brski-parameters.xhtml#brski-well-known-uris  andhttps://www.iana.org/assignments/cmp/cmp.xhtml#cmp-well-known-uri. Are you referring to the layout described in draft-ietf-anima-constrained-voucher? If this is an accepted way of adding HTTP and CoAP path segments in one table, I am fine with it.
>
> Hendrik
>
>> -----Ursprüngliche Nachricht-----
>> Von: Michael Richardson<[e-mail]>
>> Gesendet: Mittwoch, 15. Juli 2026 16:16
>> An: Brockhaus, Hendrik (FT RPD CST SEA-DE)
>> <[e-mail]>;[e-mail]
>> Cc: Russ Housley<[e-mail]>;[e-mail]
>> Betreff: Re: AW: [lamps] Re: EST /.well-known/est registry
>>
>>
>> Brockhaus, Hendrik<[e-mail]> wrote:
>>      > I prepared a PR for attestation-freshness,
>>      >https://github.com/lamps-wg/lamps-attestation-freshness/pull/38.  You
>>      > can use the text if your draft is faster
>>
>> Fantastic!
>> I've made two suggestions in your PR.
>>
>> 1. Make it five columns wide, and put the 7030/9148 entries on a single line.
>>
>> 2. Mark the draft-ietf-core-uri-path-abbrev for the short names.
>>     As this document creates getnonce/nonce verb, it ought to allocate a
>>     number for that too.
>>
>> My suggestion probably creates a non-DRY quandry.
>> Repeating the uri-path-abbrev allocations in this table is definitely NOT DRY.
>> (DRY == Don't Repeat Yourself. A software engineering term)
>>
>> The 3rd-normal-form/DRY is that one should take the CoAP short name and then
>> go visit the Uri-Path-Abbrev registry to find out the number.
>>
>> I don't love that method as it obscures which ones have allocations, and
>> which do not, and people reading this are not SQL engines that always
>> remember to do the right JOINs.
>> So I prefer not to do that, but now we are complicating the IANA Considerations.
>> The Uri-Path-Abbrev registry is currently set to IETF Review, which is
>> stronger than the Specification Required that this EST Registry demands.
>>
>> RFC9148 (like 7030) provided NO way to extend the set, and this registry
>> helps 9148 too, and Specification Required is fine for 9148 use too.
>>
>> But, this does mean that an external entity (some other SDO) could add to the
>> ESG registry, but would not be allowed to allocate a Uri-Path-Abbrev.
>> I'm not sure if this is a problem.
>>
>> Another situation might be that someone (with an RFC), would like to create a
>> new 7030 resource, but instead of doing a 9148 short-name, just do the
>> Uri-Path-Abbrev.   I think that's fine, just make the 9148 name the same as
>> the 7030.
>>
>> --
>> Michael Richardson<[e-mail]>, Sandelman Software Works
>>   -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*
>>
>>
> _______________________________________________
> core mailing list [e-mail]
> To unsubscribe send an email [e-mail]
-- 
*IoTconsultancy.nl* | Email/Teams: [e-mail] | +31 6 
2385 8339