Hi, all, I wouldn’t care if this doc used 114 - as long as it is very clear that 114 is for *ANY* 0-hop protocol, which means ANYONE else can also use it.
That means that it might be useful to treat that protocol a little like the experimental TCP codepoints as per RFC6994, i.e., to include a long (4-byte minimum) magic number and tolerate collisions. Joe > On Sep 20, 2019, at 9:03 PM, Erik Kline <[email protected]> wrote: > > There's also the matter of whether allocating 114 for this doc would > establish a precedent. > > On Fri, 20 Sep 2019 at 20:24, Brian E Carpenter <[email protected] > <mailto:[email protected]>> wrote: > On 21-Sep-19 14:11, Joe Touch wrote: > > FWIW, there are many registries with such “dead” entries. > > 114 is a bit special. By definition, all our normal traffic monitoring > techniques will *never* see protocol 114 unless by chance they are installed > on a layer 2 segment where it is in use. So even if no traces anywhere > include it for ten years, we still can't assert that it is out of use. It > seems harder to prove than most negatives :-). > > > RFC6335 talks about the issue in trying to recover such entries. > > > > In general, it recommends that even if they are recovered, at best they > > would be marked as “RESERVED” until other values have been assigned and the > > space requires reuse of those dead entries. > > > > So the net effect is: > > a) the list will never actually reflect what is deployed (as Bob notes > > below) > > b) garbage-collecting will at best mark some subset as dead > > c) but the available entries won’t be reused until we run out anyway > > > > Given the number of remaining entries, the task of garbage collection seems > > of little value. > > Until the day when it seems urgent... > > Brian > > > > > Joe > > > >> On Sep 20, 2019, at 1:31 PM, Bob Hinden <[email protected] > >> <mailto:[email protected]>> wrote: > >> > >> Andy, > >> > >>> On Sep 20, 2019, at 10:37 AM, Andrew G. Malis <[email protected] > >>> <mailto:[email protected]>> wrote: > >>> > >>> Behcet, > >>> > >>> That was a historical list. The current assignments are in > >>> https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml > >>> <https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml> > >>> . If you want to go garbage collecting, that's the place to start. > >> > >> It's difficult to tell which are no longer used. For example, I was > >> recently asked about the Reliable Data Protocol, it’s IANA assignment: > >> > >> 27 RDP Reliable Data Protocol [RFC908][Bob_Hinden] > >> > >> I assumed it was no longer used. Later by happenstance, I learned it is > >> specified by ETSI as mandatory to implement in eSIMs. I had no idea. > >> > >> Bob > >> > >> > >> _______ > >> internet-history mailing list > >> [email protected] > >> <mailto:[email protected]> > >> http://mailman.postel.org/mailman/listinfo/internet-history > >> <http://mailman.postel.org/mailman/listinfo/internet-history> > >> Contact [email protected] > >> <mailto:[email protected]> for assistance. > > > > _______ > > internet-history mailing list > > [email protected] > > <mailto:[email protected]> > > http://mailman.postel.org/mailman/listinfo/internet-history > > <http://mailman.postel.org/mailman/listinfo/internet-history> > > Contact [email protected] > > <mailto:[email protected]> for assistance. > > > > _______________________________________________ > Int-area mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/int-area > <https://www.ietf.org/mailman/listinfo/int-area>
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
