Re: [Ecrit] RFC 5031bis - Service URNs

["DRAGE, Keith \(Keith\)" <drage at alcatel-lucent.com>]

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