Re: [Anima] join proxy documents

[Toerless Eckert <[e-mail]>]

Inline

On Tue, Sep 22, 2020 at 04:06:49PM -0400, Michael Richardson wrote:
> 
> first, I reposted
>        Name:		draft-richardson-anima-state-for-joinrouter
>        Revision:	03
> 
> It was done during the early days of BRSKI to collect some options in, but
> was never intended to be published. I think that the reference.XXX file
> disappeared.
> 
> second, I have edited
> 
> Name:		draft-vanderstok-anima-constrained-join-proxy
> Revision:	04
> Title:		Constrained Join Proxy for Bootstrapping Protocols
> Document date:	2020-09-22
> Group:		Individual Submission
> Pages:		20
> URL:            https://www.ietf.org/id/draft-vanderstok-anima-constrained-join-proxy-04.txt
> Status:         https://datatracker.ietf.org/doc/draft-vanderstok-anima-constrained-join-proxy/
> Html:           https://www.ietf.org/id/draft-vanderstok-anima-constrained-join-proxy-04.html
> Htmlized:       https://tools.ietf.org/html/draft-vanderstok-anima-constrained-join-proxy-04
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-vanderstok-anima-constrained-join-proxy-04
> 
> a bunch and reposted it.

Ok, have to re-read to page in the context of these documents into my brain ;-)

> I have changed occurances of EST Server to "BRSKI Registrar", as I think that
> is more accurate.

Not in draft-richardson-anima-state-for-joinrouter from my quick read.

> Did we really want to standardize the StateFUL join proxy?

Uhmm... isn;t that what we're doing with BRSKI proper ? That's a stateful join proxy,
right ? Aka: your question seems to be missing some more context
(stndardize stateful join proxy for context XXXX... ?)

> Is it really interesting or relevant?  It seems trivial.
> If we are, then we should contrast it.  An important clue is that it does not
> behave any differently, FROM THE PLEDGE point of view.
> 
> The WG had expressed an interest in adopting this document, but the WG chairs
> have not provided any clear guidance on where they we go.

I thought we primarily had the issue of the named author having unfortunate issues
to drive the document. If you want to take on the ditors helm for it, then
the chairs will be happy to proactively see how to progress the document in the WG...

> This document could be merged into ietf-constrained-voucher, but I think we
> made it a separate document because it is not needed on all networks, just
> *constrained* multihop/MESH networks.

Yes, we have some decisions to make wrt. how much to merge into fewer documents and
how much to keep the solution definition modular.

Given how we went through half a decade of probably too-big-documents in ANIMA,
as an individual conributor i would err on the side of more smaller documents, but
i guess as a WG chair i should just leave it to authors and rough consensus of the
WG.

Cheers
    Toerless

> --
> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide



> _______________________________________________
> Anima mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima


-- 
---
[e-mail]