[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Ecrit] RFC 5031bis - Service URNs
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:drage at alcatel-lucent.com]
>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:hardie at qualcomm.com]
>> 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:hannes.tschofenig at nsn.com]
>> >> 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:rbarnes at bbn.com]
>> >> >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: ecrit-bounces at ietf.org
>> [mailto:ecrit-bounces at ietf.org] 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
>> >> >>> Ecrit at ietf.org
>> >> >>> https://www.ietf.org/mailman/listinfo/ecrit
>> >> >>>
>> >> >> _______________________________________________
>> >> >> Ecrit mailing list
>> >> >> Ecrit at ietf.org
>> >> >> https://www.ietf.org/mailman/listinfo/ecrit
>> >> >>
>> >> >
>> >>
>> >_______________________________________________
>> >Ecrit mailing list
>> >Ecrit at ietf.org
>> >https://www.ietf.org/mailman/listinfo/ecrit
>>
>>
>
_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www.ietf.org/mailman/listinfo/ecrit