Thanks Brian, inline On Wed, Apr 13, 2022 at 08:45:39AM +1200, Brian E Carpenter wrote: > If RFC8990 has a weakness, it is indeed that only the initial registration > of a GRASP objective requires a specification and expert review. Personally > I think this is a good thing, since it allows for flexible extensibility. > Since the designated expert is Michael Richardson, he might have an opinion.
Right. > I agree that if extra values of the objective are needed, they should > be specified, and making that an Updates: 8995 seems appropriate. I was wondering about that. So the logic is that the objective name is indeed IANA registered that points to rfc8995, and we amend that objective with new options. Could/should we be able to indicate in the IANA objective registry the new proxy RFC or is that only taken care of by the Update flag/tracking ? > But it must still be Updates: 8995 if it extends the details of the objective. > (Regrettably, the proposed "Extends:" tag is still only an I-D.) Right. Binary flag doesn't allow too many values ;-) > > For example, with GRASP, it would of course be easy to indicate: > > EST-COAPS-STATEFUL > > EST-COAPS-STATELESS > > > > This would require two separate GRASP objectives if a Registrar/Proxy > > supports both, > > but would be the most easy solution. > > Alternatively add options to the objective value. The value can be whatever > we want, > as long as we can say it in CBOR and make sure that the RFC8995 definition is > a proper subset. Let me expand on that in a separate answer > Brian > > > > > Similarily, i guess we could have equal variations of the names for other > > discovery > > mechanisms. > > > > Cheers > > Toerless > > > > _______________________________________________ > > Anima mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/anima > > -- --- [email protected] _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
