Hi, I would find the draft easier to understand if it used CDDL to define the proposed GRASP objectives, in the same way as RFC8992 [1].
It really isn't necessary to describe the protocol operations, which are not affected by the design of specific objectives. The diagrams in Fig. 1 and Fig. 2 seem correct, and perhaps we should have included similar diagrams in RFC 8990. New GRASP objectives need to be registered with IANA [2][3]. They really are not protocol extensions, so I think the draft should be named "GRASP Objectives for CATS Metrics Distribution." The formal IANA policy is Expert Review, which doesn't require a standards track RFC, so I don't think this absolutely needs to be an ANIMA document. But I have no objection to it being handled by ANIMA. [1] https://www.rfc-editor.org/rfc/rfc8992.html#name-autonomic-prefix-management [2] https://www.rfc-editor.org/rfc/rfc8990.html#section-5-12 [3] https://www.iana.org/assignments/grasp-parameters/grasp-parameters.xhtml#objective-names Regards/Ngā mihi Brian Carpenter On 06-Mar-26 04:32, Michael Richardson wrote:
Yao Kehan <[email protected]> wrote: KY> But I think it doesn39t necessarily depend on ACP. Can GRASP be KY> implemented decoupled from ACP? (Sorry that I have not closely followed KY> the progress of ANIMA.) GRASP depends upon the ACP for security. There has been interest to add an asymmetric authentication layer, and really we need this. There has also been interest in running it over CoAP, DTLS or TLS, but so far, no proposals. KY> It depends on implementation. In CATS metrics definition, there are KY> three metric KY> levels. https://datatracker.ietf.org/doc/draft-ietf-cats-metric-definition/ KY> The Level 0 (raw metrics) may contain many detailed compute and KY> service metrics, expressed in floating points, whose size can be KY> large. RFC9439 seems to do ALTO over HTTP with raw JSON. I'm not seeing YANG or CDDL explanations here. Please explain large. How many floats per forwading platform? 100? 1000? 1e6? KY> For simplification and routing-friendly(easy to converge, small KY> overhead), implementers can also choose Level 1 or Level 2 normalized KY> metrics, which can be represented in 1 to 10 usigned integer value, KY> whose size can be very small. It seems to me that if you have an ACP, you can easily fit your metrics into GRASP directly, as CBOR. I don't think that you need grasp-distribution, but maybe it helps if you find that you might repeat it. Generally, I think of grasp-distrbution as a way to move and cache larger artifacts (files) on a hop-by-hop basis. -- Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide _______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
