(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 <[email protected]> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
