Subject: [Anima] review of draft-jiang-config-negotiation-ps-03

From: Rene Struik <[email-masked]>
Date: Wed, 17 Sep 2014 11:47:58 -0400

Dear colleagues:

Please find below my initial comments on 
draft-jiang-config-negotiation-ps-03.

1. Summary:
The draft discusses some historical context and areas where IP 
networking has moved towards more autonomic/autonomous operations and 
where gaps remain and proposes how to address some of these.

2. General comments:
a) The introduction provides a concrete thesis that the "non-goal" 
described in draft-irtf-nmrg-autonomic-network-definitions-03 is 
actually a real goal, since it describes the dependency on (i) many 
different staff requiring very detailed training and skills; (ii) 
coordination of [...] staff [being] difficult and often inefficient.
b) The potential to have a "dry run" option in an otherwise operational 
network seems useful, but sounds more like a logical flow separation 
issue, where the operational network and the "dry run" version run in 
"different colors". This could be realized if one could have more than 
one instantiation of a protocol running at the same time, with logical 
separation being provided by color coding messaging and configuration 
data. {BTW - to my knowledge, RoLL does not really provide this right 
now, even though it knows the concept (but I may be wrong here)}. What 
this all has to do with the negotiation protocol and model argued in the 
draft is unclear, though, except for color labeling of instantiations.
c) There should be some discussion on the impact of device-to-device 
negotiation protocols on the global state of the system. After all, the 
order in which local two-device negotiations take place may have an 
impact on more global state changes (e.g., if the configuration 
parameter dependencies form a cycle in a graph [synchronization of time 
parameters comes to mind, here]). This relates to the third bullet of 
"behavior model" (Section 4, p. 9).
d) Rather than having a negotiation protocol between two devices, one 
might as well use a synchronization protocol instead, where both devices 
synchronize information of mutual interest. If one device does not have 
current info, this automatically could result in pushing the lacking 
info onto the device.
e) The "negotiation" protocol should practice "separation of concerns" 
(e.g., provide core protocol functionality of a configuration scheme, 
where the data elements to be configured are orthogonal to the core 
scheme). The protocol should also be as independent of routing protocol 
dependent features, including addressing that may correlate with network 
topology (since contrary to the objective of being a reusable block 
without all these interdependencies that increase complexity).
f) The behavior model (Section 4) contains a huge set of bullet points, 
in which it is hard to discover a common design philosophy. Aren't the 
main objectives covered by the items #d and #e above?

3. Specific comments:

Section 1:
1) First sentence: replace "and networks have" by "as networks have".
2) p.2, second para: replace "currently require" by "require" (i.e., 
remove second occurrence of "currently").

Section 2:
3) Second sentence: replace "in both directions" by "in either direction".
4) I am not sure whether the *only* focus of routing is reachability. 
Wouldn't efficiency of reach and meeting all kind of QoS measures, such 
as timeliness, energy use, link stability, be part of the deal? {I am 
not a routing expert, but in sensor networks lots of other metrics have 
been considered for a long while.}
5) Fifth para, p. 4: with respect to security handshakes, doesn't a 
protocol such as TLS already provide the algorithm suite negotiation 
feature mentioned in the draft?
6) Some of the bidirectional configuration has been provided for years 
by industrial control specifications, such as w/HART, where the network 
manager pushes configuration data to a joining device, while the joining 
device pushes network-relevant statistics to the network manager. While 
this has been implemented using non-IETF protocols, this presents a use 
case. Just a thought:  it would be good to articulate whether DHCP can 
be used to provide bidirectional configuration between two devices, by 
instantiating it either way (if not possible: summarize why; if so: 
indicate shortcomings doing it this way).
7) Section 2.1, last sentence: do I have to (sadly) conclude there is 
absolutely no IETF protocol out there where negotiation has not been 
designed with strict dumb client- know-all server setting in mind? 
{sorry - I do not know all the zillions of RFCs by heart.}
8) Section 2.3: come of the traffic engineering may only be effective if 
one has a more global view of capacities of different links in the 
network (e.g., determining capacity via the Ford-Fulkerson algorithm). 
As case in point, with 6TiSCH, there is a more central "mothership" that 
assigns time slots for individual nodes to communicate, so as to manage 
time latencies and energy efficiency of communications. This is just to 
illustrate that, at least with some applications, one cannot assume that 
local negotiations lead to (close to) optimal network metrics. Here, one 
should probably also add some verbiage as to aggregated functionality 
that is relevant when one zooms out (e.g., lease more capacity on 
backbone if local network generates
lots of traffic).
9) Section 2.4: One example where local negotiation may have real 
economical angles is hand-off of cell phone traffic to a wifi pipe, 
where pricing info and micro-payments could potentially be negotiated 
locally, without any direct involvement (or control!) of a central entity.
10) Section 2.5, first bullet: replace "authentic identity for each 
device" by "authentic device info".
11) Section 2.5, first bullet: authentic device info may indeed be a 
public key or a certificate, but also, e.g., a device identifier, such 
as an EUI-64 address, provided this is bound to a public key and 
identifiers are not reused across devices.
12) Section 2.5, last para: I would argue that, e.g., local negotiation 
of some economical token that affords network access (micro-payment 
style) should also be considered. This is just to illustrate that one 
has to think broader than just considering the network as a monolithic 
structure and consider dynamically changing, heterogeneous network 
settings as well. As case in point, what if part of the internet 
backbone is connected to users via a street lamp post network: in that 
case one does not easily get end-to-end connectivity without considering 
mobile users, city infrastructure, and back-bone (all potentially owned 
and/or operated by different entities, without necessarily secret 
handshakes and hundreds of pages of contract fine-print in place 
beforehand).

Section 3:
13) The first para may not be typical for sensor-style networks, where 
some "mothership" functionality may trigger part of this (see also 
previous notes with sensor-style angle, such as #8 above).

Section 4:
14) First bullet item: Shouldn't the negotiation protocol also be 
independent of routing addressing schemes that may be topology-dependent 
as well?
15) First para (on p.9): It is entirely unclear what "restrictive 
security infrastructure" means. Please elaborate.
16) Second para (on p. 9): This para seems to imply that inter-domain 
trust can be handled in a more sloppy fashion than intra-domain trust. 
This seems to be highly dangerous thinking and would make it almost 
impossible to reason about security provisions over the lifetime of a 
device and/or network.
17) The second bullet item (p. 9) discusses uniform patterns at the 
wrong abstraction level. The point is to design the protocol practicing 
"separation of concerns" (e.g., provide
core protocol functionality of a configuration scheme, where the data 
elements to be configured are orthogonal to the core scheme). The 
precise encoding (TLV-style or otherwise) should not be important at 
this point.
18)  Third bullet item (p. 9): It is not a priori clear that a 
multi-party negotiation can always be easily realized as an ordered 
sequence of device-to-device protocol instantiations, since this 
iteration may not always converge.
19) Fourth bullet item (p. 9): it is not clear why one should stay away 
from instantiating a negotation protocol with a vector-based approach. 
In various use cases, such as sensor networks, minimizing the number of 
communication flows (e.g., to reduce energy consumption and to reduce 
time latency) is highly desirable, as is a desire to make configuration 
changes resemble an "atomic change".
20) Fifth bullet item (pp. 9-10): the delegation feature mentioned 
raises all kind of questions re denial of service attacks, message 
storms, and the-like. Moreover, it raises potential privacy concerns re 
"gossip" behavior.
21) Sixth bullet item (p. 10): Role and functions should not necessarily 
be preconfigured; rather, these should be assigned dynamically, during 
the lifecycle of the device (e.g., during manufacturing, during device 
or system integration, during operational use, etc.). Support for 
dynamic lifecycle management should be the guiding principle here.
22) Seventh bullet item (p. 10): Whether or not a "compromise" will be 
negotiated or not entirely depends on configuration-specific data 
elements. In many applications, "chatty" behavior may be undesirable 
(e.g., with constrained devices and networks).
23) Eight bullet item (last para, p. 10): This para prescribes too much 
detail. Besides, it seems to suggest a total order of to be negotiated 
data elements (witness "should be chosen between the suggested values 
from ...").
24) Ninth bullet item (first bullet on p. 11): replace "reached through" 
by "established through".
24) Tenth bullet item (2nd bullet on p. 11): It is not clear what the 
fallback condition should be should the negotiation fail to converge. If 
a multi-party negotiation would be realized as an ordered sequence of 
two-party negotiations, would this then imply that one also has to roll 
back those? This item seems to require lots more thought.
25) Twelfth bullet item (forelast bullet on p. 11): It is unclear why 
negotiation of policy-relevant information could not be realized using 
the negotiation protocol. Wasn't the whole point of having a generic 
negotiation protocol that one could use the core protocol, independent 
of which data elements one would wish to negotiate?
26) Thirteenth bullet item (last bullet of this section): Again, it is 
entirely unclear why management monitoring, alerts, and intervention 
should not be able to use the negotiation protocol.

Section 5:
27) Second para: there are lots of use case scenarios where one does not 
have strict separation of users devices and network devices. What about 
peer-to-peer networking, where data is pushed via one smart phone to the 
next? What about sensor network settings, where each device may be a 
router (as is the case with 6TiSCH devices)? Etc., etc.? I think the 
client-server
thinking that resulted in lots of rigidities (as also mentioned in 
Section 2.1) should not be advocated here again; instead, one should 
depart from this thinking!
28) Fourth para: as already mentioned (see remark #10 above), it is 
sufficient to have authentic device info.
29) Fifth para: the notion of having a network-wide database of public 
keys seems to point into the direction of having an online (or even 
inline) CA. It is certainly possible to only involve remote/centralized 
trust entities in an offline/sparse in time fashion.
30) Fifth para: This is the first time the draft refers to "carrier 
networks". Why refer only to those? I thought the scope of 
auto-/self-/etc. management and low-overhead/low-complexity management 
was broader this and applies accross the board. Please remove reference 
to carrier network or include many more example networks, so as to 
illustrate one tries to address a central management problem here.

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 18 Sep 2014 08:10:53 +1200

Thanks for this review too. This is a document that will,
I think, be very considerably revised or maybe completely
transformed in future, so for now I will just focus on one
point:

> 7) Section 2.1, last sentence: do I have to (sadly) conclude 
> there is absolutely no IETF protocol out there where negotiation 
> has not been designed with strict dumb client- know-all server 
> setting in mind? {sorry - I do not know all the zillions of RFCs by heart.}

Actually this question is why we included section 3 (existing
protocols) and I would be really interested to know what we
missed there. There are a few protocols that are more symmetrical
in their nature (RSVP, GIST, HNCP) but none of them seemed quite right.

    Brian

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 18 Sep 2014 01:35:33 +0000

Hi, Rene,

Thanks so much for your thorough review. We really appreciate and it is very helpful.

As Brian mentioned, we are planning to revise and short the content of config-negotiation-ps and integrate it as a motivation section into draft-author-anima-config-negotiation-protocol. All your comments would be take in account during this action in near future.

Best regards,

Sheng

>-----Original Message-----
>From: Anima [mailto:[email-masked]] On Behalf Of Brian E
>Carpenter
>Sent: Thursday, September 18, 2014 4:11 AM
>To: Rene Struik
>Cc: [email-masked]
>Subject: Re: [Anima] review of draft-jiang-config-negotiation-ps-03
>
>_______________________________________________
>Anima mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/anima