Re: [Ecrit] RFC 5031bis - Service URNs

["DRAGE, Keith \(Keith\)" <[e-mail]>]

I would like to keep sub-services at the same strength of review as the
top level. For the existing top-levels that requires no change to keep
it at specification required.

Keith

> -----Original Message-----
> From: Ted Hardie [mailto:[e-mail]] 
> Sent: Wednesday, December 03, 2008 5:56 PM
> To: DRAGE, Keith (Keith); Tschofenig, Hannes (NSN - 
> FI/Espoo); ext Richard Barnes
> Cc: ECRIT
> Subject: Re: [Ecrit] RFC 5031bis - Service URNs
> 
> 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