I have been selected as the General Area Review Team (Gen-ART)
reviewer
for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Thanks, Brian, for your comments. Some quick responses inline.
Document: draft-ietf-ecrit-mapping-arch-03.txt
Reviewer: Brian Carpenter
Review Date: 2007-11-22
IETF LC End Date: 2007-11-29
IESG Telechat date: (if known)
Summary: Almost ready, with concerns
Comments:
If deployed, this would become critical infrastructure for emergency
response and for disaster handling. I'm quite concerned about moving
it
immediately to Proposed Standard, which would amount to the IETF
asserting
that it's nearly ready for that critical role. It feels to me very
much
like something that should be the subject of a serious experimental
deployment first. I know we disclaim warranty of "FITNESS FOR A
PARTICULAR
PURPOSE" but this is about sending ambulances to the wrong address,
or not knowing where to send them after an explosion.
Given the caching architecture, the critical component is probably the
LoST spec, but maybe your comments address more of the overall
architecture than the protocol itself.
I needed to look at draft-ietf-ecrit-lost-06.txt while reviewing the
present
draft. Since I carry scars from IESG discussion of draft-ietf-
geopriv-dhcp-civil
(now RFC 4676) I looked for references to that work. I'm puzzled
that RFC 4676,
LoST and draft-ietf-enum-validation-token seem to take different
approaches
to civic/civil location specifications. This seems like storing up
trouble.
In any case it seems like an architectural issue that should be
mentioned in
the current draft.
In general, I agree that this is not desirable, but this is not really
a LoST issue. LoST re-uses the location format visible in signaling
requests, i.e., the location part of PIDF-LO. For all location
applications that use DHCP (or LLDP-MED, which uses roughly the same
format), there will have to be a conversion to XML. The choice was
made due to the highly-constrained space available in DHCP and LLDP
packets. There is a separate document that details the conversion
(draft-ietf-geopriv-pdif-lo-profile), in combination with RFC 4776.
RFC 4776 and, more recently and in more detail, draft-ietf-geopriv-
revised-civic-lo-06 address the conversion to the PIDF-LO XML format.
I believe that these issues should be covered in the phone-bcp
document, for example, but I'd be happy to add a paragraph explaining
this.
While the architecture certainly includes provision for resilience
(basically caching, and redundancy within clusters) I would have
wanted
to see a discussion of resilience when large parts of the Internet
infrastructure in a geographic region are destroyed. Are redundant
copies
of the information held in other geographic regions? What is the
minimal
amount of connectivity that's needed to access such out-of-region
copies? What dependencies are there (DNS, routing, etc.)? In other
words,
will LoST be part of the disaster or part of the recovery?
I'm not quite sure I understand this comment. The call routing
information is largely of local use. In other words, there's not much
point in having somebody in Australia know which New Jersey fire
department responds to my emergency call unless I, living in NJ, can
get access to that information. Thus, this is a classical example of
fate sharing: As long as there's local infrastructure, LoST should
continue to work. If all local infrastructure has been destroyed,
there is no way to use that infrastructure to place an emergency call,
or to route it. Thus, unlike for other infrastructure where geographic
redundancy is helpful for disaster recovery, it has far less utility
here.
Henning
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
