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

On Thu, Sep 14, 2017 at 6:13 AM, David Noveck <davenoveck@gmail.com> wrote:

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

Correct.  A change in IANA behavior/procedure was not the intent.

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

Agreed with as proposed.

Chuck?

Spencer

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