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) <[email protected]> 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 <[email protected]> > Date: Tuesday, 31 May 2022 at 13:11 > To: Eric Vyncke <[email protected]> > Cc: The IESG <[email protected]>, "[email protected]" > <[email protected]>, "[email protected]" > <[email protected]>, "[email protected]" <[email protected]>, Padma Pillay-Esnault > <[email protected]> > 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 <[email protected] >> <mailto:[email protected]>> 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>
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
