Subject: [lisp] Fwd: [Gen-art] Gen-ART LC review of draft-ietf-lisp-map-versioning-02

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 02 Sep 2011 12:46:15 -0400

(Terry, I believe you saw this, copying the WG for everyone's information.)
This Genart review makes an interesting point.  I would like to hear 
from the authors as to whether they agree.

Yours,
Joel M. Halpern

-------- Original Message --------
Subject: [Gen-art] Gen-ART LC review of draft-ietf-lisp-map-versioning-02
Date: Fri, 2 Sep 2011 11:07:23 -0400
From: Richard L. Barnes <[email-masked]>
To: General Area Review Team <[email-masked]>

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-lisp-map-versioning-02.txt
Reviewer: Richard Barnes
Review Date: 02 September 2011
IETF LC End Date: 12 September 2011
IESG Telechat date: (if known) -

Summary:
Not ready

Major issues:

General
Overall the distinction  between "older" and "newer" version numbers 
does not seem meaningful.  Treating the two cases differently doesn't 
add any value, and just causes synchronization problems with things like 
restarts.  The salient distinction is "Is this version number the one I 
have in my cache or not?"  If so, no action; if not, refresh the 
mapping.  Cf. <http://xmpp.org/extensions/xep-0237.html#format>

Section 5.1. bullet 2
This bullet needs to be reconsidered.  Misbehavior is not the only 
situation in which this situation could arise.  Consider, for example, 
if the ETR for a site reboots and creates a new random initial map 
version.  Then everyone that has mappings cached will have the wrong 
map-version, and all traffic will get silently dropped.  Suggest adding 
an error message here that indicates the proper version.

Section 5.1. bullet 3
Having an ETR *force* an ITR to update its mapping seems intrusive and 
fraught with security risks.  Suggest adding an error message here that 
indicates the proper version, so that the ITR can make its own decision 
as to whether to update the cache.

Section 5.1. paragraph after bullet 3
Again, I'm concerned about silently dropping packets.  ITRs are not 
required to renew mappings when TTLs expire, so it's very plausible that 
an ITR might have stale mappings.  If such an ITR just has all its 
traffic dropped, then it has no signal to refresh.  Suggest adding an 
error message here that indicates the proper version.

Minor issues:

Editorial:

There are numerous grammatical errors, e.g.:
"If it is not the case, a Map Request can be send."
"... map-versioning does not introduce any new problem ..."
"The ETR's synchronization problem is out of the scope of this document."

Please expand "w.r.t."
_______________________________________________
Gen-art mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/gen-art