Hi Luigi,
Thanks for the response. I put my comments inline.
On Fri, May 20, 2022 at 5:33 AM Luigi Iannone <ggx@xxxxxxxxx> 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 <noreply@xxxxxxxx> 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
tsv-art@xxxxxxxx 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).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
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
