Re: [Anima] some questions about GRASP objective-values and discovery

Hi,

The question of a registry for the value field of a GRASP objective never came up before the GRASP RFC was published, as far as I remember. What we actually have in the IANA Considerations is:

"To assist expert review of a new objective, the specification should include a precise description of the format of the new objective, with sufficient explanation of its semantics to allow independent implementations."

In other words, Specification Required. We simply didn't cover the case of updating that specification. I don't know if there are other comparable cases in the IETF universe, but common sense suggests that if the specification of an objective is updated, it should go through expert review again and the citation in the registry should be updated. (https://www.iana.org/assignments/grasp-parameters/grasp-parameters.xhtml#objective-names )

Personally I'd rather do that than create a sub-registry for each case, which would in any case have to cite the updated specification, so the sub-registry wouldn't serve any real purpose. Simply, the citation in the registry would change from [RFC8995] to [RFC8995], [RFC9xxx].

If that's the way we want to go, we may need a very brief RFC that updates the IANA considerations of RFC8990. (If GRASP is a roaring success in the market we might need something as complex as RFC3864, but I doubt it.)

Regards
     Brian Carpenter

On 25-Jun-22 11:44, Michael Richardson wrote:
> 
> (Heads up to Brian and Toerless, and maybe Carsten)
> 
> Based upon review feedback and discussion among the BRSKI design team
> (now on Tuesdays, btw), we have moved the bulk of the discovery mechanism
> from draft-ietf-anima-constrained-join-proxy to draft-ietf-anima-constrained-voucher.
> 
> First, this represents a somewhat significant re-organization.
> I think that Rob mentioned the document would be returned to the WG for
> a possible second WGLC.
> 
> Here are two diffs:
> pull request:  https://github.com/anima-wg/constrained-join-proxy/pull/30
> 
>     https://author-tools.ietf.org/diff?doc_1=draft-ietf-anima-constrained-join-proxy&url_2=https://raw.githubusercontent.com/anima-wg/constrained-join-proxy/discovery-fixes/draft-ietf-anima-constrained-join-proxy-11.txt
> 
> pull request:  https://github.com/anima-wg/constrained-voucher/pull/231
> 
>     https://author-tools.ietf.org/diff?doc_1=draft-ietf-anima-constrained-voucher&url_2=https://raw.githubusercontent.com/anima-wg/constrained-voucher/discovery-in-cv/constrained-voucher-17.txt
> 
> 
> Second, we tried to get all of the GRASP objectives sorted out right.
> To this end, we are introducing two new objective-values to the
> AN_join_registrar objective, and one to the AN_Proxy objective.
> 
> In RFC8995, AN_proxy was defined:
> 
>     objective = ["AN_Proxy", objective-flags, loop-count,
>                                            objective-value]
>     objective-value   =  any       ; none
> 
> The example showing:
>   [M_FLOOD, 12340815, h'fe800000000000000000000000000001', 180000,
>               [["AN_Proxy", 4, 1, ""],
>                [O_IPv6_LOCATOR,
>                 h'fe800000000000000000000000000001', IPPROTO_TCP, 4443]]]
> 
> Here we show the objective-value as being the empty string.
> Empty string costs 1 byte, and I think it could equally well be a CBOR NULL.
> In contrained-voucher, we will do stuff like this:
> 
>          [M_FLOOD, 12340851, h'fe800000000000000000000000000001', 180000,
>          [["AN_Proxy", 4, 1, ""],
>           [O_IPv6_LOCATOR,
>            h'fe800000000000000000000000000001', IPPROTO_TCP, 4443],
>           ["AN_Proxy", 4, 1, "DTLS"],
>           [O_IPv6_LOCATOR,
>            h'fe800000000000000000000000000001', IPPROTO_UDP, 5684]]
> 
> a) I kinda wish we had put "HTTPS" in instead of "".
> b) Why waste so many bytes when a small integer would do!
> 
> Oh... but then we need another registry.
> And then one for AN_join_registrar.    We already have a registry for
> objectives, but a new one for objective-values?  Seems like a lot if we do
> this in general.
> 
> So please advise on what to do here.
> It's not the place for RFC8990 to tell us what to do, but I kinda wish it had.
> 
> I think that BRSKI-PRM will need a new value too.
> Note that I thought about a XxY mesh of objective-values such that the
> Registry could say what kind of voucher-requests it supported, but I decided
> that we had already decided that Registrars' had to lump it, and that pledges
> should just try, and if they get a 406, then go on a different Registrar.
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
>             Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 
> 
> 
> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima