Re: [lisp] AD Review of draft-ietf-lisp-6834bis-09

[Luigi Iannone <[e-mail]>]

Hi Dino,

This was just the original reply, in the meantime you already updated the bis documents as discussed in different threads.

Thanks

Ciao

L.
  

> On 4 May 2022, at 22:14, Dino Farinacci <[e-mail]> wrote:
> 
>> [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.
> 
> Are you making a comment that 6830bis-37 is not complete?
> 
> I'm looking at your other email. I don't have context to your commenting. You didn't provide enough detail if you are referring to -37, -38, or -38-2.
> 
>> 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.
> 
> This is in draft-ietf-lisp-rfc6833bis-31 and has been submitted.
> 
> Dino
> 
> 
>