Hi Michael, On Fri, Oct 1, 2021 at 11:58 AM Michael Richardson <[email protected]> wrote: > > Donald Eastlake <[email protected]> wrote: > > If it is reasonable for something to be retained as "a record for > > future reference" then, in my opinion, it follows that it is a > > plausible candidate for publication as an RFC, likely an Informational > > RFC, which is the category shown on the title page of this draft. > > The IESG has declined to publish use case documents and pushed back on a lot > of things. It's no longer 1992 :-) > But, as a record for decision making, I don't think that the document does a > good job.
True, there is some push back by the IESG against a separate use case RFC or the like being some sort of gating consideration for technical work. My impression is that much of the concern is about unnecessary work and delay, especially in cases where the problem/use-case is pretty well known. However, this particular document is not use case(s) and, whether or not it's preparation caused any delay in the approval of RFC 8926 (Geneve), that is all water under the bridge. > >> Major Issues: > >> > >> The document jumps right into comparing the three protocols. > > > Given that the purpose of the draft is to cover the comparison of the > > protocols and selection of one, what sort of material do you think > > should appear before the comparisons? > > Maybe (from memory): > 1) establish the basis of comparison > 2) the environment in which things are targeted > 3) a bit more about why each protocol is the way it is. > 4) why converge at all. Thanks, those seem like good ideas to start from for some additional material. > >> The deficiencies of each protocol are very briefly noted. > >> No diagrams or extracts of the relevant protocols are included to help > a > >> reader understand the deficiencies. > >> > >> Few readers are likely to have a deep understanding of all three, so > some > >> contrasting pictures would be helpful. > > > Some such diagrams could be added. > > Thank you. > > >> The two major issues with GENEVE (can be longer than 256 bytes, has a > hard to > >> parse in hardware TLV structure) are identified. But the document > seems to > >> conclude on GENEVE, without explaining why those major issues are not > issues, > >> or how they would be mitigated. > > > Jon Hudson responded to this point and something along the lines of > > his answer could be incorporated into the draft. > > I am not privy to such a thread. > That's why I'm an external reviewer. My apologies for not being clear. I was referring to this email to you on which the WG, rtg-dir and draft.all were cc'ed: https://mailarchive.ietf.org/arch/msg/nvo3/cxZphhmyqv0xDwXGvoSHsTD3Gz0/ Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA [email protected] > -- > Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
