Subject: [Anima] draft-bernardos-anima-fog-monitoring-04

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Jul 2021 16:40:54 +1200

Hi,

One quick comment on the draft.

>       An example of discovery message using GRASP would be the following
>       (in this example, the fog monitoring controller is identified by
>       its IPv6 address: 2001:DB8:1111:2222:3333:4444:5555:6666):
> 
>       [M_DISCOVERY, 13948745, h'20010db8111122223333444455556666',
>       ["FOGDOMAIN", F_SYNCH_bits, 2, "operator1"]]

If I can make a suggestion, I think it is better to start with an informal descrition and a CDDL definition of the GRASP objective. The details of the message don't really help the reader understand. 

Also I am not sure it needs multiple GRASP objectives. I think Toerless has a very good idea in his service description mechanism (draft-eckert-anima-grasp-dnssd), with JSON-like dictionaries that are very flexible, easily extensible, and trivial to map into CBOR. I don't think that changes the model, it just gives a lot more flexibility for the future. I think it would also make mapping to and from YANG based mechanisms a lot easier.
 
Regards
   Brian Carpenter

---

From: Dangjuanna <[email-masked]>
Date: Tue, 27 Jul 2021 08:04:22 +0000

Hi,

I am also studying the GRASP objective definition recently.
I have one question: why does F_SYNCH_bits appear in the discovery process?

Best wishes,
Joanna

-----Original Message-----
From: Anima [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: 2021年7月27日 12:41
To: Anima WG <[email-masked]>
Subject: [Anima] draft-bernardos-anima-fog-monitoring-04

Hi,

 
Regards
   Brian Carpenter

_______________________________________________
Anima mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/anima

---

From: Brian Carpenter <[email-masked]>
Date: Tue, 27 Jul 2021 21:15:11 +1200

The flag bits are simply part of the objective option, so they are always
included in the discovery message (see
https://www.rfc-editor.org/rfc/rfc8990.html#name-format-of-objective-options).
It MAY also be present in the response. It could be used for a consistency
check or used actively in Dry Run mode. (We could possibly add new flags in
future.)

Regards,
    Brian Carpenter
    (via tiny screen & keyboard)

On Tue, 27 Jul 2021, 20:04 Dangjuanna, <[email-masked]> wrote:

> If I can make a suggestion, I think it is better to start with an informal
> descrition and a CDDL definition of the GRASP objective. The details of the
> message don't really help the reader understand.
>
> Also I am not sure it needs multiple GRASP objectives. I think Toerless
> has a very good idea in his service description mechanism
> (draft-eckert-anima-grasp-dnssd), with JSON-like dictionaries that are very
> flexible, easily extensible, and trivial to map into CBOR. I don't think
> that changes the model, it just gives a lot more flexibility for the
> future. I think it would also make mapping to and from YANG based
> mechanisms a lot easier.
>
> Regards
>    Brian Carpenter
>