Subject: [Geopriv] More HELD-04 comments

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 14 Jan 2008 22:57:25 -0600

Hi Mary,

After a more thorough read, here are some additional comments.

1) There are quite a few dependencies on other IETF drafts. It would be
good to reduce this number if possible. Examples are provided in
specific comments below.
	 
2) The last sentence of section 3 references SIP location conveyance,
while this is nice, it is not technically necessary.

3) The last paragraph of section 4.3 should say that section 4.3.2 makes
recommendation to address this problem. When I read this the first time
it kind of left me hanging as to what to do.
 
4) The last paragraph of section 4.3.1 adds not real value and should be
removed. In addition there are distinct problems with this approach
particularly since HELD can deal with all of the geoshape types and
LLDP-MED and DHCP cannot. This also removes references 21 and 25.

5) Section 5.3, should also add that the Location response is depends on
what the LIS is able to provide, not just what was requested. It is
perfectly valid, for example, for the Device to request civic location
but get back a location Uri set.

6) Section 6.5 is incorrect. The LIS returns a locationUriSet which
consists of one or more locationURIs. The HELD specification doesn't
dictate what form these URI take, except to say that a define way to use
them to get location information needs to exist. This problem is
subsequently reflected in the examples. It is quite possible, for
example that the LIS will return a held: URI, a sip: URI, a sips: URI, a
pres; URI, and possibly in the future straight http: URI. The second as
currently written restricts HELD to returning only held: URIs and these
appear to be defined in multitude of ways.

The last paragraph of section 6.5 introduces a dependency on the HELD
dereference draft. I suggest that this be removed.

7) Section 6.5.1 applies to the entire locationUriSet. The last sentence
of the last paragraph here should be clarified. If a location URI is
dereferenced after the expiry time the LIS MUST return an error.

8) I have already provided comments on the required schema changes
required to section 7.

9) Section Security considerations. I have an issue with referring to
the 
"Security Requirements for the Geopriv Location System",
draft-barnes-geopriv-lo-sec-01 as it currently stands. This because this
is an individual submission, and the security section of that document
is largely incomplete. Whilst I like the direction of Richard et al's
document, it is not complete enough for us to have as a normative
reference for HELD. The security section for the HELD document should
refer to RFC 3693 and RFC 3694. 

10) Location URI example in section 10.2 is incorrect, see above and
previous post.

11)  10.3 example has a problem with the second location URI, this
should have remained SIP. See above as to why.

12) Section 11.4 Error code registry is only specification recommended,
why isn't this specification required? I am concerned about allowing
HELD error codes to be specified without a corresponding specification
being required.

13) Section 11.5 Doesn't need to talk about the dereference protocol,
and should only register one form of URI. I propose the
held://lis.example.com:2198/<something random in here> form.

14) Section 13. I think that Tatham Oddie I think has also provided
comments and has agreed to provide a detailed technical review.

Cheers
James

------------------------------------------------------------------------------------------------
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]

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

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 15 Jan 2008 00:01:02 -0600

Hi Mary,

I'll try not to rehash issues raised by James, but I will generally agree with his comments, especially regarding the references.

I'll go in document order, nits and all.  This isn't 100% complete, since other work calls me away; I'll be back before WGLC ends...

Section 4 - the introduction to this section would read easier if it were at least 3 paragraphs.  There are at least three distinct concepts here.

Section 4.3.1 - You have a few too many commas in this section.  Have a bit of a read and remove some.  For instance, "should provide the address, of the LIS"
   - Use probable, not permissible where appropriate:
	s/VPN tunnel, the Device may receive inaccurate location
       /VPN tunnel, the Device might receive inaccurate location/x
   - When using lower case requirements words, finding an alternative word helps avoid confusion:
      s/ may serve as a LIS/ could serve as a LIS/
   - I don't like the last paragraph of this section, but I wont fight that hard.

Section 5.1 - s/Section 8 ./Section 8./

Section 6 - When you talk about the "PIDF-LO" parameter (check capitalization on that too), it implies that there is an XML element <PIDF-LO> or something similar.  Perhaps it would be better to refer to the ``"presence" parameter (PIDF-LO)''.  This applies more to Section 6.6.

Section 6.5 - I have a number of problems with the URI.  Primarily, I don't think that there is enough detail to implement a URI dereferencer.  I understand if you think that deferring that to held-dereference is OK, but I agree with James in that HELD should not depend on the dereference draft.  Instead, you only need define a URI that is similar to the HTTP URL.  You could even reference RFC 2616, Section 3.2.2 and say that the HELD URI is identical to the HTTP URL except for the following exceptions:
 - The port is mandatory (since there is no default, you have to do this)
 - There is no user:password component (although it would seem that despite common usage, RFC 2616 doesn't permit this either; it's still worth pointing out though, enough people _mis_use those fields)
Noting that the held: URI is used for the HTTP binding is sufficient.  Other bindings can (and perhaps should) define their own URIs.

   held_URL = "held:" "//" host ":" port [ abs_path [ "?" query ]]

Or to use the RFC 3986 definitions:

   held-URI      = "held" ":" held-hier-part [ "?" query ] [ "#" fragment ]
   held-hier-part     = "//" held-authority path-abempty / path-absolute
   held-authority     = host ":" port
   ; All definitions taken directly from RFC 3986

Section 6.5.1 - Regarding:
   If a Device dereferences the location URI after the XML
   Schema definition expiry time, it would be possible to get an
   entirely invalid location for that Device.
 I'd prefer the following, which is simpler and more definitive:
   If the location URI is dereferenced after the expiry time, the
   dereference MUST fail.
 I'm not 100% certain on the strength of the "MUST".  Certain regulatory requirements make this a little shakey.

Section 10 - a blank line after each example would make the whole document easier to read.

Section 11.1.2 - needs to be deleted.  This is a hangup from the old WSDL days.  I missed it then, but I'm reviewing the diff this time and it leapt out at me.

> -----Original Message-----
> From: Winterbottom, James [mailto:[email-masked]]
> Sent: Tuesday, 15 January 2008 3:57 PM
> To: Mary Barnes
> Cc: [email-masked]
> Subject: [Geopriv] More HELD-04 comments
> 
> Hi Mary,
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 15 Jan 2008 00:02:21 -0600

Oh, and it was remiss of me not to thank you for the (enormous) effort put into updating the document.  The new revision shows a lot of effort.  Thanks for doing that.

Thanks,
Martin

> From: Thomson, Martin
> Sent: Tuesday, 15 January 2008 5:01 PM
> To: Mary Barnes
> Cc: [email-masked]
> Subject: [Geopriv] More and more HELD-04 comments
> 
> Hi Mary,
> 
> I'll try not to rehash issues raised by James, but I will generally agree
> with his comments, especially regarding the references.
> 
> 
> I'll go in document order, nits and all.  This isn't 100% complete, since
> other work calls me away; I'll be back before WGLC ends...
> 
> Section 4 - the introduction to this section would read easier if it were
> at least 3 paragraphs.  There are at least three distinct concepts here.
> 
> Section 4.3.1 - You have a few too many commas in this section.  Have a
> bit of a read and remove some.  For instance, "should provide the address,
> of the LIS"
> Section 6 - When you talk about the "PIDF-LO" parameter (check
> capitalization on that too), it implies that there is an XML element
> <PIDF-LO> or something similar.  Perhaps it would be better to refer to
> the ``"presence" parameter (PIDF-LO)''.  This applies more to Section 6.6.
> 
> Section 6.5 - I have a number of problems with the URI.  Primarily, I
> don't think that there is enough detail to implement a URI dereferencer.
> I understand if you think that deferring that to held-dereference is OK,
> but I agree with James in that HELD should not depend on the dereference
> draft.  Instead, you only need define a URI that is similar to the HTTP
> URL.  You could even reference RFC 2616, Section 3.2.2 and say that the
> HELD URI is identical to the HTTP URL except for the following exceptions:
>  - There is no user:password component (although it would seem that
> despite common usage, RFC 2616 doesn't permit this either; it's still
> worth pointing out though, enough people _mis_use those fields)
> Noting that the held: URI is used for the HTTP binding is sufficient.
> Other bindings can (and perhaps should) define their own URIs.
> 
> Section 11.1.2 - needs to be deleted.  This is a hangup from the old WSDL
> days.  I missed it then, but I'm reviewing the diff this time and it leapt
> out at me.
> 
> > ------------------------------------------------------------------------
> --
> > ----------------------
> > ------------------------------------------------------------------------
> --
> > ----------------------
> > [mf2]
> >
> >
> >

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 15 Jan 2008 00:42:18 -0600

I totally agree with Martin here. Thanks very much Mary for a job well
done.

Cheers
James

-----Original Message-----
From: Thomson, Martin [mailto:[email-masked]] 
Sent: Tuesday, 15 January 2008 5:02 PM
To: Mary Barnes
Cc: [email-masked]
Subject: RE: [Geopriv] More and more HELD-04 comments

Oh, and it was remiss of me not to thank you for the (enormous) effort
put into updating the document.  The new revision shows a lot of effort.
Thanks for doing that.

Thanks,
Martin

> I'll try not to rehash issues raised by James, but I will generally 
> agree with his comments, especially regarding the references.
> 
> 
> I'll go in document order, nits and all.  This isn't 100% complete, 
> since other work calls me away; I'll be back before WGLC ends...
> 
> Section 4 - the introduction to this section would read easier if it 
> were at least 3 paragraphs.  There are at least three distinct
concepts here.
> 
> Section 4.3.1 - You have a few too many commas in this section.  Have 
> a bit of a read and remove some.  For instance, "should provide the 
> address, of the LIS"
>    - I don't like the last paragraph of this section, but I wont fight

> that hard.
> <PIDF-LO> or something similar.  Perhaps it would be better to refer 
> to the ``"presence" parameter (PIDF-LO)''.  This applies more to
Section 6.6.
> I understand if you think that deferring that to held-dereference is 
> OK, but I agree with James in that HELD should not depend on the 
> dereference draft.  Instead, you only need define a URI that is 
> similar to the HTTP URL.  You could even reference RFC 2616, Section 
> 3.2.2 and say that the HELD URI is identical to the HTTP URL except
for the following exceptions:
> worth pointing out though, enough people _mis_use those fields) Noting

> that the held: URI is used for the HTTP binding is sufficient.
>  I'm not 100% certain on the strength of the "MUST".  Certain 
> regulatory requirements make this a little shakey.
> 
> Section 11.1.2 - needs to be deleted.  This is a hangup from the old 
> WSDL days.  I missed it then, but I'm reviewing the diff this time and

> it leapt out at me.
> > 1) There are quite a few dependencies on other IETF drafts. It would

> > be good to reduce this number if possible. Examples are provided in 
> > specific comments below.
> >
> > 2) The last sentence of section 3 references SIP location 
> > conveyance, while this is nice, it is not technically necessary.
> >
> > 3) The last paragraph of section 4.3 should say that section 4.3.2 
> > makes recommendation to address this problem. When I read this the 
> > first time it kind of left me hanging as to what to do.
> >
> > 4) The last paragraph of section 4.3.1 adds not real value and 
> > should be removed. In addition there are distinct problems with this

> > approach particularly since HELD can deal with all of the geoshape 
> > types and LLDP-MED and DHCP cannot. This also removes references 21
and 25.
> >
> > 5) Section 5.3, should also add that the Location response is 
> > depends on what the LIS is able to provide, not just what was 
> > requested. It is perfectly valid, for example, for the Device to 
> > request civic location but get back a location Uri set.
> >

> > dictate what form these URI take, except to say that a define way to

> > use them to get location information needs to exist. This problem is

> > example that the LIS will return a held: URI, a sip: URI, a sips: 
> > URI, a pres; URI, and possibly in the future straight http: URI. The

> > second as currently written restricts HELD to returning only held: 
> > URIs and these appear to be defined in multitude of ways.
> >
> > The last paragraph of section 6.5 introduces a dependency on the 
> > HELD dereference draft. I suggest that this be removed.
> >
> > 7) Section 6.5.1 applies to the entire locationUriSet. The last 
> > sentence of the last paragraph here should be clarified. If a 
> > location URI is dereferenced after the expiry time the LIS MUST
return an error.
> > 9) Section Security considerations. I have an issue with referring 
> > to the "Security Requirements for the Geopriv Location System",
> > draft-barnes-geopriv-lo-sec-01 as it currently stands. This because 
> > this is an individual submission, and the security section of that 
> > document is largely incomplete. Whilst I like the direction of 
> > Richard et al's document, it is not complete enough for us to have 
> > as a normative reference for HELD. The security section for the HELD

> > document should refer to RFC 3693 and RFC 3694.
> >

> > 12) Section 11.4 Error code registry is only specification 
> > recommended, why isn't this specification required? I am concerned 
> > about allowing HELD error codes to be specified without a 
> > corresponding specification being required.
> >
> > 13) Section 11.5 Doesn't need to talk about the dereference 
> > protocol, and should only register one form of URI. I propose the 
> > This message is for the designated recipient only and may contain 
> > privileged, proprietary, or otherwise private information.
> > immediately and delete the original.  Any unauthorized use of this 
> > email is prohibited.

------------------------------------------------------------------------
------------------------
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]
------------------------------------------------------------------------------------------------
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]

---

From: "Mary Barnes" <[email-masked]>
Date: Fri, 18 Jan 2008 11:07:01 -0600

Hi James,

Thanks for the review and comments. My responses are embedded below
[MB].

Mary. 

-----Original Message-----
From: Winterbottom, James [mailto:[email-masked]] 
Sent: Monday, January 14, 2008 10:57 PM
To: Barnes, Mary (RICH2:AR00)
Cc: [email-masked]
Subject: More HELD-04 comments

Hi Mary,

1) There are quite a few dependencies on other IETF drafts. It would be
good to reduce this number if possible. Examples are provided in
specific comments below.
[MB] I can share your concern over normative references to documents
that are still drafts or documents that are listed in the references
that are not even referenced, however, I don't see the concern with
informational references (that add clarity), particularly for published
RFCs or other documents. [/MB]
	 
2) The last sentence of section 3 references SIP location conveyance,
while this is nice, it is not technically necessary.
[MB] Correct. It's not technically necessary, which is why it's an
Informational reference.  So, are you proposing we delete the reference
or the entire sentence?  I don't see the point in just deleting the
exact reference and leaving the sentence.[/MB] 

3) The last paragraph of section 4.3 should say that section 4.3.2 makes
recommendation to address this problem. When I read this the first time
it kind of left me hanging as to what to do.
[MB] Okay. I'll add that reference. [/MB]
 
4) The last paragraph of section 4.3.1 adds not real value and should be
removed. In addition there are distinct problems with this approach
particularly since HELD can deal with all of the geoshape types and
LLDP-MED and DHCP cannot. This also removes references 21 and 25.
[MB] This sentence was added as a result of WG discussion and consensus,
so I'd like more feedback on it. Also, these are just informational
references, so having them there should not cause any grief for this
document to progress. [/MB]

5) Section 5.3, should also add that the Location response is depends on
what the LIS is able to provide, not just what was requested. It is
perfectly valid, for example, for the Device to request civic location
but get back a location Uri set.
[MB] Agreed. In general, we need more content in this section even if it
re-iterates some material from the previous section on Location
response. [/MB]

6) Section 6.5 is incorrect. The LIS returns a locationUriSet which
consists of one or more locationURIs. The HELD specification doesn't
dictate what form these URI take, except to say that a define way to use
them to get location information needs to exist. This problem is
subsequently reflected in the examples. It is quite possible, for
example that the LIS will return a held: URI, a sip: URI, a sips: URI, a
pres; URI, and possibly in the future straight http: URI. The second as
currently written restricts HELD to returning only held: URIs and these
appear to be defined in multitude of ways.
[MB] Yes. This confusion comes out of the schema itself.  We should
really call this entire section "locationURISet" and describe that it is
a set of  "locationURI" elements and "expries" attributes. (This
confusion was carried over from the individual draft).  Also, this
impacts table 1, which should list the locationURISet, rather than just
locationURI. And, yes, I will clarify the URIs are of form anyURI.  And,
yes, the intent was to have flexibility in the definition of the held:
URI, but if folks don't think that is necessary, we can make more strict
and less flexible and remove extensibility altoghether. [/MB]

The last paragraph of section 6.5 introduces a dependency on the HELD
dereference draft. I suggest that this be removed.
[MB] It's an informational reference and I can see that it's not
necessary in this section, BUT see my comment below on section 11.5 as
to why it may be necessary for this document. [/MB] 

7) Section 6.5.1 applies to the entire locationUriSet. The last sentence
of the last paragraph here should be clarified. If a location URI is
dereferenced after the expiry time the LIS MUST return an error.
[MB] Correct. Per my comment above, I think we need to refer correctly
to the "locationURISet" parameter in these sections altogether.  I will
add that sentence above to that first paragraph, leaving the existing
second sentence for clarification.  [/MB].

8) I have already provided comments on the required schema changes
required to section 7.
[MB] Yep. An oversight on my part. [/MB]

9) Section Security considerations. I have an issue with referring to
the "Security Requirements for the Geopriv Location System",
draft-barnes-geopriv-lo-sec-01 as it currently stands. This because this
is an individual submission, and the security section of that document
is largely incomplete. Whilst I like the direction of Richard et al's
document, it is not complete enough for us to have as a normative
reference for HELD. The security section for the HELD document should
refer to RFC 3693 and RFC 3694. 
[MB] My understanding of the discussion we had in Vancouver (and meeting
minutes) was that we do want to reference the barnes document:
"Resolution: we need the normative reference to the security document."
Can you highlight the security aspects related to HELD that should be
explicitly referenced from RFC 3693/3694? I thought one of the
motivations for the barnes security draft was that those were just not
adequate. From the perspective of the protocl, I would think the
requirements in the L7-LCP document should be considered
comprehensive.[/MB]

10) Location URI example in section 10.2 is incorrect, see above and
previous post.
[MB] Yes, I will fix the second locationURI in that example. [/MB]

[MB] Okay. [/MB]

12) Section 11.4 Error code registry is only specification recommended,
why isn't this specification required? I am concerned about allowing
HELD error codes to be specified without a corresponding specification
being required.
[MB] I put down what I considered to be the minimal requirement. If the
WG wants specification required, that's fine. I had thought there might
be some cases where folks might use the error codes in an environment
and not necessarily need or want to register.  [/MB] 

13) Section 11.5 Doesn't need to talk about the dereference protocol,
and should only register one form of URI. I propose the
held://lis.example.com:2198/<something random in here> form.
[MB] My understanding of the general requirements and guidelines for the
URI schema registration (RFC 4395) is that you should list all the
protocols that can use the schema, so the reference is needed for this
document for that situation, so I don't think it hurts to leave it in
this document. Or, we need to consider defining the URI schema in a
separate document altogether (not an uncommon thing to do).  That's fine
if the group wants to restrict the URI to that single form. It seemed
useful to me to have more flexibility and extensibility (e.g., a LIS may
want to embed more than a single random token or more specific
information in the URI). If folks don't think that's necessary, I'll
remove. [/MB]

14) Section 13. I think that Tatham Oddie I think has also provided
comments and has agreed to provide a detailed technical review.
[MB] Can you send me a link any detailed document comments?  I did see
his one comment on the "IP Address Guidance thread", but didn't see any
detailed comments on the document itself, per se.  I don't have any
others in my mailbox.  And, yes, I will update the list once the folks
provide the detailed WGLC reviews. [/MB]

Cheers
James

---

From: "Mary Barnes" <[email-masked]>
Date: Fri, 18 Jan 2008 11:25:30 -0600

Hi Martin,

Thanks for reviewing the document and providing comments. My responses
are embedded below [MB].

Mary.  

-----Original Message-----
From: Thomson, Martin [mailto:[email-masked]] 
Sent: Tuesday, January 15, 2008 12:01 AM
To: Barnes, Mary (RICH2:AR00)
Cc: [email-masked]
Subject: [Geopriv] More and more HELD-04 comments

Hi Mary,

Section 4 - the introduction to this section would read easier if it
were at least 3 paragraphs.  There are at least three distinct concepts
here.

[MB] I can see the split you suggest in terms of the last two sentences
standing on their own in a paragraph. And, I'm assuming the other split
is to start the 2nd paragraph with the 3rd sentence: "The Device must
first discover..." If not, please let me know. [/MB]

Section 4.3.1 - You have a few too many commas in this section.  Have a
bit of a read and remove some.  For instance, "should provide the
address, of the LIS"
   - Use probable, not permissible where appropriate:
	s/VPN tunnel, the Device may receive inaccurate location
       /VPN tunnel, the Device might receive inaccurate location/x
   - When using lower case requirements words, finding an alternative
word helps avoid confusion:
      s/ may serve as a LIS/ could serve as a LIS/
   - I don't like the last paragraph of this section, but I wont fight
that hard.
[MB] I'll see if I can't remove commas - I added some because I found
the sentences difficult to parse or having multiple meanings if I didn't
have them. This means that perhaps they need rewording altogether. 
I see your point on the other, and I'll try to do that as appropriate.
[/MB] 

[MB] Yep. [/MB]

Section 6 - When you talk about the "PIDF-LO" parameter (check
capitalization on that too), it implies that there is an XML element
<PIDF-LO> or something similar.  Perhaps it would be better to refer to
the ``"presence" parameter (PIDF-LO)''.  This applies more to Section
6.6.
[MB] Okay. [/MB]

Section 6.5 - I have a number of problems with the URI.  Primarily, I
don't think that there is enough detail to implement a URI dereferencer.
I understand if you think that deferring that to held-dereference is OK,
but I agree with James in that HELD should not depend on the dereference
draft.  Instead, you only need define a URI that is similar to the HTTP
URL.  You could even reference RFC 2616, Section 3.2.2 and say that the
HELD URI is identical to the HTTP URL except for the following
exceptions:
 - The port is mandatory (since there is no default, you have to do
this)
 - There is no user:password component (although it would seem that
despite common usage, RFC 2616 doesn't permit this either; it's still
worth pointing out though, enough people _mis_use those fields) Noting
that the held: URI is used for the HTTP binding is sufficient.  Other
bindings can (and perhaps should) define their own URIs.

   held-URI      = "held" ":" held-hier-part [ "?" query ] [ "#"
fragment ]
   held-hier-part     = "//" held-authority path-abempty / path-absolute
   held-authority     = host ":" port
   ; All definitions taken directly from RFC 3986

[MB] By definition, there is enough detail, per the ABNF, to implement a
deferencer, so that's not the isse.  We actually need to include an
explicit schema in this doc if we want one, so we can't reference RFC
2616 and then say except, etc. )  The one I proposed is simpler than
others and similar to some others. But, per my response to James, if
folks don't see the need for flexibility or extensibility, we can make
far simpler. I am using RFC 3986 definitions except for the token and
extensibility aspects.  Are you suggesting that we use the fragment for
the "random token"? [/MB]

Section 6.5.1 - Regarding:
   If a Device dereferences the location URI after the XML
   Schema definition expiry time, it would be possible to get an
   entirely invalid location for that Device.
 I'd prefer the following, which is simpler and more definitive:
   If the location URI is dereferenced after the expiry time, the
   dereference MUST fail.
 I'm not 100% certain on the strength of the "MUST".  Certain regulatory
requirements make this a little shakey.
[MB] James made a similar comment. Yes, I agree to replace that sentence
with the definitive one.[/MB] 

Section 10 - a blank line after each example would make the whole
document easier to read.
[MB] Okay. [/MB]

Section 11.1.2 - needs to be deleted.  This is a hangup from the old
WSDL days.  I missed it then, but I'm reviewing the diff this time and
it leapt out at me.
[MB] Wonderful. I'll do that. [/MB]

> 4) The last paragraph of section 4.3.1 adds not real value and should 
> be removed. In addition there are distinct problems with this approach

> 5) Section 5.3, should also add that the Location response is depends 
> on what the LIS is able to provide, not just what was requested. It is

> example that the LIS will return a held: URI, a sip: URI, a sips: URI,

> a pres; URI, and possibly in the future straight http: URI. The second

> as currently written restricts HELD to returning only held: URIs and 
> these appear to be defined in multitude of ways.
> 
> sentence of the last paragraph here should be clarified. If a location

> URI is dereferenced after the expiry time the LIS MUST return an
error.
> document is largely incomplete. Whilst I like the direction of Richard

> et al's document, it is not complete enough for us to have as a 
> normative reference for HELD. The security section for the HELD 
> ----------------------------------------------------------------------
> ----
> ----------------------

> ----------------------------------------------------------------------
> ----
> ----------------------
> [mf2]
> 
> 
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Sun, 20 Jan 2008 18:31:43 -0600

Hi Mary,

I will break my responses up into single threads so they are easier to
follow.

Cheers
James

---

From: "Winterbottom, James" <[email-masked]>
Date: Sun, 20 Jan 2008 18:42:43 -0600

> 4) The last paragraph of section 4.3.1 adds not real value and should
be

> document to progress. [/MB]

[AJW] To be really clear, the last paragraph of section 4.3.1 says:

"It could also be useful for a VPN device to serve as a LIS for other
   location configuration options such as Dynamic Host Configuration
   Protocol (DHCP)[21] or Link Layer Discovery Protocol - Media Endpoint
   Discovery (LLDP-MED) [25].  VPN devices that serve as a LIS may
   acquire their own location using HELD."

I read this as saying, that the VPN device can get its location using
HELD, and then distribute this to terminals inside the VPN using DHCP or
LLDP-MED. 

This is not a good idea, particularly if locations are going to be
provided a geodetic shapes. As currently defined, the only shapes I can
represent in DHCP and LLDP-MED is a point, which require my HELD
intermediary to convert location from one form to another. I am strongly
opposed this proposal as it results in the loss of information with no
arguments being presented as to why it should be done. According to
phone BCP DHCP, LLDP-MED and HELD must all be implemented by
end-devices, so there is no benefit to these devices of the VPN device
performing this conversion.

Cheers
James

---

From: "Winterbottom, James" <[email-masked]>
Date: Sun, 20 Jan 2008 20:01:08 -0600

> draft-barnes-geopriv-lo-sec-01 as it currently stands. This because
this

> requirements in the L7-LCP document should be considered

[AJW] I was under the impression, and maybe I am wrong, that the LO-Sec
draft is really trying build on existing work and try and describe more
strongly how a location object needs to be secured within Geopriv as a
whole. My issue is that this isn't a working group item, and the
security section on which we would like to depend is largely left as a
big TBD, so depending on this document before HELD can be published is
not conducive toward having HELD out soon.

I agree entirely with your last point however, that if there are
specific security requirements applicable to an L7 LCP, then these
should be captured in the L7-LCP reqs and ps document. The HELD
specification can then say how it meets those specific requirements.

RFCs 3693 and 3694 don't talk about LCPs specifically, as the general
concept of an LCP has been evolved a lot since these documents were
originally created. Section 4.1 of RFC 3694 does describe general
threats against a location protocol which at a high-level are the same
for an LCP.

I think that this general issue needs closure fairly quickly however if
want to minimize delays to HELD.

Cheers
James

---

From: Ted Hardie <[email-masked]>
Date: Mon, 21 Jan 2008 09:21:33 -0800

At 6:42 PM -0600 1/20/08, Winterbottom, James wrote:
>provided a geodetic shapes.

Would it be useful to add this data to the paragraph, rather than
removing the paragraph?  That is "VPN devices that serve
as a LIS may acquire their own location using configuration,
HELD, or other methods.  If the location the LIS is provided is a point, there
is, however, a risk of information loss in cases where the devices
they serve are not at that same point"?

I think the aim in 4.3 is to try to give folks a general understanding
of how NATs, VPNs,  and Location information servers will interact.
Adding data which clarifies the interaction seems more useful to me than
cutting it;  someone will come up with the idea of co-locating
a VPN and LIS without this working group putting the idea in their
head, and it would be better if the upsides and downsides were
clear.
	my two cents,
				Ted

>As currently defined, the only shapes I can

---

From: "Stark, Barbara" <[email-masked]>
Date: Mon, 21 Jan 2008 12:30:14 -0500

It's not just a problem related to shapes. Converting a civic PIDF-LO to
DHCP or LLDP-MED format would also lose info. In a civic PIDF-LO, it's
possible to convey much more information than it is in the other two.
Barbara

-----Original Message-----
From: Ted Hardie [mailto:[email-masked]] 
Sent: Monday, January 21, 2008 12:22 PM
To: Winterbottom, James; Mary Barnes
Cc: [email-masked]
Subject: Re: [Geopriv] HELD-04 comments: VPN device serving as a LIS

HELD, or other methods.  If the location the LIS is provided is a point,
there

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621

---

From: Ted Hardie <[email-masked]>
Date: Mon, 21 Jan 2008 09:39:50 -0800

>possible to convey much more information than it is in the other two.

Can you draft language for 4.3 that captures that?
			regards,
				Ted

---

From: "Stark, Barbara" <[email-masked]>
Date: Mon, 21 Jan 2008 13:17:48 -0500

Perhaps if we change the last paragraph of 4.3.1 to:

   VPN devices that serve as a LIS may acquire their own location using
HELD, or another configuration options such as Dynamic Host
Configuration Protocol (DHCP)[21] or Link Layer Discovery Protocol -
Media Endpoint Discovery (LLDP-MED) [25]. When acting as a LIS, however,
it is undesirable for a device that receives or has location in a
PIDF-LO format, to convert that PIDF-LO into a format that conveys less
information, in order to send the location to other devices.

I think this covers both the shape and civic complaint, as well as loss
of other information.
Barbara

-----Original Message-----
From: Ted Hardie [mailto:[email-masked]] 
Sent: Monday, January 21, 2008 12:40 PM
To: Stark, Barbara; Winterbottom, James; Mary Barnes
Cc: [email-masked]
Subject: RE: [Geopriv] HELD-04 comments: VPN device serving as a LIS

>>performing this conversion.
-
>-------------------------
-
>-------------------------
>>[mf2]
>>
>>
>>
>The information transmitted is intended only for the person or entity
to which it is addressed and may contain confidential, proprietary,
and/or privileged material. Any review, retransmission, dissemination or
other use of, or taking of any action in reliance upon this information
by persons or entities other than the intended recipient is prohibited.
If you received this in error, please contact the sender and delete the
material from all computers. GA621

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623

---

From: Ted Hardie <[email-masked]>
Date: Mon, 21 Jan 2008 10:26:59 -0800

>I think this covers both the shape and civic complaint, as well as loss

I think this looks good; James, does it cover the issue from your perspective?
			
					Ted

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 21 Jan 2008 14:07:25 -0600

My concern is still that this is a HELD specification, and that we do
not need to, and in my opinion should not be discussing, how one might
acquire location using HELD and then convert it another LCP format. LCPs
are orthogonal, you use one or the other. This paragraph blends them and
it is still unclear to me why you would do it except to accommodate end
points that don't comply with other IETF specifications.

Cheers
James

> Sent: Tuesday, 22 January 2008 5:27 AM
> >>It's not just a problem related to shapes. Converting a civic
PIDF-LO
> >to
> >>>HELD, and then distribute this to terminals inside the VPN using
DHCP
> >>or
to
> which it is addressed and may contain confidential, proprietary,
and/or
> privileged material. Any review, retransmission, dissemination or
other
> use of, or taking of any action in reliance upon this information by
> persons or entities other than the intended recipient is prohibited.
If
> you received this in error, please contact the sender and delete the
> material from all computers. GA623
>