Hi Ketan, The authors have reversed their position on FCFS and are now considering Expert Review. I have not seen any objection from the WG on this change in position.
The only question left is how much information needs to be documented for a DE to make a determination of whether a new registration can be accepted. As Michael says, there is known vagueness in some of the specifications for what lies between the LinkType and the IP header, and it might not be possible to capture all of that in this specification. Are we comfortable with that vagueness and giving the DE (which will likely be the authors themselves) the leeway to decide whether a registration should be accepted? 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]
