Re: [Tsv-art] Tsvart last call review of draft-ietf-lisp-6834bis-10

[Yoshifumi Nishida <[e-mail]>]

Hi Luigi,

Thanks for the response. I put my comments inline.

On Fri, May 20, 2022 at 5:33 AM Luigi Iannone <[e-mail]> wrote:

> Hi Yoshifumi,
>
> Thank you very much for your review.
> Please find a few comments inline.
>
>
> On 17 May 2022, at 10:22, Yoshifumi Nishida via Datatracker <
> [e-mail]> wrote:
>
> Reviewer: Yoshifumi Nishida
> Review result: Almost Ready
>
> This document has been reviewed as part of the transport area review team's
> ongoing effort to review key IETF documents. These comments were written
> primarily for the transport area directors, but are copied to the
> document's
> authors and WG to allow them to address any issues raised and also to the
> IETF
> discussion list for information.
>
> When done at the time of IETF Last Call, the authors should consider this
> review as part of the last-call comments they receive. Please always CC
> [e-mail] if you reply to or forward this review.
>
> Summary: This document is almost ready for publication as a Proposed
>         Standard document. but I believe it will be better to address
>         the following points.
>
>
> 1: It would be better to clarify the following points in the protocol for
>   registering Map Version number.
>
>   * How many versions of mapping should be maintained by routers and
> servers?
>     Only the latest one or else?
>
>
> Excellent point. It is only that latest. But for us was so obvious that we
> did not explicitly mention this point. We will add an explicit sentence.
>
>   * Are we allowed to send a new Map-Register message while waiting for
>     another Map-Register message?
>
>
> Map-registers and related operation are defined in
> https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/.
> This document does not modify its functioning.
>

Got it. It might be good if you could mention it in the draft.


>
>   * What will be the action when Map-Server receives the version number
>     that they are not expecting? Discard or else?
>
>
> Discard. We will add text to clarify this action.
>

OK. Thanks.


>
>   * What will be the action when Map-Register message reaches
> retransmission
>     limits?
>
>
> This is again defined in
> https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/.
> This document does not modify its functioning.
>
>
> 2: Page 3 Section 1:
>   "If this is not the case, the ETR can directly send a Map-Request
> containing
>    the updated mapping to the ETR,"
>
>      -> could it be "to the ITR"?
>
>
> Yes, thank you for spotting this typo.
>
>
> 3: Page 6 Section 6:
>   "An update in the version number (i.e., a newer version) consists of
>    incrementing by one the older version number"
>
>      -> This seems to be an integral part of the protocol.
>         I think using MUST here would be preferable.
>
>
> What about this formulation:
>
> An update in the version number
>    (i.e., a newer version) MUST consist in an increment by one the older
>    version number (only exception is for the Null Map-Version as
>    explained in at the end of Section 6.1 <https://datatracker.ietf.org/doc/html/draft-ietf-lisp-6834bis#section-6.1>).
>
>
> Is it OK?
>
>
Yes, works for me. Thanks for addressing.

>
> 4: Page 6 Section 6:
>   I am wondering what is the use case for comparing two version numbers.
>   I might miss something, but it seems to me that we just need to check
>   whether the version number is the expected one or not.
>   It might be better to explain the use case for it if there is any.
>
>
> That is explained in detail in Section 7. We will add an forward reference
> to that section.
>
> Got it. I am thinking that it might be better to explain in which
situations you might receive old version numbers or newer version numbers
with a gap bigger than 1.
Thanks,
--
Yoshi