Subject: [Ecrit] draft-winterbottom-ecrit-specifying-holes-00

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 10 Oct 2007 23:09:02 -0500

FYI,

A new version of I-D, draft-winterbottom-ecrit-specifying-holes-00.txt
has been successfully submitted by James Winterbottom and posted to the
IETF repository.

Filename:	 draft-winterbottom-ecrit-specifying-holes
Revision:	 00
Title:		 Specifying Holes in LoST Service Boundaries
Creation_date:	 2007-10-11
WG ID:		 Independent Submission
Number_of_pages: 16

Abstract:
This document describes how holes can be specified in service
boundaries.  One means of implementing a solution is described.

http://tools.ietf.org/html/draft-winterbottom-ecrit-specifying-holes-00

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 17 Oct 2007 11:12:02 +0300

Hi Martin,
Hi James,

thanks for the document. A few comments:

* I don't think this type of document is a BCP. The draft header says 
GEOPRIV rather than ECRIT. I wonder whether you think that the document 
updates draft-ietf-ecrit-lost-06?

* Introduction

"The boundary is a polygon made up of sets of geodetic coordinates 
specifying an enclosed area."

The boundary may also be expressed using civic location info. We did not 
specify holes for civic location information, however. I think we should 
also investigate that aspect!

"This document describes how holes SHOULD be specified in service 
boundaries defined using a GML encoding for the polygons and their 
internal elements (holes)."

The RFC 2119 "SHOULD" in this sentence is not appropriate here. No 
interoperability issue in this document.

Maybe you want to reference the figure in the text and to add a caption 
to it.

* Section 3

The rules seem to be fine with me although one might argue that they are 
common sense.

"
A hole MUST be a legal polygon in accordance with the geoshape 
specification [geoshape]. There is no restriction on the number of 
points that may be used to express the perimeter of the hole.
"

I would rather write:

"
A hole MUST be a legal polygon in accordance with the geoshape 
specification [geoshape] with the exception that there is no restriction 
on the number of points that may be used to express the perimeter of the 
hole.
"

I recall that there is this 16 point restriction in the geoshape document.

* Section 4: I assume that this section is more a reminder on how the 
polygon is specified in PIDF-LO profile/Geoshapes.
Do you think it is necessary?

* Section 6

I wonder whether you really need a normative reference to 
[I-D.schulzrinne-ecrit-lost-sync]. In some sense I am a bit confused 
about this section. While I see it being useful to have a mechanism for 
synchronizing information between LoST servers I wonder why holes in 
polygons of service boundaries are really so special that a description 
of the synchronization mechanism is necessary.

* IANA Considerations

It is good to see that you believe that the location profile 
"geodetic-2d" can be reused instead of defining an additional, new 
location profile.

Ciao
Hannes

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 17 Oct 2007 06:55:44 -0500

Hi Hannes, 

Thanks very much for the comments.
A few comments of mine inline:

Cheers
James

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Wednesday, 17 October 2007 6:12 PM
> To: Winterbottom, James
> Cc: ecrit
> Subject: Re: [Ecrit] draft-winterbottom-ecrit-specifying-holes-00
> 
> Hi Martin,
> Hi James,
> 
[AJW] Yes.. Geopriv is a querk I shall fix that. Maybe it updates LoST,
I actually wanted this document as an appendix to Henning's file-format
document but he refused. May be it stands on its own.

> also investigate that aspect!
[AJW] Yes in so far as Civic needs to express areas too, and I don't
believe that the revised civic format can cater for this. In fact I
don't believe that it can even address the kinds of ranges required
without holes, and this needs to be explored in a lot more detail.
Currently I view it as out of scope for this document.

> interoperability issue in this document.
[AJW] I don't think that this is quite right. Polygons don't strictly
speaking, allow boundary lines to cross on another, and similarly, other
than the first and last points it isn't good practice to share points.
Unless this is clearly pointed out, it may well lead to interoperability
problems.

> The rules seem to be fine with me although one might argue that they
are

[AJW] I actually had to clarify my rationale to at least one person, and
that was reflected back into the rules as you see them. So maybe they
are only common sense after they spelt out.

> I recall that there is this 16 point restriction in the geoshape
document.
[AJW] Not quite. GeoShape says that if interoperability with 3GPP GAD is
required that points in total must not exceed 16 points. There is no
3GPP GAD interoperability required in this case because we are
expressing a service boundary and not a Target Location.

> Do you think it is necessary?
[AJW] Probably not. I will delete this in the next version.

> of the synchronization mechanism is necessary.
[AJW] The rationale for this may be flawed. I see Henning's document as
not only defining the file inter-change format between LoST servers but
also forming the basis for data feeds into LoST servers. Having a
standard format for this kind of thing is a good idea, and I don't see
why Henning's suggested format couldn't work in this area. Again common
sense dictates one format is better than many.

> > A new version of I-D,
draft-winterbottom-ecrit-specifying-holes-00.txt
------------------------------------------------------------------------
> ------------------------
------------------------------------------------------------------------
> ------------------------