Hi, Brian & authors of GRASP,

Thanks so much for your hard work on GRASP. With my WG chair hat on, I have done a thorough review. (Giving that my review went much slower than I thought. I did not complete it. This email only contains most of concepts and considerations, up to section 3.4 . I will send other mail for the rest part for the protocol details next week.) In general, I feel the current document is already in a good sharp. I have a few minor comments are below. Most of them are in requirement and overview sections.

Before into details, in general the current text still have room to improve regarding to clearly distinguish the target, role and responsibility of GRASP, ASAs and autonomic network as a whole.

Second paragraph of Section 1, the Autonomic Service Agent should be in the first character uppercase format and a reference of RFC7575 should be given. It is an important term to understand the context.

In the same paragraph, “There is no restriction on the type of parameters and resources concerned.” I am not sure the meaning of restriction here. I guess this sentence means any parameters and resources could be the negotiation objective. Am I right?

In the same paragraph, should the atomic unit of discovery should also be mentioned? Actually, it is not clear whether the discovery is device oriented or ASA oriented.

Third paragraph of Section 1, “Negotiation is … between the negotiating devices”.  Is it possible to negotiate between ASAs or instances in a same device?

Fourth paragraph of Section 1, I don’t understand the purpose of these text from “Although”. It seems the 3rd, 4th and 5th sentences are saying the negotiation or GRASP is not restricted to the topology in a very obscure way. If my read is right, please just say so. The last sentence looks like a widow for me, although the word “therefore” appeared. For me, bootstrap may be a special ASA, but it is no different mean to GRASP from other ASA, unless it raises some special requirements, which I did not see.

First paragraph of Section 2, is it multiple ASAs might manage a same technical objective? If yes, it should also be mentioned.

Second paragraph of Section 2.1, “In some cases, when a new application session starts up within a device, the device or ASA may again lack information about relevant peers. It might be necessary to set up resources on multiple other devices, coordinated and matched to each other so that there is no wasted resource.” I felt difficult to understand both sentence, till I assume the second sentence describes an example scenario for the first sentence. If my assumption is what the authors want to express, it will be better to integrate them into one sentence with word “for example”.

D3 in Section 2.1, “When an ASA starts up, it must require no information about any peers in order to discover them.” It is worth to clarify the another side: if there are existing information, ASA may use it.

D4 in Section 2.1, “so discovery needs to be repeated to find counterparts for each objective.” The word “repeat” may imply the linear time order. Maybe replaced by “separated”, “splitted”?

D5 in Section 2.1, “the discovered peers should be associated with the objective.” may be more clear.

The first paragraph of D7 in Section 2.1, it looks like a subset of D2, no pre-known network topology knowledge.

N1 in Section 2.2, “arbitrary subsets of participating nodes”, maybe a “selected” is needed.

N4 in Section 2.2, “the protocol should be able to carry the message formats used by existing configuration protocols (such as NETCONF/YANG) in cases where that is convenient.” I like this requirement. However, I doubt whether it is feasible, particularly, there are multiple protocols with different message formats. If we are not sure the feasibility, it is better to lower this requirement to “MAY”.

N5 in Section 2.2, “the protocol … must be capable of running in any device that would otherwise need human intervention.” This looks like too strong for me with the word “must” and “any”, unless we are talking about full autonomic network, which exclude any human intervention, although it may be our ultimate goal. The same with N6, the word “must” and “any” may be too strong. On another side, I am not fully understand the technical impact of this requirement for the protocol design. Is there any technical difficult to prevent the running on any devices, then we have to do some special design in the protocol?

N7 in Section 2.2, if a dependency chain become too long, it may slow down the decision too much. If so, the performance of the total AN may also be damaged. So, I guess a mechanism to avoid the long-chain of dependencies is also needed. However, whether it is matter for ASAs or GRASP, I am not sure. In paragraph 3, “think ahead” could actually have two meaning here: 1, dry run to see the impact of new parameter; 2, predict some situation which may be input for the parameters decision. If you want to express the second somewhere else, at least, “In other words” is not a suitable conjunction.

N8 in Section 2.2, more discussion on why leads to the design choice that we made later in this document.

T1 in Section 2.3, “it should be possible for ASAs to be implemented independently of each other as user space programs rather than as kernel code.” This looks an recommendation/consideration for GRASP implementation rather than a technical requirement for protocol design. I understand the meaning and importance of such information. But it looks for me it appear in a wrong category.

T5 in Section 2.3, “the prerequisite is discovering a peer’s locator by any method.” Does the scenarios without any discovery possible? Such as sending out a on link multicast sync request?

T6 in Section 2.3, I believe this is a requirement for ASA, even a recommendation for ASA implementation. It is NOT a requirement for GRASP protocol design.

“Negotiation” in Section 3.1, “a process by which two (or more) ASAs”. Does multiple-side negotiation support in this document? Or does it fulfill by multiple bilateral negotiation? According to section 3.2, it is the latter. It is slightly misleading here.

“State Synchronization” in Section 3.1, according to the term of discovery, “as sources of synchronization data”, the sync in this document seems fully require-response model. If so, it is worth of clarifying here.

“Objective” in Section 3.1, “a given objective will occur during discovery and negotiation, or during discovery and synchronization, but not in all three contexts.” The discovery is not bound to negotiation, or synchronization. A better description here may be “a given objective will not occur in negotiation and synchronization contexts simultaneously.

“Objective” in Section 3.1, third paragraph, “That node is generally expected to contain an ASA which may itself manage other nodes.” In my understanding, an ASA could only manage local nodes although it may influence other nodes by negotiating with the peer ASAs on them.

The second bullet point in Section 3.2, “It will provide services to ASAs via a suitable application programming interface”. My understand is the API are our of document scope and may defined in future document. If so, this should be explicitly mentioned.

The third bullet point in Section 3.2, I believe some statement should be added, “As a design choice, the protocol itself is not provided with build-in security functionality.”

“Organizing of synchronization or negotiation content” bullet point in Section 3.2. I believe this point should be rewritten as a recommendation for ASA. GRASP is a generic platform. Consequently, it is independent from content organizing.

“Self-aware network device” bullet point in Section 3.2, last sentence “A device has no pre-configuration for the particular network in which it is installed.” I am not sure the purpose of this sentence although it looks like a requirement. If so, it is too strong. I think a “may” should be added.

Section 3.3, more description may be added regarding to use GRASP to signal between two Autonomic networks/domains.

In section 3.3.3, “In other words an might perform discovery because it only wishes to receive synchronization data.” The word “In other words” should be replaced by “for example” since there are other possible scenarios for the sentence before it..

In section 3.3, “Discovery Procedures”, “the device MAY respond to the link-local multicast”. Why “MAY”? As an important behavior for successful discovery, I think it should be “SHOULD”. At the end of second paragraph, you should define the default behavior if a receiving device does not support the object and have no information of another ASA, like silent drop the process.

Here, the word “support” has two meanings, a) understand the objective, b) has the source regarding to the objective. This may need to be distinguished during the discovery.

One scenario missed: in multiple interfaces scenarios, a device may send out the discovery message on multiple interfaces, the discovery result MUST be associated with the interface receiving it.

In multiple interfaces scenarios, “it MUST relay the query by re-issuing a Discovery message as a link-local multicast on its other interfaces.” I do NOT think “MUST” is right here. It means an objective that does not support by any devices or only support by a few devices would certainly cause a signal storm. I suggest to soft this to “SHOULD” and make it changeable by intent.

Also, there should be a way for the initiator to indicate the discovery message should not be relayed, like in the scenarios that the initiator would only want to discovery counterpart in its neighbors.

Section 3.3.4.1, I am not sure whether the Rapid mode is only used on-link or not, in another word. The discovery message with a negotiation objective option should or should not be relayed. Either way, it should be clarified further.

Last paragraph, Section 3.3.5.1, “In practice this means that they MUST NOT be transmitted and MUST be ignored on receipt unless there is an operational ACP.” I guess here should add “or other strong security mechanisms.”

The same paragraph, “synchronization objectives that are flooded SHOULD NOT contain unencrypted sensitive information.” There is not definition of “sensitive information”. Therefore, the meaning of this sentence is questionably.

The second paragraph of section 3.3.5.2, “This rapid synchronization function SHOULD be configured off by default.” Why off by default? More explanation are needed for this design choice.

Best regards,

Sheng