Can you help me out
On Thu, Jun 25, 2026 at 11:57 AM Esko Dijk <esko.dijk= [email protected]> wrote: > 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]> > <[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]> <[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 to [email protected] > > -- > *IoTconsultancy.nl* | Email/Teams: [email protected] | +31 6 > 2385 8339 > _______________________________________________ > Ace mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
