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 <[email protected]> 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. > >
