Subject: Re: [Ecrit] Service URN IANA Policy

From: "Hannes Tschofenig" <[email-masked]>
Date: Thu, 1 Oct 2009 10:20:13 +0300

Hi Ted, 

>Howdy,
>
>I don't have any problems with this allocation policy, but I 
>see two things in the draft that should probably change.  The 
>appointment should be by the IESG, not the RAI area director 
>or directors; this is the traditional appointment mechanism 
>and it allows other ADs to contribute, even if RAI leads.  For 
>services that are not SOS-related, other areas may have 
>significant input. 

Sounds reasonable. 

 Second, some text in the document that 
>describes the conditions under which new entries are approved 
>or denied is very useful, as it guides the later incumbents in 
>the role.  In the URI space, for example, there are two 
>strains of thought about minting new schemes:  one is that it 
>should be restricted to cases which absolutely cannot be met 
>by an existing scheme; the second is that the schemes will be 
>minted anyway and that registration largely serves to avoid 
>interoperability problems.
>Having the working group provide general guidance on this 
>point is very useful, in my opinion.

Sounds also useful. 

Andrea + Henning: Could you make these changes? 

Ciao
Hannes

>
>My two cents,
>
>Ted
>
>On Wed, Sep 30, 2009 at 6:36 AM, Tschofenig, Hannes (NSN - 
>FI/Espoo) <[email-masked]> wrote:
>> Hi all,
>>
>> we discussed the need to change the IANA allocation policy for the 
>> definition of new top-level services within this working group a few 
>> times. With the 
>> http://tools.ietf.org/html/draft-forte-ecrit-service-urn-policy-00
>> proposal Henning and Andrea have describe the modification. We would 
>> change the allocation policy of top-level services from "Standards 
>> Action" to "Expert Review".
>>
>> The policy for assigning labels to sub-services is left 
>unchanged and 
>> may differ for each top-level service designation and must 
>be defined 
>> by the document describing the top-level service. For the 
>Service URN 
>> RFC (RFC 5031) two sub-services are defined, namely 'sos' 
>and 'counseling'.
>> The policy for adding sub-services to the 'sos' and the 'counseling'
>> services, as defined in RFC 5031, is "Expert Review".
>>
>> In order to progress draft-forte-ecrit-service-urn-policy-00 
>we would 
>> like to know whether someone has problems with this 
>allocation policy 
>> change.
>>
>> Ciao
>> Hannes & Marc
>> _______________________________________________
>> Ecrit mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ecrit
>>
>_______________________________________________
>Ecrit mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ecrit
>

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 01 Oct 2009 16:54:51 -0500

Chairs

With respect to
http://www.ietf.org/internet-drafts/draft-polk-ecrit-lost-geocoding-00.txt
and forte's draft, I assume they keep -ecrit- in their filename, and 
are individually submitted to the RFC-Editor when the author feels 
they are ready?

I don't mean this to be nefarious sounding, as I plan on working 
within the WG until this doc has consensus of at least those that 
care about it (knowing that because this isn't going to be a WG item, 
the whole WG doesn't necessarily need to have reached consensus.

Is this the general plan of action for these types of IDs?

Of should each of these IDs have -ecrit- removed from the filenames 
because there is no hope of them ever being WG items now?

Looking for clarification and guidance

James

At 08:36 AM 9/30/2009, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
>The policy for assigning labels to sub-services is left unchanged and
>may differ for each top-level service designation and must be defined by
>the document describing the top-level service. For the Service URN RFC
>(RFC 5031) two sub-services are defined, namely 'sos' and 'counseling'.
>In order to progress draft-forte-ecrit-service-urn-policy-00 we would
>like to know whether someone has problems with this allocation policy
>change.
>
>Ciao
>Hannes & Marc

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Fri, 2 Oct 2009 09:31:52 +0300

Hi James, 

>and forte's draft, I assume they keep -ecrit- in their 
>filename, and are individually submitted to the RFC-Editor 
>when the author feels they are ready?

Andrea has worked on a few documents, namely:
http://tools.ietf.org/html/draft-forte-ecrit-service-urn-policy
http://tools.ietf.org/html/draft-forte-ecrit-service-classification
http://tools.ietf.org/html/draft-forte-ecrit-lost-extensions

So, which one do you mean? 

Regarding your document draft-polk-ecrit-lost-geocoding-00.txt

>From what I could hear at the last IETF meeting (via my remote
participation) a couple of folks had suggestions regarding your document and
they roughly proposed the following approach:

* Define a protocol for geocoding (not based on LoST)
* Define a discovery mechanism (based on LoST) for discovering the server
that does the geocoding

Regarding the overall approach of working on non-emergency services I have
not spoken to Cullen/Robert about this particular document. I plan to post a
separate mail about our very recent chat with them. 

>
>I don't mean this to be nefarious sounding, as I plan on 
>working within the WG until this doc has consensus of at least 
>those that care about it (knowing that because this isn't 
>going to be a WG item, the whole WG doesn't necessarily need 
>to have reached consensus.
>
>Of should each of these IDs have -ecrit- removed from the 
>filenames because there is no hope of them ever being WG items now?
>

Thanks for raising this issue. 

Ciao
Hannes

>>may differ for each top-level service designation and must be defined 
>>by the document describing the top-level service. For the Service URN 
>>RFC (RFC 5031) two sub-services are defined, namely 'sos' and 
>'counseling'.

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 05 Oct 2009 17:21:21 -0500

>So, which one do you mean?

I meant each of them (I think)

>* Define a discovery mechanism (based on LoST) for discovering the server

There were these two suggestions, but there were others as well - 
notably from Andy, who said we need to be conscious of the user 
experience in making this solution have to have more round-trips (or 
contact more servers) than is necessary - when the information might 
(I'd argue probably) be in/at the first server contacted (i.e., the 
first LoST server) -- which is where the initial -00 was thinking.

My next rev plans on addressing what Andy offered.

Additionally, when looking at the two bullets above, if one looks at 
them in a reverse order to which they are currently in, that makes 
for a two-step solution.  That's fair, but why do a solution in two 
steps when one can accomplish this in one step?  I believe the best 
solution is to do both what you suggested and what I'm suggesting above.

In other words, use LoST to ask for geocoding. If that server knows 
the answer, it gives it; if it doesn't know the answer, but knows a 
server that can solve the geocoding query, it gives the URI of that 
server (which is more like what LoST is defined to do now).

Also, there was a suggestion by Brian that wanted me to move the 
geocoding URN underneath a new top level URN called 
"transformation".  I've been thinking about this, feeling it probably 
is a good idea, though I haven't spent enough time on this rev to 
figure out exactly how I'm going to write it in.

>separate mail about our very recent chat with them.

look forward to that update!

>Thanks for raising this issue.

np -- always here to help

;-)

James