Re: [nfsv4] Update on documents related to rfc5661bis effort.

David Noveck <davenoveck@gmail.com> Sat, 08 October 2022 09:54 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 40CC7C152566 for <nfsv4@ietfa.amsl.com>; Sat, 8 Oct 2022 02:54:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GbQ9Ej5LQO8j for <nfsv4@ietfa.amsl.com>; Sat, 8 Oct 2022 02:54:42 -0700 (PDT)
Received: from mail-oo1-xc2c.google.com (mail-oo1-xc2c.google.com [IPv6:2607:f8b0:4864:20::c2c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E4BFC14CE33 for <nfsv4@ietf.org>; Sat, 8 Oct 2022 02:54:42 -0700 (PDT)
Received: by mail-oo1-xc2c.google.com with SMTP id r15-20020a4abf0f000000b004761c7e6be1so5013202oop.9 for <nfsv4@ietf.org>; Sat, 08 Oct 2022 02:54:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=UpfNlpGx3oCPSbK87N0vMYyHE8XI+D9arPfilaz7SaE=; b=laLFhspw16EUTnc3RsmMK64pgjnAdd+okk+TCPnE9oVC4WJHkvvTK/nkiPDEXOBKxy b5DekGYUKIhM1vDftLziATiJR3GBkcogVC3bUI4BrZel/QkFZr0k0fSOG/sabuvrMVSK PzjNRxeM0M9YBpbtY99946gFxaUn+7ikpRRmCZ4R/Wh6xPdJ+PGKme0tDCERWPPqOSNH n4Kwr+4S4nsNTEtkTRGw1OTQeYFmGKHnDXP95nvPvxj6ue6SQNaLaYGKxlRkng8N5z/K cvjTF+G8psQBOI/wLS9Jzk/rmn3m0V/wGrDAzQp2Lywk4bH/on6SCflJpC3MNz78IopG /12A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=UpfNlpGx3oCPSbK87N0vMYyHE8XI+D9arPfilaz7SaE=; b=rO5a6wX+SVe1bJccjdZStNvZU7J9XooSWRso19r8lEpnwJ4T52KYnxS181+oIID2Gs 7Cgocc1lYUTFeQKry+gn2Pcz6ye/hfBVynfSI5isD4acYtqriT7zoXrYD8zlUV9V1zsE R7v2E0u1lY5nOdAIygq1XKI6oO8g517mcWM7hj2fB67ksQA6Y2ip3h54CE4HNvHeM4wB eSDScOqo7S0LrcSPWbSIpS34vy1zcFQQy7eGpQVPTtOFwfJ+mh22y4nERaWaasOlZeZw 2UfXO86tyrT8ni+0jBPTaHPbcyujdahu3UaB/FJoRkneiB572uLD7SQ7EL+4zpQ6jpuk Y+9A==
X-Gm-Message-State: ACrzQf3pWtUQYsMoLhjUGMDumpKDRiANZ+sKEKLon+ycPMiOMp10jN9i a57daWmGQBu7XQogbfQKLc41o2n/o05SUoP5TSk=
X-Google-Smtp-Source: AMsMyM5P0X0ahpXveMDfYlgyP0LO2xwZ6h/Jr08SIMCmwfGY4ZBTWzIS+4VFUxEfMjNX8eR7oYWCrJ1YjYLQXefCRYA=
X-Received: by 2002:a05:6830:2b12:b0:65a:daa:d06c with SMTP id l18-20020a0568302b1200b0065a0daad06cmr3956851otv.51.1665222881385; Sat, 08 Oct 2022 02:54:41 -0700 (PDT)
MIME-Version: 1.0
References: <MN2PR06MB559764EE48BCDC120C15D320E15D9@MN2PR06MB5597.namprd06.prod.outlook.com> <240969EB-C93A-4D81-A4DF-D105A1E22EF1@oracle.com>
In-Reply-To: <240969EB-C93A-4D81-A4DF-D105A1E22EF1@oracle.com>
From: David Noveck <davenoveck@gmail.com>
Date: Sat, 08 Oct 2022 05:54:29 -0400
Message-ID: <CADaq8jecRu_ob91fht6XrqL3xhs6=EVx3s0FakY5yi=V3g39XA@mail.gmail.com>
To: Chuck Lever III <chuck.lever@oracle.com>, Brian Pawlowski <beepee@gmail.com>
Cc: NFSv4 <nfsv4@ietf.org>, Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com>
Content-Type: multipart/alternative; boundary="0000000000005120a205ea82ea33"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/u5IX9XLtan76ChbXKrPl3xK_Y0g>
Subject: Re: [nfsv4] Update on documents related to rfc5661bis effort.
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.39
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: Sat, 08 Oct 2022 09:54:44 -0000

On Wed, Oct 5, 2022, 10:44 AM Chuck Lever III <chuck.lever@oracle.com>
wrote:

>
>
> On Oct 5, 2022, at 10:19 AM, Noveck, David <
> David.Noveck=40netapp.com@dmarc.ietf.org> wrote:
>
> I’m looking to move to adopting any non-WG documents associated with this
> effort  within the next week.   Brian will wind up judging consensus on
> these adoption calls.
>
>
Zahed has asked me to be clearer about whether I'm asking for things to be
done as the author/editor of these documents or as wg co-chair.   To be
clear, I am discussing these matters here as editor of these documents and
as a working group member.  I have pretty much recused myself from
decisions regarding these documents as wg co-chair.   Some of my comments
are motivated by my role as co-editor of rfc5661 (mea culpa).

>
> Thanks for posting your plan!
>
> We already have three WG documents (not counting the RPC/RDMA v2 documents
> that are to expire), at least two of which might require significant
> external review. In years past, we had a large body of folks who could help
> out. But these days, and considering the total number of pages involved,
> does the WG have enough review and document stewardship resources to
> proceed with all of these in parallel?
>

Rfc5661bis has already been put off far too long, so I  really can't see us
doing these seriatim.  By the time we get to the bis, it will be difficult
to remember the issues, even though they will still need to be dealt with.
Sigh!

Note that it is already almost 13 years since rfc5661 was published and
that it is clearly deficient in a  number of major areas.  That is why I
have devoted a lot of my time to this effort.  I has been assuming that the
working group in general was in a position to do its part.  If it isn't,
then the working group is in the position of doing extensions to v4.1
without a good description of v4.1, the previous approval of rfc5661 as a
Proposed Standard notwithstanding.



> In any event, I'm not feeling inclined to support adoption of Security at
> this time due to the many outstanding issues in that document that remain
> to be worked out.
>

There are a lot of outstanding issues, which require WG input and they are
listed in Appendix B.  I anticipated that, once the document was adopted,
the working group would discuss these issues, focusing initially on those
listed in Appendix A.1.  Until the issues listed in Appendix B are dealt
with, which requires significant working group involvement, all these issue
will remain to be worked out.

>I'd like to see resolution of some or most of those issues before deciding
on document adoption.

In order to resolve the remaining issues, working group input is required,
and I expected us to have those discussions on the wg list but none has
happened so far.   While it makes most sense to me to do that in the
context of a wg document, that isn't the major issue.  To get a working
group consensus, we need working group discussion.   If we have that, it
really doesn't matter to me whether the document has -dnoveck- or -ietf- in
the name.    I can leave that issue to the working group, Brian, and
Zahed.  However, active working group involvement is necessary to make
progress in either case.


> Also IMO the completion dates are optimistic and are likely to be
> extended, in particular because of the IESG's and the RFC Editor's workload.
>

These dates are for submission to the IESG so the IESG and RFC editor
workloads are not relevant, since this work will happen *after *document
submission.  I realize that there will be a delay before RFC publication
but don't expect it to be anything like rfc9289, which I guess was two
years between submission and publication.

> I would feel more comfortable with 6/2023 for i18n and 6/2024 for
rfc5661/2bis... or even further out.

The dates I presented are my best estimate but they are subject to review
by Zahed.



>
>
> *Document*
> *Suffix*
> *Near-term*
> *Status*
> *Completion*
> *Target*
> *Recent*
> *Changes*
> *Notes and*
> *Comments*
> *Internationalization*
> WGLC already requested.
> 2/2023
> Updated (in -03) to reflect information about existing implementations of
> internationalized domain names.
> Target date needs to be approved by AD.
> I have appointed Brian as document shepherd.
> *Security*
> WG Document within a week
> 1/2024
> Last individual draft (-05) focused on appendices clarifying process going
> forward.
> Target date needs to be approved by AD.
>
> Discussion of SECINFO extensions may be continuing.
>
> Expect to focus first on issues in Appendix A.1
> *rfc5661bis*
> WG Document within a week
> 2/2024
> Last individual draft (-05) focused on adapting to the current limited
> split-up plan and resolving most pending errata.
> Target date needs to be approved by AD.
>
> Expect consensus in next six months but submission will wait for security.
>
> Only two errata reports need to be applied to document although some in
> document need wg discussion.
>
> Summary of errata status in attached document
> *rfc5662bis*
> WG Document within a week
> 12/2023
> New document.based on rfc5662.  Made changes corresponding to rfc5661
> errata reports 3067, 4118, 4914.
> Target date needs to be approved by AD.
>
> Expect consensus in next few months but will delay submission to be near
> rfc5661bis.
>
>
> <Err1004.docx>_______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
>
>
> --
> Chuck Lever
>
>
>
>