Subject: [Gen-art] Gen-ART LC review of draft-ietf-ecrit-mapping-arch-03.txt

From: Brian E Carpenter <[email-masked]>
Date: Thu, 22 Nov 2007 11:03:09 +1300

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 22 Nov 2007 23:03:49 -0500

> 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

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 24 Nov 2007 08:16:46 +1300

Henning,

...
>> response and for disaster handling. I'm quite concerned about moving it
>> that it's nearly ready for that critical role. It feels to me very much

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.

>> 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,
> 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 
> 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?

>> (basically caching, and redundancy within clusters) I would have wanted
>> infrastructure in a geographic region are destroyed. Are redundant copies
>> of the information held in other geographic regions? What is the minimal
>> copies? What dependencies are there (DNS, routing, etc.)? In other words,
> 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