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

[Toerless Eckert <[e-mail]>]

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
> > 
> > <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).
> 
> 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 without an enrollment server after partition.  Am I right and does it matter?
> 
> Yes, that could happen, I think. We could perhaps have stand-by servers
> in every router, ready to leap into action after a partition (and be
> discoverable via GRASP), but if there is no server after partition, that
> part of the network is stuck. It's like emergency generators (in fact,
> I'd say that everywhere you need a stand-by generator, you need a stand-by
> enrollment server).
> 
> <snip>
>  
> > s15.2: I think some of these references are normative:
> > especially  ietf-anima-reference-model, 
> 
> Definitely not, it's an informational document.
> 
> Regards
>     Brian

-- 
---
[e-mail]