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/ <https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/>. This document does not modify its functioning. > * 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. > * 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/ <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? > > 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. Thanks Ciao L. > > -- > Yoshi > >
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
