[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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