Re: [Ecrit] RFC 5031bis - Service URNs

["Tschofenig, Hannes (NSN - FI/Espoo)" <[e-mail]>]

Keith, 

Are you saying that the current allocation policy is fine for you? 

Did you notice that we ran into problems with LoST usage for
non-emergency services with the current allocation policy? 

There is no reason to have the same allocation policy for top-level
services as for sub-services. It just depends on the semantic of the
sub-service to decide what would be reasonable todo. 

Ciao
Hannes
 
>-----Original Message-----
>From: ext DRAGE, Keith (Keith) [mailto:[e-mail]] 
>Sent: 04 December, 2008 02:43
>To: Ted Hardie; Tschofenig, Hannes (NSN - FI/Espoo); ext Richard Barnes
>Cc: ECRIT
>Subject: RE: [Ecrit] RFC 5031bis - Service URNs
>
>I would like to keep sub-services at the same strength of 
>review as the top level. For the existing top-levels that 
>requires no change to keep it at specification required.
>
>Keith
>
>> -----Original Message-----
>> From: Ted Hardie [mailto:[e-mail]]
>> Sent: Wednesday, December 03, 2008 5:56 PM
>> To: DRAGE, Keith (Keith); Tschofenig, Hannes (NSN - FI/Espoo); ext 
>> Richard Barnes
>> Cc: ECRIT
>> Subject: Re: [Ecrit] RFC 5031bis - Service URNs
>> 
>> At 6:43 AM -0800 12/3/08, DRAGE, Keith (Keith) wrote:
>> >Well I must admit I looked quickly and read something different and 
>> >wrongly.
>> >
>> >If I was starting from scratch, I think I would write
>> "standards track"
>> >for the subservices of sos, but I cannot point to any
>> problems with the
>> >existing strategy, so on that basis there is no need to change it.
>> >
>> >The main point I was making anyway is that we must not have a lower 
>> >level for "sos" and that we do need clear guidance to stop people 
>> >registering urns where there are more appropriate places to put 
>> >information other than a URI.
>> >
>> >Keith
>> 
>> I'm not sure what "lower level for 'sos'" means, exactly, but I 
>> believe using "specification required" for top-level and 
>expert review 
>> for those
>> under sos is reasonable.    The Designated Expert for 
>> "specification required"
>> may or may not be the same as for "sos".
>> 
>> 				Ted
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> > > -----Original Message-----
>> >> From: Tschofenig, Hannes (NSN - FI/Espoo) 
>> >> [mailto:[e-mail]]
>> >> Sent: Wednesday, December 03, 2008 2:36 PM
>> >> To: ext Richard Barnes; DRAGE, Keith (Keith)
>> >> Cc: ECRIT
>> >> Subject: RE: [Ecrit] RFC 5031bis - Service URNs
>> >>
>> >> This is not what RFC 5031 says. 
>> >>
>> >> >-----Original Message-----
>> >> >From: ext Richard Barnes [mailto:[e-mail]]
>> >> >Sent: 03 December, 2008 15:48
>> >> >To: DRAGE, Keith (Keith)
>> >> >Cc: Tschofenig, Hannes (NSN - FI/Espoo); ECRIT
>> >> >Subject: Re: [Ecrit] RFC 5031bis - Service URNs
>> >> >
>> >> >Keith,
>> >> >
>> >> >So to be clear, under your proposal, I would need IETF review to 
>> >> >register "urn:service:sos.foo", but perhaps less review
>> to register
>> >> >"urn:service:foo"?
>> >> >
>> >> >If that's right, this plan makes sense to me.  IETF gets to
>> >> manage the
>> >> >"urn:service:sos" heirarchy, but others could go through
>> with less
>> >> >review.  Definitely agree that more guidance is necessary on
>> >> what OK to
>> >> >go under "urn:service:".
>> >> >
>> >> >--Richard
>> >> >
>> >> >
>> >> >
>> >> >DRAGE, Keith (Keith) wrote:
>> >> >> Does this apply only for top level?
>> >> >>
>> >> >> What I believe we should retain is that any sub-service
>> >> >under the "sos"
>> >> >> top-level should be standards track. I believe that we
>> need IETF
>> >> >> review of those to ensure that they really should be
>> classed as an
>> >> >> emergency situation and not something else.
>> >> >>
>> >> >> If we relax the rules for new top-level identifiers, I
>> >> believe we do
>> >> >> need to provide more guidance on what is a valid service
>> >> urn value,
>> >> >> and what is not (and therefore should use some other
>> >> >construct in SIP
>> >> >> or other protocol).
>> >> >>
>> >> >> regards
>> >> >>
>> >> >> Keith
>> >> >> 
>> >> >>
>> >> >>> -----Original Message-----
>> >> >>> From: [e-mail]
>> [mailto:[e-mail]] On
>> >> >>> Behalf Of Tschofenig, Hannes (NSN - FI/Espoo)
>> >> >>> Sent: Wednesday, December 03, 2008 7:45 AM
>> >> >>> To: ECRIT
>> >> >>> Subject: [Ecrit] RFC 5031bis - Service URNs
>> >> >>>
>> >> >>> At the IETF#73 ECRIT meeting we spoke about producing a RFC
>> >> >5031bis.
>> >> >>>
>> >> >>> The problem is that the current document demands a
>> >> Standards Track
>> >> >>> document for allocating a new top-level top-level
>> service labels.
>> >> >>>
>> >> >>> This turned out to make our own work more difficult.
>> >> >>>
>> >> >>> During the meeting I suggested the following:
>> >> >>> - Work on RFC5031bis to change allocation policy
>> >> >>> - Submit draft-forte-ecrit-service-classification and 
>> >> >>> draft-sun-ecrit-shelter-service as informational/experimental 
>> >> >>> documents to the RFC Editor after Expert Review from 
>the ECRIT 
>> >> >>> working group.
>> >> >>>
>> >> >>> I recall that some folks had some comments about the
>> allocation
>> >> >>> policy they would like to see. Unfortunately, the meeting
>> >> >minutes do
>> >> >>> not capture the issue. I did listen to the audio 
>recording (see
>> >> >>> ftp://videolab.uoregon.edu/pub/videolab/media/ietf73/)
>> >> and noticed
>> >> >>> that Ted argued for "Specification Required" (instead
>> of "Expert
>> >> >>> Review").
>> > > >>>
>> >> >>> When you look at RFC 5226 then you will find a
>> >> description of what
>> >> >>> the difference between "Specification Required" and
>> >> "Expert Review"
>> >> >>> is. Here is the description for "Specification Required":
>> >> >>>
>> >> >>>       Specification Required - Values and their
>> meanings must be
>> >> >>>             documented in a permanent and readily
>> available public
>> >> >>>             specification, in sufficient detail so that 
>> >> >>> interoperability
>> >> >>>             between independent implementations is possible. 
>> >> >>> When used,
>> >> >>>             Specification Required also implies use of a
>> >> Designated
>> >> >>>             Expert, who will review the public
>> specification and
>> >> >>>             evaluate whether it is sufficiently clear to allow
>> >> >>>             interoperable implementations.  The
>> intention behind
>> >> >>>             "permanent and readily available" is that a
>> >> document can
>> >> >>>             reasonably be expected to be findable and
>> >> >retrievable long
>> >> >>>             after IANA assignment of the requested value. 
>> >> >Publication
>> >> >>>             of an RFC is an ideal means of achieving this
>> >> >requirement,
>> >> >>>             but Specification Required is intended to
>> >> also cover the
>> >> >>>             case of a document published outside of the RFC
>> >> >path.  For
>> >> >>>             RFC publication, the normal RFC review process
>> >> >is expected
>> >> >>>             to provide the necessary review for
>> interoperability,
>> >> >>> though
>> >> >>>             the Designated Expert may be a particularly
>> >> >well-qualified
>> >> >>>             person to perform such a review.
>> >> >>>
>> >> >>>             Examples: Diffserv-aware TE Bandwidth
>> >> Constraints Model
>> >> >>>             Identifiers [RFC4124], TLS ClientCertificateType 
>> >> >>> Identifiers
>> >> >>>             [RFC4346], ROHC Profile Identifiers [RFC4995].
>> >> >>>
>> >> >>> Are you happy about this approach?
>> >> >>>
>> >> >>> Ciao
>> >> >>> Hannes
>> >> >>> _______________________________________________
>> >> >>> Ecrit mailing list
>> >> >>> [e-mail]
>> >> >>> https://www.ietf.org/mailman/listinfo/ecrit
>> >> >>>
>> >> >> _______________________________________________
>> >> >> Ecrit mailing list
>> >> >> [e-mail]
>> >> >> https://www.ietf.org/mailman/listinfo/ecrit
>> >> >>
>> >> >
>> >>
>> >_______________________________________________
>> >Ecrit mailing list
>> >[e-mail]
>> >https://www.ietf.org/mailman/listinfo/ecrit
>> 
>> 
>
_______________________________________________
Ecrit mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ecrit