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

Thomas Haynes <thomas.haynes@primarydata.com> Mon, 16 February 2015 17:55 UTC

Return-Path: <thomas.haynes@primarydata.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 DD2C51A1BA4 for <ietf@ietfa.amsl.com>; Mon, 16 Feb 2015 09:55:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 DCc12MxLHbkx for <ietf@ietfa.amsl.com>; Mon, 16 Feb 2015 09:55:41 -0800 (PST)
Received: from mail-pd0-f170.google.com (mail-pd0-f170.google.com [209.85.192.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97F671A1B6A for <ietf@ietf.org>; Mon, 16 Feb 2015 09:55:41 -0800 (PST)
Received: by pdbnh10 with SMTP id nh10so33696315pdb.11 for <ietf@ietf.org>; Mon, 16 Feb 2015 09:55:41 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=SD0niORK1pKGtWxw0pccKpLnBm/MwDCMDsnUd3Qs8a8=; b=Y/1RlmKJahW4szFogbtGUJ7AAISdFO1r69kwjnwoIzFP0zng2igG20h5hDURQ/u3tO uKjJXrKabOVHd/2b5m7oO5blnv79QvVUmFyPAgmtiNcVlBMVINkxViKE8lyyYcCqItyW 66GI0fxs2WRF07y5vqKPfwYcjzga4ye86RU/ljymISK745Q9WHPOyGj7zDnO03CKtnDd EDtsunMIjM172xXwbJYbQKg8atzxgP35y5VZz/RZihS+foTwoDW6H6X/a+5S9iHbpfsK Hfhy9ibSS4wkR5NFwRBz95Q7Q+hf+GtTENCAkllh739T9tLJpc0acMKZSTkZBU05vjt1 yr4w==
X-Gm-Message-State: ALoCoQn5lsom3McwWiuw6oUaygEBsiVHZY/REcfDGlzLUvpgvxHXuWwGXKUg70YilG3t6ixR3otc
X-Received: by 10.66.148.161 with SMTP id tt1mr42884504pab.85.1424109341205; Mon, 16 Feb 2015 09:55:41 -0800 (PST)
Received: from ?IPv6:2601:9:8200:9ec:642f:d4a7:5bc5:f064? ([2601:9:8200:9ec:642f:d4a7:5bc5:f064]) by mx.google.com with ESMTPSA id x10sm15511686pas.18.2015.02.16.09.55.40 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 16 Feb 2015 09:55:40 -0800 (PST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
Subject: Re: Gen-ART LC review of draft-ietf-nfsv4-lfs-registry-02
From: Thomas Haynes <thomas.haynes@primarydata.com>
In-Reply-To: <54E1D1DE.4000007@isode.com>
Date: Mon, 16 Feb 2015 09:55:39 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <3D497252-036F-4A66-BDCB-B50482D5FC76@primarydata.com>
References: <54DB4258.9050105@isode.com> <D85D2CD2-6C8B-4740-B934-986CD2AE6032@primarydata.com> <54E1D1DE.4000007@isode.com>
To: Alexey Melnikov <alexey.melnikov@isode.com>
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/7Ke-Gl2KBSoZHm5j6b-j1XSk5Jc>
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 17:55:44 -0000

> On Feb 16, 2015, at 3:17 AM, Alexey Melnikov <alexey.melnikov@isode.com> 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 <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.

Done

>>> 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. :-)


>>>> 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.