Dino, Let’s go step by step.
Let’s postpone the text relocation and focus first on the other concerns I have. > On 2 May 2024, at 22:29, Dino Farinacci <farina...@gmail.com> wrote: > > Luigi, see the diff file for most of your comments. I still cannot follow > your move suggestions. Just moving text around away from where they are, are > going to lose points I intended. You need to be crystal clear what text needs > to move where and be precise why you think so. I feel the text doesn't need > moving. So if you think it does you need to make compelling reasons without > destroying the flow and meaning I have intended. > > I made all the changes you requested in this diff file. I have comments for > what I didn't change (I didn't comment on the move text since I did above). > >> Dino, you correct text mixes specifications and use cases. By concentrating >> the specifications in one section (namely section 5) you will improve >> readability and clarity of the document. > > No it doesn't. You are using the term use-cases in a high level sense. We are > discuss functionality and why the ELP is needed. No Dino. You are mixing examples and procedures, hence my suggestion to move around some text. But we will deal with this later. > >> What really request is a mapping, which may or may not be an ELP. >> What happens if it receives a negative map-reply? > > It follows the procedures of RFC9301. And we don't need to state this > everywhere. We are assuming the reader knows how LISP works at a high level. So your text is wrong because it states "requests the ELP for RTR ‘y’”. You request a mapping and act upon what you receive, you do not request an ELP for ‘y’. > >> You mean that this second lookup can be done on a mapping system that is >> different from the one who delivered the initial ELP, right? >> If yes, can you state so? > > It means the ELP entry is an EID, so to get the RLOC for that EID, you do > another lookup. It gives another level of indirection within an ELP. The sentence I referring to is: This can be done when using a public or private mapping database. Why are you introducing this distinction between public and private? > >> The document uses a mix of “seid” and “S-EID”, choose one. > > > On purpose. The seid and deid are used in the forwarding examples. The > (S-EID) is only in the multicast section. But you do not explain de difference. Either uniform them or explain. As it is now is just confusing. > >> How the S-bit, L-bit, and the P-bit are used is not covered at all and >> should be described in section 5. > > It is explained in RFC8060. I don't want to repeat. Agreed. > > So this is the way I want your response. Because this commentary and edits > are getting too complex. I want you to respond to this email so we can > negotiate the repsonses I provided. And I want another email for the moved > text that is written with clarity and precision. Okay? > > Dino >
<<< text/html; x-unix-mode=0644; name="draft-ietf-lisp-te-15.diff.html": Unrecognized >>>
> > > > Comments on the diff: The example in figure 2, with your latest changes makes even less sense, since you are now using an ELP to make the packet go through exatly the same path as in figure 1. Looks useless. The sentence about provisioning system is still obscure. The LISP control plane is defined in RFC 9301. You are suggesting to use something else to register mappings, which is defined nowhere. So unless you want to define such a provisioning system please delete the sentence. Once we converge on these issues we will discuss about moving text around. CIao L. >
_______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
