Re: [nfsv4] Benoit Claise's Block on charter-ietf-nfsv4-05-00: (with BLOCK and COMMENT)

David Noveck <davenoveck@gmail.com> Thu, 14 September 2017 13:13 UTC

Return-Path: <davenoveck@gmail.com>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DAD2132992; Thu, 14 Sep 2017 06:13:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 EPazZSnH37uw; Thu, 14 Sep 2017 06:13:12 -0700 (PDT)
Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (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 9B50912EC30; Thu, 14 Sep 2017 06:13:12 -0700 (PDT)
Received: by mail-io0-x232.google.com with SMTP id g32so267382ioj.2; Thu, 14 Sep 2017 06:13:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UUTVpDHkvIr21JdpUNSIJ/fwq/ouFni6sqRXCNlP4NE=; b=gJM3kV1dRXPc+1Aroka8zGPT+0TUKKb+KLjKyxOTtENys+UK8vCSehlnZkS2xuhHoS fCRxP+d3kBqCSAY3HdBKjtFEwU/aN0QY4u25yu9AJ774TxirClqzboDyi7s6bYhLRucL Bjm4Fyd571K6ToMxxFHM/loBo1PSbLl+IaxDzoe+r7g+ZaT195HlRnCVmcmoyuMz1I+4 eTB3LqZLWkzELS2XI/Yiwoyo+J09YYtyrHx96dPqanlWuHKDWu7eyUbemrBFlcT+tS/p jXqfu8zpCY7AlL/yqiB2kuqQfFsRtq+KAdhY7uoaSTIUw+TIpXx1BUnAzRAxN0fuBvMc 5dSg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UUTVpDHkvIr21JdpUNSIJ/fwq/ouFni6sqRXCNlP4NE=; b=UBwuKy502kCEu8YuPIIlTmha68OECfEvYsQDhdoGIl19AlGW/sktuA42p1Ly/qBBDS mDNGC1diY1bAhrnIJ7ZBmKzZGwvXa9XObY8EtLRiwj2bDKwuaI8KMiNsQERg6SZFk0+q JL/Qx7RJCyCLLwgSaWHEHlapMIsIcAxlXHLDtNSVxgQSWAlgXyCPW+amEbSrXPABks8b TSP/ghUMrZ0BvUmEYbLQIxHYwINbCC3q994UkMn+RRqYJm+JsujMLw3+UbbozVRoPelI ERwSIogBQllzunNlRSqcUDoHCbVxJ6OhYCcWif5ZoTiXvur4VJYinbjBLoKjKF88qeKE T3MA==
X-Gm-Message-State: AHPjjUgkbEMiNbhVpMVdYPFGiYls8UgUDb16Ty4gPfxONiP//DiJy9p3 +TzUtAZ3vnUNTci2blZLSl1dAG8jhLKHd+y3k0Y=
X-Google-Smtp-Source: AOwi7QCjXCUkAvFRsy8gtR8MxoFEApVKqxRTOHKfwZJ/KC8UxiiDCnwt0ZtM+Xm6MTScFxH0uBJRIuOFqhGeow1do1Q=
X-Received: by 10.107.5.65 with SMTP id 62mr1459745iof.98.1505394791677; Thu, 14 Sep 2017 06:13:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.4.194 with HTTP; Thu, 14 Sep 2017 06:13:11 -0700 (PDT)
In-Reply-To: <CAKKJt-dr_-AiaEsaF7aQQCwKJyT_ayX6npPpNmaGAy5zUExZPA@mail.gmail.com>
References: <150537392913.12691.17798959041359292248.idtracker@ietfa.amsl.com> <CAKKJt-dr_-AiaEsaF7aQQCwKJyT_ayX6npPpNmaGAy5zUExZPA@mail.gmail.com>
From: David Noveck <davenoveck@gmail.com>
Date: Thu, 14 Sep 2017 09:13:11 -0400
Message-ID: <CADaq8je2hCB+-keYNxG94V9F_DhNErzwDOWY9fLgBb3v_esCBg@mail.gmail.com>
To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Cc: Benoit Claise <bclaise@cisco.com>, The IESG <iesg@ietf.org>, NFSv4 <nfsv4@ietf.org>, "nfsv4-chairs@ietf.org" <nfsv4-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="001a113f014ace05a90559260934"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/ldFZqts7qknB3U8tembYvy2_uTU>
Subject: Re: [nfsv4] Benoit Claise's Block on charter-ietf-nfsv4-05-00: (with BLOCK and COMMENT)
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Sep 2017 13:13:15 -0000

>  but changing the IANA registry procedure to insert the working group
wasn't something I saw being proposed during recharter discussion

I agree.  I was under the impression that Chuck, when he proposed this
text, believed,he was merely restating explicitly what was already in
effect.  While it is true that, formally speaking, the working group as
such, has no role in this process, as a practical matter, the working group
will be consulted.  For example, when Spencer S is the designated expert,
the normal expectation would be that he would consult the working group
regarding anything that was not straightforward.

I think that if anyone thought that a change in the IANA registry procedure
was being proposed, they would have pointed that out and discussed the
matter.  After all, there have been no problems with the existing
procedure.  The working group is consulted when necessary.

> So, we'll do the right thing (and hold onto your BLOCK position until we
figure out what that is).

I think it would be best to simply delete  "The working group is also
responsible for approving changes to RPC- and
NFS-related IANA registries.".  I'd like to be sure that both Chuck and
Spencer S aare OK with that.

On Thu, Sep 14, 2017 at 8:28 AM, Spencer Dawkins at IETF <
spencerdawkins.ietf@gmail.com> wrote:

> Hi, Benoit,
>
> On Thu, Sep 14, 2017 at 2:25 AM, Benoit Claise <bclaise@cisco.com> wrote:
>
>> Benoit Claise has entered the following ballot position for
>> charter-ietf-nfsv4-05-00: Block
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/charter-ietf-nfsv4/
>>
>>
>>
>> ----------------------------------------------------------------------
>> BLOCK:
>> ----------------------------------------------------------------------
>>
>> - "The working group is also responsible for approving changes to RPC- and
>> NFS-related IANA registries." I frown up the "approving" word. It sounds
>> like
>> we change the IANA process here. Also, it seems like this sentence covers
>> a
>> series of registries https://www.iana.org/protocols#index_N
>>
>> Network File System version 4 (NFSv4)
>>
>> NFSv4 ${ietf.org:CPU_ARCH} Value Registry       RFC 5661
>> First Come First Served
>> NFSv4 ${ietf.org:OS_TYPE} Value Registry        RFC 5661
>> First Come First Served
>> NFSv4 Device ID Notifications Registry  RFC 5661
>> Standards Action with Expert Review (Expert: Spencer Shepler)
>> NFSv4 Named Attribute Definitions Registry      RFC 5661, RFC 7530
>> Specification Required for new registrations; updates to fields other
>> than the
>> contact field require Expert Review or IESG Approval (Expert: Spencer
>> Shepler)
>> NFSv4 Path Variables Registry   RFC 5661 ietf.org domain: Standards
>> Action with
>> Expert Review. non-ietf.org. domain: First Come First Served. (Expert:
>> Spencer
>> Shepler) NFSv4 Recallable Object Types Registry  RFC 5661 Standards
>> Action with
>> Expert Review (Expert: Spencer Shepler) pNFS Layout Types Registry
>> RFC 5661
>>
>> So we have a mix of FCFS and Standard Action with Expert Review.
>> If the charter says that the WG is now responsible, what does it imply?
>> For ex,
>> in terms of FCFS? What do you expect from the WG in the different
>> situations?
>> Feedback? Approval? (what if the WG disagrees with the expert), Standards
>> Action Review? Standards Action with Expert Review (Expert: Spencer
>> Shepler)
>>
>
> Well, that's awkward.
>
> I'll let Spencer (S) and the working group participants copied on this
> ballot e-mail take a look at this before proposing a fix, but changing the
> IANA registry procedure to insert the working group wasn't something I saw
> being proposed during recharter discussion
>
> So, we'll do the right thing (and hold onto your BLOCK position until we
> figure out what that is).
>
> Spencer
>
>
>>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>>
>>
>> - What are we balloting on?
>> https://datatracker.ietf.org/doc/charter-ietf-nfsv4/ballot/ shows two
>> different
>> pieces of information 1. Ready w/o external review (05-00) 2. Ballot
>> question:
>> "Is this charter ready for external review? Is this charter ready for
>> approval
>> without external review?" Is this a tooling issue?
>>
>
> It's at least an issue with the AD who sent out the ballot text ...
>
> Transport guys have decades of experience getting confused about whether
> one signal means either of two things, whether that's "does loss mean
> packet congestion or packet corruption?" or, in this case, "if I think the
> charter is ready but don't agree with the ballot question about external
> review, do I ballot BLOCK or Yes/No Objection?"
>
> Of course, most ADs at least delete one of the choices before opening the
> ballot ...
>
>
>> - "The NFSv4 working group is chartered with vetting reported issues and
>> determining correctness of submitted errata." I like that approach of not
>> only
>> having the area responsible for evaluating errata.
>>
>> - Like in the current NFSV4 charter, you should break down the proposed
>> milestones in "WG Last Call" and "Submit Final" and add the intended
>> status
>>
>> - Editorial
>>
>> In addition, some areas may need more concentrated work to correct the
>> specifications already published, to deal with unanticipated interactions
>> between features, or to respond to evolving IESG expectations with regard
>> to areas such as security.
>>
>> Could we remove "IESG"? While the IESG provides guidance and sometimes
>> enforces
>> rules, we should stress that the IETF is a community-based effort, as
>> opposed
>> to IESG-driven effort.
>>
>>
>> _______________________________________________
>> nfsv4 mailing list
>> nfsv4@ietf.org
>> https://www.ietf.org/mailman/listinfo/nfsv4
>>
>
>
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
>
>