Re: [Ecrit] RFC 5031bis

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

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