Hi Tom, this is even less readable than your usual replies. Can you do this again with standard reply quoting? Grüße, Carsten > On 2023-11-29, at 12:11, tom petch <daedulus@xxxxxxxxxxxxx> wrote: > > This is getting a bit messy so splitting my reply > > From: Amanda Baber > Sent: Monday, November 27, 2023 19:14 > > Hi Tom, > > Hi Amanda > > On XML, thank you for the reference to the XML registry. What I see is a change in approach which for me has generated unnecessary work. > > A typical I-D with a YANG module asks > This document registers one URI in the "ns" subregistry of the IETF > XML Registry [RFC3688]. > > > This document registers one YANG module in the YANG Module Names > registry [RFC6020]. > > and I believe that that is what used to happen, nothing more. > > The I started seeing complaints about the XML examples being invalid, that is that the XML reviewers seem to be poking around in the I-D, find some XML, apply standards to it (that I think are excessive for an example but might be fine if the XML had any bearing on the protocol), declare the I-D invalid and request changes, generating more work for I-D authors (who resisted). I now see fewer XML examples, more JSON examples which for me is a retrograde step but which might be a coincidence (I await a JSON directorate declaring the JSON invalid:-). > > This is now a known issue and so authors allow for it. > > I still wonder what justifies the XML directorate intervening as they have. When an author omitted the :ns: in the uri then yes, that is an error that needs correcting but requiring examples to conform to a standard that has no relevance for a YANG example, well I have made that point already. > > The underlying issue is what happens in future.. Will the XML directorate look at RFC7950 which has hundreds of invalid XML snippets and require them to be valid which could make a 217 page RFC one of 500pp? probably not but who knows. RFC7950 needs revising IMHO but I doubt it will ever happen. I see the XML directorate overreaching themselves with IANA the bearer of bad news - hence, irrationally, I see it as an IANA issue but now a known one which does not need more action (until something different comes along which generates unnecessary work). > > Tom Petch > > > Ah yes, my literature search missed RFC2860. > > > > My comment about the IANA website still stands. It would help me, and > > from my experience others, if the website pointed to RFC such as > > these. > > We'll find a place to add this. And if you have (or if anyone has) any further suggestions or change requests related to IANA's website or processes, please feel free to send them to iana@xxxxxxxx at any time. That address points to a ticketing system, but it's heavily monitored. We're in the very early stages of planning improvements to registry presentation and storage, and feedback would more than welcome. > > > I did remember that anyone in the world can ask for IANA registration, > > not just IETF/IRTf etc, but had forgotten the document about the ISE. > > The only limits on registry creation by RFCs that we're aware of are in RFC 8726, which does still allow ISE-stream documents to create sub-registries for registrations. > > > A further example that I omitted in my first post, is about XML. RFC > > with YANG modules are encouraged to include examples and that has been > > XML. Sometime after that started, I started seeing posts from IANA to > > WG lists asking an XML group to review the examples and the XML group > > always said that the examples were invalid and wanted changes. As > > far as YANG is concerned, the examples are perfectly valid > and pass > > validation by tools but authors started to incorporate those changes > > to placate IANA. > > > > What is IANA's justification for requiring this conformance to someone > > else's, not YANG's, rules? > > I'm not sure whether experts and IANA are being conflated here or whether "IANA" is being used as shorthand for the registration process. > > These requests are coming from IESG-designated experts, not IANA. IANA's role in this area is strictly administrative: we request the reviews, we pass communication concerning them back and forth (if the authors/applicants aren't already copied), we record the results in the Datatracker. Before the IESG telechat, we set the document's "IANA review state" to "IANA NOT OK" if any expert reviews are still outstanding or if an expert has refused to approve without changes, but the ADs can override that absence of expert approval. > > XML experts are asked to review YANG documents because their IANA Considerations sections request registrations at https://www.iana.org/assignments/xml-registry. > > In another message, you referred to the XML expert comments in "[IANA #1261213] expert review for draft-ietf-netconf-https-notif (ns)" on the NETCONF mailing list. The expert had complaints/concerns, but those were non-blocking. He did approve the XML registration without changes, so as far as IANA was concerned, that was the end of our involvement. Had the expert refused to approve the XML registration, that could've been appealed to the ADs. > > Is there information we can/should provide about the expert review process (maybe as boilerplate in an email) that we don't? > > Thanks, > > Amanda Baber > IANA Operations Manager
