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 ;-)

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. 

Secondly, the scope of such new documents is likely much easier to set than it 
was with the
original documents.

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 ;-).

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. 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.

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

Reply via email to