Re: [Ecrit] RFC 5031bis - Service URNs

[Ted Hardie <[e-mail]>]

At 6:43 AM -0800 12/3/08, DRAGE, Keith (Keith) wrote:
>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

I'm not sure what "lower level for 'sos'" means, exactly, but I believe
using "specification required" for top-level and expert review for those
under sos is reasonable.    The Designated Expert for "specification required"
may or may not be the same as for "sos".

				Ted







> > -----Original Message-----
>> From: Tschofenig, Hannes (NSN - FI/Espoo)
>> [mailto:[e-mail]]
>> 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:[e-mail]]
>> >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: [e-mail] [mailto:[e-mail]] 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
>> >>> [e-mail]
>> >>> https://www.ietf.org/mailman/listinfo/ecrit
>> >>>
>> >> _______________________________________________
>> >> Ecrit mailing list
>> >> [e-mail]
>> >> https://www.ietf.org/mailman/listinfo/ecrit
>> >>
>> >
>>
>_______________________________________________
>Ecrit mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ecrit