Re: [Gen-art] Gen-art LC Review of draft-ietf-anima-autonomic-control-plane-13

[Toerless Eckert <[e-mail]>]

Hi Elwyn, *

Sorry for the long delay. Somehow i ended up working through the reviews
in stack, not in timeline order, and the excellent review from Joel Halpern
had me do more than i was hoping for. But as i hope all for the better
of the document. But together with business travel etc. it did delay
this feedback to your review a lot. Sorry.

I forgot to commit an intermediate version working through your comments
before the nits, but this response mail does include copies of the
changed texts for those changes anyhow. I did create a version before working
on the nits, so here is the diff created for your nits.


http://tools.ietf.org//rfcdiff?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-14-jh3.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/f9b00048946af77d8b716ec4c9e28e1d6a95b455/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-14.txt

Rest Inline.

Thank you very much & keep it coming!

Cheers
    Toerless

On Wed, Feb 28, 2018 at 02:24:09AM +0000, Elwyn Davies wrote:
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> 
> Document: draft-ietf-anima-autonomic-control-plane-13.txt
> Reviewer: Elwyn Davies
> Review Date: 2016/02/27
> IETF LC End Date:  2016/02/26
> IESG Telechat date: (if known) -
> 
> Summary:  Not ready.  There are a number of minor issues and a host of nits and editorial fixes needed.  I would also consider that the expected status (expeimental vs standards track) ought to be discussed on account of the areas where it is incomplete (e.g., incompleteness of the key Intent mechanism).

Wrt standard track:

ACP was targeted from day 1 of ANIMA charter to be standards track.
Experience with existing implementations and the technologies used by
ACP make this IMHO very appropriate. 

All the protocol mechanisms required for and used by
the ACP are well defined and their interactions (i hope) are well
specified in the normative sections of the ACP document.

ACP design is actually quite conservative, leveraging mostly
well known technologies/protocols, just combining them in a 
much more automated way than prior solutions. 

The only significant new protocol the ACP uses is GRASP,
which also targets standard track, and which was developed
with ACP as a use-case in mind to solve problems with prior,
IMHO more complex protocols.

We also have a range of implementations ranging from
commercial/production over to experimental/open-source.

> Major issues:
> I am sure this has been considered elsewhere, but the amount of future work and areas where operation might discover problems indicates to me that maybe this should be an experimental proposal rather than standards track.

Wrt future work: 

Maybe there is a misunderstanding. The term "future work"
in the ACP draft is not meant to indicate things that need
to be resolved in this document before it can become RFC
or that limit the ability of the ACP to support the use
cases it it designed for.

All references to "future work" are informational. They
refer to features considered valuable during WG work,
but did not make the cut when we defined the minimum
viable product for ACP (which is now its MUST/SHOULD/MAY). 

During chartering, ANIMA was asked by the AD to NOT
work on pure architecture documents, but concentrate on
specification. During the resulting WG work, it became
obvious that its hard to make the community understand 
the overall system design without being more explanatory
and that includes extensions and interactions with
future components like Intent. So a good amount of
explanatory text including mentioning of futures
is a stand in for not having another document to
discuss more in-depth background information on a novel
system design.

If it helps, i am happy to change "future work" to
"future documents", but "future work" is the most
popular term in existing RFCs.

Wrt intent:

ANIMA charter so far is to define ANI: ACP,GRASP,BRSKI
as a common infra for non-autonomic and future autonomic
networks. Intent is only a part of envisioned future autonomic
networks, so Intent is not necessary to use ACP/ANI in todays
networks. It is mentioned in ACP primarily so that
future work for Intent understands how ACP
would like to use Intent itself if/when it is available.
Specifically the issue of designing it so circual dependencies
with ACP are avoided/resolved.

Wrt: "operation might discover problems"

Simple answer ? 

The ACP is very simple to operate, the suggested operational
considerations in the draft are quite limited but IMHO very important. 

Ranting answer ? 

I really frightened by this comment, because i think
it can encourage the bad habbit of ignoring or at least
not documenting operational aspects of solutions  in RFCs
to make them look better. Especially when many existing solutions
are extremely difficult to manage: 

    "Nerd knob heaven - SDN controller to the rescue"

With ACP we do attempt to do the opposite: Make it as easy to operate
as possible and document the remaining operational aspects well
to accelerate adoption based on our pre-standard implementation
experience

I can only guess what specifically you are referring to,
because you did not specify it:

Section 10.2 discusses desirable/suggested diagnostics and 
-14 new section 10.3 desirable configuration (for registrars).
These sections are intended to be precursors/suggested requirements
to future YANG models specifying the operator interface to the ACP.

I have developed, deployed and operated a commercial
ACP implementation. The operator interface
aspects discussed in 10.2/10.3 are from reflection
of that experience. Diagnostics for implementation issues
and operator mistakes, smallest number of nerd knobs that
we think would make the solution low-opex and by minimizing
the opportunity for operational mistakes.

To put this into perspective:

I have also designed, developed or operated a range
of enterprise VPN technologies/solutions (including their PKI), 
all of which are widely used and deployed and use
standard IETF protocols and IETF standard PKI crypto.

That stuff is IMHO orders of magnitude more complex than
ACP, full of nerd-knobs and IMHO very error prone
(did i say SDN controller to the rescue ?). Yet you
will not find any good IETF specifications of most
operational aspects of these solutions exposing their
complexity (diagnstics, config CLI, better automation, ...).

Aka: The amount of suggested operational interfaces to
manage the ACP as discussed in 10.2/10.3 is very
small compared to what you would need to document
to support the same degree of implementation and
operator issue diagnostics and configuration for
any of the pre-existing IETF standard based system 
solutions leveraging similar technologies (PKI, encryption, VPN, VRF,...)

> Minor issues:
> Clarity regarding limitations of the ACP approach:The document is relentlessly positive about the ACP approach.  Clearly certain problems will not allow the ACP to function.  For example it implies that the physical network and interfaces are a shared resource: low level failures or misconfiguration at (say) Level 2, may still knockout the ACP as well as the data-plane.  Some brief words on this would not go amiss.  This could well be in s4.

Wrt. "relentlessly positive"

Please point me to specific places you consider to be
"relentlessly positive" ? I will be happy to re-word them
factually.

Wrt. implementation options

Unlike the documentation of operator interfaces discussed
above, that i am adament to include in the specification
we choose not to include any of this implementation
specific discussion because it really does not fit into
this document (IMHO):

We have prototyped, productized or brainstormed a wide
range of implementation options. Neither of them is
really short to document or IMHO appropriate for this
document, but they all impact the degree of solving
local, non-interoperability issues you mention. Instead,
10.2/10.3 specifically limits itself to discussing
issues we hope  are independent of implementation choices.

I would love to find the time to write an informational
document discussing principle implementation alternatives
and their pro/cons because i think some of them are also quite
fundamental for how to design network OS software
and could equally find applicability in other longer
term IETF relevant network SW architectures, like slices or virtual
routers.

I am actually relentlessy negative about some
well-understood implementation options for exctly the
reasons you mention. But i am likewise relentlessly
positive about implementation options that would solve
these issues. And yes, i think there are feasible
implementation options to make the ACP fully resilient
against the issues you mention with the right
implementation option.

If you're not persudaded to leave such implementation
discussion for other work, maybe we can take it offline.
I do not want to drag this on too much in this thread.

> s2, para 2: There are several instances in the terminology definitions that are confusing before the term has been fully introduced later (and in some cases even then, e.g., the cryptic reference to 'paragraph 21' in the ACP address definition.)  This should be cleared up.  Notes are given in the Nits/Editorial comments below,

I am not a big fan of cross-referencing between terms defined
in the terminology section. Not only because i think its somewhat
obvious that if you don't know a word, you gotta look it up
in *doh* the terminology section, but also because the tooling
we have with our XML really sucks for this problem. That paragraph 21 was my
first attempt to create a cross reference into another
term defined in the terminology section and it failed as you saw.
I've figured out a better way in -14 (see ACP domain certificate),
but its very cumbersome trying to create these for all terms
where the XMl tooling should really make this a lot easier.
I've left myself a breadcrumb to disuss this with RFC editor.

So, if you have specific enumerated terms you see, please tell
me, i'll do the chores, but let me try not to have to do it for
all of them unnecessarily.

> s4, "ACP4", also s6.8.2:
> > Clients of the ACP MUST
> >            NOT be tied to a particular application or transport protocol.
> 
> It may be that I don't understand the problem, but the communication between the ACP nodes seems to be tied to the secure channels.  I am not sure how this is compatible with the any transport protocol requirement.  There doesn't seem to be any further explanation of how this requirement is fufilled.  This is linked to he means that is not specified by which the ACP address TLS connections are connected to the secure channels.  This may be because I don't understand the problem

Hah. So this whole section was basically the result of a long
discussion during initial ANIMA work about our self-defined requirements
(before chartering if i remember right).

The initial argument was made that ACP just needs to provide
resilient GRASP connectivity between nodes because all AN will
use is GRASP. Then we started to include the need to support non-AN
networks with ACP as well and ACP4 was written to effectively
argue that ACP needs to provide IPv6 connectivity.

I think you're something like the third reviewer or so whom
i have to explain this, so i finally dared to add the explanation
to this requirements chapter that i really didn't
want to touch, because its like the five commandments to the ACP.

<t>Explanation for ACP4: In a fully autonomic network (AN),
newly written ASA could potentially all communicate exclusively 
via GRASP with each other, and if that was assumed to be the 
only requirement against the ACP, it would not need to provide
IPv6 layer connectivity between nodes, but only GRASP connectivity.
Nevertheless, because ACP also intends to support non-AN networks,
it it is crucial to support IPv6 layer connectivity across the
ACP to support any transport and application layer protocols.</t>

Not sure about your confusion about TLS. There is no linkage
between any end-to-end security connections and they ACP.
The ACP just blindly hop-by-hop encrypts to protect the ACP
infra. So there is what looks like duplication of security effort,
but end-to-end and hop-by-hop security really serve two complementary
purposes even though the hop-by-hop encryption also stands
in for missing end-to-end encryption of legacy OAM protocols.
I thought i also wrote that somewhere in the doc.

> s6.1.1:  RFC 5280 discusses the option of leaving the subjectName blank if the subjectAltName is present.  What would we expect to find in the subjectName field of the ACP Domain cert?

"I don't know and ACP does not care"

ACP only cares for the subjectAltName email address
carrying the ACP domain information. No other field is
required to be present in the cert to pass the mutual ACP
domain cert authentication. As far as ACP is concerned,
subjectName could be empty.

We did choose this so we would not step on any subjectName
a cert might want to have if its used dual-purpose for ACP
domain authentication and any other auhentication that
may pre-exist on the device. So in all likelyhood,
the subjectName will include whatever a standard cert
on a device includes and it just also includes the
ACP domain information field.

Let me know if i am missing any explanation.
I thought i'd already explained everything possible for the section.

> s6.1.1:  I don't understand where the routing-subdomain element is
> carried.  routing-subdomain is a top level production in the ABNF that
> isn't referenced in the rest of the ABNF and a separate example is
> given.  Is the intention that the subjectAltName would consist of a
> sequence of two rfc822names as allowed by the X.509 syntax if the
> routing-subdomain is required?

So we need a domain like acp.ietf.org for domain authentication
and we may want multiple subdomains like bla.bla.acp.ietf.org and
whatever.else.acp.ietf.org if we want to segment routing in the future.

We can not simply encode as [e-mail]
because we wouldn't know what the domain part of this is. ietf.org ?
bla.acp.ietf.org ? both wrong. So we encode the subdomain prefix
rsub in the local part [e-mail]. Then we have the 
ABNF definition of routing subdomain and thats what we refer to
for the ULA hash calculation later in the doc because that creates different
IPv6 prefixes and those different prefixes would allow easy
aggregateable routing areas.

Please let me know where wee lost you in explaining how it work.
Best with suggested text improvements.
> 
> s6.1.3: I don't understand why the EST renewal server address has to (or, at least, might) be configured into all ACP nodes when the EST server announces itself with M_FLOOD messages.  For one thing it goes (further) against automicity.

The explanation is further below in the text: stickyness for easier diagnostics, reduced attack vector. 

I also wanted to have at least one deterministic selection mechanism, and i had to drop
the more intelligent ones like priority or vicinity based, because we'd first need
to get better service parameters for GRASP standardized (draft-eckert-anima-grasp-dnssd)
(too much work for just a one-off definition in the ACP spec).

There is no relevant additional manual work needed to store/remember 
the prior EST server though. But the text wasn't well written. here
is whats in -14:

<t>ACP nodes SHOULD be able to remember the EST server from which they last
renewed their ACP domain certificate and SHOULD provide the ability for this remembered EST server to also be set by an ACP Registrar 
(see <xref target="acp-registrars"/>) that initially enrolled the ACP 
device with its domain certificate. When BRSKI is used for certificate
enrollment, the ACP address of the BRSKI Registrar from the BRSKI TLS
connection SHOULD be remembered and used for the next renewal via
EST if that Registrar also announces itself as an EST server
for renewal via GRASP (see next section) on its ACP address.</t>

Aka: Can be fully automatic when BRSKI is used. And also IMHO with any other
automated mechanism. And just because the ACP node SHOULD support it doesn't
mean that some Registrar SHOULD use this option !!!

> s6.7.x, Security algorithm agility?:  Each of the options specifies a
> MTI, minimum (in today's tems) capability set of cyypto algorithms. It
> is not clear (to me) how this will be adapted if and when these
> algorithms are no longer adequately secure.  Some words on ths may be
> necessary.

Good question. I have no idea what the best statement/text
would be to comply with the IETF BCP for crypto agility.
In fact: is there any such BCP and what is its number ? 

I am only aware of this one 
draft retrofitting static session keys into IKEv2 to overcome
the quantum attacks against RSA/ECC functions like DH.

If you can not suggest text, i was trying to wait for SEC review
to resolve this issue. Unless i stumble into simple example
text earlier that SEC AD would like.

> s9.1, "Network Partition":  I am not sure I believe the story on partition - It seems possinle that one of the segments could be left without an enrollment server after partition.  Am I right and does it matter?

Hah, thank you.

I had to write a bunch of new text about ACP Registrars for -14 after Joel
Halperns review and seeing it as a big gap in the text. He was
also complaining about our addressing scheme, so i wanted to
outline in more detail how the addressing (and its "waste" of 48 bit
of address space for Registrar-IDs) related to the desire to
also support highly resilient distributed solutions. Section 10.3.4
describes now the example of distributed registrars with integrated
sub-CA.

I added the following to 9.1:

  <t>Highly resilient ACP designs can be built by using ACP registrars with embedded sub-CA, as outlined in <xref target="sub-ca"/>. As long as a partition is left with one or more of such ACP registrars, it can continue to enroll new candidate ACP nodes as long as the ACP registrars sub-CA certificate does not expire. Because the ACP addressing relies on unique Registrar-IDs, a later re-merge of partitions will also not cause problems with ACP addresses assigned during partitioning.</t>
  
Relentlessly positive!

> s12: There is no registration policy specified for the new registry created.

Hmm.. MUST be assigned using the Standards Action policy defined by <xref target="RFC8126"/>.

But the paragraph requesting creartion of the registry was duplicated. Maybe that confused you. Fixed.

------------------------------------------------------------------------
> Nits/editorial comments:

Reply syntax:
Gone - Requested fixes had been applied through prior -14 fixes
A&A  - Asked & Answered (above)

> General: The style used for introducing acronyms is not consistent with
> normal RFC style, which is expansion followed by acronym in parentheses,
> thus...
> Example (in the Abstract): s/OAM (Operations Administration and
> Management)/Operations Administration and Management (OAM)/

Ok. Hope i found & fixed all instances of this.

> General: s/e.g.:/e.g.,/ (global)

Done.

> General: In English thequestion mark (?) is not separated by space from the
> last word in the sentence.  There are many instanxes of this problem,
> especially in s10.

Done.

> Exclusive usage of IPv6: It would be useful to mention (probably somewhere
> in the last two paras of s1) that the ACP is stricly an IPv6 construct.

Resolved via new section 1.1 "Applicability and Scope" introduced as
result of another review into -14.

> Abstract and 3 other places: s/out of band/out-of-band/

Done.

> Abstract:  In the last sentence is "not misconfigured" correct?  I would
> have thought it shuld be "misconfigured".

Done.

> s1, para 1: The phraseology "currently being defined in the document" for
> the reference model is not future proof.  Replace with "specified in".

Done

> s1, para 3:  A construct cannot 'run' in a table:
> OLD:
> runs in the global routing table
> NEW:
> runs over the network defined by the global routing table
> END

Fixed as "uses the global routing table"

(scared of trying to defend what "network defined by" would mean,
given how inconsistent this can be from different viewpoints).

> s1, para 3: s/to recover/to avoid or allow recovery/, s/personnel
> is/personnel are/

Done

> s1,para 6: s/data-plen/data-plane/

Gone

> s1, para 8: Expand GRASP on first occurrence  (the terminology definitions
> come in s2).

Done

> s1, para 13 (2nd para on page 6): Suggest  s/without dependency
> against/without reliance on/

Gone

> s1, next to last para: s/It also explains on how existing management
> solutions/It also explains how existing management solutions/

Gone

> s1,last para: s/with full secure/with fully secure/,
> s/[I-D.ietf-anima-reference-model]. which/[I-D.ietf-anima-reference-model],
> which/ [period ->comma], s/it enables building more/it allows the building
> of more/

Done

> s2: There are a few terms that have special meaning within the context of
> the document (e.g., data-plane, loopback interface) which do not use
> capitalized names.  It might be helpful to globally change the names  to
> (eg.) Data-plane Loopback interface where the special meaning is implied.

Done for these two terms. But i am still not sure about explicit rules
for capitalization. Any good reference/rules you could point me to ?

> s2:  It would be useful to note the terms imported from RFC7575.

I would rather not do this. The problem is that the ACP draft
started out assuming an autonomic network like RFC7575 does so it
used all autonomic/AN-* terms, and over time and many reviews
it became clearer that we should avoid any autonomic network
terms because they would often raise the confusion that the
ACP requires a full autonomic network (the few cases of
Intent being the last leftovers). In the last revisions
i did therefore changed most AN-* terms into ACP-* terms to make it
a lot clearer that there is no dependency against (especially undefined)
AN components, and that ACP is really standalone. Last one was
in -14 the definition of ACP Registrar as a superset of of BRSKI
Registrar and any other possible Registrar meeting the now defined
ACP Registrar requirements.

> s2, para 2:  ADD:
> Note that definitions may contain terms that are defined later in the list
> as a result of the alphabetic ordering.
> END

A&A

> s2, "ACP": The term "zero-touch" is jargon that may not be understood by
> non-English mother tongue readers.  Please add a definition or expand it
> here.

Let me partially punt this to BRSKI because thats the doc really responsible
for this. Today it just says "zero-touch (automated)", so i also added
that parenthesis explanation. The first use of zero-touch also refers to BRSKI
as providing it.

> s2, "ACP address":  The term "ACP domain certificate" probably needs a
> definition - this would then point to the RFC that defines the certificate
> type used and hence allow the reader to locate the domain information
> field.

Term was defined but not correct in order. Fixed. Fixed to say RFC5280 certificate.

>  I am unclear what "(paragraph 21)" refers to  - is this terminology
> used in the certificate type?

A&A

> s2, "ACP connect": For consistency this should be "ACP connect interface".

Done

> s2, "ACP secure channel protocol": Expand IKEv2, dTLS.(IPsec is well-known).

Done.

> s2, "ACP (ULA) prefixes":  Given that ULA is a term defined in RFC 4193, I
> would be inclined to expand on first use (here) and refer to the RFC rather
> than part duplicating the formal definition further down.

Actually, RFC4193 uses the word Prefix in its section 3.1 to refer to
the 7 bit IPv6 address prefix identifying the ULA address space. But does not
call it "ULA Prefix". And it doesn't define a term for the /48 prefix that
we need to refer to. So we've used in my memory in ANIMA and at work 
the term ULA Prefix always to refer to the /48 prefixes in the ULA space,
and thats why i want to keep that definition. Unless someone tells me a better
way to solve the issue of how to refer to the /48 prefixes. Which is what we
want to do.

> s2, "data-plane": s/In a full Autonomic Network node/In a fully Autonomic
> Network node/

Done

> s2, "Intent": The term 'Northbound' is a piece of jargon that is not
> well-known outside the SDN community.   This is the only usage in the
> document.  Please expand it here.

Gone

> s2, "RPL": Please add the ref to RFC 6550 here.

Gone

> s2, last para: Given the last sentence, change RFC 2119 -> RFC 8174.

Done

> s3.3, para 1: s/(global routing table)/using the global routing table/ [See
> comment on s1, para 3 above]

Done

> s3.3, para 2: s/unreachable can lock/unreachable or can lock/

Done

> s3.3, para 4: s/allows control plane and management plane/allows the control
> plane and the management plane/

Done

> s4, "ACP3": s/suggests to use/suggests using/

Done

> s5, bullet #5:
> > each node sets up a loopback interface with
> >         its ULA IPv6 address.

> Given the way the IPv6 loopback interface works, this might be better
> described as "adding the ULA IPv6 address to the loopback interface" - there
> is only ever one IPv6 loopback interface per device or VRF.

Changed to "Inside the ACP VRF, each node assigns its ULA IPv6 address to a Loopback interface assigned to the ACP VRF"

On the router OS you can have multiple loopback interfaces,
so do not want to presume three is only one.

> s6, para 2: What certificate must it have?             (the ACP domain cert
> according to s6.1.)

fixed to "must have its ACP domain certificate"

> s6.1, para 3:
> OLD:
> Those IDevID do not
>    include owner and deployment specific information to allows autonomic
>    establishment of trust for the operations of an ACP domain
> NEW:
> A IDevID does not
>    include owner and deployment specific information that would allow
> autonomic
>    establishment of trust for the operations of an ACP domain
> END

Gone

> s6.1, para 4:  The  term 'its reference document is unclear.  I guess it
> means RFC 7575.
> OLD:
>    This document uses the term ACP in many places where its reference
>    document use the word autonomic.  This is done because those
>    reference document consider fully autonomic network and nodes, but
>    support of ACP does not require support for other components of
>    autonomic networks.  Therefore the word autonomic would be irritating
>    to operators interested in only the ACP:
> NEW:
>    This document uses the term ACP in many places where the Autonomic
> Networking reference
>    model  document [RFC7575] uses the word "autonomic".  This is done
> because those
>    reference model document considers fully autonomic network and nodes, but
>    support of ACP does not require support for other components of
>    autonomic networks.  Therefore the using just the word "autonomic" might
> be confusing
>    to operators interested in only the ACP:
> END

Done (also referring to reference-model draft beside 7575).

> s6.1.1, title: s/Field/Fields/?  Not sure if this is better?

Specifies single instance, so Field should be fine.

> s6.1.1: Turn RFC 1034 into a proper reference to shut up idnits.

Don't know how to do it inside a figure.
Changed to "RFC 1034" for the time being in hope to shut up idnits.
If you don't have an idea, then its a job for RFC editor.

> s6.1.2, bullets #2 and #4: s/peers/peer's/

Done

> s6.1.2, bullet #3:Expamd CDP, OCSP and CRL - not in RFC editor well-known
> list (and indeed CDP as used here is not in the list at all.)

Gone

> s6.1.3: Point to Section 2.8.11 of the GRASP draft for the flood message
> definition.

Done

> s6.1.3: Expand CDDL on first occurrence.

Done. Also added missing reference.

> s6.1.3, top of page 20: So high?  Surely 'sufficiently low'?
> OLD:
> It must be so
>    high that the aggregate amount of periodic M_FLOODs from all flooded
>    objectives causes only negligible traffic across the ACP.
> NEW:
> The frequency of sending MUST be such
>    that the aggregate amount of periodic M_FLOODs from all flooding
> sources  causes only negligible traffic across the ACP.
> END

Done

> s6.1.2, para 2: s/directly adjacent/diectly adjacent (i.e., not on a link
> connected to this node)/

Done

> s6.1.3: To make the introduction of BRSKI at the end of Section 6.3 more
> comprehensible, it would be useful to explain that the initial domain
> certificate can possibly be installed using BRSKI or some other mechanism
> rather than by out-of-band configuration as set out in the BRSKI draft. 
> Alternatively this could be part of s5, the overview.

There is now a lot more text about Registrars and BRSKI in -14,
so i do not want to add more in random places like this, but fixed
up the sentence, but fixed up sentence to read easier:

Note: If an ACP node also implements BRSKI to enroll its ACP domain certificate 
(see <xref target="bootstrap"/> for a summary), then the above considerations also apply to 
GRASP discovery for BRSKI

> s6.1.3, next to last para: s/primarily/primary/

Done

> s6.2, para 1: The term Node-ID should probably be in the terminology
> section.  Either that or it needs to be explained here

Done
Added definition to terminology and explanation her:
(identifier of the node inside the ACP, see <xref target="zone-scheme"/> and <xref target="Vlong"/>)

> s6.2, para 2: s/node-ID/Node-ID/

Done

> s6.3: It would be helpful to reinforce that this part of the operation (and
> the reason for the existence of DULL GRASP) is that it operates on an
> unsecured channel - otherwise the appearance of DULL is unexplained.  DULL
> should be expanded on first use.

Done

DULL GRASP is a limited subset of GRASP intended to operate across aninsecure link-local scope.  See section 2.5.2 of <xref target="I-D.ietf-anima-grasp"/> for its 
formal definition.  The ACP uses one instance of DULL GRASP for every L2 interface

> s6.3, para 1: The DULL section in the GRASP draft is now s2.5.2.

Gone (fixed be above).

> s6.3, para 1: Expand SLAAC on first use. Maybe refer to RFC 4862.

Done

> s6.3, para 2: Since RFC3810 is referenced. is MLDv2 REQUIRED (not sure if
> MLDv1 is still implemented ever)?

Done

...to use Multicast Listener Discovery Version 2 (MLDv2, see <xref target="RFC3810"/>) 

Funny how RFC editor recognizes IGMP as well-known in its abbreviations, but
MLD not.

Wrt. proto rev requirement, see my post on [e-mail] triggered by this nit.
Technically, MLDv1 would suffice in this case.

> s6.3, para 3: s/how to enable/on how to enable/

Done

> s6.5, paras 2-4:  Para 2 ends with a colon: It maybe that the original
> intention was to format the next two (?) paras as bullet points introduced
> by para 2.  If so then adjust the formatting of paras 3-4; otherwise change
> the colon to a period.

Done
Changed to period. Only following paragraph explains what the colon meant
to emphasize, so single bullet wouldn't look good... i think. 

> s6.5, para 3: Need a reference for MacSec and probably an expansion of the
> name - I presume this is referring to IEEE 802.1AE.

Done

> s6.5, paras 5-8: As above para 5 ends with a colon.  It seems that there are
> two rules to enumerate  after this - para 6 and paras 7-8.  If so arrange
> these paras as two bullet points.  Otherwise the wording of para 5 needs
> altering.

Done
Created list.

> s6.5, para 6: s/itmust be used/they must be used/

Done

> s6.6, "(with throttling)":  Some greater precision is needed here.

Done

Attempts to reconnect MUST be throttled. The RECOMMENDED default is exponential backoff with a a minimum delay of 10 seconds and a maximum delay of 640 seconds.

> s6.8.1, para 1:
> OLD:
>    They function in GRASP that makes it
>    fundamental as a service is the ability for ACP wide service
>    discovery (called objectives in GRASP).
> NEW:
>    The function in GRASP that makes it
>    fundamental as a service is the ability to provide ACP wide service
>    discovery (using objectives in GRASP).
> END

Done

> s6.8.1, para 2: s/described below/see Section 6.11/

Done

> s6.8.1, para 3: s/in the following section/in Section 6.8.2/

Done

> s6.8.1, para 4: s/original form/the original form/

Done

> s6.8.1, para 4: s/that has never been attempted to be solved/where no attempt at a solution has been described/

Done

> s6.8.1, para 5: s/Future ASA/A future ASA/, s/These ASA/Such an ASA/

Done (used "Some" instead of "A").

> s6.8.1, para 6: The concept 'constrained flooding' used here for M_DISCOVERY messages is not defined either in this document or the GRASP draft.  This needs to be explained more cearly.

Done

which are intelligently (constrained) flooded not across the whole ACP, but only up to a node where a responder is found

Btw: This is not anything new, just reciting what GRASP specifies.
GRASP may not have phrased a term like "constrained" for it though.

> s6.8.1, para 4: Expand PIM-SM.

Done

> s6.8.2, para 2: s/responsible to ensure/responsible for ensuring/

Done

> s6.8.2:
> >     [RFC Editor: please try to put the following picture on a single page
> >     and remove this note.  We cannot figure out how to do this with XML.
> >     The picture does fit on a single page.]
> Layout hints:
> You can get an extra 9 lines for the figure by
> - Moving the heading ACP: either to the left of the first line or put it as part of the title (which you haven't specified as yet) so it doesn't need a line to itself.
> - Removing 2 essentially blank lines (the second line and the line above ACP-loopback Intetf.
> - Forcing a page break after the paragaph above the figure
> - Removing the RFC Editor note.
> 
> Assuming you are using xml2rfc v2, insert the Processing Instruction PI
> <?rfc needLines="46" ?>
> above the figure text (assuming I have counted right).  I think it will then fit on one page.

Gave up after 45 minutes. needLines not working for me yet.
Posted question to [e-mail]

> s6.8.2.1, para 4: s/the semantic of the GRASP negotiation to an extend/the
> semantics of the GRASP negotiation to an extent/

Done

> s6.9, para 1: s/ACP channels/ACP channels'/

Done

> s6.9, para 2: s/systems/system's/

Done

> s6.10.1, last bullet: s/no not/do not/

Gone

> s6.10.2, bullet #3: Expand CSR.

Done

> s6.10.3, next to last para: s/allows to easily add/allows the easy addition
> of/, Expand SW.
> 
> s6.10.3, last para: s/allows to announce/allws the announcement of/

Done

> s6.10.4, next to last para: s/The Z field is following/The Z field follows/

Gone.

> s6.10.5, bullet #1: s/use via/that might be used/

Gone

> s6.10.5, bullet #2: s/allows to use/permits the use of/

Done

> s6.10.6, last para: s/should consider to be extensible in itself/should
> consider making provision for further extensions/

Done

> s6.11.1.1, para 1:s/reasonable fast/with reasonably fast/

Done

> s6.11.1.1: Expand DODAG, NOC, RPI, RPPL on first occurrence. ( or is it
> s/RPPL/RPL/?)

Done

> s6.11.1.4: Expand DAO on first occurrence.

Done

> s6.11.1.11, last para: s/is avoid/is to avoid/

Gone

> s6.11.1.12: Expand DIO.

Done

> s6.12.2, para 1: s/only specify/only specifies/

Rejected

The fully autonomic mechanisms in this document only specify

Its mechanisms, so it should be specify, not ?

> s6.12.3, para 2: s/to be prioritize/to prioritize/
> 
> Reviewer note: There are a rather smaller density of nits in s7 and s8 - I
> have run out of time to record them at this point.  If it is useful I can
> forward notes separately in a few days time.

Please do so, your thoroughness is greaT!

> s10, para 1: s/cope/scope/

Done

> s10.2: expand LLDP on first occurrence. May need a reference.

Done

> s10.3.2.2: Expand BFD on (only) occurrence.  May need a reference.

Done

> s10.4.1: Expand CDP on firat occurrence.

Done

> s10.4.2: Expand mDNS and DNS-SD on first occurrence.

Done

> s10.5:
> This Appendix explains why RPL
> > This Appendix explains why RPL...
> S10.5 is not an appendix (although aguably the whole of s10 should be an
> appendix.).

Done

We had long discussions about appendices and Michael Richardson made the
IMHO excellent observation that nobody reads appendices given the RFC
template thats pushing them all the way past all the text you wouldn't
read like references, author addresses and the like.

I would also claim that there are at leas three categories of information
in section 10 that i would differentiate:

10.2/10.3 discuss as mentioned in before the operator interface. I can
see how this can not be normative due to the absence of formal specification
to achieve exact consistency. Thats the work that would need to go into a
YANG model doc. But the operator interface is functionally a
MUST HAVE OR ELSE YOUR IMPLEMENTATION IS UNDEPLOYABLE, so that makes it
IMHO totally inappropriate for an appendix.

10.5 is similar but more controversal, so not clear to me if we would
get to some easy agreement on the config model proposed here.

The rest is either background or future considerations.

So... afer i commit -14, i will commit a -15 where i will split
10. into a "Operational considerations" followed
by a "Background and future considerations". I want to do this
separately, because moving around subsections will make diffs totally
useless. Then we can later have the discussion whether to move the
background and future considerations into appendices. But i definitely
do not want that for the operational considerations.

> s12, paras 5 and 6: These are duplicates. Remove one!

Done

> s15.2: I think some of these references are normative:
> especially  ietf-anima-reference-model, ietf-roll-useofrplinfo, RFC 6553,
> RFC 5234

Done except:

See discussion on mailing list etc. we religiously do not want the
reference model to be a normative reference, because it is really
meant to only be a secondary document giving an overview of the
ANI pieces (so the normative specs like BRSKI and GRASP are the normative
references) AND then it talks about what we think a full AN network is,
and that is totally incomplete and subject for further though. And
not at all a dependency of ACP.

Thank you so much!