Hi Dino, I went through the meeting meetings recordings and minutes of IETF 96/97/115 when you did present this document. No discussion about types value. Even on the mailing list there was nothing about the issue.
Until my first review of the document in December 2022, when it was recently adopted as WG document. My review: https://mailarchive.ietf.org/arch/msg/lisp/3YYoMIG_oDSs-4ZVZ9gkzy1eOoE/ States: > > > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | AFI = 16387 | Rsvd1 | Flags | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Type = 5 | Rsvd2 | Length | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > You cannot use type 5. The type has been allocated in RFC 8060 and the > associated format already defined there (see also IANA section). > How you can see I already pointed out the issue. Your reply: https://mailarchive.ietf.org/arch/msg/lisp/peZDtwerz_r5t9Q7tkJv-W5kf1k/ > > I agree with all your comments and will do a revision. > > Regarding Type 5, that type was previously allocated *for this draft*. > Sometimes it is hard to remember since so much time has passed. > > So we do not need a new type. > > Dino And my further reply: https://mailarchive.ietf.org/arch/msg/lisp/P21u34iuAUY8cncjFmW_NnLAIto/ > Hi Dino, > > > On 9 Dec 2022, at 22:20, Dino Farinacci <farina...@gmail.com> > > <mailto:<farina...@gmail.com>> wrote: > > > > I agree with all your comments and will do a revision. > > > > Regarding Type 5, that type was previously allocated *for this draft*. > > Sometimes it is hard to remember since so much time has passed. > > Indeed it has been quite some time…. > > If you look Section 4.3 of RFC 8060 you can see Type 5 LCAF Format that is > completely incompatible with the specs in this document. > > What about asking for type 15 and name it “extended Geo-coordinates”? > > Ciao > > L. > To which you further replied: https://mailarchive.ietf.org/arch/msg/lisp/L9WE04EZ0B5K8Weg1-1e2e_jzSk/ > > > > Hi Dino, > > > >> On 9 Dec 2022, at 22:20, Dino Farinacci <farina...@gmail.com> > >> <mailto:<farina...@gmail.com>> wrote: > >> > >> I agree with all your comments and will do a revision. > >> > >> Regarding Type 5, that type was previously allocated *for this draft*. > >> Sometimes it is hard to remember since so much time has passed. > > > > Indeed it has been quite some time…. > > > > If you look Section 4.3 of RFC 8060 you can see Type 5 LCAF Format that is > > completely incompatible with the specs in this document. > > We need to update RFC 8060 so the format in the geo draft matches and points > to this use-case draft. That is what we have done with the other LCAF types. > So we just need to be consistent. > > > What about asking for type 15 and name it “extended Geo-coordinates”? > > There is no point to have 2 code points for Geo-Coordinates. > > Want me to start on a 8060bis document? > > Dino > Followed by your mail: https://mailarchive.ietf.org/arch/msg/lisp/DuDuw3c2vi_Y_buNJBPsFuRHPlI/ > This update reflects Luigi's comments. > > The only outstanding issue I think we have is if RFC8060 should be updated (I > think it should) to reflect the packet format changes. > > Dino > I have no trace of any private exchange with you about this document. If you have it please share it with us. From my perspective the situation is the following: I did raise the type value issue and suggested a solution one year and a half ago. More recently I have tried to explain (in my email https://mailarchive.ietf.org/arch/msg/lisp/mLhu6ELFjBtoFJSzgDwndA5Xubw/) that even updating RFC8060, going through a 8060bis document (which we are chartered to do) will not solve the problem. We cannot keep the value 5 in the geo document and deliberately change or delete the geo value in 8060bis. We need to ask IANA for a value different from 5 and currently unassigned, and at the same time deprecate the encoding in RFC8060. Yes, this means as well fixing implementations that shouldn’t have used type 5 in the first place. Ciao L. > On 27 Apr 2024, at 09:23, Luigi Iannone <g...@gigix.net> wrote: > > Hi Dino, > >> On 27 Apr 2024, at 00:19, Dino Farinacci <farina...@gmail.com> wrote: >> >> I think this is what transpired. >> >> (1) we wrote lisp-geo with exact packet syntax as RFC 8060. >> (2) We received comments from Enke, Naiming, Chris Hopps, and Acee. >> (3) We changed the format to be consistent with OSPF, ISIS, and BGP (the >> lisp-geo Document Change section documents this and when). >> (4) I asked if we could change RFC 8060 and pretty sure Luigi said yes. > > I do not recall any of this. I remember agreeing on changing the format. I > admit I did not pay attention to the code point (most probably assuming that > it will be different). > > But I will check my email archive to see if there is anything related or that > may suggest otherwise I will share it on the mailing list. > > Ciao > > L. > > >> >> That’s my memory. >> >> Dino >> >>> On Apr 26, 2024, at 6:07 PM, Joel Halpern <j...@joelhalpern.com> wrote: >>> >>> It's up to Luigi and Padma, but my read is that if it was private it was >>> not a WG decision. >>> >>> Yours, >>> >>> Joel >>> >>> On 4/26/2024 6:05 PM, Dino Farinacci wrote: >>>>> Can you find an on-list email where such a conclusion was reached. That >>>>> would certainly explain your choice. >>>> I searched (before I sent the last email) and could not find anything. >>>> Likely it was private. >>>> >>>> Dino >
_______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
