On April 26, 2022 at 9:44:10 AM, Luigi Iannone wrote: [Adding to the distribution list to keep everyone in the loop.]
Luigi: Hi! I have some replies below. I'll take a look at the diffs when you post an update. Thanks! Alvaro. ... > > > (1) Duplication and overlap ... > > [LI] Having a look to 6830bis: > Yes, Section 13.2 can be dropped altogether. 6830bis references Section 13.2 > in Section 10 and Section 5.3. Both references can be replaced to a reference > to 6834bis. > > As for the last two paragraphs: The very last is the text to be put in > section 5.3. > > The second last is actually already present in the security section of > 6834bis. This should be enough, right? > > I would just add the sentence “Further security considerations on > Map-Versioning can be found in [6834bis]” in the paragraph mentioning > Map-Versioning in Section 16 “Security Considerations” in 6833bis. This sounds good to me. As Shepherd for rfc6830bis, can you please take care of making sure this update gets done? > For 6833bis: > In Section 5.4 replacing: > > Map-Version Number: When this 12-bit value is non-zero, the Map- > Reply sender is informing the ITR what the version number is for > the EID record contained in the Map-Reply. The ETR can allocate > this number internally but MUST coordinate this value with other > ETRs for the site. When this value is 0, there is no versioning > information conveyed. The Map-Version Number can be included in > Map-Request and Map-Register messages. See Map-Versioning > [I-D.ietf-lisp-6834bis] for more details. > > With: > > Map-Version Number: 12-bit version number assigned to the EID > record contained in the Map-Reply. See Map-Versioning > [I-D.ietf-lisp-6834bis] for more details. > > The above should completely eliminate any duplication. Yup. Please also take care of this update. ... > > 224 4.1. The Null Map-Version > > > > [] The comments below indicate that there are multiple places that > > overlap with this section. The text from this section may be > > relocated (and clarifying actions taken) to make the document clearer. > > This section could then be eliminated. > > > > Paragraph 1 could be moved to §6. > > > > Paragraph 2 could be moved to §5/§5.1/§5.2. > > > > Paragraph 3 could be moved to §7. > > > > Paragraph 4 could be moved to §4. ... > > > [LI] This is certainly a possible approach, but actually back to the writing > of the original 6834, the section has been added in order to have one single > place that specifies everything related to the null version number. If you > really think that readability will have a huge improvement but spreading the > content in other sections this can be done. Yes, that's fine. ... > > 262 5. Dealing with Map-Version Numbers > > ... > > 272 To each mapping, a version number is associated and changes each time > > 273 the mapping is changed. Note that Map-Versioning does not introduce > > 274 new problems concerning the coordination of different ETRs of a > > 275 domain. Indeed, ETRs belonging to the same LISP site must return for > > 276 a specific EID-prefix the same mapping, including the same Map- > > 277 Version number. This is orthogonal to whether or not Map-Versioning > > 278 is used. The synchronization problem and its implications on the > > 279 traffic are out of the scope of this document. > > > > [] See my comment in §7 about leaving this out of scope and the > > requirement from rfc6833bis. > > > [LI] Not sure what is the issue here. This paragraph has been added in the > first 6834 document because of the question “can different ETRs have > different Map-Version for the same mapping” The answer is no. That text does > not change anything in the 6833bis. The text was cut before you got to §7. :-( _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
