Using this thread: We had a good first discussion about the subject
on last thursdays BRSKI-DT call and hopefully will continue it over the coming
ones.
While initially the split into two documents sounded like a useful option
based on the two separate reference architecture pictures for the
two separate use-cases == scenarios, i began to question whether the
use cases of interest would be able to support combinations of both
scenarios.
Scenario 1 introduces a "offline-site", e.g.: manufacturing plant, with
an extended registrar to support the offline backend connectivity
to MASA and CA-infra.
Scenario 2 introduces a pledge that is not initiating enrollment as
in BRSKI, but at most supporting some link-local discovery protocol
(e.g.: mDNS) and would prefer to speak afterwards a protocol wher
it is the responder, as normal in Netconf, opposed to being the
initiator as normal in BRSKI.
To me it looked very likely that the typical use-case of a manufacturing
plant would often want to have a combination of both scenarios:
The manufacturing plant might prefer to not be connected to the
Internet (== scenario 1) AND pledges want to be of the type defined
via Scenario 2.
So, while this does not say that we may not want to split up the document
into 2 in the end, it means that i would very much like to see that
the document adds a single integrated combined reference picure and
then explores how it would be possible to combine them, so that we do
not end up creasting two incompatible solutions and forego the option
to build this combined scenario.
There is of course also always the variability in protocol options
specific industries prefer, and i would like to avoid having to re-specify
more than just the bare minimum when this happens instead of having to
repeat a lot of redundant normative text because we are missing a
good architecural reference document to which one can refer when adding
yet another protocol or crypto option in one part of the solution.
Meaning: I would not exclude the option yet, to split the document in
3: One that is the inclusive "reference/architecture" document that
we keep alive and extend with whatever we need to keep in common,
and then 2 or maybe over time more protocol specification parts of
the pieces we are adding.
So, just tactically, maybe just start putting a new section with
combined picture into the document, informationally discussing the
things that would need to happen (protocol wise) or this combination.
Cheers
Toerless
On Wed, Aug 25, 2021 at 02:32:20PM +0000, Fries, Steffen wrote:
> Hi Toerless,
>
> Just using the previous thread to ask if there has been a decision regarding
> the document split of BRSKI-AE, we proposed during IETF 111.
>
> Best regards
> Steffen
>
> > -----Original Message-----
> > From: Anima <[email protected]> On Behalf Of Michael Richardson
> > Sent: Donnerstag, 5. August 2021 15:58
> > To: Robert Wilton <[email protected]>; [email protected]
> > Subject: Re: [Anima] BRSKI-AE document split discussion
> >
> >
> > Dear Area Director and WG Chairs,
> >
> > While I am in favour of splitting the document into two, the number of
> > documents that the IESG is willing to process is not infinite.
> > One advantage of the split is that products can more clearly articulate
> > which RFC
> > they support.
> > (RFCXXXX vs RFCZZZZ, or RFCYYYY section A, or RFCYYYY section B)
> >
> > Can you comment on this thread about splitting things up?
> >
> > I also have not heard very clearly about whether or not RFC8366bis will
> > be adopted and worked on. If reducing number of documents is important,
> > then one possibility is to merge draft-ietf-anima-jws-voucher into
> > RFC8366bis.
> >
> > Plus: fewer documents.
> > Negative: potentially opens up RFC8366bis to new semantics?
> >
> > --
> > Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
> > Sandelman Software Works Inc, Ottawa and Worldwide
> >
> >
> >
>
--
---
[email protected]
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
