On Thu, May 31, 2018 at 03:07:15PM -0400, Michael Richardson wrote:
>     > I would prefer to have the simple definition "ANI == systems that 
> support
>     > both BRSKI and ACP" in the doc itself. Threre is really no single 
> authoritative
>     > normative document for ANI, so it should simply be stated equally in 
> BRSKI and
>     > ACP. Rest of text is fine.
> 
> I'm not getting what you are suggesting.
> I think you are saying that we shouldn't point at ACP for the ANI term, but
> rather define it ourselves?

Yes.

Thanks
    Toerless

>     >> > Without this term we can not nail down the explicit requirements 
> against
>     >> > ANI Pledges, Proxies, Registrars that we need from the document (and 
> distinguish
>     >> > from requirements against any non-ANI adaptation of BRSKI). I added 
> according
>     >> > comments into other parts of the doc.
>     >> 
>     >> > g) Please replace "MASA server" with "MASA service" everywhere.
>     >> 
>     >> I prefer to just say "MASA" actually.
>     >> Are you okay with that?
> 
>     > Yes. There are a few leftovers of "MASA server" in -14 though. Pls fix.
> 
> fixed them all, I hope.
> 
>     >> There is no requirement that the Join Registrar is also the EST for the
>     >> purposes of ongoing certificate renewal.  I don't know if you are 
> speaking
>     >> about certificate lifetime management (renewal, etc.) when you say
>     >> "EST Enrollment service".  I'll assume that you mean that for the 
> moment.
>     >> 
>     >> In a big network I would want the roles (bootstrap and initial 
> certificate,
>     >> vs certificate renewal) split up.    
> 
>     > Lets in any case consider this issue closed or BRSKI, because it loooks 
> now like
>     > scope creep to me to discuss it for this draft. I'll probably have this 
> discussion
>     > on my hand for ACP anyhow, because (only) ACP needs to be concerned 
> about
>     > initial bootstrap and renewal (just working through that in ACP doc 
> because
>     > of the ongoing review of it).
> 
> okay.
> 
>     > 4.1.1:
> 
>     >> transport-proto  = IPPROTO_TCP / IPPROTO_UDP / IPPROTO_IPV6
> 
>     > The way i see it, the normative approach with TCP circuit proxy would
>     > always only have TCP, right, e.g.: the line should say
> 
>     > transport-proto  = IPPROTO_TCP ; Not considering non-normative
>     > ; options like Appendix C.
> 
> I'll reply to Brian.
> 
> -- 
> ]               Never tell me the odds!                 | ipv6 mesh networks 
> [ 
> ]   Michael Richardson, Sandelman Software Works        | network architect  
> [ 
> ]     m...@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    
> [ 
>       



> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima


-- 
---
t...@cs.fau.de

_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Reply via email to