On 27-Jun-22 12:58, Michael Richardson wrote:

Brian E Carpenter <brian.e.carpen...@gmail.com> 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"...

Yes, and suggest to the AD that it should be "Hold for document update".
Barring anyone else speaking up, I'd be happy with that.


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 ...

No, the only constraint is that it's legal CBOR and a recipient can parse
the different cases.

Obsoleting an existing format is harder, but an implementation that
doesn't understand "EST-TLS" could simply ignore it, I suppose.

(Comment: We didn't design GRASP for constrained environments and
saving every possible bit on the wire. GRASP-lite, anyone?)

   Brian

_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Reply via email to