Re: [lisp] Draft LISP Geo-Coordinate Use-Cases

My preference is to update RFC 8060.

Dino

> On Apr 23, 2024, at 12:24 PM, Joel Halpern <jmh@joelhalpern.com> wrote:
> 
> From where I sit, doing nothing should be a non-starter.  We have a published RFC.  We are allowed to change our mind.
> 
> But...
> 
> 1) We need to be explicit about making such a change.  Which involves updating the existing RFC.
> 
> 2) Any such change needs to explain why it is being changed. Just because a later implementation did it differently, without a standard, does not justify changing the standard.  If there is an actual benefit to the change we should step up, admit we are changing it, and explain why.
> 
> Yours,
> 
> Joel
> 
> On 4/23/2024 11:48 AM, Dino Farinacci wrote:
>>> As I said, the simplest solution is to use a different type value. This allows to still use the old encoding and does not obsoletes implementations that use it.
>> You will obsolete implementations if we do that. Which really means you make the spec irrelevant. So I say stay with the same code point.
>> 
>>> Option B. This document officially updates 8060, but this means that existing implementation of the 8060 encoding are not valid anymore.
>> Right. But so much time has passed between from when the lisp-geo spec was published I believe most implementations have done lisp-geo encoding vs RFC 8060. My lispers.net implementation does the lisp-geo encoding with the type defined in the draft which is the same as RFC 8060.
>> 
>>> How many implementation of this draft are you aware of?
>> I think cisco and lispers.net. But cisco has to confirm.
>> 
>> I think we should do Option C which is do nothing to RFC 8060 and put text in the lisp-geo spec which indicates its encoding takes precedent over RFC 8060 using the same code point and document all implementations have evolved to the lisp-geo spec.
>> 
>> Dino
>> 
>> 
>> _______________________________________________
>> lisp mailing list
>> lisp@ietf.org
>> https://www.ietf.org/mailman/listinfo/lisp