Subject: Re: [Geopriv] Review of draft-bellis-geopriv-flow-identity-01

From: Robin Wilton <[email-masked]>
Date: Thu, 6 Sep 2012 17:02:36 +0100

Hi folks - 

Apologies for the very slow response following my promise to review the draft.

I agree with James that the draft is clear and to the point. I'm afraid I'm not competent to comment on the detail of the XML, but I did have a question about wider relevance of this draft.

While at IETF 84, I sat in on the atoca (Authority-to-citizen alert) session, where there was a predominantly US-centric discussion of emergency notification requirements. I wondered if the Emergency Location Working Group mentioned in the Introduction had taken a wider view than just UK telecom, and if so, whether this draft reflects an international approach to location data requests.

Hope this makes sense…

Yrs.,
Robin

Robin Wilton
Technical Outreach Director - Identity and Privacy
Internet Society

email: [email-masked]
Phone: +44 705 005 2931
Twitter: @futureidentity

On 28 Aug 2012, at 10:11, Ray Bellis wrote:

> 
> On 27 Aug 2012, at 02:58, "Winterbottom, James" <[email-masked]> wrote:
> 
>> Hi All,
>>  
>> Here is my review of draft-bellis-geopriv-flow-identity-01.
>>  
>> I like the draft and I think it is clear and to the point.
>>  
> 
> thanks :)
> 
>> Given that way that the flow element is defined I think it would be good to explicitly indicate that it deprecates the use of the port number as shown in the example in section 3.3 of RFC6155. This will ensure that we really only get flows specified using one data structure type.
> 
> Are there situations where the 6155 format may be useful and where the full tuple in my draft cannot be obtained?
> 
> I certainly don't mind deprecating that part of 6155 if appropriate.  I think I actually had that in mind when I specified that this draft would update 6155, since the draft doesn't otherwise do so at the moment.
> 
>> I think it would be useful if the IP address data type used in the flow draft was defined in the same way the IP address type in RFC6155 so that we have some consistency.
> 
> This is a deliberate design decision.
> 
> The idea of moving the v="n" attribute out of the <ip> element (and then not using the <ip> element) is to ensure that the protocol version cannot appear mismatched between the <src> and <dst> elements.  The protocol is more logically (IMHO) an attribute of the flow and not of the endpoints.
> 
> kind regards,
> 
> Ray
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv

---

From: Ray Bellis <[email-masked]>
Date: Fri, 7 Sep 2012 07:43:14 +0000

On 6 Sep 2012, at 17:02, Robin Wilton <[email-masked]>
 wrote:

> I agree with James that the draft is clear and to the point.

thanks :)

> I'm afraid I'm not competent to comment on the detail of the XML, but I did have a question about wider relevance of this draft.
> 

The NICC group does follow what's happening at NENA, EENA, etc.

Whilst in the longer term "device supplied" location may be preferable in some jurisdictions, some are taking the view that "network supplied" location is more trustworthy.

In many cases, network supplied location may need to be looked up based on an IP flow.

In that respect, this draft just seeks to correct a technical omission from RFC 6155.

kind regards,

Ray

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 7 Sep 2012 09:21:38 -0400

Remembering that:
a) VPNs and other mechanisms make IP address problematic for an identifier
b) The relationships between parties is significantly different.  Whether that's good or bad is in the eye of the beholder, but the device-centric model relies only on existing relationships and any OBO mechanism requires new relationships when the access network is not the calling(origination) network.  Regulators can force these kinds of relationships to come to pass, of course.

I'm still okay with this mechanism and the draft. 

Brian