[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Ecrit] RFC 5031bis - Service URNs
Good that you raised this issue.
My comment was only about the allocation of top-level services.
The allocation strategy for sub-services depends on what is defined by
the specification standardizing the top-level service.
For the sub-services of the 'sos service the allocation strategy is
currently expert review:
"
Additional sub-services can
be added after expert review and must be of general public interest
and have a similar emergency nature. The expert is designated by the
ECRIT working group, its successor, or, in their absence, the IESG.
The expert review should only approve emergency services that are
offered widely and in different countries, with approximately the
same caller expectation in terms of services rendered. The 'sos'
service is not meant to invoke general government, public
information, counseling, or social services.
"
I did not plan to change this part.
Ciao
Hannes
>-----Original Message-----
>From: ext DRAGE, Keith (Keith) [mailto:drage at alcatel-lucent.com]
>Sent: 03 December, 2008 15:42
>To: Tschofenig, Hannes (NSN - FI/Espoo); ECRIT
>Subject: RE: [Ecrit] RFC 5031bis - Service URNs
>
>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