Subject: [Anima] Comments on draft-carpenter-anima-gdn-protocol-01

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Wed, 18 Feb 2015 09:25:08 +0000

Authors, 

I finally went through this document in detail, and have some comments/questions. Overall, I think this document is going in the right direction, it's clearly written, nice to read. 

Now, whilst reviewing I saw Brian's message to the list that he's re-doing the draft right now. So I stop my review for now where I am. So far I got only to the end of section 2. When the new revision is out, I'll review the rest. 

There are a couple of pretty fundamental questions here, so probably worth having some exchange on those already. And we need to develop this in sync with the reference doc, which is next on my plate for a revision. Bear with me! :-) 

Michael

General: 
*** "configuration": The abstract is about how " to negotiate mutual configurations". I think autonomic processes don't negotiate configuration. Configuration is in my world the thing that admins (or NMS systems) fight with, transfer, input. I think in AN we should talk about negotiating parameters and settings. Those may be in conflict with configuration, btw, as outlined in the NMRG definitions draft. 

*** Which type of discovery are we talking about? There are many types of discovery. peer discovery, service discovery, topology discovery. Which one are we talking about here? I *thought* this draft is about peer based discovery, but it looks like you want it to be generic enough to cover all forms of discovery? I think this is an important point, which we should clarify. For example, is this going to overlap with mDNS type discovery in the end? 
In my mind (not saying that I'm right or wrong, just explaining a view point) I thought this GDNP is for peer discovery, and negotiation of parameters with a peer. To me, service discovery is a different beast. (again, not claiming I'm right, just dumping my brain here)

Intro: 
*** " Therefore, the discovery mechanism needs to be able to bootstrap
   itself without making any prior assumptions about network structure."
I find it a bit strange to say that a mechanism needs to bootstrap itself. Specifically, it does need a trust infrastructure which it cannot bootstrap itself.  I would say "a device needs to bootstrap itself". That bootstrap process includes discovery and negotiation. (as well as bootstrapping a trust infra). 

*** " The PKI may be managed by an operator or be autonomic." 
Suggest to add a reference ", for example as described in draft-pritikin...". 

2.1 Requirements for discovery
*** " In an autonomic network we must assume that when a device starts up it has no information about any peer devices." I would add, ", the network and its services, nor about its own role in this network". 

*** What is a "user session" in this context? Confused...  I think you want to bring in an example of a user connecting to the network? Maybe, start with "for example". A more concrete example would be better. Also, the example you bring could be answered with "use AAA" - the example needs to be clear why this may not be optimal. 
Maybe a better example would be that a device when booting doesn't know where the AAA service, is, and it could ask its peer for it? 
Or, to find the boundary of the network you need a local discovery mechanism. That is  I think a better example for local discovery. 

*** "   During initialisation, a device must be able to discover the appropriate trust anchor, i.e. the appropriate PKI authority."  Initialisation is a more complex process, I think we shouldn't try to project that larger problem entirely onto discovery. For example, in draft-pritikin, we suggest a process where the new device doesn't really discover ANYTHING apart from the link local peer device, and specifically NOT a trust anchor. 
So I disagree with "this is just a specific case of discovery". There is a bigger process required to make that a secure operation. (And you point to the boostrap draft). I think it's just a question of wording. 

2.2
*** " It follows that a requirement for the protocol is to be capable of being installed in
   any device that would otherwise need human intervention." I suggest s/being installed in/operate on/ because "install" to me implies a user action, which I don't think we want to imply. 

*** " the protocol must be capable of supporting a "dry run" of a changed configuration before actually installing the change."  I don't think THE PROTOCOL must be, the overall autonomic process must be. This is not a requirement on the protocol, and I think this requirement actually doesn't belong here. I suggest to take that entire paragraph out. 

*** " The protocol needs to be capable of detecting unexpected events" - Same comment. The protocol needs to understand failures of the protocol itself, such as timeouts. General failures are not the protocol's job. This doesn't mean that you couldn't use it for some validation, but the logic of general failure detection is OUTSIDE the protocol. So this paragraph should be changed to reflect that the protocol must detect failures in its own operation, but not general failures. 

*** " Another consideration is whether to be able" change to " Another consideration is whether it should be able"

2.3
*** First paragraph. I think what you want to say is that the protocol transport may have protocol dependencies, but the protocol payload should be protocol independent. 

*** "   The protocol must be able to access off-link counterparts, i.e., must not be restricted to link-local operation." That sounds a bit weird. What about "must be able to work with routable as well as link local addresses."  

*** " The negotiation process must be guaranteed to terminate..." - again, the PROCESS is outside scope for the protocol spec and requirements, I think. Since this is a re-curing thing, maybe we need to discuss this as a separate topic. To me, there are two pieces: The protocol, and the usage thereof. And we should keep those separate. I think some of this should probably move into the reference draft. 

*** " Policy constraints" paragraph: I don't see why this paragraph is here? 

*** Next paragraph, same comment. Some of this text could / should move to the reference doc, IMO.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 19 Feb 2015 08:49:30 +1300

Hi Michael,

Thanks for the review so far.
> *** "configuration": The abstract is about how " to negotiate mutual configurations". I think autonomic processes don't negotiate configuration. Configuration is in my world the thing that admins (…

Well, first, the discrepancy is about words, not substance. The way I look
at it is that AN is setting parameters that were traditionally set by
manual or NMS methods (including modern traditions like NETCONF). I hadn't
thought of the word "configuration" being strictly limited to manual or NMS
actions. Actually the definitions draft, in the Abstract, says "The fundamental
goal is self-management, including self-configuration,...". But later on
the text uses "configuration" when it clearly means traditional methods.

Certainly we can tidy this up.

> 
> *** Which type of discovery are we talking about? There are many types of discovery. peer discovery, service discovery, topology discovery. Which one are we talking about here? I *thought* this draft is about peer based discovery,

Yes, the goal is to discover the peer(s) for a given negotiation or
synchronization objective. In -02 we will significantly update the
description of objectives, which makes this much more clear (I think).

> but it looks like you want it to be generic enough to cover all forms of discovery? I think this is an important point, which we should clarify. For example, is this going to overlap with mDNS type discovery in the end? 

That isn't the goal, but if we make a generic design then of course it
might overlap.

> In my mind (not saying that I'm right or wrong, just explaining a view point) I thought this GDNP is for peer discovery, and negotiation of parameters with a peer. To me, service discovery is a dif…

Yes. But in the end, the boundary will be fuzzy and if we succeed at all,
it's the market that will decide.

> I find it a bit strange to say that a mechanism needs to bootstrap itself. Specifically, it does need a trust infrastructure which it cannot bootstrap itself.  I would say "a device needs to bootst…

Physically, it's each device of course.

> Suggest to add a reference ", for example as described in draft-pritikin...". 

Yes, we need to start inserting linkages between the various documents.

> *** " In an autonomic network we must assume that when a device starts up it has no information about any peer devices." I would add, ", the network and its services, nor about its own role in this…

That is certainly the intention - it's a factory-fresh device. But it does know
what roles it is capable of playing.

> Or, to find the boundary of the network you need a local discovery mechanism. That is  I think a better example for local discovery. 

I need to think about that a bit.

> So I disagree with "this is just a specific case of discovery". There is a bigger process required to make that a secure operation. (And you point to the boostrap draft). I think it's just a questi…

Actually I now think it's a special case. Once you have executed draft-pritikin,
you are a trusted member of the domain, and exchange authenticated traffic. That
makes everything easier. Before you are enrolled, all traffic is suspect.
This does need some rewording.

>    any device that would otherwise need human intervention." I suggest s/being installed in/operate on/ because "install" to me implies a user action, which I don't think we want to imply. 

Yes.

> *** " the protocol must be capable of supporting a "dry run" of a changed configuration before actually installing the change."  I don't think THE PROTOCOL must be, the overall autonomic process mu…

Sheng made a similar remark, and that led me to think that we are all correct.
The overall process must support this, and therefore the protocol must
allow it. In practice that means that it's a requirement on the design of
individual objectives. My conclusion is that we do need to discuss it,
but in a slightly different way.

> *** " The protocol needs to be capable of detecting unexpected events" - Same comment. The protocol needs to understand failures of the protocol itself, such as timeouts. General failures are not t…

Yes, it is the autonomic service agent that has to detect functional
failures. But (see previous message) I think the protocol does need
to detect timeouts and loops in its own operations.

> *** " Another consideration is whether to be able" change to " Another consideration is whether it should be able"

Ack

> *** First paragraph. I think what you want to say is that the protocol transport may have protocol dependencies, but the protocol payload should be protocol independent. 

Sure.

> *** "   The protocol must be able to access off-link counterparts, i.e., must not be restricted to link-local operation." That sounds a bit weird. What about "must be able to work with routable as…

Semi-consciously, the phrasing is to draw a contrast with HNCP, which is
very clear that it's on-link only.
> *** " The negotiation process must be guaranteed to terminate..." - again, the PROCESS is outside scope for the protocol spec and requirements, I think. Since this is a re-curing thing, maybe we ne…

Well, I do see this as the protocol detecting failures in its own operation,
to use your phrase.

> *** Next paragraph, same comment. Some of this text could / should move to the reference doc, IMO. 

It's a matter of taste perhaps. You could grab some of this for the
reference model, and if it fits nicely there we can remove it here.

Thanks very much,

    Brian