Henning, ...
Comments:If deployed, this would become critical infrastructure for emergency response and for disaster handling. I'm quite concerned about moving itimmediately to Proposed Standard, which would amount to the IETF assertingthat it's nearly ready for that critical role. It feels to me very much like something that should be the subject of a serious experimentaldeployment first. I know we disclaim warranty of "FITNESS FOR A PARTICULARPURPOSE" 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 guess my main point is that in approving the package of drafts, the IESG needs to be sure that PS is the correct first step. I'm not even sure which way I would decide if I was still an AD.
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 inthe 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.
That would be fine. Since it's a generic issue, it should be discussed in a generic document. Maybe even a job for the IAB?
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.
But how do you rebuild the information? Suppose all the data centers
in NJ have been flooded and will take 6 months to recreate. I'd hope
that some sort of (wireless) infrastructure would reappear quite quickly.
At that point LoST would be lost, because the data were missing. But if
NJ arranged to have a copy kept in New Mexico, restoration could be
automatic once there was basic IP connectivity. I don't think mentioning
this is out of scope. It's an advantage of the architecture that it's possible.
Brian
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
