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%2Fmailarch > ive.ietf.org%2Farch%2Fmsg%2Fanima%2FydPpdwGC4sJ3GY5Tq44nK1hZ4MU%2 > F&data=04%7C01%7Csteffen.fries%40siemens.com%7C262a97ab276f456b > 487108d989bf63e0%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C6 > 37692277381958061%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi > LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=IbN > 5OhI%2Bq1U6nP04HnVC7CwGKiK%2B6h1VkQzYZUu%2BzaY%3D&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. > > > > 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) <[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.fries > > > %40siemens.com%7C262a97ab276f456b487108d989bf63e0%7C38ae3bcd9579 > 4fd4ad > > > dab42e1495d55a%7C1%7C0%7C637692277381968065%7CUnknown%7CTWFpb > GZsb3d8ey > > > JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C > 100 > > > 0&sdata=XpRDNqux39%2FK38bh7qnkxtrhUqnhl60RlUgbYYK6k8c%3D& > ;reser > > ved=0 > > -- > --- > [email protected] _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
