Hi Toerless, hi Michael > -----Original Message----- > From: Michael Richardson <mcr+i...@sandelman.ca> > Sent: Freitag, 3. September 2021 19:09 > > t...@cs.fau.de <t...@cs.fau.de> wrote: > > 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. > > Will we be able to avoid normative cross-references? Probably not. > So the documents will progress together. The problem space that we had in mind regarding the split should address this by: A: An informative document outlining the use of alternative enrollment protocols in BRSKI. As BRSKI already distinguishes between the endpoints for voucher handling and enrolment handling, the introduction of an alternative enrollment should be straight forward as outlined in the latest async draft. BRSKI is not prescriptive regarding the protocol used from the Registrar (as RA) to the CA. Handling of offline situation with respect to enrollment could thus also be part of an operational considerations document. Offline voucher exchanges are already considered in BRSKI by using nonceless vouchers.
B: A normative document specifying responder mode of pledges. This is what use case 2 addresses by introducing the registrar-agent. Depending on the deployment, the registrar-agent may be part of a commissioning tool, to provide support when there is no connectivity to the registrar. Alternatively, the registrar-agent may be part of the registrar itself. This enables (online) interactions with pledges in initiator mode and pledges in responder mode. > > I think that where we will benefit will be in the review/reader point of view. > > > 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. > > I would call the third document the applicability statement for uses in > industry > FOO. Or it may be part of an operational considerations document that addresses different architecture deployment options. Regards Steffen > > > -- > Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
