Hi Michael, See inline.
> On Dec 4, 2025, at 6:21 PM, Michael Richardson <[email protected]> wrote: > > > Mahesh Jethanandani <[email protected]> wrote: >> Thanks for posting an update. You beat me to the update. I was hoping >> for the discussion to settle down and see an updated version that >> captured all the discussion. Well … > > Okay. I wish you'd said this earlier :-) > please see: > https://github.com/IETF-OPSAWG-WG/draft-ietf-opsawg-pcap/pull/195/files > I can post -17 if this satisfies you. I did take a quick look at the diffs. Thank you for sharing. What did we decide for grandfathered entries that do not have a reference? Did we not decide to refer to the document itself? E.g., LinkType Value 4, 5, etc. > >> Besides these editorial changes, I am hoping for a resolution on the >> following points. > >> 1. Consistency > >> - The description of the LinkType Registry talks about 4 items per entry. >> They are: >> - LinkType Name >> - LinkType Value >> - Description >> - Reference > >> The initial version of the table in Section 2.2.1 shows: > >> - Name >> - Number >> - Description >> - Reference > > okay, I've renamed the initgial version file "stanzas" > (note it's presented this way because a table did not fit, and IANA suggested > thisA) > We changed the order of the table from Name/Value -> Value/Name. > I have not changed the order in initial value stanzas, as there are many of > them, and > we've departed from the .csv file and scripts at this point... Is the order now Value/Name? Hmm. Maybe then I do not understand how the linktypes.xml file is rendered, and the order is what you say it is. I can wait for you to publish the version. > >> Can these be made consistent? > >> 2. I would have deferred the definition of Change Controller to Section >> 2.3 of RFC8126. As is, the definition is incomplete. > > So you want me to say: > * Change Controller: as per {{RFC8126, Section 2.3}} Yes, thank you. > >> 3. In reading Section 2.3 of RFC8126, there seems to be some >> flexibility on who is the Change Controller for entries that are being >> grandfathered vs new entries. I see that the document now calls out >> [email protected] for entries that are grandfathered. Thanks for >> adding that. > > okay. > >> 4. Guy had suggestion for registration that do not have a reference. In >> particular, if there is no document, can the email address for the >> person who requested the LinkType be added? > > That's the intention for all new entries. > >> I believe that is captured >> in Section 2.2.2 of the document which is somewhat misplaced as the >> Section Title is “Guidance for Designated Experts”, says "The minimal >> requirement is to provide a contact person for that link type.” I think >> what was intended was “contact information for a person”, not just >> “contact person”, or better still “email address of the person”. > > I have changed it to say: > The minimal requirement is to provide a contact for that link type. > > 1. email addresses for the person can go stale. > In fact, the person who registered the 23 JUNIPER ones (over a period of > time), no longer works at Juniper. {A person who does has initiated an > internal query} > So while we have some additional information for some legacy allocations > recorded in emails and in the libpcap/pcap.c file, I would be hesistant to > put that into an RFC. > > 2. If we got a request from, say, the NSA, we would say yes. We might not > be able to list more than "NSA, Fort Mead, Drone to Aircraft Division" > (To make something up. Likely, it would be some contractor asking...) > > 3. Like, phone numbers are not yet obsolete :-) How about “contact information for a person, which should include the name as the minimum, and any additional information such as email address, phone number.”? Thanks. > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | IoT architect [ > ] [email protected] http://www.sandelman.ca/ | ruby on rails > [ > > > > > -- > Michael Richardson <[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]
