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