Hello,
After the discussion in the design team meeting today, we agreed in this round
on the naming of the two documents which aligns with the proposal sent in the
previous email. This would result in
- "Support of asynchronous Enrollment in BRSKI (BRSKI-AE)": covering the
application of alternative enrollment protocols as this was the initially
described use case 1. It will cover the description of utilizing other
enrollment protocol than EST in general and using Lightweight CMP specifically.
- "BRSKI with Pledge in Responder Mode (BRSKI-PRM)", covering the communication
between the pledge and the registrar by reversing the initiator and responder
role of the pledge (compared to RFC 8995). It will reflect UC2 f the original
document with the registrar-agent as facilitator for the communication.
Are there any objections regarding these names for the two documents?
We also discussed about proposed authors for the two documents.
The following authors are on the current draft (version 03):
- S. Fries, H. Brockhaus, T. Werner, Siemens
- E. Lear, Cisco Systems
There are changes proposed based on the involvement into the single use cases.
Proposed authors
- BRSKI-AE:
- D.v. Oheimb, S. Fries, H. Brockhaus, Siemens
- E. Lear, Cisco Systems
- BRSKI-RPM:
- S. Fries, T. Werner, Siemens
- E. Lear, Cisco Systems
- M. Richardson, Sandelman Software Works
Are there any objections regarding the changes in the list of authors?
The next steps would be to prepare the documents (and repository) and submit a
first version of both drafts as WG draft before the submission deadline. We
would give an overview about the changes during the ANIMA session at IETF 112.
Best regards
Steffen
> -----Original Message-----
> From: Fries, Steffen (T RDA CST)
> Sent: Donnerstag, 14. Oktober 2021 09:05
> To: [email protected]
> Cc: Michael Richardson <[email protected]>; Eliot Lear
> <[email protected]>; Werner, Thomas (T RDA CST SEA-DE) <thomas-
> [email protected]>; Brockhaus, Hendrik (T RDA CST SEA-DE)
> <[email protected]>
> Subject: RE: [Anima] BRSKI-AE document split discussion
>
> Hello,
>
> Based on the split discussion we started with the naming of the two resulting
> documents. I put the current proposals under issue #19
> (https://github.com/anima-wg/anima-brski-async-enroll/issues/19) on the
> github. The proposal there is as following:
>
> - UC1 is proposed to stay as "BRSKI-AE" covering the application of
> alternative enrollment protocols as this was the initially described use case
> .
> It will cover the description of utilizing other enrollment protocol than EST
> in
> general and using Lightweight CMP specifically.
> - UC2 is proposed to become "BRSKI with Pledge in Responder Mode (BRSKI-
> PRM)", as it addresses the communication between the pledge and the
> registrar by reversing the initiator and responder role (compared to RFC
> 8995) also introducing the registrar-agent as facilitator for the
> communication.
>
> We would like to discuss this in the design team meeting today. Based on
> that we would fork the repository (with the new names) and start to
> separate the content.
>
> Best regards
> Steffen
>
> > -----Original Message-----
> > From: Anima <[email protected]> On Behalf Of Fries, Steffen
> > Sent: Freitag, 8. Oktober 2021 10:28
> > To: [email protected]
> > Cc: Michael Richardson <[email protected]>; [email protected]; Eliot
> > Lear <[email protected]>; Werner, Thomas (T RDA CST SEA-DE) <thomas-
> > [email protected]>; Brockhaus, Hendrik (T RDA CST SEA-DE)
> > <[email protected]>
> > Subject: Re: [Anima] BRSKI-AE document split discussion
> >
> > Hi Toerless,
> >
> > Thank you for the positive info regarding the draft split and your
> > concrete proposal about the way forward with the documents and the
> > concrete questions to be answered. That also helps to identify
> > potential missing information.
> >
> > We will go ahead and discuss the split (content, authors, ...) in the
> > round of current authors and will also provide proposals regarding the
> > naming. The plan is to have separate issues in gitlab per draft and
> > send them both to the mailing list once created for further discussion.
> >
> > We still think the approach with two documents is sufficient as also
> > the informative part about the use cases can be clearly separated. As
> > UC2 reverses the role of the pledge from initiator to responder the
> > application can be motivated using different examples. That said,
> > working on both in parallel should be possible. We will try to keep
> > the informative part concise and specific for the normative part. As
> > soon as we have further output from the discussion, we will post it to the
> list.
> >
> > Best regards
> > Steffen
> >
> >
> > > -----Original Message-----
> > > From: [email protected] <[email protected]>
> > > Sent: Donnerstag, 7. Oktober 2021 20:22
> > > To: Fries, Steffen (T RDA CST) <[email protected]>
> > > Cc: Michael Richardson <[email protected]>; Werner, Thomas (T
> > RDA
> > > CST
> > > SEA-DE) <[email protected]>; [email protected]
> > > Subject: Re: [Anima] BRSKI-AE document split discussion
> > >
> > > Steffen, *:
> > >
> > > AFAIK, we should not need any new adoption call for splitting up the
> > > document as long as we do not change the scope of the new documents
> > > to be in summary not different to what the WG has already agreed to
> > > work on
> > for BRSKI-AE.
> > > And i think all work is within that WG adopted scope. But i've
> > > reached out to others to check if this statement is correc.
> > >
> > > I think splitting up makes a lot of sense to help accelerate the process.
> > >
> > > The split into one draft for use-case 1 and anothrer for use-case 2
> > > is fine, but not the only option you could consier (see below). If
> > > you want to do that split, i think both resulting drafts should be
> > > standards
> track.
> > >
> > > For example for use-case 1:
> > >
> > > I) the normative part (if i understand your target right) is really
> > > the requirements for pledges and registrars to support
> > > a) the pre-EST part of BRSKI (but no need to support the EST part,
> > > and likely also not some other details like ACP requirements...
> > > TBD detail work).
> > > b) lightweight CMP according to (draft-lamps.... - probably multiple)
> > > c) transfering state from a) to b) (aka: using the keying material from
> > > a) for b). Figure out which option is MTI, e.g.: same https
> > > connection,
> > > or rather https for BRSKI then http for lightweight CMP (probably
> > > thats
> > > the safest/easiest requirement ?).
> > > d) likely a specific profile for the discovery part between pledge and
> > > registrar (you just want mDNS ? forgot...).
> > > e) transport: Are we fine with MUST-ONLY IPv6, no IPv4 ?
> > >
> > > The core output is that client/registrars that implemen ONLY the
> > > MUST parts of this spec MUST interoperate ;-)
> > >
> > > So this is actually good and hopefully logically simple, but in thre
> > > deteals of MUST/SHOULD/MAY good profiling work for the draft.
> > >
> > > This normative part can be driven purely by the requirement to
> > > support BRSKI for clients that already support CMP and therefore
> > > will easily be able to support the lightweight CMP profile and
> > > should not also have to
> > implement EST.
> > >
> > > The information part of the document would be the larger picture
> > > showing the framework picture and explaining how one can
> > > a) in general replace BRSKI-EST to the client by other protocols,
> > > and that this spec is specifying one particular instance of that
> > > relying on a lightweight CMP-profile.
> > >
> > > b) describing that a specific set of features for the
> > > pledge-registrars protocol are required or beneficial
> > > to support asynchronous operastions in the backend well,
> > > and that this document specification for pledge-brski with CMP does
> > > meet those requirements but does NOT specify any new
> > > backend protocol for backend AE (but that that is subject to
> > > other documents).
> > >
> > > Aka: In my opinion i would then title that document as something
> > > like "BRSKI for pledges with lightweight CMP (BRSKI-plCMP)"
> > >
> > > And as you suggested in the DT meeting, feel free to ask the titling
> > > question on the list pointing to a github issue.
> > >
> > > Very much the same approach of spllitting use-case 2 into
> > > information framework aspects and the normative protocol spec.
> > >
> > > Now, alternatively, you could go for 3 documents, where you keep the
> > > informational parts of both use-case 1 and use-case 2 together in a
> > > single informational framework document and simply split out the
> > > normative parts of use case 1 and 2 into the two
> > > normative/standards-track
> > draft.
> > >
> > > What i would recommend is to simply start drafts for the normative
> > > parts of use- case 1 and (not necessrily at the same time) use-case
> > > 2, and soo how thy look like standalone, and referring back to the
> > > original (current) draft that would be stripped down and continue to
> > > be the
> > informational framework draft.
> > >
> > > I would hope that 3-split and incremental work on only the normative
> > > new drafts might end up not only being what i personally would hope
> > > to be best readable, but also least amount of work to you as the authors.
> > > Copy&paste what seems normative, improve / harden in the new draft,
> > > then remove text from the current draft.
> > >
> > > WG-last-call and IESG review always hates long-winding explanations
> > > in normative specifications for example. And if there is any
> > > duplication between the two specifications, it would be in their
> informative parts.
> > >
> > > If you feel the informative parts are also best put into the two new
> > > normative drafts, then do that as well, and he current draft becomes
> > empty and dies.
> > >
> > > Cheers
> > > Toerless
> > >
> > >
> > >
> > > On Tue, Oct 05, 2021 at 03:02:39PM +0000, Fries, Steffen wrote:
> > > > Hello Toerless, hello Michael,
> > > >
> > > > Sorry for not being able to react earlier. Based on the response
> > > > from Michael,
> > > would that be your view as well Toerless?
> > > > We just want to ensure that we can go forward with the split under
> > > > the
> > > assumption that beside the split as technically described in Thomas'
> > > last email
> > >
> >
> (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmai
> > > larch
> > >
> >
> ive.ietf.org%2Farch%2Fmsg%2Fanima%2FydPpdwGC4sJ3GY5Tq44nK1hZ4MU
> > %2
> > >
> >
> F&data=04%7C01%7Csteffen.fries%40siemens.com%7C262a97ab276f45
> > 6b
> > >
> >
> 487108d989bf63e0%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C6
> > >
> >
> 37692277381958061%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
> > Ai
> > >
> >
> LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Ib
> > N
> > >
> >
> 5OhI%2Bq1U6nP04HnVC7CwGKiK%2B6h1VkQzYZUu%2BzaY%3D&reser
> > ved
> > > =0), we should come up with names for the drafts reflecting the
> > > target and potential adaptations in the authors list. I would assume
> > > that the two resulting drafts can be submitted as WG documents, as
> > > they basically reflect the current WG draft content in separate
> documents.
> > > >
> > > > Toerless, can we proceed in that way?
> > > >
> > > > Best regards
> > > > Steffen
> > > >
> > > > > -----Original Message-----
> > > > > From: Michael Richardson <[email protected]>
> > > > > Sent: Donnerstag, 23. September 2021 00:36
> > > > > To: Werner, Thomas (T RDA CST SEA-DE) <thomas-
> > [email protected]>;
> > > > > [email protected]
> > > > > Cc: [email protected]; Fries, Steffen (T RDA CST)
> > > > > <[email protected]>
> > > > > Subject: Re: [Anima] BRSKI-AE document split discussion
> > > > >
> > > > >
> > > > > I think that Thomas' explanation makes sense.
> > > > >
> > > > > Split the document. I suggest you clone the repo, and post a
> > > > > second copy under a new name.
> > > > >
> > > > > --
> > > > > Michael Richardson <[email protected]> . o O ( IPv6 IøT
> > consulting )
> > > > > Sandelman Software Works Inc, Ottawa and Worldwide
> > > > >
> > > > >
> > > > >
> > > >
> > > > _______________________________________________
> > > > Anima mailing list
> > > > [email protected]
> > > >
> >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> > .
> > > >
> > >
> >
> ietf.org%2Fmailman%2Flistinfo%2Fanima&data=04%7C01%7Csteffen.fri
> > es
> > > >
> > >
> >
> %40siemens.com%7C262a97ab276f456b487108d989bf63e0%7C38ae3bcd9579
> > > 4fd4ad
> > > >
> > >
> >
> dab42e1495d55a%7C1%7C0%7C637692277381968065%7CUnknown%7CTWFp
> > b
> > > GZsb3d8ey
> > > >
> > >
> >
> JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
> > 7C
> > > 100
> > > >
> > >
> >
> 0&sdata=XpRDNqux39%2FK38bh7qnkxtrhUqnhl60RlUgbYYK6k8c%3D&a
> > mp
> > > ;reser
> > > > ved=0
> > >
> > > --
> > > ---
> > > [email protected]
> >
> > _______________________________________________
> > Anima mailing list
> > [email protected]
> >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> >
> .ietf.org%2Fmailman%2Flistinfo%2Fanima&data=04%7C01%7Csteffen.fr
> >
> ies%40siemens.com%7Cb4ff8a86440d4c1ea7d208d98a35a24b%7C38ae3bcd9
> >
> 5794fd4addab42e1495d55a%7C1%7C0%7C637692785248630055%7CUnknown
> > %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
> >
> WwiLCJXVCI6Mn0%3D%7C1000&sdata=W%2Bd3pvhLTSA1RXLlZR6pbDG
> > qTZl2i4vlWriuorVSNyk%3D&reserved=0
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
