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]> wrote: > > Mahesh Jethanandani <[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]> . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > > >
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
