Hi Luigi, Thanks for the response. I put my comments inline.
On Fri, May 20, 2022 at 5:33 AM Luigi Iannone <[email protected]> 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 < > [email protected]> 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 > [email protected] 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
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
