Subject: Re: [Anima] BRSKI-AE document split discussion

From: "Fries, Steffen" <[email-masked]>
Date: Tue, 5 Oct 2021 15:02:39 +0000

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://mailarchive.ietf.org/arch/msg/anima/ydPpdwGC4sJ3GY5Tq44nK1hZ4MU/),  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-masked]>
> Sent: Donnerstag, 23. September 2021 00:36
> To: Werner, Thomas (T RDA CST SEA-DE) <[email-masked]>;
> [email-masked]
> Cc: [email-masked]; Fries, Steffen (T RDA CST) <[email-masked]>
> 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-masked]>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
>

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 7 Oct 2021 20:22:12 +0200

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:
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

-- 
---
[email-masked]

---

From: "Fries, Steffen" <[email-masked]>
Date: Fri, 8 Oct 2021 08:28:18 +0000

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

> From: [email-masked] <[email-masked]>
> Sent: Donnerstag, 7. Oktober 2021 20:22
> To: Fries, Steffen (T RDA CST) <[email-masked]>
> Cc: Michael Richardson <[email-masked]>; Werner, Thomas (T RDA CST
> SEA-DE) <[email-masked]>; [email-masked]
> 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.
> 
> 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.
> 
> I) the normative part (if i understand your target right) is really the requirements
> for pledges and registrars to support
> 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
> 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.
> 
> 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
> 
> 
> 
> > 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%2Fmailarch
> ive.ietf.org%2Farch%2Fmsg%2Fanima%2FydPpdwGC4sJ3GY5Tq44nK1hZ4MU%2
> F&amp;data=04%7C01%7Csteffen.fries%40siemens.com%7C262a97ab276f456b
> 487108d989bf63e0%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C6
> 37692277381958061%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi
> LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=IbN
> 5OhI%2Bq1U6nP04HnVC7CwGKiK%2B6h1VkQzYZUu%2BzaY%3D&amp;reserved
> =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.
> >
> > > Split the document.  I suggest you clone the repo, and post a second
> > > copy under a new name.
> > >
> > > --
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> >
> ietf.org%2Fmailman%2Flistinfo%2Fanima&amp;data=04%7C01%7Csteffen.fries
> >
> %40siemens.com%7C262a97ab276f456b487108d989bf63e0%7C38ae3bcd9579
> 4fd4ad
> >
> dab42e1495d55a%7C1%7C0%7C637692277381968065%7CUnknown%7CTWFpb
> GZsb3d8ey
> >
> JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C
> 100
> >
> 0&amp;sdata=XpRDNqux39%2FK38bh7qnkxtrhUqnhl60RlUgbYYK6k8c%3D&amp
> ;reser
> > ved=0
> 
> --
> ---
> [email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Sun, 10 Oct 2021 12:51:16 -0400

Fries, Steffen <[email-masked]> wrote:
    > 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.

The MT makefiles support having multiple drafts in the same github repo, but
you could also just fork the repo.
I suggest that it may be simpler to fork the repo, because then we'll be more
clear about which issue is for which document.

But, you could go the other way too if you thought that many issues would be
cross-document.

---

From: "Fries, Steffen" <[email-masked]>
Date: Mon, 11 Oct 2021 09:44:06 +0000

Hi Michael

> Sent: Sonntag, 10. Oktober 2021 18:51
Forking the repo is probably the best way forward.

Best regards
Steffen

---

From: "Fries, Steffen" <[email-masked]>
Date: Thu, 14 Oct 2021 07:05:01 +0000

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

> From: Anima <[email-masked]> On Behalf Of Fries, Steffen
> Sent: Freitag, 8. Oktober 2021 10:28
> To: [email-masked]
> Cc: Michael Richardson <[email-masked]>; [email-masked]; Eliot
> Lear <[email-masked]>; Werner, Thomas (T RDA CST SEA-DE) <thomas-
> [email-masked]>; Brockhaus, Hendrik (T RDA CST SEA-DE)
> <[email-masked]>
> 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
> 
> 
> > Cc: Michael Richardson <[email-masked]>; Werner, Thomas (T
> RDA
> > CST
> > 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.
> >
> > want to do that split, i think both resulting drafts should be standards track.
> >
> > I) the normative part (if i understand your target right) is really
> > the requirements for pledges and registrars to support
> > So this is actually good and hopefully logically simple, but in thre
> > deteals of MUST/SHOULD/MAY good profiling work for the draft.
> >
> > 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
> > 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.
> >
> > 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.
> >
> > parts of use- case 1 and (not necessrily at the same time) use-case 2,
> > original (current) draft that would be stripped down and continue to be the
> informational framework draft.
> >
> > 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.
> >
> > 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
> >
> >
> >
> > =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.
> > >
> > > > Split the document.  I suggest you clone the repo, and post a
> > > > second copy under a new name.
> > > >
> > > > --
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .ietf.org%2Fmailman%2Flistinfo%2Fanima&amp;data=04%7C01%7Csteffen.fr
> ies%40siemens.com%7Cb4ff8a86440d4c1ea7d208d98a35a24b%7C38ae3bcd9
> 5794fd4addab42e1495d55a%7C1%7C0%7C637692785248630055%7CUnknown
> %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
> WwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=W%2Bd3pvhLTSA1RXLlZR6pbDG
> qTZl2i4vlWriuorVSNyk%3D&amp;reserved=0

---

From: "Fries, Steffen" <[email-masked]>
Date: Thu, 14 Oct 2021 15:56:06 +0000

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

> From: Fries, Steffen (T RDA CST)
> Sent: Donnerstag, 14. Oktober 2021 09:05
> To: [email-masked]
> Cc: Michael Richardson <[email-masked]>; Eliot Lear
> <[email-masked]>; Werner, Thomas (T RDA CST SEA-DE) <thomas-
> 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
> 
> > 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 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
> >
> >
> > > 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.
> > >
> > > 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.
> > >
> > > The core output is that client/registrars that implemen ONLY the
> > > MUST parts of this spec MUST interoperate ;-)
> > >
> > > 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.
> > >
> > > Aka: In my opinion i would then title that document as something
> > > like "BRSKI for pledges with lightweight CMP (BRSKI-plCMP)"
> > >
> > > Very much the same approach of spllitting use-case 2 into
> > > information framework aspects and the normative protocol spec.
> > >
> > > 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
> > > 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.
> > > 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.
> > >
> > .

---

From: Michael Richardson <[email-masked]>
Date: Thu, 14 Oct 2021 16:28:49 -0400

Fries, Steffen <[email-masked]> wrote:
    > 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.

As discussed at the design team meeting, this works for me.

BRSKI-PRM => pronounced Brewski-Prime.
  see: https://en.wikipedia.org/wiki/Optimus_Prime