[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Ecrit] RFC 5031bis - Service URNs
Well I must admit I looked quickly and read something different and
wrongly.
If I was starting from scratch, I think I would write "standards track"
for the subservices of sos, but I cannot point to any problems with the
existing strategy, so on that basis there is no need to change it.
The main point I was making anyway is that we must not have a lower
level for "sos" and that we do need clear guidance to stop people
registering urns where there are more appropriate places to put
information other than a URI.
Keith
> -----Original Message-----
> From: Tschofenig, Hannes (NSN - FI/Espoo)
> [mailto:hannes.tschofenig at nsn.com]
> Sent: Wednesday, December 03, 2008 2:36 PM
> To: ext Richard Barnes; DRAGE, Keith (Keith)
> Cc: ECRIT
> Subject: 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