Hi Michael,
Thanks much for your detailed review (again).
And sorry for the delayed response. See inline please.
> -----Original Message-----
> From: Anima <anima-boun...@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 [
> ] m...@sandelman.ca http://www.sandelman.ca/ | ruby on
> rails [
>
> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
