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 directly? >> KT> But then, the DE cannot make this determination if a reference is not >> KT> provided/available? In summary, please see if the DE 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]
