[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Ecrit] RFC 5031bis - Service URNs
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: ecrit-bounces at ietf.org [mailto:ecrit-bounces at ietf.org]
>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:rbarnes at bbn.com]
>> Sent: Wednesday, December 03, 2008 1:48 PM
>> To: DRAGE, Keith (Keith)
>> Cc: Tschofenig, Hannes (NSN From ecrit-bounces at ietf.org Wed Dec 3 06:36:16 2008
Return-Path: <ecrit-bounces at ietf.org>
X-Original-To: ecrit-archive at megatron.ietf.org
Delivered-To: ietfarch-ecrit-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 890D13A6965;
Wed, 3 Dec 2008 06:36:16 -0800 (PST)
X-Original-To: ecrit at core3.amsl.com
Delivered-To: ecrit at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 5FD733A68D1
for <ecrit at core3.amsl.com>; Wed, 3 Dec 2008 06:36:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.673
X-Spam-Level:
X-Spam-Status: No, score=-5.673 tagged_above=-999 required=5 tests=[AWL=0.926,
BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id SDotDUZ-tmyQ for <ecrit at core3.amsl.com>;
Wed, 3 Dec 2008 06:36:14 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net
[217.115.75.233])
by core3.amsl.com (Postfix) with ESMTP id B4ABA3A68F4
for <ecrit at ietf.org>; Wed, 3 Dec 2008 06:36:13 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56])
by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id
mB3EZvBx005305
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
Wed, 3 Dec 2008 15:35:58 +0100
Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net
[10.159.32.11])
by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP
id mB3EZvdX005180; Wed, 3 Dec 2008 15:35:57 +0100
Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by
demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959);
Wed, 3 Dec 2008 15:35:57 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 3 Dec 2008 16:38:19 +0200
Message-ID: <C41BFCED3C088E40A8510B57B165C162D83AA4 at FIESEXC007.nsn-intra.net>
In-Reply-To: <5D1A7985295922448D5550C94DE291800255A5D7 at DEEXC1U01.de.lucent.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Ecrit] RFC 5031bis - Service URNs
Thread-Index: AclVTcM0NnAg5UH9RwuOOzYBex7lrAAACWQAAAGgRNA=
References: <C41BFCED3C088E40A8510B57B165C162D832FD at FIESEXC007.nsn-intra.net><5D1A7985295922448D5550C94DE291800255A5CF at DEEXC1U01.de.lucent.com><49368E08.1000802 at bbn.com>
<5D1A7985295922448D5550C94DE291800255A5D7 at DEEXC1U01.de.lucent.com>
From: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig at nsn.com>
To: "ext DRAGE, Keith (Keith)" <drage at alcatel-lucent.com>,
"Richard Barnes" <rbarnes at bbn.com>
X-OriginalArrivalTime: 03 Dec 2008 14:35:57.0575 (UTC)
FILETIME=[746E0170:01C95554]
Cc: ECRIT <ecrit at ietf.org>
Subject: Re: [Ecrit] RFC 5031bis - Service URNs
X-BeenThere: ecrit at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>,
<mailto:ecrit-request at ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:ecrit at ietf.org>
List-Help: <mailto:ecrit-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>,
<mailto:ecrit-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ecrit-bounces at ietf.org
Errors-To: ecrit-bounces at ietf.org
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: ecrit-bounces at ietf.org [mailto:ecrit-bounces at ietf.org]
>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:rbarnes at bbn.com]
>> Sent: Wednesday, December 03, 2008 1:48 PM
>> To: DRAGE, Keith (Keith)
>> Cc: Tschofenig, Hannes (NSN - FI/Esp- 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 oo); 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.
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
>> >>
>> >> 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