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

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: wilton@isoc.org
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" <James.Winterbottom@commscope.com> 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
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv

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

Attachment: smime.p7s