[Ecrit] RFC 5031bis - Service URNs

["Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig at nsn.com>]

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