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

[Toerless Eckert <[e-mail]>]

On Fri, Aug 03, 2018 at 11:26:08AM +0200, Eliot Lear wrote:
> On the other hand, there are no fewer than *44* uses of the word
> "future" prior to the appendices.

Yepp. But you're too late, Alissa was already complaining about it,
so i am just trying to improve the situation for -17. Just
taking a break to answer to your email...

Actually, the consistent use of the word "future" is the most
helpful part of this problem, because it allows me to find all those
places easily. ;-)

> Some of this is a certain writing style for a general architecture,

Nah, don't say this, our charter explicitly disallows archtiecture
work, we pulled the permission to do the reference-model draft against
a lot of resistance.

All the "future" mentions where really derived from cutting ambitions
2? years ago to not try to boil the ocean but stick the normative part to
what we where able to work out from practical experience with implementation
or suficient confidence of experience, and highlight the rest as
futures.

I'll probably want to create a summary of "futures" at the end of the
doc, so we do not forget the bits we want to do, but didn't get around

But yets, will definitely want to clean up primarily the normative part
of the doc, not the informative parts so much.

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

Definitely. I think ACP does actually do that.
Which WG is this proposed to be adopted by (or IAB ?).

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

In japanese cuisine, all garnish is edible and delicious.

Yes, that text was the worst example offender in -16. There actually
is a great current use-case for rsub today that can be solved by
the ACP normative functions and existing router configuration,
which is what will be used as justification in -17:

  Using different rsub for separated ACP areas connected via non-ACP
  capable "core", because .e.gg: core routers don't support ACP (yet) - and
  when later on core nodes do support ACP, no change is necessary, just
  removal of the manual configs to interconnect those areas. 

> I see three different things going on in this document:
> 
>   * Some real future proofing with extension mechanisms.

Right. The example of that is the ability to not include an ACP
address in the certificate because ACP peers might have a different
way to derive their ACP address (which is a future as we have
not defined such a mechanism). For a node compliant with this ACP
doc, the acp-address MUST be present in the cert, but it must
also recognize a peer (during IKE/TLS authentication) as a valid
peer that does NOT have an acp-address in the certificate.

This was the second big issue not well described that i had to
figured out in the text from Alissas review.

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

Yeah, how do we call this class better: "Stuff that contributors to
the WG wanted to have ACP do, but that didn't make the cut to
be defined in this spec - for various reasons.

So i think i'll move breadcrumps for those points out of the normative part,
but i do not want to loose them.

>   * Stuff like the above that doesn't seem well justified.

    I hope the doc has none of that but only (as above example)

    * Useful intentions with bad writing.

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

Right now i feel quite confident that this is all ok, but i think
i will learn the real solution once i am through with Ekrs review.

Right now, domain membership is really meant to be just normal Internet PKI
certificte validation plus use of the same trust anchors plus
the check that the local acp-domain-name is the same as that of the peer.

But i think Eric has a bunch of issues with the way we wrote that.



> Eliot
> 
> 




> _______________________________________________
> Anima mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima


-- 
---
[e-mail]