Hi Brian, There is ongoing work in the ANIMA design team about the extension of the discovery information for a registrar, to contain more information about specific features of the registrar. We currently identified: - the operational mode: registrar as responder (as in RFC 8995) or pledge as responder (as in BRSKI-PRM) - the enrollment protocol: EST as in RFC 8995) or CMP (as in BRSIK-AE) or future adaptations - the voucher format: CMS-signed JSON (as in RFC 8995) or JOSE-signed JSON (as in JWS-Voucher used in BRSKI-PRM
The discussion is to define TXT key value pairs for DNS-SD, and use this approach also for GRASP. Best regards Steffen > -----Original Message----- > From: Michael Richardson <[email protected]> > Sent: Monday, July 17, 2023 11:47 PM > To: Brian E Carpenter <[email protected]> > Cc: Fries, Steffen (T CST) <[email protected]>; [email protected] > Subject: Re: [Anima] New Version of draft-eckert-anima-grasp-dnssd > > > Brian E Carpenter <[email protected]> wrote: > > I can't answer that, but note that the AN_Proxy and AN_join_registrar > > GRASP objectives defined in RFC 8995 include an objective-value field. > > For AN_Proxy that field is "any" so is currently undefined and could be > > extended in any way we want. For AN_join_registrar it is defined as > > In hindsight, 8995 should have created an IANA registry for these. > > > I find that "(list of)" a bit unclear but again there is flexibility to > > extend the semantics as we want. In fact that "(list of)" is almost > > worth an errata, since I wouldn't know what to write in a program to > > implement it. > > :-) > > -- > Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
