Hi Alberto, Thank you for sharing this update and plan vs 8060bis.
Fully agree that the YANG model will have to follow what will be in the base draft-ietf-lisp-geo spec. This is why I’m insisting we clarify the positioning vs RFC 9179 in the base spec. Otherwise, Alberto will have to justify in his spec why the spec does not reuse existing standards structure and not adhering to RFC8407, e.g., If an appropriate derived type exists in any standard module, such as [RFC6991], then it SHOULD be used instead of defining a new derived type. The discussion I’m expecting to be included in draft-ietf-lisp-geo does not need to use any YANG-specific but reason about configurable parameters. Dino, I would be more than happy to propose text but I can’t here because this is an analysis/conclusion that the WG needs to do. Having text such as: “This specification deviates from the structure defined in [RFC9179] to configure the because xxxx” OR “The mapping of the Geo-Location parameters defined in Figure 1 and those defined in [RFC9179] is as follows: * lisp para1 corresponds to xxx in RFC9179 * lisp para2 corresponds to xxx in RFC9179 * .. * lisp paran corresponds to xxx in RFC9179” Thank you Cheers, Med De : Alberto Rodriguez-Natal (natal) <na...@cisco.com> Envoyé : mercredi 2 juillet 2025 18:34 À : Dino Farinacci <farina...@gmail.com>; BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com> Cc : The IESG <i...@ietf.org>; draft-ietf-lisp-...@ietf.org; lisp-cha...@ietf.org; lisp@ietf.org; Kiran Makhijani <kiran.i...@gmail.com> Objet : Re: [lisp] Re: Mohamed Boucadair's Discuss on draft-ietf-lisp-geo-14: (with DISCUSS and COMMENT) Hi Dino, Med, I was preparing the refresh of LISP YANG and checking this discussion. Just so that we are all in the same page, as you know, currently the YANG model uses the geo encoding defined in RFC8060. My understanding is that Alvaro’s plan for 8060bis [1] is to incorporate RFC-to-be-draft-ietf-lisp-geo in 8060bis. My opinion is that the YANG model should reflect whichever geo encoding ends up in 8060bis. We can discuss this further in Madrid. Alberto [1] https://datatracker.ietf.org/meeting/122/materials/slides-122-lisp-rfc8060bis-00 From: Dino Farinacci <farina...@gmail.com<mailto:farina...@gmail.com>> Date: Tuesday, June 17, 2025 at 6:31 PM To: mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>> Cc: The IESG <i...@ietf.org<mailto:i...@ietf.org>>, draft-ietf-lisp-...@ietf.org<mailto:draft-ietf-lisp-...@ietf.org> <draft-ietf-lisp-...@ietf.org<mailto:draft-ietf-lisp-...@ietf.org>>, lisp-cha...@ietf.org<mailto:lisp-cha...@ietf.org> <lisp-cha...@ietf.org<mailto:lisp-cha...@ietf.org>>, lisp@ietf.org<mailto:lisp@ietf.org> <lisp@ietf.org<mailto:lisp@ietf.org>>, Kiran Makhijani <kiran.i...@gmail.com<mailto:kiran.i...@gmail.com>> Subject: [lisp] Re: Mohamed Boucadair's Discuss on draft-ietf-lisp-geo-14: (with DISCUSS and COMMENT) > On Jun 17, 2025, at 5:09 AM, > mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> wrote: > > For the second point, the yang model will be following what is in the base > spec (i.e., draft-ietf-lisp-geo). The root issue should be discussed/fixed in > draft-ietf-lisp-geo. Thank you. I’m sorry but I don’t understand the root issue. The fields in the control packet are simply copied internally and set to the yang model according to the draft-ietf-lisp-yang document. Be specific in the issue bs pointing to an RFC. Because I can’t derive any issues or guess what your issue is. Dino _______________________________________________ lisp mailing list -- lisp@ietf.org<mailto:lisp@ietf.org> To unsubscribe send an email to lisp-le...@ietf.org<mailto:lisp-le...@ietf.org> ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ lisp mailing list -- lisp@ietf.org To unsubscribe send an email to lisp-le...@ietf.org
