[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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