Hi Tom, Thanks for these notes on the website, which I agree can be pretty opaque in this regard, especially if you've followed an external link to a registry rather than starting from, say, https://www.iana.org/protocols (which is itself in line for review, and points only to 8126). I've passed this on. Again, we're in the early stages of development, so suggestions (or questions concerning any IANA-related topic) are very welcome: iana@xxxxxxxx. Best regards, Amanda On 11/29/23, 4:11 AM, "ietf on behalf of tom petch" <ietf-bounces@xxxxxxxx on behalf of daedulus@xxxxxxxxxxxxx> wrote: From: ietf <ietf-bounces@xxxxxxxx> on behalf of tom petch <daedulus@xxxxxxxxxxxxx> Sent: 29 November 2023 11:11 This is getting a bit messy so splitting my reply - this on the website From: Amanda Baber Sent: Monday, November 27, 2023 19:14 Hi Tom, Hi Amanda > 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. <tp> Nowadays someone wanting information about an organisation will likely look for a website and start from there. For this, I find the IANA website wanting. RFC Editor, IESG, IETF do better. Knowing something of what IANA does, being familiar with RFC8126, I can find what I want but when a question such as what the ISE can do via IANA comes up, the website is no use and this has surfaced more than once and at least one user thinks they should have been able to find something about it, IESG statement, RFC etc. I agree. I spent hours looking and came up empty-handed. You can of course say that the user should go to the ISE website instead and fnd RFC8726 there but I think that wrong. The web is - well, the web with hyperlinks giving ready access to related material so the use does not have to go back to a search engine and search the next ten pages to see if anything helps. The IANA website should be a starting point, linking users to relevant information, be that MoU, RFC, IESG statement and so on. This is completely different to the current landing page and that creates a logistic problem. The IETF had a similar problem that it changed its web page from being helpful to those with work to do to being helpful to the uniformed browser. I often cannot find what I want on the current website so this can be a challenge but I think that the needs of the ignorant user should be addressed and the current landing page of the IETF does that. In the same vein, a post to a WG list flagged the fact that a registry entry had the wrong codepage. Well I know to look for ...action buried, invisible, in the small print at the foot of the page but the current convention is to put CONTACT US at the top beside a SEARCH. Again, it is the ignorant user whose needs need addressing. Tom Petch > 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
<<attachment: smime.p7s>>
