Hi Mahesh, RFC 8126 talks about writing up guidance for designated experts in new registries. There are a few sections that address this (particularly the first and third):
- Section 4.5 (third and fourth paragraphs, plus pointers to RFCs that include examples) - Section 5.2 (first three paragraphs) - Section 5.3 (paragraph beginning with "When a designated expert is used, the documentation should" and the bullet points that follow) 8126 says that document should include guidance for the experts. 8126bis is going to say that they must provide guidance for new experts, so if this could be laid out in a more useful way (for example, in a subsection dedicated to expert guidance sections), let me know. This might be something to take to IANABIS. I'm not sure what you mean by "Does IANA need all the details, or does it rely on the DE to give its expert opinion?" Is that a question about the level of detail in a document that requests registration, or about the level of detail in the document that creates the registry and provides guidance for the experts? In either case, what IANA needs and what the expert needs are separate. IANA itself only needs enough information to fill in the fields of the registry (or to fill in in the fields in a registration template, if the template contains more information than the registry does). What the expert might need in either situation isn't really a question we can answer. I'd have to refer you to RFC 8126 for new registry creation, or the registry RFC/experts for a new registration in an existing registry. thanks, Amanda On Mon Nov 24 03:20:51 2025, [email protected] wrote: > Hi IANA, > > I would like to know if IANA has any advice on how much guidance needs > to be in the document for a registration type that is marked Expert > Review. Does IANA need all the details, or does it rely on the DE to > give its expert opinion? > > Thanks. > > > On Nov 21, 2025, at 9:22 PM, Ketan Talaulikar <[email protected]> > > wrote: > > > > Hi Michael, > > > > I'll admit that I am now conflicted and don't know which of FCFS and > > Expert Review is suitable for this registry. But those are the 2 > > options on the table for the WG to consider. > > > > 1) FCFS - "handing lollipops" with some perfunctory (non-technical) > > checks done by IANA > > 2) Expert Review - Very specific DE guidance is required to be > > capture; IANA will direct the request to the DE(s) who will need to > > review and evaluate > > > > Mahesh, I don't know if anyone from the IANA team has been consulted > > and what their recommendations are. That may be helpful for the WG to > > consider. > > > > I'll wait for what comes out of the WG consensus in the document and > > will update my ballot based on that. > > > > Thanks, > > Ketan > > > > > > On Sat, Nov 22, 2025 at 2:52 AM Michael Richardson > > <[email protected] <mailto:mcr%[email protected]>> wrote: > >> > >> Mahesh Jethanandani <[email protected] > >> <mailto:[email protected]>> wrote: > >> > See below for the discussion on the second paragraph of > >> > Section 3.2.2. > >> > >> >> > 4) The DE guidance has the following text but I am not sure > >> >> > that I understand > >> >> > what this means. This needs a reference to some relevant > >> >> > specification that > >> >> > explains the encoding in question. > >> >> > > >> >> > "When the contents of the link type can contain an IPv4 or > >> >> > IPv6 header, then > >> >> > the octets between the beginning of the link type and the > >> >> > IP header needs to be > >> >> > clear." > >> >> > >> >> I *think* the idea is that, *if* you can encapsulate IPv4 or > >> >> IPv6 packet in that link type, the specification should > >> >> describe everything from the beginning of the packet to the > >> >> IP header", i.e. "don't leave anything out". > >> >> > >> >> I'm not sure what the purpose of that is. Michael? > >> > >> KT> IOW, it is asking for a specification of that link type's > >> KT> header/packet format. If so, would it be better to say that > >> KT> directly? > >> KT> But then, the DE cannot make this determination if a > >> KT> reference is not > >> KT> provided/available? In summary, please see if the DE > >> KT> guidance can be > >> KT> more precise. > >> > >> There is some back and forth by unicast that I won't repeat. > >> Please suggest better wording, but the DE is not going to fix the > >> specification! > >> > >> This point is raised because it is a place where specifications have > >> sometimes fallen short or been vague. No specification is required. > >> > >> For example, there are DLTs that describe USB captures. And we could > >> have > >> new variations. IP packets *could* be there via PPP over USB > >> Modem, ACM, > >> or Serial port. (That's three different USB profiles, I think) > >> There are also 2-3 different ways to do Ethernet over USB that could > >> contain IP. > >> But, the DE should *not* insist that the spec says how to find the > >> IP header; > >> as it would be tied up in all the ethernet formats, etc. > >> So the suggested text, "... if you can" would be far too strong > >> advice. > >> The spec could say, "here be ethernet", which would be enough. > >> > >> -- > >> Michael Richardson <[email protected] > >> <mailto:mcr%[email protected]>> . o O ( IPv6 IøT consulting ) > >> Sandelman Software Works Inc, Ottawa and Worldwide > >> > >> > >> > >> > > > Mahesh Jethanandani > [email protected] _______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
