Re: [Anima] some minor comments on draft-ietf-anima-grasp-distribution-09

Hi Michael,

Thanks much for your detailed review (again). 
And sorry for the delayed response. See inline please.

> -----Original Message-----
> From: Anima <anima-bounces@ietf.org> On Behalf Of Michael Richardson
> Sent: Monday, January 1, 2024 2:53 AM
> To: anima@ietf.org
> Subject: [Anima] some minor comments on
> draft-ietf-anima-grasp-distribution-09
> 
> 1. I have checked the xml into git, and I can send patches ("git send-email") or
> git tree or just the final file, as the authors wish.
> 
> 2. I don't know if moving the use cases to ... improves the document.
> 
> 3. queries:
> 
> section 5.2.1 says:
> > The IS module uses a syntax to index
> 
> while I think that the word syntax here is probably correct according to a
> dictionary, it's probably a much less familiar term to use here.

[Bing] I would suggest to simply avoid using an noun here. No need to articulate another word to replace "syntax".

> I'm concerned about step (2) _Storing Mode Mapping_, which suggests DHT,
> but doesn't require it.  I guess that this is an implementation detail which
> does not affect the protocol, but it more explanation of why it does not matter
> might be good.

[Bing] The original texts there actually intended to consider DHT as an example rather than recommendation. But I agree we need to articulate a bit more on why it does not matter, will change.

> I find step 5 far too hand wavey about how the block is transfered.
> At the very very least:
>    In this case, the IS module should support basic TCP-based
>    session protocols such as HTTP(s).
> 
> this seems like it needs BCP14 language: SHOULD How do we do HTTP, and if
> HTTPS is implied, then how do we do certificates for what are probably IP
> addresses.

[Bing] For how the bulk block is transferred, I think we can just refer the approach defined in Section 5.3 (Bulk Information Transfer), to close the dependency chain within GRASP itself.

> It seems like step 7 is really step 0, and the process ought to just loop?

[Bing] I think we can move step 7 to be a fork under step 4, which actually already mentioned step 7 in the texts. This might be more intuitive to read.

> Almost all of the SHOULDs are probably MUSTs.

[Bing] I have similar feeling for at least some of the SHOULDs. We'll check them one by one in the new version.

> section 5.3, it is inaccurate to describe network policy as being in YANG.
> YANG is not distributed, but serialized to JSON or XML or CBOR.
> I suggest:
> 
>   There are scenarios where this restriction is a problem. One case
>   is the distribution of network policy in lengthy YANG formats such as XML
>   or JSON.

[Bing] Yeah, that's an explicit mistake, thanks for picking it up.

> Also at:
>   A third case might be a supervisory system
>   downloading a software upgrade to a network node.
> 
> is a really good case, and mentioning SUIT Manifests would be a very good
> connection.
> They fit quite well into 2048 bytes.
> https://www.ietf.org/archive/id/draft-ietf-suit-manifest-24.html#name-b-exam
> ples

[Bing] Cool, will consider how SUIT could fit in.

Best regards,
Bing

> The security considerations seem wrong.
> What is the TLS hop by hop security?
> 
> --
> ]               Never tell me the odds!                 | ipv6 mesh
> networks [
> ]   Michael Richardson, Sandelman Software Works        |    IoT
> architect   [
> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on
> rails    [
> 
> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima