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

Tom Haynes <> Wed, 11 February 2015 21:14 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 013AF1A19FE for <>; Wed, 11 Feb 2015 13:14:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PGH6y6CmcYBp for <>; Wed, 11 Feb 2015 13:14:08 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5E0FD1A06E9 for <>; Wed, 11 Feb 2015 13:14:08 -0800 (PST)
Received: by with SMTP id et14so6587471pad.4 for <>; Wed, 11 Feb 2015 13:14:07 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=R1aGGCt1fNDG15vLR0UGLsPXJPZt6AMohBh9XMGFXpA=; b=JIfWrzV4KPiPixvKBZRXHAkCykJ9uno2SdS0ivTG0MNJJTxsaJ5V6heOX8Fe6yS0OY OkFxt0K8HdD4tbAVswTdd67n2FEFsj298lt+rCVCYS/jHH2IJVbE9nFed37oxHo008wX kQQco/YtroxmcLVTDOSTBKHO3cfLLSsX8oZjvOVAbZ2B1KmlhUWjQQOUAiYYNCSpxLZX iolN6z/l75XaMYhs7IfP9M+pevfhCbuaBGHZAYD8pgncCWFWtRnj4Muo8JEoYWHnOWrw jhK4bWlBcIRJXmCcFh9AO1qkvs5dineZog3SXGVQNCxzs9gPCoqBynhiuadmMWy9CtHg evbA==
X-Gm-Message-State: ALoCoQnOQIycvQJlMoM5zRPjd07k2s3x7x9Lk10v2RRKXsTu9lqkAlS/2tP9r0+OwMq485fyLfdX
X-Received: by with SMTP id v4mr919064pde.114.1423689247846; Wed, 11 Feb 2015 13:14:07 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id j9sm1708602pbq.66.2015. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Feb 2015 13:14:07 -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: Tom Haynes <>
In-Reply-To: <>
Date: Wed, 11 Feb 2015 13:14:05 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Alexey Melnikov <>
X-Mailer: Apple Mail (2.2070.6)
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: Wed, 11 Feb 2015 21:14:11 -0000

Hi Alex,

Thanks for the review.

Comments inline.


> On Feb 11, 2015, at 3:51 AM, Alexey Melnikov <> wrote:
> I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <>.
> 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

> 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

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

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

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

  obsoletes the Label Format Specifier - follow the process in Section 5.2.

  updates the label syntax and/or model - approve the change.

> Nits/editorial comments: