Subject: [Geopriv] Editor's proposal: resolving held: URI concerns

From: "Mary Barnes" <[email-masked]>
Date: Mon, 23 Jun 2008 10:20:02 -0500

I realize some of my responses to the HELD threads have been slightly
inconsistent and that's because we will have extreme difficulties in
resolving the current concerns given the current document structure. I
do agree that moving the schema definition just moves the problems, but
at this point, it seems very clear to me that these problems are not at
all HELD protocol problems, but problems associated with a URI provided
by LIS discovery and a URI that's used by another protocol (or use of
HELD that's not specified in the current HELD document) to
derereference. Brian's suggestion to add a tag helps somewhat, but I'd
like to propose something slightly different:  

-   I propose that we define two URI schemas and that the two schemas be
defined in the LIS discovery and dereference documents respectively. I
believe this is the most reasonable approach because it appropriately
moves the definitions, constraints and security  into the two documents
that really define the context for the definition and usages of those
URIs. Indeed there's already most of the appropriate scoping in LIS
discovery at this point AFAIK. 

The side effects of this are the following:
1. Distinguishes the URIs that represent a LIS and the URI that
represents a reference to a specific location. I believe the security
requirements for these two URIs (or usage of the same URI if folks want
to go that route) are different.

2. HELD's usage of the two URIs is also different, so it clarifies that
(this is the point raised by both the sec-dir and gen-art reviews).

3. Simplifies the current HELD document.

4. Decouples the dereference of a held: URI from HELD, which is
consistent with the definition and usage of the URI in the protocol,
which does not have to be a held: URI

5. As it is now, either way (i.e., keep URI definition(s) in HELD), I
believe we need a normative reference to the dereference document.
Noting that we already have a normative reference to LIS discovery that
is less mature than HELD (in terms of WG progress) and dereference,
which is even less mature.  I don't believe this would inordinately hold
up HELD, as you really need a baseline dereference protocol defined to
even make use of a lbyr. 

If we don't define two separate URIs, I propose we define the URI in a
separate document, documenting LIS discovery and dereference as two
unique users of the URI and defining the tag that Brian suggests as part
of the URI to resolve my concern about debugging.  I believe this still
keeps HELD much cleaner and it would be far easier to properly scope as
it would move some chunks of text that aren't really specific to the
HELD protocol into more tightly scoped documents.

Also, a logistical note, I am out of the office starting Friday morning
(June 27th) through July 4th (the following Friday). I lose Internet
access Sunday morning and won't regain it until the 4th. It is also
likely that I will not be able to get to the document on Friday or
Saturday nites (I'm driving all day Friday and Saturday through in the
flatlands of West Texas and Eastern New Mexico).  So, it would be
really, really good if we could converge early this week.  I can't
guarantee that I can get the document updated unless we have full
agreement on the way forward by COB Wednesday as I anticipate at least a
full 8 hours of careful editting. Otherwise edits will have to wait till
the week of July 7th. 

Regards,
Mary

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 23 Jun 2008 21:50:55 +0300

Hi Mary,

I never really shared the concerns that some people had on this subject. 
I don't care too much about using one or 2 URI schemes.

If you get some text out there I will reviekw it.

Ciao
Hannes

Mary Barnes wrote:
> do agree that moving the schema definition just moves the problems, 
> but at this point, it seems very clear to me that these problems are 
> not at all HELD protocol problems, but problems associated with a URI 
> provided by LIS discovery and a URI that's used by another protocol 
> (or use of HELD that's not specified in the current HELD document) to 
> -   I propose that we define two URI schemas and that the two schemas 
> be defined in the LIS discovery and dereference documents 
> respectively. I believe this is the most reasonable approach because 
> it appropriately moves the definitions, constraints and security  into 
> the two documents that really define the context for the definition 
> and usages of those URIs. Indeed there's already most of the 
> appropriate scoping in LIS discovery at this point AFAIK.
>
> requirements for these two URIs (or usage of the same URI if folks 
> want to go that route) are different.
>
> 2. HELD's usage of the two URIs is also different, so it clarifies 
> that (this is the point raised by both the sec-dir and gen-art reviews).
>
> Noting that we already have a normative reference to LIS discovery 
> that is less mature than HELD (in terms of WG progress) and 
> dereference, which is even less mature.  I don't believe this would 
> inordinately hold up HELD, as you really need a baseline dereference 
> protocol defined to even make use of a lbyr.
>
> unique users of the URI and defining the tag that Brian suggests as 
> part of the URI to resolve my concern about debugging.  I believe this 
> still keeps HELD much cleaner and it would be far easier to properly 
> scope as it would move some chunks of text that aren't really specific 
> to the HELD protocol into more tightly scoped documents.
>
> Also, a logistical note, I am out of the office starting Friday 
> morning (June 27th) through July 4th (the following Friday). I lose 
> Internet access Sunday morning and won't regain it until the 4th. It 
> is also likely that I will not be able to get to the document on 
> Friday or Saturday nites (I'm driving all day Friday and Saturday 
> through in the flatlands of West Texas and Eastern New Mexico).  So, 
> it would be really, really good if we could converge early this week.  
> I can't guarantee that I can get the document updated unless we have 
> full agreement on the way forward by COB Wednesday as I anticipate at 
> least a full 8 hours of careful editting. Otherwise edits will have to 
> wait till the week of July 7th.
>
> Regards,
> Mary
>
>
> ------------------------------------------------------------------------
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 23 Jun 2008 21:51:02 +0300

Hi Mary,

If you get some text out there I will review it.

Ciao
Hannes

---

From: "Mary Barnes" <[email-masked]>
Date: Wed, 25 Jun 2008 12:28:16 -0500

I'm going to give this another shot as based on a chat yesterday with
James W., I think there's been alot of crosstalk. And I'm happy to see
that seems to have stopped for now. 
 
There were two neutral responses to this proposal and then I believe
just 4 of us debating things in circles.  
 
Based on gen-art and sec-dir feedback, there were concerns raised about
the two URIs: URI from LIS Discovery and URI in the locationURI field in
a locationResponse message.
I think it's really important to note that these reviews were entirely
independent since I realized yesterday that gen-art comments had not
gone to the WG mailing list.
 
 In terms of the content of the document, the concerns raised relate
primarily to the following sections:
- 4.2 Overview of Location by Reference 
- 6.5 (.1) Definition of locationURI parameter  (where we had previously
had WG discussion and a reference to the dereference document (removed
as a result of 1st WGLC))
- 8: HELDS: URI definition.   Here is where we define the two uses of
the URI.  
 
In order to resolve these concerns, I'm proposing the following changes:
 
1) Differentiate the two URIs by either of the following:
1a) Define two sets of schemas (recalling the past agreement that we
needed to define both held:/helds:)
1b) Add a parameter to the URI schema.   
 
Note: I do not believe we have the option of deferring this distinction
in terms of only defining a tag/parm for dereference because the
ambiguity exists in the base-HELD document and unless we remove the
location by reference altogether (my past silly suggestion), we must
resolve the ambiguity in base-HELD.
 
My preference is for 1a, as I think it makes the distinction clearer. I
believe the URI schema returned from LIS Discovery should go in that
document. That makes base-HELD entirely neutral on the form of the LIS
Discovery URI (as it currently is).  I think it's entirely appropriate
for the URI schema for the location by reference to go in base-HELD.
So, overall, this change does not have a huge impact on base-HELD other
than clarifying the text as appropriate in the above sections. 
 
2)  To resolve the concerns raised in section 6.5,  I believe we need to
add back in the reference to the dereference document.   The decision to
be made here is whether this needs to be an informative reference (what
we had in the past) or normative.  I think we could make this
informative, since base-HELD does not do the dereference itself and I
believe we can properly scope the security around the passing of the
locationURI in the response and the implications of the expiry,
mobility, etc. in the base-HELD without having a normative reference to
the deference document. With base-HELD, we do not provide the capability
to dereference, thus I think it's entirely appropriate that we defer the
security details around the dereferencing to the deref document.
 
I honestly think this is all we've really been debating this week.  
 
I will work on the edits done that aren't directly related to these
changes before I head to the hills Friday morning. If we can quickly
agree the points above, I may be able to make the necessary changes.
However, I cannot guarantee because very careful editting is required at
this stage and I think it's more important to get it right than get it
done quickly. But, I will commit to getting the changes done the week of
the 7th and absolutely before the draft deadline for IETF-72 IFF we have
resolution on the issue before the 7th.  I don't think this dramatically
impacts the progression because we need re-reviews from the WG, Ben
(gen-art) and Ekr (sec-dir) review before we can forward to the IESG. 
 
Regards,
Mary. 

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Barnes, Mary (RICH2:AR00)
Sent: Monday, June 23, 2008 10:20 AM
To: GEOPRIV
Subject: [Geopriv] Editor's proposal: resolving held: URI concerns

Regards, 
Mary

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 25 Jun 2008 21:46:35 -0500

Hi Mary,

Thanks for putting this summary together.

I am happy to proceed as you suggest below.

Cheers

James

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Mary Barnes
Sent: Thursday, 26 June 2008 3:28 AM
To: GEOPRIV
Subject: [Geopriv] Round 2: Editor's proposal: resolving held: URI
concerns

Regards,

Mary. 

Regards, 
Mary 

------------------------------------------------------------------------------------------------
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://www.ietf.org/mailman/listinfo/geopriv

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 25 Jun 2008 22:24:00 -0500

As a way to make progress, I’m happy with this approach.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Winterbottom, James
Sent: Thursday, 26 June 2008 12:47 PM
To: Mary Barnes; GEOPRIV
Subject: Re: [Geopriv] Round 2: Editor's proposal: resolving held: URIconcerns

Hi Mary,

Cheers

James

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mary Barnes
Sent: Thursday, 26 June 2008 3:28 AM
To: GEOPRIV
Subject: [Geopriv] Round 2: Editor's proposal: resolving held: URI concerns

I'm going to give this another shot as based on a chat yesterday with James W., I think there's been alot of crosstalk. And I'm happy to see that seems to have stopped for now. 

There were two neutral responses to this proposal and then I believe just 4 of us debating things in circles.  

Based on gen-art and sec-dir feedback, there were concerns raised about the two URIs: URI from LIS Discovery and URI in the locationURI field in a locationResponse message.

I think it's really important to note that these reviews were entirely independent since I realized yesterday that gen-art comments had not gone to the WG mailing list.

 In terms of the content of the document, the concerns raised relate primarily to the following sections:

- 6.5 (.1) Definition of locationURI parameter  (where we had previously had WG discussion and a reference to the dereference document (removed as a result of 1st WGLC))

- 8: HELDS: URI definition.   Here is where we define the two uses of the URI.  

1a) Define two sets of schemas (recalling the past agreement that we needed to define both held:/helds:)

Note: I do not believe we have the option of deferring this distinction in terms of only defining a tag/parm for dereference because the ambiguity exists in the base-HELD document and unless we remove the location by reference altogether (my past silly suggestion), we must resolve the ambiguity in base-HELD.

My preference is for 1a, as I think it makes the distinction clearer. I believe the URI schema returned from LIS Discovery should go in that document. That makes base-HELD entirely neutral on the form of the LIS Discovery URI (as it currently is).  I think it's entirely appropriate for the URI schema for the location by reference to go in base-HELD.  So, overall, this change does not have a huge impact on base-HELD other than clarifying the text as appropriate in the above sections. 

2)  To resolve the concerns raised in section 6.5,  I believe we need to add back in the reference to the dereference document.   The decision to be made here is whether this needs to be an informative reference (what we had in the past) or normative.  I think we could make this informative, since base-HELD does not do the dereference itself and I believe we can properly scope the security around the passing of the locationURI in the response and the implications of the expiry, mobility, etc. in the base-HELD without having a normative reference to the deference document. With base-HELD, we do not provide the capability to dereference, thus I think it's entirely appropriate that we defer the security details around the dereferencing to the deref document.

I will work on the edits done that aren't directly related to these changes before I head to the hills Friday morning. If we can quickly agree the points above, I may be able to make the necessary changes. However, I cannot guarantee because very careful editting is required at this stage and I think it's more important to get it right than get it done quickly. But, I will commit to getting the changes done the week of the 7th and absolutely before the draft deadline for IETF-72 IFF we have resolution on the issue before the 7th.  I don't think this dramatically impacts the progression because we need re-reviews from the WG, Ben (gen-art) and Ekr (sec-dir) review before we can forward to the IESG. 

Regards,

Mary. 

From: [email-masked] [mailto:[email-masked]] On Behalf Of Barnes, Mary (RICH2:AR00)
Sent: Monday, June 23, 2008 10:20 AM
To: GEOPRIV
Subject: [Geopriv] Editor's proposal: resolving held: URI concerns

I realize some of my responses to the HELD threads have been slightly inconsistent and that's because we will have extreme difficulties in resolving the current concerns given the current document structure. I do agree that moving the schema definition just moves the problems, but at this point, it seems very clear to me that these problems are not at all HELD protocol problems, but problems associated with a URI provided by LIS discovery and a URI that's used by another protocol (or use of HELD that's not specified in the current HELD document) to derereference. Brian's suggestion to add a tag helps somewhat, but I'd like to propose something slightly different:  

-   I propose that we define two URI schemas and that the two schemas be defined in the LIS discovery and dereference documents respectively. I believe this is the most reasonable approach because it appropriately moves the definitions, constraints and security  into the two documents that really define the context for the definition and usages of those URIs. Indeed there's already most of the appropriate scoping in LIS discovery at this point AFAIK. 

The side effects of this are the following: 
1. Distinguishes the URIs that represent a LIS and the URI that represents a reference to a specific location. I believe the security requirements for these two URIs (or usage of the same URI if folks want to go that route) are different.

2. HELD's usage of the two URIs is also different, so it clarifies that (this is the point raised by both the sec-dir and gen-art reviews).

4. Decouples the dereference of a held: URI from HELD, which is consistent with the definition and usage of the URI in the protocol, which does not have to be a held: URI

5. As it is now, either way (i.e., keep URI definition(s) in HELD), I believe we need a normative reference to the dereference document. Noting that we already have a normative reference to LIS discovery that is less mature than HELD (in terms of WG progress) and dereference, which is even less mature.  I don't believe this would inordinately hold up HELD, as you really need a baseline dereference protocol defined to even make use of a lbyr. 

If we don't define two separate URIs, I propose we define the URI in a separate document, documenting LIS discovery and dereference as two unique users of the URI and defining the tag that Brian suggests as part of the URI to resolve my concern about debugging.  I believe this still keeps HELD much cleaner and it would be far easier to properly scope as it would move some chunks of text that aren't really specific to the HELD protocol into more tightly scoped documents.

Also, a logistical note, I am out of the office starting Friday morning (June 27th) through July 4th (the following Friday). I lose Internet access Sunday morning and won't regain it until the 4th. It is also likely that I will not be able to get to the document on Friday or Saturday nites (I'm driving all day Friday and Saturday through in the flatlands of West Texas and Eastern New Mexico).  So, it would be really, really good if we could converge early this week.  I can't guarantee that I can get the document updated unless we have full agreement on the way forward by COB Wednesday as I anticipate at least a full 8 hours of careful editting. Otherwise edits will have to wait till the week of July 7th. 

Regards, 
Mary

---

From: Richard Barnes <[email-masked]>
Date: Thu, 26 Jun 2008 10:32:10 -0400

Mary,

That plan looks good to me.

--Richard

Mary Barnes wrote:
> *From:* [email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Barnes, Mary (RICH2:AR00)
> *Sent:* Monday, June 23, 2008 10:20 AM
> *To:* GEOPRIV
> *Subject:* [Geopriv] Editor's proposal: resolving held: URI concerns
>

---

From: "Mary Barnes" <[email-masked]>
Date: Thu, 26 Jun 2008 13:06:15 -0500

Thanks guys! We have gotten feedback and agreement from the primary
folks involved in the debate. And, Martin, just to clarify, you're also
okay with adding that URI schema registration in the LIS Discovery
document?  
 
As mentioned, I will try to get the updates completed ASAP, but I am in
the mode where it's less than 24 hours before I hit the road, so unless
I get some quality time on Friday/Saturday evening or Sunday morning, I
may not be able to get the doc out before the following weekend.
 
Thanks,
Mary. 

From: Thomson, Martin [mailto:[email-masked]] 
Sent: Wednesday, June 25, 2008 10:24 PM
To: Winterbottom, James; Barnes, Mary (RICH2:AR00); GEOPRIV
Subject: RE: [Geopriv] Round 2: Editor's proposal: resolving held:
URIconcerns

As a way to make progress, I'm happy with this approach.

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Winterbottom, James
Sent: Thursday, 26 June 2008 12:47 PM
To: Mary Barnes; GEOPRIV
Subject: Re: [Geopriv] Round 2: Editor's proposal: resolving held:
URIconcerns

Hi Mary,

Cheers

James

Regards,

Mary. 

Regards, 
Mary 

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

------------------------
------------------------

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 26 Jun 2008 18:38:24 -0500

Hi Mary,

I can simply cut/paste the text from HELD into discovery.  I’ll make the change at the same time as my proposed changes (which I haven’t received any feedback on, except for Hannes’ brief note).

I’ll make sure that this gets done before the submission deadline, with or without feedback from the WG.  But agreement would be ideal: http://www.ietf.org/mail-archive/web/geopriv/current/msg05777.html

Thanks,

Martin

From: Mary Barnes [mailto:[email-masked]] 
Sent: Friday, 27 June 2008 4:06 AM
To: Thomson, Martin; Winterbottom, James; GEOPRIV
Subject: RE: [Geopriv] Round 2: Editor's proposal: resolving held: URIconcerns

Thanks guys! We have gotten feedback and agreement from the primary folks involved in the debate. And, Martin, just to clarify, you're also okay with adding that URI schema registration in the LIS Discovery document?  

As mentioned, I will try to get the updates completed ASAP, but I am in the mode where it's less than 24 hours before I hit the road, so unless I get some quality time on Friday/Saturday evening or Sunday morning, I may not be able to get the doc out before the following weekend.

Thanks,

Mary. 

From: Thomson, Martin [mailto:[email-masked]] 
Sent: Wednesday, June 25, 2008 10:24 PM
To: Winterbottom, James; Barnes, Mary (RICH2:AR00); GEOPRIV
Subject: RE: [Geopriv] Round 2: Editor's proposal: resolving held: URIconcerns

Hi Mary,

Cheers

James

Regards,

Mary. 

Regards, 
Mary