Re: [Ecrit] RFC 5031bis - Service URNs

["Tschofenig, Hannes (NSN - FI/Espoo)" <[e-mail]>]

Why do you see a problem with the current allocation policy of expert
review the IETF ECRIT WG (its successor, or, in their absence, the
IESG)? 

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] 
>On Behalf Of ext DRAGE, Keith (Keith)
>Sent: 03 December, 2008 15:50
>To: Richard Barnes
>Cc: Tschofenig, Hannes (NSN - FI/Espoo); ECRIT
>Subject: Re: [Ecrit] RFC 5031bis - Service URNs
>
>Correct.
>
>Keith 
>
>> -----Original Message-----
>> From: Richard Barnes [mailto:[e-mail]]
>> Sent: Wednesday, December 03, 2008 1:48 PM
>> 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