[Anima-signaling] On Charlie's comments on draft-ietf-anima-grasp-10

[Brian E Carpenter <[e-mail]>]

Here's a stream of consciousness about some of Charlie's comments -
mainly ones where I didn't just say "yes, he's right" and make the
suggested change. Some of them are matters of taste, of course.

   Brian

> D6. Some objectives may only be significant on the local link,...
> CEP: Can GRASP *require* on-link?

We have made that an API feature, and the issue is covered in
the "Constrained Instances" section.

> T1. It should be convenient for ASA designers to define...
> CEP: This means: understanding of GRASP depends on choice of operating system.	
>  --> is GRASP "off-limits" for implementation on kernel-only devices?

Not intentionally, phrasing adjusted accordingly.

> T2. The protocol should be easily extensible...
> CEP: This doesn't really say anything...

Well, it helped to determine the MESSAGE_TYPE mechanism.

> T9. The protocol needs to be fully secured...
> CEP: It seems this is NOT a requirement for GRASP.  It should be relocated	
> to the Security Considerations.

The requirement is that protocol exchanges are secure; the phrasing
was inaccurate. As a *requirement* it seems to belong here.

> It is expected that GRASP will access the ACP by using a	
> typical socket interface.	 	
> CEP: The last sentence doesn't really belong here.

It needs to be said; it was very unclear during earlier WG discussions.


> o Convergence of negotiation procedures
...
> CEP: Not clear why any such multi-step iterative negotiation would exist.

This is fairly basic in autonomics, when assigning resources from a limited
pool, with a tree structure of allocators.

> 3.5.3.  Transport Layer Usage
> ...MUST NOT be fragmented
> CEP: What about 802.15.4 with IPv6 addresses and objective parameters?

The RFC4944 adaptation layer provides a 1280 byte MTU. So I guess
that sets the limit.

Added to the section on Message Size:

<t>The maximum size of multicast messages (M_DISCOVERY and M_FLOOD) depends on the link
layer technology or link adaptation layer in use.</t>


> CEP: Previous IESG guidance has required MUST for exponential backoff.	
> (and exponent MUST be 2).  (I don't necessarily agree with this)

It might be the wrong semantic. If you are waiting for another node
to come up, a waiting time that tends to infinity is not what you
want at all. Something less than exponential may be perfectly fine.
So SHOULD seems appropriate (in all places where this issue comes up).

> o GRASP_DEF_TIMEOUT (60000 milliseconds)
> CEP: That's a long, long time...

True. That's somewhat intentional, since we have no idea what might
be appropriate for an arbitrary application of GRASP. During debugging,
I found it quite useful (enough time to notice that something was stuck,
and investigate a little before the timeout occurs).

> 3.7.  Session Identifier (Session ID)
> This is an up to 32-bit opaque value used to distinguish multiple

> [CEP deleted 'up to']

Actually, it *is* 'up to'. In CBOR, an integer <65536 is encoded
in 16 bits, and <256 in 8 bits.


OLD:
> The embedded Locator Option(s) (Section 3.9.5) point to diverted	 	   	
> destination target(s) in response to a Discovery message.

NEW from CEP:
> The embedded Locator Option(s) (Section 3.9.5) points to diverted
> destination target(s) in response to a Discovery message.

Both seem wrong. Let the RFC Editor decide :-)

> Since GRASP is intended to be deployed in a single administrative
> domain operating its own trust anchor and CA, there is no need for
> a trusted public third party.  In a network requiring "air gap"
> security, such a dependency would be unacceptable.

> CEP: More explanation is needed for this.

Actually I think less, much less, is needed in *this* document. Since
we are requiring an external security mechanism, this whole point
belongs there (the ACP draft). So my draft has shortened this text
considerably.

> The GRASP protocol is agnostic about the role of individual ASAs	
> CEP: the concept of "role" does not seem to be well-defined.
...
> CEP: Not clear what is the value of this text.

Yes, the WG has punted on roles and authorization - left for
a possible rechartering. So we have no definition beyond the
dictionary meaning. But the text is intended to guide implmenters
in the meantime.

(ends)