I think we should just say we disagree and leave it at that I'm for any help we can to implementors but ... Scott > On May 22, 2022, at 8:32 PM, Martin Thomson <mt@xxxxxxxxxxxxxx> wrote: > > On Fri, May 20, 2022, at 20:59, Scott Bradner wrote: >> the IETF has a long standing problem with implementors understating >> what RFCs are needed to be implemented when >> implementing a protocol (TCP is a good example - RFC 7414 was done to >> provide a roadmap) - anything that helps >> implementors know"what QUIC is" has to be a good idea > > Yes, I agree that this has been a problem. But I think that I disagree with your prognosis. > > I see the problem not as a discoverability issue. https://www.iana.org/assignments/quic/quic.xhtml#quic-transport exists and provides many of the same pointers you suggest we add here. > > The natural end state of using Updates on every extension is close what we have in the registry, with a filter on whether the specification ends up in an IETF RFC. This does the future implementer no favours beyond what they might learn by searching for "QUIC RFC". > > The true value in RFC 7414 (and RFC 5411 for SIP) is not the existence of a collection of pointers, but how those pointers are contextualized. These documents provide a map of the space. > > An undifferentiated collection of Updates is of little help to implementers, particularly if the value of those pointers is degraded by the inclusion of features that are largely discretionary, which is definitely the case here. > > I would prefer to reserve Updates for changes that are essential. Examples that spring to mind: the CRC change in SCTP in RFC 3309, the addition of QUIC to RFC 7983, or the transcript hash for TLS in RFC 7627 (and TCP has a bunch of these). So this is less about "cheap", but more about preserving this resource. > > -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
