Re: Gen-ART LC review of draft-ietf-nfsv4-lfs-registry-02

Alexey Melnikov <> Mon, 16 February 2015 18:47 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3EBDC1A1DBC; Mon, 16 Feb 2015 10:47:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8w-W3d_DnPH9; Mon, 16 Feb 2015 10:47:14 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 61AA51A1F70; Mon, 16 Feb 2015 10:47:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1424112433;; s=selector;; bh=hQVD+/BnqcLRTvIiS+YytUFMuVP92bZOuuAmuko+1RM=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=uHJdhzVz6dHGPRQWiUZChXdVxbiAgG2KFRsjEsd64Rc4KJbbikFPhTZwoLp+ZTqAEsuJcI fsQqIy3bIxdCI81yTOIJhl99CrTqmojW/gUR+IV4e4SK78qkZObaQrsZoNPboaCreydwsc PK9Eh/JhVVF9Q8ryg/thxZhzjPD84t0=;
Received: from [] ( []) by (submission channel) via TCP with ESMTPSA id <>; Mon, 16 Feb 2015 18:47:13 +0000
Message-ID: <>
Date: Mon, 16 Feb 2015 18:47:10 +0000
From: Alexey Melnikov <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
To: Thomas Haynes <>
Subject: Re: Gen-ART LC review of draft-ietf-nfsv4-lfs-registry-02
References: <> <> <> <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-transfer-encoding: quoted-printable
Archived-At: <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 16 Feb 2015 18:47:16 -0000

Hi Tom,

On 16/02/2015 17:55, Thomas Haynes wrote:
>> On Feb 16, 2015, at 3:17 AM, Alexey Melnikov <> wrote:
>> Hi Tom,
>> On 11/02/2015 21:14, Tom Haynes wrote:
>>> Hi Alex,
>>> Thanks for the review.
>>> Comments inline.
>>> Tom
>>>> On Feb 11, 2015, at 3:51 AM, Alexey Melnikov <> wrote:
>>>> In Section 5:
>>>> Label Description: - what is the allowed character set for this field? Is it ASCII? Is it UTF-8 with some restrictions?
>>>     Label Description:  A human readable ASCII text string that describes
>> This is a good change.
> This was the original text. :-)
Oops :-). I think you need to add a reference to RFC 20 for US-ASCII. It 
would also be better to say that control characters should not be allowed.
>>>>> Status:  A short ASCII text string indicating the status of an entry
>>>>>        in the registry.  The status field for most entries should have
>>>>>        the value "active".  In the case that a label format selection
>>>>>        entry is obsolete, the status field of the obsoleted entry should
>>>>>        be "obsoleted by entry NNN".
>>>> What is entry NNN? Is it a document reference (e.g. An RFC)?
>>> It is another entry in the registry. That new entry will provide the mapping to a document reference.
>> Some registries allow obsoletion of entries which are just not considered to be a good idea anymore. I don't know if your document should allow for that or not.
> This registry does not consider worthiness as a criteria.
>>>> Is it possible to obsolete without such entry?
>>> No, Section 5.3 is clear on that.
>>>> In Section 5.3 - is it possible to update a label description document without requesting a new label? For example if changes are editorial and don't significantly affect label syntax and model.
>>> Two considerations:
>>> 1) Edit of “Description” - I don’t see a problem with allowing this to occur.
>>> 2) Edit of “Reference” - Which is what I think you are asking about here.
>> I was asking about both.
>>> If we consider IETF created RFCs, we know that a -bis is a legitimate need for an update as it obsoletes the earlier RFC.
>>> And if we consider non-IETF created documents, I think we need to fall back Designated Expert reviewer to answer whether the new document requires a new label or we can allow an edit.
>>> This is rough, but I’d envision a new Section 5.4:
>>> 5.4.  Modifying an Existing Entry in the Registry
>>>    A request to modify  either the Description or the published
>>>    label format specification will also require the Specification
>>>    Required IANA policy to be applied. The Designated Expert reviewer
>>>    will need to determine if the published label format specification
>>>    either
>>>    obsoletes the Label Format Specifier - follow the process in Section 5.2.
>>>    updates the label syntax and/or model - approve the change.
>> I like this.
>>>> Nits/editorial comments:
>> Best Regards,
>> Alexey
> And Alexey, thank you very much for that last point, I think it makes the document more complete.
> I’ve applied the changes, let me know if you want to see an early copy of the next version.
I am satisfied with your responses where new text was discussed and 
agreed upon.

Thank you for replying so quickly and doing the updates!

Best Regards,