--On Wednesday, June 14, 2023 10:48 +0200 Carsten Bormann <cabo@xxxxxxx> wrote: > Hi John, > > Thank you for your comments! > I'll address them in installments, let me start at the end > now. > >> On 2023-06-14, at 06:53, John C Klensin <john-ietf@xxxxxxx> >> wrote: > […] >> (3) Robert Sparks's Genart review [1] identifies several other >> places where the specification is ambiguous as to what is >> actually allowed. I disagree with him only in that I do not >> believe that list adds up to "Ready with Issues" but, instead, >> that his list identifies things that the community (and the >> IESG on its behalf) should insist on being clarified before >> the I-D is approved. For most or all of them, I believe that >> making decisions and getting them clearly expressed is more >> important than what the decisions actually are. […] > > Please see > Archived-At: > <https://mailarchive.ietf.org/arch/msg/last-call/ZTQH7yDmPme66 > lyN-LmNwJKqBZg> > > …and the interesting thread that started from Robert's > comments. > > So far, I have created > https://github.com/ietf-wg-sedate/draft-ietf-sedate-datetime-e > xtended/issues/46 from the thread, which I think is a good > point to discuss. I had reviewed at least most of the thread starting with Robert's comments before writing and have now reviewed the Github issue. First, I repeat my comment that being clear is more important than the actual decision, even if the decision is "leave it up to the Designated Expert". I do think that would be a bad idea in this case because I think DEs serve the specification and the community best when they are arbiters of consistency with the intent of the standard. When we get to matters of taste, tastes that might differ among experts, that seems to me to be inviting problems. So I think the text should, at worst, say "this is the rule" (choosing the narrower/ more conservative case) "but, with sufficient and clearly documented reasons, the DE may make an exception" I also note that discussion thread justifies some text on the basis of POSIX file names, but that is not mentioned in the document nor is there a citation. >> p.s. as a strictly editorial matter that would not be worth >> mentioning except insofar as it is a symptom that the authors >> and WG were not quite finished with this document before >> asking that an IETF Last Call be initiated, there are five BCP >> documents (six entries) listed as Normative References. Two >> of them are listed by BCP numbers, the others, including two >> that make up one BCP, are listed by RFC numbers. Is there >> any reason for that distinction other than to confuse the >> reader? > > The reason is (a) that we forgot one [2], but (b) mainly > didn't make this fully consistent because the referencegroup > support in today's RFCXML/xml2rfc is awful. I'd rather fix > BCP13 together with the RPC, and not at this stage. (I don't > think we want to fix BCP14 because we have agreed text in RFC > 8174 that does not use a BCP reference.) As long as there is a clear reason, not an accident, I'm ok. With RFC 8126/ BCP 26 fixed, it looks less accidental. > [2]: > https://github.com/ietf-wg-sedate/draft-ietf-sedate-datetime-e > xtended/pull/47 best, john -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
