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

[Joel Halpern <[e-mail]>]

 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lisp