Re: [lisp] Éric Vyncke's No Objection on draft-ietf-lisp-6834bis-11: (with COMMENT)

[Luigi Iannone <[e-mail]>]

Thanks Éric,

I will include the discussed changes in the next revision (tomorrow at latest so that is available for the telechat)

Ciao

L.



> On 31 May 2022, at 14:33, Eric Vyncke (evyncke) <[e-mail]> wrote:
> 
> Thank you, Luigi, for the fast reply !
>  
> Indeed, as you guessed, I made a mistake when copying & pasting from my ‘ballot template’ into your I-D... I really want to apologize [*]
>  
> Understood for the ‘N’ discussion, still suggest to only use it for 12 bits but this is cosmetic. Up to the authors.
>  
> The proposed text for the security consideration is an improvement to my eyes. Again up to the authors.
>  
> Hope this will help the document,
>  
> Regards,
>  
> -éric
>  
> [*] as a lame excuse, have a look on my ‘to review’ list https://datatracker.ietf.org/iesg/agenda/documents/ <https://datatracker.ietf.org/iesg/agenda/documents/> (knowing that last week was partly ‘off’ in most of Europe as you know).
>  
> From: Luigi Iannone <[e-mail]>
> Date: Tuesday, 31 May 2022 at 13:11
> To: Eric Vyncke <[e-mail]>
> Cc: The IESG <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, Padma Pillay-Esnault <[e-mail]>
> Subject: Re: Éric Vyncke's No Objection on draft-ietf-lisp-6834bis-11: (with COMMENT)
>  
> Hi Éric,
>  
> Thank you very much for your review.
> Please find my comments inline.
> 
> 
>> On 31 May 2022, at 09:54, Éric Vyncke via Datatracker <[e-mail] <mailto:[e-mail]>> wrote:
>>  
>> Éric Vyncke has entered the following ballot position for
>> draft-ietf-lisp-6834bis-11: No Objection
>> 
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>> 
>> 
>> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ <https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/> 
>> for more information about how to handle DISCUSS and COMMENT positions.
>> 
>> 
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-lisp-6834bis/ <https://datatracker.ietf.org/doc/draft-ietf-lisp-6834bis/>
>> 
>> 
>> 
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>> 
>> # Éric Vyncke, INT AD, review of draft-ietf-lisp-6834bis-11
>> 
>> Thank you for the work put into this document.
>> 
>> Please find below some blocking DISCUSS points (easy to address), some
>> non-blocking COMMENT points (but replies would be appreciated even if only for
>> my own education), and some nits.
>> 
>> Special thanks to Padma Pillay-Esnault for the shepherd's write-up including
>> the WG consensus and the intended status.
>> 
>> I hope that this helps to improve the document,
>> 
>> Regards,
>> 
>> -éric
>> 
>> ## DISCUSS
>> 
>> As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a
>> DISCUSS ballot is a request to have a discussion on the following topics:
>> 
>> ### Section 2.2
>> 
>  
> I miss the DISCUSS point here, and there is not section 2.2 (may be a cut and paste error?)
>  
> 
> 
>> ## COMMENTS
>> 
>> ### Section 6
>> 
>> Just wondering why having an algorithm defined for 'N' while the versions are
>> always on 12 bits.
>  
> At the very very beginning there were a couple of options on where to place the version number in the header (original suggestion was in replacement of the Loc-Status-Bits). So, we described the general algorithm without specifying the real size of the field. 
>  
> 
> 
>> 
>> ### Section 8
>> 
>> ```
>> Map-Versioning MUST NOT be used over the public Internet and SHOULD
>>   only be used in trusted and closed deployments.
>> ```
>> 
>> An explanation of why and how would be welcome. Feel free to ignore this
>> comment though as this is the usual recommendation for any tunneling mechanism
>> w/o authentication/confidentiality.
>> 
>  
> The MUST NOT is actually part of the overall review and discussion that has been held about 6830bis and 6833bis (and 6834bis).
> Consensus was on the MUST NOT be used. We can actually merge the sentence with the previous paragraph to highlight the link with those documents:
>   
>    This document builds on the specification and operation of the LISP
>    control and data planes.  The Security Considerations of
>    [I-D.ietf-lisp-rfc6830bis <https://datatracker.ietf.org/doc/html/draft-ietf-lisp-6834bis#ref-I-D.ietf-lisp-rfc6830bis>] and [I-D.ietf-lisp-rfc6833bis <https://datatracker.ietf.org/doc/html/draft-ietf-lisp-6834bis#ref-I-D.ietf-lisp-rfc6833bis>] apply, as such 
>    Map-Versioning MUST NOT be used over the public Internet and SHOULD
>    only be used in trusted and closed deployments.  A
>    thorough security analysis of LISP is documented in [RFC7835 <https://datatracker.ietf.org/doc/html/rfc7835>].
>  
>  
> Would this work better?
>  
>> ## NITS
>> 
>> ### Section 6
>> 
>> s/MUST consist in an increment by one the older/MUST consist in an increment by
>> one of the older/ ? Moreover, 'increment' is usually understood as 'add 1' so
>> no need to add 'by one' in the sentence
>  
> Thanks. Will fix as suggested.
>  
> Thank you again for the review.
>  
> Ciao
>  
> L.
>  
> 
> 
>> 
>> ## Notes
>> 
>> This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
>> [`ietf-comments` tool][ICT] to automatically convert this review into
>> individual GitHub issues.
>> 
>> [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md <https://github.com/mnot/ietf-comments/blob/main/format.md>
>> [ICT]: https://github.com/mnot/ietf-comments <https://github.com/mnot/ietf-comments>