Hi Dino,
> On 23 Apr 2024, at 00:57, Dino Farinacci <[email protected]> wrote: > >> P.s. >> >> Just noticed that this document proposes an encoding which is not the same >> as the one in RFC 8060 but use the same type number. > > That is right, we chose a format consistent with the IGPs so RFC8060 has to > updated. I made this clear when the change was made. > > Since so much time passes since we are not being productive, the same > arguments resurface years later. And its getting harder and harder for people > to remember and keep context. > > So should I submit a change to RFC 8060 and call it RFC 8060bis? You can, but this will slow down the publication of this draft because of the dependency. 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. Option B. This document officially updates 8060, but this means that existing implementation of the 8060 encoding are not valid anymore. > >> This is not possible. The best solution would be to use a different type >> number. > > The implementations use the latest in the draft. > How many implementation of this draft are you aware of? Ciao L. >> On 22 Apr 2024, at 13:23, Luigi Iannone <[email protected]> wrote: >>> >>> Dino, >>> >>> You did put a reference to other protocols in the acknowledgement section. >>> This is not enough. >>> >>> You should put a sentence like: >>> >>> The encoding format is consistent with the encoding used in other routing >>> protocols, namely: OSPF [I-D.acee-ospf-geo-location], IS-IS >>> [I-D.shen-isis-geo-coordinates], and BGP [I-D.chen-idr-geo-coordinates] >>> protocols. > > I will add. Thanks for the text. > >>> This sentence should be placed at the end of section 5, where you describe >>> the encoding. > > Okay. See diff enclosed. > > Dino > > <draft-ietf-lisp-geo-03.diff.html> > > > > > >>> >>> Ciao >>> >>> L. >>> >>> >>> >>>> On 18 Apr 2024, at 17:19, Dino Farinacci <[email protected]> wrote: >>>> >>>> You have to judge that. We do have references that point to ISIS and OSPF. >>>> >>>> Dino >>>> >>>>> On Apr 18, 2024, at 8:14 AM, Luigi Iannone <[email protected]> wrote: >>>>> >>>>> >>>>> >>>>>> On 18 Apr 2024, at 16:19, Dino Farinacci <[email protected]> wrote: >>>>>> >>>>>> LISP geo-location decided to use the encoding format consistent and >>>>>> coordinated with the routing protocols. >>>>>> >>>>> >>>>> Is this clearly state in the document? >>>>> >>>>> L. >>>>> >>>>>> Dino >>>>>> >>>>>>> On Apr 17, 2024, at 11:59 PM, Padma Pillay-Esnault >>>>>>> <[email protected]> wrote: >>>>>>> >>>>>>> Hello Dino and Alberto >>>>>>> >>>>>>> The Yang Doctor review had comments on Yang -20 draft regarding the >>>>>>> geoloc. >>>>>>> For reference comment from Joe Clark >>>>>>> As to the two questions asked here, I can see some benefit of breaking >>>>>>> out the IANA parts of address-types into a module that they maintain. >>>>>>> But in its current form, I don't know that it makes sense to have them >>>>>>> maintain it. As for geoloc, I do see some overlap, but I am not a LISP >>>>>>> expert at all, so I cannot comment as to whether bringing that whole >>>>>>> module in makes sense or would even work with LISP implementations. >>>>>>> That is, it seems LISP lat and long are expressed in degrees° >>>>>>> minutes'seconds" whereas geoloc does this as a decimal64 from a >>>>>>> reference frame. I do feel that whatever direction is taken, text >>>>>>> explaining why geoloc is not used is useful. >>>>>>> >>>>>>> Per Med's comment on groupings - >>>>>>> https://mailarchive.ietf.org/arch/msg/lisp/lJ7jBJzjJNY2P4sQgCcLuSnnzds/ >>>>>>> >>>>>>> Consolidating these comments in a single thread here for resolution and >>>>>>> discussion on the list before the refresh, >>>>>>> >>>>>>> Thanks >>>>>>> Padma and Luigi >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>> >> > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
