[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Ecrit] RFC 5031bis - Service URNs
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:hardie at qualcomm.com]
> 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: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
>
>
_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www.ietf.org/mailman/listinfo/ecrit