Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-autonomic-control-plane-16: (with DISCUSS and COMMENT)

[Eliot Lear <[e-mail]>]

Hi Ben,

With apologies to the WG for adding a late comment. 

On 02.08.18 02:30, Benjamin Kaduk wrote:
> In particular, in its current form, it's not clear to me why this document
> is targeting the standards-track -- there are lots of places where
> determinations of what works best or how to do some things is left for
> future work.  Are there lots of implementations or consumers clamoring for
> this stuff that it makes sense to go for PS as opposed to Experimental (so
> as to figure out what works and nail down a slimmer protocol for the
> standards track)?  I see in A.4 that the choice of RPL was motivated by
> experience with a pre-standard version of ACP; it would have been great to
> hear more about those deployments in an Implementation Status section (per
> RFC 7942) or the Shepherd writeup.

FWIW I do not think experimental is appropriate.  Experiments have
beginnings and endings, and exit conditions.  Nor for PS should an
implementation report be required (quite the opposite).  I think PS is
more appropriate.  This is a pretty big document, and it is
architectural in nature, and there are multiple building blocks in this
document.  How they fit together may change based on operational
experience, and to me that means that a future revised PS of this
document would be considerably firmer.  To require that everything be
spelled out for this PS would be a bit much.

On the other hand, there are no fewer than *44* uses of the word
"future" prior to the appendices.  Some of this is a certain writing
style for a general architecture, but at the end of the day
I was left wondering whether
https://tools.ietf.org/html/draft-thomson-use-it-or-lose-it-01 should be
taken to heart in this instance.  In particular, the following stands
out to me:

>   "rsub" is optional; its syntax is defined in this document,
>    but its semantics are for further study.  Understanding the benefits
>    of using rsub may depend on the results of future work on enhancing
>    routing for the ACP.

Why define rsub now if it has no semantic value?  Is that the garnish
that nobody eats?

I see three different things going on in this document:

  * Some real future proofing with extension mechanisms.
  * Some implicit and explicit forward references to work that is a bit
    behind this work.  I think the purpose of this text is to justify
    particular functionality as fulfilling some envisioned dependency.
  * Stuff like the above that doesn't seem well justified.

The big concern with all of this is when an extension is used on one
system and no by another, will there be interoperability problems? 
Especially as relates to ACP domain membership.  I don't have a good
feel for that in a few of these cases.

Eliot