Re: [Ecrit] RFC 5031bis - Service URNs

["DRAGE, Keith \(Keith\)" <drage at alcatel-lucent.com>]

Correct.

Keith 

> -----Original Message-----
> From: Richard Barnes [mailto:rbarnes at bbn.com] 
> 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: 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