Re: [Ext] Re: What can do IANA do and not do

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Tom,

> 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

<<attachment: smime.p7s>>


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux