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

[Spencer Dawkins at IETF <[e-mail]>]

Dear NFSv4 Folk,

On Fri, Sep 15, 2017 at 10:26 PM, Spencer Dawkins at IETF <
[e-mail]> wrote:

> Backing up to Benoit's original ballot, since we've been focused on his
> Block, and haven't mentioned his Comments ...
>
> On Thu, Sep 14, 2017 at 2:25 AM, Benoit Claise <[e-mail]> 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)
>>
>
> This sentence is gone in 05-01.
>
>
>>
>> ----------------------------------------------------------------------
>> 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?
>>
>
> The IESG has been talking about tooling for the general case, but Spencer
> thinks the NFSv4 charter can be revised in this way without requiring
> External Review (typically, that's required for new charters, but unless a
> recharter is basically rebooting a working group to do something else, the
> working assumption is that people who care are already following the
> working group, and it's not necessary to annoy people who didn't care about
> the previous version of the charter by telling them that there's a new
> version that they probably don't care about either).
>
>
>> - "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.
>>
>
> I also like it, and wish I could take credit for it (but I can't).
>
>
>> - 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
>>
>
> I care more about the "Submit to IESG/Request Publication" part of this,
> but stating the intended status for milestones does help many working
> groups along their way.
>
> Do the right thing :-)
>
>
>> - 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.
>
>
> I agree. The point is that expectations change over a time for a reason,
> that's not just "we got new ADs who have time on their hands, so the IESG
> should move the goal posts". This is removed in 05-01.
>
> NFSv4 chairs, could you provide the "submit to IESG" dates for the
> milestones, in addition to the "WGLC" dates you've already provided? I
> think that with that, we'll be ready to announce the new charter.
>

Could you folks let me know what the updated milestones should look like? I
may have missed them ...

I'll enter them into the datatracker (or, approve them if the chairs add
them), and send the note approving the current version of the charter.

Thanks!

Spencer


> Thanks to everyone for your help.
>
> Spencer (D)
>