> On 1. Mar 2018, at 18:36, Toerless Eckert <[email protected]> wrote: > >> On Thu, Mar 01, 2018 at 06:45:27AM +0000, Fries, Steffen wrote: >> We came up with the proposal as the current title of the document gives the >> impression, that BRSKI would solely work with EST as it is the only example >> stated. As we see different use cases, which already target CMP, we thought >> it would be good to cover it in the base document. If the schedule of the >> document is that tight, then an extension in terms of a separate document >> might be the way to go. > > Lets see, i think the WG hat is most fitting for this email, but not quite > sure: > > Its not only the timing, its also the complexity of a resulting document. How > about we wire an RFC that descrbies both IPv4 and IPv6 together in one doc ? > Would you think thats a good document structure ? The comparison may suck, > but i think the resulting documents would suck even more ;-) > Well, I see were you are heading to ;-) The intention of the proposal was not to increase the complexity of the base document. But given your example, having a base document that is agnostic to the enrollment and enhancement documents that map an enrollment protocol would probably be ideal regarding complexity. From your statement below, I conclude that the process of document creation and scoping can be cumbersome. But‚ I‘m certainly not in the position to argue about document structure as I’m stepping in late.
> We already have in all our first round documents that we >> re just finishing now the problem of scope creep and i wish we could have >> more modularized document structure, but i think this is a common problem of >> starting working groups, that if you start with many documents, especially >> when you're interdepending, you increase the chance of failing on a piece. > > Once we have shown success of round one with BRSKI/ACP, i think it will be a > lot easier, to get variations of these themes as working group drafts, > especially when there is a clear industry desire for such variations: > > For once, a variation can always be less explanatory by hopefully being able > to refer to > the base document (like BRSKI) for explanations and/or reuse. This supports my impression of the base document and additional enhancement documents. > > Secondly, the scope of such new documents is likely much easier to set than > it was with the > original documents. Agreed > > Thirdly, IMHO, such variations might not even need re-chartering as long as > they can be > interpreted to do the same thing as what we've already chartered. > In the case of the ''BRSKI'' charter item, i would say that procedures for > better support of > offline device bootstrap should already be in charter. BRSKI has already some > loose suggestions > in appendices. Of course, AD ultimately decides (after WG proposes ;-). Step 5 in section 2.1 in BRSKI mentions EST as example for an enrollment protocol. Based on that I assumed other enrollment protocols would in general applicable as well. > I personally do very much welcome document submissions for work in this area, > even if just > to stop scope creep discussion for the BRSKI document, but i think as a WG we > should not > try to accept this as a WG item before we have pushed BRSKI to IESG, but i > would really like that to > happen before 102. You made it clear that finishing the base spec has the highest priority. > More importantly though, it would be nice to discuss what scope specific > documents > should have. We already have variations of BRSKI and vouchers coming up, and > i can see > especially for supporting offline operations a lot of possible varieties. Yes, I‘m sure there are several approaches for offline enrollment. The reason for proposing a profile of CMP basically stems on its success in existing deployments for online and offline use cases in a single solution. Regards Steffen > > Cheers > Toerless > >>> Brian >> >> _______________________________________________ >> 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
