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

[Toerless Eckert]

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=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 +, 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
> 
> .
> 
> 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 

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

[Alissa Cooper]

Hi,

I was wondering if any response to Elwyn’s review besides Brian’s is 
forthcoming and if so when the authors or shepherd expect to send it.

Thanks,
Alissa

> On Apr 18, 2018, at 8:50 PM, Toerless Eckert <t...@cs.fau.de> wrote:
> 
> Sorry, trying to get through backlog. Took longer than expected...
> 
> On Thu, Apr 19, 2018 at 01:04:53AM +0100, Elwyn Davies wrote:
>> Hi.
>> It has been about 6 weeks since responses to the review were postponed till 
>> after IETF 101 any thoughts yet?
>> Regards,Elwyn
>> 
>> 
>> Sent from Samsung tablet.
>>  Original message From: Elwyn Davies <elw...@dial.pipex.com> 
>> Date: 02/03/2018  12:04  (GMT+00:00) To: Brian E Carpenter 
>> <brian.e.carpen...@gmail.com>, gen-art@ietf.org Cc: 
>> draft-ietf-anima-autonomic-control-plane....@ietf.org Subject: Re: [Gen-art] 
>> Gen-art LC Review of
>>   draft-ietf-anima-autonomic-control-plane-13 
>> Just taking up one point for the time being  
>> Even if the reference model is informational, I was relying on RFC 8067, s1, 
>> para 3:
>>Section 2 of [RFC3967] lists some conditions under which downrefs may
>>make sense.  In addition to those, it has become common for working
>>groups to produce foundational documents (which contain important
>>information such as terminology definitions and architectural design
>>and considerations) at Informational status, and those documents are
>>often needed as normative references in the Standards Track protocol
>>documents that follow. 
>> I would say that sombody implementing ACP really needs to have read and 
>> understood the reference model and so I would argue:1. That it needs to be 
>> normative,and2. The downref is sanctioned by the language in RFC 8067. 
>> I am on holiday for a week and others are fighting the draft deadline so 
>> perhaps we can postpone discussion of the other points until the draft panic 
>> has subsided.
>> Cheers,Elwyn
>> Sent from Samsung tablet.
> 
> -- 
> ---
> t...@cs.fau.de
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Elwyn Davies]

Just taking up one point for the time being  
Even if the reference model is informational, I was relying on RFC 8067, s1, 
para 3:
   Section 2 of [RFC3967] lists some conditions under which downrefs may
   make sense.  In addition to those, it has become common for working
   groups to produce foundational documents (which contain important
   information such as terminology definitions and architectural design
   and considerations) at Informational status, and those documents are
   often needed as normative references in the Standards Track protocol
   documents that follow. 
I would say that sombody implementing ACP really needs to have read and 
understood the reference model and so I would argue:1. That it needs to be 
normative,and2. The downref is sanctioned by the language in RFC 8067. 
I am on holiday for a week and others are fighting the draft deadline so 
perhaps we can postpone discussion of the other points until the draft panic 
has subsided.
Cheers,Elwyn
Sent from Samsung tablet.
 Original message From: Brian E Carpenter 
<brian.e.carpen...@gmail.com> Date: 01/03/2018  02:45  (GMT+01:00) To: Elwyn 
Davies <elw...@dial.pipex.com>, gen-art@ietf.org Cc: 
draft-ietf-anima-autonomic-control-plane@ietf.org Subject: Re: [Gen-art] 
Gen-art LC Review of
  draft-ietf-anima-autonomic-control-plane-13 
Replying as a protagonist -

First thanks for the really thorough review with many good points.

Now a few replies in-line:

On 28/02/2018 15:24, 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
> you need a stand-by generator, you need a stand-by
enrollment server).


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

Definitely not, it's an informational document.

Regards
    Brian

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Toerless Eckert]

Elwyn, Brian, *: Just quickly:

Thank a lot. there is this looming deadline called March 5th for other work,
so will only be able to get back and seriously work on your review afterwards.

Cheers
Toerless

On Thu, Mar 01, 2018 at 02:45:36PM +1300, Brian E Carpenter wrote:
> Replying as a protagonist -
> 
> First thanks for the really thorough review with many good points.
> 
> Now a few replies in-line:
> 
> On 28/02/2018 15:24, 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
> > 
> > .
> > 
> > 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).
> 
> An Intent mechanism is not required to build and operate the ACP, and if
> the draft gives that impression, it needs to be fixed.
> 
> > 
> > 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.
> 
> It's chartered as standards track and other drafts have a normative
> dependency on it. So changing the intended status would be very
> problematic. Of course it's a judgment call, but there's nothing
> dubious that it depends on - ULAs, IPSEC, RPL, VRF functionality,
> in fact all the normative references except GRASP and BRSKI are well
> established. (GRASP has a mutual normative reference to this document,
> and is already in the RFC Editor queue; BRSKI is not out of the
> WG yet, so is likely to become a MISSREF.)
> 
> Yes, I'd be happier if I had running code for the ACP, but as far as
> I know that isn't a requirement for Proposed Standard.
>  
> > 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.
> > 
> > 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,
> > 
> > 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.  
> 
> Yes, but those are IPv6-in-something channels, that being the nature of a VRF.
> So anything that runs over IPv6 is OK. (I'm not sure that this MUST NOT
> actually matters: once we know it's an IPv6 channel, do we care?)
> 
> > 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
> > 
> > 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?
> > 
> > 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?
> > 
> > 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) 
> 

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

[Brian E Carpenter]

Replying as a protagonist -

First thanks for the really thorough review with many good points.

Now a few replies in-line:

On 28/02/2018 15:24, 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
> 
> .
> 
> 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).

An Intent mechanism is not required to build and operate the ACP, and if
the draft gives that impression, it needs to be fixed.

> 
> 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.

It's chartered as standards track and other drafts have a normative
dependency on it. So changing the intended status would be very
problematic. Of course it's a judgment call, but there's nothing
dubious that it depends on - ULAs, IPSEC, RPL, VRF functionality,
in fact all the normative references except GRASP and BRSKI are well
established. (GRASP has a mutual normative reference to this document,
and is already in the RFC Editor queue; BRSKI is not out of the
WG yet, so is likely to become a MISSREF.)

Yes, I'd be happier if I had running code for the ACP, but as far as
I know that isn't a requirement for Proposed Standard.
 
> 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.
> 
> 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,
> 
> 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.  

Yes, but those are IPv6-in-something channels, that being the nature of a VRF.
So anything that runs over IPv6 is OK. (I'm not sure that this MUST NOT
actually matters: once we know it's an IPv6 channel, do we care?)

> 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
> 
> 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?
> 
> 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?
> 
> 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.
> 
> 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.
> 
> 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 

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

[Elwyn Davies]

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

.

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).

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.

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.

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,

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

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?

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?

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.

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.

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?

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

Nits/editorial comments:

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)/


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

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.


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.


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

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


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


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

s1, para 3: