On 21-Sep-19 17:45, Joe Touch wrote:
> 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.
Or add a protocol number following this ambiguous protocol number.
(See what I did there?)
Brian
>
> Joe
>
>> On Sep 20, 2019, at 9:03 PM, Erik Kline <[email protected]
>> <mailto:[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 .
>> 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
>> >> 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
>> > 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
>>
>
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
