Re: [Ecrit] RFC 5031bis

This is not what RFC 5031 says.  

>-----Original Message-----
>From: ext Richard Barnes [mailto:rbarnes@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@ietf.org [mailto:ecrit-bounces@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@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>
>> _______________________________________________
>> Ecrit mailing list
>> Ecrit@ietf.org
>> https://www.ietf.org/mailman/listinfo/ecrit
>> 
>
_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit