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

Alexey Melnikov <alexey.melnikov@isode.com> Mon, 16 February 2015 11:17 UTC

Return-Path: <alexey.melnikov@isode.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 523161A87F1; Mon, 16 Feb 2015 03:17:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRamdbSMDoAY; Mon, 16 Feb 2015 03:17:53 -0800 (PST)
Received: from waldorf.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id 642491A87EE; Mon, 16 Feb 2015 03:17:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1424085472; d=isode.com; s=selector; i=@isode.com; bh=hRqkFqlI0UNfpN3nx/ef2HNtQpHcpgLfbfPA9OrU8QI=; 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=Vp/r2BsCAvGkdT3sLGPgiZwNW39F5VzA+Nd5uW+FOPUuvRpJBhzgckAuQABBh5qqaLeWEL /gUGqSYBQ004P4xRUNkWmO42UlhnyT/i/iR+1AMeCOIGioLeYM3BBeQzmQ/QmE8G0yXOc0 lIZWUmRlH4rL16GP5KXJS4yFjwC0+t0=;
Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id <VOHR4ABB7S9q@waldorf.isode.com>; Mon, 16 Feb 2015 11:17:52 +0000
Message-ID: <54E1D1DE.4000007@isode.com>
Date: Mon, 16 Feb 2015 11:17:50 +0000
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
To: Tom Haynes <thomas.haynes@primarydata.com>
Subject: Re: Gen-ART LC review of draft-ietf-nfsv4-lfs-registry-02
References: <54DB4258.9050105@isode.com> <D85D2CD2-6C8B-4740-B934-986CD2AE6032@primarydata.com>
In-Reply-To: <D85D2CD2-6C8B-4740-B934-986CD2AE6032@primarydata.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-transfer-encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/GUzxtLwKlg7bqAlgysoSbZTVTpY>
Cc: gen-art@ietf.org, ietf@ietf.org, draft-ietf-nfsv4-lfs-registry.all@tools.ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Mon, 16 Feb 2015 11:17:56 -0000

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 <alexey.melnikov@isode.com> wrote:
>>
>> I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>>
>> Please resolve these comments along with any other Last Call comments you may receive.
>>
>> Document:  draft-ietf-nfsv4-lfs-registry-02
>> Reviewer: Alexey Melnikov
>> Review Date: 2015-02-11
>> IETF LC End Date: 2015-02-16
>> IESG Telechat date: N/A.
>>
>> Summary: This draft is nearly ready for publication as a standard track RFC (with nits).
>>
>> Major issues:
>> Minor issues:
>>
>> In Section 4:
>>
>> "LSF" is used for the first time without being expanded. I suggest you introduce the abbreviation in the terminology section.
> I think I prefer to expand it as there are two possible expansions and only one use of it:
>
>
> 4.  Security Considerations
>
>     This document defines a mechanism to associate LFS identifier with a
>
> ->
>
> 4.  Security Considerations
>
>     This document defines a mechanism to associate the Label Format Specifier to a
Sounds good to me.
>> 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.
>>> 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.
>> 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