Brian E Carpenter <[email protected]> wrote: > "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
Yeah, okay.
...
> 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].
Okay, I think that I can absolutely live with this.
> 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.)
I wonder if we could just write some errata on 8990 to explain what to do.
I'm really skittish about "very brief RFCs"...
Well, I think we should it down somewhere.
But, back to my second part:
> b) Why waste so many bytes when a small integer would do!
I can't see any reason why objective-value should be a string.
I don't think we are very constrained here, such that "DTLS" is that much
better than CBOR-smallint 2, but ...
--
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
