Carsten’s comments make sense to me. Reference are more complicated when you start looking close. IEEE 754 floats is another example. Definitely don’t want to restate it, definitely don’t want to reinvent it. I think there are cases where something is referenced that can’t be implemented for free due to IP and copyright. We (must) live and interplay with a commercial world, so this happens. I think I’d like to see a better review of references in the document shepherd write up and/or better BCP for references in general (my document got caught up in a MISSREF delay of about 6 months that could have been avoided with a little foresight). LL > On May 12, 2024, at 12:18 PM, Carsten Bormann <cabo@xxxxxxx> wrote: > > On 12. May 2024, at 20:22, John Levine <johnl@xxxxxxxxx> wrote: >> >> RFC 9043: ISO/IECC 9899:2018, costs CHF 216 > > (This is an example where we could be a bit better in doing our homework [1].) > > But generally: +1 > > Whether a normative reference needs to be accessible also depends a lot on the context of its use. > > When somebody implements the unit “second” in SenML (RFC 8428), they are almost certainly not also implementing the realization of the SI second (atomic clocks etc., Zeeman frequency shifts anyone?). > But a normative reference may still be required to *identify* the authoritative document. > > In other cases, the implementer is really concerned with the details in the referenced document, beyond the matter of identification. > (This is, for instance, true in [2], which references [1] for this purpose.) > Of course, the technical content of the authoritative reference could have been restated instead. > This is bad for an implementer, who might have to distinguish genuinely new requirements from bad restatements. This is bad for the authors and reviewers, who waste time (and then introduce mistakes anyway). > This is also sometimes nearly impossible — try to restate Table 4 in Section 7.6.2.5 of IEEE1588-2019 without creating a copyright issue, as would be needed in [3] (we did restate most of Table 5 for [4]). > (See [3] for a more general treatment of restatements.) > > I’m mainly saying all this to underscore my point: Every case is different; there are no useful red lines. > That doesn’t mean there can't be good guidance, but in the end there needs to be reasonable judgement for any specific case. > (And, yes, we need guidance in place that gives us bargaining chips for our peer SDOs.) > > (I also believe the crude binary system of normative and informative references is deeply broken and needs more nuance, e.g., to identify historical references separately from up-to-date informative references.) > > Grüße, Carsten > > > [1]: https://www.ietf.org/archive/id/draft-ietf-cbor-cddl-more-control-04.html#C > [2]: https://www.ietf.org/archive/id/draft-ietf-cbor-cddl-more-control-04.html#name-printf-style-formatting > [3]: https://www.ietf.org/archive/id/draft-bormann-restatement-01.html > [4]: https://www.ietf.org/archive/id/draft-ietf-cbor-time-tag-12.html#section-3.5.1 > [5]: https://www.ietf.org/archive/id/draft-ietf-cbor-time-tag-12.html#section-3.5.2 > > -- > last-call mailing list -- last-call@xxxxxxxx > To unsubscribe send an email to last-call-leave@xxxxxxxx -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
