Getting back to this topic - I have edits now on a branch where I try to
apply the shepherd's review suggestions and make it far more clear what
of RFC 8995 and RFC 9148 is updated. In the sense of "we expect new
implementers of 8995 or 9148 to implement that even if they don't want
cBRSKI".
While doing this, I wondered if it's actually worth it to port back
certain changes to EST-coaps. (Hence in 'To:' of this mail - the ACE
WG) It will make RFC 9148 a bit more complex - there's the base text and
readers have to look at a new RFC that updates parts by inserting text
into it at various places.
An alternative is that in the future someone makes an 9148-bis that
scoops up these changes from cBRSKI?
One example is the use of the new multipart-core Content-Format (62) to
carry certificates instead of application/pkcs7-mime;
smime-type=certs-only (287) -> I do think using 62 is much easier than
287. But should we enforce an EST-coaps server always to support this
content-format? Maybe only cBRSKI devices will ever use it? Any ACE WG
feedback is welcome here :)
Current draft commit is here:
https://github.com/anima-wg/constrained-voucher/commit/a850774dd78a0dbd70c20b059fd588bc3a6753ab
> More words do not always help.
> I think that this is pretty niche.
> Search engines and LLMs seem to know what BRSKI-EST, so leave it alone.
I kept these names BRSKI-EST and BRSKI-MASA by the way - RFC 8995 also
defines these clearly, so reusing is the best way.
Esko
On 6/10/26 21:42, Michael Richardson wrote:
Esko Dijk<[email protected]> wrote:
> Thanks for the feedback. It looks like the draft is struggling between
the
> viewpoints of "cBRSKI is a new protocol based on BRSKI" vs "cBRSKI equals
> BRSKI and is a variant on it".
In general, I have used and pushed others to use the
draft-kuehlewind-rswg-updates-tag stuff, even though a few had small problems
with it that kept it stagnating.
RFC9914 got through with amends/extends, although there were some bumps.
> cBRSKI is an extension of BRSKI (without impacting existing
implementations),
> however the document also does provide some normative updates to
BRSKI/8995
> which might impact existing implementations in case they weren't doing
these
> things right.
> The namings "BRSKI-EST" and "BRSKI-MASA" are used to divide all protocol
> interactions into 2 groups. This way of dividing would conceptually hold
for
> cBRSKI, but also for existing BRSKI (8995).
> An alternate way to summarize this very shortly would be like this:
> cBRSKI = cBRSKI-EST + cBRSKI-MASA
> BRSKI = BRSKI-EST + BRSKI-MASA
> This is probably confusing as well, because it uses another definition
for
> these terms. The key thing I think is that "BRSKI-EST" as used now in the
> draft is a way to say "The Pledge-to-Registrar interactions of any BRSKI
type
> protocol (including 8995 and cBRSKI and possible others)".
Yes.
The BRSKI-MASA side of things is being extended.
I'd have to look again if there was anything on that side that gets amended.
cBRSKI-EST is clearly extending RFC9148 by adding the new resources.
I think we are also **amending** it with draft-ietf-core-uri-path-abbrev.
> Maybe we should call it "Pledge-to-Registrar Scope" or
"Pledge-to-Registrar
> Leg" or so instead of BRSKI-EST.
More words do not always help.
I think that this is pretty niche.
Search engines and LLMs seem to know what BRSKI-EST, so leave it alone.
--
Michael Richardson<[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
** My working hours and your working hours may be different. **
** Please do not feel obligated to reply outside your normal working hours **
_______________________________________________
Anima mailing list [email protected]
To unsubscribe send an email [email protected]
--
*IoTconsultancy.nl* | Email/Teams: [email protected] | +31 6
2385 8339_______________________________________________
Anima mailing list -- [email protected]
To unsubscribe send an email to [email protected]
