Re: Last Call on draft-ietf-pim-registry-03.txt

Mykyta Yevstifeyev <evnikita2@gmail.com> Thu, 13 January 2011 15:49 UTC

Return-Path: <evnikita2@gmail.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 118933A6BAC for <ietf@core3.amsl.com>; Thu, 13 Jan 2011 07:49:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.304
X-Spam-Level:
X-Spam-Status: No, score=-2.304 tagged_above=-999 required=5 tests=[AWL=-0.665, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1]
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 axzIH4gZZIqB for <ietf@core3.amsl.com>; Thu, 13 Jan 2011 07:49:05 -0800 (PST)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 071433A6BA7 for <ietf@ietf.org>; Thu, 13 Jan 2011 07:49:04 -0800 (PST)
Received: by eyd10 with SMTP id 10so942251eyd.31 for <ietf@ietf.org>; Thu, 13 Jan 2011 07:51:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=YKLs85uh2CJqRgZyj01LJnfk4Gre7HzJ4dnJ6nYJbuU=; b=WZ9gsQL95tCzG8LJKJ2ReXq4TfT1VdRzbKYxxLzQezumMpziOvOvbX8t0U4FpvZb9o FSDhxcP0pWUWNyzh35aQXcmyLQCImuCkQGMVXz4jzQkKmrfRWF+1YAAaexIwLcYYhEpo 3KJB7wrShLWczy9Jt8AgEDAuUTcem3VrXmTjo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=bCTwyPqUmQp806TWUOdQKUzF5tynXWCSrEIsJE1HiD9WNgxU66Lse9/1rTWex6HbNt /5DvLajJriVDBsah5cpejmFt2u+3uhTNV46LRAyktLPz7K4oJ9/VYODk48AbUfgjir18 Txn5RYI/8pNZiF8d4f20z4TmvglfC6VJE66I0=
Received: by 10.204.59.140 with SMTP id l12mr1907578bkh.2.1294933886483; Thu, 13 Jan 2011 07:51:26 -0800 (PST)
Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id x38sm743449bkj.13.2011.01.13.07.51.24 (version=SSLv3 cipher=RC4-MD5); Thu, 13 Jan 2011 07:51:25 -0800 (PST)
Message-ID: <4D2F1F8F.5060304@gmail.com>
Date: Thu, 13 Jan 2011 17:51:43 +0200
From: Mykyta Yevstifeyev <evnikita2@gmail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: Julian Reschke <julian.reschke@gmx.de>
Subject: Re: Last Call on draft-ietf-pim-registry-03.txt
References: <AANLkTin+wxG6oSrvux6DuqZNA1hLGALmozfxzhhGxT3+@mail.gmail.com> <01bc01cbb25c$41590700$c40b1500$@huawei.com> <4D2DB36C.7070107@gmx.de> <01da01cbb264$2f1462d0$8d3d2870$@huawei.com> <4D2DBC48.2080302@gmx.de> <AANLkTikTks15pML38XSAuJZY-yRmDXdQBhe12ynWq+Pz@mail.gmail.com> <0FCCAC8F1FBB48FDA5A5C347233271AA@DougEwell> <4D2EB195.60604@gmx.de> <AANLkTi=6pMxR56z3safr3gQ0q8Aw8sJ3WAcRfwOuNiUk@mail.gmail.com> <4D2EE2A7.5060805@gmx.de>
In-Reply-To: <4D2EE2A7.5060805@gmx.de>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: The IETF <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Jan 2011 15:49:06 -0000

13.01.2011 13:31, Julian Reschke wrote:
> On 13.01.2011 10:21, Mykyta Yevstifeyev wrote:
>> Hello all,
>>
>> Let me cite RFC 5226, that says:
>>
>> <...>
>> Documents that create a new namespace (or modify the definition of an
>> existing space) and that expect IANA to play a role in maintaining
>> that space (e.g., serving as a repository for registered values) MUST
>> provide clear instructions on details of the namespace.  In
>> particular, instructions *MUST* include:
>> <...>
>> 5) Initial assignments and reservations.  Clear instructions should be
>> provided to identify any initial assignments or registrations.  In
>> addition, any ranges that are to be reserved  for "Private Use",
>> "Reserved", *"Unassigned"*, etc. should be *clearly indicated*.
>> <...>
>> ...
>
> That sounds like an editorial error to me.
>
> "any ranges to be *reserved* for .... "Unassigned"..."
>
> doesn't make any sense at all. They are not reserved.
Yes, that is a type of error, but the meaning is that unassigned and 
reserved values MUST (yes, must, that is in RFC 5226; see citation 
below) be mentioned.
>
> This should probably be raised as erratum.
>
>> So the document specifying the regsitry MUST mention what are
>> Unassigned.  Moreover, IMO, it would be useful to assign one value for
>> Experimentation.
>
> No. should != must.
See below.
>
> There are tons of registries where this is not the case; namely all or 
> most of those where the values are strings, not numbers.
The strings registries are rather exceptions from the rule I cited above.

Mykyta
>
>
> Best regards, Julian
>