Thanks a lot, BRSKI authors (i think primarily Michael had the pain
of working through my feedback holding the editor pen.)
I have examined the mailing list feedback for all the incremental work
done since -09 including calls we had discussing/resolving several
of the issues. I like most of the work/fixes done towards -14 and
agree or at least accept the rest. Just few tiny bits leftover
(see below). For brevity i am not going to walk through the other
points, but thanks a lot for the discussion replies, especially
when proving me wrong (;-).
[ Pls. let me know if i overlooked responding to any open issue you
wanted to get an answer from me to, i hope/think, there is none. ]
I am pretty happy with the BRSKI document now (-15). Obviously the
last versions also had a lot of other important fixes/improvements made,
not only those from the shepherd review.
The authors asserted that the document is ready for WG last call, and i agree.
Cheers
Toerless
---
> > f) IMPORTANT: Please add/define the term "ANI"
>
> > ANI - "Autonomic Network Infrastructure". Systems that support both BRSKI
> > and
> > Autonomic Control plane - ACP ([I-D.ietf-anima-autonomic-control-plane]).
> > ANI
> > systems (pledges, proxies, registrar) have specific requirements detailled
> > in
> > the document.
>
> <t hangText="ANI:">The Autonomic Network Infrastructure as
> defined by <xref target="I-D.ietf-anima-autonomic-control-plane"
> />. This document details specific requirements for pledges,
> proxies and registrars when they are part of an ANI.</t>
>
> Does this work for you?
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.
---
> > 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.
---
> 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).
---
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.
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
