Toerless Eckert <t...@cs.fau.de> wrote:
>> > 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.
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?
>> > 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 [
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
