Subject: RE: [Ecrit] draft-ietf-ecrit-framework-04

From: "Brian Rosen" <[email-masked]>
Date: Sun, 2 Dec 2007 20:09:15 -0500

> -----Original Message-----
> From: Cullen Jennings [mailto:[email-masked]]
> Sent: Thursday, November 29, 2007 10:41 PM
> To: ECRIT
> Subject: [Ecrit] draft-ietf-ecrit-framework-04
> 
> 
> I think there need to be more explanation about why the design allows
> multiple location objects and when this should be used (and how).
Okay, I'll work on it.

The general idea is that if you can choose wisely, do so, and send one.  If
you can't, choose the best you have for routing, mark it, and send the rest,
marked with who added it.

> 
> The location validation step seem a bit arm wavy in not clear exactly
> what you do, how anyone checks, and what happens if it fails. Perhaps
> I just need to go read other documents more.
Well, some words should be in LoST.  I guess I better check.

It's pretty easy: you validate before you put location in a LIS.  That's the
one MUST.  You should validate whenever you get location, and especially
before you need it for an emergency call.

If it fails before you need it, it's a human alarm.  If it fails at call
time, you can't get an accurate route, but you might get something "close". 

> 
> If you are going to say IPSEC is an acceptable alternative to TLS, I
> think you need to say what ways it needs to be used to be acceptable.
> Regardless of if it is TLS or IPSEC, having an encrypted connection
> to the attacker does not do you much good and you need to stop that
> somehow.
Agree more words are needed.  

> 
> Some trivial NIT stuff.
> 
> Overall there is a lot of duplicated ideas in here. I understand
> drafts get like this after years of editing.
Yeah, and the editor usually doesn't see them, so having them pointed out is
helpful

> 
> In the first list in section 3 before figure 1. I think it might help
> to add a "time passes" type text and make it very clear what happens
> at boot time and what happens when the call is dialed.
> 
> There are some section that look a little weird from formatting point
> of view in the txt version:
> * title section 4
> * Civic list item in 6.1
> * list in 6.2.4
> * list in 6.5
> 
> Should Location beacons be in section 6.2.3 instead of 6.2.4?
> 
> End of 1st para in 6.13. I think one of these references was meant to
> point at something else.
> 
> Cullen <with my individual contributor hat on>
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit