This document is almost ready. But the document raises several more general questions that should be looked at by the IETF/IESG/... The document collects errata for six RFCs (RFC4119, RFC5606, RFC5774, RFC6442, RFC7378, RFC8262), and updates these RFCs. All these errata are about the contents of a single element in XML described by XML Schema, and about examples of that element's use: The RFCs use the values "yes" and "no", while XML Schema only allows true, false, 1, and 0 (see https://www.w3.org/TR/xmlschema-2/#boolean).The 'retransmission-allowed' element, I have not checked that the actual details (all relevant RFCs, and in these, all relevant occurrences) are correct, sorry. I assume the two authors and three contributors have done that with stringent diligence. Yet another check may help. The first general question is why there was already an Erratum in 2008 (https://www.rfc-editor.org/errata/eid1535) but five more RFCs were published with the same errors after that. One would assume that the GEOPRIV community would be small enough to avoid such a thing. According to the draft, things were fixed in 8 out of 13 documents, but not in another five. Fixing might also have been helped by a better way of integrating errata into the published RFCs. Currently, there is https://www.rfc-editor.org/rfc/inline-errata/rfc4119.html, but it only has second-class status. The second general question is how to make it easier to check code examples against syntax restrictions (e.g. schemas, programming language syntax,...), ideally in an automated way. In XML2RFC, we have ways to label code with types. For the full examples in the RFCs (e.g. the ones in https://datatracker.ietf.org/doc/html/rfc4119#section-2.3), that should make automated checks easy. But it's probably not fine-grained enough for inline text such as "When the value of this element is 'no",...". The third general question is how to avoid such problems in general. They seem to be a manifestation of a general problem described in https://tess.oconnor.cx/2023/09/polyglots-and-interoperability. In that article, the problem is more multi-layered, but the essence here is the same: We have a type of documents described both by XML Schema and by specific text and examples in the RFCs. Both not making use of mechanisms such as XML Schema and not using examples in RFCs seem bad ideas. But at least adding a checkpoint for the authors/editors in the RFC publication process where they have to confirm that they checked all the examples against the relevant syntax or schema should be an improvement. The fourth general question is whether/how much publishing this document as an RFC will contribute to actually improving the situation. What I mean is that I e.g. have not found any errata for RFC8262. My expectation would have been that for all the RFCs involved, errata get submitted first, and then they get wrapped up in a document such as this. This would give the errata additional visibility; every little bit of additional visibility may help improve the situation. Specific issues: - XML Schema Datatypes (in particular https://www.w3.org/TR/xmlschema-2/#boolean) should by cited. Among else, this will help people go to the source to check things. - The title needs to be fixed. There are people who are okay with "Errata" as a singular, but there are others who cringe at this. What is more, the title not only uses "Errata" as a grammatical singular, it also uses it as a semantic plural ("Errata" standing for "collection of Errata") at the same time :-(. It's very easy to fix this: Just drop the initial "A". I also suggest adding a "the" before 'retransmission-allowed', because "XML Element" is countable and therefore in the singular needs an article. So the title should read "Comprehensive Errata for the 'retransmission-allowed' XML Element". - PIDF-LO should be expanded in the abstract and the introduction. - The last paragraph before 1.1 starts with "Other than submitting individual errata". I read this as "In addition to submitting individual errata". But that's currently not the case. I suggest also submitting errata for all affected documents, and in that case changing the text to "In addition to submitting...". If individual errata are not submitted, I suggest changing the text to "Rather than submitting ...". - Same paragraph, "to further reinforce". I think "reinforce" is the wrong word. "confirm" should do. It's very clear that it's an error once you know it; no reinforcement needed. - 1.2: I understand that this paragraph is necessary in theory. But I'd argue that the actual text snippets extracted are small enough to fall under fair use, so that this section could be dropped. - 2.2: "\retransmission-allowed>" appears twice, but is nowhere found in RFC 5606. Probably should be "". - Why do the last two replacements in section 2.2 suddenly use only very short extracts where all the changes up to here were done on full paragraphs? - Section 3: Why make a difference between 'true'/'false' and '0'/'1'? Because creating implementations can also produce '0'/'1', and so accepting implementations have to be able to interpret these values, " Implementations SHOULD use only values 'true' and 'false'." does not increase interoperability at all. Also, any deviation from what XML Schema says, such as this half-way restriction of the lexical space, is a bad idea given that some implementations may be built by using an XML Schema-derived parser.