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
_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
