On Wed, Aug 24, 2022 at 6:19 PM Paul Hoffman <paul.hoff...@icann.org> wrote:
> On Aug 24, 2022, at 5:14 PM, Brian Dickson <brian.peter.dick...@gmail.com> > wrote: > > "at this stage" is only the case due to the draft not being explicit in > the flow. > > Are you saying that it was explicit after WG Last Call but changed? Or > during IETF Last Call and was changed? > No, I'm saying that, as far as I can tell, the flow was never explicit, and that's a big part of the problem. And I'm saying that if it had been explicit, the concerns would have been raised at that time, rather than now. (This is, IMNSHO, the poster child for why being as clear as possible for actual logic flows is really important, both to implementers, and to those involved in the process of reviewing documents and advancing standards.) I.e. I definitely apologise that this was not caught earlier. I also don't think it would have been possible to catch prior to doing interoperability tests and discussing with developers, which is exactly what the process was that lead to the request to the chairs and AD. > > > Yes, this is a non-editorial change. > > Also called a technical change. > Or a technical correction of a defect. It's a change, but not an arbitrary change. > > > If it were limited to an editorial change, it could be handled with an > Errata or via a -bis document. > > Technical changes require going back at least to IETF Last Call, if not WG > consideration again. Bis documents are for making technical changes. > .... once the RFC is published. And yes, while this will require those things, those are good things. Clarification and scrutiny are the responsibility of the WG and the IETF. This is an exceptional case, given that the issues are central to interoperability and deployability (usability by zone administrators). It is an unavoidable risk that developers take in attempting to track an in-progress draft prior to publication as a standards-draft RFC. Any change made up until the RFC is published, is something developers that want to be RFC-compliant need to do. Yes, doing development while the standard isn't complete gets software deployed sooner. The standard necessarily dictates the implementation, not vice versa. The copyright assignment stuff when bringing things to the IETF basically says that once adopted by the WG, it's a WG doc, not the original author's. I believe that, for the most part, the needed changes are code deletions or branching logic pruning, and as a result, de minimis. I also believe that the resulting client performance will be faster, more reliable, and less risky. In particular, the speculative DNS queries made in parallel can benefit from early abandonment. If a client receives an AliasMode response, outstanding queries for A/AAAA are no longer needed. This permits a client to proceed faster than if the client waited until it received responses, or worse waited until those queries timed out. Brian
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
