From nobody Sun Aug 1 13:48:44 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E68B43A0F13 for ; Sun, 1 Aug 2021 13:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.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 TZ4ZGZiOZLb3 for ; Sun, 1 Aug 2021 13:48:38 -0700 (PDT) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (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 382243A0F04 for ; Sun, 1 Aug 2021 13:48:38 -0700 (PDT) Received: by mail-qt1-x82a.google.com with SMTP id t18so10397222qta.8 for ; Sun, 01 Aug 2021 13:48:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=cckNBG71UDUDFazFHnczGPMlkAUiIIcauuTA6rVSIJQ=; b=DgavV27jWPe3Nb4KN6+NFqY481UKEM/LnzxNas4V9bW7F2XAxe5Sw0axj+yw007wPw nlCckf3Bz9oOEQSA34tM4m645dz+Ijpo/HT0wjiURCnHAhyiwfy9kwY2L8pqG4VI0twA bzhH0gU+vDlNSi2CtFfZ7n2f2cDQYE4p1l1SmSSAyobkif/WCPMK8cq4mqeI+22B27zY aPdzXEaTjekrnnIyd9Vw1B2UuxHGj1gnzT95fudLHj2st3KEldJTiJIT3IbGwxmSaBt8 pypIYkjdGG9pgVq5wSwG7PXJabZE9x/jhoYK9QSrW0qfacfDZUNNct4h0wqBd+DkuXsg 7rwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=cckNBG71UDUDFazFHnczGPMlkAUiIIcauuTA6rVSIJQ=; b=Xo7AJvhxi18vFxO/h5JsRfOmRPiFfbtFcAywbmf19evjTpNhtcpomf3j3Mj/sibEsp KzWUejqf8Hi5j+qsIBYL0h6AyQsVQ4OHcEfMcpPJwLepE6/mU4HvvQpfZ7Z5idYA5CUM WsOHTLJx0WV4yKT5tvFZ/I+NrOF4EdWv2CBlajPTEAszpF7oaLE8fg7u3gZ5Yd6NetH7 luoL9fkI7Cjcw46aI+qSgjaHKArAWwUro5uYN0fW10SoLROaPXrUgrwEIuT6ZnGfxdX6 Mwuq1MJkXHNGgOcVEpvsS/dQuTVOeoe+4kMFG0wDUl2n38hJbRwrb2xDigIpS62n9aSQ psdQ== X-Gm-Message-State: AOAM531hFaZCYsj1RyUMggIwDYauDPu1DJbPtp6gx0zwirfeEW0PzqLH kTJWO11svdCrPVbVYz4Mq5Atz04u130MbwiP X-Google-Smtp-Source: ABdhPJxsXi8WTFjEdu/JoI9kHJZNgXHsCMI4H9U37gkfoxWi4/3CmzxpTbF+5cU43easyJQlWNnpOQ== X-Received: by 2002:ac8:7770:: with SMTP id h16mr11601255qtu.144.1627850915369; Sun, 01 Aug 2021 13:48:35 -0700 (PDT) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id k15sm4737985qko.84.2021.08.01.13.48.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 01 Aug 2021 13:48:34 -0700 (PDT) To: "Joel M. Halpern" , Eric Rescorla Cc: rfced-future@iab.org References: <6b5f89e8-2d79-016b-65bb-39704c438e96@nthpermutation.com> <2739d8af-209a-6714-c21c-d723fbd941fd@joelhalpern.com> From: Michael StJohns Message-ID: <59a3aeda-0a76-eed9-70ac-ad2739c15eb5@nthpermutation.com> Date: Sun, 1 Aug 2021 16:48:33 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <2739d8af-209a-6714-c21c-d723fbd941fd@joelhalpern.com> Content-Type: multipart/alternative; boundary="------------B17579A6CAD44E1D8D03CFEE" Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Replacement text for Section 4.2 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Aug 2021 20:48:43 -0000 This is a multi-part message in MIME format. --------------B17579A6CAD44E1D8D03CFEE Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Let me break this down into two section:  1) What is the scope of confidentiality?  2) What does the RSEA get to see and comment on prior to it going to the LLC - if anything? For confidentiality, I have these questions: 1) Are truly anonymous comments permitted? 2) Does the IED get to see all of the comments with the source unredacted? 3) Does the RSAB get to see all of the comments?    3a) paraphrased?    3b) source unredacted?    3c) source redacted?       3c.1) With redactors comment on the source?       3c.2) Without comment 4) Does the LLC get to see all of the comments?    4a) paraphrased?    4b) source unredacted?    4c) source redacted?        4c.1) With redactors comment on the source        4c.2) Without comment on the source I assume that if the IED gets to see all comments, they will act as redactor for any further distribution if redaction is required. In the draft I assumed that 1, 2), 3c.1), and 4c.1) were the answers to the above questions because of the comments that were made by the call about confidentiality.    Obviously, if the LLC and the RSAB get to see everything, there won't be a redaction and comment on the source necessary.   If the LLC doesn't get to see everything, then it at least needs the context of possible biases from the submitters of the comments to help it understand the reality on the ground. For the RSEA, I believe that it needs to be a bit more that Joel suggests below - and instead we should be making sure that any comment that will be considered by the LLC has to be provided to the RSEA for feedback and rebuttal in at least a paraphrased form.  I don't think the RSEA gets to know about any of the sources, but it seems both unfair and legally fraught not to provide them with an opportunity to make an opposing case for any negative comments. And I'm glad that EKR brought up "legal".   Unlike the Nomcom process there is/will be a financial relationship between the LLC and the RSEA in the form of either an employment agreement or contract.   In the event that the LLC moves to terminate that relationship, if the RSEA feels it is being done for "unfair" reasons and can make a case to a legal standard in the appropriate legal venue, _*each and every comment, and all emails and notes discussing those comments will be subject to subpoena and the related depositions*_. And lastly - no company I know of solicits company wide comments (unless the company is really tiny) on a particular employee's performance, nor does the manager not know who made the comment and hence that manager can accurately weigh said comments.  It would be a truly bad manager that did not ask an employee about their take on any  negative comments the manager received and the manager should help them redress any actual problems. Mike ps - Martin - "derogatory" is a term of art, mostly used related to credit worthiness,   it differs from negative, in that the derogatory info may affect the credit score, but there might be other negative information that can't be taken into account due to legal issues (e.g. for this "the RSEA is too old for the job" would be a negative comment, but not a derogatory one as age discrimination is generally prohibited and the comment couldn't be considered and would need to be discarded when received).   Happy though to change to "negative and positive" vice derogatory. On 7/29/2021 11:49 PM, Joel M. Halpern wrote: > I mostly agree with Ekr here. > > The only edge case I see is one that I know has come up with nomcoms. > If nomcoms see a pattern of reports of an issue, they have been known > to say to a candidate "there have been issues raised about X.  Do you > have any comment on that?"   This is not the same as showing the > candidate the feedback, even sanitized. It does reveal that > information has been provided.  (And, even more importantly, ti does > not give even a large portion of the feedback.)  The nomcoms where I > know this came up concluded that the combination of seeing the > candidates reaction and giving then a chance to respond was worth > pushing that envelop.   Do we consider that the selection committee or > LLC or someone has that right under this process already?  Do we want > to say anything about it? > > Yours, > Joel > > On 7/29/2021 11:34 PM, Eric Rescorla wrote: >> >> >> On Thu, Jul 29, 2021 at 5:00 PM Michael StJohns >> > wrote: >> >>     Replacement for section 4.2: >> >>               <<< Set a schedule - could be omitted, but this is a >>     promise to >>     the community >> >>                      as well as a schedule for the IED/RSEA >>> >>          No more often than semi-annually nor less often than >> bi-yearly, the >>          IETF Executive Director will send out to the community a >> call for >>          input on the performance of the RSEA. >> >>           <<< Separate the IED's recommendation from the feedback >> process - >> >>            there may not actually be an action that needs an immediate >>     recommendation >>> >> >>          <<<< the IED acts as the confidentiality mediator, anonymous >> and >>     confidential >> >>                   comments get tagged in the document that goes to the >>     LLC - >>     this provides >> >>                   needed context. >>>> >>          The IETF Executive Director and the stream managers will >> review the >>          received feedback and produce a draft summary (a paraphrase) >>          including both positive and derogatory information. Any >> feedback >>          provided anonymously shall be tagged as such in the summary. >> Any >>          feedback provided with a request for confidentiality shall >> likewise >>          be tagged in the summary and the IETF Executive Director MAY >>          comment on the weight that may be appropriate to apply to the >>          comment based on their knowledge of the submitter.  The stream >>          managers should ensure that any of their concerns are added >> to the >>          document at this point and MAY also provide any commentary >> on the >>          externally provided feedback that they feel appropriate. >> >>          <<< Make sure that the LLC hears both sides of the coin >>> >>          That draft feedback, redacted with respect to any names >> associated >>          with confidential comments and with respect to the IED's weight >>          evaluations, shall be provided to the RSEA with for comment or >>          rebuttal, and such comments shall be incorporated as an >> appendix to >>          the final feedback document provided to the IETF LLC Board. >> >> >> This doesn't seem appropriate to me. >> >> If people want to provide confidential comments, then they shouldn't >> be supplied to the RSEA, >> nor should the IED's weights. This is not a legal proceeding, it's a >> performance review, and >> there's no generic reason that the RSEA should get to hear all the >> feedback that the LLC is >> receiving. >> >> -Ekr >> >> --------------B17579A6CAD44E1D8D03CFEE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Let me break this down into two section:  1) What is the scope of confidentiality?  2) What does the RSEA get to see and comment on prior to it going to the LLC - if anything?

For confidentiality, I have these questions:

1) Are truly anonymous comments permitted?
2) Does the IED get to see all of the comments with the source unredacted?
3) Does the RSAB get to see all of the comments?
   3a) paraphrased?
   3b) source unredacted?
   3c) source redacted?
      3c.1) With redactors comment on the source?
      3c.2) Without comment
4) Does the LLC get to see all of the comments?
   4a) paraphrased?
   4b) source unredacted?
   4c) source redacted?
       4c.1) With redactors comment on the source
       4c.2) Without comment on the source

I assume that if the IED gets to see all comments, they will act as redactor for any further distribution if redaction is required.

In the draft I assumed that 1, 2), 3c.1), and 4c.1) were the answers to the above questions because of the comments that were made by the call about confidentiality.    Obviously, if the LLC and the RSAB get to see everything, there won't be a redaction and comment on the source necessary.   If the LLC doesn't get to see everything, then it at least needs the context of possible biases from the submitters of the comments to help it understand the reality on the ground.

For the RSEA, I believe that it needs to be a bit more that Joel suggests below - and instead we should be making sure that any comment that will be considered by the LLC has to be provided to the RSEA for feedback and rebuttal in at least a paraphrased form.  I don't think the RSEA gets to know about any of the sources, but it seems both unfair and legally fraught not to provide them with an opportunity to make an opposing case for any negative comments.

And I'm glad that EKR brought up "legal".   Unlike the Nomcom process there is/will be a financial relationship between the LLC and the RSEA in the form of either an employment agreement or contract.   In the event that the LLC moves to terminate that relationship, if the RSEA feels it is being done for "unfair" reasons and can make a case to a legal standard in the appropriate legal venue, each and every comment, and all emails and notes discussing those comments will be subject to subpoena and the related depositions.   

And lastly - no company I know of solicits company wide comments (unless the company is really tiny) on a particular employee's performance, nor does the manager not know who made the comment and hence that manager can accurately weigh said comments.  It would be a truly bad manager that did not ask an employee about their take on any  negative comments the manager received and the manager should help them redress any actual problems. 

Mike


ps - Martin - "derogatory" is a term of art, mostly used related to credit worthiness,   it differs from negative, in that the derogatory info may affect the credit score, but there might be other negative information that can't be taken into account due to legal issues (e.g. for this "the RSEA is too old for the job" would be a negative comment, but not a derogatory one as age discrimination is generally prohibited and the comment couldn't be considered and would need to be discarded when received).   Happy though to change to "negative and positive" vice derogatory.



On 7/29/2021 11:49 PM, Joel M. Halpern wrote:
I mostly agree with Ekr here.

The only edge case I see is one that I know has come up with nomcoms. If nomcoms see a pattern of reports of an issue, they have been known to say to a candidate "there have been issues raised about X.  Do you have any comment on that?"   This is not the same as showing the candidate the feedback, even sanitized.  It does reveal that information has been provided.  (And, even more importantly, ti does not give even a large portion of the feedback.)  The nomcoms where I know this came up concluded that the combination of seeing the candidates reaction and giving then a chance to respond was worth pushing that envelop.   Do we consider that the selection committee or LLC or someone has that right under this process already?  Do we want to say anything about it?

Yours,
Joel

On 7/29/2021 11:34 PM, Eric Rescorla wrote:


On Thu, Jul 29, 2021 at 5:00 PM Michael StJohns <msj@nthpermutation.com <mailto:msj@nthpermutation.com>> wrote:

    Replacement for section 4.2:

              <<< Set a schedule - could be omitted, but this is a
    promise to
    the community

                     as well as a schedule for the IED/RSEA >>>
         No more often than semi-annually nor less often than bi-yearly, the
         IETF Executive Director will send out to the community a call for
         input on the performance of the RSEA.

          <<< Separate the IED's recommendation from the feedback process -

           there may not actually be an action that needs an immediate
    recommendation >>>

         <<<< the IED acts as the confidentiality mediator, anonymous and
    confidential

                  comments get tagged in the document that goes to the
    LLC -
    this provides

                  needed context. >>>>
         The IETF Executive Director and the stream managers will review the
         received feedback and produce a draft summary (a paraphrase)
         including both positive and derogatory information.  Any feedback
         provided anonymously shall be tagged as such in the summary. Any
         feedback provided with a request for confidentiality shall likewise
         be tagged in the summary and the IETF Executive Director MAY
         comment on the weight that may be appropriate to apply to the
         comment based on their knowledge of the submitter.  The stream
         managers should ensure that any of their concerns are added to the
         document at this point and MAY also provide any commentary on the
         externally provided feedback that they feel appropriate.

         <<< Make sure that the LLC hears both sides of the coin >>>
         That draft feedback, redacted with respect to any names associated
         with confidential comments and with respect to the IED's weight
         evaluations, shall be provided to the RSEA with for comment or
         rebuttal, and such comments shall be incorporated as an appendix to
         the final feedback document provided to the IETF LLC Board.


This doesn't seem appropriate to me.

If people want to provide confidential comments, then they shouldn't be supplied to the RSEA,
nor should the IED's weights. This is not a legal proceeding, it's a performance review, and
there's no generic reason that the RSEA should get to hear all the feedback that the LLC is
receiving.

-Ekr



--------------B17579A6CAD44E1D8D03CFEE-- From nobody Sun Aug 1 14:11:21 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 522293A1118 for ; Sun, 1 Aug 2021 14:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 CcrjP-mK5DeK for ; Sun, 1 Aug 2021 14:11:14 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FBB33A1110 for ; Sun, 1 Aug 2021 14:11:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4GdDMQ0MKjz1nwgs; Sun, 1 Aug 2021 14:11:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1627852274; bh=FcntLgJ92H9Erhp27O8UFwCkB9DQBK96Gcq8fYt5CEA=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=hCY6WEy1lZkJmVKR+NNRmIbUfwq5j225d6r3hNKxfIGcOl2k8wlp9ITZHro1RsDix KBgVQzeEdn35GQsJo8xgagjL62QZVwBlSGJzignA+BKM/RJwyvZnI59lcMrZ6GGBTa wI1cd0eIKhl9s6Xq8de29g/8LSvzkcsLDKOJypu0= X-Quarantine-ID: <2_Q4J0Czi8bZ> X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.23.64] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4GdDMP3qvlz1nwXC; Sun, 1 Aug 2021 14:11:13 -0700 (PDT) To: Michael StJohns Cc: rfced-future@iab.org References: <6b5f89e8-2d79-016b-65bb-39704c438e96@nthpermutation.com> <2739d8af-209a-6714-c21c-d723fbd941fd@joelhalpern.com> <59a3aeda-0a76-eed9-70ac-ad2739c15eb5@nthpermutation.com> From: "Joel M. Halpern" Message-ID: Date: Sun, 1 Aug 2021 17:11:12 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <59a3aeda-0a76-eed9-70ac-ad2739c15eb5@nthpermutation.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Replacement text for Section 4.2 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Aug 2021 21:11:19 -0000 I am not following the bottom part of your note. We are not a government agency, subject to government contracting regulations. As far as I know, the restrictions on a company for hiring and firing contractors is always more generous than for employees. The closest I have gotten in a review to knowing what the comments were from other people was when my boss at my first job out of school told me that he had received complaints (no idea of number, I did not get to see the complaints) that I typed too loudly. (I took this as a sign that I should work somewhere else.) I would expect that the LLC would want to get concerns discussed (which is why I raised the question to see if others agreed that an aggregating question was acceptable. Forwarding the actual responses (even somewhat redacted) seems likely to cause problems. Among other things, it seems likely to discourage negative feedback. Sure, a law suit can of course be filed in the US under almost any circumstance. And can attempt to subpoena almost anything. But that does not justify over-sharing information during the normal process. Yours, Joel On 8/1/2021 4:48 PM, Michael StJohns wrote: > Let me break this down into two section:  1) What is the scope of > confidentiality?  2) What does the RSEA get to see and comment on prior > to it going to the LLC - if anything? > > For confidentiality, I have these questions: > > 1) Are truly anonymous comments permitted? > 2) Does the IED get to see all of the comments with the source unredacted? > 3) Does the RSAB get to see all of the comments? >    3a) paraphrased? >    3b) source unredacted? >    3c) source redacted? >       3c.1) With redactors comment on the source? >       3c.2) Without comment > 4) Does the LLC get to see all of the comments? >    4a) paraphrased? >    4b) source unredacted? >    4c) source redacted? >        4c.1) With redactors comment on the source >        4c.2) Without comment on the source > > I assume that if the IED gets to see all comments, they will act as > redactor for any further distribution if redaction is required. > > In the draft I assumed that 1, 2), 3c.1), and 4c.1) were the answers to > the above questions because of the comments that were made by the call > about confidentiality.    Obviously, if the LLC and the RSAB get to see > everything, there won't be a redaction and comment on the source > necessary.   If the LLC doesn't get to see everything, then it at least > needs the context of possible biases from the submitters of the comments > to help it understand the reality on the ground. > > For the RSEA, I believe that it needs to be a bit more that Joel > suggests below - and instead we should be making sure that any comment > that will be considered by the LLC has to be provided to the RSEA for > feedback and rebuttal in at least a paraphrased form.  I don't think the > RSEA gets to know about any of the sources, but it seems both unfair and > legally fraught not to provide them with an opportunity to make an > opposing case for any negative comments. > > And I'm glad that EKR brought up "legal".   Unlike the Nomcom process > there is/will be a financial relationship between the LLC and the RSEA > in the form of either an employment agreement or contract.   In the > event that the LLC moves to terminate that relationship, if the RSEA > feels it is being done for "unfair" reasons and can make a case to a > legal standard in the appropriate legal venue, _*each and every comment, > and all emails and notes discussing those comments will be subject to > subpoena and the related depositions*_. > > And lastly - no company I know of solicits company wide comments (unless > the company is really tiny) on a particular employee's performance, nor > does the manager not know who made the comment and hence that manager > can accurately weigh said comments.  It would be a truly bad manager > that did not ask an employee about their take on any  negative comments > the manager received and the manager should help them redress any actual > problems. > > Mike > > > ps - Martin - "derogatory" is a term of art, mostly used related to > credit worthiness,   it differs from negative, in that the derogatory > info may affect the credit score, but there might be other negative > information that can't be taken into account due to legal issues (e.g. > for this "the RSEA is too old for the job" would be a negative comment, > but not a derogatory one as age discrimination is generally prohibited > and the comment couldn't be considered and would need to be discarded > when received).   Happy though to change to "negative and positive" vice > derogatory. > > > > On 7/29/2021 11:49 PM, Joel M. Halpern wrote: >> I mostly agree with Ekr here. >> >> The only edge case I see is one that I know has come up with nomcoms. >> If nomcoms see a pattern of reports of an issue, they have been known >> to say to a candidate "there have been issues raised about X.  Do you >> have any comment on that?"   This is not the same as showing the >> candidate the feedback, even sanitized. It does reveal that >> information has been provided.  (And, even more importantly, ti does >> not give even a large portion of the feedback.)  The nomcoms where I >> know this came up concluded that the combination of seeing the >> candidates reaction and giving then a chance to respond was worth >> pushing that envelop.   Do we consider that the selection committee or >> LLC or someone has that right under this process already?  Do we want >> to say anything about it? >> >> Yours, >> Joel >> >> On 7/29/2021 11:34 PM, Eric Rescorla wrote: >>> >>> >>> On Thu, Jul 29, 2021 at 5:00 PM Michael StJohns >>> > wrote: >>> >>>     Replacement for section 4.2: >>> >>>               <<< Set a schedule - could be omitted, but this is a >>>     promise to >>>     the community >>> >>>                      as well as a schedule for the IED/RSEA >>> >>>          No more often than semi-annually nor less often than >>> bi-yearly, the >>>          IETF Executive Director will send out to the community a >>> call for >>>          input on the performance of the RSEA. >>> >>>           <<< Separate the IED's recommendation from the feedback >>> process - >>> >>>            there may not actually be an action that needs an immediate >>>     recommendation >>> >>> >>>          <<<< the IED acts as the confidentiality mediator, anonymous >>> and >>>     confidential >>> >>>                   comments get tagged in the document that goes to the >>>     LLC - >>>     this provides >>> >>>                   needed context. >>>> >>>          The IETF Executive Director and the stream managers will >>> review the >>>          received feedback and produce a draft summary (a paraphrase) >>>          including both positive and derogatory information. Any >>> feedback >>>          provided anonymously shall be tagged as such in the summary. >>> Any >>>          feedback provided with a request for confidentiality shall >>> likewise >>>          be tagged in the summary and the IETF Executive Director MAY >>>          comment on the weight that may be appropriate to apply to the >>>          comment based on their knowledge of the submitter.  The stream >>>          managers should ensure that any of their concerns are added >>> to the >>>          document at this point and MAY also provide any commentary >>> on the >>>          externally provided feedback that they feel appropriate. >>> >>>          <<< Make sure that the LLC hears both sides of the coin >>> >>>          That draft feedback, redacted with respect to any names >>> associated >>>          with confidential comments and with respect to the IED's weight >>>          evaluations, shall be provided to the RSEA with for comment or >>>          rebuttal, and such comments shall be incorporated as an >>> appendix to >>>          the final feedback document provided to the IETF LLC Board. >>> >>> >>> This doesn't seem appropriate to me. >>> >>> If people want to provide confidential comments, then they shouldn't >>> be supplied to the RSEA, >>> nor should the IED's weights. This is not a legal proceeding, it's a >>> performance review, and >>> there's no generic reason that the RSEA should get to hear all the >>> feedback that the LLC is >>> receiving. >>> >>> -Ekr >>> >>> > From nobody Sun Aug 1 14:36:59 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1931D3A1283 for ; Sun, 1 Aug 2021 14:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.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 FujuJZOHVn1d for ; Sun, 1 Aug 2021 14:36:54 -0700 (PDT) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (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 86EF23A127F for ; Sun, 1 Aug 2021 14:36:54 -0700 (PDT) Received: by mail-qt1-x829.google.com with SMTP id h10so10454558qth.5 for ; Sun, 01 Aug 2021 14:36:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=oNUIkQ1Y2ZwsQvWNdDieKIYEGmMMOEnASlYDwUkYZTM=; b=yV0embgpN0rBH4OWt5frewqVl9qAVHYmJcAaqDoZO8ZTFw3XeK73xQteJNEmrB1eTa 5rL4QJxktd/1ACfz7XzS1PoN1Fp2gjHDM9/EAGd4xtI1Ap1fjeTyTUXhoWG104ig7ugq K/7yN8dF+sW5E1blsE4WZH5cUS3OgahwFF8gPH8AY5xsGdMEmhLHsqRNF2d3GBr02bTr D1TlrLYd2Lnc8LJ1QC7xHNk2H4Uwd8RZGYlbs+ub2oYl5dixYn3QsCydr0qdr9rSMRBm cHEm7dLAIPkU6jbqUDTK5VFjLAbaj+IAGNYEbktlMQLt1MSvDDZT21M/XIAgOB+S1Ykd Y/Bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=oNUIkQ1Y2ZwsQvWNdDieKIYEGmMMOEnASlYDwUkYZTM=; b=TDao+5FXOvLsIxH7QeYJv1Sue86K3GB+xEjNPyUukPjRqQIzV/vhOkrnvgJ7bUqFJL m53BA73NEBi0EXqrX3KCChc0Pbsc1Wnr3yi7M7NhRxtcKtc7KDxDkQWaK0JpsDySGOEj j9Ud2E/aF7uvqIoO7ZbJjUr3g/th6JBYYakliE+iJ4n2Gw+QaRXZG+8Mn5CHX83hQo+p i0Y6vJld68QLsdv1+HFqB6dK+BdkBi3ObMn6LWuYPGYRQwJXEs5UK0i+HW96GEJ5xtJf 8Ri7UXp4tioHWHirveGgJ/KOHFrOwWQoAsAUWVrctj2aOUqqiHf2tZTg3cRfvUVip/r7 md3g== X-Gm-Message-State: AOAM531P/2uUis6aebgoTuVp/ck2+YhnhIzHdugZcYujfuskdRKbbBsX +4YXDoiJb10O6zsy7hwbxvzlsHbfW/9CnWsW X-Google-Smtp-Source: ABdhPJxpnTVIADbH+xFUuZVKm+T/BqmIRIlw2hYZHaAjIhZNvvHA70TOn3Bsq0LhiXMegZn5zCyTjw== X-Received: by 2002:a05:622a:1489:: with SMTP id t9mr11523534qtx.302.1627853812444; Sun, 01 Aug 2021 14:36:52 -0700 (PDT) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id b204sm4661247qkg.76.2021.08.01.14.36.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 01 Aug 2021 14:36:51 -0700 (PDT) To: "Joel M. Halpern" Cc: rfced-future@iab.org References: <6b5f89e8-2d79-016b-65bb-39704c438e96@nthpermutation.com> <2739d8af-209a-6714-c21c-d723fbd941fd@joelhalpern.com> <59a3aeda-0a76-eed9-70ac-ad2739c15eb5@nthpermutation.com> From: Michael StJohns Message-ID: Date: Sun, 1 Aug 2021 17:36:50 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Replacement text for Section 4.2 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Aug 2021 21:36:59 -0000 On 8/1/2021 5:11 PM, Joel M. Halpern wrote: > I am not following the bottom part of your note. > > We are not a government agency, subject to government contracting > regulations. I know that - but we are a non-profit corporation incorporated within US and mostly subject to US labor laws and practices.  All I'm saying is that telling people that their comments will always remain confidential may run up against the law which says that's not the case. > As far as I know, the restrictions on a company for hiring and firing > contractors is always more generous than for employees.  The closest I > have gotten in a review to knowing what the comments were from other > people was when my boss at my first job out of school told me that he > had received complaints (no idea of number, I did not get to see the > complaints) that I typed too loudly.   (I took this as a sign that I > should work somewhere else.) It a) depends on the contract - board members and C-suite staff contracts tend to have some pretty interesting poison pills as do by-name contracts for people with rare skills, but the typical employee is at-will and can be fired for any reason*, and b) it depends on the country or state.     *As long as those reasons don't implicate a few fair labor laws and regulations such as age, gender, race, national origin, political and religious beliefs, etc. Re your comment - I took this that your boss had a sense of humor and provided you with information that had no effect on your actual review and compensation.  The key thing here is that your boss knew who said what, and you were given an opportunity to hear the issue. > > I would expect that the LLC would want to get concerns discussed > (which is why I raised the question to see if others agreed that an > aggregating question was acceptable. > > Forwarding the actual responses (even somewhat redacted) seems likely > to cause problems.   Among other things, it seems likely to discourage > negative feedback. Contrariwise, not providing negative feedback to the RSEA is unlikely to result in any improvements if they are warranted.  And given this community, it's possible that the RSEA can provide missing context on a prospectively negative comment to assist the LLC in deciding what actions need to be taken. And sorry - I'm not sure who gets to see the actual results in your model.  Can you tell me what each of RSAB, IED, LLC and the RSEA see please? > > Sure, a law suit can of course be filed in the US under almost any > circumstance.  And can attempt to subpoena almost anything.  But that > does not justify over-sharing information during the normal process. I still hesitate to see how providing the RSEA a summary/redaction of the comments received and allowing them to provide a response is "over-sharing". Later, Mike > > Yours, > Joel > > On 8/1/2021 4:48 PM, Michael StJohns wrote: >> Let me break this down into two section: 1) What is the scope of >> confidentiality?  2) What does the RSEA get to see and comment on >> prior to it going to the LLC - if anything? >> >> For confidentiality, I have these questions: >> >> 1) Are truly anonymous comments permitted? >> 2) Does the IED get to see all of the comments with the source >> unredacted? >> 3) Does the RSAB get to see all of the comments? >>     3a) paraphrased? >>     3b) source unredacted? >>     3c) source redacted? >>        3c.1) With redactors comment on the source? >>        3c.2) Without comment >> 4) Does the LLC get to see all of the comments? >>     4a) paraphrased? >>     4b) source unredacted? >>     4c) source redacted? >>         4c.1) With redactors comment on the source >>         4c.2) Without comment on the source >> >> I assume that if the IED gets to see all comments, they will act as >> redactor for any further distribution if redaction is required. >> >> In the draft I assumed that 1, 2), 3c.1), and 4c.1) were the answers >> to the above questions because of the comments that were made by the >> call about confidentiality.    Obviously, if the LLC and the RSAB get >> to see everything, there won't be a redaction and comment on the >> source necessary.   If the LLC doesn't get to see everything, then it >> at least needs the context of possible biases from the submitters of >> the comments to help it understand the reality on the ground. >> >> For the RSEA, I believe that it needs to be a bit more that Joel >> suggests below - and instead we should be making sure that any >> comment that will be considered by the LLC has to be provided to the >> RSEA for feedback and rebuttal in at least a paraphrased form.  I >> don't think the RSEA gets to know about any of the sources, but it >> seems both unfair and legally fraught not to provide them with an >> opportunity to make an opposing case for any negative comments. >> >> And I'm glad that EKR brought up "legal".   Unlike the Nomcom process >> there is/will be a financial relationship between the LLC and the >> RSEA in the form of either an employment agreement or contract.   In >> the event that the LLC moves to terminate that relationship, if the >> RSEA feels it is being done for "unfair" reasons and can make a case >> to a legal standard in the appropriate legal venue, _*each and every >> comment, and all emails and notes discussing those comments will be >> subject to subpoena and the related depositions*_. >> >> And lastly - no company I know of solicits company wide comments >> (unless the company is really tiny) on a particular employee's >> performance, nor does the manager not know who made the comment and >> hence that manager can accurately weigh said comments.  It would be a >> truly bad manager that did not ask an employee about their take on >> any  negative comments the manager received and the manager should >> help them redress any actual problems. >> >> Mike >> >> >> ps - Martin - "derogatory" is a term of art, mostly used related to >> credit worthiness,   it differs from negative, in that the derogatory >> info may affect the credit score, but there might be other negative >> information that can't be taken into account due to legal issues >> (e.g. for this "the RSEA is too old for the job" would be a negative >> comment, but not a derogatory one as age discrimination is generally >> prohibited and the comment couldn't be considered and would need to >> be discarded when received). Happy though to change to "negative and >> positive" vice derogatory. >> >> >> >> On 7/29/2021 11:49 PM, Joel M. Halpern wrote: >>> I mostly agree with Ekr here. >>> >>> The only edge case I see is one that I know has come up with >>> nomcoms. If nomcoms see a pattern of reports of an issue, they have >>> been known to say to a candidate "there have been issues raised >>> about X.  Do you have any comment on that?"   This is not the same >>> as showing the candidate the feedback, even sanitized. It does >>> reveal that information has been provided. (And, even more >>> importantly, ti does not give even a large portion of the >>> feedback.)  The nomcoms where I know this came up concluded that the >>> combination of seeing the candidates reaction and giving then a >>> chance to respond was worth pushing that envelop.   Do we consider >>> that the selection committee or LLC or someone has that right under >>> this process already?  Do we want to say anything about it? >>> >>> Yours, >>> Joel >>> >>> On 7/29/2021 11:34 PM, Eric Rescorla wrote: >>>> >>>> >>>> On Thu, Jul 29, 2021 at 5:00 PM Michael StJohns >>>> > wrote: >>>> >>>>     Replacement for section 4.2: >>>> >>>>               <<< Set a schedule - could be omitted, but this is a >>>>     promise to >>>>     the community >>>> >>>>                      as well as a schedule for the IED/RSEA >>> >>>>          No more often than semi-annually nor less often than >>>> bi-yearly, the >>>>          IETF Executive Director will send out to the community a >>>> call for >>>>          input on the performance of the RSEA. >>>> >>>>           <<< Separate the IED's recommendation from the feedback >>>> process - >>>> >>>>            there may not actually be an action that needs an immediate >>>>     recommendation >>> >>>> >>>>          <<<< the IED acts as the confidentiality mediator, >>>> anonymous and >>>>     confidential >>>> >>>>                   comments get tagged in the document that goes to the >>>>     LLC - >>>>     this provides >>>> >>>>                   needed context. >>>> >>>>          The IETF Executive Director and the stream managers will >>>> review the >>>>          received feedback and produce a draft summary (a paraphrase) >>>>          including both positive and derogatory information. Any >>>> feedback >>>>          provided anonymously shall be tagged as such in the >>>> summary. Any >>>>          feedback provided with a request for confidentiality shall >>>> likewise >>>>          be tagged in the summary and the IETF Executive Director MAY >>>>          comment on the weight that may be appropriate to apply to the >>>>          comment based on their knowledge of the submitter. The stream >>>>          managers should ensure that any of their concerns are >>>> added to the >>>>          document at this point and MAY also provide any commentary >>>> on the >>>>          externally provided feedback that they feel appropriate. >>>> >>>>          <<< Make sure that the LLC hears both sides of the coin >>> >>>>          That draft feedback, redacted with respect to any names >>>> associated >>>>          with confidential comments and with respect to the IED's >>>> weight >>>>          evaluations, shall be provided to the RSEA with for >>>> comment or >>>>          rebuttal, and such comments shall be incorporated as an >>>> appendix to >>>>          the final feedback document provided to the IETF LLC Board. >>>> >>>> >>>> This doesn't seem appropriate to me. >>>> >>>> If people want to provide confidential comments, then they >>>> shouldn't be supplied to the RSEA, >>>> nor should the IED's weights. This is not a legal proceeding, it's >>>> a performance review, and >>>> there's no generic reason that the RSEA should get to hear all the >>>> feedback that the LLC is >>>> receiving. >>>> >>>> -Ekr >>>> >>>> >> From nobody Sun Aug 1 14:54:03 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5E33A1403 for ; Sun, 1 Aug 2021 14:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 bErGm296fpJe for ; Sun, 1 Aug 2021 14:53:55 -0700 (PDT) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 9B7C23A1400 for ; Sun, 1 Aug 2021 14:53:55 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id r18so18163958iot.4 for ; Sun, 01 Aug 2021 14:53:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jUF3TD1gDk5W3Yr8ZY5AOdgEH/tz8GtRI0PtwAOZlHY=; b=cFkCaVet5sEN/an1i4q0Edem/+3w7NGk4ngt2uEwcC/lEwFjFEWE4rCoDLt5qpzuSH 6OKvaLfTSIuoJr6hA8Z3EkBPmNHxFanXxqip1nJ6kO7VCyBBGMvFT7FzNhT73980KXxf FfXFyED40hq6ZqbplaTP7R1YyVHoQvQlsoG9rFYEHdNi95E8xTQ+titJAZNe9vq+eHTT nPIGOjCd9L2F9El+jbJq68FRY0AwMXU1dOhFXmusdIEvT4HZdXZCS3okrOIbY0uwLLo7 CudGtT+I7w4SXEfnZSUPfz9m8M/0HMlabBacAvbNRZAJHi/i6JlNc7lb3J8ZrTOinqId +4fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jUF3TD1gDk5W3Yr8ZY5AOdgEH/tz8GtRI0PtwAOZlHY=; b=hJuFd9NNR6W3RRX4+LmPkqhcN8r+mVmFsugrtJD9JoT9nzBDNc0cX1Jiw0V4Inx347 bRMLjcnyPYbb/oh/siumwlOZ2yLQ/U13q4HFuGvG+64wtVFC8SUQK8kEamlUpD7eoSnj PoajqR+pGOylKPHuLPEbh9BYTDur1i8tNUY7QCzk2NylPIa43GK3i5irx0PJIsCcs4HM idYApZoxAcrP6b6Pfku4utOj/Zwv86HsgHuD2NvROioCx7qly37J2uk/yPfNgoRGFiPl uwm9FjrCYhHYVwQvBjKO14WpGpfctyImJdxKGS46NwNPAsTYMf9QWTz8Q0rl3bUziT1O DNww== X-Gm-Message-State: AOAM532x9mJQuzHFHo0oPPFPiKrHS2XS7fYgCIUtMC5fYaRqdkgNtTqu yoDAwkZaxqIRQ85vzu914RCY70Iwvthtg4As6SGJa077C+x8+w== X-Google-Smtp-Source: ABdhPJwpWXZso8/XfmrpJ6Z+u1Fk7+pBaS4FW/djHp+TY79hOjDo/1jD97vGCf347G59RVTY4jA7qiHbFKOuYchhWPk= X-Received: by 2002:a05:6638:24c3:: with SMTP id y3mr11755302jat.10.1627854833419; Sun, 01 Aug 2021 14:53:53 -0700 (PDT) MIME-Version: 1.0 References: <6b5f89e8-2d79-016b-65bb-39704c438e96@nthpermutation.com> <2739d8af-209a-6714-c21c-d723fbd941fd@joelhalpern.com> <59a3aeda-0a76-eed9-70ac-ad2739c15eb5@nthpermutation.com> In-Reply-To: From: Eric Rescorla Date: Sun, 1 Aug 2021 14:53:17 -0700 Message-ID: To: Michael StJohns Cc: "Joel M. Halpern" , rfced-future@iab.org Content-Type: multipart/alternative; boundary="000000000000179ab905c8867d1e" Archived-At: Subject: Re: [Rfced-future] Replacement text for Section 4.2 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Aug 2021 21:54:01 -0000 --000000000000179ab905c8867d1e Content-Type: text/plain; charset="UTF-8" It might be useful to distinguish here between what we think is good practice and what this RFC is going to require. In general, the executive management of a company has a fair amount of latitude in what kind of HR practices they want to employ (subject to local law, of course) They can do 360 reviews or not, solicit peer feedback or not, share it with the employee or not, etc. I would expect the same here, with the LLC and the IED being responsible for making those decisions. For us to put specific requirements about how that feedback is collected and shared is a bit like writing that into the company bylaws. Perhaps there is some point which is truly necessary to be encoded in such a way that it constrains the LLC but none of this text seems to me to fit that bill. What I would prefer, therefore, is to omit essentially all of this material. To the extent to which the community wishes to have input on those processes, well, that's why the LLC board is answerable to the community. And of course the RSWG can always write an RFC to add new requirements if it deems it necessary in the future. -Ekr On Sun, Aug 1, 2021 at 2:37 PM Michael StJohns wrote: > On 8/1/2021 5:11 PM, Joel M. Halpern wrote: > > I am not following the bottom part of your note. > > > > We are not a government agency, subject to government contracting > > regulations. > > I know that - but we are a non-profit corporation incorporated within US > and mostly subject to US labor laws and practices. All I'm saying is > that telling people that their comments will always remain confidential > may run up against the law which says that's not the case. > > > As far as I know, the restrictions on a company for hiring and firing > > contractors is always more generous than for employees. The closest I > > have gotten in a review to knowing what the comments were from other > > people was when my boss at my first job out of school told me that he > > had received complaints (no idea of number, I did not get to see the > > complaints) that I typed too loudly. (I took this as a sign that I > > should work somewhere else.) > > It a) depends on the contract - board members and C-suite staff > contracts tend to have some pretty interesting poison pills as do > by-name contracts for people with rare skills, but the typical employee > is at-will and can be fired for any reason*, and b) it depends on the > country or state. *As long as those reasons don't implicate a few > fair labor laws and regulations such as age, gender, race, national > origin, political and religious beliefs, etc. > > Re your comment - I took this that your boss had a sense of humor and > provided you with information that had no effect on your actual review > and compensation. The key thing here is that your boss knew who said > what, and you were given an opportunity to hear the issue. > > > > > I would expect that the LLC would want to get concerns discussed > > (which is why I raised the question to see if others agreed that an > > aggregating question was acceptable. > > > > > > Forwarding the actual responses (even somewhat redacted) seems likely > > to cause problems. Among other things, it seems likely to discourage > > negative feedback. > > Contrariwise, not providing negative feedback to the RSEA is unlikely to > result in any improvements if they are warranted. And given this > community, it's possible that the RSEA can provide missing context on a > prospectively negative comment to assist the LLC in deciding what > actions need to be taken. > > And sorry - I'm not sure who gets to see the actual results in your > model. Can you tell me what each of RSAB, IED, LLC and the RSEA see > please? > > > > > > Sure, a law suit can of course be filed in the US under almost any > > circumstance. And can attempt to subpoena almost anything. But that > > does not justify over-sharing information during the normal process. > > I still hesitate to see how providing the RSEA a summary/redaction of > the comments received and allowing them to provide a response is > "over-sharing". > > > Later, Mike > > > > > > > Yours, > > Joel > > > > On 8/1/2021 4:48 PM, Michael StJohns wrote: > >> Let me break this down into two section: 1) What is the scope of > >> confidentiality? 2) What does the RSEA get to see and comment on > >> prior to it going to the LLC - if anything? > >> > >> For confidentiality, I have these questions: > >> > >> 1) Are truly anonymous comments permitted? > >> 2) Does the IED get to see all of the comments with the source > >> unredacted? > >> 3) Does the RSAB get to see all of the comments? > >> 3a) paraphrased? > >> 3b) source unredacted? > >> 3c) source redacted? > >> 3c.1) With redactors comment on the source? > >> 3c.2) Without comment > >> 4) Does the LLC get to see all of the comments? > >> 4a) paraphrased? > >> 4b) source unredacted? > >> 4c) source redacted? > >> 4c.1) With redactors comment on the source > >> 4c.2) Without comment on the source > >> > >> I assume that if the IED gets to see all comments, they will act as > >> redactor for any further distribution if redaction is required. > >> > >> In the draft I assumed that 1, 2), 3c.1), and 4c.1) were the answers > >> to the above questions because of the comments that were made by the > >> call about confidentiality. Obviously, if the LLC and the RSAB get > >> to see everything, there won't be a redaction and comment on the > >> source necessary. If the LLC doesn't get to see everything, then it > >> at least needs the context of possible biases from the submitters of > >> the comments to help it understand the reality on the ground. > >> > >> For the RSEA, I believe that it needs to be a bit more that Joel > >> suggests below - and instead we should be making sure that any > >> comment that will be considered by the LLC has to be provided to the > >> RSEA for feedback and rebuttal in at least a paraphrased form. I > >> don't think the RSEA gets to know about any of the sources, but it > >> seems both unfair and legally fraught not to provide them with an > >> opportunity to make an opposing case for any negative comments. > >> > >> And I'm glad that EKR brought up "legal". Unlike the Nomcom process > >> there is/will be a financial relationship between the LLC and the > >> RSEA in the form of either an employment agreement or contract. In > >> the event that the LLC moves to terminate that relationship, if the > >> RSEA feels it is being done for "unfair" reasons and can make a case > >> to a legal standard in the appropriate legal venue, _*each and every > >> comment, and all emails and notes discussing those comments will be > >> subject to subpoena and the related depositions*_. > >> > >> And lastly - no company I know of solicits company wide comments > >> (unless the company is really tiny) on a particular employee's > >> performance, nor does the manager not know who made the comment and > >> hence that manager can accurately weigh said comments. It would be a > >> truly bad manager that did not ask an employee about their take on > >> any negative comments the manager received and the manager should > >> help them redress any actual problems. > >> > >> Mike > >> > >> > >> ps - Martin - "derogatory" is a term of art, mostly used related to > >> credit worthiness, it differs from negative, in that the derogatory > >> info may affect the credit score, but there might be other negative > >> information that can't be taken into account due to legal issues > >> (e.g. for this "the RSEA is too old for the job" would be a negative > >> comment, but not a derogatory one as age discrimination is generally > >> prohibited and the comment couldn't be considered and would need to > >> be discarded when received). Happy though to change to "negative and > >> positive" vice derogatory. > >> > >> > >> > >> On 7/29/2021 11:49 PM, Joel M. Halpern wrote: > >>> I mostly agree with Ekr here. > >>> > >>> The only edge case I see is one that I know has come up with > >>> nomcoms. If nomcoms see a pattern of reports of an issue, they have > >>> been known to say to a candidate "there have been issues raised > >>> about X. Do you have any comment on that?" This is not the same > >>> as showing the candidate the feedback, even sanitized. It does > >>> reveal that information has been provided. (And, even more > >>> importantly, ti does not give even a large portion of the > >>> feedback.) The nomcoms where I know this came up concluded that the > >>> combination of seeing the candidates reaction and giving then a > >>> chance to respond was worth pushing that envelop. Do we consider > >>> that the selection committee or LLC or someone has that right under > >>> this process already? Do we want to say anything about it? > >>> > >>> Yours, > >>> Joel > >>> > >>> On 7/29/2021 11:34 PM, Eric Rescorla wrote: > >>>> > >>>> > >>>> On Thu, Jul 29, 2021 at 5:00 PM Michael StJohns > >>>> > wrote: > >>>> > >>>> Replacement for section 4.2: > >>>> > >>>> <<< Set a schedule - could be omitted, but this is a > >>>> promise to > >>>> the community > >>>> > >>>> as well as a schedule for the IED/RSEA >>> > >>>> No more often than semi-annually nor less often than > >>>> bi-yearly, the > >>>> IETF Executive Director will send out to the community a > >>>> call for > >>>> input on the performance of the RSEA. > >>>> > >>>> <<< Separate the IED's recommendation from the feedback > >>>> process - > >>>> > >>>> there may not actually be an action that needs an immediate > >>>> recommendation >>> > >>>> > >>>> <<<< the IED acts as the confidentiality mediator, > >>>> anonymous and > >>>> confidential > >>>> > >>>> comments get tagged in the document that goes to the > >>>> LLC - > >>>> this provides > >>>> > >>>> needed context. >>>> > >>>> The IETF Executive Director and the stream managers will > >>>> review the > >>>> received feedback and produce a draft summary (a paraphrase) > >>>> including both positive and derogatory information. Any > >>>> feedback > >>>> provided anonymously shall be tagged as such in the > >>>> summary. Any > >>>> feedback provided with a request for confidentiality shall > >>>> likewise > >>>> be tagged in the summary and the IETF Executive Director MAY > >>>> comment on the weight that may be appropriate to apply to the > >>>> comment based on their knowledge of the submitter. The stream > >>>> managers should ensure that any of their concerns are > >>>> added to the > >>>> document at this point and MAY also provide any commentary > >>>> on the > >>>> externally provided feedback that they feel appropriate. > >>>> > >>>> <<< Make sure that the LLC hears both sides of the coin >>> > >>>> That draft feedback, redacted with respect to any names > >>>> associated > >>>> with confidential comments and with respect to the IED's > >>>> weight > >>>> evaluations, shall be provided to the RSEA with for > >>>> comment or > >>>> rebuttal, and such comments shall be incorporated as an > >>>> appendix to > >>>> the final feedback document provided to the IETF LLC Board. > >>>> > >>>> > >>>> This doesn't seem appropriate to me. > >>>> > >>>> If people want to provide confidential comments, then they > >>>> shouldn't be supplied to the RSEA, > >>>> nor should the IED's weights. This is not a legal proceeding, it's > >>>> a performance review, and > >>>> there's no generic reason that the RSEA should get to hear all the > >>>> feedback that the LLC is > >>>> receiving. > >>>> > >>>> -Ekr > >>>> > >>>> > >> > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > --000000000000179ab905c8867d1e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It might be useful to distinguish here between what w= e think is good practice and what this RFC is going to require.
<= br>
In general, the executive management of a company has a fair = amount of latitude in what kind of HR practices they want to employ (subjec= t to local law, of course) They can do 360 reviews or not, solicit peer fee= dback or not, share it with the employee or not, etc. I would expect the sa= me here, with the LLC and the IED being responsible for making those decisi= ons. For us to put specific requirements about how that feedback is collect= ed and shared is a bit like writing that into the company bylaws. Perhaps t= here is some point which is truly necessary to be encoded in such a way tha= t it constrains the LLC but none of this text seems to me to fit that bill.=

What I would prefer, therefore, is to omit es= sentially all of this material. To the extent to which the community wishes= to have input on those processes, well, that's why the LLC board is an= swerable to the community. And of course the RSWG can always write an RFC t= o add new requirements if it deems it necessary in the future.

-Ekr


On Sun, Aug 1, 2021 at 2:37 PM Mi= chael StJohns <msj@nthpermutat= ion.com> wrote:
On 8/1/2021 5:11 PM, Joel M. Halpern wrote:
> I am not following the bottom part of your note.
>
> We are not a government agency, subject to government contracting
> regulations.

I know that - but we are a non-profit corporation incorporated within US and mostly subject to US labor laws and practices.=C2=A0 All I'm saying= is
that telling people that their comments will always remain confidential may run up against the law which says that's not the case.

> As far as I know, the restrictions on a company for hiring and firing =
> contractors is always more generous than for employees.=C2=A0 The clos= est I
> have gotten in a review to knowing what the comments were from other <= br> > people was when my boss at my first job out of school told me that he =
> had received complaints (no idea of number, I did not get to see the <= br> > complaints) that I typed too loudly.=C2=A0=C2=A0 (I took this as a sig= n that I
> should work somewhere else.)

It a) depends on the contract - board members and C-suite staff
contracts tend to have some pretty interesting poison pills as do
by-name contracts for people with rare skills, but the typical employee is at-will and can be fired for any reason*, and b) it depends on the
country or state.=C2=A0=C2=A0=C2=A0=C2=A0 *As long as those reasons don'= ;t implicate a few
fair labor laws and regulations such as age, gender, race, national
origin, political and religious beliefs, etc.

Re your comment - I took this that your boss had a sense of humor and
provided you with information that had no effect on your actual review
and compensation.=C2=A0 The key thing here is that your boss knew who said =
what, and you were given an opportunity to hear the issue.

>
> I would expect that the LLC would want to get concerns discussed
> (which is why I raised the question to see if others agreed that an > aggregating question was acceptable.


>
> Forwarding the actual responses (even somewhat redacted) seems likely =
> to cause problems.=C2=A0=C2=A0 Among other things, it seems likely to = discourage
> negative feedback.

Contrariwise, not providing negative feedback to the RSEA is unlikely to result in any improvements if they are warranted.=C2=A0 And given this
community, it's possible that the RSEA can provide missing context on a=
prospectively negative comment to assist the LLC in deciding what
actions need to be taken.

And sorry - I'm not sure who gets to see the actual results in your model.=C2=A0 Can you tell me what each of RSAB, IED, LLC and the RSEA see p= lease?


>
> Sure, a law suit can of course be filed in the US under almost any > circumstance.=C2=A0 And can attempt to subpoena almost anything.=C2=A0= But that
> does not justify over-sharing information during the normal process.
I still hesitate to see how providing the RSEA a summary/redaction of
the comments received and allowing them to provide a response is
"over-sharing".


Later, Mike



>
> Yours,
> Joel
>
> On 8/1/2021 4:48 PM, Michael StJohns wrote:
>> Let me break this down into two section: 1) What is the scope of <= br> >> confidentiality?=C2=A0 2) What does the RSEA get to see and commen= t on
>> prior to it going to the LLC - if anything?
>>
>> For confidentiality, I have these questions:
>>
>> 1) Are truly anonymous comments permitted?
>> 2) Does the IED get to see all of the comments with the source >> unredacted?
>> 3) Does the RSAB get to see all of the comments?
>> =C2=A0=C2=A0=C2=A0 3a) paraphrased?
>> =C2=A0=C2=A0=C2=A0 3b) source unredacted?
>> =C2=A0=C2=A0=C2=A0 3c) source redacted?
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 3c.1) With redactors comment = on the source?
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 3c.2) Without comment
>> 4) Does the LLC get to see all of the comments?
>> =C2=A0=C2=A0=C2=A0 4a) paraphrased?
>> =C2=A0=C2=A0=C2=A0 4b) source unredacted?
>> =C2=A0=C2=A0=C2=A0 4c) source redacted?
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 4c.1) With redactors co= mment on the source
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 4c.2) Without comment o= n the source
>>
>> I assume that if the IED gets to see all comments, they will act a= s
>> redactor for any further distribution if redaction is required. >>
>> In the draft I assumed that 1, 2), 3c.1), and 4c.1) were the answe= rs
>> to the above questions because of the comments that were made by t= he
>> call about confidentiality.=C2=A0=C2=A0=C2=A0 Obviously, if the LL= C and the RSAB get
>> to see everything, there won't be a redaction and comment on t= he
>> source necessary.=C2=A0=C2=A0 If the LLC doesn't get to see ev= erything, then it
>> at least needs the context of possible biases from the submitters = of
>> the comments to help it understand the reality on the ground.
>>
>> For the RSEA, I believe that it needs to be a bit more that Joel <= br> >> suggests below - and instead we should be making sure that any >> comment that will be considered by the LLC has to be provided to t= he
>> RSEA for feedback and rebuttal in at least a paraphrased form.=C2= =A0 I
>> don't think the RSEA gets to know about any of the sources, bu= t it
>> seems both unfair and legally fraught not to provide them with an =
>> opportunity to make an opposing case for any negative comments. >>
>> And I'm glad that EKR brought up "legal".=C2=A0=C2= =A0 Unlike the Nomcom process
>> there is/will be a financial relationship between the LLC and the =
>> RSEA in the form of either an employment agreement or contract.=C2= =A0=C2=A0 In
>> the event that the LLC moves to terminate that relationship, if th= e
>> RSEA feels it is being done for "unfair" reasons and can= make a case
>> to a legal standard in the appropriate legal venue, _*each and eve= ry
>> comment, and all emails and notes discussing those comments will b= e
>> subject to subpoena and the related depositions*_.
>>
>> And lastly - no company I know of solicits company wide comments <= br> >> (unless the company is really tiny) on a particular employee's=
>> performance, nor does the manager not know who made the comment an= d
>> hence that manager can accurately weigh said comments.=C2=A0 It wo= uld be a
>> truly bad manager that did not ask an employee about their take on=
>> any=C2=A0 negative comments the manager received and the manager s= hould
>> help them redress any actual problems.
>>
>> Mike
>>
>>
>> ps - Martin - "derogatory" is a term of art, mostly used= related to
>> credit worthiness,=C2=A0=C2=A0 it differs from negative, in that t= he derogatory
>> info may affect the credit score, but there might be other negativ= e
>> information that can't be taken into account due to legal issu= es
>> (e.g. for this "the RSEA is too old for the job" would b= e a negative
>> comment, but not a derogatory one as age discrimination is general= ly
>> prohibited and the comment couldn't be considered and would ne= ed to
>> be discarded when received). Happy though to change to "negat= ive and
>> positive" vice derogatory.
>>
>>
>>
>> On 7/29/2021 11:49 PM, Joel M. Halpern wrote:
>>> I mostly agree with Ekr here.
>>>
>>> The only edge case I see is one that I know has come up with <= br> >>> nomcoms. If nomcoms see a pattern of reports of an issue, they= have
>>> been known to say to a candidate "there have been issues = raised
>>> about X.=C2=A0 Do you have any comment on that?"=C2=A0=C2= =A0 This is not the same
>>> as showing the candidate the feedback, even sanitized. It does=
>>> reveal that information has been provided. (And, even more >>> importantly, ti does not give even a large portion of the
>>> feedback.)=C2=A0 The nomcoms where I know this came up conclud= ed that the
>>> combination of seeing the candidates reaction and giving then = a
>>> chance to respond was worth pushing that envelop.=C2=A0=C2=A0 = Do we consider
>>> that the selection committee or LLC or someone has that right = under
>>> this process already?=C2=A0 Do we want to say anything about i= t?
>>>
>>> Yours,
>>> Joel
>>>
>>> On 7/29/2021 11:34 PM, Eric Rescorla wrote:
>>>>
>>>>
>>>> On Thu, Jul 29, 2021 at 5:00 PM Michael StJohns
>>>> <msj@nthpermutation.com <mailto:msj@nthpermutation.com>> wrote:
>>>>
>>>> =C2=A0=C2=A0=C2=A0 Replacement for section 4.2:
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0= =C2=A0=C2=A0 <<< Set a schedule - could be omitted, but this is a<= br> >>>> =C2=A0=C2=A0=C2=A0 promise to
>>>> =C2=A0=C2=A0=C2=A0 the community
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 as well as a sche= dule for the IED/RSEA >>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 No more often = than semi-annually nor less often than
>>>> bi-yearly, the
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 IETF Executive= Director will send out to the community a
>>>> call for
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 input on the p= erformance of the RSEA.
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 <<= < Separate the IED's recommendation from the feedback
>>>> process -
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 th= ere may not actually be an action that needs an immediate
>>>> =C2=A0=C2=A0=C2=A0 recommendation >>>
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 <<<&l= t; the IED acts as the confidentiality mediator,
>>>> anonymous and
>>>> =C2=A0=C2=A0=C2=A0 confidential
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 comments get tagged in the document= that goes to the
>>>> =C2=A0=C2=A0=C2=A0 LLC -
>>>> =C2=A0=C2=A0=C2=A0 this provides
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 needed context. >>>> >>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 The IETF Execu= tive Director and the stream managers will
>>>> review the
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 received feedb= ack and produce a draft summary (a paraphrase)
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 including both= positive and derogatory information. Any
>>>> feedback
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 provided anony= mously shall be tagged as such in the
>>>> summary. Any
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 feedback provi= ded with a request for confidentiality shall
>>>> likewise
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 be tagged in t= he summary and the IETF Executive Director MAY
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 comment on the= weight that may be appropriate to apply to the
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 comment based = on their knowledge of the submitter. The stream
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 managers shoul= d ensure that any of their concerns are
>>>> added to the
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 document at th= is point and MAY also provide any commentary
>>>> on the
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 externally pro= vided feedback that they feel appropriate.
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 <<< M= ake sure that the LLC hears both sides of the coin >>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 That draft fee= dback, redacted with respect to any names
>>>> associated
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 with confident= ial comments and with respect to the IED's
>>>> weight
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 evaluations, s= hall be provided to the RSEA with for
>>>> comment or
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 rebuttal, and = such comments shall be incorporated as an
>>>> appendix to
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 the final feed= back document provided to the IETF LLC Board.
>>>>
>>>>
>>>> This doesn't seem appropriate to me.
>>>>
>>>> If people want to provide confidential comments, then they=
>>>> shouldn't be supplied to the RSEA,
>>>> nor should the IED's weights. This is not a legal proc= eeding, it's
>>>> a performance review, and
>>>> there's no generic reason that the RSEA should get to = hear all the
>>>> feedback that the LLC is
>>>> receiving.
>>>>
>>>> -Ekr
>>>>
>>>>
>>

--
Rfced-future mailing list
Rfced-future@iab.= org
https://www.iab.org/mailman/listinfo/rfced-future
--000000000000179ab905c8867d1e-- From nobody Sun Aug 1 15:10:41 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A9143A14CB for ; Sun, 1 Aug 2021 15:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.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 3YXsLas1Zk0m for ; Sun, 1 Aug 2021 15:10:34 -0700 (PDT) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 0883E3A14BE for ; Sun, 1 Aug 2021 15:10:33 -0700 (PDT) Received: by mail-qk1-x72f.google.com with SMTP id 190so14923488qkk.12 for ; Sun, 01 Aug 2021 15:10:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=BsglkP7lboUX2cHb3C+Q7HzElWK5RAp2rnuxGzkl0wg=; b=CTXkVIC4o53RadFCVs9SZaNjHw/URR4G16nC6Jp5fpmCvQRDF2azB5TaoLWOCTQQ3U g5QQYEHatYWnxFBVB6r/7vy5EuALZNjOlJBykupuxe+Y1Pa8cx+Y1gMp5m79CQURdL/G qZZDcZWNnwPqZEiil55c73vZb3t9e3QdcXI50sbMntx0P5MdkMt5Pau4HU900VUKEMAl f+cohB3/WZM/1EFQy84Iy1DphfbXrShZUYkabzmANRhXwDz7rxnuvVqdMTi8EQitJ9Vx nuzQo7PhLTyxUYrDSTMUy+vE688UMB8/ARRp6qDDkC/wk/gsSbIeTNFoYnj1ErtxIHu/ ux+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=BsglkP7lboUX2cHb3C+Q7HzElWK5RAp2rnuxGzkl0wg=; b=a5rpCACvzmftpQk1g7XFf7zP5Yt4uyMf0pLju5DHe06ElTw4LrXxlLMbh7l6W5Kcy/ kwVCPaUU91pAlTFKLIOBVPEOJpCQolrfAyA7VMsVOE8yPksTBCxlwaaQTUvQjz2XwKOO tEJDPZUH7wS1P19IGVZsJTBA/Np/19NM18tOt+fm6qK6kmNuJ06aacnlyyyBSi7YkaHl EsD4rguDbJ6JA/ZLI6CH2j7rKbRP0jb+sYDfAXePPrvejlJIPS2mQViyGuXaiSGaDPRP MLtwxM416UA1Zw3yD441VkzY6QtyExQoMkts+xvaOm9qvN93Opr8u293To1451qJvhJY L++A== X-Gm-Message-State: AOAM533qPrUQFvpOMH/bwzl5tUQFpoCJ6dLSdUmXH9wUZ9ICk4EW9D3I aJbaAeZXfU6hel/aEp5uDHhkp3vTNE7QneKQ X-Google-Smtp-Source: ABdhPJwV22wlmiPcfa8ZBxFmiy/FlEml0egC0KdzowflhNWhf8a0PfW7JcAKLkHa+efMK6bgnUk4+w== X-Received: by 2002:ae9:f817:: with SMTP id x23mr12356578qkh.103.1627855831730; Sun, 01 Aug 2021 15:10:31 -0700 (PDT) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id 6sm4842947qkv.115.2021.08.01.15.10.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 01 Aug 2021 15:10:31 -0700 (PDT) To: Eric Rescorla Cc: "Joel M. Halpern" , rfced-future@iab.org References: <6b5f89e8-2d79-016b-65bb-39704c438e96@nthpermutation.com> <2739d8af-209a-6714-c21c-d723fbd941fd@joelhalpern.com> <59a3aeda-0a76-eed9-70ac-ad2739c15eb5@nthpermutation.com> From: Michael StJohns Message-ID: Date: Sun, 1 Aug 2021 18:10:29 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------B8A43B68C4C14AC6A6C29A75" Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Replacement text for Section 4.2 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Aug 2021 22:10:39 -0000 This is a multi-part message in MIME format. --------------B8A43B68C4C14AC6A6C29A75 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Strangely enough I'd be happy with omitting any requirement for the LLC to accept comments from the community and that includes the RSAB.  But I grok, that is not what some people want, and if there is a requirement for community feed back, then there needs to be a way of ensuring that feedback goes through some form of fairness filter and a way for the target of that feedback to rebut or provide context for negative feedback. Jay has indicated that the LLC desires to defer mostly to what the community wants.  ISTM that makes sense in the macro processes, but less sense when the target is one specific person employed or contracted by the LLC where the law and contracts have to outweigh the community desire of the moment. Later, Mike On 8/1/2021 5:53 PM, Eric Rescorla wrote: > It might be useful to distinguish here between what we think is good > practice and what this RFC is going to require. > > In general, the executive management of a company has a fair amount of > latitude in what kind of HR practices they want to employ (subject to > local law, of course) They can do 360 reviews or not, solicit peer > feedback or not, share it with the employee or not, etc. I would > expect the same here, with the LLC and the IED being responsible for > making those decisions. For us to put specific requirements about how > that feedback is collected and shared is a bit like writing that into > the company bylaws. Perhaps there is some point which is truly > necessary to be encoded in such a way that it constrains the LLC but > none of this text seems to me to fit that bill. > > What I would prefer, therefore, is to omit essentially all of this > material. To the extent to which the community wishes to have input on > those processes, well, that's why the LLC board is answerable to the > community. And of course the RSWG can always write an RFC to add new > requirements if it deems it necessary in the future. > > -Ekr > > > On Sun, Aug 1, 2021 at 2:37 PM Michael StJohns > wrote: > > On 8/1/2021 5:11 PM, Joel M. Halpern wrote: > > I am not following the bottom part of your note. > > > > We are not a government agency, subject to government contracting > > regulations. > > I know that - but we are a non-profit corporation incorporated > within US > and mostly subject to US labor laws and practices.  All I'm saying is > that telling people that their comments will always remain > confidential > may run up against the law which says that's not the case. > > > As far as I know, the restrictions on a company for hiring and > firing > > contractors is always more generous than for employees. The > closest I > > have gotten in a review to knowing what the comments were from > other > > people was when my boss at my first job out of school told me > that he > > had received complaints (no idea of number, I did not get to see > the > > complaints) that I typed too loudly.   (I took this as a sign > that I > > should work somewhere else.) > > It a) depends on the contract - board members and C-suite staff > contracts tend to have some pretty interesting poison pills as do > by-name contracts for people with rare skills, but the typical > employee > is at-will and can be fired for any reason*, and b) it depends on the > country or state.     *As long as those reasons don't implicate a few > fair labor laws and regulations such as age, gender, race, national > origin, political and religious beliefs, etc. > > Re your comment - I took this that your boss had a sense of humor and > provided you with information that had no effect on your actual > review > and compensation.  The key thing here is that your boss knew who said > what, and you were given an opportunity to hear the issue. > > > > > I would expect that the LLC would want to get concerns discussed > > (which is why I raised the question to see if others agreed that an > > aggregating question was acceptable. > > > > > > Forwarding the actual responses (even somewhat redacted) seems > likely > > to cause problems.   Among other things, it seems likely to > discourage > > negative feedback. > > Contrariwise, not providing negative feedback to the RSEA is > unlikely to > result in any improvements if they are warranted.  And given this > community, it's possible that the RSEA can provide missing context > on a > prospectively negative comment to assist the LLC in deciding what > actions need to be taken. > > And sorry - I'm not sure who gets to see the actual results in your > model.  Can you tell me what each of RSAB, IED, LLC and the RSEA > see please? > > > > > > Sure, a law suit can of course be filed in the US under almost any > > circumstance.  And can attempt to subpoena almost anything.  But > that > > does not justify over-sharing information during the normal process. > > I still hesitate to see how providing the RSEA a summary/redaction of > the comments received and allowing them to provide a response is > "over-sharing". > > > Later, Mike > > > > > > > Yours, > > Joel > > > > On 8/1/2021 4:48 PM, Michael StJohns wrote: > >> Let me break this down into two section: 1) What is the scope of > >> confidentiality?  2) What does the RSEA get to see and comment on > >> prior to it going to the LLC - if anything? > >> > >> For confidentiality, I have these questions: > >> > >> 1) Are truly anonymous comments permitted? > >> 2) Does the IED get to see all of the comments with the source > >> unredacted? > >> 3) Does the RSAB get to see all of the comments? > >>     3a) paraphrased? > >>     3b) source unredacted? > >>     3c) source redacted? > >>        3c.1) With redactors comment on the source? > >>        3c.2) Without comment > >> 4) Does the LLC get to see all of the comments? > >>     4a) paraphrased? > >>     4b) source unredacted? > >>     4c) source redacted? > >>         4c.1) With redactors comment on the source > >>         4c.2) Without comment on the source > >> > >> I assume that if the IED gets to see all comments, they will > act as > >> redactor for any further distribution if redaction is required. > >> > >> In the draft I assumed that 1, 2), 3c.1), and 4c.1) were the > answers > >> to the above questions because of the comments that were made > by the > >> call about confidentiality.    Obviously, if the LLC and the > RSAB get > >> to see everything, there won't be a redaction and comment on the > >> source necessary.   If the LLC doesn't get to see everything, > then it > >> at least needs the context of possible biases from the > submitters of > >> the comments to help it understand the reality on the ground. > >> > >> For the RSEA, I believe that it needs to be a bit more that Joel > >> suggests below - and instead we should be making sure that any > >> comment that will be considered by the LLC has to be provided > to the > >> RSEA for feedback and rebuttal in at least a paraphrased form.  I > >> don't think the RSEA gets to know about any of the sources, but it > >> seems both unfair and legally fraught not to provide them with an > >> opportunity to make an opposing case for any negative comments. > >> > >> And I'm glad that EKR brought up "legal".   Unlike the Nomcom > process > >> there is/will be a financial relationship between the LLC and the > >> RSEA in the form of either an employment agreement or > contract.   In > >> the event that the LLC moves to terminate that relationship, if > the > >> RSEA feels it is being done for "unfair" reasons and can make a > case > >> to a legal standard in the appropriate legal venue, _*each and > every > >> comment, and all emails and notes discussing those comments > will be > >> subject to subpoena and the related depositions*_. > >> > >> And lastly - no company I know of solicits company wide comments > >> (unless the company is really tiny) on a particular employee's > >> performance, nor does the manager not know who made the comment > and > >> hence that manager can accurately weigh said comments.  It > would be a > >> truly bad manager that did not ask an employee about their take on > >> any  negative comments the manager received and the manager should > >> help them redress any actual problems. > >> > >> Mike > >> > >> > >> ps - Martin - "derogatory" is a term of art, mostly used > related to > >> credit worthiness,   it differs from negative, in that the > derogatory > >> info may affect the credit score, but there might be other > negative > >> information that can't be taken into account due to legal issues > >> (e.g. for this "the RSEA is too old for the job" would be a > negative > >> comment, but not a derogatory one as age discrimination is > generally > >> prohibited and the comment couldn't be considered and would > need to > >> be discarded when received). Happy though to change to > "negative and > >> positive" vice derogatory. > >> > >> > >> > >> On 7/29/2021 11:49 PM, Joel M. Halpern wrote: > >>> I mostly agree with Ekr here. > >>> > >>> The only edge case I see is one that I know has come up with > >>> nomcoms. If nomcoms see a pattern of reports of an issue, they > have > >>> been known to say to a candidate "there have been issues raised > >>> about X.  Do you have any comment on that?" This is not the same > >>> as showing the candidate the feedback, even sanitized. It does > >>> reveal that information has been provided. (And, even more > >>> importantly, ti does not give even a large portion of the > >>> feedback.)  The nomcoms where I know this came up concluded > that the > >>> combination of seeing the candidates reaction and giving then a > >>> chance to respond was worth pushing that envelop.   Do we > consider > >>> that the selection committee or LLC or someone has that right > under > >>> this process already?  Do we want to say anything about it? > >>> > >>> Yours, > >>> Joel > >>> > >>> On 7/29/2021 11:34 PM, Eric Rescorla wrote: > >>>> > >>>> > >>>> On Thu, Jul 29, 2021 at 5:00 PM Michael StJohns > >>>> > >> > wrote: > >>>> > >>>>     Replacement for section 4.2: > >>>> > >>>>               <<< Set a schedule - could be omitted, but this > is a > >>>>     promise to > >>>>     the community > >>>> > >>>>                      as well as a schedule for the IED/RSEA >>> > >>>>          No more often than semi-annually nor less often than > >>>> bi-yearly, the > >>>>          IETF Executive Director will send out to the > community a > >>>> call for > >>>>          input on the performance of the RSEA. > >>>> > >>>>           <<< Separate the IED's recommendation from the > feedback > >>>> process - > >>>> > >>>>            there may not actually be an action that needs an > immediate > >>>>     recommendation >>> > >>>> > >>>>          <<<< the IED acts as the confidentiality mediator, > >>>> anonymous and > >>>>     confidential > >>>> > >>>>                   comments get tagged in the document that > goes to the > >>>>     LLC - > >>>>     this provides > >>>> > >>>>                   needed context. >>>> > >>>>          The IETF Executive Director and the stream managers > will > >>>> review the > >>>>          received feedback and produce a draft summary (a > paraphrase) > >>>>          including both positive and derogatory information. Any > >>>> feedback > >>>>          provided anonymously shall be tagged as such in the > >>>> summary. Any > >>>>          feedback provided with a request for confidentiality > shall > >>>> likewise > >>>>          be tagged in the summary and the IETF Executive > Director MAY > >>>>          comment on the weight that may be appropriate to > apply to the > >>>>          comment based on their knowledge of the submitter. > The stream > >>>>          managers should ensure that any of their concerns are > >>>> added to the > >>>>          document at this point and MAY also provide any > commentary > >>>> on the > >>>>          externally provided feedback that they feel appropriate. > >>>> > >>>>          <<< Make sure that the LLC hears both sides of the > coin >>> > >>>>          That draft feedback, redacted with respect to any names > >>>> associated > >>>>          with confidential comments and with respect to the > IED's > >>>> weight > >>>>          evaluations, shall be provided to the RSEA with for > >>>> comment or > >>>>          rebuttal, and such comments shall be incorporated as an > >>>> appendix to > >>>>          the final feedback document provided to the IETF LLC > Board. > >>>> > >>>> > >>>> This doesn't seem appropriate to me. > >>>> > >>>> If people want to provide confidential comments, then they > >>>> shouldn't be supplied to the RSEA, > >>>> nor should the IED's weights. This is not a legal proceeding, > it's > >>>> a performance review, and > >>>> there's no generic reason that the RSEA should get to hear > all the > >>>> feedback that the LLC is > >>>> receiving. > >>>> > >>>> -Ekr > >>>> > >>>> > >> > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > > --------------B8A43B68C4C14AC6A6C29A75 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Strangely enough I'd be happy with omitting any requirement for the LLC to accept comments from the community and that includes the RSAB.  But I grok, that is not what some people want, and if there is a requirement for community feed back, then there needs to be a way of ensuring that feedback goes through some form of fairness filter and a way for the target of that feedback to rebut or provide context for negative feedback.

Jay has indicated that the LLC desires to defer mostly to what the community wants.  ISTM that makes sense in the macro processes, but less sense when the target is one specific person employed or contracted by the LLC where the law and contracts have to outweigh the community desire of the moment.

Later, Mike




On 8/1/2021 5:53 PM, Eric Rescorla wrote:
It might be useful to distinguish here between what we think is good practice and what this RFC is going to require.

In general, the executive management of a company has a fair amount of latitude in what kind of HR practices they want to employ (subject to local law, of course) They can do 360 reviews or not, solicit peer feedback or not, share it with the employee or not, etc. I would expect the same here, with the LLC and the IED being responsible for making those decisions. For us to put specific requirements about how that feedback is collected and shared is a bit like writing that into the company bylaws. Perhaps there is some point which is truly necessary to be encoded in such a way that it constrains the LLC but none of this text seems to me to fit that bill.

What I would prefer, therefore, is to omit essentially all of this material. To the extent to which the community wishes to have input on those processes, well, that's why the LLC board is answerable to the community. And of course the RSWG can always write an RFC to add new requirements if it deems it necessary in the future.

-Ekr


On Sun, Aug 1, 2021 at 2:37 PM Michael StJohns <msj@nthpermutation.com> wrote:
On 8/1/2021 5:11 PM, Joel M. Halpern wrote:
> I am not following the bottom part of your note.
>
> We are not a government agency, subject to government contracting
> regulations.

I know that - but we are a non-profit corporation incorporated within US
and mostly subject to US labor laws and practices.  All I'm saying is
that telling people that their comments will always remain confidential
may run up against the law which says that's not the case.

> As far as I know, the restrictions on a company for hiring and firing
> contractors is always more generous than for employees.  The closest I
> have gotten in a review to knowing what the comments were from other
> people was when my boss at my first job out of school told me that he
> had received complaints (no idea of number, I did not get to see the
> complaints) that I typed too loudly.   (I took this as a sign that I
> should work somewhere else.)

It a) depends on the contract - board members and C-suite staff
contracts tend to have some pretty interesting poison pills as do
by-name contracts for people with rare skills, but the typical employee
is at-will and can be fired for any reason*, and b) it depends on the
country or state.     *As long as those reasons don't implicate a few
fair labor laws and regulations such as age, gender, race, national
origin, political and religious beliefs, etc.

Re your comment - I took this that your boss had a sense of humor and
provided you with information that had no effect on your actual review
and compensation.  The key thing here is that your boss knew who said
what, and you were given an opportunity to hear the issue.

>
> I would expect that the LLC would want to get concerns discussed
> (which is why I raised the question to see if others agreed that an
> aggregating question was acceptable.


>
> Forwarding the actual responses (even somewhat redacted) seems likely
> to cause problems.   Among other things, it seems likely to discourage
> negative feedback.

Contrariwise, not providing negative feedback to the RSEA is unlikely to
result in any improvements if they are warranted.  And given this
community, it's possible that the RSEA can provide missing context on a
prospectively negative comment to assist the LLC in deciding what
actions need to be taken.

And sorry - I'm not sure who gets to see the actual results in your
model.  Can you tell me what each of RSAB, IED, LLC and the RSEA see please?


>
> Sure, a law suit can of course be filed in the US under almost any
> circumstance.  And can attempt to subpoena almost anything.  But that
> does not justify over-sharing information during the normal process.

I still hesitate to see how providing the RSEA a summary/redaction of
the comments received and allowing them to provide a response is
"over-sharing".


Later, Mike



>
> Yours,
> Joel
>
> On 8/1/2021 4:48 PM, Michael StJohns wrote:
>> Let me break this down into two section: 1) What is the scope of
>> confidentiality?  2) What does the RSEA get to see and comment on
>> prior to it going to the LLC - if anything?
>>
>> For confidentiality, I have these questions:
>>
>> 1) Are truly anonymous comments permitted?
>> 2) Does the IED get to see all of the comments with the source
>> unredacted?
>> 3) Does the RSAB get to see all of the comments?
>>     3a) paraphrased?
>>     3b) source unredacted?
>>     3c) source redacted?
>>        3c.1) With redactors comment on the source?
>>        3c.2) Without comment
>> 4) Does the LLC get to see all of the comments?
>>     4a) paraphrased?
>>     4b) source unredacted?
>>     4c) source redacted?
>>         4c.1) With redactors comment on the source
>>         4c.2) Without comment on the source
>>
>> I assume that if the IED gets to see all comments, they will act as
>> redactor for any further distribution if redaction is required.
>>
>> In the draft I assumed that 1, 2), 3c.1), and 4c.1) were the answers
>> to the above questions because of the comments that were made by the
>> call about confidentiality.    Obviously, if the LLC and the RSAB get
>> to see everything, there won't be a redaction and comment on the
>> source necessary.   If the LLC doesn't get to see everything, then it
>> at least needs the context of possible biases from the submitters of
>> the comments to help it understand the reality on the ground.
>>
>> For the RSEA, I believe that it needs to be a bit more that Joel
>> suggests below - and instead we should be making sure that any
>> comment that will be considered by the LLC has to be provided to the
>> RSEA for feedback and rebuttal in at least a paraphrased form.  I
>> don't think the RSEA gets to know about any of the sources, but it
>> seems both unfair and legally fraught not to provide them with an
>> opportunity to make an opposing case for any negative comments.
>>
>> And I'm glad that EKR brought up "legal".   Unlike the Nomcom process
>> there is/will be a financial relationship between the LLC and the
>> RSEA in the form of either an employment agreement or contract.   In
>> the event that the LLC moves to terminate that relationship, if the
>> RSEA feels it is being done for "unfair" reasons and can make a case
>> to a legal standard in the appropriate legal venue, _*each and every
>> comment, and all emails and notes discussing those comments will be
>> subject to subpoena and the related depositions*_.
>>
>> And lastly - no company I know of solicits company wide comments
>> (unless the company is really tiny) on a particular employee's
>> performance, nor does the manager not know who made the comment and
>> hence that manager can accurately weigh said comments.  It would be a
>> truly bad manager that did not ask an employee about their take on
>> any  negative comments the manager received and the manager should
>> help them redress any actual problems.
>>
>> Mike
>>
>>
>> ps - Martin - "derogatory" is a term of art, mostly used related to
>> credit worthiness,   it differs from negative, in that the derogatory
>> info may affect the credit score, but there might be other negative
>> information that can't be taken into account due to legal issues
>> (e.g. for this "the RSEA is too old for the job" would be a negative
>> comment, but not a derogatory one as age discrimination is generally
>> prohibited and the comment couldn't be considered and would need to
>> be discarded when received). Happy though to change to "negative and
>> positive" vice derogatory.
>>
>>
>>
>> On 7/29/2021 11:49 PM, Joel M. Halpern wrote:
>>> I mostly agree with Ekr here.
>>>
>>> The only edge case I see is one that I know has come up with
>>> nomcoms. If nomcoms see a pattern of reports of an issue, they have
>>> been known to say to a candidate "there have been issues raised
>>> about X.  Do you have any comment on that?"   This is not the same
>>> as showing the candidate the feedback, even sanitized. It does
>>> reveal that information has been provided. (And, even more
>>> importantly, ti does not give even a large portion of the
>>> feedback.)  The nomcoms where I know this came up concluded that the
>>> combination of seeing the candidates reaction and giving then a
>>> chance to respond was worth pushing that envelop.   Do we consider
>>> that the selection committee or LLC or someone has that right under
>>> this process already?  Do we want to say anything about it?
>>>
>>> Yours,
>>> Joel
>>>
>>> On 7/29/2021 11:34 PM, Eric Rescorla wrote:
>>>>
>>>>
>>>> On Thu, Jul 29, 2021 at 5:00 PM Michael StJohns
>>>> <msj@nthpermutation.com <mailto:msj@nthpermutation.com>> wrote:
>>>>
>>>>     Replacement for section 4.2:
>>>>
>>>>               <<< Set a schedule - could be omitted, but this is a
>>>>     promise to
>>>>     the community
>>>>
>>>>                      as well as a schedule for the IED/RSEA >>>
>>>>          No more often than semi-annually nor less often than
>>>> bi-yearly, the
>>>>          IETF Executive Director will send out to the community a
>>>> call for
>>>>          input on the performance of the RSEA.
>>>>
>>>>           <<< Separate the IED's recommendation from the feedback
>>>> process -
>>>>
>>>>            there may not actually be an action that needs an immediate
>>>>     recommendation >>>
>>>>
>>>>          <<<< the IED acts as the confidentiality mediator,
>>>> anonymous and
>>>>     confidential
>>>>
>>>>                   comments get tagged in the document that goes to the
>>>>     LLC -
>>>>     this provides
>>>>
>>>>                   needed context. >>>>
>>>>          The IETF Executive Director and the stream managers will
>>>> review the
>>>>          received feedback and produce a draft summary (a paraphrase)
>>>>          including both positive and derogatory information. Any
>>>> feedback
>>>>          provided anonymously shall be tagged as such in the
>>>> summary. Any
>>>>          feedback provided with a request for confidentiality shall
>>>> likewise
>>>>          be tagged in the summary and the IETF Executive Director MAY
>>>>          comment on the weight that may be appropriate to apply to the
>>>>          comment based on their knowledge of the submitter. The stream
>>>>          managers should ensure that any of their concerns are
>>>> added to the
>>>>          document at this point and MAY also provide any commentary
>>>> on the
>>>>          externally provided feedback that they feel appropriate.
>>>>
>>>>          <<< Make sure that the LLC hears both sides of the coin >>>
>>>>          That draft feedback, redacted with respect to any names
>>>> associated
>>>>          with confidential comments and with respect to the IED's
>>>> weight
>>>>          evaluations, shall be provided to the RSEA with for
>>>> comment or
>>>>          rebuttal, and such comments shall be incorporated as an
>>>> appendix to
>>>>          the final feedback document provided to the IETF LLC Board.
>>>>
>>>>
>>>> This doesn't seem appropriate to me.
>>>>
>>>> If people want to provide confidential comments, then they
>>>> shouldn't be supplied to the RSEA,
>>>> nor should the IED's weights. This is not a legal proceeding, it's
>>>> a performance review, and
>>>> there's no generic reason that the RSEA should get to hear all the
>>>> feedback that the LLC is
>>>> receiving.
>>>>
>>>> -Ekr
>>>>
>>>>
>>

--
Rfced-future mailing list
Rfced-future@iab.org
https://www.iab.org/mailman/listinfo/rfced-future


--------------B8A43B68C4C14AC6A6C29A75-- From nobody Sun Aug 1 15:15:34 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F07823A1521 for ; Sun, 1 Aug 2021 15:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 GMS1NT99e231 for ; Sun, 1 Aug 2021 15:15:28 -0700 (PDT) Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (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 6BD1D3A1553 for ; Sun, 1 Aug 2021 15:15:26 -0700 (PDT) Received: by mail-il1-x12f.google.com with SMTP id a14so14856341ila.1 for ; Sun, 01 Aug 2021 15:15:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GfyVfCbtng+dsbh251UTZySdoYugrBC3212ZUpu3cLg=; b=I8zOfZI2wqqK67EaipR1TnoTm1ZqI9qdAM8fk47AHXmPJQj6MWAecBy9sN8kTqBT7q hoiT+r26FoZnctz07SYrHzlzLD2xDQXj8ZyyR6PjuA0DR6fqhWx4NpPQA/lCACD4wDbM /Sde3voka6KwTysxE2OTOUHkX4F0YIT1wFdvPeEvaAoT+KIAhFJRJul1N66w2Qny7mHD p59il+FDgNyFL9gK1jkDYS7dMJ/Fq9dxoJFLyLNpQ4r86ytzM0hcyFmNgYvvEr0awsdq nn+6VsYSNSvNqk12OyUhCj5rPRhQjHWo5R11XrI18Zxkskd0ByuF13lhwIagQNDtmnuN WWZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GfyVfCbtng+dsbh251UTZySdoYugrBC3212ZUpu3cLg=; b=C/HbdC3Hri3FWkEFuUDcKBom5/K8HW+9aB5MwLNG6JK6TVYx9lU2MMGJtlgrVFp8i1 tw55HSVSPRAqJ+qMBnsl64ZXokUu+jRLIRulRrf09ySABEx+CH2gI67YvnNV+T82HIHi orAlK7mJhE5XDwdfRYghK8MFZDavtG7uRl8ZQt0TytcPbhQRu5gR+DB8iCWG79ahO99b Lzenc1FgKt6+9X5yqixy0DP5JZ1g9hxy3oD6WnGGe7+37ptw0yVyi3MgFjFeofqvFd+B f9/Jgsc+FT2xxb6P5d9Kdw486+77smp2/D62k63awvDl3EfI26fwZsD9Y6l9Mnq8TXHg 3ApQ== X-Gm-Message-State: AOAM531eN1zhNJGW5lwfuLAuLdLDJ/3YRdHLhgqoUQs2zUhq0FVYwAfL 0DRevHNuQNcbPi+TRqz5nKnQYK7EwK4wpRt9z595v2e0Z5uRjg== X-Google-Smtp-Source: ABdhPJww0Bb5NheojWh9lYZEaP1+YwgTAO8SGjMiobk5DT7aBvuwn6fILslL5AwNs0TUxkRKIR3fk+Ep8jA9LnAZyfA= X-Received: by 2002:a05:6e02:f54:: with SMTP id y20mr2304367ilj.56.1627856124839; Sun, 01 Aug 2021 15:15:24 -0700 (PDT) MIME-Version: 1.0 References: <6b5f89e8-2d79-016b-65bb-39704c438e96@nthpermutation.com> <2739d8af-209a-6714-c21c-d723fbd941fd@joelhalpern.com> <59a3aeda-0a76-eed9-70ac-ad2739c15eb5@nthpermutation.com> In-Reply-To: From: Eric Rescorla Date: Sun, 1 Aug 2021 15:14:48 -0700 Message-ID: To: Michael StJohns Cc: "Joel M. Halpern" , rfced-future@iab.org Content-Type: multipart/alternative; boundary="0000000000001119bd05c886ca2a" Archived-At: Subject: Re: [Rfced-future] Replacement text for Section 4.2 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Aug 2021 22:15:33 -0000 --0000000000001119bd05c886ca2a Content-Type: text/plain; charset="UTF-8" On Sun, Aug 1, 2021 at 3:10 PM Michael StJohns wrote: > Strangely enough I'd be happy with omitting any requirement for the LLC to > accept comments from the community and that includes the RSAB. But I grok, > that is not what some people want, and if there is a requirement for > community feed back, then there needs to be a way of ensuring that feedback > goes through some form of fairness filter > The details of this seem like something that we could leave to the LLC to decide. and a way for the target of that feedback to rebut or provide context for > negative feedback. > This seems like something that might be good practice in many cases and bad in some others, but in any case doesn't need to be encoded in an RFC. -Ekr On 8/1/2021 5:53 PM, Eric Rescorla wrote: It might be useful to distinguish here between what we think is good practice and what this RFC is going to require. In general, the executive management of a company has a fair amount of latitude in what kind of HR practices they want to employ (subject to local law, of course) They can do 360 reviews or not, solicit peer feedback or not, share it with the employee or not, etc. I would expect the same here, with the LLC and the IED being responsible for making those decisions. For us to put specific requirements about how that feedback is collected and shared is a bit like writing that into the company bylaws. Perhaps there is some point which is truly necessary to be encoded in such a way that it constrains the LLC but none of this text seems to me to fit that bill. What I would prefer, therefore, is to omit essentially all of this material. To the extent to which the community wishes to have input on those processes, well, that's why the LLC board is answerable to the community. And of course the RSWG can always write an RFC to add new requirements if it deems it necessary in the future. -Ekr On Sun, Aug 1, 2021 at 2:37 PM Michael StJohns wrote: > On 8/1/2021 5:11 PM, Joel M. Halpern wrote: > > I am not following the bottom part of your note. > > > > We are not a government agency, subject to government contracting > > regulations. > > I know that - but we are a non-profit corporation incorporated within US > and mostly subject to US labor laws and practices. All I'm saying is > that telling people that their comments will always remain confidential > may run up against the law which says that's not the case. > > > As far as I know, the restrictions on a company for hiring and firing > > contractors is always more generous than for employees. The closest I > > have gotten in a review to knowing what the comments were from other > > people was when my boss at my first job out of school told me that he > > had received complaints (no idea of number, I did not get to see the > > complaints) that I typed too loudly. (I took this as a sign that I > > should work somewhere else.) > > It a) depends on the contract - board members and C-suite staff > contracts tend to have some pretty interesting poison pills as do > by-name contracts for people with rare skills, but the typical employee > is at-will and can be fired for any reason*, and b) it depends on the > country or state. *As long as those reasons don't implicate a few > fair labor laws and regulations such as age, gender, race, national > origin, political and religious beliefs, etc. > > Re your comment - I took this that your boss had a sense of humor and > provided you with information that had no effect on your actual review > and compensation. The key thing here is that your boss knew who said > what, and you were given an opportunity to hear the issue. > > > > > I would expect that the LLC would want to get concerns discussed > > (which is why I raised the question to see if others agreed that an > > aggregating question was acceptable. > > > > > > Forwarding the actual responses (even somewhat redacted) seems likely > > to cause problems. Among other things, it seems likely to discourage > > negative feedback. > > Contrariwise, not providing negative feedback to the RSEA is unlikely to > result in any improvements if they are warranted. And given this > community, it's possible that the RSEA can provide missing context on a > prospectively negative comment to assist the LLC in deciding what > actions need to be taken. > > And sorry - I'm not sure who gets to see the actual results in your > model. Can you tell me what each of RSAB, IED, LLC and the RSEA see > please? > > > > > > Sure, a law suit can of course be filed in the US under almost any > > circumstance. And can attempt to subpoena almost anything. But that > > does not justify over-sharing information during the normal process. > > I still hesitate to see how providing the RSEA a summary/redaction of > the comments received and allowing them to provide a response is > "over-sharing". > > > Later, Mike > > > > > > > Yours, > > Joel > > > > On 8/1/2021 4:48 PM, Michael StJohns wrote: > >> Let me break this down into two section: 1) What is the scope of > >> confidentiality? 2) What does the RSEA get to see and comment on > >> prior to it going to the LLC - if anything? > >> > >> For confidentiality, I have these questions: > >> > >> 1) Are truly anonymous comments permitted? > >> 2) Does the IED get to see all of the comments with the source > >> unredacted? > >> 3) Does the RSAB get to see all of the comments? > >> 3a) paraphrased? > >> 3b) source unredacted? > >> 3c) source redacted? > >> 3c.1) With redactors comment on the source? > >> 3c.2) Without comment > >> 4) Does the LLC get to see all of the comments? > >> 4a) paraphrased? > >> 4b) source unredacted? > >> 4c) source redacted? > >> 4c.1) With redactors comment on the source > >> 4c.2) Without comment on the source > >> > >> I assume that if the IED gets to see all comments, they will act as > >> redactor for any further distribution if redaction is required. > >> > >> In the draft I assumed that 1, 2), 3c.1), and 4c.1) were the answers > >> to the above questions because of the comments that were made by the > >> call about confidentiality. Obviously, if the LLC and the RSAB get > >> to see everything, there won't be a redaction and comment on the > >> source necessary. If the LLC doesn't get to see everything, then it > >> at least needs the context of possible biases from the submitters of > >> the comments to help it understand the reality on the ground. > >> > >> For the RSEA, I believe that it needs to be a bit more that Joel > >> suggests below - and instead we should be making sure that any > >> comment that will be considered by the LLC has to be provided to the > >> RSEA for feedback and rebuttal in at least a paraphrased form. I > >> don't think the RSEA gets to know about any of the sources, but it > >> seems both unfair and legally fraught not to provide them with an > >> opportunity to make an opposing case for any negative comments. > >> > >> And I'm glad that EKR brought up "legal". Unlike the Nomcom process > >> there is/will be a financial relationship between the LLC and the > >> RSEA in the form of either an employment agreement or contract. In > >> the event that the LLC moves to terminate that relationship, if the > >> RSEA feels it is being done for "unfair" reasons and can make a case > >> to a legal standard in the appropriate legal venue, _*each and every > >> comment, and all emails and notes discussing those comments will be > >> subject to subpoena and the related depositions*_. > >> > >> And lastly - no company I know of solicits company wide comments > >> (unless the company is really tiny) on a particular employee's > >> performance, nor does the manager not know who made the comment and > >> hence that manager can accurately weigh said comments. It would be a > >> truly bad manager that did not ask an employee about their take on > >> any negative comments the manager received and the manager should > >> help them redress any actual problems. > >> > >> Mike > >> > >> > >> ps - Martin - "derogatory" is a term of art, mostly used related to > >> credit worthiness, it differs from negative, in that the derogatory > >> info may affect the credit score, but there might be other negative > >> information that can't be taken into account due to legal issues > >> (e.g. for this "the RSEA is too old for the job" would be a negative > >> comment, but not a derogatory one as age discrimination is generally > >> prohibited and the comment couldn't be considered and would need to > >> be discarded when received). Happy though to change to "negative and > >> positive" vice derogatory. > >> > >> > >> > >> On 7/29/2021 11:49 PM, Joel M. Halpern wrote: > >>> I mostly agree with Ekr here. > >>> > >>> The only edge case I see is one that I know has come up with > >>> nomcoms. If nomcoms see a pattern of reports of an issue, they have > >>> been known to say to a candidate "there have been issues raised > >>> about X. Do you have any comment on that?" This is not the same > >>> as showing the candidate the feedback, even sanitized. It does > >>> reveal that information has been provided. (And, even more > >>> importantly, ti does not give even a large portion of the > >>> feedback.) The nomcoms where I know this came up concluded that the > >>> combination of seeing the candidates reaction and giving then a > >>> chance to respond was worth pushing that envelop. Do we consider > >>> that the selection committee or LLC or someone has that right under > >>> this process already? Do we want to say anything about it? > >>> > >>> Yours, > >>> Joel > >>> > >>> On 7/29/2021 11:34 PM, Eric Rescorla wrote: > >>>> > >>>> > >>>> On Thu, Jul 29, 2021 at 5:00 PM Michael StJohns > >>>> > wrote: > >>>> > >>>> Replacement for section 4.2: > >>>> > >>>> <<< Set a schedule - could be omitted, but this is a > >>>> promise to > >>>> the community > >>>> > >>>> as well as a schedule for the IED/RSEA >>> > >>>> No more often than semi-annually nor less often than > >>>> bi-yearly, the > >>>> IETF Executive Director will send out to the community a > >>>> call for > >>>> input on the performance of the RSEA. > >>>> > >>>> <<< Separate the IED's recommendation from the feedback > >>>> process - > >>>> > >>>> there may not actually be an action that needs an immediate > >>>> recommendation >>> > >>>> > >>>> <<<< the IED acts as the confidentiality mediator, > >>>> anonymous and > >>>> confidential > >>>> > >>>> comments get tagged in the document that goes to the > >>>> LLC - > >>>> this provides > >>>> > >>>> needed context. >>>> > >>>> The IETF Executive Director and the stream managers will > >>>> review the > >>>> received feedback and produce a draft summary (a paraphrase) > >>>> including both positive and derogatory information. Any > >>>> feedback > >>>> provided anonymously shall be tagged as such in the > >>>> summary. Any > >>>> feedback provided with a request for confidentiality shall > >>>> likewise > >>>> be tagged in the summary and the IETF Executive Director MAY > >>>> comment on the weight that may be appropriate to apply to the > >>>> comment based on their knowledge of the submitter. The stream > >>>> managers should ensure that any of their concerns are > >>>> added to the > >>>> document at this point and MAY also provide any commentary > >>>> on the > >>>> externally provided feedback that they feel appropriate. > >>>> > >>>> <<< Make sure that the LLC hears both sides of the coin >>> > >>>> That draft feedback, redacted with respect to any names > >>>> associated > >>>> with confidential comments and with respect to the IED's > >>>> weight > >>>> evaluations, shall be provided to the RSEA with for > >>>> comment or > >>>> rebuttal, and such comments shall be incorporated as an > >>>> appendix to > >>>> the final feedback document provided to the IETF LLC Board. > >>>> > >>>> > >>>> This doesn't seem appropriate to me. > >>>> > >>>> If people want to provide confidential comments, then they > >>>> shouldn't be supplied to the RSEA, > >>>> nor should the IED's weights. This is not a legal proceeding, it's > >>>> a performance review, and > >>>> there's no generic reason that the RSEA should get to hear all the > >>>> feedback that the LLC is > >>>> receiving. > >>>> > >>>> -Ekr > >>>> > >>>> > >> > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > --0000000000001119bd05c886ca2a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Aug 1, 2021 at 3:10 PM Michae= l StJohns <msj@nthpermutation.= com> wrote:
=20 =20 =20
Strangely enough I'd be happy with omitting any requirement for the LLC to accept comments from the community and that includes the RSAB.=C2=A0 But I grok, that is not what some people want, and if there is a requirement for community feed back, then there needs to be a way of ensuring that feedback goes through some form of fairness filter

The details of this seem like something that we could lea= ve to the LLC to decide.


and a way for the target of that feedback to rebut or provide context for negative feedback.

This seems like= something that might be good practice in many cases and bad in some others= , but in any case doesn't need to be encoded in an RFC.
<= br>
-Ekr




On 8/1/2021 5:53 PM, Eric Rescorla wrote:
=20
It might be useful to distinguish here between what we think is good practice and what this RFC is going to require.

In general, the executive management of a company has a fair amount of latitude in what kind of HR practices they want to employ (subject to local law, of course) They can do 360 reviews or not, solicit peer feedback or not, share it with the employee or not, etc. I would expect the same here, with the LLC and the IED being responsible for making those decisions. For us to put specific requirements about how that feedback is collected and shared is a bit like writing that into the company bylaws. Perhaps there is some point which is truly necessary to be encoded in such a way that it constrains the LLC but none of this text seems to me to fit that bill.

What I would prefer, therefore, is to omit essentially all of this material. To the extent to which the community wishes to have input on those processes, well, that's why the LLC board is answerable to the community. And of course the RSWG can always write an RFC to add new requirements if it deems it necessary in the future.

-Ekr


On Sun, Aug 1, 2021 at 2:37 P= M Michael StJohns <msj@nthpermutation.com> wrote:
On 8/1/2021 5:11 PM, Joel M. Halpern wrote:
> I am not following the bottom part of your note.
>
> We are not a government agency, subject to government contracting
> regulations.

I know that - but we are a non-profit corporation incorporated within US
and mostly subject to US labor laws and practices.=C2=A0 All I= 9;m saying is
that telling people that their comments will always remain confidential
may run up against the law which says that's not the case.
> As far as I know, the restrictions on a company for hiring and firing
> contractors is always more generous than for employees.=C2= =A0 The closest I
> have gotten in a review to knowing what the comments were from other
> people was when my boss at my first job out of school told me that he
> had received complaints (no idea of number, I did not get to see the
> complaints) that I typed too loudly.=C2=A0=C2=A0 (I took thi= s as a sign that I
> should work somewhere else.)

It a) depends on the contract - board members and C-suite staff
contracts tend to have some pretty interesting poison pills as do
by-name contracts for people with rare skills, but the typical employee
is at-will and can be fired for any reason*, and b) it depends on the
country or state.=C2=A0=C2=A0=C2=A0=C2=A0 *As long as those reaso= ns don't implicate a few
fair labor laws and regulations such as age, gender, race, national
origin, political and religious beliefs, etc.

Re your comment - I took this that your boss had a sense of humor and
provided you with information that had no effect on your actual review
and compensation.=C2=A0 The key thing here is that your boss knew who said
what, and you were given an opportunity to hear the issue.

>
> I would expect that the LLC would want to get concerns discussed
> (which is why I raised the question to see if others agreed that an
> aggregating question was acceptable.


>
> Forwarding the actual responses (even somewhat redacted) seems likely
> to cause problems.=C2=A0=C2=A0 Among other things, it seems = likely to discourage
> negative feedback.

Contrariwise, not providing negative feedback to the RSEA is unlikely to
result in any improvements if they are warranted.=C2=A0 And given this
community, it's possible that the RSEA can provide missing context on a
prospectively negative comment to assist the LLC in deciding what
actions need to be taken.

And sorry - I'm not sure who gets to see the actual results i= n your
model.=C2=A0 Can you tell me what each of RSAB, IED, LLC and the RSEA see please?


>
> Sure, a law suit can of course be filed in the US under almost any
> circumstance.=C2=A0 And can attempt to subpoena almost anything.=C2=A0 But that
> does not justify over-sharing information during the normal process.

I still hesitate to see how providing the RSEA a summary/redaction of
the comments received and allowing them to provide a response is
"over-sharing".


Later, Mike



>
> Yours,
> Joel
>
> On 8/1/2021 4:48 PM, Michael StJohns wrote:
>> Let me break this down into two section: 1) What is the scope of
>> confidentiality?=C2=A0 2) What does the RSEA get to see and comment on
>> prior to it going to the LLC - if anything?
>>
>> For confidentiality, I have these questions:
>>
>> 1) Are truly anonymous comments permitted?
>> 2) Does the IED get to see all of the comments with the source
>> unredacted?
>> 3) Does the RSAB get to see all of the comments?
>> =C2=A0=C2=A0=C2=A0 3a) paraphrased?
>> =C2=A0=C2=A0=C2=A0 3b) source unredacted?
>> =C2=A0=C2=A0=C2=A0 3c) source redacted?
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 3c.1) With redactor= s comment on the source?
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 3c.2) Without comme= nt
>> 4) Does the LLC get to see all of the comments?
>> =C2=A0=C2=A0=C2=A0 4a) paraphrased?
>> =C2=A0=C2=A0=C2=A0 4b) source unredacted?
>> =C2=A0=C2=A0=C2=A0 4c) source redacted?
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 4c.1) With re= dactors comment on the source
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 4c.2) Without= comment on the source
>>
>> I assume that if the IED gets to see all comments, they will act as
>> redactor for any further distribution if redaction is required.
>>
>> In the draft I assumed that 1, 2), 3c.1), and 4c.1) were the answers
>> to the above questions because of the comments that were made by the
>> call about confidentiality.=C2=A0=C2=A0=C2=A0 Obviously,= if the LLC and the RSAB get
>> to see everything, there won't be a redaction and comment on the
>> source necessary.=C2=A0=C2=A0 If the LLC doesn't get= to see everything, then it
>> at least needs the context of possible biases from the submitters of
>> the comments to help it understand the reality on the ground.
>>
>> For the RSEA, I believe that it needs to be a bit more that Joel
>> suggests below - and instead we should be making sure that any
>> comment that will be considered by the LLC has to be provided to the
>> RSEA for feedback and rebuttal in at least a paraphrased form.=C2=A0 I
>> don't think the RSEA gets to know about any of the sources, but it
>> seems both unfair and legally fraught not to provide them with an
>> opportunity to make an opposing case for any negative comments.
>>
>> And I'm glad that EKR brought up "legal".= =C2=A0=C2=A0 Unlike the Nomcom process
>> there is/will be a financial relationship between the LLC and the
>> RSEA in the form of either an employment agreement or contract.=C2=A0=C2=A0 In
>> the event that the LLC moves to terminate that relationship, if the
>> RSEA feels it is being done for "unfair" reaso= ns and can make a case
>> to a legal standard in the appropriate legal venue, _*each and every
>> comment, and all emails and notes discussing those comments will be
>> subject to subpoena and the related depositions*_.
>>
>> And lastly - no company I know of solicits company wide comments
>> (unless the company is really tiny) on a particular employee's
>> performance, nor does the manager not know who made the comment and
>> hence that manager can accurately weigh said comments.=C2=A0 It would be a
>> truly bad manager that did not ask an employee about their take on
>> any=C2=A0 negative comments the manager received and the manager should
>> help them redress any actual problems.
>>
>> Mike
>>
>>
>> ps - Martin - "derogatory" is a term of art, m= ostly used related to
>> credit worthiness,=C2=A0=C2=A0 it differs from negative,= in that the derogatory
>> info may affect the credit score, but there might be other negative
>> information that can't be taken into account due to legal issues
>> (e.g. for this "the RSEA is too old for the job&quo= t; would be a negative
>> comment, but not a derogatory one as age discrimination is generally
>> prohibited and the comment couldn't be considered an= d would need to
>> be discarded when received). Happy though to change to "negative and
>> positive" vice derogatory.
>>
>>
>>
>> On 7/29/2021 11:49 PM, Joel M. Halpern wrote:
>>> I mostly agree with Ekr here.
>>>
>>> The only edge case I see is one that I know has come up with
>>> nomcoms. If nomcoms see a pattern of reports of an issue, they have
>>> been known to say to a candidate "there have be= en issues raised
>>> about X.=C2=A0 Do you have any comment on that?"= ;=C2=A0=C2=A0 This is not the same
>>> as showing the candidate the feedback, even sanitized. It does
>>> reveal that information has been provided. (And, even more
>>> importantly, ti does not give even a large portion of the
>>> feedback.)=C2=A0 The nomcoms where I know this came = up concluded that the
>>> combination of seeing the candidates reaction and giving then a
>>> chance to respond was worth pushing that envelop.=C2=A0=C2=A0 Do we consider
>>> that the selection committee or LLC or someone has that right under
>>> this process already?=C2=A0 Do we want to say anythi= ng about it?
>>>
>>> Yours,
>>> Joel
>>>
>>> On 7/29/2021 11:34 PM, Eric Rescorla wrote:
>>>>
>>>>
>>>> On Thu, Jul 29, 2021 at 5:00 PM Michael StJohns
>>>> <msj@nthpermutation.com <mailto:msj@nthpermutation.com>> wrote:
>>>>
>>>> =C2=A0=C2=A0=C2=A0 Replacement for section 4.2:<= br> >>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2= =A0 =C2=A0=C2=A0=C2=A0 <<< Set a schedule - could be omitted, but this is a
>>>> =C2=A0=C2=A0=C2=A0 promise to
>>>> =C2=A0=C2=A0=C2=A0 the community
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 as we= ll as a schedule for the IED/RSEA >>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 No m= ore often than semi-annually nor less often than
>>>> bi-yearly, the
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 IETF= Executive Director will send out to the community a
>>>> call for
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 inpu= t on the performance of the RSEA.
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2= =A0 <<< Separate the IED's recommendation from the feedback
>>>> process -
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 there may not actually be an action that needs an immediate
>>>> =C2=A0=C2=A0=C2=A0 recommendation >>> >>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 <= <<< the IED acts as the confidentiality mediator,
>>>> anonymous and
>>>> =C2=A0=C2=A0=C2=A0 confidential
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 comments get tagged in = the document that goes to the
>>>> =C2=A0=C2=A0=C2=A0 LLC -
>>>> =C2=A0=C2=A0=C2=A0 this provides
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 needed context. >>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 The = IETF Executive Director and the stream managers will
>>>> review the
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 rece= ived feedback and produce a draft summary (a paraphrase)
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 incl= uding both positive and derogatory information. Any
>>>> feedback
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 prov= ided anonymously shall be tagged as such in the
>>>> summary. Any
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 feed= back provided with a request for confidentiality shall
>>>> likewise
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 be t= agged in the summary and the IETF Executive Director MAY
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 comm= ent on the weight that may be appropriate to apply to the
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 comm= ent based on their knowledge of the submitter. The stream
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 mana= gers should ensure that any of their concerns are
>>>> added to the
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 docu= ment at this point and MAY also provide any commentary
>>>> on the
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 exte= rnally provided feedback that they feel appropriate.
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 <= << Make sure that the LLC hears both sides of the coin >>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 That= draft feedback, redacted with respect to any names
>>>> associated
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 with= confidential comments and with respect to the IED's
>>>> weight
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 eval= uations, shall be provided to the RSEA with for
>>>> comment or
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 rebu= ttal, and such comments shall be incorporated as an
>>>> appendix to
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 the = final feedback document provided to the IETF LLC Board.
>>>>
>>>>
>>>> This doesn't seem appropriate to me.
>>>>
>>>> If people want to provide confidential comments, then they
>>>> shouldn't be supplied to the RSEA,
>>>> nor should the IED's weights. This is not a legal proceeding, it's
>>>> a performance review, and
>>>> there's no generic reason that the RSEA should get to hear all the
>>>> feedback that the LLC is
>>>> receiving.
>>>>
>>>> -Ekr
>>>>
>>>>
>>

--
Rfced-future mailing list
Rfced-f= uture@iab.org
https://www.iab.org/mailman/listinfo/rfce= d-future


--0000000000001119bd05c886ca2a-- From nobody Sun Aug 1 16:05:49 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF39D3A16FC for ; Sun, 1 Aug 2021 16:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, 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 YRE29yicvSWr for ; Sun, 1 Aug 2021 16:05:46 -0700 (PDT) Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (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 D0A403A16F8 for ; Sun, 1 Aug 2021 16:05:46 -0700 (PDT) Received: by mail-pj1-x1033.google.com with SMTP id b1-20020a17090a8001b029017700de3903so17280610pjn.1 for ; Sun, 01 Aug 2021 16:05:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=ek91xzbn2NQGFlbQ6mPb48QdPcCNGGlCXjYyNP2DP2o=; b=izvdNRavG2vEQvOv9Q5GVsGyxUIVTH/gT/pWVXkprz0//Ya/4MTSa1VBsHBXm8+iWu bbFOeTTGcf309M9uS7nR2aH5j1P/45DVXxfK5F7VPBEPMULZ/0wv+IPN5W9OcygxMa6e MO7sLXv6/dfQSVN45Mrs1RFT2N2PRzgq0caVAuhtnC1R+YAxI3DU0rb7703KyTJ8AEA7 2qzCxD4owthJgHEPKKNSnRBLlTVMT7G8ZpPRW7rPCXmWYFJpLczwgBHAp7FWwd2cBsfn zbz5nNIWa+sJvMbrKGTvEXMaUUpsvf5QHlcc6eR4QHa4zToQzYf9ImtjBedLA+E2djjf R7uQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ek91xzbn2NQGFlbQ6mPb48QdPcCNGGlCXjYyNP2DP2o=; b=ZLZBqQ9AXpJexwSywMQUoBV4oH6hBmf3CmFFTyP5kWOwvjG4z6GMtqqNbTn8Pbie+9 t75pD82cQE7nVUXTDpn9VgJPwKEmtV9EJniaXM3uk3201bY4eoLoNlO7J7LrbAleWQ5Y iFmu9tpWv9sHCGjD36dk66MbdtYWACsx9NQhWdeI7/HDA6Hi7/Rsn7OpxVYdo0cI+xFu YXeCfz88Iaqs0gKLirtYP4dOrRzC1JBALPJeO08zctFASur2nDmIMhTc1aF/PiBY/2wg VcgKPKnM0iqIHQxKHA+NpDYafMS9oqH18thG5GEEwxcfi/pUwYtDNe0/rqWNcJT1qdGc iFFA== X-Gm-Message-State: AOAM531MyuecwxkZ0IkDW54ngvcnw9f0L1r7mD/5Tn3s/8ggZcIaA5kd 1GhyazQD0tgUl2KgoJDLhwX0s9BD69HMQQ== X-Google-Smtp-Source: ABdhPJzchtTfX/k+mLWABWXkoQngJwpWUTEIo0u9yTen9hrDdyLKPl7DDC0rvn9QYRSjA99M1l2Q+A== X-Received: by 2002:a05:6a00:139e:b029:337:1895:b702 with SMTP id t30-20020a056a00139eb02903371895b702mr13841111pfg.39.1627859145528; Sun, 01 Aug 2021 16:05:45 -0700 (PDT) Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id d134sm9459833pfd.60.2021.08.01.16.05.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 01 Aug 2021 16:05:45 -0700 (PDT) To: "Joel M. Halpern" , Michael StJohns Cc: rfced-future@iab.org References: <6b5f89e8-2d79-016b-65bb-39704c438e96@nthpermutation.com> <2739d8af-209a-6714-c21c-d723fbd941fd@joelhalpern.com> <59a3aeda-0a76-eed9-70ac-ad2739c15eb5@nthpermutation.com> From: Brian E Carpenter Message-ID: <65be7d04-8efc-65d8-eb12-f08b597e3fe5@gmail.com> Date: Mon, 2 Aug 2021 11:05:40 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Replacement text for Section 4.2 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Aug 2021 23:05:48 -0000 I have to say that the notion of our colleague Joel as a young man being dinged for typing too loudly has made my day. (I certainly typed too loudly as a grad student, since all the PDP-8 code that I wrote had to be keyed into an ASR-33 teletype, and typing quietly on that device was physically impossible.) Regards Brian Carpenter From nobody Sun Aug 1 16:09:21 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 118123A1728 for ; Sun, 1 Aug 2021 16:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.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 jbBrTZqB0wSg for ; Sun, 1 Aug 2021 16:09:14 -0700 (PDT) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 04DC63A1726 for ; Sun, 1 Aug 2021 16:09:13 -0700 (PDT) Received: by mail-qk1-x72a.google.com with SMTP id x3so15030536qkl.6 for ; Sun, 01 Aug 2021 16:09:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=K6KX0cphdCVxs5obFx1JK/WRTw8WrBVlDInGY6W9e2s=; b=b9DSzHsRggZ5us/fKnabPFtIFH9fXekYlfOy82okaAC1NLD3grjMiu2Tj5lnrHLX7c OlTu6mwnBcqjvy1vz5iUbcK98vC7Eu11JyRy6S2XnIdDbbwkRETHnCpTVNrty4NWa1Ay RsxDow+IHOe0pv1617ANqetEV3vXRNOFhXXd3Cev+AJ6iJBLqlAd/er007wm5AFSYfCi OpU1uqD2xDS9iXoiWpUehaCNRrUhCSSCPmoaTfJwvk0ZfJ+FZcN2F/mYjOxtro7zmuHX mESItEmY/SbCU0zQmBCNBHGfZMn3mf43f5CJQ/FOGcxNjaJvb0Kj9hXj59Gpp//7dBhm r30A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=K6KX0cphdCVxs5obFx1JK/WRTw8WrBVlDInGY6W9e2s=; b=rsM0m4zkmqBlDmMFkYR0WOVfpW59dZSjp9G+cz/8BDWNA8WU8i3Xo/NXgF1y49a8KL hrzXfGUFmux0MW8f6RQpDmVhETCaWEEuMf0YyjpDXqI3uQFS0ld2UOVM116vX2mjGi5h G1JskBYgfsnwHsXEMraUCkohihc/P6+HNPmKY18BT3ZP/eVyA2jhJv68AA7OZaFV6mcs ol3XhWbexv2ngZV5wc09HNW6unMfjJLcAvg/NcmO3ae4Swhn1PcIRGiPX9051/o7tQPh BsXFNPz2jdp7hxUqVJxp8YrkLm38gJNW7xwGldPkawR20r8avOK3C6eSRlYTQb80u1SI 4Zeg== X-Gm-Message-State: AOAM532fQOle7Azo6K4Ev7FNcQt1F+OPqnOMvIwe/YOPH6cA8LTEwRGR eLwtM3chtRKuSFEI2trKlXozicBoudRyoz33 X-Google-Smtp-Source: ABdhPJz0rHjIDyvT2qzwP3it3b1y4HY/3MeeljeakzHQ0C8oCFZDjAE9EfdP3KM5CeDb3JGuQs15rQ== X-Received: by 2002:a05:620a:31a:: with SMTP id s26mr13138660qkm.80.1627859352401; Sun, 01 Aug 2021 16:09:12 -0700 (PDT) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id o24sm3856440qtt.21.2021.08.01.16.09.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 01 Aug 2021 16:09:11 -0700 (PDT) To: Eric Rescorla Cc: "Joel M. Halpern" , rfced-future@iab.org References: <6b5f89e8-2d79-016b-65bb-39704c438e96@nthpermutation.com> <2739d8af-209a-6714-c21c-d723fbd941fd@joelhalpern.com> <59a3aeda-0a76-eed9-70ac-ad2739c15eb5@nthpermutation.com> From: Michael StJohns Message-ID: <59fd0a3a-f0b2-d66b-ae6a-4909ba5a25d6@nthpermutation.com> Date: Sun, 1 Aug 2021 19:09:10 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------090ACFEAA7E88731D162EEDF" Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Replacement text for Section 4.2 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Aug 2021 23:09:19 -0000 This is a multi-part message in MIME format. --------------090ACFEAA7E88731D162EEDF Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit So delete section 4.2 in its entirety? I'm good with that. Mike On 8/1/2021 6:14 PM, Eric Rescorla wrote: > > > On Sun, Aug 1, 2021 at 3:10 PM Michael StJohns > wrote: > > Strangely enough I'd be happy with omitting any requirement for > the LLC to accept comments from the community and that includes > the RSAB.  But I grok, that is not what some people want, and if > there is a requirement for community feed back, then there needs > to be a way of ensuring that feedback goes through some form of > fairness filter > > > The details of this seem like something that we could leave to the LLC > to decide. > > > and a way for the target of that feedback to rebut or provide > context for negative feedback. > > > This seems like something that might be good practice in many cases > and bad in some others, but in any case doesn't need to be encoded in > an RFC. > > -Ekr > > > > > On 8/1/2021 5:53 PM, Eric Rescorla wrote: >> It might be useful to distinguish here between what we think is good >> practice and what this RFC is going to require. >> >> In general, the executive management of a company has a fair amount >> of latitude in what kind of HR practices they want to employ (subject >> to local law, of course) They can do 360 reviews or not, solicit peer >> feedback or not, share it with the employee or not, etc. I would >> expect the same here, with the LLC and the IED being responsible for >> making those decisions. For us to put specific requirements about how >> that feedback is collected and shared is a bit like writing that into >> the company bylaws. Perhaps there is some point which is truly >> necessary to be encoded in such a way that it constrains the LLC but >> none of this text seems to me to fit that bill. >> >> What I would prefer, therefore, is to omit essentially all of this >> material. To the extent to which the community wishes to have input >> on those processes, well, that's why the LLC board is answerable to >> the community. And of course the RSWG can always write an RFC to add >> new requirements if it deems it necessary in the future. >> >> -Ekr >> >> >> On Sun, Aug 1, 2021 at 2:37 PM Michael StJohns >> > wrote: >> >> On 8/1/2021 5:11 PM, Joel M. Halpern wrote: >> > I am not following the bottom part of your note. >> > >> > We are not a government agency, subject to government contracting >> > regulations. >> >> I know that - but we are a non-profit corporation incorporated >> within US >> and mostly subject to US labor laws and practices. All I'm saying is >> that telling people that their comments will always remain >> confidential >> may run up against the law which says that's not the case. >> >> > As far as I know, the restrictions on a company for hiring and >> firing >> > contractors is always more generous than for employees.  The >> closest I >> > have gotten in a review to knowing what the comments were from >> other >> > people was when my boss at my first job out of school told me >> that he >> > had received complaints (no idea of number, I did not get to >> see the >> > complaints) that I typed too loudly.   (I took this as a sign >> that I >> > should work somewhere else.) >> >> It a) depends on the contract - board members and C-suite staff >> contracts tend to have some pretty interesting poison pills as do >> by-name contracts for people with rare skills, but the typical >> employee >> is at-will and can be fired for any reason*, and b) it depends on >> the >> country or state.     *As long as those reasons don't implicate a >> few >> fair labor laws and regulations such as age, gender, race, national >> origin, political and religious beliefs, etc. >> >> Re your comment - I took this that your boss had a sense of humor >> and >> provided you with information that had no effect on your actual >> review >> and compensation.  The key thing here is that your boss knew who >> said >> what, and you were given an opportunity to hear the issue. >> >> > >> > I would expect that the LLC would want to get concerns discussed >> > (which is why I raised the question to see if others agreed >> that an >> > aggregating question was acceptable. >> >> >> > >> > Forwarding the actual responses (even somewhat redacted) seems >> likely >> > to cause problems.   Among other things, it seems likely to >> discourage >> > negative feedback. >> >> Contrariwise, not providing negative feedback to the RSEA is >> unlikely to >> result in any improvements if they are warranted.  And given this >> community, it's possible that the RSEA can provide missing >> context on a >> prospectively negative comment to assist the LLC in deciding what >> actions need to be taken. >> >> And sorry - I'm not sure who gets to see the actual results in your >> model.  Can you tell me what each of RSAB, IED, LLC and the RSEA >> see please? >> >> >> > >> > Sure, a law suit can of course be filed in the US under almost any >> > circumstance.  And can attempt to subpoena almost anything.  >> But that >> > does not justify over-sharing information during the normal >> process. >> >> I still hesitate to see how providing the RSEA a >> summary/redaction of >> the comments received and allowing them to provide a response is >> "over-sharing". >> >> >> Later, Mike >> >> >> >> > >> > Yours, >> > Joel >> > >> > On 8/1/2021 4:48 PM, Michael StJohns wrote: >> >> Let me break this down into two section: 1) What is the scope of >> >> confidentiality?  2) What does the RSEA get to see and comment on >> >> prior to it going to the LLC - if anything? >> >> >> >> For confidentiality, I have these questions: >> >> >> >> 1) Are truly anonymous comments permitted? >> >> 2) Does the IED get to see all of the comments with the source >> >> unredacted? >> >> 3) Does the RSAB get to see all of the comments? >> >>     3a) paraphrased? >> >>     3b) source unredacted? >> >>     3c) source redacted? >> >>        3c.1) With redactors comment on the source? >> >>        3c.2) Without comment >> >> 4) Does the LLC get to see all of the comments? >> >>     4a) paraphrased? >> >>     4b) source unredacted? >> >>     4c) source redacted? >> >>         4c.1) With redactors comment on the source >> >>         4c.2) Without comment on the source >> >> >> >> I assume that if the IED gets to see all comments, they will >> act as >> >> redactor for any further distribution if redaction is required. >> >> >> >> In the draft I assumed that 1, 2), 3c.1), and 4c.1) were the >> answers >> >> to the above questions because of the comments that were made >> by the >> >> call about confidentiality.    Obviously, if the LLC and the >> RSAB get >> >> to see everything, there won't be a redaction and comment on the >> >> source necessary.   If the LLC doesn't get to see everything, >> then it >> >> at least needs the context of possible biases from the >> submitters of >> >> the comments to help it understand the reality on the ground. >> >> >> >> For the RSEA, I believe that it needs to be a bit more that Joel >> >> suggests below - and instead we should be making sure that any >> >> comment that will be considered by the LLC has to be provided >> to the >> >> RSEA for feedback and rebuttal in at least a paraphrased form.  I >> >> don't think the RSEA gets to know about any of the sources, >> but it >> >> seems both unfair and legally fraught not to provide them with an >> >> opportunity to make an opposing case for any negative comments. >> >> >> >> And I'm glad that EKR brought up "legal". Unlike the Nomcom >> process >> >> there is/will be a financial relationship between the LLC and the >> >> RSEA in the form of either an employment agreement or >> contract.   In >> >> the event that the LLC moves to terminate that relationship, >> if the >> >> RSEA feels it is being done for "unfair" reasons and can make >> a case >> >> to a legal standard in the appropriate legal venue, _*each and >> every >> >> comment, and all emails and notes discussing those comments >> will be >> >> subject to subpoena and the related depositions*_. >> >> >> >> And lastly - no company I know of solicits company wide comments >> >> (unless the company is really tiny) on a particular employee's >> >> performance, nor does the manager not know who made the >> comment and >> >> hence that manager can accurately weigh said comments.  It >> would be a >> >> truly bad manager that did not ask an employee about their >> take on >> >> any  negative comments the manager received and the manager >> should >> >> help them redress any actual problems. >> >> >> >> Mike >> >> >> >> >> >> ps - Martin - "derogatory" is a term of art, mostly used >> related to >> >> credit worthiness,   it differs from negative, in that the >> derogatory >> >> info may affect the credit score, but there might be other >> negative >> >> information that can't be taken into account due to legal issues >> >> (e.g. for this "the RSEA is too old for the job" would be a >> negative >> >> comment, but not a derogatory one as age discrimination is >> generally >> >> prohibited and the comment couldn't be considered and would >> need to >> >> be discarded when received). Happy though to change to >> "negative and >> >> positive" vice derogatory. >> >> >> >> >> >> >> >> On 7/29/2021 11:49 PM, Joel M. Halpern wrote: >> >>> I mostly agree with Ekr here. >> >>> >> >>> The only edge case I see is one that I know has come up with >> >>> nomcoms. If nomcoms see a pattern of reports of an issue, >> they have >> >>> been known to say to a candidate "there have been issues raised >> >>> about X.  Do you have any comment on that?"   This is not the >> same >> >>> as showing the candidate the feedback, even sanitized. It does >> >>> reveal that information has been provided. (And, even more >> >>> importantly, ti does not give even a large portion of the >> >>> feedback.)  The nomcoms where I know this came up concluded >> that the >> >>> combination of seeing the candidates reaction and giving then a >> >>> chance to respond was worth pushing that envelop.   Do we >> consider >> >>> that the selection committee or LLC or someone has that right >> under >> >>> this process already?  Do we want to say anything about it? >> >>> >> >>> Yours, >> >>> Joel >> >>> >> >>> On 7/29/2021 11:34 PM, Eric Rescorla wrote: >> >>>> >> >>>> >> >>>> On Thu, Jul 29, 2021 at 5:00 PM Michael StJohns >> >>>> >> >> >> wrote: >> >>>> >> >>>>     Replacement for section 4.2: >> >>>> >> >>>>               <<< Set a schedule - could be omitted, but >> this is a >> >>>>     promise to >> >>>>     the community >> >>>> >> >>>>                      as well as a schedule for the IED/RSEA >>> >> >>>>          No more often than semi-annually nor less often than >> >>>> bi-yearly, the >> >>>>          IETF Executive Director will send out to the >> community a >> >>>> call for >> >>>>          input on the performance of the RSEA. >> >>>> >> >>>>           <<< Separate the IED's recommendation from the >> feedback >> >>>> process - >> >>>> >> >>>>            there may not actually be an action that needs an >> immediate >> >>>>     recommendation >>> >> >>>> >> >>>>          <<<< the IED acts as the confidentiality mediator, >> >>>> anonymous and >> >>>>     confidential >> >>>> >> >>>>                   comments get tagged in the document that >> goes to the >> >>>>     LLC - >> >>>>     this provides >> >>>> >> >>>>                   needed context. >>>> >> >>>>          The IETF Executive Director and the stream managers >> will >> >>>> review the >> >>>>          received feedback and produce a draft summary (a >> paraphrase) >> >>>>          including both positive and derogatory information. >> Any >> >>>> feedback >> >>>>          provided anonymously shall be tagged as such in the >> >>>> summary. Any >> >>>>          feedback provided with a request for >> confidentiality shall >> >>>> likewise >> >>>>          be tagged in the summary and the IETF Executive >> Director MAY >> >>>>          comment on the weight that may be appropriate to >> apply to the >> >>>>          comment based on their knowledge of the submitter. >> The stream >> >>>>          managers should ensure that any of their concerns are >> >>>> added to the >> >>>>          document at this point and MAY also provide any >> commentary >> >>>> on the >> >>>>          externally provided feedback that they feel >> appropriate. >> >>>> >> >>>>          <<< Make sure that the LLC hears both sides of the >> coin >>> >> >>>>          That draft feedback, redacted with respect to any >> names >> >>>> associated >> >>>>          with confidential comments and with respect to the >> IED's >> >>>> weight >> >>>>          evaluations, shall be provided to the RSEA with for >> >>>> comment or >> >>>>          rebuttal, and such comments shall be incorporated >> as an >> >>>> appendix to >> >>>>          the final feedback document provided to the IETF >> LLC Board. >> >>>> >> >>>> >> >>>> This doesn't seem appropriate to me. >> >>>> >> >>>> If people want to provide confidential comments, then they >> >>>> shouldn't be supplied to the RSEA, >> >>>> nor should the IED's weights. This is not a legal >> proceeding, it's >> >>>> a performance review, and >> >>>> there's no generic reason that the RSEA should get to hear >> all the >> >>>> feedback that the LLC is >> >>>> receiving. >> >>>> >> >>>> -Ekr >> >>>> >> >>>> >> >> >> >> -- >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future >> >> > --------------090ACFEAA7E88731D162EEDF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
So delete section 4.2 in its entirety?  I'm good with that.

Mike


On 8/1/2021 6:14 PM, Eric Rescorla wrote:


On Sun, Aug 1, 2021 at 3:10 PM Michael StJohns <msj@nthpermutation.com> wrote:
Strangely enough I'd be happy with omitting any requirement for the LLC to accept comments from the community and that includes the RSAB.  But I grok, that is not what some people want, and if there is a requirement for community feed back, then there needs to be a way of ensuring that feedback goes through some form of fairness filter

The details of this seem like something that we could leave to the LLC to decide.


and a way for the target of that feedback to rebut or provide context for negative feedback.

This seems like something that might be good practice in many cases and bad in some others, but in any case doesn't need to be encoded in an RFC.

-Ekr




On 8/1/2021 5:53 PM, Eric Rescorla wrote:
It might be useful to distinguish here between what we think is good practice and what this RFC is going to require.

In general, the executive management of a company has a fair amount of latitude in what kind of HR practices they want to employ (subject to local law, of course) They can do 360 reviews or not, solicit peer feedback or not, share it with the employee or not, etc. I would expect the same here, with the LLC and the IED being responsible for making those decisions. For us to put specific requirements about how that feedback is collected and shared is a bit like writing that into the company bylaws. Perhaps there is some point which is truly necessary to be encoded in such a way that it constrains the LLC but none of this text seems to me to fit that bill.

What I would prefer, therefore, is to omit essentially all of this material. To the extent to which the community wishes to have input on those processes, well, that's why the LLC board is answerable to the community. And of course the RSWG can always write an RFC to add new requirements if it deems it necessary in the future.

-Ekr


On Sun, Aug 1, 2021 at 2:37 PM Michael StJohns <msj@nthpermutation.com> wrote:
On 8/1/2021 5:11 PM, Joel M. Halpern wrote:
> I am not following the bottom part of your note.
>
> We are not a government agency, subject to government contracting
> regulations.

I know that - but we are a non-profit corporation incorporated within US
and mostly subject to US labor laws and practices.  All I'm saying is
that telling people that their comments will always remain confidential
may run up against the law which says that's not the case.

> As far as I know, the restrictions on a company for hiring and firing
> contractors is always more generous than for employees.  The closest I
> have gotten in a review to knowing what the comments were from other
> people was when my boss at my first job out of school told me that he
> had received complaints (no idea of number, I did not get to see the
> complaints) that I typed too loudly.   (I took this as a sign that I
> should work somewhere else.)

It a) depends on the contract - board members and C-suite staff
contracts tend to have some pretty interesting poison pills as do
by-name contracts for people with rare skills, but the typical employee
is at-will and can be fired for any reason*, and b) it depends on the
country or state.     *As long as those reasons don't implicate a few
fair labor laws and regulations such as age, gender, race, national
origin, political and religious beliefs, etc.

Re your comment - I took this that your boss had a sense of humor and
provided you with information that had no effect on your actual review
and compensation.  The key thing here is that your boss knew who said
what, and you were given an opportunity to hear the issue.

>
> I would expect that the LLC would want to get concerns discussed
> (which is why I raised the question to see if others agreed that an
> aggregating question was acceptable.


>
> Forwarding the actual responses (even somewhat redacted) seems likely
> to cause problems.   Among other things, it seems likely to discourage
> negative feedback.

Contrariwise, not providing negative feedback to the RSEA is unlikely to
result in any improvements if they are warranted.  And given this
community, it's possible that the RSEA can provide missing context on a
prospectively negative comment to assist the LLC in deciding what
actions need to be taken.

And sorry - I'm not sure who gets to see the actual results in your
model.  Can you tell me what each of RSAB, IED, LLC and the RSEA see please?


>
> Sure, a law suit can of course be filed in the US under almost any
> circumstance.  And can attempt to subpoena almost anything.  But that
> does not justify over-sharing information during the normal process.

I still hesitate to see how providing the RSEA a summary/redaction of
the comments received and allowing them to provide a response is
"over-sharing".


Later, Mike



>
> Yours,
> Joel
>
> On 8/1/2021 4:48 PM, Michael StJohns wrote:
>> Let me break this down into two section: 1) What is the scope of
>> confidentiality?  2) What does the RSEA get to see and comment on
>> prior to it going to the LLC - if anything?
>>
>> For confidentiality, I have these questions:
>>
>> 1) Are truly anonymous comments permitted?
>> 2) Does the IED get to see all of the comments with the source
>> unredacted?
>> 3) Does the RSAB get to see all of the comments?
>>     3a) paraphrased?
>>     3b) source unredacted?
>>     3c) source redacted?
>>        3c.1) With redactors comment on the source?
>>        3c.2) Without comment
>> 4) Does the LLC get to see all of the comments?
>>     4a) paraphrased?
>>     4b) source unredacted?
>>     4c) source redacted?
>>         4c.1) With redactors comment on the source
>>         4c.2) Without comment on the source
>>
>> I assume that if the IED gets to see all comments, they will act as
>> redactor for any further distribution if redaction is required.
>>
>> In the draft I assumed that 1, 2), 3c.1), and 4c.1) were the answers
>> to the above questions because of the comments that were made by the
>> call about confidentiality.    Obviously, if the LLC and the RSAB get
>> to see everything, there won't be a redaction and comment on the
>> source necessary.   If the LLC doesn't get to see everything, then it
>> at least needs the context of possible biases from the submitters of
>> the comments to help it understand the reality on the ground.
>>
>> For the RSEA, I believe that it needs to be a bit more that Joel
>> suggests below - and instead we should be making sure that any
>> comment that will be considered by the LLC has to be provided to the
>> RSEA for feedback and rebuttal in at least a paraphrased form.  I
>> don't think the RSEA gets to know about any of the sources, but it
>> seems both unfair and legally fraught not to provide them with an
>> opportunity to make an opposing case for any negative comments.
>>
>> And I'm glad that EKR brought up "legal".   Unlike the Nomcom process
>> there is/will be a financial relationship between the LLC and the
>> RSEA in the form of either an employment agreement or contract.   In
>> the event that the LLC moves to terminate that relationship, if the
>> RSEA feels it is being done for "unfair" reasons and can make a case
>> to a legal standard in the appropriate legal venue, _*each and every
>> comment, and all emails and notes discussing those comments will be
>> subject to subpoena and the related depositions*_.
>>
>> And lastly - no company I know of solicits company wide comments
>> (unless the company is really tiny) on a particular employee's
>> performance, nor does the manager not know who made the comment and
>> hence that manager can accurately weigh said comments.  It would be a
>> truly bad manager that did not ask an employee about their take on
>> any  negative comments the manager received and the manager should
>> help them redress any actual problems.
>>
>> Mike
>>
>>
>> ps - Martin - "derogatory" is a term of art, mostly used related to
>> credit worthiness,   it differs from negative, in that the derogatory
>> info may affect the credit score, but there might be other negative
>> information that can't be taken into account due to legal issues
>> (e.g. for this "the RSEA is too old for the job" would be a negative
>> comment, but not a derogatory one as age discrimination is generally
>> prohibited and the comment couldn't be considered and would need to
>> be discarded when received). Happy though to change to "negative and
>> positive" vice derogatory.
>>
>>
>>
>> On 7/29/2021 11:49 PM, Joel M. Halpern wrote:
>>> I mostly agree with Ekr here.
>>>
>>> The only edge case I see is one that I know has come up with
>>> nomcoms. If nomcoms see a pattern of reports of an issue, they have
>>> been known to say to a candidate "there have been issues raised
>>> about X.  Do you have any comment on that?"   This is not the same
>>> as showing the candidate the feedback, even sanitized. It does
>>> reveal that information has been provided. (And, even more
>>> importantly, ti does not give even a large portion of the
>>> feedback.)  The nomcoms where I know this came up concluded that the
>>> combination of seeing the candidates reaction and giving then a
>>> chance to respond was worth pushing that envelop.   Do we consider
>>> that the selection committee or LLC or someone has that right under
>>> this process already?  Do we want to say anything about it?
>>>
>>> Yours,
>>> Joel
>>>
>>> On 7/29/2021 11:34 PM, Eric Rescorla wrote:
>>>>
>>>>
>>>> On Thu, Jul 29, 2021 at 5:00 PM Michael StJohns
>>>> <msj@nthpermutation.com <mailto:msj@nthpermutation.com>> wrote:
>>>>
>>>>     Replacement for section 4.2:
>>>>
>>>>               <<< Set a schedule - could be omitted, but this is a
>>>>     promise to
>>>>     the community
>>>>
>>>>                      as well as a schedule for the IED/RSEA >>>
>>>>          No more often than semi-annually nor less often than
>>>> bi-yearly, the
>>>>          IETF Executive Director will send out to the community a
>>>> call for
>>>>          input on the performance of the RSEA.
>>>>
>>>>           <<< Separate the IED's recommendation from the feedback
>>>> process -
>>>>
>>>>            there may not actually be an action that needs an immediate
>>>>     recommendation >>>
>>>>
>>>>          <<<< the IED acts as the confidentiality mediator,
>>>> anonymous and
>>>>     confidential
>>>>
>>>>                   comments get tagged in the document that goes to the
>>>>     LLC -
>>>>     this provides
>>>>
>>>>                   needed context. >>>>
>>>>          The IETF Executive Director and the stream managers will
>>>> review the
>>>>          received feedback and produce a draft summary (a paraphrase)
>>>>          including both positive and derogatory information. Any
>>>> feedback
>>>>          provided anonymously shall be tagged as such in the
>>>> summary. Any
>>>>          feedback provided with a request for confidentiality shall
>>>> likewise
>>>>          be tagged in the summary and the IETF Executive Director MAY
>>>>          comment on the weight that may be appropriate to apply to the
>>>>          comment based on their knowledge of the submitter. The stream
>>>>          managers should ensure that any of their concerns are
>>>> added to the
>>>>          document at this point and MAY also provide any commentary
>>>> on the
>>>>          externally provided feedback that they feel appropriate.
>>>>
>>>>          <<< Make sure that the LLC hears both sides of the coin >>>
>>>>          That draft feedback, redacted with respect to any names
>>>> associated
>>>>          with confidential comments and with respect to the IED's
>>>> weight
>>>>          evaluations, shall be provided to the RSEA with for
>>>> comment or
>>>>          rebuttal, and such comments shall be incorporated as an
>>>> appendix to
>>>>          the final feedback document provided to the IETF LLC Board.
>>>>
>>>>
>>>> This doesn't seem appropriate to me.
>>>>
>>>> If people want to provide confidential comments, then they
>>>> shouldn't be supplied to the RSEA,
>>>> nor should the IED's weights. This is not a legal proceeding, it's
>>>> a performance review, and
>>>> there's no generic reason that the RSEA should get to hear all the
>>>> feedback that the LLC is
>>>> receiving.
>>>>
>>>> -Ekr
>>>>
>>>>
>>

--
Rfced-future mailing list
Rfced-future@iab.org
https://www.iab.org/mailman/listinfo/rfced-future



--------------090ACFEAA7E88731D162EEDF-- From nobody Sun Aug 1 16:38:37 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEBA93A1813 for ; Sun, 1 Aug 2021 16:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Tx6Qa0DLRVYC for ; Sun, 1 Aug 2021 16:38:32 -0700 (PDT) Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) (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 3B3023A1814 for ; Sun, 1 Aug 2021 16:38:32 -0700 (PDT) Received: by mail-pl1-x62e.google.com with SMTP id k1so17562713plt.12 for ; Sun, 01 Aug 2021 16:38:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=jIAyNUW7tJwDopkk2nChWhfX8DK9nZ041nrMn3k4rWE=; b=mQxbB62fmuvWv+z5iEaUox8zD8IkMyZuI+VMWlwelAeaXmTFtjOAw5rwRGuHmDh37n +JoR9m1zNv6ScvKPWvZ/ftTXPI4BN05O9BL7+EbbtpuSIcRxlhiq9Od7Yu9RdHptqBOc XvEd+pWmk/8XhnxiZQsEsjN4PMj3opDbJeU38vwy7QX/5JOnxkwYTzp/Y60u68+TTGvI pK49Nqzw9mws+mUHEr6bKJDt6rXpnBrlAVhWqYeNGUAC8DI0241iB9QnB6/aFXg7KQN/ Tt1Kt+vZNn0FoT0P+kPJQ+pAlCxZNZMPgFSmhfoakjPTJzI9rD0tx84fixNvNQ4af2IT u9UA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=jIAyNUW7tJwDopkk2nChWhfX8DK9nZ041nrMn3k4rWE=; b=DrdV7npGgn+4RP6XjBLCjxObQXyypJGkJ9PJiPC4H/fne1JwUIK1SbB4xrK/syTgfe e9TUVyZCEUSd7PSgYY7PReym30XV/aAZc6iMjKMZ/5q6hppXuRKQoVzdAqTGEivRsqhH F0kcinYIkzPP/AekSjfpa39IIopxEG6PeGeoKw469oMn6mjWC5ETJaRuwCrn90bLnyET m6DOTNo8WJ7ZslSN+8gUjtNHNev4Bf7vSX23UhkIvEV7AAurasqB3k5pwPOw4BZJidpT HNxg/FwjscP7Uc4sQYFg/wyp8Ldb8pc6954mlE13fPW2jAYNlRUoO1mnjEBKHiCleMed aZcw== X-Gm-Message-State: AOAM533bikKBQkI70DRGi60MVdu8o8YeVzQCZCcCOL+oEs1BMEbyhKhd lSbv3GTl3MdaeeUmRuykmB8= X-Google-Smtp-Source: ABdhPJz1vQQtaAa4um3sE38TUvFPa94LHVqMn/dDRoW95sm86lEL/fCylJ8F/5SAJNI8Fplmp1ilaQ== X-Received: by 2002:a62:7dcb:0:b029:3af:8a46:a7e4 with SMTP id y194-20020a627dcb0000b02903af8a46a7e4mr13252286pfc.20.1627861110580; Sun, 01 Aug 2021 16:38:30 -0700 (PDT) Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id t37sm9628151pfg.14.2021.08.01.16.38.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 01 Aug 2021 16:38:29 -0700 (PDT) To: Michael StJohns , Eric Rescorla Cc: rfced-future@iab.org, "Joel M. Halpern" References: <6b5f89e8-2d79-016b-65bb-39704c438e96@nthpermutation.com> <2739d8af-209a-6714-c21c-d723fbd941fd@joelhalpern.com> <59a3aeda-0a76-eed9-70ac-ad2739c15eb5@nthpermutation.com> <59fd0a3a-f0b2-d66b-ae6a-4909ba5a25d6@nthpermutation.com> From: Brian E Carpenter Message-ID: Date: Mon, 2 Aug 2021 11:38:24 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <59fd0a3a-f0b2-d66b-ae6a-4909ba5a25d6@nthpermutation.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Replacement text for Section 4.2 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Aug 2021 23:38:37 -0000 On 02-Aug-21 11:09, Michael StJohns wrote: > So delete section 4.2 in its entirety?=C2=A0 I'm good with that. Really? I agree that it is not a good idea to specify too many details; t= he LLC clearly owns the process, but stating that community feedback is p= art of the process seems desirable. Something like: Periodically, the IETF LLC will evaluate the performance of the RSEA, including a call for confidential input from the community. Also the last sentence of the current text needs to be said somewhere: Whether the RSEA role is structured as a contractual or employee relationship is a matter for the IETF LLC and the IETF Executive Director to determine. Brian >=20 > Mike >=20 >=20 > On 8/1/2021 6:14 PM, Eric Rescorla wrote: >> >> >> On Sun, Aug 1, 2021 at 3:10 PM Michael StJohns > wrote: >> >> Strangely enough I'd be happy with omitting any requirement for th= e LLC to accept comments from the community and that includes the RSAB.=C2= =A0 But I grok, that is not what some people want, and if there is a requ= irement for community feed back, then there needs to be a way of ensuring=20 that feedback goes through some form of fairness filter >> >> >> The details of this seem like something that we could leave to the LLC=20 to decide. >> >> >> and a way for the target of that feedback to rebut or provide cont= ext for negative feedback. >> >> >> This seems like something that might be good practice in many cases an= d bad in some others, but in any case doesn't need to be encoded in an RF= C. >> >> -Ekr >> >> >> >> >> On 8/1/2021 5:53 PM, Eric Rescorla wrote: >>> It might be useful to distinguish here between what we think is good = practice and what this RFC is going to require. >>> >>> In general, the executive management of a company has a fair amount o= f latitude in what kind of HR practices they want to employ (subject to l= ocal law, of course) They can do 360 reviews or not, solicit peer feedbac= k or not, share it with the employee or not, etc. I would expect the same=20 here, with the LLC and the IED being responsible for making those decisio= ns. For us to put specific requirements about how that feedback is collec= ted and shared is a bit like writing that into the company bylaws. Perhap= s there is some point which is truly necessary to be encoded in such a wa= y that it constrains the LLC but none of this text seems to me to fit tha= t bill. >>> >>> What I would prefer, therefore, is to omit essentially all of this ma= terial. To the extent to which the community wishes to have input on thos= e processes, well, that's why the LLC board is answerable to the communit= y. And of course the RSWG can always write an RFC to add new requirements=20 if it deems it necessary in the future. >>> >>> -Ekr >>> >>> >>> On Sun, Aug 1, 2021 at 2:37 PM Michael StJohns > wrote: >>> >>> On 8/1/2021 5:11 PM, Joel M. Halpern wrote: >>> > I am not following the bottom part of your note. >>> > >>> > We are not a government agency, subject to government contracti= ng >>> > regulations. >>> >>> I know that - but we are a non-profit corporation incorporated wi= thin US >>> and mostly subject to US labor laws and practices.=C2=A0 All I'm = saying is >>> that telling people that their comments will always remain confid= ential >>> may run up against the law which says that's not the case. >>> >>> > As far as I know, the restrictions on a company for hiring and = firing >>> > contractors is always more generous than for employees.=C2=A0 T= he closest I >>> > have gotten in a review to knowing what the comments were from = other >>> > people was when my boss at my first job out of school told me t= hat he >>> > had received complaints (no idea of number, I did not get to se= e the >>> > complaints) that I typed too loudly.=C2=A0=C2=A0 (I took this a= s a sign that I >>> > should work somewhere else.) >>> >>> It a) depends on the contract - board members and C-suite staff >>> contracts tend to have some pretty interesting poison pills as do= >>> by-name contracts for people with rare skills, but the typical em= ployee >>> is at-will and can be fired for any reason*, and b) it depends on=20 the >>> country or state.=C2=A0=C2=A0=C2=A0=C2=A0 *As long as those reaso= ns don't implicate a few >>> fair labor laws and regulations such as age, gender, race, nation= al >>> origin, political and religious beliefs, etc. >>> >>> Re your comment - I took this that your boss had a sense of humor=20 and >>> provided you with information that had no effect on your actual r= eview >>> and compensation.=C2=A0 The key thing here is that your boss knew=20 who said >>> what, and you were given an opportunity to hear the issue. >>> >>> > >>> > I would expect that the LLC would want to get concerns discusse= d >>> > (which is why I raised the question to see if others agreed tha= t an >>> > aggregating question was acceptable. >>> >>> >>> > >>> > Forwarding the actual responses (even somewhat redacted) seems = likely >>> > to cause problems.=C2=A0=C2=A0 Among other things, it seems lik= ely to discourage >>> > negative feedback. >>> >>> Contrariwise, not providing negative feedback to the RSEA is unli= kely to >>> result in any improvements if they are warranted.=C2=A0 And given=20 this >>> community, it's possible that the RSEA can provide missing contex= t on a >>> prospectively negative comment to assist the LLC in deciding what= >>> actions need to be taken. >>> >>> And sorry - I'm not sure who gets to see the actual results in yo= ur >>> model.=C2=A0 Can you tell me what each of RSAB, IED, LLC and the = RSEA see please? >>> >>> >>> > >>> > Sure, a law suit can of course be filed in the US under almost = any >>> > circumstance.=C2=A0 And can attempt to subpoena almost anything= =2E=C2=A0 But that >>> > does not justify over-sharing information during the normal pro= cess. >>> >>> I still hesitate to see how providing the RSEA a summary/redactio= n of >>> the comments received and allowing them to provide a response is >>> "over-sharing". >>> >>> >>> Later, Mike >>> >>> >>> >>> > >>> > Yours, >>> > Joel >>> > >>> > On 8/1/2021 4:48 PM, Michael StJohns wrote: >>> >> Let me break this down into two section: 1) What is the scope = of >>> >> confidentiality?=C2=A0 2) What does the RSEA get to see and co= mment on >>> >> prior to it going to the LLC - if anything? >>> >> >>> >> For confidentiality, I have these questions: >>> >> >>> >> 1) Are truly anonymous comments permitted? >>> >> 2) Does the IED get to see all of the comments with the source= >>> >> unredacted? >>> >> 3) Does the RSAB get to see all of the comments? >>> >> =C2=A0=C2=A0=C2=A0 3a) paraphrased? >>> >> =C2=A0=C2=A0=C2=A0 3b) source unredacted? >>> >> =C2=A0=C2=A0=C2=A0 3c) source redacted? >>> >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 3c.1) With redactors comm= ent on the source? >>> >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 3c.2) Without comment >>> >> 4) Does the LLC get to see all of the comments? >>> >> =C2=A0=C2=A0=C2=A0 4a) paraphrased? >>> >> =C2=A0=C2=A0=C2=A0 4b) source unredacted? >>> >> =C2=A0=C2=A0=C2=A0 4c) source redacted? >>> >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 4c.1) With redactor= s comment on the source >>> >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 4c.2) Without comme= nt on the source >>> >> >>> >> I assume that if the IED gets to see all comments, they will a= ct as >>> >> redactor for any further distribution if redaction is required= =2E >>> >> >>> >> In the draft I assumed that 1, 2), 3c.1), and 4c.1) were the a= nswers >>> >> to the above questions because of the comments that were made = by the >>> >> call about confidentiality.=C2=A0=C2=A0=C2=A0 Obviously, if th= e LLC and the RSAB get >>> >> to see everything, there won't be a redaction and comment on t= he >>> >> source necessary.=C2=A0=C2=A0 If the LLC doesn't get to see ev= erything, then it >>> >> at least needs the context of possible biases from the submitt= ers of >>> >> the comments to help it understand the reality on the ground. >>> >> >>> >> For the RSEA, I believe that it needs to be a bit more that Jo= el >>> >> suggests below - and instead we should be making sure that any= >>> >> comment that will be considered by the LLC has to be provided = to the >>> >> RSEA for feedback and rebuttal in at least a paraphrased form.= =C2=A0 I >>> >> don't think the RSEA gets to know about any of the sources, bu= t it >>> >> seems both unfair and legally fraught not to provide them with=20 an >>> >> opportunity to make an opposing case for any negative comments= =2E >>> >> >>> >> And I'm glad that EKR brought up "legal".=C2=A0=C2=A0 Unlike t= he Nomcom process >>> >> there is/will be a financial relationship between the LLC and = the >>> >> RSEA in the form of either an employment agreement or contract= =2E=C2=A0=C2=A0 In >>> >> the event that the LLC moves to terminate that relationship, i= f the >>> >> RSEA feels it is being done for "unfair" reasons and can make = a case >>> >> to a legal standard in the appropriate legal venue, _*each and=20 every >>> >> comment, and all emails and notes discussing those comments wi= ll be >>> >> subject to subpoena and the related depositions*_. >>> >> >>> >> And lastly - no company I know of solicits company wide commen= ts >>> >> (unless the company is really tiny) on a particular employee's= >>> >> performance, nor does the manager not know who made the commen= t and >>> >> hence that manager can accurately weigh said comments.=C2=A0 I= t would be a >>> >> truly bad manager that did not ask an employee about their tak= e on >>> >> any=C2=A0 negative comments the manager received and the manag= er should >>> >> help them redress any actual problems. >>> >> >>> >> Mike >>> >> >>> >> >>> >> ps - Martin - "derogatory" is a term of art, mostly used relat= ed to >>> >> credit worthiness,=C2=A0=C2=A0 it differs from negative, in th= at the derogatory >>> >> info may affect the credit score, but there might be other neg= ative >>> >> information that can't be taken into account due to legal issu= es >>> >> (e.g. for this "the RSEA is too old for the job" would be a ne= gative >>> >> comment, but not a derogatory one as age discrimination is gen= erally >>> >> prohibited and the comment couldn't be considered and would ne= ed to >>> >> be discarded when received). Happy though to change to "negati= ve and >>> >> positive" vice derogatory. >>> >> >>> >> >>> >> >>> >> On 7/29/2021 11:49 PM, Joel M. Halpern wrote: >>> >>> I mostly agree with Ekr here. >>> >>> >>> >>> The only edge case I see is one that I know has come up with >>> >>> nomcoms. If nomcoms see a pattern of reports of an issue, the= y have >>> >>> been known to say to a candidate "there have been issues rais= ed >>> >>> about X.=C2=A0 Do you have any comment on that?"=C2=A0=C2=A0 = This is not the same >>> >>> as showing the candidate the feedback, even sanitized. It doe= s >>> >>> reveal that information has been provided. (And, even more >>> >>> importantly, ti does not give even a large portion of the >>> >>> feedback.)=C2=A0 The nomcoms where I know this came up conclu= ded that the >>> >>> combination of seeing the candidates reaction and giving then=20 a >>> >>> chance to respond was worth pushing that envelop.=C2=A0=C2=A0=20 Do we consider >>> >>> that the selection committee or LLC or someone has that right=20 under >>> >>> this process already?=C2=A0 Do we want to say anything about = it? >>> >>> >>> >>> Yours, >>> >>> Joel >>> >>> >>> >>> On 7/29/2021 11:34 PM, Eric Rescorla wrote: >>> >>>> >>> >>>> >>> >>>> On Thu, Jul 29, 2021 at 5:00 PM Michael StJohns >>> >>>> >> wrote: >>> >>>> >>> >>>> =C2=A0=C2=A0=C2=A0 Replacement for section 4.2: >>> >>>> >>> >>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0= =C2=A0 <<< Set a schedule - could be omitted, but this is a >>> >>>> =C2=A0=C2=A0=C2=A0 promise to >>> >>>> =C2=A0=C2=A0=C2=A0 the community >>> >>>> >>> >>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 as well as a sched= ule for the IED/RSEA >>> >>> >>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 No more often th= an semi-annually nor less often than >>> >>>> bi-yearly, the >>> >>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 IETF Executive D= irector will send out to the community a >>> >>>> call for >>> >>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 input on the per= formance of the RSEA. >>> >>>> >>> >>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 <<< Separa= te the IED's recommendation from the feedback >>> >>>> process - >>> >>>> >>> >>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ther= e may not actually be an action that needs an immediate >>> >>>> =C2=A0=C2=A0=C2=A0 recommendation >>> >>> >>>> >>> >>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 <<<< the IED act= s as the confidentiality mediator, >>> >>>> anonymous and >>> >>>> =C2=A0=C2=A0=C2=A0 confidential >>> >>>> >>> >>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 comments get tagged in the document = that goes to the >>> >>>> =C2=A0=C2=A0=C2=A0 LLC - >>> >>>> =C2=A0=C2=A0=C2=A0 this provides >>> >>>> >>> >>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 needed context. >>>> >>> >>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 The IETF Executi= ve Director and the stream managers will >>> >>>> review the >>> >>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 received feedbac= k and produce a draft summary (a paraphrase) >>> >>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 including both p= ositive and derogatory information. Any >>> >>>> feedback >>> >>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 provided anonymo= usly shall be tagged as such in the >>> >>>> summary. Any >>> >>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 feedback provide= d with a request for confidentiality shall >>> >>>> likewise >>> >>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 be tagged in the=20 summary and the IETF Executive Director MAY >>> >>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 comment on the w= eight that may be appropriate to apply to the >>> >>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 comment based on=20 their knowledge of the submitter. The stream >>> >>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 managers should = ensure that any of their concerns are >>> >>>> added to the >>> >>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 document at this=20 point and MAY also provide any commentary >>> >>>> on the >>> >>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 externally provi= ded feedback that they feel appropriate. >>> >>>> >>> >>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 <<< Make sure th= at the LLC hears both sides of the coin >>> >>> >>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 That draft feedb= ack, redacted with respect to any names >>> >>>> associated >>> >>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 with confidentia= l comments and with respect to the IED's >>> >>>> weight >>> >>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 evaluations, sha= ll be provided to the RSEA with for >>> >>>> comment or >>> >>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 rebuttal, and su= ch comments shall be incorporated as an >>> >>>> appendix to >>> >>>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 the final feedba= ck document provided to the IETF LLC Board. >>> >>>> >>> >>>> >>> >>>> This doesn't seem appropriate to me. >>> >>>> >>> >>>> If people want to provide confidential comments, then they >>> >>>> shouldn't be supplied to the RSEA, >>> >>>> nor should the IED's weights. This is not a legal proceeding= , it's >>> >>>> a performance review, and >>> >>>> there's no generic reason that the RSEA should get to hear a= ll the >>> >>>> feedback that the LLC is >>> >>>> receiving. >>> >>>> >>> >>>> -Ekr >>> >>>> >>> >>>> >>> >> >>> >>> --=20 >>> Rfced-future mailing list >>> Rfced-future@iab.org >>> https://www.iab.org/mailman/listinfo/rfced-future >>> >> >=20 >=20 From nobody Sun Aug 1 17:24:33 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB2D23A0121 for ; Sun, 1 Aug 2021 17:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=TV+sW+4m; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=luX0PU1J 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 vnUU-3Y3_Xnj for ; Sun, 1 Aug 2021 17:24:26 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87EE93A011F for ; Sun, 1 Aug 2021 17:24:26 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 04E1B5C0079; Sun, 1 Aug 2021 20:24:25 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Sun, 01 Aug 2021 20:24:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=9 NqzcNoDgGzBsogoZg0ad8TGMQocm5ODCZuGCdPkkPQ=; b=TV+sW+4m02oecZL7+ TzjcCVIDNmnM2FOprj6Vkuz7wmGbnY088EpFKmQvQT+oj+6dYpTdBaBZCfaGUDlQ oAxYCJjdWpZbYw6TwUEKqurZcKuQKcK6FBAqNn3wx28+syspaKn0dbxqGGM69Wqd iAw6X9sJPVz8qAaLtx2uHSwQB0a4GhC7BtQaJpSy4nYAZPtjEQjzT7rybxvEXz1R JNgE861nwYZTKmVb0f6e4UxfM30N8Q1hmXy9Moo16delXJpFjxyr4n80E6xiKFB9 49GnEnSgf0xFGUd0DFpb9eLV/qn8iNlU6z025B2IwRdfFs2UbASxHKZFheZHR8ix 7zwjQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=9NqzcNoDgGzBsogoZg0ad8TGMQocm5ODCZuGCdPkk PQ=; b=luX0PU1JxpFhsMDg7u0vK/G8w2AdjDoRgH0FgYCvb481cKxVGDBwFYbt3 cTnsgl2cjmoXk8RcGdgTsTEzKndpJ/QqjUNoocW5hzgs16eHbIuMGUNQsLwS7k0i /hZMtMUYDz9mwmDTQ/Ie4XAdj43tQOzCMLPVkZVDNmzGyfp8/4so1/vvxgitBURC vyLA3KGf0+pIg03IIHvPS9O98VU+n8gSh/yHmbeNPGcUpiV1ewXwXfc04UDNIvBs O5/l++lWw6fAhifnzOH2ixqc2ulNqqhL4zO8YYSwWwHsoAlAu9Gc10b/lJ6XxdL8 aJYH5E9hzw5sjp9Fb9TscL+piyVOA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddriedugddukecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepuedtkefhtdfggfejjeegkeevheefhffguefgheefgfegkefhiedtgeduvedufeei necuffhomhgrihhnpehirggsrdhorhhgpdhmnhhothdrnhgvthenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 1 Aug 2021 20:24:20 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Mark Nottingham In-Reply-To: Date: Mon, 2 Aug 2021 10:24:18 +1000 Cc: Michael StJohns , Eric Rescorla , rfced-future@iab.org, "Joel M. Halpern" Content-Transfer-Encoding: quoted-printable Message-Id: References: <6b5f89e8-2d79-016b-65bb-39704c438e96@nthpermutation.com> <2739d8af-209a-6714-c21c-d723fbd941fd@joelhalpern.com> <59a3aeda-0a76-eed9-70ac-ad2739c15eb5@nthpermutation.com> <59fd0a3a-f0b2-d66b-ae6a-4909ba5a25d6@nthpermutation.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [Rfced-future] Replacement text for Section 4.2 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2021 00:24:32 -0000 I thought the current 4.2 has about the right amount of detail; it's = vague enough (e.g., 'periodically', 'criteria could include') to convey = the general lay of the land without constraining things too exactly. Cheers, > On 2 Aug 2021, at 9:38 am, Brian E Carpenter = wrote: >=20 > On 02-Aug-21 11:09, Michael StJohns wrote: >> So delete section 4.2 in its entirety? I'm good with that. >=20 > Really? I agree that it is not a good idea to specify too many = details; the LLC clearly owns the process, but stating that community = feedback is part of the process seems desirable. Something like: >=20 > Periodically, the IETF LLC will evaluate the performance of > the RSEA, including a call for confidential input from the > community. >=20 > Also the last sentence of the current text needs to be said somewhere: >=20 > Whether the RSEA role is structured as a contractual or employee > relationship is a matter for the IETF LLC and the IETF Executive > Director to determine. >=20 > Brian >=20 >>=20 >> Mike >>=20 >>=20 >> On 8/1/2021 6:14 PM, Eric Rescorla wrote: >>>=20 >>>=20 >>> On Sun, Aug 1, 2021 at 3:10 PM Michael StJohns = > wrote: >>>=20 >>> Strangely enough I'd be happy with omitting any requirement for = the LLC to accept comments from the community and that includes the = RSAB. But I grok, that is not what some people want, and if there is a = requirement for community feed back, then there needs to be a way of = ensuring=20 > that feedback goes through some form of fairness filter >>>=20 >>>=20 >>> The details of this seem like something that we could leave to the = LLC=20 > to decide. >>>=20 >>>=20 >>> and a way for the target of that feedback to rebut or provide = context for negative feedback. >>>=20 >>>=20 >>> This seems like something that might be good practice in many cases = and bad in some others, but in any case doesn't need to be encoded in an = RFC. >>>=20 >>> -Ekr >>>=20 >>>=20 >>>=20 >>>=20 >>> On 8/1/2021 5:53 PM, Eric Rescorla wrote: >>>> It might be useful to distinguish here between what we think is = good practice and what this RFC is going to require. >>>>=20 >>>> In general, the executive management of a company has a fair amount = of latitude in what kind of HR practices they want to employ (subject to = local law, of course) They can do 360 reviews or not, solicit peer = feedback or not, share it with the employee or not, etc. I would expect = the same=20 > here, with the LLC and the IED being responsible for making those = decisions. For us to put specific requirements about how that feedback = is collected and shared is a bit like writing that into the company = bylaws. Perhaps there is some point which is truly necessary to be = encoded in such a way that it constrains the LLC but none of this text = seems to me to fit that bill. >>>>=20 >>>> What I would prefer, therefore, is to omit essentially all of this = material. To the extent to which the community wishes to have input on = those processes, well, that's why the LLC board is answerable to the = community. And of course the RSWG can always write an RFC to add new = requirements=20 > if it deems it necessary in the future. >>>>=20 >>>> -Ekr >>>>=20 >>>>=20 >>>> On Sun, Aug 1, 2021 at 2:37 PM Michael StJohns = > wrote: >>>>=20 >>>> On 8/1/2021 5:11 PM, Joel M. Halpern wrote: >>>>> I am not following the bottom part of your note. >>>>>=20 >>>>> We are not a government agency, subject to government contracting >>>>> regulations. >>>>=20 >>>> I know that - but we are a non-profit corporation incorporated = within US >>>> and mostly subject to US labor laws and practices. All I'm = saying is >>>> that telling people that their comments will always remain = confidential >>>> may run up against the law which says that's not the case. >>>>=20 >>>>> As far as I know, the restrictions on a company for hiring and = firing >>>>> contractors is always more generous than for employees. The = closest I >>>>> have gotten in a review to knowing what the comments were from = other >>>>> people was when my boss at my first job out of school told me that = he >>>>> had received complaints (no idea of number, I did not get to see = the >>>>> complaints) that I typed too loudly. (I took this as a sign that = I >>>>> should work somewhere else.) >>>>=20 >>>> It a) depends on the contract - board members and C-suite staff >>>> contracts tend to have some pretty interesting poison pills as = do >>>> by-name contracts for people with rare skills, but the typical = employee >>>> is at-will and can be fired for any reason*, and b) it depends = on=20 > the >>>> country or state. *As long as those reasons don't implicate = a few >>>> fair labor laws and regulations such as age, gender, race, = national >>>> origin, political and religious beliefs, etc. >>>>=20 >>>> Re your comment - I took this that your boss had a sense of = humor=20 > and >>>> provided you with information that had no effect on your actual = review >>>> and compensation. The key thing here is that your boss knew=20 > who said >>>> what, and you were given an opportunity to hear the issue. >>>>=20 >>>>>=20 >>>>> I would expect that the LLC would want to get concerns discussed >>>>> (which is why I raised the question to see if others agreed that = an >>>>> aggregating question was acceptable. >>>>=20 >>>>=20 >>>>>=20 >>>>> Forwarding the actual responses (even somewhat redacted) seems = likely >>>>> to cause problems. Among other things, it seems likely to = discourage >>>>> negative feedback. >>>>=20 >>>> Contrariwise, not providing negative feedback to the RSEA is = unlikely to >>>> result in any improvements if they are warranted. And given=20 > this >>>> community, it's possible that the RSEA can provide missing = context on a >>>> prospectively negative comment to assist the LLC in deciding = what >>>> actions need to be taken. >>>>=20 >>>> And sorry - I'm not sure who gets to see the actual results in = your >>>> model. Can you tell me what each of RSAB, IED, LLC and the RSEA = see please? >>>>=20 >>>>=20 >>>>>=20 >>>>> Sure, a law suit can of course be filed in the US under almost any >>>>> circumstance. And can attempt to subpoena almost anything. But = that >>>>> does not justify over-sharing information during the normal = process. >>>>=20 >>>> I still hesitate to see how providing the RSEA a = summary/redaction of >>>> the comments received and allowing them to provide a response is >>>> "over-sharing". >>>>=20 >>>>=20 >>>> Later, Mike >>>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>> Yours, >>>>> Joel >>>>>=20 >>>>> On 8/1/2021 4:48 PM, Michael StJohns wrote: >>>>>> Let me break this down into two section: 1) What is the scope of >>>>>> confidentiality? 2) What does the RSEA get to see and comment on >>>>>> prior to it going to the LLC - if anything? >>>>>>=20 >>>>>> For confidentiality, I have these questions: >>>>>>=20 >>>>>> 1) Are truly anonymous comments permitted? >>>>>> 2) Does the IED get to see all of the comments with the source >>>>>> unredacted? >>>>>> 3) Does the RSAB get to see all of the comments? >>>>>> 3a) paraphrased? >>>>>> 3b) source unredacted? >>>>>> 3c) source redacted? >>>>>> 3c.1) With redactors comment on the source? >>>>>> 3c.2) Without comment >>>>>> 4) Does the LLC get to see all of the comments? >>>>>> 4a) paraphrased? >>>>>> 4b) source unredacted? >>>>>> 4c) source redacted? >>>>>> 4c.1) With redactors comment on the source >>>>>> 4c.2) Without comment on the source >>>>>>=20 >>>>>> I assume that if the IED gets to see all comments, they will act = as >>>>>> redactor for any further distribution if redaction is required. >>>>>>=20 >>>>>> In the draft I assumed that 1, 2), 3c.1), and 4c.1) were the = answers >>>>>> to the above questions because of the comments that were made by = the >>>>>> call about confidentiality. Obviously, if the LLC and the RSAB = get >>>>>> to see everything, there won't be a redaction and comment on the >>>>>> source necessary. If the LLC doesn't get to see everything, = then it >>>>>> at least needs the context of possible biases from the submitters = of >>>>>> the comments to help it understand the reality on the ground. >>>>>>=20 >>>>>> For the RSEA, I believe that it needs to be a bit more that Joel >>>>>> suggests below - and instead we should be making sure that any >>>>>> comment that will be considered by the LLC has to be provided to = the >>>>>> RSEA for feedback and rebuttal in at least a paraphrased form. I >>>>>> don't think the RSEA gets to know about any of the sources, but = it >>>>>> seems both unfair and legally fraught not to provide them with=20 > an >>>>>> opportunity to make an opposing case for any negative comments. >>>>>>=20 >>>>>> And I'm glad that EKR brought up "legal". Unlike the Nomcom = process >>>>>> there is/will be a financial relationship between the LLC and the >>>>>> RSEA in the form of either an employment agreement or contract. = In >>>>>> the event that the LLC moves to terminate that relationship, if = the >>>>>> RSEA feels it is being done for "unfair" reasons and can make a = case >>>>>> to a legal standard in the appropriate legal venue, _*each and=20 > every >>>>>> comment, and all emails and notes discussing those comments will = be >>>>>> subject to subpoena and the related depositions*_. >>>>>>=20 >>>>>> And lastly - no company I know of solicits company wide comments >>>>>> (unless the company is really tiny) on a particular employee's >>>>>> performance, nor does the manager not know who made the comment = and >>>>>> hence that manager can accurately weigh said comments. It would = be a >>>>>> truly bad manager that did not ask an employee about their take = on >>>>>> any negative comments the manager received and the manager = should >>>>>> help them redress any actual problems. >>>>>>=20 >>>>>> Mike >>>>>>=20 >>>>>>=20 >>>>>> ps - Martin - "derogatory" is a term of art, mostly used related = to >>>>>> credit worthiness, it differs from negative, in that the = derogatory >>>>>> info may affect the credit score, but there might be other = negative >>>>>> information that can't be taken into account due to legal issues >>>>>> (e.g. for this "the RSEA is too old for the job" would be a = negative >>>>>> comment, but not a derogatory one as age discrimination is = generally >>>>>> prohibited and the comment couldn't be considered and would need = to >>>>>> be discarded when received). Happy though to change to "negative = and >>>>>> positive" vice derogatory. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 7/29/2021 11:49 PM, Joel M. Halpern wrote: >>>>>>> I mostly agree with Ekr here. >>>>>>>=20 >>>>>>> The only edge case I see is one that I know has come up with >>>>>>> nomcoms. If nomcoms see a pattern of reports of an issue, they = have >>>>>>> been known to say to a candidate "there have been issues raised >>>>>>> about X. Do you have any comment on that?" This is not the = same >>>>>>> as showing the candidate the feedback, even sanitized. It does >>>>>>> reveal that information has been provided. (And, even more >>>>>>> importantly, ti does not give even a large portion of the >>>>>>> feedback.) The nomcoms where I know this came up concluded that = the >>>>>>> combination of seeing the candidates reaction and giving then=20 > a >>>>>>> chance to respond was worth pushing that envelop. =20 > Do we consider >>>>>>> that the selection committee or LLC or someone has that right=20 > under >>>>>>> this process already? Do we want to say anything about it? >>>>>>>=20 >>>>>>> Yours, >>>>>>> Joel >>>>>>>=20 >>>>>>> On 7/29/2021 11:34 PM, Eric Rescorla wrote: >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Thu, Jul 29, 2021 at 5:00 PM Michael StJohns >>>>>>>> = >> wrote: >>>>>>>>=20 >>>>>>>> Replacement for section 4.2: >>>>>>>>=20 >>>>>>>> <<< Set a schedule - could be omitted, but this = is a >>>>>>>> promise to >>>>>>>> the community >>>>>>>>=20 >>>>>>>> as well as a schedule for the IED/RSEA >>> >>>>>>>> No more often than semi-annually nor less often than >>>>>>>> bi-yearly, the >>>>>>>> IETF Executive Director will send out to the community = a >>>>>>>> call for >>>>>>>> input on the performance of the RSEA. >>>>>>>>=20 >>>>>>>> <<< Separate the IED's recommendation from the = feedback >>>>>>>> process - >>>>>>>>=20 >>>>>>>> there may not actually be an action that needs an = immediate >>>>>>>> recommendation >>> >>>>>>>>=20 >>>>>>>> <<<< the IED acts as the confidentiality mediator, >>>>>>>> anonymous and >>>>>>>> confidential >>>>>>>>=20 >>>>>>>> comments get tagged in the document that goes = to the >>>>>>>> LLC - >>>>>>>> this provides >>>>>>>>=20 >>>>>>>> needed context. >>>> >>>>>>>> The IETF Executive Director and the stream managers = will >>>>>>>> review the >>>>>>>> received feedback and produce a draft summary (a = paraphrase) >>>>>>>> including both positive and derogatory information. = Any >>>>>>>> feedback >>>>>>>> provided anonymously shall be tagged as such in the >>>>>>>> summary. Any >>>>>>>> feedback provided with a request for confidentiality = shall >>>>>>>> likewise >>>>>>>> be tagged in the=20 > summary and the IETF Executive Director MAY >>>>>>>> comment on the weight that may be appropriate to apply = to the >>>>>>>> comment based on=20 > their knowledge of the submitter. The stream >>>>>>>> managers should ensure that any of their concerns are >>>>>>>> added to the >>>>>>>> document at this=20 > point and MAY also provide any commentary >>>>>>>> on the >>>>>>>> externally provided feedback that they feel = appropriate. >>>>>>>>=20 >>>>>>>> <<< Make sure that the LLC hears both sides of the = coin >>> >>>>>>>> That draft feedback, redacted with respect to any = names >>>>>>>> associated >>>>>>>> with confidential comments and with respect to the = IED's >>>>>>>> weight >>>>>>>> evaluations, shall be provided to the RSEA with for >>>>>>>> comment or >>>>>>>> rebuttal, and such comments shall be incorporated as = an >>>>>>>> appendix to >>>>>>>> the final feedback document provided to the IETF LLC = Board. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> This doesn't seem appropriate to me. >>>>>>>>=20 >>>>>>>> If people want to provide confidential comments, then they >>>>>>>> shouldn't be supplied to the RSEA, >>>>>>>> nor should the IED's weights. This is not a legal proceeding, = it's >>>>>>>> a performance review, and >>>>>>>> there's no generic reason that the RSEA should get to hear all = the >>>>>>>> feedback that the LLC is >>>>>>>> receiving. >>>>>>>>=20 >>>>>>>> -Ekr >>>>>>>>=20 >>>>>>>>=20 >>>>>>=20 >>>>=20 >>>> --=20 >>>> Rfced-future mailing list >>>> Rfced-future@iab.org >>>> https://www.iab.org/mailman/listinfo/rfced-future = >>>>=20 >>>=20 >>=20 >>=20 >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future -- Mark Nottingham https://www.mnot.net/ From nobody Sun Aug 1 17:24:47 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23F213A0121 for ; Sun, 1 Aug 2021 17:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.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 ciBtMCpoipzb for ; Sun, 1 Aug 2021 17:24:42 -0700 (PDT) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 9030C3A011F for ; Sun, 1 Aug 2021 17:24:42 -0700 (PDT) Received: by mail-qk1-x72f.google.com with SMTP id k7so15125383qki.11 for ; Sun, 01 Aug 2021 17:24:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=opk15nDmgXUefwInSpvyervSR1aV1IR5dQpvgsulG30=; b=e6BX99XriEoVC9tEGCLNADIRpQdHeMUwCCCNP9a0lhly84GSFLzzfETPt8o61JhznV CfpgdxvApa2zyuTd+/PZboyBtBHz3AlTMGdd4oOW9fQfmZJI6XoAGBBAKTDCh8lh3Z6a PJMuNheSvyQ51Q2GZW09eLtyTX40cz+k8fBdisNiE//x/bbwypPkvlcIfsAXHV73p+ht qK0vXuBZDwKTjBUJwh+mhQvJ4bcAy+F+2+3ioYkNHx8ix6RIdDfuvVIshL0ND8KWuRQA JuXBuryqLFMqTROLcNe2hYE5F4XU0NiGwkTXc8aWliWBF3Ix5uS4eGVAHHez8Pw2NL+b RB7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=opk15nDmgXUefwInSpvyervSR1aV1IR5dQpvgsulG30=; b=LZnuavj8oeSXoN4cnDvBtDFabBNlVa+2ESeNcR1qKNFLu6pd572P8dKneejII3q9jw ITZXnHgVGomsMR8XNCGloqPIveQU5hg2Daix8gpgpK66uhkS2Szn1FZfowzoRLgj/QBY SWUVKYzJUpYvJzjBAkeKlHMAyRl+5x8k6KlvNYguEUwdPjgK0yD5C3OZ7Gx+nx2EP8fQ wVmIo/Qtj9fZUT9HbPekL4sb9FBqZzanyeR2jwx+x8cjEGdNPiovsrGF9b2x4XLGqkbj /aePk3y0JWhQFq4PJXnRgdEwQ/U5uF67ITUKaB/XIa5Mh95+LfCMTiGDYRxkQmkaX6Ce P3YA== X-Gm-Message-State: AOAM530gpnBJAt2eA34aypPh+sr8yyeau9AVx8wQPPBuEwpa47VqeFou 1Cfh2W5zBpWZi4/9cvDMxXjxpA== X-Google-Smtp-Source: ABdhPJyl+MhpYsiL4WUQPEB7xn3q22jDefI1XmH3+0buexOucjjLs5sT0dTaxo2eeI+wTyWpc08EUA== X-Received: by 2002:a05:620a:318b:: with SMTP id bi11mr13141572qkb.229.1627863880854; Sun, 01 Aug 2021 17:24:40 -0700 (PDT) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id m3sm4992748qkk.0.2021.08.01.17.24.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 01 Aug 2021 17:24:40 -0700 (PDT) To: Brian E Carpenter , Eric Rescorla Cc: rfced-future@iab.org, "Joel M. Halpern" References: <6b5f89e8-2d79-016b-65bb-39704c438e96@nthpermutation.com> <2739d8af-209a-6714-c21c-d723fbd941fd@joelhalpern.com> <59a3aeda-0a76-eed9-70ac-ad2739c15eb5@nthpermutation.com> <59fd0a3a-f0b2-d66b-ae6a-4909ba5a25d6@nthpermutation.com> From: Michael StJohns Message-ID: Date: Sun, 1 Aug 2021 20:24:39 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Replacement text for Section 4.2 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2021 00:24:45 -0000 On 8/1/2021 7:38 PM, Brian E Carpenter wrote: > On 02-Aug-21 11:09, Michael StJohns wrote: >> So delete section 4.2 in its entirety?  I'm good with that. > Really? I agree that it is not a good idea to specify too many details; the LLC clearly owns the process, but stating that community feedback is part of the process seems desirable. Something like: > > Periodically, the IETF LLC will evaluate the performance of > the RSEA, including a call for confidential input from the > community. Really.  We're going to inject a requirement that the LLC make a call for community input, that implies that the LLC will do that whether or not it makes contractual or HR sense to do and that the LLC is required to pay an undefined level of attention to any input from that process.  I'd rather leave the whole evaluation thing in the LLC's hands to decide whether and when it needs to make a community call, and for the candidates being hired or contracted to be able to negotiate the impact of such input.    So if you want to specify the requirement for "confidential input from the community", then it's only fair to specify how that input will impact the LLC's decisions and provide the appropriate safety valves to allow the RSEA to push back against and the LLC to ignore inappropriate or biased input. I'd rather leave this to the contracting process and for the LLC to do the right thing in conjunction with any HR and Legal help that they engage.  I expect they probably will ask for input, but it would be their choice to do so. Was there any language in Jay's contract or employment agreement requiring the LLC to ask for public comment on his performance? If not, I don't see any reason to do that here. > > Also the last sentence of the current text needs to be said somewhere: > > Whether the RSEA role is structured as a contractual or employee > relationship is a matter for the IETF LLC and the IETF Executive > Director to determine. Was there something similar in one of the documents when Heather was hired/contracted?  I forget.  I don't actually think its necessary as the LLC holds the money and hence the decision process on the engagement mode. Mike > > Brian > From nobody Sun Aug 1 21:23:42 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDAFE3A05A0 for ; Sun, 1 Aug 2021 21:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.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 sCDJGMlNumGJ for ; Sun, 1 Aug 2021 21:23:35 -0700 (PDT) Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-eopbgr1410112.outbound.protection.outlook.com [40.107.141.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B8E53A0597 for ; Sun, 1 Aug 2021 21:23:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZbOkBBSISiPY8Jgnj5qjxXWL7wMmfM9ecBy9f+ib6552XUV6nUWsFaE2VMZblpiiAOMlKJ4e4K323QXxbR7NfrJp29tsWO7KVZ3bS6GVDEgxJ5q8vKOocX40A3vTn0Xq3wIegNTBse1uTQd5pyLnU2jkip/YWqtwMmERAJRLRKy2lkS2dX5z7h8qIVzF/lW3Vqq4LDATV/JgrDZxO/W8a8Ns6aD5nLbnpQLvItLT9veTlQckItTlFSwtsy6Fw9U/qnkk7PM3QCYEBJVSuRpwUtqhN+tBv6PwxVfERGrqvJCtgeHqwGIu5POsCQaziHj2kBea0LpszH4+imbVnZXOtw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hn1jnWbV2amcPf2TiAg/c0xB2ipmfpc/mV3wdm1rTSk=; b=Cu9dUJviWxANoR2lN4+5PRGNz5OX6LrlHD/3bT39fSNw+6eQ8aECNcMrlmWG022H1T2lQbiF3IrmiCJ2SE7pt7UrzXvAXC/m1eCJHnQN2TeMqjIQKv/HBRSEN5ewsKlksUdUhgLFt4ESGPBPTwXtBNGTVqoqh3oS5HW8//cZk68UCzeEZbMkaq7H773R/BCDaG5OPMLJJ27d9E+ntmblav7mglRtgOKGbMW+niFdAXXSn4py96L5MUP5UTPlMIdy+++413lMppHe9ITtk6S/7K37sdhLpewvOqo1QJ00g9/hLd52ZDtDxx8n/djrgHbeNl220Xuiyw13RMRqXfJ10Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=it.aoyama.ac.jp; dmarc=pass action=none header.from=it.aoyama.ac.jp; dkim=pass header.d=it.aoyama.ac.jp; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector2-itaoyama-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hn1jnWbV2amcPf2TiAg/c0xB2ipmfpc/mV3wdm1rTSk=; b=EbB435ThR/BIE+I5U56juv2BWSoXLEuRV8gwDOcTVDUz1R2ZWTqTOagVnpzX8uSwUC+GNadFDZ3DOL/5iS4gG7wzGX0zN2kN2hHvYDmJaTh3uWndGas/QaLx0ohuuZstUmpTbowbTF2qS9mf3JRrPvHsz3HXUyxfk0JA/5GfIHk= Authentication-Results: iab.org; dkim=none (message not signed) header.d=none;iab.org; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) by TYCPR01MB7044.jpnprd01.prod.outlook.com (2603:1096:400:bf::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4373.18; Mon, 2 Aug 2021 04:23:31 +0000 Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::11f6:52bc:8bf7:d82b]) by TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::11f6:52bc:8bf7:d82b%6]) with mapi id 15.20.4373.026; Mon, 2 Aug 2021 04:23:31 +0000 To: Michael StJohns , "Joel M. Halpern" , Eric Rescorla Cc: rfced-future@iab.org References: <6b5f89e8-2d79-016b-65bb-39704c438e96@nthpermutation.com> <2739d8af-209a-6714-c21c-d723fbd941fd@joelhalpern.com> <59a3aeda-0a76-eed9-70ac-ad2739c15eb5@nthpermutation.com> From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <5d0763a9-6899-fdbb-8106-836ffec27212@it.aoyama.ac.jp> Date: Mon, 2 Aug 2021 13:23:28 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 In-Reply-To: <59a3aeda-0a76-eed9-70ac-ad2739c15eb5@nthpermutation.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-ClientProxiedBy: TYAPR01CA0238.jpnprd01.prod.outlook.com (2603:1096:404:11e::34) To TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [100.70.19.14] (133.2.0.94) by TYAPR01CA0238.jpnprd01.prod.outlook.com (2603:1096:404:11e::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4373.18 via Frontend Transport; Mon, 2 Aug 2021 04:23:31 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 4aaec800-9e6c-4afe-3aef-08d9556d4928 X-MS-TrafficTypeDiagnostic: TYCPR01MB7044: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Ky8CidRzidE6VS+SY6UFL03ThLS81iFnqatO6ytBFLN8dXPd4rRh3teYpBbIx8gzWtmUsLtlnWUkKs+rjhPrXQ5NtKuWUr02ZmIWiCXPc/HSI9igHLj0YduhzRQLEQ7l0Wl7amowvQUzimCj6joNt4grZha7q3tqmrbW/yD/SgfCrBUmaEfR9NV1E90A4nhq/GSHHk808StYuZYtzrVwBPDfsLHaOzZQ9pLhf5mY8XJPJYpTeIzRVeSzKV4TMjiVwwidGLl/5e4VTbjwe4Mx3J1KsV6Y9JzrM60pgTfcemob682aocOZGp90vlUr5SUCDvqa/8MsneIgf0JKBEcroEwOSnq+Yi7rNt4/UgJ6mPaoog52qvwib3nFJBpU12vaLVhATP6cIbnCMfOn/5fHLJMKCB80Z6F1w4LWQMsfsbgrZ9AxC6GNjfyeH+GMr0vH/EUhOdGF2dqeIkiB/F/RyNbyVqzPhNj/AqAWOMKelJI9bP0MShLiZRhk95X7OX7NqzO3eO4nknCQRLHnJsy1R1W3fGbY054Lsx5Sx/Tbaq8dgn3phwciQtz1XrhTHy34KGN1qnQ7BXse/alwr9HPhZJKFwGtS/C3RYw5SuoM0NUMAOjy9r26WYr58+8qbkzMzBSKeU3vwlNoxNQKrztgMOg26Fb0LD13//fHwE3MK8vuTu+iuiookgYrstpk+MTcWZ39R8IwXeZ4mjtUXAR1wv3RLmPXOLwm8MT1ObuuVFWNMllsADbP6S1pvdTJsMjXRCPaumKvHkrfxhVLY6tRSpXajFAAkBveAwjsOUCx2h2wTHwkCq5JcSqOMa34IfIQsPjTRF2H1qHkrll4PBfA0xrD2vbnRgF/PhVGuxr9dAdfiEbBH9r/mxO3K6Fu/ghf X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYAPR01MB5689.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(376002)(346002)(39840400004)(136003)(396003)(478600001)(83380400001)(66946007)(66476007)(66556008)(38350700002)(38100700002)(6666004)(2906002)(5660300002)(966005)(4326008)(31686004)(36916002)(86362001)(31696002)(8936002)(53546011)(16576012)(316002)(786003)(110136005)(956004)(2616005)(186003)(6486002)(26005)(52116002)(6706004)(8676002)(78286007)(43740500002)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?QWErd245V01XUjJlZEZwbVlZK2FyMlhXbFBVbzc4c0ZOKzNOcWdJUStrMXJm?= =?utf-8?B?V0wrQnhmREZYenpRL1o1eldnMlpPOCtxcjJFU3B0UUY1ZU9IYjJxZmtwd25z?= =?utf-8?B?cG9NUENqdUNSdEZkK3pmb0hkZDE2VWphcWtnanJTTVhyVU9ZL0xQeEhJR2ZP?= =?utf-8?B?cXZqYTBYUWZkaFdYRTFERVlrNjZQbWRkK1ovNGRpaU5LQkZkaElyTlJJNDRt?= =?utf-8?B?UkVUd0RLdGVXYUNwZ2tXMk9nSXBsdk9HTFZyY1pkZU50QVlDR2ZPRUxBclAr?= =?utf-8?B?UTVhOStyR0hKYTVmUUo5WHh2Q0FiSHV1N0hkL3ZhOCtFTStONnRRai9NSExZ?= =?utf-8?B?VWh3MkhTOGdWdmVnWXAwdWxPRnNQWVdzR2JqdWh6dXVuanNSTTdENDRMRTZq?= =?utf-8?B?ajd2LzBUbkFlTjBVbTBST1FacXFNbDB1cWdGYkw3S0RIWjNBNGxyeHcwWGNC?= =?utf-8?B?dTRLZmk1TGNFUzZUR01TejBTaCt5UHRDbS9ob2hLNDVZbVorNHBkMWI3NUxx?= =?utf-8?B?ZGhXVzlTZEJVTnpOeVpHYnloWW1QQlZiUGpjUmFMM1J5eDRYMnMxcHpHdldQ?= =?utf-8?B?bXVKck5aa2poQVVCZzF4Mit5VUh3TFZreDdaUGh0bHo1SmRONnRKWWVzTU1z?= =?utf-8?B?MmhPQU40eURwT1Ayc1paT3ptVTN0NFR3QmxhUEtYalpDSTc5RDlMNmg0Rm5G?= =?utf-8?B?Qi9ERmtRVkRyQWlXOXpFVHBMQ3NkeFExdUwwemk3czNxVHdGZ0VkYWFKUjYw?= =?utf-8?B?TmZIN0hzdVNDNHNDN1BGUVdCSEE4eWNrRkUvVzVKbVh0cHYwSHRjUmZlTEcw?= =?utf-8?B?NkNjSHdvdytNTWdmTEJGSG9aQncwbGY4UFFDLzhmQm9rMEk3Vlp5T0Vjck1W?= =?utf-8?B?QWNOamZSK1RMeTFOcnk1OEIzck01Y1dZZVRZWXg3V1cyZ0d3V1h1N05NWE05?= =?utf-8?B?LzBPQWtRTVFLbUo5eS9lYWpyakFTYmtrcnJkSEhnM243NjhtTm55bVJYYVd5?= =?utf-8?B?c0pqZm8yWE80NnNMSU41c0ZwNFRydXNkc2FTMGdTQjBwbkp1Y2xZem5GV28z?= =?utf-8?B?aTRERkZxZGVVVlFHSUdYNk5Td0g1RHoyM2k0a2ZzbTdFdmF5dEFGOU5mOERt?= =?utf-8?B?VWN1Q3pVeFVYZjRnTk94MkR6VXk0TFA5dHNMTFp0aVN5ejIyUG9Sem44QkZF?= =?utf-8?B?c09tNzhta1p0Um9ZcUtRRWpxdVMwMXoyQUFUQk03Q1JWRUp6akZCWmxwMnR2?= =?utf-8?B?SzhuU3k1RFM5MUlGR0o0bkFtQ3dzRW9tdnQwQUtwRGp5R1ArTGtSVlgxdXpI?= =?utf-8?B?dGIzQTFWUTJ2ZERPNFlXeEZsenpCb0FJVWRNYVpHZi8rMmJtd2tzWGZYUzdR?= =?utf-8?B?bmVYY0VJL3hCNFJ1WGhRUDZMV3huc0JTbzR6Yk4wRFBZSUIrdDk1MkNUUExu?= =?utf-8?B?c1hvbHJqMzFZWGRITUZETWZ0QkVZTEtpM0JXZkJMb2lWMjlDTUUvNUdodUtF?= =?utf-8?B?dTJkVS9Xa01UNFlTZmdoUFl1b3NLeU1JQmFqZVBJajhyenBmaHlMcDZXcXFa?= =?utf-8?B?SHFvSGV5QXBjY3Aranp4M1JWMzhTOEdBSS90cmMrMzJPcVhZTks3Qk9GWFhQ?= =?utf-8?B?U2hCc2lsVEZaUGtUWWNHbWdCOEQrNUlzenFsYzc3WDJiMnVRVzl5U3VUanpN?= =?utf-8?B?WjU0d1hLM0tpSWQrWlJjbWNBWEg4QlBXU2M0VmllTnE3SVpXSmtNNzl4ZG1j?= =?utf-8?Q?PXgBMPQsgk3PUMmIcVkXLAARBI0DLssvGG2LrVQ?= X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 4aaec800-9e6c-4afe-3aef-08d9556d4928 X-MS-Exchange-CrossTenant-AuthSource: TYAPR01MB5689.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Aug 2021 04:23:31.7970 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: e02030e7-4d45-463e-a968-0290e738c18e X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: qQ+npcIXZVh/WhupmiwOs2LRUedEM4TgrqJckJnc7N+C1a5m7kFndRF8GHPfkJeCstyzB/8eS8rE+zsiA9MOUg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYCPR01MB7044 Archived-At: Subject: Re: [Rfced-future] Replacement text for Section 4.2 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2021 04:23:40 -0000 Hello Mike, others, On 2021-08-02 05:48, Michael StJohns wrote: > ps - Martin - "derogatory" is a term of art, mostly used related to > credit worthiness,   it differs from negative, in that the derogatory > info may affect the credit score, but there might be other negative > information that can't be taken into account due to legal issues (e.g. > for this "the RSEA is too old for the job" would be a negative comment, > but not a derogatory one as age discrimination is generally prohibited > and the comment couldn't be considered and would need to be discarded > when received).   Happy though to change to "negative and positive" vice > derogatory. The problem here is that the dictionary meaning of "derogatory", which isn't just factually negative, but the equivalent of demeaning. (see https://www.merriam-webster.com/dictionary/derogatory) While that page also mentions the specific meaning in a credit report (which I didn't know about), I think that credit reports and personal evaluations are two different things, and we should not expect the average (engineer) reader to know the credit report meaning, nor to have to guess by themselves that it's the credit report meaning that applies in this (different) context if they happen to know that meaning. Regards,   Martin. From nobody Mon Aug 2 00:33:34 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3593A1143; Mon, 2 Aug 2021 00:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 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, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch 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 aseH-s1uEHxC; Mon, 2 Aug 2021 00:33:26 -0700 (PDT) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 306EA3A1140; Mon, 2 Aug 2021 00:33:25 -0700 (PDT) Received: from Lear-Air.local (31-10-155-187.cgn.dynamic.upc.ch [31.10.155.187]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 1727XLN8151915 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Mon, 2 Aug 2021 09:33:21 +0200 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1627889603; bh=ZyaR6n8+/SGbmNPSjhWmh5IJVDKjG7YK4RpYhSYXEt0=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=AhRLgGWfPqA3YCtVA1WKna7nt2/ukgkHldgZFYhJ+GHBYy0rkonds7ilc8UyKqSNx 8T2XCiPPxQaD38rpmcK83I0E7p6UR8laAJonYBqjeL62WZ8RddgY+8qsDfePe2oHQQ BJr2inI8EyBLdLd+aQXhKhFIORKk7ZZVudIEtOD4= To: Michael StJohns Cc: rfced-future@iab.org, Jay Daley References: <6b5f89e8-2d79-016b-65bb-39704c438e96@nthpermutation.com> <2739d8af-209a-6714-c21c-d723fbd941fd@joelhalpern.com> <59a3aeda-0a76-eed9-70ac-ad2739c15eb5@nthpermutation.com> <59fd0a3a-f0b2-d66b-ae6a-4909ba5a25d6@nthpermutation.com> From: Eliot Lear Message-ID: Date: Mon, 2 Aug 2021 09:33:20 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3xpbF1oW03s5516Jszq241zQBI0hwr9Tv" Archived-At: Subject: Re: [Rfced-future] Replacement text for Section 4.2 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2021 07:33:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3xpbF1oW03s5516Jszq241zQBI0hwr9Tv Content-Type: multipart/mixed; boundary="L9hbhrShJOJd5ZQmp2bvBR0oFQqwVi3Ib"; protected-headers="v1" From: Eliot Lear To: Michael StJohns Cc: rfced-future@iab.org, Jay Daley Message-ID: Subject: Re: [Rfced-future] Replacement text for Section 4.2 References: <6b5f89e8-2d79-016b-65bb-39704c438e96@nthpermutation.com> <2739d8af-209a-6714-c21c-d723fbd941fd@joelhalpern.com> <59a3aeda-0a76-eed9-70ac-ad2739c15eb5@nthpermutation.com> <59fd0a3a-f0b2-d66b-ae6a-4909ba5a25d6@nthpermutation.com> In-Reply-To: --L9hbhrShJOJd5ZQmp2bvBR0oFQqwVi3Ib Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Most of us having been in the position of having had anonymous feedback=20 submitted in our own NOMCOM evaluations, I think we can all sympathize=20 with Mike's concern about fairness (it's one reason that as a general=20 rule I do not provide anonymous feedback).=C2=A0 I'm especially concerned= =20 when people who have little to lose throw such darts. Notwithstanding that sympathy, I would be very concerned that REQUIRING=20 feedback to someone whose contract or employment is not going to be=20 continued might actually cause legal difficulties for the organization.=C2= =A0=20 What if the feedback turned out to be factually wrong?=C2=A0 What if it's= =20 debatable? What if the feedback was not the basis for not continuing the = relationship?=C2=A0 Worse, that requirement might tie the IED's hands in = terms of what employment mechanisms and jurisdictions are used. If we're going to pursue this line, I would want us to hear from the LLC = and the IED about any such risks. Eliot --L9hbhrShJOJd5ZQmp2bvBR0oFQqwVi3Ib-- --3xpbF1oW03s5516Jszq241zQBI0hwr9Tv Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmEHn8EFAwAAAAAACgkQh7ZrRtnSejMl Ggf/XWTy35tyucVnoF8/+rDYtbvpbBqRohlaymplkFC7GEggAuiC3O4tJsB3avT5r3RPlqUb7/qu aHmoWGvzXEJF4Aftv56jdD4w30BTsjLrJ4oeyj+CNnZctbudvSuvZVo48O5gyGxI1dquUptV5bdt YYGWCcZnhoetVCLjFqQA3rfsRPuLnxAL96qn2xDy1h8N2s3PnnLobmf93JhIzBrBSNUFGGUhCiEv B2+dCjbq9e7WiJSjDPF5F42Q4oUNKai5aKIJjJ3Xp2j+zqgRW6yoOJhgHOVskjYo8UW1sljKE+1g y9r/IQ1XKGMLBds6G/GZ/uNpjy8ceDc5nKobYx8J8Q== =Ai2J -----END PGP SIGNATURE----- --3xpbF1oW03s5516Jszq241zQBI0hwr9Tv-- From nobody Mon Aug 2 08:57:41 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 675913A07F3 for ; Mon, 2 Aug 2021 08:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 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, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch 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 0rOPmG2bQ-pq for ; Mon, 2 Aug 2021 08:57:32 -0700 (PDT) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A39EA3A083F for ; Mon, 2 Aug 2021 08:57:32 -0700 (PDT) Received: from [IPv6:2001:420:c0c0:1011::8] ([IPv6:2001:420:c0c0:1011:0:0:0:8]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 172FvTeN157550 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Mon, 2 Aug 2021 17:57:30 +0200 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1627919850; bh=xBW5JldsmmZv93u9xcmvr8CPRZCq6UmTmu9XqEAm/4Y=; h=To:From:Subject:Date:From; b=w2jkppXA2vatgkpp1GpVxr6h/qnh0Y6SQssqsgfE69aDa4glCt7feC9StTjTmN+Iq E176nbsKxtup0a/Jzhjkg17PCgLdN0TUQFD1YCWRSk/ViDiPjf/aub/9iN3ZcFsRp6 hbcA92gz6Cs0mz7I/XZqsSvqPVUwoqZGMbMP5oqc= To: "rfced-future@iab.org" From: Eliot Lear Message-ID: Date: Mon, 2 Aug 2021 17:57:26 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="x76bkxM1fBmQLWgMouqml5DHeWc2Kbpcn" Archived-At: Subject: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2021 15:57:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --x76bkxM1fBmQLWgMouqml5DHeWc2Kbpcn Content-Type: multipart/mixed; boundary="XwtAPTPhyKXpIKDj0pN8JYEnyrTm0knCO"; protected-headers="v1" From: Eliot Lear To: "rfced-future@iab.org" Message-ID: Subject: RSE, RSEA, RSCE, or Ruler Of The Universe? --XwtAPTPhyKXpIKDj0pN8JYEnyrTm0knCO Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi all, Thankfully we didn't take time to discuss the naming of the role in the=20 meeting, but I think we should try to complete this conversation.=C2=A0 I= t's=20 pretty clear that we would not gain consensus on RFC Series Advisor or=20 RFC Series Editor.=C2=A0 I believe someone offered RFC Series Consulting = Editor.=C2=A0 Is that something that would work for people? Eliot --XwtAPTPhyKXpIKDj0pN8JYEnyrTm0knCO-- --x76bkxM1fBmQLWgMouqml5DHeWc2Kbpcn Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmEIFeYFAwAAAAAACgkQh7ZrRtnSejNa Ngf/Vn8hhfPDlGf83c+f/KUzhOBDMhRqsgqjGN1DJx3ZWQcYDpIw/UATTGYDmZJY289adG7p2jm0 XkLXYG4d0X+iK5HDek7sv3N+lhpTN1HPlAs6njtvIXMXk/QXWgOoAk9je2BeL3KrP7bfIh8aU+sN eotef3AKjWIgKW1ZIv9jKI8agY5FlUKdQefAvMEigj7WWYwQm1Uau5LFo5wvHMLFEVPFt+nyajMA uNmhJHueEm8bcVoO4j3PXYt5TW59bY2RmB4wOoYMTQ9O0rZhc61+Pi5eDyKTjxtSC6w4i8LAcNR+ hldDoJG0nWTwXLdzcMXV/tDHOExyVWHQuTAvmm0SRA== =1A4A -----END PGP SIGNATURE----- --x76bkxM1fBmQLWgMouqml5DHeWc2Kbpcn-- From nobody Mon Aug 2 09:03:53 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DBF73A0A51 for ; Mon, 2 Aug 2021 09:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 tMSA9pPHjbQH for ; Mon, 2 Aug 2021 09:03:43 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52C953A08F6 for ; Mon, 2 Aug 2021 09:03:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 1F791300B10 for ; Mon, 2 Aug 2021 12:03:43 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id zKsktqfwZ2cS for ; Mon, 2 Aug 2021 12:03:41 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id D5E1E300A1C; Mon, 2 Aug 2021 12:03:40 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) From: Russ Housley In-Reply-To: Date: Mon, 2 Aug 2021 12:03:39 -0400 Cc: "rfced-future@iab.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Eliot Lear X-Mailer: Apple Mail (2.3445.104.21) Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2021 16:03:48 -0000 How about RFC Series Advisor and Advocate? > On Aug 2, 2021, at 11:57 AM, Eliot Lear wrote: >=20 > Signed PGP part > Hi all, >=20 > Thankfully we didn't take time to discuss the naming of the role in = the meeting, but I think we should try to complete this conversation. = It's pretty clear that we would not gain consensus on RFC Series Advisor = or RFC Series Editor. I believe someone offered RFC Series Consulting = Editor. Is that something that would work for people? >=20 > Eliot >=20 >=20 >=20 >=20 From nobody Mon Aug 2 11:24:09 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEEE43A1467 for ; Mon, 2 Aug 2021 11:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.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 4MmUsS1bLrNZ for ; Mon, 2 Aug 2021 11:24:05 -0700 (PDT) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (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 9A9AA3A1463 for ; Mon, 2 Aug 2021 11:24:05 -0700 (PDT) Received: by mail-qt1-x835.google.com with SMTP id m11so12276979qtx.7 for ; Mon, 02 Aug 2021 11:24:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=Va1fol76PEZWNJNOc1XgjW0LO6ESs0WjXxBdIq4Smh4=; b=QDQckL3kHsw1qdRQcKAM5npeGOYViyTdvWMcecgbkBsDr6mGA+b9MWuIGq4Eb7mAod vYXL+0NQ4TYUJFJ0vRWRSU7TLQyq3fs369e3cQPJNAKimk6DlcfmAtk4EK3do0VU4HO7 +NOxDYjgO3+PW/6qWSUqTdpYWCtD6A/SdnZy01/EohLYWbjHhp2GIjtRfnQ7A6Yf1r6E wTmpNzYs+HUY1u7S/+bUbpeLhGQXSix2jKNqvb4janY3JABFXQRSST4ROWfJsbLGbZGX nM37uODsuqy4ivqLdddtPz/nzHLEW9FNxKuvfvcksmAVOqTcxjtER/tow0wsxyFNVKZh u5fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=Va1fol76PEZWNJNOc1XgjW0LO6ESs0WjXxBdIq4Smh4=; b=tgLMvYJ2voUa3ovSrXzE33UnwAtv4Ttn7SWz4ayiSvLRpFXwREwZMRHcn1rIYJ1NtN SJSSVBn7LzrXR9kGufJhG0vaUfM8z77lKLPxd8Tj/S36eG8HkXCMbUbpD0oo6MMK50Qy Mop1jUXOa0Nc1GjKmvUC20l98xQ0D7GSEb78rhdGIYrwwoMIIwlvBqU+V8YGrSP6dUs0 S/eaZ+ureIj9rGxn/fDEuRp6eugSNX/g8aOUSoow4mly8yUgnlFBN41fKjpBdSpXvC+Y qs1rl5ARlMdBJJwPKzUZXJyu/nYCPTGiTo8/AMMwVZrvwahIJ7NbKDsoLgoJqna5teWI D8Ew== X-Gm-Message-State: AOAM531Xjp528pFypZtq1I56RQ8APpXYVrWf5PPdHtrIuqZyCLVmiRRB bPmCE8zA+r6kMsXbhe9MaER3dSGuujZ3mzXE X-Google-Smtp-Source: ABdhPJxQiyQcJn8NjST4l3cYFYd1e7SvFAGrQcHI4SELFd/UPfJN0neQfSw1Rm/ZA1Zhxp9hyG7Dzg== X-Received: by 2002:a05:622a:183:: with SMTP id s3mr14994988qtw.169.1627928643348; Mon, 02 Aug 2021 11:24:03 -0700 (PDT) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id z29sm6691360qkg.9.2021.08.02.11.24.02 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Aug 2021 11:24:02 -0700 (PDT) To: rfced-future@iab.org References: From: Michael StJohns Message-ID: Date: Mon, 2 Aug 2021 14:24:01 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------4379104705153C389656C636" Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2021 18:24:08 -0000 This is a multi-part message in MIME format. --------------4379104705153C389656C636 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 8/2/2021 11:57 AM, Eliot Lear wrote: > Hi all, > > Thankfully we didn't take time to discuss the naming of the role in > the meeting, but I think we should try to complete this conversation.  > It's pretty clear that we would not gain consensus on RFC Series > Advisor or RFC Series Editor.  I believe someone offered RFC Series > Consulting Editor.  Is that something that would work for people? > > Eliot > > > I think RSCE makes a lot of sense.   I can live with it. Mike --------------4379104705153C389656C636 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 8/2/2021 11:57 AM, Eliot Lear wrote:
Hi all,

Thankfully we didn't take time to discuss the naming of the role in the meeting, but I think we should try to complete this conversation.  It's pretty clear that we would not gain consensus on RFC Series Advisor or RFC Series Editor.  I believe someone offered RFC Series Consulting Editor.  Is that something that would work for people?

Eliot



I think RSCE makes a lot of sense.   I can live with it.

Mike


--------------4379104705153C389656C636-- From nobody Mon Aug 2 12:46:12 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF573A1922 for ; Mon, 2 Aug 2021 12:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 9r1QP5bLkkI7 for ; Mon, 2 Aug 2021 12:46:08 -0700 (PDT) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 9BE353A191F for ; Mon, 2 Aug 2021 12:46:08 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id f11so21614172ioj.3 for ; Mon, 02 Aug 2021 12:46:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=5/wfc4kDh8VsA981m9yRbIMDsiMePTlHM6z95x6x0yU=; b=fK5K2kvyguR+BW2OjLJIC814odC7vUC0Fylkt/2UqIIdWzv6R1DEr/XPNpkF3M/WPl cy+oQ5LBxuzEiUHTIVtrNHPGEL8dXdkVtMdUSp6cMsU+EfoVhVyRfpYTyLL8UJfHOIl5 XQ33EReWC1r0VdQneTT5A/jGg3ARPEpP2lIro= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=5/wfc4kDh8VsA981m9yRbIMDsiMePTlHM6z95x6x0yU=; b=R/wPASGaKYMD6WVLzoQ1MMHmuLMwcRcLzOHpZyCHfsX86+/jfb9cXlLSfWqocp53Dd 5/MBnEambfHfVLbkoQnSeUXAjwpYwTEb8aYCJIe4hxLYluw+0KqjSw4idbVNAthUXUM0 IJdxqEKANE3LtaI0JRlp7c6xl0RN3l+Z2GOsnmVf5KIM0Fbj083sPuqkZjpG2UMcciyM zwsZ+tI1o2Pz939ZKDXspJtBJXEy/xrngzxAu3xm2bFb+FFxiTnZFDZ8Z//vrgy4Ni/v 7q4JWpzj2ChSzFqHdLaz3XET7VPlLf5BIihaJ4qTF/GuxJFBS+sG+PH+1hbZYppmIbtz GOAg== X-Gm-Message-State: AOAM5309pxuElxzNfIRXfHXWPDp5HEwORfFhayKFj/LMoSsjN2WlGqRr rWDwGjqnwWZbd2kpuviZCtOjFg== X-Google-Smtp-Source: ABdhPJwXJYzGVjjWFzwtRuXYSNC1EaFDmBeGBeeG5CC5EAe8Ssglkxbhu0Kzaqvhzq9O7oa3y87L/w== X-Received: by 2002:a02:a40f:: with SMTP id c15mr4235603jal.38.1627933566064; Mon, 02 Aug 2021 12:46:06 -0700 (PDT) Received: from dragon.local (c-73-78-113-156.hsd1.co.comcast.net. [73.78.113.156]) by smtp.gmail.com with ESMTPSA id t11sm6185607ilp.66.2021.08.02.12.46.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Aug 2021 12:46:05 -0700 (PDT) To: Brian E Carpenter Cc: rfced-future@iab.org References: <6b5f89e8-2d79-016b-65bb-39704c438e96@nthpermutation.com> <2739d8af-209a-6714-c21c-d723fbd941fd@joelhalpern.com> <59a3aeda-0a76-eed9-70ac-ad2739c15eb5@nthpermutation.com> <59fd0a3a-f0b2-d66b-ae6a-4909ba5a25d6@nthpermutation.com> From: Peter Saint-Andre Message-ID: <7c7b6247-994a-9d05-bcd8-71cd92abe717@mozilla.com> Date: Mon, 2 Aug 2021 13:46:04 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Replacement text for Section 4.2 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2021 19:46:11 -0000 On 8/1/21 5:38 PM, Brian E Carpenter wrote: > On 02-Aug-21 11:09, Michael StJohns wrote: >> So delete section 4.2 in its entirety?  I'm good with that. > > Really? I agree that it is not a good idea to specify too many details; the LLC clearly owns the process, but stating that community feedback is part of the process seems desirable. Well, and also stating that the RSEA will be evaluated. > Something like: > > Periodically, the IETF LLC will evaluate the performance of > the RSEA, including a call for confidential input from the > community. Short and sweet. :-) > Also the last sentence of the current text needs to be said somewhere: > > Whether the RSEA role is structured as a contractual or employee > relationship is a matter for the IETF LLC and the IETF Executive > Director to determine. No matter what we do with §4.2, I suggest moving this text to §4. Peter From nobody Mon Aug 2 13:35:00 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5B4E3A1BFB for ; Mon, 2 Aug 2021 13:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 U-0bQ-ttmNe0 for ; Mon, 2 Aug 2021 13:34:44 -0700 (PDT) Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) (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 6D8C73A1BB3 for ; Mon, 2 Aug 2021 13:34:37 -0700 (PDT) Received: by mail-pj1-x102e.google.com with SMTP id l19so26878931pjz.0 for ; Mon, 02 Aug 2021 13:34:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=7XoT2oTfa0etuLD8hhchHw3HG6CfVLhkaNlvq+ocsE4=; b=Ow/WUhZlAXnAXAxsY1b0jORsUdM8S8cOA8MX2tWn9X4BpQNGYyCwzBOpp5bBXz76d1 mNejd5Lq1e7tkwRbcf7gyVz+ItvZx7TIGqGCVB6P08xu7SmMiUOwcxhDX67zDvl/P0QP X8q5UEX0rsaRFe/CMxgmqvjYhSNITJDfshTEIqggaiQKvD12gG0dyFQCoGviyZsSNlaW EMI65BGjrWHiMPOUH4TTT8fWIhOFgDgNBbputCbjX+uvZ1NmU+F4zXVRKmuhrdQuLiYZ ym924qixokII/cOhyTDV0CcmOlisG8iFGMJqzBm8M7KG3RUUmK5IXFXnFOHEDOv7KiU2 +fbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=7XoT2oTfa0etuLD8hhchHw3HG6CfVLhkaNlvq+ocsE4=; b=pHHcMm7QHbw+Ny9KCynNseI+ZiN4Sp2+O0lXSljOYwQ9vDsNvaVedTtO/7KMpT5bjY NzicFkKjyOWeM5WQk5aMWVudSbyirXVYjAwztmMg/9KWnKrz18M2Jucr2QXRwiq7fhKD 59Hwo8mJZYrwNkSLm51mYn4iDsCXxbu89DEMqq3BmUtOC9paPQY4CLYzT7GiIv3I1Ug+ HyWZYUeuirkXrE5FUU2OuOVBDebaAgIyqdmHJJXN68MC61C4qqpkh1XUuv26f1xnqYGP VfqGgx9j1zE6bZwfOSztwPUBnFWC8d8zzRA5xtaq4jZ45tEuefaloOJrbJqL4FB4gj4y ZnRQ== X-Gm-Message-State: AOAM532nU5zH9nNDFNvPXxyObIV9KZ453P4GiPOFv9Q1L1xPm6yYn2hm h9SYrK//68NwT+wy3Agl3Gg= X-Google-Smtp-Source: ABdhPJwlWG7r3QZiN577kA6ILUw65Ru8Yzkirm9r4i/hExAdytITX5KFLt1gLtZaEIEMeuC0JnyDOw== X-Received: by 2002:a17:902:c409:b029:12c:8d18:a03 with SMTP id k9-20020a170902c409b029012c8d180a03mr15676807plk.81.1627936475658; Mon, 02 Aug 2021 13:34:35 -0700 (PDT) Received: from ?IPv6:2601:647:5a00:659:4c53:1a47:ee67:2139? ([2601:647:5a00:659:4c53:1a47:ee67:2139]) by smtp.gmail.com with ESMTPSA id c12sm277239pjm.16.2021.08.02.13.34.34 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Aug 2021 13:34:35 -0700 (PDT) From: Bob Hinden Message-Id: <4002F5EB-8E45-4727-9A1A-CF35B6BE7312@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_57FAC1E7-8E08-4CD4-B014-B897D37821E7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) Date: Mon, 2 Aug 2021 13:34:33 -0700 In-Reply-To: Cc: Bob Hinden , rfced-future@iab.org To: Michael StJohns References: X-Mailer: Apple Mail (2.3445.104.21) Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2021 20:34:58 -0000 --Apple-Mail=_57FAC1E7-8E08-4CD4-B014-B897D37821E7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Aug 2, 2021, at 11:24 AM, Michael StJohns = wrote: >=20 > On 8/2/2021 11:57 AM, Eliot Lear wrote: >> Hi all, >>=20 >> Thankfully we didn't take time to discuss the naming of the role in = the meeting, but I think we should try to complete this conversation. = It's pretty clear that we would not gain consensus on RFC Series Advisor = or RFC Series Editor. I believe someone offered RFC Series Consulting = Editor. Is that something that would work for people? >>=20 >> Eliot >>=20 >>=20 >>=20 >=20 > I think RSCE makes a lot of sense. I can live with it. Likewise. Bob >=20 > Mike >=20 >=20 >=20 > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future --Apple-Mail=_57FAC1E7-8E08-4CD4-B014-B897D37821E7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAmEIVtkACgkQrut0EXfn u6jrVgf6AgVDldSTae9FRnvPqxfw76P1mTQWuYYvhde78tjzbKr/uq9rF8FthH41 EtecqQA2IUHa7ARSp4/sBdoM93AFdfgT6Atn4yB5Eh8pnhLyjzBfowSsrGhxehgR zYicYwMNtwiUn/zlXUNnM3GK86AMXJHR9b9vRiJJsLuxZMphd63ID5bvPIQRaHGa Dmx8tgpL8VoxVZlzjrkG31l4bIthMQYn9MiPpO1BWHwqjus1ai+T+Z9lvavkP0Xb RJWFbulxasVgDrP1n6GLfofoGTOywDBu7LdYTSxSBues8gfY3qHqtN0H9FdO6XBp FDrVRAMQWo4cisWX5K/A24ixa/7+Ww== =FExv -----END PGP SIGNATURE----- --Apple-Mail=_57FAC1E7-8E08-4CD4-B014-B897D37821E7-- From nobody Mon Aug 2 13:43:05 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD503A1BC7 for ; Mon, 2 Aug 2021 13:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 GfsBL2mvtkE4; Mon, 2 Aug 2021 13:42:58 -0700 (PDT) Received: from smtpclient.apple (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id 6E1103A1BC4; Mon, 2 Aug 2021 13:42:57 -0700 (PDT) From: Jay Daley Message-Id: <40B13AB2-C207-4632-BE6C-0A2A2A499181@ietf.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_9379FA28-1FD5-4010-93ED-D71B9DF40780" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Tue, 3 Aug 2021 08:42:54 +1200 In-Reply-To: <4002F5EB-8E45-4727-9A1A-CF35B6BE7312@gmail.com> Cc: Michael StJohns , rfced-future@iab.org To: Bob Hinden References: <4002F5EB-8E45-4727-9A1A-CF35B6BE7312@gmail.com> X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2021 20:43:03 -0000 --Apple-Mail=_9379FA28-1FD5-4010-93ED-D71B9DF40780 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 3/08/2021, at 8:34 AM, Bob Hinden wrote: >=20 >=20 >=20 >> On Aug 2, 2021, at 11:24 AM, Michael StJohns = wrote: >>=20 >> On 8/2/2021 11:57 AM, Eliot Lear wrote: >>> Hi all, >>>=20 >>> Thankfully we didn't take time to discuss the naming of the role in = the meeting, but I think we should try to complete this conversation. = It's pretty clear that we would not gain consensus on RFC Series Advisor = or RFC Series Editor. I believe someone offered RFC Series Consulting = Editor. Is that something that would work for people? >>>=20 >>> Eliot >>>=20 >>>=20 >>>=20 >>=20 >> I think RSCE makes a lot of sense. I can live with it. >=20 > Likewise. =46rom my "Does this title define the role well and thereby support a = successful recruitment process?" perspective, the answer is yes it does. Jay=20 >=20 > Bob >=20 >>=20 >> Mike >>=20 >>=20 >>=20 >> -- >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future = >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future = --=20 Jay Daley IETF Executive Director jay@ietf.org --Apple-Mail=_9379FA28-1FD5-4010-93ED-D71B9DF40780 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On 3/08/2021, at 8:34 AM, Bob Hinden <bob.hinden@gmail.com> wrote:



On Aug 2, 2021, at 11:24 AM, Michael = StJohns <msj@nthpermutation.com> wrote:

On 8/2/2021 11:57 AM, Eliot Lear wrote:
Hi all,

Thankfully we didn't take time to discuss the naming of the = role in the meeting, but I think we should try to complete this = conversation.  It's pretty clear that we would not gain consensus = on RFC Series Advisor or RFC Series Editor.  I believe someone = offered RFC Series Consulting Editor.  Is that something that would = work for people?

Eliot




I = think RSCE makes a lot of sense.   I can live with it.

Likewise.

=46rom my "Does this title define the role well = and thereby support a successful recruitment process?" perspective, the = answer is yes it does.

Jay 



Bob


Mike



--
Rfced-future mailing list
Rfced-future@iab.org
https://www.iab.org/mailman/listinfo/rfced-future

-- Rfced-future mailing = list
Rfced-future@iab.org
https://www.iab.org/mailman/listinfo/rfced-future

-- 
Jay Daley
IETF = Executive Director
jay@ietf.org

= --Apple-Mail=_9379FA28-1FD5-4010-93ED-D71B9DF40780-- From nobody Mon Aug 2 14:00:53 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6573A1C4D for ; Mon, 2 Aug 2021 14:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 oeq9Umwk7lV5 for ; Mon, 2 Aug 2021 14:00:46 -0700 (PDT) Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) (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 A8F213A1C4A for ; Mon, 2 Aug 2021 14:00:46 -0700 (PDT) Received: by mail-pj1-x1035.google.com with SMTP id s22-20020a17090a1c16b0290177caeba067so870840pjs.0 for ; Mon, 02 Aug 2021 14:00:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=XHeOGkLiJpdnCdQUhpJb8ElyfU2x8+xIgRjKDRmkKmE=; b=oOSMgp6Bp0l9OBlizp9bUY7zzB4TQ8YiDlShU8VlF4g3jwBwDDL/pem/N7Cy0kBK69 ryQuJvHyAxdPLvte5k8Npk6Lcqb9CKX+8GYyTDb8Zf1nGhoiHYYkCuCWxCsdb9lCMyRA Um+a7XjDyuT+jJ79jG95vJoYLZPxSSDpzb4nbG6xSJ3+TPrw7OC68pfj8EFfHj6ky8Yv EpN5FPfrtEFxwjuiGuu5/FLg1Ay8Y36tl47i/jXLS6jP08GfBNoTRzfHyjv6P682EBFs +2sfz3bvNNwfPgUgCULqrd1G2mtbZYqvhzbYysREJHvCmW115f14aKvw/RnUSF6H5vVE TcLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=XHeOGkLiJpdnCdQUhpJb8ElyfU2x8+xIgRjKDRmkKmE=; b=OoONoTBhKxNwkXVu/Q+6SJRxGeGCblyNcscRpQqTatkpUfi+dm4LE+sj7k3IusAQVz 7hjGa6G/no/yTPF7jEErJ9HiVzKCdrYcZdOJ+I+6EEjgWHrC4sKlYLZ+GmrYRlXY5je5 MqS/i52umBQkX2CgGjj4H7xO0cqGm2nDMv9tz2XP/0icSx94t7pGh05Wo01f4zg7QV7c Vl9cdmxzBTOcclBOuarLawcJAJGFJ4fN3TTKnkufkHNJWEcm/f+ghZg1l6sQH1E5E2j9 1ZUbLGHsyorBwpoY2JRiQipK3k5VBzfiGRM+9msjQkZYBMWs01xelup2E7JzKwx0sdo2 PE7g== X-Gm-Message-State: AOAM531HX07PD9UmjjyYcPGikMssyOMB6Mq8MefIhTPuzGB6jQnwrrfU RWZdLx69Jyo5umaLRUwHxtdMrd3E7z8ycA== X-Google-Smtp-Source: ABdhPJyFmfM0sOhk9muGdNuWRA415Xb8opaxlXJSDKdsMnTTsue8punQ+66gJiGAmW6YzPzuc0cAKg== X-Received: by 2002:a63:1926:: with SMTP id z38mr2881894pgl.451.1627938045293; Mon, 02 Aug 2021 14:00:45 -0700 (PDT) Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id o8sm11739976pjm.21.2021.08.02.14.00.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Aug 2021 14:00:43 -0700 (PDT) To: Bob Hinden , Michael StJohns Cc: rfced-future@iab.org References: <4002F5EB-8E45-4727-9A1A-CF35B6BE7312@gmail.com> From: Brian E Carpenter Message-ID: <572454c8-3d19-ae13-be45-75ee5a6cea62@gmail.com> Date: Tue, 3 Aug 2021 09:00:39 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <4002F5EB-8E45-4727-9A1A-CF35B6BE7312@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2021 21:00:52 -0000 On 03-Aug-21 08:34, Bob Hinden wrote: > > >> On Aug 2, 2021, at 11:24 AM, Michael StJohns wrote: >> >> On 8/2/2021 11:57 AM, Eliot Lear wrote: >>> Hi all, >>> >>> Thankfully we didn't take time to discuss the naming of the role in the meeting, but I think we should try to complete this conversation. It's pretty clear that we would not gain consensus on RFC Series Advisor or RFC Series Editor. I believe someone offered RFC Series Consulting Editor. Is that something that would work for people? >>> >>> Eliot >>> >>> >>> >> >> I think RSCE makes a lot of sense. I can live with it. > > Likewise. I concur (not surprising, since I suggested it). Brian From nobody Mon Aug 2 15:13:40 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5226D3A1EC7 for ; Mon, 2 Aug 2021 15:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=GMZWJBGC; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=vjmyIA0x 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 GL6bC1bJLDS9 for ; Mon, 2 Aug 2021 15:13:29 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E5843A1EC8 for ; Mon, 2 Aug 2021 15:13:29 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 8B6EB3200909 for ; Mon, 2 Aug 2021 18:13:27 -0400 (EDT) Received: from imap41 ([10.202.2.91]) by compute5.internal (MEProxy); Mon, 02 Aug 2021 18:13:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm2; bh=vQErD ApZok2KRxs1Us8DgBoV15hA34KbrOTSCKhOYAM=; b=GMZWJBGCHMRqWAtgqeZr7 63U4FcvHnLo/1fVL+wgmdqVocRcLunDsZqTIkFn2VMKl8EnsOFrOKtR+74H0OfKP 23j7Zgbn8x5ThYwXxtoGaDZcmJF7SHN2oZdFKlMFI2pzcQy4qW9P/dtESQVDN8vp b/2tdQl7h8g0YbvIasO+EKMw9GtcotAqlDljbgMdsTmMe5/Al8ojsHDU20lht4Ze n4rlAtuZ4yawqCKiScRJFVIQ8uIqTzwN9o5Y39j7QzzFTKo8xZ5pB40h82otwNU7 A4Gb1kAidoTZG1OUp0+8B8RZoFuq/g10OutmvhfSbzP1DPqMydE8tg45LveJcTHN A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=vQErDApZok2KRxs1Us8DgBoV15hA34KbrOTSCKhOY AM=; b=vjmyIA0xx7Al8b9oZVX8xNlxcqKsMCrC1fjyFGx+5X5dvupoY5nARhbcB ws8RybIGvQt3C53sVYWUj4R1lGBmawo+9yRLW4X//jLnALkdYZE6L+ubXQhpkpLg J5X+5yvayBG2TqOwDN8Rdptyj+yOH+7XSqO7tnQbi0CFWx9/axQUuJwwAUh7VDoR mONbJcM2VtiA3Ujy1b3+9Gm1IHOz09xgh1HN3WiHJZTSHghX28VJ6WEhHR31uIdZ gUbcbh2OlbIZMT3x2DrtSTZf+DKutkXTVbrdmChGfupmcAhud8+fY5wqV9S3bSdy /Le/7ibziCoI/62s9praLhyw3Kfdg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddriedvgdduheekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehl ohifvghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepgfejueduieffledtge elheejvdettdejudduhefggeefgfekgfeuieetgefftddtnecuvehluhhsthgvrhfuihii vgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnh gvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 560D33C0449; Mon, 2 Aug 2021 18:13:26 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-545-g7a4eea542e-fm-20210727.001-g7a4eea54 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 03 Aug 2021 08:13:05 +1000 From: "Martin Thomson" To: rfced-future@iab.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2021 22:13:34 -0000 On Tue, Aug 3, 2021, at 01:57, Eliot Lear wrote: > I believe someone offered RFC Series Consulting=20 > Editor.=C2=A0 Is that something that would work for people? WFM From nobody Mon Aug 2 15:42:06 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83F743A1FB4 for ; Mon, 2 Aug 2021 15:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 CS_SAvZAVPPb for ; Mon, 2 Aug 2021 15:42:00 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18D3E3A1FB2 for ; Mon, 2 Aug 2021 15:41:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4GdtKg4qWCz1nspL for ; Mon, 2 Aug 2021 15:41:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1627944119; bh=ayzaDhCEL63SoP2tzlU1t0LIHfWdW7ue+KkyTASQC2g=; h=Subject:To:References:From:Date:In-Reply-To:From; b=mJY52kL62N9oyHFj5UTNd2m6A6VQaEMqcVF8t6sU3UWrfbiO0mW5QRY/m1bFFL5x4 1QOt2Mz7iC5C9oXJY2j7Y4cPbREPDHWYtA4EMXb+PT2qheHjJtCuHlE0bHLcMuyikF GWOLjVmRVc0yj/K7qQsvjFtAGU0G7U5xJ9G9Ve4Y= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.23.64] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (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 mailb2.tigertech.net (Postfix) with ESMTPSA id 4GdtKg1Qq7z1nsZZ for ; Mon, 2 Aug 2021 15:41:59 -0700 (PDT) To: rfced-future@iab.org References: From: "Joel M. Halpern" Message-ID: <608f49c6-5e3e-637a-482d-15e48298beb9@joelhalpern.com> Date: Mon, 2 Aug 2021 18:41:57 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2021 22:42:05 -0000 I can live with this. (I am bad at naming, so my actually liking something is largely irrelevant.) Yours, Joel On 8/2/2021 6:13 PM, Martin Thomson wrote: > On Tue, Aug 3, 2021, at 01:57, Eliot Lear wrote: >> I believe someone offered RFC Series Consulting >> Editor.  Is that something that would work for people? > > WFM > From nobody Mon Aug 2 16:02:31 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C54DB3A204C for ; Mon, 2 Aug 2021 16:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HDRS_LCASE=0.1, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 fqpt1rnYDDyj for ; Mon, 2 Aug 2021 16:02:16 -0700 (PDT) Received: from bsa3.jck.com (static-65-175-133-136.nh.cpe.atlanticbb.net [65.175.133.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A05213A2047 for ; Mon, 2 Aug 2021 16:02:16 -0700 (PDT) Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1mAgsz-0000qG-E0; Mon, 02 Aug 2021 18:58:17 -0400 Date: Mon, 02 Aug 2021 18:57:57 -0400 From: John C Klensin To: Michael StJohns , Brian E Carpenter , Eric Rescorla cc: rfced-future@iab.org, "Joel M. Halpern" Message-ID: <3CAE5F5790D60E614C535A32@JcK-HP5> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Archived-At: Subject: Re: [Rfced-future] Replacement text for Section 4.2 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2021 23:02:30 -0000 FWIW, Mike's comments below (and at least some of those expressing agreement) are consistent with what I tried to say during the meeting: I'm concerned about handing too much over to the LLC because, in this case, the optimal way to run a company may not be the optimal way of overseeing / running the RFC Editor Function and because it can lead to things closely resembling the "just a contractor" disease that got us into this mess. There is also nothing in the job descriptions of either the LLC ExecDir or the LLC Board requiring sufficient expertise in publication matters to predict that they will be able to make educated decisions about the selection of an RSEA or even that they would have sufficient knowledge and expertise to be able to make a good choice a search firms to help. =20 However, if that is what we are doing -- either because others are more comfortable with the "put the LLC in charge" idea or because all other options are worse-- then let's try to minimize very detailed instructions and trust Jan and his successors to do their job(s). john --On Sunday, 01 August, 2021 20:24 -0400 Michael StJohns wrote: > On 8/1/2021 7:38 PM, Brian E Carpenter wrote: >> On 02-Aug-21 11:09, Michael StJohns wrote: >>> So delete section 4.2 in its entirety?=C2=A0 I'm good with = that. >> Really? I agree that it is not a good idea to specify too >> many details; the LLC clearly owns the process, but stating >> that community feedback is part of the process seems >> desirable. Something like: >>=20 >> Periodically, the IETF LLC will evaluate the performance >> of the RSEA, including a call for confidential input from >> the community. >=20 > Really.=C2=A0 We're going to inject a requirement that the LLC > make a call for community input, that implies that the LLC > will do that whether or not it makes contractual or HR sense > to do and that the LLC is required to pay an undefined level > of attention to any input from that process.=C2=A0 I'd rather > leave the whole evaluation thing in the LLC's hands to decide > whether and when it needs to make a community call, and for > the candidates being hired or contracted to be able to > negotiate the impact of such input.=C2=A0=C2=A0=C2=A0 So if = you want to > specify the requirement for "confidential input from the > community", then it's only fair to specify how that input will > impact the LLC's decisions and provide the appropriate safety > valves to allow the RSEA to push back against and the LLC to > ignore inappropriate or biased input. >=20 > I'd rather leave this to the contracting process and for the > LLC to do the right thing in conjunction with any HR and Legal > help that they engage.=C2=A0 I expect they probably will ask = for > input, but it would be their choice to do so. >=20 > Was there any language in Jay's contract or employment > agreement requiring the LLC to ask for public comment on his > performance? If not, I don't see any reason to do that here. >=20 >>=20 >> Also the last sentence of the current text needs to be said >> somewhere: >>=20 >> Whether the RSEA role is structured as a contractual or >> employee relationship is a matter for the IETF LLC and >> the IETF Executive Director to determine. >=20 > Was there something similar in one of the documents when > Heather was hired/contracted?=C2=A0 I forget.=C2=A0 I don't = actually > think its necessary as the LLC holds the money and hence the > decision process on the engagement mode. >=20 > Mike >=20 >=20 >=20 >>=20 >> Brian From nobody Mon Aug 2 16:11:07 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 948933A2076 for ; Mon, 2 Aug 2021 16:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 bibIArm-QBXn for ; Mon, 2 Aug 2021 16:11:00 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB3D63A2074 for ; Mon, 2 Aug 2021 16:11:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4Gdtz83831z1nwhV; Mon, 2 Aug 2021 16:11:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1627945860; bh=iOEwsBnklezDKwm8TSXD2PCr3ZIXUz7N96fNvte/NJg=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=e0I0wPgGUPdD9d2UdyDLfd27Rbu8Xc5GnEefF8iR7QLQULEO8MBi6BBjTCJMB3Hl0 rsN+VOOu1haoaiNYbeo8lwDSpHtkFDUUDjjq4yWCbY7w9eTIGavfUpNtRP9qdfcOz9 QYtN21CkxE29zzbfImaAan7GnqDQ8PYaYHIM2ZzY= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.23.64] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (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 mailb2.tigertech.net (Postfix) with ESMTPSA id 4Gdtz763sXz1ntSQ; Mon, 2 Aug 2021 16:10:59 -0700 (PDT) To: John C Klensin Cc: rfced-future@iab.org, "Joel M. Halpern" References: <3CAE5F5790D60E614C535A32@JcK-HP5> From: "Joel M. Halpern" Message-ID: Date: Mon, 2 Aug 2021 19:10:58 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <3CAE5F5790D60E614C535A32@JcK-HP5> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Replacement text for Section 4.2 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2021 23:11:07 -0000 I read the text as being aimed at providing appropriate guardrails (mandating what we consider necessary) while trusting the LLC / IAD to execute reasonably well. For example, if we do not tell them they need to consult the community, then a complaint to the nomcom that they did not consult the community is not very strong. If we require it, then the complaint is saying something. Yours, joel On 8/2/2021 6:57 PM, John C Klensin wrote: > FWIW, Mike's comments below (and at least some of those > expressing agreement) are consistent with what I tried to say > during the meeting: > > I'm concerned about handing too much over to the LLC because, in > this case, the optimal way to run a company may not be the > optimal way of overseeing / running the RFC Editor Function and > because it can lead to things closely resembling the "just a > contractor" disease that got us into this mess. There is also > nothing in the job descriptions of either the LLC ExecDir or the > LLC Board requiring sufficient expertise in publication matters > to predict that they will be able to make educated decisions > about the selection of an RSEA or even that they would have > sufficient knowledge and expertise to be able to make a good > choice a search firms to help. > > However, if that is what we are doing -- either because others > are more comfortable with the "put the LLC in charge" idea or > because all other options are worse-- then let's try to minimize > very detailed instructions and trust Jan and his successors to > do their job(s). > > john > > > --On Sunday, 01 August, 2021 20:24 -0400 Michael StJohns > wrote: > >> On 8/1/2021 7:38 PM, Brian E Carpenter wrote: >>> On 02-Aug-21 11:09, Michael StJohns wrote: >>>> So delete section 4.2 in its entirety?  I'm good with that. >>> Really? I agree that it is not a good idea to specify too >>> many details; the LLC clearly owns the process, but stating >>> that community feedback is part of the process seems >>> desirable. Something like: >>> >>> Periodically, the IETF LLC will evaluate the performance >>> of the RSEA, including a call for confidential input from >>> the community. >> >> Really.  We're going to inject a requirement that the LLC >> make a call for community input, that implies that the LLC >> will do that whether or not it makes contractual or HR sense >> to do and that the LLC is required to pay an undefined level >> of attention to any input from that process.  I'd rather >> leave the whole evaluation thing in the LLC's hands to decide >> whether and when it needs to make a community call, and for >> the candidates being hired or contracted to be able to >> negotiate the impact of such input.    So if you want to >> specify the requirement for "confidential input from the >> community", then it's only fair to specify how that input will >> impact the LLC's decisions and provide the appropriate safety >> valves to allow the RSEA to push back against and the LLC to >> ignore inappropriate or biased input. >> >> I'd rather leave this to the contracting process and for the >> LLC to do the right thing in conjunction with any HR and Legal >> help that they engage.  I expect they probably will ask for >> input, but it would be their choice to do so. >> >> Was there any language in Jay's contract or employment >> agreement requiring the LLC to ask for public comment on his >> performance? If not, I don't see any reason to do that here. >> >>> >>> Also the last sentence of the current text needs to be said >>> somewhere: >>> >>> Whether the RSEA role is structured as a contractual or >>> employee relationship is a matter for the IETF LLC and >>> the IETF Executive Director to determine. >> >> Was there something similar in one of the documents when >> Heather was hired/contracted?  I forget.  I don't actually >> think its necessary as the LLC holds the money and hence the >> decision process on the engagement mode. >> >> Mike >> >> >> >>> >>> Brian > > > > > From nobody Mon Aug 2 19:09:07 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E59C73A0A0B for ; Mon, 2 Aug 2021 19:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 yAECbSNF6C63 for ; Mon, 2 Aug 2021 19:09:01 -0700 (PDT) Received: from bsa3.jck.com (static-65-175-133-136.nh.cpe.atlanticbb.net [65.175.133.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 889443A0A09 for ; Mon, 2 Aug 2021 19:09:01 -0700 (PDT) Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1mAjqj-0001AC-EL; Mon, 02 Aug 2021 22:08:09 -0400 Date: Mon, 02 Aug 2021 22:07:49 -0400 From: John C Klensin To: "Joel M. Halpern" cc: rfced-future@iab.org Message-ID: <59CA5FEFFE26D92DDA3AE545@JcK-HP5> In-Reply-To: References: <3CAE5F5790D60E614C535A32@JcK-HP5> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Archived-At: Subject: Re: [Rfced-future] Replacement text for Section 4.2 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2021 02:09:06 -0000 --On Monday, 02 August, 2021 19:10 -0400 "Joel M. Halpern" wrote: > I read the text as being aimed at providing appropriate > guardrails (mandating what we consider necessary) while > trusting the LLC / IAD to execute reasonably well. > > For example, if we do not tell them they need to consult the > community, then a complaint to the nomcom that they did not > consult the community is not very strong. If we require it, > then the complaint is saying something. Joel, Given that we are going down that path, I have no problem with "consult the community" and, for the reason you give, think it is probably a good idea. Where I start having a problem is with getting into details about what "consult" means, how they are to consult, what various people tell each other and how things are reported, etc., etc. john From nobody Mon Aug 2 19:24:41 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1C903A0AE4 for ; Mon, 2 Aug 2021 19:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 OzGyh7FvWzw1 for ; Mon, 2 Aug 2021 19:24:35 -0700 (PDT) Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) (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 4564F3A0A35 for ; Mon, 2 Aug 2021 19:24:35 -0700 (PDT) Received: by mail-pl1-x629.google.com with SMTP id e5so21892751pld.6 for ; Mon, 02 Aug 2021 19:24:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=ySVu08/PA5mGuE44zQq+rqVmP1meSflkvtHmdga1Z9U=; b=ZUQgadCLHL04JGw+SSRmUySYWgqvAs76L4hPEjz0Y2SMO45xhfIdOC1+VI4dPAae0q pUR6j3Q0hlSEaUyOj/rigkS32yK8WurYnKGw10bbGFdlLji1ysVmJkCukR2jIyOS3As5 0CtosnAal59/fMjMNZ4bQ8IvrsxFZq1Ya175pzCeMMN79a/tfaqXOhxXZGM45qmaO+X9 nVVk/1srQnFjRG5iIYiED5uvVu+juth1EXeq8/1IEe18izuoPhVXJdGoEUD0BAiA1r+7 nN1RcxOE1pDK9vUbigZB8QQCPEtokpOghzT1zXsSx49mCibZ66Eg8vXmyV7VaFcx4LlC rjng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ySVu08/PA5mGuE44zQq+rqVmP1meSflkvtHmdga1Z9U=; b=BvrQAyWXNYntJ+CM/uLV4Gb1h6wVVVXigiU7fElWuFp3wNfz4pvoVIMXokp8gISVHn k/B29uKQIzumXlV+O3wDiUgdq28z4jtdnFaRaJKGBq4cI4ZZMd31qVspTjADAvg4shLc ByVJGZyv8FsL7IqcKXYyDmrz8B0ZRw2ba1Sfsrzys+g2OzJ4vt+yQO1bKHnxtfvWDl+v QH/5+8cSuQYw5Lpn4E8MIAjcjPmH3mJ6/Ih0vv7U7KwlcbTiW6zXD4L1vezYfKUy0TBE mIJvOJlM+oo1CkyaoY/dQhdVnXNXTY4tI91o/KJjPcyqVQ4No2+tO7zl29mJ3I4i53y0 F5fA== X-Gm-Message-State: AOAM532aqn4lpqUYpiX10rKeVurrm/nQFjIIO8hEG0x8QUAE+pC4P57R Q2JSCJJVuTHQnADhwbaBxZlszEb1PuMEYQ== X-Google-Smtp-Source: ABdhPJx1oHHa6LGLzx51+XpDTz1aA2VWsPfPdnF8GmA6azrbUHO5vPW+sVXt37dAJW0A2sE50cec8g== X-Received: by 2002:a63:3c5d:: with SMTP id i29mr76890pgn.147.1627957473071; Mon, 02 Aug 2021 19:24:33 -0700 (PDT) Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id n20sm6270599pfv.212.2021.08.02.19.24.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Aug 2021 19:24:32 -0700 (PDT) To: John C Klensin , "Joel M. Halpern" Cc: rfced-future@iab.org References: <3CAE5F5790D60E614C535A32@JcK-HP5> <59CA5FEFFE26D92DDA3AE545@JcK-HP5> From: Brian E Carpenter Message-ID: <9b42615f-ede4-2db1-a1d4-dbc42c13498a@gmail.com> Date: Tue, 3 Aug 2021 14:24:27 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <59CA5FEFFE26D92DDA3AE545@JcK-HP5> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Replacement text for Section 4.2 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2021 02:24:40 -0000 On 03-Aug-21 14:07, John C Klensin wrote: > > > --On Monday, 02 August, 2021 19:10 -0400 "Joel M. Halpern" > wrote: > >> I read the text as being aimed at providing appropriate >> guardrails (mandating what we consider necessary) while >> trusting the LLC / IAD to execute reasonably well. >> >> For example, if we do not tell them they need to consult the >> community, then a complaint to the nomcom that they did not >> consult the community is not very strong. If we require it, >> then the complaint is saying something. > > Joel, > > Given that we are going down that path, I have no problem with > "consult the community" and, for the reason you give, think it > is probably a good idea. Where I start having a problem is with > getting into details about what "consult" means, how they are to > consult, what various people tell each other and how things are > reported, etc., etc. Exactly why I suggested a single sentence version instead of the two or three paragraphs in the current draft. Brian From nobody Mon Aug 2 19:42:58 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B009C3A0BC1 for ; Mon, 2 Aug 2021 19:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.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 tudRREOCT2Gw for ; Mon, 2 Aug 2021 19:42:52 -0700 (PDT) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 04C463A0BBC for ; Mon, 2 Aug 2021 19:42:51 -0700 (PDT) Received: by mail-qk1-x72b.google.com with SMTP id t66so18707632qkb.0 for ; Mon, 02 Aug 2021 19:42:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=JRRDb2BmXXlLq7245/znQpJJ/AxdnH+30lXF6wS0FKA=; b=YEzby2OJ2e4v7dG13nCq9bGPIO3N3QV8Kx3v0VabOPgLwZBdEh0DrbbMNTA6dI6AlL 0wejY39tGdxCXu+33w4Wy5CuXMkU6eaWgmIuqsAf93FfXXeOKYbGJGQ6GKvyB+GuKxKL UwSeewVWjDMfKfwnsjW842twgSzT0we07AfB+I82kdlus9jxJ5/+hj9fcMP6+NGgp9Zb follMPkvMIMBXujUt77E1wIzDhLZ4mX1/lcGMKTbXGKl/Hx0etZ2UUrQG2qYtp/Sh+le kFa30bBD+7VFhxCKyktTtRCrzkfvVZJqfyP/zrjt7o78bWT6ocWCk9woAo7HPe2iWQtM oAdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=JRRDb2BmXXlLq7245/znQpJJ/AxdnH+30lXF6wS0FKA=; b=OPbFtr9iYhr2E4Xz6O8FjFZwUvGh82iFMBpqpZ1DYxYBRuM3ipjQYKrq3qdt3rtk0b P6OZLJwinBjmMdYU2FphV67Bj6TgIsGP8q0PJmQQuJP34bpL4kShg+owZLKnV4GwFCcr CYuBRNud2jPYH2W20Iwq63luG/FLHhwUoR7NenBP02lhm1wa1e5mEmy5HrtlRo10JG0/ wQurZU9XB1tbJRADRuyA3DaQ3+lULJjIALy4lBH+WY4M2aQ5xnnAzUJFRmIHHNhn6279 dszNhcEPuoPWHSiyDiBE3TkQOwlpy5//ArpCPOlzA+bVKaxRkzoFuSsvIiC7WTi0skLp XUXQ== X-Gm-Message-State: AOAM531Eq0nYTzuUczhZkXzOvXkeJHEIDFJ2XhcshWYbYmNQvGhLs6Sf AvyU5raHkMUJOwFMK2SexJ9xScQ6UbKeyZVO X-Google-Smtp-Source: ABdhPJy1Phe6f8e0RcsKEc63K9wc0QMCY//VTEZmf2w7Ys54dqP5ITrmsCt7T8PvO6V29p/sR7YBCg== X-Received: by 2002:a37:e10c:: with SMTP id c12mr18552483qkm.333.1627958569620; Mon, 02 Aug 2021 19:42:49 -0700 (PDT) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id f62sm7029838qke.135.2021.08.02.19.42.48 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Aug 2021 19:42:48 -0700 (PDT) To: rfced-future@iab.org References: <3CAE5F5790D60E614C535A32@JcK-HP5> <59CA5FEFFE26D92DDA3AE545@JcK-HP5> <9b42615f-ede4-2db1-a1d4-dbc42c13498a@gmail.com> From: Michael StJohns Message-ID: <6090c77c-4da0-5a00-4a4c-f2f2bfc08565@nthpermutation.com> Date: Mon, 2 Aug 2021 22:42:48 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <9b42615f-ede4-2db1-a1d4-dbc42c13498a@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Replacement text for Section 4.2 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2021 02:42:57 -0000 >      Periodically, the IETF LLC will evaluate the performance >      of the RSEA, including a call for confidential input from >      the community. *sigh* I can see where this is going, so I'm grudgingly willing to accept the above with the deletion of the word "confidential".  Leave it to the LLC to specify the form in which it is willing to accept comments when it issues such calls - that's in keeping with Eliot's commentary on legal/HR issues. Or alternately, "Periodically, the IETF LLC should make a call  to the community for comments on the performance of the RSCE and RPC and for any suggestions for the improvement of the RFC publication system." Basically, any contract or employment agreement will have some form of periodic evaluation - we don't need to state that here it's really the sole responsibility of the engaging entity. Later, Mike On 8/2/2021 10:24 PM, Brian E Carpenter wrote: > On 03-Aug-21 14:07, John C Klensin wrote: >> >> --On Monday, 02 August, 2021 19:10 -0400 "Joel M. Halpern" >> wrote: >> >>> I read the text as being aimed at providing appropriate >>> guardrails (mandating what we consider necessary) while >>> trusting the LLC / IAD to execute reasonably well. >>> >>> For example, if we do not tell them they need to consult the >>> community, then a complaint to the nomcom that they did not >>> consult the community is not very strong. If we require it, >>> then the complaint is saying something. >> Joel, >> >> Given that we are going down that path, I have no problem with >> "consult the community" and, for the reason you give, think it >> is probably a good idea. Where I start having a problem is with >> getting into details about what "consult" means, how they are to >> consult, what various people tell each other and how things are >> reported, etc., etc. > Exactly why I suggested a single sentence version instead of the > two or three paragraphs in the current draft. > > Brian > From nobody Mon Aug 2 19:50:35 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE1A3A0C22 for ; Mon, 2 Aug 2021 19:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.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 vNc_DUpjwFPB for ; Mon, 2 Aug 2021 19:50:32 -0700 (PDT) Received: from mail-qv1-xf2d.google.com (mail-qv1-xf2d.google.com [IPv6:2607:f8b0:4864:20::f2d]) (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 EA27D3A0C20 for ; Mon, 2 Aug 2021 19:50:31 -0700 (PDT) Received: by mail-qv1-xf2d.google.com with SMTP id s11so9950752qvz.7 for ; Mon, 02 Aug 2021 19:50:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=bDOS6lpP0TCzttiX29wqdJ4Ek2MAw5i+C3iEMkevVDk=; b=Dn6pyprFe1JPJmVYbmjPFwCfSR5JyzVGPmC/haR0pJGYLgBYAmNDt/0uAvYTSA9RT2 Qnt/WmWsI85cvN6KkrhFmg2c4CEdiKg32t+RiFcG0Na+LvX32IRDJhsVlPkrliGBK1pX FrDWMkNTT9KnZRlMFWLsiy4AWoEUUyIVkRLDOQcuV6Pf/j+X+TkiwKq2ET5ZO1Bef1wD w8UodlAt4OdxAUHrjNAS/Ruk+sLw+4UTlKmLnuZaHyerVUPoNUzI/0SFlQ/i9DrCedOB QbRwy81NK8VpHKq0EEaw8q6zMJ2sDscmfxOGrd6P6IAjfgxKwfXZoA8ztY9lB9L/L0St sdzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=bDOS6lpP0TCzttiX29wqdJ4Ek2MAw5i+C3iEMkevVDk=; b=DsawUgta8Gc/WqcakREnlz1aRwa5A/JgB+AtZyvx8TlQrj79mlFweFXDMz3lOiGtHu NSHJyaLzb/2G6hVIhFCzHr4TF9/mNX/WPXJd4Cqmmi6nB+OFSgMGGT9DrgCQ6RjCvg+x wFeSnNN7stnoaFUHOxk4AjZSRy4fAWbbY6/bYmZbiGBgeVIUFfMb0uGtyl/t7o2B8SSu TD3OQ3MDtzbouD5v6HlY1gBI1obFvi4ED61rBl5ghtbvffD4jJpwt8H804lfRhxgiJaC sTxYVDs6qGXVMDFlpG4Hn8BNdau76NUmL09QgdN/yHqqnPWsmqF/+Il6Mn4DY5Sr4VL3 tuFA== X-Gm-Message-State: AOAM532iSEKaf3A4fLOU6EZAH7EFU5eDvt4tXfh+4xbMwIng+HbPy1GH WxIvw9qeB/CnZJX8OKh8n+EuURg3igZW7Fwo X-Google-Smtp-Source: ABdhPJw0l+F0Z3SKK4jQXES/xITR4nKhoVxqRbjEBZfi1As23yZMckD3s6VeKUKwspwO8g3f/vFI9Q== X-Received: by 2002:a05:6214:18c7:: with SMTP id cy7mr19288702qvb.59.1627959029705; Mon, 02 Aug 2021 19:50:29 -0700 (PDT) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id i123sm7246251qkf.60.2021.08.02.19.50.28 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Aug 2021 19:50:29 -0700 (PDT) To: rfced-future@iab.org References: <3CAE5F5790D60E614C535A32@JcK-HP5> From: Michael StJohns Message-ID: <87b10815-1071-96fc-103b-1479e82eb15a@nthpermutation.com> Date: Mon, 2 Aug 2021 22:50:28 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Replacement text for Section 4.2 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2021 02:50:33 -0000 On 8/2/2021 7:10 PM, Joel M. Halpern wrote: > I read the text as being aimed at providing appropriate guardrails > (mandating what we consider necessary) while trusting the LLC / IAD to > execute reasonably well. > > For example, if we do not tell them they need to consult the > community, then a complaint to the nomcom that they did not consult > the community is not very strong.  If we require it, then the > complaint is saying something. > > Yours, > joel I'll repeat the same question I asked before to wit:  Is the LLC required to consult the community for the IED - e.g. is there a formal requirement written somewhere that the LLC will periodically ask "how is Jay doing"?  If not, then why should this be any different? I think your argument is too much of a strawman in any case. There are lots of reasons we might ding the LLC via the Nomcom - but personnel issues will not be (a useful) one of them as the actual personnel actions and who voted for what with respect to those actions will not be visible to the Nomcom. Later, Mike From nobody Mon Aug 2 20:04:34 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB89F3A0C5B for ; Mon, 2 Aug 2021 20:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 LjT2QTOXq6aH for ; Mon, 2 Aug 2021 20:04:28 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 566353A0C54 for ; Mon, 2 Aug 2021 20:04:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4Gf08W70rbz1nt1R; Mon, 2 Aug 2021 20:04:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1627959867; bh=86LWKgR5KrcivRO37jA83qf4AkjsPk1MyyZvk6u8z0Q=; h=Subject:To:References:From:Date:In-Reply-To:From; b=l1oc7PiifMNg27Jx29mmM7ZRG5twO3qCh6RGZx3e7E1imhyFrh95JsAWjIdpOyF1Z Oi/NFp7LB/Y8VwhhaCP/yG3Oh3P2eZ7a+zgzBK720pT6RhMQnAEOGf1sQ9R3VdJoeR jA08Nd21ocZ3vGiwHSpMSm8NXRNsOoWz4A83UQrI= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.23.64] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (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 mailb2.tigertech.net (Postfix) with ESMTPSA id 4Gf08W2BJxz1nsyx; Mon, 2 Aug 2021 20:04:27 -0700 (PDT) To: Michael StJohns , rfced-future@iab.org References: <3CAE5F5790D60E614C535A32@JcK-HP5> <87b10815-1071-96fc-103b-1479e82eb15a@nthpermutation.com> From: "Joel M. Halpern" Message-ID: <402b19b8-11b6-bbaf-a9c8-5584f5c8a134@joelhalpern.com> Date: Mon, 2 Aug 2021 23:04:25 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <87b10815-1071-96fc-103b-1479e82eb15a@nthpermutation.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Replacement text for Section 4.2 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2021 03:04:33 -0000 It seems to me that if we as a community expect the LLC to do something, we should tell them rather than expecting them to guess correctly waht we want. It can be short (Brian's proposal). But leaving it out because we assume they will do the right thing seems rather odd. Yours, Joel On 8/2/2021 10:50 PM, Michael StJohns wrote: > On 8/2/2021 7:10 PM, Joel M. Halpern wrote: >> I read the text as being aimed at providing appropriate guardrails >> (mandating what we consider necessary) while trusting the LLC / IAD to >> execute reasonably well. >> >> For example, if we do not tell them they need to consult the >> community, then a complaint to the nomcom that they did not consult >> the community is not very strong.  If we require it, then the >> complaint is saying something. >> >> Yours, >> joel > > > I'll repeat the same question I asked before to wit:  Is the LLC > required to consult the community for the IED - e.g. is there a formal > requirement written somewhere that the LLC will periodically ask "how is > Jay doing"?  If not, then why should this be any different? > > I think your argument is too much of a strawman in any case. There are > lots of reasons we might ding the LLC via the Nomcom - but personnel > issues will not be (a useful) one of them as the actual personnel > actions and who voted for what with respect to those actions will not be > visible to the Nomcom. > > Later, Mike > > From nobody Mon Aug 2 20:07:32 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BECC13A0CDF for ; Mon, 2 Aug 2021 20:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 Iw8QVpo5rfWy; Mon, 2 Aug 2021 20:07:25 -0700 (PDT) Received: from smtpclient.apple (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id 298413A0CDD; Mon, 2 Aug 2021 20:07:25 -0700 (PDT) From: Jay Daley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_091C5CB7-2143-4305-A776-4077DD239210" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Tue, 3 Aug 2021 15:07:22 +1200 In-Reply-To: <87b10815-1071-96fc-103b-1479e82eb15a@nthpermutation.com> Cc: rfced-future@iab.org To: Michael StJohns References: <3CAE5F5790D60E614C535A32@JcK-HP5> <87b10815-1071-96fc-103b-1479e82eb15a@nthpermutation.com> X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Rfced-future] Replacement text for Section 4.2 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2021 03:07:31 -0000 --Apple-Mail=_091C5CB7-2143-4305-A776-4077DD239210 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 3/08/2021, at 2:50 PM, Michael StJohns = wrote: >=20 > On 8/2/2021 7:10 PM, Joel M. Halpern wrote: >> I read the text as being aimed at providing appropriate guardrails = (mandating what we consider necessary) while trusting the LLC / IAD to = execute reasonably well. >>=20 >> For example, if we do not tell them they need to consult the = community, then a complaint to the nomcom that they did not consult the = community is not very strong. If we require it, then the complaint is = saying something. >>=20 >> Yours, >> joel >=20 >=20 > I'll repeat the same question I asked before to wit: Is the LLC = required to consult the community for the IED - e.g. is there a formal = requirement written somewhere that the LLC will periodically ask "how is = Jay doing"? If not, then why should this be any different? It=E2=80=99s not in my contract no. All it says is "The Employee agrees = to participate fully in any formal performance appraisal program that = shall be conducted by the company". =20 Jay >=20 > I think your argument is too much of a strawman in any case. There are = lots of reasons we might ding the LLC via the Nomcom - but personnel = issues will not be (a useful) one of them as the actual personnel = actions and who voted for what with respect to those actions will not be = visible to the Nomcom. >=20 > Later, Mike >=20 >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future --=20 Jay Daley IETF Executive Director jay@ietf.org --Apple-Mail=_091C5CB7-2143-4305-A776-4077DD239210 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 3/08/2021, at 2:50 PM, Michael StJohns <msj@nthpermutation.com> wrote:

On = 8/2/2021 7:10 PM, Joel M. Halpern wrote:
I read the text as being aimed at providing = appropriate guardrails (mandating what we consider necessary) while = trusting the LLC / IAD to execute reasonably well.

For example, if we do not tell them they need to consult the = community, then a complaint to the nomcom that they did not consult the = community is not very strong.  If we require it, then the complaint = is saying something.

Yours,
joel


I'll repeat the same question I asked before to wit:  Is = the LLC required to consult the community for the IED - e.g. is there a = formal requirement written somewhere that the LLC will periodically ask = "how is Jay doing"?  If not, then why should this be any = different?

It=E2=80=99s not in my contract no.  All it = says is "The Employee agrees to participate fully in any formal = performance appraisal program that shall be conducted by the company". =  

Jay


I think your argument is too much of a = strawman in any case. There are lots of reasons we might ding the LLC = via the Nomcom - but personnel issues will not be (a useful) one of them = as the actual personnel actions and who voted for what with respect to = those actions will not be visible to the Nomcom.

Later, Mike


-- =
Rfced-future mailing list
Rfced-future@iab.org
https://www.iab.org/mailman/listinfo/rfced-future

-- 
Jay Daley
IETF = Executive Director
jay@ietf.org

= --Apple-Mail=_091C5CB7-2143-4305-A776-4077DD239210-- From nobody Mon Aug 2 20:25:05 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB0DE3A0D8B for ; Mon, 2 Aug 2021 20:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 R9CfCRvBJ93T for ; Mon, 2 Aug 2021 20:25:00 -0700 (PDT) Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) (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 5D41A3A0D82 for ; Mon, 2 Aug 2021 20:25:00 -0700 (PDT) Received: by mail-pl1-x62c.google.com with SMTP id u2so13758294plg.10 for ; Mon, 02 Aug 2021 20:25:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=G/o7Deb3JXuU9yBFYJaVTUhIrS5l+eIcmMvnJeXpuiU=; b=JJaYeYaAl6eVr9l6NTcSVWSGpwbeuDEZR3mgQDW4ogcxUfiPbi8/rO4R4OmV4Zz4aU Oz5aNwzo7a2bz7zqxYXML/hQXAds/aurK+/3byE6tbrI6AfKr3kDh+baytRsfW4EbIBw hUR3Y2QXBE8KAcp7zLhzxRavWTqpIBY/94vXzOowbsEMzFZ429Te84q1lfACAwGjIAtW HABXqdMo0lD7pQWME6sWxX0reyNNIoKvks8apuaLJddJ5zfYCIIolpinDQTPfDjywcym Imx92jRtb7kJsOcWLOFNDBamyYDGmsngrrgGFy2TnzbiTnJdidTfWes1olvpzYgJ4SIH Rg4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=G/o7Deb3JXuU9yBFYJaVTUhIrS5l+eIcmMvnJeXpuiU=; b=Cw4g37T9HKLuyeK7MKsQ6MlEMLbvLKKF2NUocyoP+cDPKOMRXe/QdNHzN4l4ZpSYRn DRuoLOtadKEYWYoJQEG5oHHJ7lU1t2WbnuinFpbIUOTs3d6pBx62ijk69F0mCXYQM7Im aZ1YUh8Rhoc0JQwUzFFbltUdHijpgrx7U1uQPuYfJjK68VkHDIHd1ICUWZMVDrWfy6Tt 2QinhriRIQgEHHo7s+64NrWkIAgvp8NhtYLhLe0VIgpVcmDeSGWxtazHcZ52SGzpMaVr s5CTiSdWtaShM+EXbPI//fE2Zij4Xno7e+fx3nf7uTsw8Lf2Y8qhMmZPdtqnZbgJEt6C FbcA== X-Gm-Message-State: AOAM532aDu/gR/vda5jxDQVhQVtqWzujk9t6X9gc81NX8/IRmWxcWFwN o2x5//V6//3FmbrAnBi3THdsHDltMuIB9A== X-Google-Smtp-Source: ABdhPJzyykOnrWXlB7Jxycib/4xaMrTelcciq4xuHq4a+nXDhnboQc8UqTpifsZITpoGABRC+6KUdw== X-Received: by 2002:a17:90a:ab0f:: with SMTP id m15mr20775376pjq.154.1627961098886; Mon, 02 Aug 2021 20:24:58 -0700 (PDT) Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id r13sm15047907pgi.78.2021.08.02.20.24.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Aug 2021 20:24:58 -0700 (PDT) To: Jay Daley , Michael StJohns Cc: rfced-future@iab.org References: <3CAE5F5790D60E614C535A32@JcK-HP5> <87b10815-1071-96fc-103b-1479e82eb15a@nthpermutation.com> From: Brian E Carpenter Message-ID: <2c85e16c-a2ec-a674-c21c-9bde817a1bd7@gmail.com> Date: Tue, 3 Aug 2021 15:24:53 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Replacement text for Section 4.2 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2021 03:25:05 -0000 On 03-Aug-21 15:07, Jay Daley wrote: >=20 >=20 >> On 3/08/2021, at 2:50 PM, Michael StJohns > wrote: >> >> On 8/2/2021 7:10 PM, Joel M. Halpern wrote: >>> I read the text as being aimed at providing appropriate guardrails (m= andating what we consider necessary) while trusting the LLC / IAD to exec= ute reasonably well. >>> >>> For example, if we do not tell them they need to consult the communit= y, then a complaint to the nomcom that they did not consult the community=20 is not very strong.=C2=A0 If we require it, then the complaint is saying = something. >>> >>> Yours, >>> joel >> >> >> I'll repeat the same question I asked before to wit:=C2=A0 Is the LLC = required to consult the community for the IED - e.g. is there a formal re= quirement written somewhere that the LLC will periodically ask "how is Ja= y doing"?=C2=A0 If not, then why should this be any different? >=20 > It=E2=80=99s not in my contract no. =C2=A0All it says is "The Employee = agrees to participate fully in any formal performance appraisal program t= hat shall be conducted by the company". =C2=A0 BCP 101 doesn't specify any periodicity, but it does make it clear that t= he community can complain: https://www.rfc-editor.org/rfc/rfc8711.html#se= ction-4.7 Since it's the LLC that will hire the RSCE, I suppose that avenue could a= pply here too. But since the RFC community is wider than the IETF communi= ty, it seems natural to me to write something down that is specific to th= e RSCE case. Brian > Jay >=20 >> >> I think your argument is too much of a strawman in any case. There are=20 lots of reasons we might ding the LLC via the Nomcom - but personnel issu= es will not be (a useful) one of them as the actual personnel actions and=20 who voted for what with respect to those actions will not be visible to t= he Nomcom. >> >> Later, Mike >> >> >> --=20 >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future >=20 > --=C2=A0 > Jay Daley > IETF Executive Director > jay@ietf.org >=20 >=20 From nobody Tue Aug 3 01:30:03 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D20EA3A19C3 for ; Tue, 3 Aug 2021 01:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch 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 WU8w-e6xzrBW for ; Tue, 3 Aug 2021 01:29:56 -0700 (PDT) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF14D3A19C0 for ; Tue, 3 Aug 2021 01:29:55 -0700 (PDT) Received: from [IPv6:2001:420:c0c0:1011::7] ([IPv6:2001:420:c0c0:1011:0:0:0:7]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 1738TqxK168835 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Tue, 3 Aug 2021 10:29:52 +0200 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1627979393; bh=AbZjNfQt657E1eE9JlDLXOm3CJq/csDbQz29kVqXlfY=; h=To:Cc:From:Subject:Date:From; b=T4EnejeapuClYxabNPfRCmCRShA0DPWj4QP+HdC49482NvQbz/N6f0Id+hh5RpCSL JpG6BTwYMdjB+guWkRwCBFj53RPnePs6QKYGbC8HNt57ezOsHoJSlJJ5EyetmjEOhn WNu5iLWet+7D8fx4+GYgDFy6kYs3e34f1VIexEIc= To: "rfced-future@iab.org" Cc: EKR From: Eliot Lear Message-ID: <693d789b-da06-7a34-035f-152cfc9fa6cc@lear.ch> Date: Tue, 3 Aug 2021 10:29:48 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="JWRKpWlVekpeqS8r46aS2KfqEOjw06qFy" Archived-At: Subject: [Rfced-future] Reviewing Issue 16: Who handles oversight/appeals? Propose to close. X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2021 08:30:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --JWRKpWlVekpeqS8r46aS2KfqEOjw06qFy Content-Type: multipart/mixed; boundary="rOW9xMrzMcT9BCJNaanZpahNBEkzzMGGK"; protected-headers="v1" From: Eliot Lear To: "rfced-future@iab.org" Cc: EKR Message-ID: <693d789b-da06-7a34-035f-152cfc9fa6cc@lear.ch> Subject: Reviewing Issue 16: Who handles oversight/appeals? Propose to close. --rOW9xMrzMcT9BCJNaanZpahNBEkzzMGGK Content-Type: multipart/alternative; boundary="------------99C88964E8DA709F5E3DA4B7" Content-Language: en-US This is a multi-part message in MIME format. --------------99C88964E8DA709F5E3DA4B7 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Peter has wondered in the issue tracker if we should close this issue.=C2= =A0=20 He wrote: > Version -01 says: > > The RSWG shall operate by rough consensus, a mode of operation > informationally described in [RFC7282]. > > and: > > It is the responsibility of the chairs to encourage rough > consensus within the RSWG and to follow that consensus in their > decision making, for instance regarding advancement of proposals > to the RSAB. > > and: > > It is expected that the RSAB will respect the rough consensus of > the RSWG wherever possible, without ceding its review function. > > So I think we can close this issue? > Before we do that, I want to review the concerns that have been raised,=20 and there are two.=C2=A0 The first was simply this: what happens if the=20 chairs do not call consensus?=C2=A0 What is the redress?=C2=A0 The second= is what=20 happens if there is an appeal to the RSAB on an issue driven by RSAB=20 members that most people would say DOESN'T have consensus where the=20 chairs have NOT called consensus? The text in draft -00 has this to say about *not* calling consensus: =C2=A0=C2=A0 Appeals of RSWG decisions shall be made to the RSAB. Decisi= ons of =C2=A0=C2=A0 the RSWG can only be appealed on grounds of failure to foll= ow the =C2=A0=C2=A0 correct process.=C2=A0 Appeals should be made within 30 day= s of any =C2=A0=C2=A0 action, or in the case of failure to act, of notice having = been given =C2=A0=C2=A0 to the RSWG.=C2=A0 The RSAB will then decide if the process= was followed =C2=A0=C2=A0 and will direct RSWG chairs as to what procedural actions a= re =C2=A0=C2=A0 required. From my perspective, this handles the first case reasonably well, along = with the text that Peter quotes. The text in -00 also says: > =C2=A0 Appeals of RSAB decisions shall be made to the IAB and should be= made > =C2=A0=C2=A0 within thirty (30) days of public notice of the relevant R= SAB > =C2=A0=C2=A0 decision (typically, when minutes are posted).=C2=A0 The a= ppeals body > =C2=A0=C2=A0 shall decide whether a process failure occurred and what i= f any > =C2=A0=C2=A0 corrective action should take place. Part of following the process is the text Peter quoted, and so the IAB=20 can take corrective measures in the 2nd case. Given this, unless anyone has any great insights as to how to improve=20 this text, I suggest that we do indeed close this issue. Please comment=20 by the 17th of August. Eliot --------------99C88964E8DA709F5E3DA4B7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Peter has wondered in the issue tracker if we should close this issue.=C2=A0 He wrote:

Version -01 says:

The RSWG shall operate by rough consensus, a mode of operation informationally described in [RFC7282].

and:

It is the responsibility of the chairs to encourage rough consensus within the RSWG and to follow that consensus in their decision making, for instance regarding advancement of proposals to the RSAB.

and:

It is expected that the RSAB will respect the rough consensus of the RSWG wherever possible, without ceding its review function.

So I think we can close this issue?

Before we do that, I want to review the concerns that have been raised, and there are two.=C2=A0 The first was simply this: what happens if the chairs do not call consensus?=C2=A0 What is the redress?=C2=A0 The second is what happens if there is an appeal to = the RSAB on an issue driven by RSAB members that most people would say DOESN'T have consensus where the chairs have NOT called consensus?<= /p>

The text in draft -00 has this to say about not calling consensus:

=C2=A0=C2=A0 Appeals of RSWG decisions shall be made to the RSAB.=C2= =A0 Decisions of
=C2=A0=C2=A0 the RSWG can only be appealed on grounds of failure to= follow the
=C2=A0=C2=A0 correct process.=C2=A0 Appeals should be made within 3= 0 days of any
=C2=A0=C2=A0 action, or in the case of failure to act, of notice ha= ving been given
=C2=A0=C2=A0 to the RSWG.=C2=A0 The RSAB will then decide if the pr= ocess was followed
=C2=A0=C2=A0 and will direct RSWG chairs as to what procedural acti= ons are
=C2=A0=C2=A0 required.

From my perspective, this handles the first case reasonably well, along with the text that Peter quotes.

The text in -00 also says:

=C2=A0 Appeals of RSAB decisions shall be= made to the IAB and should be made
=C2=A0=C2=A0 within thirty (30) days of public notice of the rele= vant RSAB
=C2=A0=C2=A0 decision (typically, when minutes are posted).=C2=A0= The appeals body
=C2=A0=C2=A0 shall decide whether a process failure occurred and = what if any
=C2=A0=C2=A0 corrective action should take place.

Part of following the process is the text Peter quoted, and so the IAB can take corrective measures in the 2nd case.

Given this, unless anyone has any great insights as to how to improve this text, I suggest that we do indeed close this issue.=C2= =A0 Please comment by the 17th of August.

Eliot

--------------99C88964E8DA709F5E3DA4B7-- --rOW9xMrzMcT9BCJNaanZpahNBEkzzMGGK-- --JWRKpWlVekpeqS8r46aS2KfqEOjw06qFy Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmEI/nwFAwAAAAAACgkQh7ZrRtnSejOZ WQgAn3eYHzh6Xeq8t5FMu1kVuwS05PvdMKWUlp4yyRV9FcUbTe7NIoDLSv/pmw3JBCNjFVVRjQV8 L0voDuavbmOhKNG5b3lxQTKnsVoUJPzqBrfr7ePmk14gDV5fAejc0+IeV5Cnfg4SCdxxbuSa592K Kxk6YXj10Bb7N+Fogwxx/kdESsAm1OM6sW+4Yottx9aSLvPObAkz/NxE4bQmsFJh50KCZgcL63zA wL02mcAZYrSTNn3a3MFQwtD5BK0Qp9w/xAXViwND+EBoHah9KhAFFhlPX1XShf/8T6Xiod40rUH4 gG0qLLpQS9kzbabDR0RGgflLpvf72FZ/9EC2wox61g== =Q1kI -----END PGP SIGNATURE----- --JWRKpWlVekpeqS8r46aS2KfqEOjw06qFy-- From nobody Tue Aug 3 01:40:45 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FBCD3A1A12 for ; Tue, 3 Aug 2021 01:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 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, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch 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 1RWItlpv8xgM for ; Tue, 3 Aug 2021 01:40:39 -0700 (PDT) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9678D3A1A10 for ; Tue, 3 Aug 2021 01:40:39 -0700 (PDT) Received: from [IPv6:2001:420:c0c0:1011::7] ([IPv6:2001:420:c0c0:1011:0:0:0:7]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 1738ea3n168986 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Tue, 3 Aug 2021 10:40:36 +0200 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1627980036; bh=btaw5b1E282gQ050G9d1FeeQc4uZE/EJXI8D3WtPRAQ=; h=To:Cc:From:Subject:Date:From; b=ZOrKcIl0M8rc7q8l6Cozi/HxbK8xOMYfgvA9qhngWlq7R+V/Gm6O278AoQ7je46Vu +CoDB40E/4nDmGMYPMXgMmr1+QueEAnAugxwfEhIHmPf8USdFkMouqB2kBpAlkPuOZ Asoog8G/FCCPyl7A8CHnLbbxFpPHkyd6Bs5xJUzE= To: "Joel M. Halpern" Cc: "rfced-future@iab.org" From: Eliot Lear Message-ID: <19a7134f-8ac8-b8b3-3ac4-73af4ddf503e@lear.ch> Date: Tue, 3 Aug 2021 10:40:35 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="eosphPU9ljZq3plLOjK0Hjy4TlpyhP61X" Archived-At: Subject: [Rfced-future] Issue 43: LLC and structure text X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2021 08:40:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --eosphPU9ljZq3plLOjK0Hjy4TlpyhP61X Content-Type: multipart/mixed; boundary="CpGPQtJ6wHnmekbDZfy2K1BRDF7Cv7dws"; protected-headers="v1" From: Eliot Lear To: "Joel M. Halpern" Cc: "rfced-future@iab.org" Message-ID: <19a7134f-8ac8-b8b3-3ac4-73af4ddf503e@lear.ch> Subject: Issue 43: LLC and structure text --CpGPQtJ6wHnmekbDZfy2K1BRDF7Cv7dws Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Joel, As part of your April review you wrote: > As discussed earlier, to confirm, the paragraph that states that the=20 > LLC provides the structure for defining policies for the RFC Series=20 > seems to not be grounded in prior discussion, and be wrong. In terms=20 > of formal current authority, the authority for this activity comes=20 > from the IAB, via the earlier RFCs. In terms of who beyond the=20 > WG-to-be should have such authority, or how that WG could be changed,=20 > is an interesting one that has not been discussed. I believe the first sentence has been addressed.=C2=A0 Can you confirm th= is? I would like to take up the formal authority question in a separate=20 discussion.=C2=A0 With that understanding, are you okay with this issue b= eing=20 closed? Eliot --CpGPQtJ6wHnmekbDZfy2K1BRDF7Cv7dws-- --eosphPU9ljZq3plLOjK0Hjy4TlpyhP61X Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmEJAQMFAwAAAAAACgkQh7ZrRtnSejMH SAf7B7tpi1VGsTxYW7akuuAzAy4j9Rpa4ViTOVCo0+NZ9QqSNNMhnjPx50RLEZ1ZTTIXOg/RXgCE 1c1pYbzsIGXa5JaNvYngLLKgp8H9F7Zb6Z8xc64unzDRuiqsN8N5+O60R1rMKQHjGd6YQvB3Q72Q Qfq0++DnSU0ubil1k4LpCPCy48ZmiNQvkeAD23k86rUsH2WF+uM90R0m4uuwIjT7RQ1qrWHji9yB bG9Ei8lMspT00Wl90t335x9vFq+ubnQa/1xZtliAE2PMUBRDU+3bYh3MvOFu32sepQk4//JYMY/5 BfcyppZJXq3sY8rmpxghMhl1X/Y7zzOIf7iuISzB1Q== =QqXE -----END PGP SIGNATURE----- --eosphPU9ljZq3plLOjK0Hjy4TlpyhP61X-- From nobody Tue Aug 3 05:14:01 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 317923A212C for ; Tue, 3 Aug 2021 05:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 PkUymD_iQLmk for ; Tue, 3 Aug 2021 05:13:55 -0700 (PDT) Received: from bsa3.jck.com (static-65-175-133-136.nh.cpe.atlanticbb.net [65.175.133.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14C4A3A2129 for ; Tue, 3 Aug 2021 05:13:54 -0700 (PDT) Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1mAtHR-0002T2-7T; Tue, 03 Aug 2021 08:12:21 -0400 Date: Tue, 03 Aug 2021 08:12:00 -0400 From: John C Klensin To: Michael StJohns , rfced-future@iab.org Message-ID: <1A4090C2089720E240F62E1F@JcK-HP5> In-Reply-To: <6090c77c-4da0-5a00-4a4c-f2f2bfc08565@nthpermutation.com> References: <3CAE5F5790D60E614C535A32@JcK-HP5> <59CA5FEFFE26D92DDA3AE545@JcK-HP5> <9b42615f-ede4-2db1-a1d4-dbc42c13498a@gmail.com> <6090c77c-4da0-5a00-4a4c-f2f2bfc08565@nthpermutation.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Archived-At: Subject: Re: [Rfced-future] Replacement text for Section 4.2 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2021 12:13:59 -0000 (off list) --On Monday, 02 August, 2021 22:42 -0400 Michael StJohns wrote: >... > *sigh* I can see where this is going >... I assume you see the same thing I see. We replace an out of control and over-controlling RSOC and IAB with a sometimes out of control and often over-controlling ExecDir who tends to be controlling at times and, while I can't go public with what I know because I (and they) are convinced it would cause retribution for violating his instructions, has told various people at AMSthat they are not allowed to participate in IETF technical work or speak directly with the community without his instructions and that they are forbidden to tell the community about those restrictions. They are all "just contractors" and he is running the show. The problem with Henrik was that he was not managed and supervised enough, etc. I think Jay is doing rather well at the job he believes he was told to do, but I hope the community is going to be happy with what it wished for. I wish I knew how to fix this other than concluding that the IETF has outlived its useful life. john From nobody Tue Aug 3 05:40:01 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2676C3A21D7 for ; Tue, 3 Aug 2021 05:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no 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 j_TUK0aPBkcO for ; Tue, 3 Aug 2021 05:39:56 -0700 (PDT) Received: from bsa3.jck.com (static-65-175-133-136.nh.cpe.atlanticbb.net [65.175.133.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56B6B3A21D4 for ; Tue, 3 Aug 2021 05:39:56 -0700 (PDT) Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1mAthr-0002U2-N6 for rfced-future@iab.org; Tue, 03 Aug 2021 08:39:39 -0400 Date: Tue, 03 Aug 2021 08:39:19 -0400 From: John C Klensin To: rfced-future@iab.org Message-ID: In-Reply-To: <1A4090C2089720E240F62E1F@JcK-HP5> References: <3CAE5F5790D60E614C535A32@JcK-HP5> <59CA5FEFFE26D92DDA3AE545@JcK-HP5> <9b42615f-ede4-2db1-a1d4-dbc42c13498a@gmail.com> <6090c77c-4da0-5a00-4a4c-f2f2bfc08565@nthpermutation.com> <1A4090C2089720E240F62E1F@JcK-HP5> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Archived-At: Subject: [Rfced-future] Apologies X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2021 12:40:00 -0000 Hi. Sorry. I just sent a note to the list than was intended for Mike only. As many of your know, I'm often more blunt and outspoken in private than in more public contexts. Please ignore if possible. john From nobody Tue Aug 3 06:57:40 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15A1F3A24C1 for ; Tue, 3 Aug 2021 06:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 5b9Nuqhso58B for ; Tue, 3 Aug 2021 06:57:34 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DB0C3A24BF for ; Tue, 3 Aug 2021 06:57:34 -0700 (PDT) Received: from p200300dee72c62009c2e811e0ce79019.dip0.t-ipconnect.de ([2003:de:e72c:6200:9c2e:811e:ce7:9019]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1mAuv8-0004Uo-SN; Tue, 03 Aug 2021 15:57:26 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Mirja Kuehlewind In-Reply-To: Date: Tue, 3 Aug 2021 15:57:25 +0200 Cc: "rfced-future@iab.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Eliot Lear X-Mailer: Apple Mail (2.3608.120.23.2.4) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1627999054;fc1d3d52; X-HE-SMSGID: 1mAuv8-0004Uo-SN Archived-At: Subject: Re: [Rfced-future] Consensus check: Issue 55 Suggestions for ongoing evaluation of RS[EA] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2021 13:57:39 -0000 This process is fine for me. I just would like to ask/double-check why = we ended up with sending community feedback to the LLC rather than = directly to the RSAB (excluding the RSEA)? > On 30. Jul 2021, at 01:07, Eliot Lear wrote: >=20 > In today's call, Jay indicated that he wanted to have some sort of = confidential review of community feedback relating to the RSEA = performance. What the group came up with on the call was the following = process: >=20 > =E2=80=A2 Community feedback to the LLC > =E2=80=A2 LLC produces a draft performance evaluation for the = RSAB (excluding the RSEA) > =E2=80=A2 RSAB (excluding RSEA) provides feedback back to the = LLC on that evaluation. > If you disagree with this approach, could you comment by the 13th of = August? >=20 > Eliot >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future From nobody Tue Aug 3 07:20:54 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE6D73A2580 for ; Tue, 3 Aug 2021 07:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 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, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch 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 r-K3iwXSiTfN for ; Tue, 3 Aug 2021 07:20:45 -0700 (PDT) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 068AE3A2570 for ; Tue, 3 Aug 2021 07:20:44 -0700 (PDT) Received: from [IPv6:2001:420:c0c0:1011::5] ([IPv6:2001:420:c0c0:1011:0:0:0:5]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 173EKfTj173039 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Tue, 3 Aug 2021 16:20:42 +0200 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1628000442; bh=tKXx1Fxy44pFMuewTRYm6PHj++EhmCqMonv/2Y11qJk=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=NPHmazu1KG6w9lsofjl4pVHmEApdRv0a/M6Lbnnu1rZqsiq3K2q/8gH+avHKf7XTe ROwHBnf+pzyeMTbMAi2Slr+CsbgtArEOnEJ/Sny0BFKtb5uCU4zLKku+vG/7LUSnWa dedssk91eP8aZ69p5bkgtDk9F0ce94Fw7uq4EIC8= To: Mirja Kuehlewind Cc: "rfced-future@iab.org" References: From: Eliot Lear Message-ID: <0bdad87d-3bec-f3c7-4493-71233dc54300@lear.ch> Date: Tue, 3 Aug 2021 16:20:38 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3sreESuVGg961qAiWbg95ZbZOIPbKniwO" Archived-At: Subject: Re: [Rfced-future] Consensus check: Issue 55 Suggestions for ongoing evaluation of RS[EA] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2021 14:20:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3sreESuVGg961qAiWbg95ZbZOIPbKniwO Content-Type: multipart/mixed; boundary="2vIrthfGE0nc8UL70nUNj78SaaOicLJP0"; protected-headers="v1" From: Eliot Lear To: Mirja Kuehlewind Cc: "rfced-future@iab.org" Message-ID: <0bdad87d-3bec-f3c7-4493-71233dc54300@lear.ch> Subject: Re: [Rfced-future] Consensus check: Issue 55 Suggestions for ongoing evaluation of RS[EA] References: In-Reply-To: --2vIrthfGE0nc8UL70nUNj78SaaOicLJP0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Others may disagree, but I interpreted the discussion of this review in=20 part as a desire from the LLC to add context to comment.=C2=A0 That is- d= o=20 the experts in the RSAB see another side to issues that individuals have = raised that the individuals themselves haven't seen?=C2=A0 I think it mig= ht=20 make sense to add that sort of narrative text into the document so that=20 people understand the reasoning for the review. Eliot On 03.08.21 15:57, Mirja Kuehlewind wrote: > This process is fine for me. I just would like to ask/double-check why = we ended up with sending community feedback to the LLC rather than direct= ly to the RSAB (excluding the RSEA)? > > >> On 30. Jul 2021, at 01:07, Eliot Lear wrote: >> >> In today's call, Jay indicated that he wanted to have some sort of con= fidential review of community feedback relating to the RSEA performance. = What the group came up with on the call was the following process: >> >> =E2=80=A2 Community feedback to the LLC >> =E2=80=A2 LLC produces a draft performance evaluation for the RSAB (e= xcluding the RSEA) >> =E2=80=A2 RSAB (excluding RSEA) provides feedback back to the LLC on = that evaluation. >> If you disagree with this approach, could you comment by the 13th of A= ugust? >> >> Eliot >> >> --=20 >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future --2vIrthfGE0nc8UL70nUNj78SaaOicLJP0-- --3sreESuVGg961qAiWbg95ZbZOIPbKniwO Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmEJULYFAwAAAAAACgkQh7ZrRtnSejOQ ywf/Xn9y2kK76tAuLYzlrtggxGWiYl3rYu1IxZDNmSrTz2f2rPkSe4E/96II/TzZEdRZXhd8tWC/ GBiQ91dGiSro/bsBFq6Bj5SGWi1nBFIIX/HR99vkW/yUmH2kusiw9UP123fyn+Gg2JRpqfWlC1gC WfPuy4xqXBgS3+obefq5NJNtNyQhA6WXmuLD6LOPgLwTs/pOZeDKv80lJ1D4K0mID9NlqTJ7if3H sApPrF+WdP7iEwIl2IuD43lHh1peFXP3cJxuIRkZlLGola0hjh9JwR0MiWhy6+hZScuV5RaTKiOD T2dWJMdq3kI4T3qlKCOofbSYp1pipumn8fUleA3UWA== =8BM8 -----END PGP SIGNATURE----- --3sreESuVGg961qAiWbg95ZbZOIPbKniwO-- From nobody Tue Aug 3 07:26:50 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF1623A259E for ; Tue, 3 Aug 2021 07:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 4AivLLSKFjVU for ; Tue, 3 Aug 2021 07:26:43 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FD873A2599 for ; Tue, 3 Aug 2021 07:26:43 -0700 (PDT) Received: from p200300dee72c62009c2e811e0ce79019.dip0.t-ipconnect.de ([2003:de:e72c:6200:9c2e:811e:ce7:9019]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1mAvNO-00046L-Qc; Tue, 03 Aug 2021 16:26:38 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Mirja Kuehlewind In-Reply-To: <0bdad87d-3bec-f3c7-4493-71233dc54300@lear.ch> Date: Tue, 3 Aug 2021 16:26:37 +0200 Cc: "rfced-future@iab.org" Content-Transfer-Encoding: quoted-printable Message-Id: <3D4DACBC-A360-4952-8685-AB43CA60CBC8@kuehlewind.net> References: <0bdad87d-3bec-f3c7-4493-71233dc54300@lear.ch> To: Eliot Lear X-Mailer: Apple Mail (2.3608.120.23.2.4) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1628000803;47c5d6f4; X-HE-SMSGID: 1mAvNO-00046L-Qc Archived-At: Subject: Re: [Rfced-future] Consensus check: Issue 55 Suggestions for ongoing evaluation of RS[EA] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2021 14:26:48 -0000 Thanks Eliot. However, just catching with the rest of the thread (on sec = 4.2), this seems obsolete as we seem to tend to provide less level of = detail, which I support. > On 3. Aug 2021, at 16:20, Eliot Lear wrote: >=20 > Others may disagree, but I interpreted the discussion of this review = in part as a desire from the LLC to add context to comment. That is- do = the experts in the RSAB see another side to issues that individuals have = raised that the individuals themselves haven't seen? I think it might = make sense to add that sort of narrative text into the document so that = people understand the reasoning for the review. >=20 > Eliot >=20 > On 03.08.21 15:57, Mirja Kuehlewind wrote: >> This process is fine for me. I just would like to ask/double-check = why we ended up with sending community feedback to the LLC rather than = directly to the RSAB (excluding the RSEA)? >>=20 >>=20 >>> On 30. Jul 2021, at 01:07, Eliot Lear wrote: >>>=20 >>> In today's call, Jay indicated that he wanted to have some sort of = confidential review of community feedback relating to the RSEA = performance. What the group came up with on the call was the following = process: >>>=20 >>> =E2=80=A2 Community feedback to the LLC >>> =E2=80=A2 LLC produces a draft performance evaluation for the = RSAB (excluding the RSEA) >>> =E2=80=A2 RSAB (excluding RSEA) provides feedback back to the = LLC on that evaluation. >>> If you disagree with this approach, could you comment by the 13th of = August? >>>=20 >>> Eliot >>>=20 >>> --=20 >>> Rfced-future mailing list >>> Rfced-future@iab.org >>> https://www.iab.org/mailman/listinfo/rfced-future >=20 From nobody Tue Aug 3 07:57:39 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5E863A2670 for ; Tue, 3 Aug 2021 07:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 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, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch 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 73mp_Nf27x2t for ; Tue, 3 Aug 2021 07:57:32 -0700 (PDT) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF5403A266F for ; Tue, 3 Aug 2021 07:57:31 -0700 (PDT) Received: from [IPv6:2001:420:c0c0:1011::5] ([IPv6:2001:420:c0c0:1011:0:0:0:5]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 173EvSfA173314 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Tue, 3 Aug 2021 16:57:29 +0200 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1628002649; bh=OpO6j6LRiXJFaDHa+sPsBcAAnrrwmF+f9280Wjmjy98=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=waQLsb8QoYwcKgMd2hZ20Trsk999yFnIB5/cdMeyRp9n1DVJdzIBoshxCSVGehKNx AfjfgAZrAKwcq4LNjuHSoxV7gHJ2FLuDufGPfkzq3W2q8KQoj9zNiTYpoSg+HaY5ez n5ShYQV0/F9XX8nr7oSMlmZ5amtZu3XKDY7nKiRg= To: Mirja Kuehlewind Cc: "rfced-future@iab.org" References: <0bdad87d-3bec-f3c7-4493-71233dc54300@lear.ch> <3D4DACBC-A360-4952-8685-AB43CA60CBC8@kuehlewind.net> From: Eliot Lear Message-ID: <03554458-031e-c99d-6dd9-d126d8c74b78@lear.ch> Date: Tue, 3 Aug 2021 16:57:27 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <3D4DACBC-A360-4952-8685-AB43CA60CBC8@kuehlewind.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vntI2LMYnErhfmDBGJQVudioVyGbBpBuU" Archived-At: Subject: Re: [Rfced-future] Consensus check: Issue 55 Suggestions for ongoing evaluation of RS[EA] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2021 14:57:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --vntI2LMYnErhfmDBGJQVudioVyGbBpBuU Content-Type: multipart/mixed; boundary="kFb749YJy8nHIGV7oQfkAwaZTrTMMAGYo"; protected-headers="v1" From: Eliot Lear To: Mirja Kuehlewind Cc: "rfced-future@iab.org" Message-ID: <03554458-031e-c99d-6dd9-d126d8c74b78@lear.ch> Subject: Re: [Rfced-future] Consensus check: Issue 55 Suggestions for ongoing evaluation of RS[EA] References: <0bdad87d-3bec-f3c7-4493-71233dc54300@lear.ch> <3D4DACBC-A360-4952-8685-AB43CA60CBC8@kuehlewind.net> In-Reply-To: <3D4DACBC-A360-4952-8685-AB43CA60CBC8@kuehlewind.net> --kFb749YJy8nHIGV7oQfkAwaZTrTMMAGYo Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Mirja, On 03.08.21 16:26, Mirja Kuehlewind wrote: > Thanks Eliot. However, just catching with the rest of the thread (on se= c 4.2), this seems obsolete as we seem to tend to provide less level of d= etail, which I support. You asked a very legitimate question.=C2=A0 I am not actually sure that I= =20 have answered it correctly, by the way.=C2=A0 Others should chime in. =C2= =A0 If=20 you asked it, someone else who is not here today and does not yet=20 understand our processes and who may hold the reigns some years from now = may well ask the question as well. Let's therefore make the distinction=20 between more normative text and more explanatory text.=C2=A0 One can=20 absolutely go overboard on both, but there needs to be enough. To this end, I would suggest that when we are close enough to done, we=20 will need to find some fresh eyes, along the lines of a shepherd review, = to see if what we have written makes sense to others.=C2=A0 More on next = steps, tho, in a separate message. Eliot --kFb749YJy8nHIGV7oQfkAwaZTrTMMAGYo-- --vntI2LMYnErhfmDBGJQVudioVyGbBpBuU Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmEJWVcFAwAAAAAACgkQh7ZrRtnSejOR Kgf/cbW+B9nGVuGJGu4fk05iH2vVEGZOINaF024PsGfJ2uefdDP9Eaca4pY6G5WAG63HIE5iaX2o rVDpdbwUBLa4++VG9TN/5bzT2BOTs4dgW6X8+QgK3fpXra+vWkcz1yy1Vx//mm+zuHUgnLl6xu4m M2YDPxvjnhkPh/mdhFLUyXoUcTY3J30tihKYgckmrAixOeVMyNZGrMU7lTIVXsjcGy6ifpVVi34/ MNgyNjPJdyKVB33u4j2xWwoRSWh0370UnMij6bDc2h0VLQRzYo2A2CRTexVxBtGSP83he6iEHSqK F2Frr3JTqlwO2S6FmoN/7my6ygOHOkwA/C43yJj/Pw== =J6l8 -----END PGP SIGNATURE----- --vntI2LMYnErhfmDBGJQVudioVyGbBpBuU-- From nobody Tue Aug 3 08:22:05 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 875BB3A271F for ; Tue, 3 Aug 2021 08:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 h6MhGZvG9zjb for ; Tue, 3 Aug 2021 08:21:59 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A02E3A2720 for ; Tue, 3 Aug 2021 08:21:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4GfJWV558Lz6GR9F; Tue, 3 Aug 2021 08:21:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1628004118; bh=T3Be7OyD1qqAbW7dHwx7YDbTKwQQCK4AOB4N00VX2FM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=bXK/gaw9y5BqQZKS/Ty1Wut1wBZEMaJXkuuWqoo98nQr62aj8Ohw9ZCEU/9Pv3qdc ni9dQ9M07+I+9PtUByzJkXmtjqStsFRsw6ziJEXpI8D6ZhNy2JmlqeiXR95GiMe6+8 ja4uPohN1HKgFDvd5CYpPvEAOtX1lBmi/KpjW2Qk= X-Quarantine-ID: <8CMHUuVpfxyV> X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.23.64] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (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 maila2.tigertech.net (Postfix) with ESMTPSA id 4GfJWT6DnJz6G9CK; Tue, 3 Aug 2021 08:21:57 -0700 (PDT) To: Eliot Lear Cc: "rfced-future@iab.org" References: <19a7134f-8ac8-b8b3-3ac4-73af4ddf503e@lear.ch> From: "Joel M. Halpern" Message-ID: <5f278d0c-ae9a-fffa-7bf0-9abd992e584e@joelhalpern.com> Date: Tue, 3 Aug 2021 11:21:56 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <19a7134f-8ac8-b8b3-3ac4-73af4ddf503e@lear.ch> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Issue 43: LLC and structure text X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2021 15:22:04 -0000 Looking at the document, I am fine with closing this issue. Thank you, Joel On 8/3/2021 4:40 AM, Eliot Lear wrote: > Joel, > > As part of your April review you wrote: > >> As discussed earlier, to confirm, the paragraph that states that the >> LLC provides the structure for defining policies for the RFC Series >> seems to not be grounded in prior discussion, and be wrong. In terms >> of formal current authority, the authority for this activity comes >> from the IAB, via the earlier RFCs. In terms of who beyond the >> WG-to-be should have such authority, or how that WG could be changed, >> is an interesting one that has not been discussed. > > I believe the first sentence has been addressed.  Can you confirm this? > > I would like to take up the formal authority question in a separate > discussion.  With that understanding, are you okay with this issue being > closed? > > Eliot > > > From nobody Tue Aug 3 08:49:01 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B58D3A27ED for ; Tue, 3 Aug 2021 08:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 fC6F4ca1-Mdn for ; Tue, 3 Aug 2021 08:48:58 -0700 (PDT) Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (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 0799A3A27C5 for ; Tue, 3 Aug 2021 08:48:57 -0700 (PDT) Received: by mail-il1-x12e.google.com with SMTP id x7so16566532ilh.10 for ; Tue, 03 Aug 2021 08:48:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=tj6KbPrIvv7y2yAnJacSXE+CwBoM0f0EpNZqiRBATj8=; b=Vqe4fpYY6PrlyPyTfuiM54ldqf+cH6Oc7nnBRBeAuViaWcIjXLBB/UOJZaHL9589R8 sMRnx7DQQ/8g5DtAvzflWnhtR7W/lwRcLE+ITJiwwi2tlb339UoVaRm4/y+pAuSKxb0K Uza9FA2cHcmNeAikMN+oDlaU8ICXg+bjIi6Ss= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=tj6KbPrIvv7y2yAnJacSXE+CwBoM0f0EpNZqiRBATj8=; b=rNiHEVPXOIwNX3n6adKu/0DUv7FymPiHVGNwvLJX9Qu6zT1JA07mjQy/vtxV2r1JMq eQQjx/Vm/eVM4ZpfwsZ0nFJ2OKhEVSgL4OQCnsIuGUpuZs9MB2oYzvl10W0EZDoYKAgq WdPSFt71tN6dW3Xlwa1VQyhzEPyLR7f6zfPNYySHGQ4/XwvWw7F57ye/HFwS2IAqKvnP 4lte31+DLcJGIu5ssvAzCxJM67jjl5Toqzf0UJYJqGkoVmvJlN9q1hiXVmSCq3MjGkdx 4xzcfGBahR4XNov+d5E+bcwNCUoBDCl5xPg48xi3Etb9dxZb31EhQQLXcTBrdvXzhmAO fa1Q== X-Gm-Message-State: AOAM532D7MxtsQuNm00mwcADgBFNjgdrbpyuol/6R7soz6yJVN/TMjP8 qcTbWma1CpwXF2VT/+Kem3teAA== X-Google-Smtp-Source: ABdhPJxJdnGEwZcSDFzi0LftRfLt+hDsJhyMzV+BRC1lxchtMwF9Ifuou5Yp+5nJmBX3+gB7+ID4Lw== X-Received: by 2002:a05:6e02:1c88:: with SMTP id w8mr47515ill.154.1628005736807; Tue, 03 Aug 2021 08:48:56 -0700 (PDT) Received: from dragon.local (c-73-78-113-156.hsd1.co.comcast.net. [73.78.113.156]) by smtp.gmail.com with ESMTPSA id 125sm9999630iow.9.2021.08.03.08.48.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 03 Aug 2021 08:48:56 -0700 (PDT) To: "Joel M. Halpern" , Michael StJohns , rfced-future@iab.org References: <3CAE5F5790D60E614C535A32@JcK-HP5> <87b10815-1071-96fc-103b-1479e82eb15a@nthpermutation.com> <402b19b8-11b6-bbaf-a9c8-5584f5c8a134@joelhalpern.com> From: Peter Saint-Andre Message-ID: <3ff3dc08-82e0-275d-3602-0b42c38b884e@mozilla.com> Date: Tue, 3 Aug 2021 09:48:55 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <402b19b8-11b6-bbaf-a9c8-5584f5c8a134@joelhalpern.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Replacement text for Section 4.2 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2021 15:49:00 -0000 [ no hats ] I thought Brian's one-sentence version covered things adequately: Periodically, the IETF LLC will evaluate the performance of the RSCE, including a call for confidential input from the community. Peter On 8/2/21 9:04 PM, Joel M. Halpern wrote: > It seems to me that if we as a community expect the LLC to do something, > we should tell them rather than expecting them to guess correctly waht > we want. > > It can be short (Brian's proposal).   But leaving it out because we > assume they will do the right thing seems rather odd. > > Yours, > Joel > > On 8/2/2021 10:50 PM, Michael StJohns wrote: >> On 8/2/2021 7:10 PM, Joel M. Halpern wrote: >>> I read the text as being aimed at providing appropriate guardrails >>> (mandating what we consider necessary) while trusting the LLC / IAD >>> to execute reasonably well. >>> >>> For example, if we do not tell them they need to consult the >>> community, then a complaint to the nomcom that they did not consult >>> the community is not very strong.  If we require it, then the >>> complaint is saying something. >>> >>> Yours, >>> joel >> >> >> I'll repeat the same question I asked before to wit:  Is the LLC >> required to consult the community for the IED - e.g. is there a formal >> requirement written somewhere that the LLC will periodically ask "how >> is Jay doing"?  If not, then why should this be any different? >> >> I think your argument is too much of a strawman in any case. There are >> lots of reasons we might ding the LLC via the Nomcom - but personnel >> issues will not be (a useful) one of them as the actual personnel >> actions and who voted for what with respect to those actions will not >> be visible to the Nomcom. >> >> Later, Mike >> >> > From nobody Tue Aug 3 16:55:55 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECD1C3A37ED for ; Tue, 3 Aug 2021 16:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 ajTYSJ8lhAM7; Tue, 3 Aug 2021 16:55:49 -0700 (PDT) Received: from smtpclient.apple (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id AAC983A37E8; Tue, 3 Aug 2021 16:55:48 -0700 (PDT) From: Jay Daley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_AF5F0B7C-6AEE-4963-A172-69396F33D50B" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Wed, 4 Aug 2021 11:55:45 +1200 In-Reply-To: <1A4090C2089720E240F62E1F@JcK-HP5> Cc: Michael StJohns , rfced-future@iab.org To: John C Klensin References: <3CAE5F5790D60E614C535A32@JcK-HP5> <59CA5FEFFE26D92DDA3AE545@JcK-HP5> <9b42615f-ede4-2db1-a1d4-dbc42c13498a@gmail.com> <6090c77c-4da0-5a00-4a4c-f2f2bfc08565@nthpermutation.com> <1A4090C2089720E240F62E1F@JcK-HP5> X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Rfced-future] Replacement text for Section 4.2 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2021 23:55:54 -0000 --Apple-Mail=_AF5F0B7C-6AEE-4963-A172-69396F33D50B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 4/08/2021, at 12:12 AM, John C Klensin wrote: >=20 > (off list) Fortunately for me, it wasn't >=20 > --On Monday, 02 August, 2021 22:42 -0400 Michael StJohns > wrote: >=20 >> ... >> *sigh* I can see where this is going >> ... >=20 > I assume you see the same thing I see. We replace an out of > control and over-controlling RSOC and IAB with a sometimes out > of control and often over-controlling ExecDir who tends to be > controlling at times and, while I can't go public with what I > know because I (and they) are convinced it would cause > retribution for violating his instructions, has told various > people at AMSthat they are not allowed to participate in IETF > technical work or speak directly with the community without his > instructions and that they are forbidden to tell the community > about those restrictions. =20 That is a deeply poisonous lie. You could have discounted it in just a = few minutes with an email to AMS but the fact that you chose not to do = that and instead to propagate and enhance it, speaks volumes to your = character. Jay > They are all "just contractors" and > he is running the show. The problem with Henrik was that he > was not managed and supervised enough, etc. >=20 > I think Jay is doing rather well at the job he believes he was > told to do, but I hope the community is going to be happy with > what it wished for. I wish I knew how to fix this other than > concluding that the IETF has outlived its useful life. >=20 > john >=20 >=20 >=20 >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future >=20 --=20 Jay Daley IETF Executive Director jay@ietf.org --Apple-Mail=_AF5F0B7C-6AEE-4963-A172-69396F33D50B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On 4/08/2021, at 12:12 AM, John C Klensin <klensin@jck.com> = wrote:

(off list)

Fortunately for me, it wasn't


--On Monday, 02 August, 2021 22:42 -0400 = Michael StJohns
<msj@nthpermutation.com> wrote:

...
*sigh* = I can see where this is going
...

I assume you see the same thing I = see.  We replace an out of
control and = over-controlling RSOC and IAB with a sometimes out
of = control and often over-controlling ExecDir who tends to be
controlling at times and, while I can't go public with what = I
know because I (and they) are convinced it would = cause
retribution for violating his instructions, has told = various
people at AMSthat they are not allowed to = participate in IETF
technical work or speak directly with = the community without his
instructions and that they are = forbidden to tell the community
about those restrictions. =  

That = is a deeply poisonous lie.  You could have discounted it in just a = few minutes with an email to AMS but the fact that you chose not to do = that and instead to propagate and enhance it, speaks volumes to your = character.

Jay


They are all = "just contractors" and
he is running the show. =   The problem with Henrik was that he
was not = managed and supervised enough, etc.

I = think Jay is doing rather well at the job he believes he was
told to do, but I hope the community is going to be happy = with
what it wished for.  I wish I knew how to fix = this other than
concluding that the IETF has outlived its = useful life.

   john




-- =
Rfced-future mailing list
Rfced-future@iab.org
https://www.iab.org/mailman/listinfo/rfced-future


-- 
Jay Daley
IETF = Executive Director
jay@ietf.org

= --Apple-Mail=_AF5F0B7C-6AEE-4963-A172-69396F33D50B-- From nobody Tue Aug 3 16:58:19 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06F8A3A3805 for ; Tue, 3 Aug 2021 16:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 5zUn8H9agNP5; Tue, 3 Aug 2021 16:58:13 -0700 (PDT) Received: from smtpclient.apple (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id AD82F3A3804; Tue, 3 Aug 2021 16:58:12 -0700 (PDT) From: Jay Daley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_C9EFC9ED-D3C6-4B02-89CC-3B3037181487" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Wed, 4 Aug 2021 11:58:09 +1200 In-Reply-To: <03554458-031e-c99d-6dd9-d126d8c74b78@lear.ch> Cc: Mirja Kuehlewind , "rfced-future@iab.org" To: Eliot Lear References: <0bdad87d-3bec-f3c7-4493-71233dc54300@lear.ch> <3D4DACBC-A360-4952-8685-AB43CA60CBC8@kuehlewind.net> <03554458-031e-c99d-6dd9-d126d8c74b78@lear.ch> X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Rfced-future] Consensus check: Issue 55 Suggestions for ongoing evaluation of RS[EA] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2021 23:58:18 -0000 --Apple-Mail=_C9EFC9ED-D3C6-4B02-89CC-3B3037181487 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 4/08/2021, at 2:57 AM, Eliot Lear wrote: >=20 > Hi Mirja, >=20 > On 03.08.21 16:26, Mirja Kuehlewind wrote: >> Thanks Eliot. However, just catching with the rest of the thread (on = sec 4.2), this seems obsolete as we seem to tend to provide less level = of detail, which I support. >=20 > You asked a very legitimate question. I am not actually sure that I = have answered it correctly, by the way. Others should chime in. If = you asked it, someone else who is not here today and does not yet = understand our processes and who may hold the reigns some years from now = may well ask the question as well. Let's therefore make the distinction = between more normative text and more explanatory text. One can = absolutely go overboard on both, but there needs to be enough. The reasons are twofold 1) The LLC manages the contract and this is a = contractual matter; 2) Whenever this group has discussed giving the RSAB = this sort of role there have been multiple objections. Jay=20 >=20 > To this end, I would suggest that when we are close enough to done, we = will need to find some fresh eyes, along the lines of a shepherd review, = to see if what we have written makes sense to others. More on next = steps, tho, in a separate message. >=20 > Eliot >=20 >=20 >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future --=20 Jay Daley IETF Executive Director jay@ietf.org --Apple-Mail=_C9EFC9ED-D3C6-4B02-89CC-3B3037181487 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On 4/08/2021, at 2:57 AM, Eliot Lear <lear@lear.ch> = wrote:

Hi Mirja,

On 03.08.21 16:26, = Mirja Kuehlewind wrote:
Thanks Eliot. However, just catching with the rest of the = thread (on sec 4.2), this seems obsolete as we seem to tend to provide = less level of detail, which I support.

You asked a very legitimate question.  I am not actually = sure that I have answered it correctly, by the way.  Others should = chime in.   If you asked it, someone else who is not here today and = does not yet understand our processes and who may hold the reigns some = years from now may well ask the question as well. Let's therefore make = the distinction between more normative text and more explanatory = text.  One can absolutely go overboard on both, but there needs to = be enough.


The reasons are twofold 1) = The LLC manages the contract and this is a contractual matter; 2) = Whenever this group has discussed giving the RSAB this sort of role = there have been multiple objections.

Jay 


To= this end, I would suggest that when we are close enough to done, we = will need to find some fresh eyes, along the lines of a shepherd review, = to see if what we have written makes sense to others.  More on next = steps, tho, in a separate message.




Eliot



--
Rfced-future = mailing list
Rfced-future@iab.org
https://www.iab.org/mailman/listinfo/rfced-future

-- 
Jay Daley
IETF = Executive Director
jay@ietf.org

= --Apple-Mail=_C9EFC9ED-D3C6-4B02-89CC-3B3037181487-- From nobody Tue Aug 3 20:12:05 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 202363A3EFB for ; Tue, 3 Aug 2021 20:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 vZ2QDZbw9Fgz for ; Tue, 3 Aug 2021 20:11:59 -0700 (PDT) Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (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 68C7C3A3EFA for ; Tue, 3 Aug 2021 20:11:59 -0700 (PDT) Received: by mail-pj1-x1033.google.com with SMTP id j1so1006116pjv.3 for ; Tue, 03 Aug 2021 20:11:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=EZfYDirZ0pP7mCQQ1DEoH+E7qSH/ZsMQ9qIo5R9hpdA=; b=hVilDFHP2OLqJLoJw4M+8c5oxYGXZNwG1QNbhh7O3UrwCWI2TyR6MaOCYsDkRitmXl RxpgOrCXdd1rUmhaYzLAb+v9deE0h7Dow7Z90WQfluivlA2sVJenrpwQf9wA8kXFnavJ mqt51WLvBU1VBZsFkoDfdQBYqtU2ar4tYZ/oZ3sYjN2EYmC26SoG176MCXL33Ul6VobF l8i49skVcd+M6QhOoBAVDuFMTa4U3e4DSZfykYOFOqA0MN8mhWgeriX5Tp0QST8LX9NP hmwrCr3w+15gM9XTDU/eyNWUmfIa45uUbO0/kTQDETFTNj6D7Bb+0npVbpdk24UsBlnw i3MQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=EZfYDirZ0pP7mCQQ1DEoH+E7qSH/ZsMQ9qIo5R9hpdA=; b=oyszW7e7ip4asmblDX4rvelaaQvCqNy57hryyK4k+kCp78CRDIV9+5F7Aj6ChT4WaZ AZZJERExSsKr/Uky+bn0SvtRnu6e/kmsgeCBQEQhUCgb1ZuVjRrdrpRvXive2xktZiLV I5qs7idbQEdNSrECmzhgD4bXd9Vuk599nfiPZhfrIGs8AKzHqvJA2Lb7Hp59Jg46kC2u /CZuf426pqGxzTtu3y8yktUILgiM7qd+s/JGvnyg1Vt0hb5HTVfhqqaODB9isP8QdoA3 vgDGAX12VQQ0juReyd/HIyMUXOkO5fIgdKVL18RTK2ZIrmRAJ6uX77esDjgoCFp5CsFU NTAg== X-Gm-Message-State: AOAM530K/Xz9O/GnISAqv6ErFaoIunDtrlXGCI9h2ecALnT9RPOxQEl0 7Y7m6Pg/S0bx03FEK2pL0dE= X-Google-Smtp-Source: ABdhPJwGo2pisH0+fUSRPjFgaU/rJEpYJND9D68i2lTh3DlPz9O1p/FPTe+K8U2nAObZZBH/LytGyw== X-Received: by 2002:a05:6a00:1141:b029:396:d224:160a with SMTP id b1-20020a056a001141b0290396d224160amr25059526pfm.34.1628046717286; Tue, 03 Aug 2021 20:11:57 -0700 (PDT) Received: from [10.100.8.98] ([58.84.227.247]) by smtp.gmail.com with ESMTPSA id i1sm622565pfo.37.2021.08.03.20.11.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 03 Aug 2021 20:11:56 -0700 (PDT) To: Jay Daley , Eliot Lear Cc: "rfced-future@iab.org" , Mirja Kuehlewind References: <0bdad87d-3bec-f3c7-4493-71233dc54300@lear.ch> <3D4DACBC-A360-4952-8685-AB43CA60CBC8@kuehlewind.net> <03554458-031e-c99d-6dd9-d126d8c74b78@lear.ch> From: Brian E Carpenter Message-ID: Date: Wed, 4 Aug 2021 15:11:51 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Consensus check: Issue 55 Suggestions for ongoing evaluation of RS[EA] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2021 03:12:04 -0000 On 04-Aug-21 11:58, Jay Daley wrote: >=20 >=20 >> On 4/08/2021, at 2:57 AM, Eliot Lear > wrote: >> >> Hi Mirja, >> >> On 03.08.21 16:26, Mirja Kuehlewind wrote: >>> Thanks Eliot. However, just catching with the rest of the thread (on = sec 4.2), this seems obsolete as we seem to tend to provide less level of=20 detail, which I support. >> >> You asked a very legitimate question.=C2=A0 I am not actually sure tha= t I have answered it correctly, by the way.=C2=A0 Others should chime in.=20 =C2=A0 If you asked it, someone else who is not here today and does not y= et understand our processes and who may hold the reigns some years from n= ow may well ask the question as well. Let's therefore make the distinctio= n between more normative text and more explanatory text.=C2=A0 One can ab= solutely go overboard on both, but there needs to be enough. >=20 >=20 > The reasons are twofold 1) The LLC manages the contract and this is a c= ontractual matter; 2) Whenever this group has discussed giving the RSAB t= his sort of role there have been multiple objections. And 2) follows directly from 1). Either the LLC is the contract manager, = or it isn't. The RSAB is not in the management hierarchy; the A stands fo= r Advisory. Brian >=20 > Jay=C2=A0 >=20 >> >> To this end, I would suggest that when we are close enough to done, we=20 will need to find some fresh eyes, along the lines of a shepherd review, = to see if what we have written makes sense to others.=C2=A0 More on next = steps, tho, in a separate message. >=20 >=20 >=20 >> >> Eliot >> >> >> >> --=20 >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future >=20 > --=C2=A0 > Jay Daley > IETF Executive Director > jay@ietf.org >=20 >=20 From nobody Wed Aug 4 03:10:53 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED3553A11E1 for ; Wed, 4 Aug 2021 03:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 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, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch 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 Ex1ABxy1Ks30 for ; Wed, 4 Aug 2021 03:10:45 -0700 (PDT) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C4AE3A08C1 for ; Wed, 4 Aug 2021 03:10:45 -0700 (PDT) Received: from [IPv6:2001:420:c0c0:1011::b] ([IPv6:2001:420:c0c0:1011:0:0:0:b]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 174AAfDS187336 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Wed, 4 Aug 2021 12:10:42 +0200 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1628071842; bh=eqQWWOyVHORNkYor7jVIibKSS+jXryzG4rtkAllRNGk=; h=Subject:To:References:From:Date:In-Reply-To:From; b=iPAoq1bH9aUXuguYxrBNgS30p/1kabPo0cCOzmelyfwEvb/rxNPvGQe1tpqAXNKKC 9WY0qwiAiwHOfR04kplNfADJ3VHxw3V31MynsvG4nl9yx9u+iCpJMiDAoX3lUrN7iT sY1zXzJZkZSak28ccpYfQXjMjkVUQQTfH4MIC6oo= To: "rfced-future@iab.org" References: <608f49c6-5e3e-637a-482d-15e48298beb9@joelhalpern.com> From: Eliot Lear Message-ID: Date: Wed, 4 Aug 2021 12:10:39 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <608f49c6-5e3e-637a-482d-15e48298beb9@joelhalpern.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5cyex70evJ2yd3CpWNilIVXzbEsa4r6Yb" Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2021 10:10:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5cyex70evJ2yd3CpWNilIVXzbEsa4r6Yb Content-Type: multipart/mixed; boundary="CqRpwmEY4AgJZQIAU3Ejp5RzpmAI6RjbZ"; protected-headers="v1" From: Eliot Lear To: "rfced-future@iab.org" Message-ID: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? References: <608f49c6-5e3e-637a-482d-15e48298beb9@joelhalpern.com> In-Reply-To: <608f49c6-5e3e-637a-482d-15e48298beb9@joelhalpern.com> --CqRpwmEY4AgJZQIAU3Ejp5RzpmAI6RjbZ Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Unless people voice objections, I'll ask Peter to please use this term=20 in the next revision of the draft. Eliot On 03.08.21 00:41, Joel M. Halpern wrote: > I can live with this.=C2=A0 (I am bad at naming, so my actually liking = > something is largely irrelevant.) > > Yours, > Joel > > On 8/2/2021 6:13 PM, Martin Thomson wrote: >> On Tue, Aug 3, 2021, at 01:57, Eliot Lear wrote: >>> I believe someone offered RFC Series Consulting >>> Editor.=C2=A0 Is that something that would work for people? >> >> WFM >> > --CqRpwmEY4AgJZQIAU3Ejp5RzpmAI6RjbZ-- --5cyex70evJ2yd3CpWNilIVXzbEsa4r6Yb Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmEKZ58FAwAAAAAACgkQh7ZrRtnSejPZ kQf/UNf8STmNmB34cXUcLfETHfYP/GrDLRGc+ialKxHjmRJECH0Y9929p9oD3eP5oCPiiGNyrm14 vvQFAE0HtgbBXvp4uXlCLGqPgR29dEfzvOLMSeSe9JggjN+CzPouwtR4KaKze4zNx1HebcfYet0F jmzTahslRDbyheGyDfbKAybJAB75+pmuZPCnIvwUdoZpHPDM3JRjs4KLzKcXPzxRak+GJGznoUU4 3G5cd8LGFkoyR0p4975LvChqK9NVDPaOnZtAOidxsfoUynvGa/EFaA59dSXGZZ9JghgerHaONVID yBkpmt8WBsUCAoCtLKoIeLrOVS4Cq1QXArlxuzClaw== =2UE9 -----END PGP SIGNATURE----- --5cyex70evJ2yd3CpWNilIVXzbEsa4r6Yb-- From nobody Wed Aug 4 03:53:37 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B84E43A12FE for ; Wed, 4 Aug 2021 03:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch 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 z-wM8o0whstz for ; Wed, 4 Aug 2021 03:53:30 -0700 (PDT) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E71653A12FD for ; Wed, 4 Aug 2021 03:53:29 -0700 (PDT) Received: from [IPv6:2001:420:c0c0:1011::b] ([IPv6:2001:420:c0c0:1011:0:0:0:b]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 174ArPFu187751 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 4 Aug 2021 12:53:26 +0200 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1628074407; bh=+jkfo350ds6WjDVkQo9UPBNJ3cfuCzx4X4pwUbAKbMI=; h=To:Cc:From:Subject:Date:From; b=V3alTmBdMq9BvydJUO04wt/tjO8XeBCg8+kg8NFr9ajSM++kdIey/RDAKliFiHD3l isj7aUIGhVnfOgIeuUiSI/gWzhjD8Co6mRAWwtSjNOaW2gJNpvtEMp8c5+Bl/z+5XO BmT3I08QrezJTJx34eMLNgbEBHjgb8eH7KJHuYvM= To: EKR Cc: "rfced-future@iab.org" From: Eliot Lear Message-ID: <3d76e434-791e-d117-ce86-e4c49e3e9b37@lear.ch> Date: Wed, 4 Aug 2021 12:53:24 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="TCPlteD1s1QHWerhYIp2PiXuyW4MUxrfn" Archived-At: Subject: [Rfced-future] Issue 69: Who can adopt WG items? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2021 10:53:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TCPlteD1s1QHWerhYIp2PiXuyW4MUxrfn Content-Type: multipart/mixed; boundary="DIEn7PexZ6M71Rmw5g0HMCR2EOJ9ox0mF"; protected-headers="v1" From: Eliot Lear To: EKR Cc: "rfced-future@iab.org" Message-ID: <3d76e434-791e-d117-ce86-e4c49e3e9b37@lear.ch> Subject: Issue 69: Who can adopt WG items? --DIEn7PexZ6M71Rmw5g0HMCR2EOJ9ox0mF Content-Type: multipart/alternative; boundary="------------A35440EB1F67D9C6B092D548" Content-Language: en-US This is a multi-part message in MIME format. --------------A35440EB1F67D9C6B092D548 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi Eric, In Issue 69, you wrote: > 2. If there is sufficient interest in the proposal, RSWG may adopt > the proposal as a draft proposal of the RSWG, much the same way a > working group of the IETF or IRTF would. > > As has been pointed out previously, 2418 is a bit vague on how=20 > adoption happens. Do we want to be vague here? > In light of the conversation around the chairs supporting working group=20 consensus, do you believe there is still an issue with the above text?=C2= =A0=20 If so, do you have suggestions as to how to remedy it? Thanks, Eliot --------------A35440EB1F67D9C6B092D548 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Eric,

In Issue 69, you wrote:

  1. If there is sufficient interest in the proposal, RSWG may adopt
    the proposal as a draft proposal of the RSWG, much the same way a
    working group of the IETF or IRTF would.

As has been pointed out previously, 2418 is a bit vague on how adoption happens. Do we want to be vague here?

In light of the conversation around the chairs supporting working group consensus, do you believe there is still an issue with the above text?=C2=A0 If so, do you have suggestions as to how to remed= y it?

Thanks,

Eliot

--------------A35440EB1F67D9C6B092D548-- --DIEn7PexZ6M71Rmw5g0HMCR2EOJ9ox0mF-- --TCPlteD1s1QHWerhYIp2PiXuyW4MUxrfn Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmEKcaQFAwAAAAAACgkQh7ZrRtnSejOQ 4QgAzHnkTDPdQJY8QKvmsUcrEmQcfucEPDZVDj2dX5DZNyA2gA/byrqYfKtsAGI2sygEqV39X4h8 RGpv9xsq1BjdNVsHbuSKvUd3mcdw5FuoaVJtRusZAJMa+E72SutVWldWCy8tLQB5tekr7dpy9yfK yNk4j42mqpiW3u4frrMvTf1K+pPoZKfro78Xz8uklAUoaQDneZ5MvLkfZvyUscYeSmoOeNQZdatZ zAySMRJYHHyak2UiR13DBIgBQd32lQucPlbEKJmwgk0s4Yact37A60vreAUVeFVMQ7SuWI2UekaD jr6CIZpeobBmYySeZBTITKOLVRAg2LznkZunqvGnWw== =pstg -----END PGP SIGNATURE----- --TCPlteD1s1QHWerhYIp2PiXuyW4MUxrfn-- From nobody Wed Aug 4 17:05:24 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F2C3A09E0 for ; Wed, 4 Aug 2021 17:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=k87l0OVM; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=NrYp6qWY 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 yU3ayVlwkokL for ; Wed, 4 Aug 2021 17:05:17 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D20553A09DF for ; Wed, 4 Aug 2021 17:05:17 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 84900320098E; Wed, 4 Aug 2021 20:05:15 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Wed, 04 Aug 2021 20:05:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=7 c3rFJMjSBBKi3+iXMCWV4WW5pnZ/RM3pfBLo66Z1D8=; b=k87l0OVM7NoN7mU4/ 6MUlaMW8kuEH2lZMrkoRImjcOpudq+ZS3ug9rREKbXJTA15QgkSiYewTp/9xybP/ A1ppIWcGpbxjzJQlGoNzMn0fhTza+q7yiPR59HKAdEL1rnnVGcwoCjSBm+if7yw+ tlrvrff+X4qSBLzME0AHH/GaRHEJJAi+QjjEcbAhBzG9XWlDI14TBHX7KrJHP1E0 7jt+e0lMNYZLh+CPwG8jnM6EngXx7kia3fnIL6fIURHhpJ6yoCe+ROloHwc+h72P V1eJtEE0gIwjxLge93+T2Ta50sV5qRzoROplEjRP8TSK7w2hNhvQOyAZZPYR1med Fx4Rw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=7c3rFJMjSBBKi3+iXMCWV4WW5pnZ/RM3pfBLo66Z1 D8=; b=NrYp6qWYyL1PSNKsiTtujN4Tr+wDfLZt77UKzoYCIFOoXd9X5JqfhQ5E/ mJZFL2XrveXTBRc3ruM76xh948+yVlms5m8q0/nXsKK3I8sMAGLSchdn/awGV94g N1CeEAESX5Z1aTBWZHxDd5TW2Ufvkdddj6bi8BoQw9t1VOQDfGyj2FpT1YQaYahv Lva7TvXdwF+FpJtyfNnfmIg/Zq3SrBGeUzepnR+ju4/cgds/gK1nvBIK1AqKRPVq 6C3Dys3fPynzZQVKbPMXvUJM2KTLwFhJICDOXvlYG4EhlkAOWgFF3OS0/16JdEVj CPnesLxUYvO4by3tZ4dklZR47/uQw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrieekgddvjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepuedtkefhtdfggfejjeegkeevheefhffguefgheefgfegkefhiedtgeduvedufeei necuffhomhgrihhnpehirggsrdhorhhgpdhmnhhothdrnhgvthenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 4 Aug 2021 20:05:11 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Mark Nottingham In-Reply-To: Date: Thu, 5 Aug 2021 10:05:08 +1000 Cc: "rfced-future@iab.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <608f49c6-5e3e-637a-482d-15e48298beb9@joelhalpern.com> To: Eliot Lear X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2021 00:05:23 -0000 I can *just* live with this. I would be much happier if we expunged the phrase 'RFC Editor' from our = documents (progressively, of course), as it's going to cause confusion. Cheers, > On 4 Aug 2021, at 8:10 pm, Eliot Lear wrote: >=20 > Unless people voice objections, I'll ask Peter to please use this term = in the next revision of the draft. >=20 > Eliot >=20 >=20 > On 03.08.21 00:41, Joel M. Halpern wrote: >> I can live with this. (I am bad at naming, so my actually liking = something is largely irrelevant.) >>=20 >> Yours, >> Joel >>=20 >> On 8/2/2021 6:13 PM, Martin Thomson wrote: >>> On Tue, Aug 3, 2021, at 01:57, Eliot Lear wrote: >>>> I believe someone offered RFC Series Consulting >>>> Editor. Is that something that would work for people? >>>=20 >>> WFM >>>=20 >>=20 >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future -- Mark Nottingham https://www.mnot.net/ From nobody Wed Aug 4 18:13:36 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37D403A0DB5 for ; Wed, 4 Aug 2021 18:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.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 SZn1Tjr0QQI7 for ; Wed, 4 Aug 2021 18:13:30 -0700 (PDT) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-eopbgr1400118.outbound.protection.outlook.com [40.107.140.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CA723A0DB4 for ; Wed, 4 Aug 2021 18:13:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mHtULsWaGnfA1XDU7R5/pknOGrygrIZbnON1b8rN2N7hJvArn9dAc3RzRGH/sY0MMPvED74MZvpk1bd0WoynpNjjcFNieBXwuLKK1w0pN9vcSWwtY2echjyjyZv6WZp2MBLY7Ax6CCOy2rnJNkhi6tmtpCPe02+WR4LTNdqtZlgLqspkNo4+jR55knDJkYZ80xB3NoMyniHXevvJCJvtbzVBk14hCHP1504YlYa+BTxO3kFzwiugwjvQ/wt6gC++AyfrFlLk/l6+r+A2DISqiOel96C1d12RkpJaA32HkksWG/Z/USQjrEctdK0ih+KxR/8ockLoJicR/j35xa8iRQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qEkkOAHd+2pvqOL1NzZphIY5H3aMwltCChbp6kUOlz8=; b=BbVjJ3CS/mhkYRctoFWWNuoRU81qyAXpxWoDcvHCCWsIvDD0FGAbCOx7l+896X9BBvwBIetiYdZP8CWhh/6z6/mEbDEkfHRwD4y+bXMbfZbSUTQjqHQS3edXubBGGDY66TtWrzjHA2cZWyO8IMgGxbaN6GmjmLTwqQysh6yHar3UanOVqeM7Py/TAJiQoi5CzvKpuwr2ZVDOoLi5iS9mzaLWSAS693pacrXSQklICHYZ454W1n+sUK0wT922l+Bv0UoBDvG9COwIS1aMvfz5RIRVAS4PU9Bd1NJRy0qq2/FK0Gz8nbEGkBGQ2Rq2KZqkvjp/xqXpm10XsGjJZvVY+Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=it.aoyama.ac.jp; dmarc=pass action=none header.from=it.aoyama.ac.jp; dkim=pass header.d=it.aoyama.ac.jp; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector2-itaoyama-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qEkkOAHd+2pvqOL1NzZphIY5H3aMwltCChbp6kUOlz8=; b=VgWzVDuQip1K65P7CUHWLCrP77lxJf4BnGmt9aMtS33pY1V7e8fJ0Hf+CurOcoN4BAqBcKIcJY+kNZ9MCX+Lf/h8ehD5au+ODPLjLKRNVeiBSdcC1hzj7xlDDzuZB0GetRPgkYeQS/O0UvilrrbJ/5kxOGPXmyYD3Fmb/9Yot1A= Authentication-Results: iab.org; dkim=none (message not signed) header.d=none;iab.org; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) by TYCPR01MB5839.jpnprd01.prod.outlook.com (2603:1096:400:45::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4373.21; Thu, 5 Aug 2021 01:13:25 +0000 Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::11f6:52bc:8bf7:d82b]) by TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::11f6:52bc:8bf7:d82b%6]) with mapi id 15.20.4373.026; Thu, 5 Aug 2021 01:13:25 +0000 To: Mark Nottingham , Eliot Lear Cc: "rfced-future@iab.org" References: <608f49c6-5e3e-637a-482d-15e48298beb9@joelhalpern.com> From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: Date: Thu, 5 Aug 2021 10:13:20 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-ClientProxiedBy: TY2PR01CA0014.jpnprd01.prod.outlook.com (2603:1096:404:a::26) To TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.5] (114.185.21.49) by TY2PR01CA0014.jpnprd01.prod.outlook.com (2603:1096:404:a::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4394.16 via Frontend Transport; Thu, 5 Aug 2021 01:13:24 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: c4d0359e-58ef-49c1-a96b-08d957ae3979 X-MS-TrafficTypeDiagnostic: TYCPR01MB5839: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: dybmDKz3vEbFBmk8WU7P28idtz+x1UY92M5bwSwrcY7lqvNFVBhqfbcVdgUA7H6UMEtumRAN4LhxI+QrOabNnzE3hnZxycvrz+9tbQcaujn0KDpthHnvcJY8zee+E/mVVAvvzoZPOBJcEsbyMvCEriDtcZBON/e2TC6u7bG9fjJyqAbW7EUbO21oLIqzGvMMNd5NmlGv95SvAc+YdA8V2JdCC20kJvbWj5EB9YpPdi872DPmPhLTVNdVLVka1XsrtRLf64c6UP+QV4Y0c+UpXY9EKRWVT9svrXtf1TF3+QNr/8ryRZhKiXyClzC13q4d+kMgkMKT8FcUwRLbnD5Am5LlPZoVhZkmhRNyXlzeCCs7kDlfsbk7Egb5abx89XkdVo362DdyTMfL2i3qDmAQlCJo6NDyMRaHkPwhvTc1/FIDywp90mYSNS8DSqp0tnzw1I4lDOaXQLGdpoEAqg5PHZSM2nJsNm69PDtz14HCz8pQPpRwI35jvFd2J9on50EFwl7NptPPp7rHxLRlMPOyer2NcsnGSRf3pk4/sJAuYofTaoLs/syH3F5HkmPCMzAqr/6R8/WK4dcaDLkSDgBb1hZkQmZrFJZHZq0xMEPqscCcC02SWdrxrZ5bgRo3Z2UWr9qD/872vZt4TF9XKBJB6rCAUqoqDe2vtbAqq5g8ogvy0bd4Rb8Brfcihsy9cC5LeO1P3WS4J3WnuGb0+fKWSMVqSr0qdZz0iCTbnNUZ7Nv4Z+c1vVnK3iWL0zkmWxeo2BujwjiKW6PhYMZBggI1gyGUQPUbHixFpcszTP+4ycu1yLNS8FNWIbRlLJDuAR9tUf9ovYamDJsLkzwL2ybDEA== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYAPR01MB5689.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(376002)(396003)(346002)(366004)(39830400003)(786003)(5660300002)(8936002)(66476007)(66946007)(26005)(956004)(52116002)(53546011)(66556008)(36916002)(110136005)(2616005)(4326008)(6486002)(186003)(316002)(16576012)(86362001)(38350700002)(966005)(38100700002)(8676002)(478600001)(31686004)(31696002)(2906002)(6666004)(43740500002)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Y2FBTUZnZVhmQ3ZJVG9ZT044a05QRHNtMS8vRTkvUCsydnpvZjl5MDU0OW5w?= =?utf-8?B?N3FFNjJHdGl4ek1YTjhQNGcyamFvTDRxTzB6cnAzbDFzaFJqMnpMZXVUY1FE?= =?utf-8?B?eS9WbXF4a2xLc2RXbTRxZ241dVd4MjU3QVhDM0ZQeVRUWU4rVDFRTGpEdXN4?= =?utf-8?B?b3pHUmJ2YjM5ODBoTEJGKzdOT1lqanE4RHNZNEtucm5oWU01QnRLelk1WHdh?= =?utf-8?B?TmhhR2JuMzFDZllLUmdjVFN0czZpdjE5NVJQOUhhL3E5ZDNROXNTRWcydExh?= =?utf-8?B?RjVDQmZmVmxlRnd0SlBqWGxJOHRhVzM4aUExQmV0UXZ3RmZBRGR4NUFUbWto?= =?utf-8?B?Z1pJQmR3U1phS2tEakc5ei9KU1lINWdDQ0dDQ3VYL2tqZUltMFFWZlNLRHoy?= =?utf-8?B?cklycStNYTB6SStDbk5ydm4zWFJSb1k3aFpvckR1b1l1TytrbjFwb3hmcTYx?= =?utf-8?B?dzFtSm9SeVpBbWdNNm1yaitsRFNwaHM4MTRlY3NqS3JpdlJvb0NlZXNoS01y?= =?utf-8?B?UlZKbi9iK2lHM0JLNEE0VjdubW9CTmRtN1VLMVJsYmJRbUZSSEZVQkFkK3l0?= =?utf-8?B?UGkxNXp2UmVZRjg3R3YxdCtZQysxNmY1UHc2bmZxK0E5MjkzMmxMa3grb3ND?= =?utf-8?B?bURPanI4MFUzRnY5dmRFcXVJSEdHblc2b0I5NG1KcGtVQjNkQXhnTVgrN3Ba?= =?utf-8?B?RTJqclRId09MQVo1b0dyaDkzWjBHM25XME1FS2dMaktubDlneUlxeGQybFc1?= =?utf-8?B?RnpLN2hMMW1YTys4NlRZdXVWL0xSVTRHNjRjaXp5cDdiMUZseFFUL0NCK2t3?= =?utf-8?B?akMxUmxIaGNJbEcreFlqR2FXWjNubzU5SUJ3U3FmMHVubmVJbnlOOGJMMTk3?= =?utf-8?B?TG1IaVJJS09sYkhkWEJ5MEM2TDF6aE5URDQvUDBsZHlLbW8yMnFRYXRVYVlD?= =?utf-8?B?T0tLcFdtb0dpWWdEUXV5bTNVWU4zZjluMGoyK1VWTlhYQ3UycVd3dUhBUDFa?= =?utf-8?B?SW44TE50MmhQc25JSWhlNXJsMG1FekMvcmRUTkdKR3RPOXVIYTl0NW1zM3hF?= =?utf-8?B?M1IrNmJOMDdhNHFMUjBxWit0QUgyK213YUMzWllvMGJ1dVlNck1uQ3c0ZUh0?= =?utf-8?B?VkR3eTBEWWxWempxeGhKYW11K3JnQzI4b2RCbDNXY0l0WUJ3azI1TXRPbkR1?= =?utf-8?B?RHl0MkxCTXBjcFhyUmk2TWJRRVlwK2ttN0FaS1lTR3VSd0NnK3Awc0ZhcDNw?= =?utf-8?B?YnNGZWp6VkFiWUdEeHFGQ3N2aVZzSTBSOTg4K2d4VTFjSVBtdGZRTndWbDEw?= =?utf-8?B?aXdnUVM1VGlLNVJPY3dMMTMrK1NxNGFjQjFUQjJjM0ZDZTd6MEJnbUViSTlm?= =?utf-8?B?eUQ1RCtHWE1OTlRUR2ZYVEo2dTNGN2x2dXQ0Q0FWSXFvK0RhR2J1RjlZSnJj?= =?utf-8?B?aXhpVUllVCtSSjNOOUw5cmtRbzJrbnBJSWhMOEs2OUpBNWVRQ3hma1o2VTJm?= =?utf-8?B?bnFUdGxLdWdrbnBwZXpMbCtqN3A0bEVoanlLUWMxMnplVVJnbDdaMU9vQU9W?= =?utf-8?B?eG5STUE4Q3I0UVVRWC9HY1JZM1ZXTGo2R2J3SENERVpVNEc3Q0NaRWRQaVJF?= =?utf-8?B?RVRUY1JuaCs2L2tmWFdzMVNSYVFKVWx3WEJFandnQ216UWNjNndBTWFLN2lD?= =?utf-8?B?YUNlYTVRWE1ydzZpczBOaW1yK0hQeUlQd0JyeG91eWVMTHMyNTcxT2lSRnI5?= =?utf-8?Q?GdAIPk1cMRdCCaVrITVlASnfkNUkkWRmdFDmQtd?= X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: c4d0359e-58ef-49c1-a96b-08d957ae3979 X-MS-Exchange-CrossTenant-AuthSource: TYAPR01MB5689.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Aug 2021 01:13:25.1240 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: e02030e7-4d45-463e-a968-0290e738c18e X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: c9/1ggsh98IwHKoyaeg/R62L2RToZF3UqMpA5RKN2o3sfW/7TF4RrRCAW2G7yWiFRLpFRbiGVBkqYbw1Uot/qw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYCPR01MB5839 Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2021 01:13:35 -0000 On 2021-08-05 09:05, Mark Nottingham wrote: > I can *just* live with this. > > I would be much happier if we expunged the phrase 'RFC Editor' from our documents (progressively, of course), as it's going to cause confusion. This seems to be a separate issue. If we no longer have a "RFC Editor" *function*, then the title "RFC Series Consulting Editor" may not make much sense anymore. But if we'd start expunging the phrase "RFC Editor", what would you replace it with? Regards,   Martin. > Cheers, > > >> On 4 Aug 2021, at 8:10 pm, Eliot Lear wrote: >> >> Unless people voice objections, I'll ask Peter to please use this term in the next revision of the draft. >> >> Eliot >> >> >> On 03.08.21 00:41, Joel M. Halpern wrote: >>> I can live with this. (I am bad at naming, so my actually liking something is largely irrelevant.) >>> >>> Yours, >>> Joel >>> >>> On 8/2/2021 6:13 PM, Martin Thomson wrote: >>>> On Tue, Aug 3, 2021, at 01:57, Eliot Lear wrote: >>>>> I believe someone offered RFC Series Consulting >>>>> Editor. Is that something that would work for people? >>>> >>>> WFM >>>> >>> >> >> -- >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future > > -- > Mark Nottingham https://www.mnot.net/ > From nobody Wed Aug 4 18:35:46 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 652DC3A0E97 for ; Wed, 4 Aug 2021 18:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=TACQbbXx; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=JmEefcUZ 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 Nrucj4A37Ygu for ; Wed, 4 Aug 2021 18:35:39 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03D303A0E96 for ; Wed, 4 Aug 2021 18:35:38 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 3B42B3200936; Wed, 4 Aug 2021 21:35:37 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Wed, 04 Aug 2021 21:35:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=0 MMHl3BxCMcZNSobBSOz1GDddY25/w4x9S0VYF0Ocmw=; b=TACQbbXxBr6st92BX Lf++y8480dhoeKwohShUKgHqrRGW2ujrju71QZv0I+sA+Zyx2G11SmWM6RB8N7OU FB8ovrnO/hwXf7fv/1r8NQWhYVZ7C6COkDn7evBSCebESk/ku5kuoFMLb/t9/ESU Hs78pZyBK3nH72xJ87ZfIdfEPs/JVhR23oxqGF1wQYt5hsz7IRbPj5GZQRH9tU0Q eiabY3xfqdR3D0Lz6EWBJfFR2AErOSF7ChFK9SAZiS3dbJuSwVQHox8s9239ikD4 OPyxca4WbvJ8yQhtypcqFet7g0VaCS2V3pMj5RcXZNtlU77W3OpIx/c8N/hMNTxV HZCHg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=0MMHl3BxCMcZNSobBSOz1GDddY25/w4x9S0VYF0Oc mw=; b=JmEefcUZypmcaHY3+1ChaIO1anaDosVC3hysMnyyxIb3OsemLNvHW++vL nOq/kPzhhaBYSqs5SXvD5KxvuGIDAfw5WS2kpSAUeyKXkXzwY+q1SQ4HGkTeEe0W iMMYBZ4nrrga0gyPYuy7o+SDqW3jNIby3UPQKbsaah4r/iFUX0vH1JNP/sVCjj+i a3lh9iuGOEca9OZMWhBFDMVH+jTj/AqxxBkfb6qpQA6a4gnPoQWq2dzuquHe6ZK4 5wj5VxFPnzFTvxXYslzIxdn9gdyXLMhvLdnqCS8jqNyWSP0Vg1vj2RJRFNK19xes f1PDNDdh56RJQtWgc8ZZxUhiGdZIA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrieekgdeghecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnheptdelveetkeeivefgjeekvdelfefgtddtkeevvedtgfffveeutdefueefhfejgfel necuffhomhgrihhnpehrfhgtqdgvughithhorhdrohhrghdpihgrsgdrohhrghdpmhhnoh htrdhnvghtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhho mhepmhhnohhtsehmnhhothdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 4 Aug 2021 21:35:33 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Mark Nottingham In-Reply-To: Date: Thu, 5 Aug 2021 11:35:28 +1000 Cc: Eliot Lear , "rfced-future@iab.org" Content-Transfer-Encoding: quoted-printable Message-Id: <010AEB19-A39C-46BB-8BBF-5BBA4B4B11C5@mnot.net> References: <608f49c6-5e3e-637a-482d-15e48298beb9@joelhalpern.com> To: =?utf-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2021 01:35:45 -0000 Let's map out the space. Currently, we have a couple of things that are = well-defined: * RFC Production Centre -- the people who actually do the editing * RFC Publisher -- other bits (e.g., web site, announcements, legal = verification) We also have: * RFC Series Consulting Editor -- the person we've been talking about a = lot. *Not* in charge of the entities above. * IETF Executive Director -- contracting authority for the RSCE, RPC and = RP. * RFC Series Working Group -- where the community/communities come = together to figure out things about the series. * RFC Series Approval Board -- oversight of the RSWG, representation of = the streams. If we were to draw a diagram around bits of this a la RFC8728 Section 2, = I'd be very interested to know what should be inside a box labeled 'RFC = Editor'. Looking at draft-iab-rfcefdp-rfced-model-00, 'RFC Editor' is used = consistently to talk about the set of functions that collectively = manages the Series. Calling everything happening the 'RFC Editor' while = also having someone whose job title ends in 'Editor' is confusing and = arguably misleading to those who aren't steeped in the details of IETF = minutia (an ongoing problem, especially for the one part of our work = that's actually exposed to non-IETF people on a regular basis).=20 The problem, of course, is that we've invested a lot in = 'rfc-editor.org'. Even if we plaster 'The RFC Editor is not a person' in = red on the top of that web site, the nature of this role is still going = to be confusing if it ends with 'Editor.' So actually, I retract my 'can live with this.' I haven't seen any = evidence supporting the notion that people will refuse this position if = it doesn't have 'editor' in the title; that seems frankly petty, and if = someone were to make it a sticking point for the position, I'd think = carefully about whether they're appropriate for the role.=20 Eliot, consider this an objection, please. If we're going to have 'RFC = Editor' refer to the function, it should be clearly and absolutely = delineated from the component bodies and people. Instead, I would suggest 'RFC Series Consulting Expert' -- same acronym. = Much clearer, and still looks nice on someone's resume if that's truly = important. Cheers, > On 5 Aug 2021, at 11:13 am, Martin J. D=C3=BCrst = wrote: >=20 > On 2021-08-05 09:05, Mark Nottingham wrote: >> I can *just* live with this. >> I would be much happier if we expunged the phrase 'RFC Editor' from = our documents (progressively, of course), as it's going to cause = confusion. >=20 > This seems to be a separate issue. If we no longer have a "RFC Editor" = *function*, then the title "RFC Series Consulting Editor" may not make = much sense anymore. >=20 > But if we'd start expunging the phrase "RFC Editor", what would you = replace it with? >=20 > Regards, Martin. >=20 >=20 >> Cheers, >>> On 4 Aug 2021, at 8:10 pm, Eliot Lear wrote: >>>=20 >>> Unless people voice objections, I'll ask Peter to please use this = term in the next revision of the draft. >>>=20 >>> Eliot >>>=20 >>>=20 >>> On 03.08.21 00:41, Joel M. Halpern wrote: >>>> I can live with this. (I am bad at naming, so my actually liking = something is largely irrelevant.) >>>>=20 >>>> Yours, >>>> Joel >>>>=20 >>>> On 8/2/2021 6:13 PM, Martin Thomson wrote: >>>>> On Tue, Aug 3, 2021, at 01:57, Eliot Lear wrote: >>>>>> I believe someone offered RFC Series Consulting >>>>>> Editor. Is that something that would work for people? >>>>>=20 >>>>> WFM >>>>>=20 >>>>=20 >>>=20 >>> --=20 >>> Rfced-future mailing list >>> Rfced-future@iab.org >>> https://www.iab.org/mailman/listinfo/rfced-future >> -- >> Mark Nottingham https://www.mnot.net/ -- Mark Nottingham https://www.mnot.net/ From nobody Wed Aug 4 19:53:05 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 795823A138C for ; Wed, 4 Aug 2021 19:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 sgV-4pbavB2h for ; Wed, 4 Aug 2021 19:52:55 -0700 (PDT) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (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 A08103A138B for ; Wed, 4 Aug 2021 19:52:55 -0700 (PDT) Received: by mail-il1-x136.google.com with SMTP id i13so3643911ilm.11 for ; Wed, 04 Aug 2021 19:52:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5LgpViTrGiIhfrgqCo7clCKdvrs5ZYQlC13y7RosdmY=; b=CSAcx0TyBAWRdpjq8VYV60q9Iwzgp+W3MRpunwqPsnHOrQn8UAjTJHRggdeHSC927s 6BNcKUpO9rZfBuhu7+fZkDDhbOz+4T9JtDN4fMazJVBJSmLtX08VDaSSgU7akHyrFes0 +anD1J5Sb/RdqLHvGuoGhhzRsTQM3/hQFG4eTjuaOEpdc5BJk2O/44V5YVpuxzZBZHwt q8PEuDWbwVu4xuYRiesYS4FYohmq/b4OuNWYWSqxd5z0hGMAjiL0IixVAT2UKgn/9NXD ZjwJ+JthaZbsxmRJs+toEQvCQ5HkhKcTOkHDHU1nabULafe2WRlRo0duogQn9+QlwpeA C7xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5LgpViTrGiIhfrgqCo7clCKdvrs5ZYQlC13y7RosdmY=; b=FBZ9DHum9smS1+WwTozdudfU+w4S6KhpWvPjgC8EyQ4cgajOS7NN+sV6Zn9l9+uvR0 14KAYjqhp2hITtKWsPXbxNvsT6/hVlOddXiCzZorJlxRiivH4yRFrEvvrt6EWAm1oHVT IX9Onx0v9PNHGwCU6ALTaxYUd+JKuHTsbTGmV7ribA2/fiHzb6bF13snv/ayKbZJfDaF WZ/fBqSfwjdVsUl5AHqTKMkbWJEhHYv4RReOQg4IVVsIPUJ4dEc59ZsCPA5n5hhlJVUl Hz5JanjIe2tn75ky5igWP6M9Y/Xeb7faBjR3xK3CaOx2JTIqOhgUxNmTj1auvm4TL3RB ENgg== X-Gm-Message-State: AOAM5314owVCmn80gzeQrJbNYJ/RaIjRautomzokSN96rYzLfPwesJ6F UednDQcGNGT/UfUWZ3O6koWeA08/OD7f926DkhZ3jQ== X-Google-Smtp-Source: ABdhPJx61Q6ATJ9QLsSK/nD9LZdk1s2ovWp1Go300CuMLeiWfHOCejmOaZgkJLcFFeBXh92mIUbVz/VzFaNcRdfFRZc= X-Received: by 2002:a05:6e02:1aae:: with SMTP id l14mr10632ilv.35.1628131973436; Wed, 04 Aug 2021 19:52:53 -0700 (PDT) MIME-Version: 1.0 References: <608f49c6-5e3e-637a-482d-15e48298beb9@joelhalpern.com> <010AEB19-A39C-46BB-8BBF-5BBA4B4B11C5@mnot.net> In-Reply-To: <010AEB19-A39C-46BB-8BBF-5BBA4B4B11C5@mnot.net> From: Eric Rescorla Date: Wed, 4 Aug 2021 19:52:17 -0700 Message-ID: To: Mark Nottingham Cc: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= , "rfced-future@iab.org" , Eliot Lear Content-Type: multipart/alternative; boundary="000000000000ecb64605c8c703e7" Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2021 02:53:02 -0000 --000000000000ecb64605c8c703e7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On reflection I concur with Mark. This person isn't editing, they're advising. So, expert seems fine, but Editor just seems historical. FWIW, I'm somewhat less attached to rfc-editor.org than mnot is. If we were starting from scratch with a document series called "RFC", I doubt we would host it at "rfc-editor.org". OTOH, that seems mostly OBE now. -Ekr On Wed, Aug 4, 2021 at 6:35 PM Mark Nottingham wrote: > Let's map out the space. Currently, we have a couple of things that are > well-defined: > > * RFC Production Centre -- the people who actually do the editing > * RFC Publisher -- other bits (e.g., web site, announcements, legal > verification) > > We also have: > * RFC Series Consulting Editor -- the person we've been talking about a > lot. *Not* in charge of the entities above. > * IETF Executive Director -- contracting authority for the RSCE, RPC and > RP. > * RFC Series Working Group -- where the community/communities come > together to figure out things about the series. > * RFC Series Approval Board -- oversight of the RSWG, representation of > the streams. > > If we were to draw a diagram around bits of this a la RFC8728 Section 2, > I'd be very interested to know what should be inside a box labeled 'RFC > Editor'. > > Looking at draft-iab-rfcefdp-rfced-model-00, 'RFC Editor' is used > consistently to talk about the set of functions that collectively manages > the Series. Calling everything happening the 'RFC Editor' while also havi= ng > someone whose job title ends in 'Editor' is confusing and arguably > misleading to those who aren't steeped in the details of IETF minutia (an > ongoing problem, especially for the one part of our work that's actually > exposed to non-IETF people on a regular basis). > > The problem, of course, is that we've invested a lot in 'rfc-editor.org'. > Even if we plaster 'The RFC Editor is not a person' in red on the top of > that web site, the nature of this role is still going to be confusing if = it > ends with 'Editor.' > > So actually, I retract my 'can live with this.' I haven't seen any > evidence supporting the notion that people will refuse this position if i= t > doesn't have 'editor' in the title; that seems frankly petty, and if > someone were to make it a sticking point for the position, I'd think > carefully about whether they're appropriate for the role. > > Eliot, consider this an objection, please. If we're going to have 'RFC > Editor' refer to the function, it should be clearly and absolutely > delineated from the component bodies and people. > > Instead, I would suggest 'RFC Series Consulting Expert' -- same acronym. > Much clearer, and still looks nice on someone's resume if that's truly > important. > > Cheers, > > > > On 5 Aug 2021, at 11:13 am, Martin J. D=C3=BCrst > wrote: > > > > On 2021-08-05 09:05, Mark Nottingham wrote: > >> I can *just* live with this. > >> I would be much happier if we expunged the phrase 'RFC Editor' from ou= r > documents (progressively, of course), as it's going to cause confusion. > > > > This seems to be a separate issue. If we no longer have a "RFC Editor" > *function*, then the title "RFC Series Consulting Editor" may not make mu= ch > sense anymore. > > > > But if we'd start expunging the phrase "RFC Editor", what would you > replace it with? > > > > Regards, Martin. > > > > > >> Cheers, > >>> On 4 Aug 2021, at 8:10 pm, Eliot Lear wrote: > >>> > >>> Unless people voice objections, I'll ask Peter to please use this ter= m > in the next revision of the draft. > >>> > >>> Eliot > >>> > >>> > >>> On 03.08.21 00:41, Joel M. Halpern wrote: > >>>> I can live with this. (I am bad at naming, so my actually liking > something is largely irrelevant.) > >>>> > >>>> Yours, > >>>> Joel > >>>> > >>>> On 8/2/2021 6:13 PM, Martin Thomson wrote: > >>>>> On Tue, Aug 3, 2021, at 01:57, Eliot Lear wrote: > >>>>>> I believe someone offered RFC Series Consulting > >>>>>> Editor. Is that something that would work for people? > >>>>> > >>>>> WFM > >>>>> > >>>> > >>> > >>> -- > >>> Rfced-future mailing list > >>> Rfced-future@iab.org > >>> https://www.iab.org/mailman/listinfo/rfced-future > >> -- > >> Mark Nottingham https://www.mnot.net/ > > -- > Mark Nottingham https://www.mnot.net/ > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > --000000000000ecb64605c8c703e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On reflection I concur with Mark. This person isn'= ;t editing, they're advising. So, expert seems fine, but Editor just se= ems historical.

FWIW, I'm somewhat less at= tached to rfc-editor.or= g than mnot is. If we were starting from scratch with a document series= called "RFC", I doubt we would host it at "rfc-editor.org". OTOH, that se= ems mostly OBE now.

-Ekr

<= /div>
O= n Wed, Aug 4, 2021 at 6:35 PM Mark Nottingham <mnot@mnot.net> wrote:
Let's map out the space. Current= ly, we have a couple of things that are well-defined:

* RFC Production Centre -- the people who actually do the editing
* RFC Publisher -- other bits (e.g., web site, announcements, legal verific= ation)

We also have:
* RFC Series Consulting Editor -- the person we've been talking about a= lot. *Not* in charge of the entities above.
* IETF Executive Director -- contracting authority for the RSCE, RPC and RP= .
* RFC Series Working Group -- where the community/communities come together= to figure out things about the series.
* RFC Series Approval Board -- oversight of the RSWG, representation of the= streams.

If we were to draw a diagram around bits of this a la RFC8728 Section 2, I&= #39;d be very interested to know what should be inside a box labeled 'R= FC Editor'.

Looking at draft-iab-rfcefdp-rfced-model-00, 'RFC Editor' is used c= onsistently to talk about the set of functions that collectively manages th= e Series. Calling everything happening the 'RFC Editor' while also = having someone whose job title ends in 'Editor' is confusing and ar= guably misleading to those who aren't steeped in the details of IETF mi= nutia (an ongoing problem, especially for the one part of our work that'= ;s actually exposed to non-IETF people on a regular basis).

The problem, of course, is that we've invested a lot in 'rfc-editor.org= '. Even if we plaster 'The RFC Editor is not a person' in r= ed on the top of that web site, the nature of this role is still going to b= e confusing if it ends with 'Editor.'

So actually, I retract my 'can live with this.' I haven't seen = any evidence supporting the notion that people will refuse this position if= it doesn't have 'editor' in the title; that seems frankly pett= y, and if someone were to make it a sticking point for the position, I'= d think carefully about whether they're appropriate for the role.

Eliot, consider this an objection, please. If we're going to have '= RFC Editor' refer to the function, it should be clearly and absolutely = delineated from the component bodies and people.

Instead, I would suggest 'RFC Series Consulting Expert' -- same acr= onym. Much clearer, and still looks nice on someone's resume if that= 9;s truly important.

Cheers,


> On 5 Aug 2021, at 11:13 am, Martin J. D=C3=BCrst <duerst@it.aoyama.ac.jp> w= rote:
>
> On 2021-08-05 09:05, Mark Nottingham wrote:
>> I can *just* live with this.
>> I would be much happier if we expunged the phrase 'RFC Editor&= #39; from our documents (progressively, of course), as it's going to ca= use confusion.
>
> This seems to be a separate issue. If we no longer have a "RFC Ed= itor" *function*, then the title "RFC Series Consulting Editor&qu= ot; may not make much sense anymore.
>
> But if we'd start expunging the phrase "RFC Editor", wha= t would you replace it with?
>
> Regards,=C2=A0 =C2=A0Martin.
>
>
>> Cheers,
>>> On 4 Aug 2021, at 8:10 pm, Eliot Lear <lear@lear.ch> wrote:
>>>
>>> Unless people voice objections, I'll ask Peter to please u= se this term in the next revision of the draft.
>>>
>>> Eliot
>>>
>>>
>>> On 03.08.21 00:41, Joel M. Halpern wrote:
>>>> I can live with this.=C2=A0 (I am bad at naming, so my act= ually liking something is largely irrelevant.)
>>>>
>>>> Yours,
>>>> Joel
>>>>
>>>> On 8/2/2021 6:13 PM, Martin Thomson wrote:
>>>>> On Tue, Aug 3, 2021, at 01:57, Eliot Lear wrote:
>>>>>> I believe someone offered RFC Series Consulting >>>>>> Editor.=C2=A0 Is that something that would work fo= r people?
>>>>>
>>>>> WFM
>>>>>
>>>>
>>>
>>> --
>>> Rfced-future mailing list
>>> Rfce= d-future@iab.org
>>> https://www.iab.org/mailman/listinfo/r= fced-future
>> --
>> Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/

--
Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/

--
Rfced-future mailing list
Rfced-future@iab.= org
https://www.iab.org/mailman/listinfo/rfced-future
--000000000000ecb64605c8c703e7-- From nobody Wed Aug 4 20:12:31 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE1C53A1454 for ; Wed, 4 Aug 2021 20:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 yoEp5YOiP-ty; Wed, 4 Aug 2021 20:12:22 -0700 (PDT) Received: from smtpclient.apple (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id 2C5653A1455; Wed, 4 Aug 2021 20:12:21 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Jay Daley In-Reply-To: Date: Thu, 5 Aug 2021 15:12:18 +1200 Cc: Mark Nottingham , "rfced-future@iab.org" , =?utf-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= , Eliot Lear Content-Transfer-Encoding: quoted-printable Message-Id: References: <608f49c6-5e3e-637a-482d-15e48298beb9@joelhalpern.com> <010AEB19-A39C-46BB-8BBF-5BBA4B4B11C5@mnot.net> To: Eric Rescorla X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2021 03:12:29 -0000 > On 5/08/2021, at 2:52 PM, Eric Rescorla wrote: >=20 > If we were starting from scratch with a document series called "RFC", = I doubt we would host it at "rfc-editor.org". OTOH, that seems mostly = OBE now. While that=E2=80=99s undoubtedly true, we now have problems from our use = of rfc-editor.org. Naming the site after the editorial function, which = is possibly the lowest profile function in the whole IETF process, means = that the site inherently has very little brand recognition (and = therefore authority) to an uninitiated user. This is one of the reasons = why tools.ietf.org dominates in the search rankings. We could partly get around this by using say rfcseries.org but even then = it=E2=80=99s not clear that any site that is not closely related to the = IETF has the brand necessary to be recognised as the authoritative site = for RFCs. I believe that=E2=80=99s why some people have proposed a = docs.ietf.org site. (We could also get over the SEO hurdle by using a 301 redirect not a 302 = from tools.ietf.org and set rel=3D"canonical" everywhere we publish = RFCs, but not the cognitive hurdle) Jay >=20 > -Ekr >=20 >=20 > On Wed, Aug 4, 2021 at 6:35 PM Mark Nottingham wrote: > Let's map out the space. Currently, we have a couple of things that = are well-defined: >=20 > * RFC Production Centre -- the people who actually do the editing > * RFC Publisher -- other bits (e.g., web site, announcements, legal = verification) >=20 > We also have: > * RFC Series Consulting Editor -- the person we've been talking about = a lot. *Not* in charge of the entities above. > * IETF Executive Director -- contracting authority for the RSCE, RPC = and RP. > * RFC Series Working Group -- where the community/communities come = together to figure out things about the series. > * RFC Series Approval Board -- oversight of the RSWG, representation = of the streams. >=20 > If we were to draw a diagram around bits of this a la RFC8728 Section = 2, I'd be very interested to know what should be inside a box labeled = 'RFC Editor'. >=20 > Looking at draft-iab-rfcefdp-rfced-model-00, 'RFC Editor' is used = consistently to talk about the set of functions that collectively = manages the Series. Calling everything happening the 'RFC Editor' while = also having someone whose job title ends in 'Editor' is confusing and = arguably misleading to those who aren't steeped in the details of IETF = minutia (an ongoing problem, especially for the one part of our work = that's actually exposed to non-IETF people on a regular basis).=20 >=20 > The problem, of course, is that we've invested a lot in = 'rfc-editor.org'. Even if we plaster 'The RFC Editor is not a person' in = red on the top of that web site, the nature of this role is still going = to be confusing if it ends with 'Editor.' >=20 > So actually, I retract my 'can live with this.' I haven't seen any = evidence supporting the notion that people will refuse this position if = it doesn't have 'editor' in the title; that seems frankly petty, and if = someone were to make it a sticking point for the position, I'd think = carefully about whether they're appropriate for the role.=20 >=20 > Eliot, consider this an objection, please. If we're going to have 'RFC = Editor' refer to the function, it should be clearly and absolutely = delineated from the component bodies and people. >=20 > Instead, I would suggest 'RFC Series Consulting Expert' -- same = acronym. Much clearer, and still looks nice on someone's resume if = that's truly important. >=20 > Cheers, >=20 >=20 > > On 5 Aug 2021, at 11:13 am, Martin J. D=C3=BCrst = wrote: > >=20 > > On 2021-08-05 09:05, Mark Nottingham wrote: > >> I can *just* live with this. > >> I would be much happier if we expunged the phrase 'RFC Editor' from = our documents (progressively, of course), as it's going to cause = confusion. > >=20 > > This seems to be a separate issue. If we no longer have a "RFC = Editor" *function*, then the title "RFC Series Consulting Editor" may = not make much sense anymore. > >=20 > > But if we'd start expunging the phrase "RFC Editor", what would you = replace it with? > >=20 > > Regards, Martin. > >=20 > >=20 > >> Cheers, > >>> On 4 Aug 2021, at 8:10 pm, Eliot Lear wrote: > >>>=20 > >>> Unless people voice objections, I'll ask Peter to please use this = term in the next revision of the draft. > >>>=20 > >>> Eliot > >>>=20 > >>>=20 > >>> On 03.08.21 00:41, Joel M. Halpern wrote: > >>>> I can live with this. (I am bad at naming, so my actually liking = something is largely irrelevant.) > >>>>=20 > >>>> Yours, > >>>> Joel > >>>>=20 > >>>> On 8/2/2021 6:13 PM, Martin Thomson wrote: > >>>>> On Tue, Aug 3, 2021, at 01:57, Eliot Lear wrote: > >>>>>> I believe someone offered RFC Series Consulting > >>>>>> Editor. Is that something that would work for people? > >>>>>=20 > >>>>> WFM > >>>>>=20 > >>>>=20 > >>>=20 > >>> --=20 > >>> Rfced-future mailing list > >>> Rfced-future@iab.org > >>> https://www.iab.org/mailman/listinfo/rfced-future > >> -- > >> Mark Nottingham https://www.mnot.net/ >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future --=20 Jay Daley IETF Executive Director jay@ietf.org From nobody Wed Aug 4 20:57:52 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBF4B3A1625 for ; Wed, 4 Aug 2021 20:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=btaIxHSm; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ehaMOEEn 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 unB8ECTfKEqa for ; Wed, 4 Aug 2021 20:57:45 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 918343A1623 for ; Wed, 4 Aug 2021 20:57:45 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 5CCA75C0048; Wed, 4 Aug 2021 23:57:44 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Wed, 04 Aug 2021 23:57:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=t qvLuifmP16TfTFDiEvjAlgVE7AK7DlPRQ4Y01+ENH4=; b=btaIxHSmmsjnx/e71 jlp4jvI+0RAxwco0Nvyf6+acO/6Qlsi/VPqi2GdJYGiq58K1GB3XG7DEr++QL01g goSkqkifXh5sVVm3pwkgQ03F7EplNAEZsdzhDh7LaxedY/1Of1UYrpCxDrFWk/AO sX9fPGvfuW7L0kmK4QaQnjp1AFlwDqU5JEvB6Y0x6cesLEE4TMRYCYs+dxq53moR ZVQsSHV6sIqZPqSgfycYS6sIb6TR9GR+xj9eCG6QHwf9Z8WwiXmzu+mBCWK9lvsW 5GOFikwbqfeRNpOXRJXqAXw/GYt9bzPxodBR7r+TtqcFnrQhTyd7Ui+bV2vHrpGL xUpXA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=tqvLuifmP16TfTFDiEvjAlgVE7AK7DlPRQ4Y01+EN H4=; b=ehaMOEEnkwXg8JOppo8DQ+eanMMmuEhYx9hlQUJ6YG4vUX5Yi/4X6BaEr SxbgsxEWUPaZ/W/RM1xOi/eyDRAsfTTunW0o0S7WD+JuBh3BtAv2LeobZkqDP303 IEtkFcjTbHRxYk9re/MnjxUEwC28UpZ7Yybns3deWcETMJyWrQ7fDizlZm0xCL1L QQf0eMNuIyLtgSJgjLsl9ihEqv0nT5jecDNxj9oDWpmQOYngzERJXmWDzuac3ATI q3I4yjFo1LnLsMWkIysk9KFNvICbUC9KqwTj7/zEaDpz9Gc988LNh7HX3vHaR5iB /0ayBDxuI7uO/0HqwMg5RfETcTWRw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrieekgdejfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepueeuveeghfdtfeeuheffvdfhveevudelkeeluedtleeltedvvdeifefhudeludej necuffhomhgrihhnpehrfhgtqdgvughithhorhdrohhrghdpihgvthhfrdhorhhgpdhrfh gtshgvrhhivghsrdhorhhgpdhirggsrdhorhhgpdhmnhhothdrnhgvthenucevlhhushht vghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrd hnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 4 Aug 2021 23:57:37 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Mark Nottingham In-Reply-To: Date: Thu, 5 Aug 2021 13:57:32 +1000 Cc: Eric Rescorla , "rfced-future@iab.org" , =?utf-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= , Eliot Lear Content-Transfer-Encoding: quoted-printable Message-Id: References: <608f49c6-5e3e-637a-482d-15e48298beb9@joelhalpern.com> <010AEB19-A39C-46BB-8BBF-5BBA4B4B11C5@mnot.net> To: Jay Daley X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2021 03:57:51 -0000 Changing terminology in the draft and on the web site away from 'RFC = Editor' would also work.=20 > On 5 Aug 2021, at 1:12 pm, Jay Daley wrote: >=20 >=20 >=20 >> On 5/08/2021, at 2:52 PM, Eric Rescorla wrote: >>=20 >=20 >> If we were starting from scratch with a document series called "RFC", = I doubt we would host it at "rfc-editor.org". OTOH, that seems mostly = OBE now. >=20 > While that=E2=80=99s undoubtedly true, we now have problems from our = use of rfc-editor.org. Naming the site after the editorial function, = which is possibly the lowest profile function in the whole IETF process, = means that the site inherently has very little brand recognition (and = therefore authority) to an uninitiated user. This is one of the reasons = why tools.ietf.org dominates in the search rankings. >=20 > We could partly get around this by using say rfcseries.org but even = then it=E2=80=99s not clear that any site that is not closely related to = the IETF has the brand necessary to be recognised as the authoritative = site for RFCs. I believe that=E2=80=99s why some people have proposed a = docs.ietf.org site. >=20 > (We could also get over the SEO hurdle by using a 301 redirect not a = 302 from tools.ietf.org and set rel=3D"canonical" everywhere we publish = RFCs, but not the cognitive hurdle) >=20 > Jay >=20 >=20 >>=20 >> -Ekr >>=20 >>=20 >> On Wed, Aug 4, 2021 at 6:35 PM Mark Nottingham wrote: >> Let's map out the space. Currently, we have a couple of things that = are well-defined: >>=20 >> * RFC Production Centre -- the people who actually do the editing >> * RFC Publisher -- other bits (e.g., web site, announcements, legal = verification) >>=20 >> We also have: >> * RFC Series Consulting Editor -- the person we've been talking about = a lot. *Not* in charge of the entities above. >> * IETF Executive Director -- contracting authority for the RSCE, RPC = and RP. >> * RFC Series Working Group -- where the community/communities come = together to figure out things about the series. >> * RFC Series Approval Board -- oversight of the RSWG, representation = of the streams. >>=20 >> If we were to draw a diagram around bits of this a la RFC8728 Section = 2, I'd be very interested to know what should be inside a box labeled = 'RFC Editor'. >>=20 >> Looking at draft-iab-rfcefdp-rfced-model-00, 'RFC Editor' is used = consistently to talk about the set of functions that collectively = manages the Series. Calling everything happening the 'RFC Editor' while = also having someone whose job title ends in 'Editor' is confusing and = arguably misleading to those who aren't steeped in the details of IETF = minutia (an ongoing problem, especially for the one part of our work = that's actually exposed to non-IETF people on a regular basis).=20 >>=20 >> The problem, of course, is that we've invested a lot in = 'rfc-editor.org'. Even if we plaster 'The RFC Editor is not a person' in = red on the top of that web site, the nature of this role is still going = to be confusing if it ends with 'Editor.' >>=20 >> So actually, I retract my 'can live with this.' I haven't seen any = evidence supporting the notion that people will refuse this position if = it doesn't have 'editor' in the title; that seems frankly petty, and if = someone were to make it a sticking point for the position, I'd think = carefully about whether they're appropriate for the role.=20 >>=20 >> Eliot, consider this an objection, please. If we're going to have = 'RFC Editor' refer to the function, it should be clearly and absolutely = delineated from the component bodies and people. >>=20 >> Instead, I would suggest 'RFC Series Consulting Expert' -- same = acronym. Much clearer, and still looks nice on someone's resume if = that's truly important. >>=20 >> Cheers, >>=20 >>=20 >>> On 5 Aug 2021, at 11:13 am, Martin J. D=C3=BCrst = wrote: >>>=20 >>> On 2021-08-05 09:05, Mark Nottingham wrote: >>>> I can *just* live with this. >>>> I would be much happier if we expunged the phrase 'RFC Editor' from = our documents (progressively, of course), as it's going to cause = confusion. >>>=20 >>> This seems to be a separate issue. If we no longer have a "RFC = Editor" *function*, then the title "RFC Series Consulting Editor" may = not make much sense anymore. >>>=20 >>> But if we'd start expunging the phrase "RFC Editor", what would you = replace it with? >>>=20 >>> Regards, Martin. >>>=20 >>>=20 >>>> Cheers, >>>>> On 4 Aug 2021, at 8:10 pm, Eliot Lear wrote: >>>>>=20 >>>>> Unless people voice objections, I'll ask Peter to please use this = term in the next revision of the draft. >>>>>=20 >>>>> Eliot >>>>>=20 >>>>>=20 >>>>> On 03.08.21 00:41, Joel M. Halpern wrote: >>>>>> I can live with this. (I am bad at naming, so my actually liking = something is largely irrelevant.) >>>>>>=20 >>>>>> Yours, >>>>>> Joel >>>>>>=20 >>>>>> On 8/2/2021 6:13 PM, Martin Thomson wrote: >>>>>>> On Tue, Aug 3, 2021, at 01:57, Eliot Lear wrote: >>>>>>>> I believe someone offered RFC Series Consulting >>>>>>>> Editor. Is that something that would work for people? >>>>>>>=20 >>>>>>> WFM >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>> --=20 >>>>> Rfced-future mailing list >>>>> Rfced-future@iab.org >>>>> https://www.iab.org/mailman/listinfo/rfced-future >>>> -- >>>> Mark Nottingham https://www.mnot.net/ >>=20 >> -- >> Mark Nottingham https://www.mnot.net/ >>=20 >> --=20 >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future >> --=20 >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future >=20 > --=20 > Jay Daley > IETF Executive Director > jay@ietf.org >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future -- Mark Nottingham https://www.mnot.net/ From nobody Wed Aug 4 21:49:57 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB1473A0858 for ; Wed, 4 Aug 2021 21:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 dG4RtDxRIIR6 for ; Wed, 4 Aug 2021 21:49:50 -0700 (PDT) Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (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 5BFC23A084D for ; Wed, 4 Aug 2021 21:49:50 -0700 (PDT) Received: by mail-pl1-x62f.google.com with SMTP id a20so5696673plm.0 for ; Wed, 04 Aug 2021 21:49:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=kpXiGewa1Fi/Ge7VkIEJhgBWklbIa1/IWQVb0waHoG8=; b=ZNr386yy5hyGJTx5PWLu/ul3OQiR4PEydDZgUXQCVBPUd4/p9MUm7CNADbH3du8qpD KtC8Jj8xyx+sljv6z3n04s7cGspwrHJv9f2Neg56HW0YziZHSgUag/d7GxO1mjcK922E 4kHuNI0pJ5pYsIf6tZm/MzxJLz3DQkLaJRO6VrChIYa6CEXWBGFHYjKLmCch9uENsIBW bd9bMOAEwDmFKGPz4qPwYL3UnHrUNdnpg479pL0YLyoSUS/RYKX2ZOF5nHbOJYGohRBN F+ktdMdM4Bx+bNTAMNUtNTK7xqJBfZqXD1aAIwKgZvAo3T5K2Xb34jO48RuJ6SPJDktK JoRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=kpXiGewa1Fi/Ge7VkIEJhgBWklbIa1/IWQVb0waHoG8=; b=bMn8oH84LOqPWD3kcRX2Dp/15+mdtUOG1ut6sspunW4dSrD+nLFXgYfc/DzOQ8gqtV kkpgaelFnNb7KYifNuC8LhyRXCz9ZLfk9KHzhmj7zhlgMQJ0cYN3cnW4UGt0wenDpUJO PAhcpT6VERsk/n2elPBKFWZB5SXyEt5UQ6St9675Gfz9iv+6u4YBMvMl0VaJrzsZB6Jf NEVAuGNrepYsO446x9uS9xB2GNim9gCSazOXYOMCW4NryV7XYA7NYYdtaHFA/+T4SdZY pYXmGDNBNjkzMj1jvgQ1kP7+sVMMWE+H0qkkvFX/SZ8Kq8dAX2Cbwu7aIUzFa0J45q+4 VM/Q== X-Gm-Message-State: AOAM532DeRu3kg7SoSbCE6yYgaAhBBzK2YiwcL/UfkK+mjgmR14yj/MU aiW+p4DoWwvDtK42Gs3QsudT+7AYyRzmqlmJ X-Google-Smtp-Source: ABdhPJztbqJA745ZYrLECWdzSqKUnay7gdRvLbBfk26cfrj/16rV319lSZfVPo4NVJTEG7SWk/mhvw== X-Received: by 2002:a17:90b:4f8d:: with SMTP id qe13mr13298709pjb.204.1628138988015; Wed, 04 Aug 2021 21:49:48 -0700 (PDT) Received: from [10.100.8.98] ([58.84.227.247]) by smtp.gmail.com with ESMTPSA id y13sm7717850pjn.34.2021.08.04.21.49.46 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Aug 2021 21:49:47 -0700 (PDT) To: rfced-future@iab.org References: <608f49c6-5e3e-637a-482d-15e48298beb9@joelhalpern.com> <010AEB19-A39C-46BB-8BBF-5BBA4B4B11C5@mnot.net> From: Brian E Carpenter Message-ID: <1a03f465-9870-dfc2-14b9-4d72e6c8e1ac@gmail.com> Date: Thu, 5 Aug 2021 16:49:42 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2021 04:49:56 -0000 On 05-Aug-21 14:52, Eric Rescorla wrote: > On reflection I concur with Mark. This person isn't editing, they're ad= vising. So, expert seems fine, but Editor just seems historical. "Consulting Editor" is a status marker. It will look serious on LinkedIn.=20 This is highly relevant when trying recruit a good candidate. It's also v= ery descriptive of the role we have been evolving. As for Mark's point, I think that preferring a term such as "RFC Editor S= ervice" in future would be a good idea. Let the wordsmithing commence. Brian >=20 > FWIW, I'm somewhat less attached to rfc-editor.org than mnot is. If we were starting from scratch with a document series=20 called "RFC", I doubt we would host it at "rfc-editor.org ". OTOH, that seems mostly OBE now. >=20 > -Ekr >=20 >=20 > On Wed, Aug 4, 2021 at 6:35 PM Mark Nottingham > wrote: >=20 > Let's map out the space. Currently, we have a couple of things that=20 are well-defined: >=20 > * RFC Production Centre -- the people who actually do the editing > * RFC Publisher -- other bits (e.g., web site, announcements, legal=20 verification) >=20 > We also have: > * RFC Series Consulting Editor -- the person we've been talking abo= ut a lot. *Not* in charge of the entities above. > * IETF Executive Director -- contracting authority for the RSCE, RP= C and RP. > * RFC Series Working Group -- where the community/communities come = together to figure out things about the series. > * RFC Series Approval Board -- oversight of the RSWG, representatio= n of the streams. >=20 > If we were to draw a diagram around bits of this a la RFC8728 Secti= on 2, I'd be very interested to know what should be inside a box labeled = 'RFC Editor'. >=20 > Looking at draft-iab-rfcefdp-rfced-model-00, 'RFC Editor' is used c= onsistently to talk about the set of functions that collectively manages = the Series. Calling everything happening the 'RFC Editor' while also havi= ng someone whose job title ends in 'Editor' is confusing and arguably mis= leading to those who aren't steeped in the details of IETF minutia (an on= going problem, especially for the one part of our work that's actually ex= posed to non-IETF people on a regular basis). >=20 > The problem, of course, is that we've invested a lot in 'rfc-editor= =2Eorg '. Even if we plaster 'The RFC Editor is no= t a person' in red on the top of that web site, the nature of this role i= s still going to be confusing if it ends with 'Editor.' >=20 > So actually, I retract my 'can live with this.' I haven't seen any = evidence supporting the notion that people will refuse this position if i= t doesn't have 'editor' in the title; that seems frankly petty, and if so= meone were to make it a sticking point for the position, I'd think carefu= lly about whether they're appropriate for the role. >=20 > Eliot, consider this an objection, please. If we're going to have '= RFC Editor' refer to the function, it should be clearly and absolutely de= lineated from the component bodies and people. >=20 > Instead, I would suggest 'RFC Series Consulting Expert' -- same acr= onym. Much clearer, and still looks nice on someone's resume if that's tr= uly important. >=20 > Cheers, >=20 >=20 > > On 5 Aug 2021, at 11:13 am, Martin J. D=C3=BCrst > wrote: > > > > On 2021-08-05 09:05, Mark Nottingham wrote: > >> I can *just* live with this. > >> I would be much happier if we expunged the phrase 'RFC Editor' f= rom our documents (progressively, of course), as it's going to cause conf= usion. > > > > This seems to be a separate issue. If we no longer have a "RFC Ed= itor" *function*, then the title "RFC Series Consulting Editor" may not m= ake much sense anymore. > > > > But if we'd start expunging the phrase "RFC Editor", what would y= ou replace it with? > > > > Regards,=C2=A0 =C2=A0Martin. > > > > > >> Cheers, > >>> On 4 Aug 2021, at 8:10 pm, Eliot Lear > wrote: > >>> > >>> Unless people voice objections, I'll ask Peter to please use th= is term in the next revision of the draft. > >>> > >>> Eliot > >>> > >>> > >>> On 03.08.21 00:41, Joel M. Halpern wrote: > >>>> I can live with this.=C2=A0 (I am bad at naming, so my actuall= y liking something is largely irrelevant.) > >>>> > >>>> Yours, > >>>> Joel > >>>> > >>>> On 8/2/2021 6:13 PM, Martin Thomson wrote: > >>>>> On Tue, Aug 3, 2021, at 01:57, Eliot Lear wrote: > >>>>>> I believe someone offered RFC Series Consulting > >>>>>> Editor.=C2=A0 Is that something that would work for people? > >>>>> > >>>>> WFM > >>>>> > >>>> > >>> > >>> -- > >>> Rfced-future mailing list > >>> Rfced-future@iab.org > >>> https://www.iab.org/mailman/listinfo/rfced-future > >> -- > >> Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/ >=20 > -- > Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/ >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future >=20 >=20 From nobody Wed Aug 4 21:53:39 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 645CA3A0888 for ; Wed, 4 Aug 2021 21:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no 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 xBJnRPGy2kNV for ; Wed, 4 Aug 2021 21:53:33 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D78813A0891 for ; Wed, 4 Aug 2021 21:53:32 -0700 (PDT) Received: from smtpclient.apple (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4GgGTP4B5lz31MM; Thu, 5 Aug 2021 06:53:29 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Carsten Bormann In-Reply-To: Date: Thu, 5 Aug 2021 06:53:28 +0200 Cc: "rfced-future@iab.org" Content-Transfer-Encoding: quoted-printable Message-Id: <6C23FC78-CE0C-49A5-B342-29BD91A948EA@tzi.org> References: <608f49c6-5e3e-637a-482d-15e48298beb9@joelhalpern.com> <010AEB19-A39C-46BB-8BBF-5BBA4B4B11C5@mnot.net> To: Jay Daley X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2021 04:53:38 -0000 On 5. Aug 2021, at 05:12, Jay Daley wrote: >=20 > We could partly get around this by using say rfcseries.org but even = then it=E2=80=99s not clear that any site that is not closely related to = the IETF has the brand necessary to be recognised as the authoritative = site for RFCs. I believe that=E2=80=99s why some people have proposed a = docs.ietf.org site. That is certainly not the reason I have proposed doc.ietf.org. doc.ietf.org is an attempt to, for once, *design* the URI and the = contents behind it as if we had 30 years of experience with the Web and = publishing IETF documents on it. Yes, a focal point the naming of which = includes the IETF brand. But branding is a nice add-on, not the reason = to do this. Should we get rid of rfc-editor.org? We could 301 it, once we have a = credible approach to doc.ietf.org, but please let=E2=80=99s do this in = this sequence. The argument that the RFC series is larger than the IETF = remains, but doesn=E2=80=99t dominate all other considerations. = Introducing yet another URI like rfc-series.org would be another symptom = of change for the sake of change. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Aug 4 21:58:17 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2CD13A08E4 for ; Wed, 4 Aug 2021 21:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 JipPgUscgllB for ; Wed, 4 Aug 2021 21:58:09 -0700 (PDT) Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) (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 79FB13A08E5 for ; Wed, 4 Aug 2021 21:58:09 -0700 (PDT) Received: by mail-pl1-x62e.google.com with SMTP id e5so5653662pld.6 for ; Wed, 04 Aug 2021 21:58:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=1KGQUhYiUHro4cGEcdpv2BOkF+TvhYARacwLem6T810=; b=Q1Ca541KWmYrjS4tyc6gExg+wPJnSi9gFbPnyS785/uKdutiuVsmudTFxpaR1mlsG7 EI/sps72mWQTpM84nX0NGwyolhAxbUcH/SJGPWmchU7s1Cf39IwS2ndHd9AbfjaV1tHZ tvpNK/9UyOriZwXbgAkvVbCLxB++94JPRkeudQKQEZCW5r17aCSUXQWcrhaG8vF8N0Pn Yj38meS4jJTHBKTiyEA4COk3rL/VeXJeI4LEe4jYhHFlF38CWSxr2uLNihZRpiUZcwsa AijGNLwDg97EkygloUekW5Ao6InZT3zUz7D0A8TpzLq+KMqZzbkEHH0GDnOk7L0jRgsA g+AA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=1KGQUhYiUHro4cGEcdpv2BOkF+TvhYARacwLem6T810=; b=Nz8oYgeDNz7jPApH6mAuQgf8LQ2QVEDXSBuXPgrisnXFPHhR1bNtea29ctB+za9+52 2QBOZQ5rPGAyPzXjL7HgUGInWmNYRiFzud0FmbjjSllauW69JT+A8Opa7mTrji35XlCr zelQ7q2v5GfSWIZKoi6IS/hFU128gX751voJZEB4clwT9UpfCnY4MbECd+0WgS1d58xg bnY95BsTJWTUFNJaPPYdsxacC5tgBRLuRJA0JJ17IYNOLuZ7RYleD84zQkEKxg5BAdPb RgjL5pW3VJ+6EIr2Qfk7seUm8tWxpNmuWdZFJ/BeGTt3iPjquDx1LtKUk1dF39IxuKVC sIzQ== X-Gm-Message-State: AOAM533xOaa3gt802xKvy4IekR0xi1tDftPRKTXiJAj3jsmIEogW//Ez wvRp12z6vrjDuSxCsUxCEd4KFCe/3mUV7weS X-Google-Smtp-Source: ABdhPJzsDeYd+P/hyLI7Q8dEuOuH5eGQCjtjWH3mS56ba1yKKb0Yew3ZYR4nn/jnMJWfKF1483kRvg== X-Received: by 2002:a17:902:b717:b029:11a:fae3:ba7c with SMTP id d23-20020a170902b717b029011afae3ba7cmr2661269pls.28.1628139488315; Wed, 04 Aug 2021 21:58:08 -0700 (PDT) Received: from [10.100.8.98] ([58.84.227.247]) by smtp.gmail.com with ESMTPSA id d22sm4973942pfo.142.2021.08.04.21.58.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Aug 2021 21:58:07 -0700 (PDT) To: Jay Daley , Eric Rescorla Cc: "rfced-future@iab.org" , Mark Nottingham , =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= , Eliot Lear References: <608f49c6-5e3e-637a-482d-15e48298beb9@joelhalpern.com> <010AEB19-A39C-46BB-8BBF-5BBA4B4B11C5@mnot.net> From: Brian E Carpenter Message-ID: Date: Thu, 5 Aug 2021 16:58:01 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2021 04:58:16 -0000 On 05-Aug-21 15:12, Jay Daley wrote: >=20 >=20 >> On 5/08/2021, at 2:52 PM, Eric Rescorla wrote: >> >=20 >> If we were starting from scratch with a document series called "RFC", = I doubt we would host it at "rfc-editor.org". OTOH, that seems mostly OBE=20 now. >=20 > While that=E2=80=99s undoubtedly true, we now have problems from our us= e of rfc-editor.org. Naming the site after the editorial function, which=20 is possibly the lowest profile function in the whole IETF process, means = that the site inherently has very little brand recognition (and therefore=20 authority) to an uninitiated user. This is one of the reasons why tools.= ietf.org dominates in the search rankings. >=20 > We could partly get around this by using say rfcseries.org but even the= n it=E2=80=99s not clear that any site that is not closely related to the=20 IETF has the brand necessary to be recognised as the authoritative site f= or RFCs. I believe that=E2=80=99s why some people have proposed a docs.i= etf.org site. That would be wonderful if the RFC Series belonged to the IETF, but it do= esn't. At this point I think the "RFC" (or "Internet RFC") brand is stron= g enough that the domain name simply doesn't matter. I mean, we're not so= me Amazon wannabe trying to sell the most RFCs. Recently my Google searches have been showing tools.ietf.org first and rf= c-editor.org second for rfcXXXX. SEO magic to reverse that would be fine.=20 Only geeks would want the datatracker to come first. Brian > (We could also get over the SEO hurdle by using a 301 redirect not a 30= 2 from tools.ietf.org and set rel=3D"canonical" everywhere we publish RFC= s, but not the cognitive hurdle) >=20 > Jay >=20 >=20 >> >> -Ekr >> >> >> On Wed, Aug 4, 2021 at 6:35 PM Mark Nottingham wrote: >> Let's map out the space. Currently, we have a couple of things that ar= e well-defined: >> >> * RFC Production Centre -- the people who actually do the editing >> * RFC Publisher -- other bits (e.g., web site, announcements, legal ve= rification) >> >> We also have: >> * RFC Series Consulting Editor -- the person we've been talking about = a lot. *Not* in charge of the entities above. >> * IETF Executive Director -- contracting authority for the RSCE, RPC a= nd RP. >> * RFC Series Working Group -- where the community/communities come tog= ether to figure out things about the series. >> * RFC Series Approval Board -- oversight of the RSWG, representation o= f the streams. >> >> If we were to draw a diagram around bits of this a la RFC8728 Section = 2, I'd be very interested to know what should be inside a box labeled 'RF= C Editor'. >> >> Looking at draft-iab-rfcefdp-rfced-model-00, 'RFC Editor' is used cons= istently to talk about the set of functions that collectively manages the=20 Series. Calling everything happening the 'RFC Editor' while also having s= omeone whose job title ends in 'Editor' is confusing and arguably mislead= ing to those who aren't steeped in the details of IETF minutia (an ongoin= g problem, especially for the one part of our work that's actually expose= d to non-IETF people on a regular basis).=20 >> >> The problem, of course, is that we've invested a lot in 'rfc-editor.or= g'. Even if we plaster 'The RFC Editor is not a person' in red on the top=20 of that web site, the nature of this role is still going to be confusing = if it ends with 'Editor.' >> >> So actually, I retract my 'can live with this.' I haven't seen any evi= dence supporting the notion that people will refuse this position if it d= oesn't have 'editor' in the title; that seems frankly petty, and if someo= ne were to make it a sticking point for the position, I'd think carefully=20 about whether they're appropriate for the role.=20 >> >> Eliot, consider this an objection, please. If we're going to have 'RFC=20 Editor' refer to the function, it should be clearly and absolutely deline= ated from the component bodies and people. >> >> Instead, I would suggest 'RFC Series Consulting Expert' -- same acrony= m. Much clearer, and still looks nice on someone's resume if that's truly=20 important. >> >> Cheers, >> >> >>> On 5 Aug 2021, at 11:13 am, Martin J. D=C3=BCrst wrote: >>> >>> On 2021-08-05 09:05, Mark Nottingham wrote: >>>> I can *just* live with this. >>>> I would be much happier if we expunged the phrase 'RFC Editor' from = our documents (progressively, of course), as it's going to cause confusio= n. >>> >>> This seems to be a separate issue. If we no longer have a "RFC Editor= " *function*, then the title "RFC Series Consulting Editor" may not make = much sense anymore. >>> >>> But if we'd start expunging the phrase "RFC Editor", what would you r= eplace it with? >>> >>> Regards, Martin. >>> >>> >>>> Cheers, >>>>> On 4 Aug 2021, at 8:10 pm, Eliot Lear wrote: >>>>> >>>>> Unless people voice objections, I'll ask Peter to please use this t= erm in the next revision of the draft. >>>>> >>>>> Eliot >>>>> >>>>> >>>>> On 03.08.21 00:41, Joel M. Halpern wrote: >>>>>> I can live with this. (I am bad at naming, so my actually liking = something is largely irrelevant.) >>>>>> >>>>>> Yours, >>>>>> Joel >>>>>> >>>>>> On 8/2/2021 6:13 PM, Martin Thomson wrote: >>>>>>> On Tue, Aug 3, 2021, at 01:57, Eliot Lear wrote: >>>>>>>> I believe someone offered RFC Series Consulting >>>>>>>> Editor. Is that something that would work for people? >>>>>>> >>>>>>> WFM >>>>>>> >>>>>> >>>>> >>>>> --=20 >>>>> Rfced-future mailing list >>>>> Rfced-future@iab.org >>>>> https://www.iab.org/mailman/listinfo/rfced-future >>>> -- >>>> Mark Nottingham https://www.mnot.net/ >> >> -- >> Mark Nottingham https://www.mnot.net/ >> >> --=20 >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future >> --=20 >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future >=20 From nobody Wed Aug 4 22:16:51 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F14573A0A1E for ; Wed, 4 Aug 2021 22:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.89 X-Spam-Level: X-Spam-Status: No, score=-0.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=lear.ch 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 qojEeyH4Lb2F for ; Wed, 4 Aug 2021 22:16:43 -0700 (PDT) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 966F73A0A1C for ; Wed, 4 Aug 2021 22:16:43 -0700 (PDT) Received: from Lear-Air.local ([IPv6:2a02:aa15:4101:2a80:387c:29cb:487:66f3]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 1755Gc4j199271 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Thu, 5 Aug 2021 07:16:39 +0200 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1628140600; bh=2NWlkuHQiFKNxlF82JWqNDT8dQPRi4sexMapCSMY+oY=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=GForahDO7I0mNWFQ6vPCydeylwboFqE99vxdrJu5yVyss6KiPAeW+5TfQrxlojsNh udRU9mFWFYOrBeppoNoBFQR9d8d+TqiwHuMuCI8iFzDLZG8Gxc5EIgO0HTGcsNxWvz 6aMuB/+bXWJ6oXSEmNRFpZb/GYT2dLcx08nhzu9Q= To: Eric Rescorla , Mark Nottingham Cc: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= , "rfced-future@iab.org" References: <608f49c6-5e3e-637a-482d-15e48298beb9@joelhalpern.com> <010AEB19-A39C-46BB-8BBF-5BBA4B4B11C5@mnot.net> From: Eliot Lear Message-ID: <2c7d5a3e-87b4-53d6-17c6-3e1814bb35a2@lear.ch> Date: Thu, 5 Aug 2021 07:16:37 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="HIjjqEaMujXT3LRoRtUaYh664WsPUueBI" Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2021 05:16:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HIjjqEaMujXT3LRoRtUaYh664WsPUueBI Content-Type: multipart/mixed; boundary="RL41O4pyckOd2bquJ5o197Qbx6ISGR1Es"; protected-headers="v1" From: Eliot Lear To: Eric Rescorla , Mark Nottingham Cc: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= , "rfced-future@iab.org" Message-ID: <2c7d5a3e-87b4-53d6-17c6-3e1814bb35a2@lear.ch> Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? References: <608f49c6-5e3e-637a-482d-15e48298beb9@joelhalpern.com> <010AEB19-A39C-46BB-8BBF-5BBA4B4B11C5@mnot.net> In-Reply-To: --RL41O4pyckOd2bquJ5o197Qbx6ISGR1Es Content-Type: multipart/alternative; boundary="------------E5E9CF2CB279EC103FA4F8F5" Content-Language: en-US This is a multi-part message in MIME format. --------------E5E9CF2CB279EC103FA4F8F5 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Peter should hold on this change until there is consensus, which I am=20 not ready to say that there is. However, I think Mark and Eric, you should reconsider your objections.=C2= =A0=20 As I have stated, I do not see consensus for advisor.=C2=A0 I do not know= if=20 we will see consensus for expert, and I would like to get beyond this=20 issue.=C2=A0 We are seeking compromise. This person is expected to be an = editor by profession and to provide that expertise.=C2=A0 We're not hirin= g=20 just any expert. Eliot On 05.08.21 04:52, Eric Rescorla wrote: > On reflection I concur with Mark. This person isn't editing, they're=20 > advising. So, expert seems fine, but Editor just seems historical. > > FWIW, I'm somewhat less attached to rfc-editor.org=20 > than mnot is. If we were starting from scratch = > with a document series called "RFC", I doubt we would host it at=20 > "rfc-editor.org ". OTOH, that seems mostly OBE n= ow. > > -Ekr > > > On Wed, Aug 4, 2021 at 6:35 PM Mark Nottingham > wrote: > > Let's map out the space. Currently, we have a couple of things > that are well-defined: > > * RFC Production Centre -- the people who actually do the editing > * RFC Publisher -- other bits (e.g., web site, announcements, > legal verification) > > We also have: > * RFC Series Consulting Editor -- the person we've been talking > about a lot. *Not* in charge of the entities above. > * IETF Executive Director -- contracting authority for the RSCE, > RPC and RP. > * RFC Series Working Group -- where the community/communities come > together to figure out things about the series. > * RFC Series Approval Board -- oversight of the RSWG, > representation of the streams. > > If we were to draw a diagram around bits of this a la RFC8728 > Section 2, I'd be very interested to know what should be inside a > box labeled 'RFC Editor'. > > Looking at draft-iab-rfcefdp-rfced-model-00, 'RFC Editor' is used > consistently to talk about the set of functions that collectively > manages the Series. Calling everything happening the 'RFC Editor' > while also having someone whose job title ends in 'Editor' is > confusing and arguably misleading to those who aren't steeped in > the details of IETF minutia (an ongoing problem, especially for > the one part of our work that's actually exposed to non-IETF > people on a regular basis). > > The problem, of course, is that we've invested a lot in > 'rfc-editor.org '. Even if we plaster 'The > RFC Editor is not a person' in red on the top of that web site, > the nature of this role is still going to be confusing if it ends > with 'Editor.' > > So actually, I retract my 'can live with this.' I haven't seen any > evidence supporting the notion that people will refuse this > position if it doesn't have 'editor' in the title; that seems > frankly petty, and if someone were to make it a sticking point for > the position, I'd think carefully about whether they're > appropriate for the role. > > Eliot, consider this an objection, please. If we're going to have > 'RFC Editor' refer to the function, it should be clearly and > absolutely delineated from the component bodies and people. > > Instead, I would suggest 'RFC Series Consulting Expert' -- same > acronym. Much clearer, and still looks nice on someone's resume if > that's truly important. > > Cheers, > > > > On 5 Aug 2021, at 11:13 am, Martin J. D=C3=BCrst > > wrote: > > > > On 2021-08-05 09:05, Mark Nottingham wrote: > >> I can *just* live with this. > >> I would be much happier if we expunged the phrase 'RFC Editor' > from our documents (progressively, of course), as it's going to > cause confusion. > > > > This seems to be a separate issue. If we no longer have a "RFC > Editor" *function*, then the title "RFC Series Consulting Editor" > may not make much sense anymore. > > > > But if we'd start expunging the phrase "RFC Editor", what would > you replace it with? > > > > Regards,=C2=A0 =C2=A0Martin. > > > > > >> Cheers, > >>> On 4 Aug 2021, at 8:10 pm, Eliot Lear > wrote: > >>> > >>> Unless people voice objections, I'll ask Peter to please use > this term in the next revision of the draft. > >>> > >>> Eliot > >>> > >>> > >>> On 03.08.21 00:41, Joel M. Halpern wrote: > >>>> I can live with this.=C2=A0 (I am bad at naming, so my actuall= y > liking something is largely irrelevant.) > >>>> > >>>> Yours, > >>>> Joel > >>>> > >>>> On 8/2/2021 6:13 PM, Martin Thomson wrote: > >>>>> On Tue, Aug 3, 2021, at 01:57, Eliot Lear wrote: > >>>>>> I believe someone offered RFC Series Consulting > >>>>>> Editor.=C2=A0 Is that something that would work for people? > >>>>> > >>>>> WFM > >>>>> > >>>> > >>> > >>> -- > >>> Rfced-future mailing list > >>> Rfced-future@iab.org > >>> https://www.iab.org/mailman/listinfo/rfced-future > > >> -- > >> Mark Nottingham https://www.mnot.net/ > > -- > Mark Nottingham https://www.mnot.net/ > > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > > --------------E5E9CF2CB279EC103FA4F8F5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Peter should hold on this change until there is consensus, which I am not ready to say that there is.

However, I think Mark and Eric, you should reconsider your objections.=C2=A0 As I have stated, I do not see consensus for advisor.=C2=A0 I do not know if we will see consensus for expert, a= nd I would like to get beyond this issue.=C2=A0 We are seeking compromis= e.=C2=A0 This person is expected to be an editor by profession and to provide that expertise.=C2=A0 We're not hiring just any expert.

=

Eliot

On 05.08.21 04:52, Eric Rescorla wrote= :
On reflection I concur with Mark. This person isn't editing, they're advising. So, expert seems fine, but Editor just seems historical.

FWIW, I'm somewhat less attached to rfc-editor.org than mnot is. If we were starting from scratch with a document series called "RFC", I doubt we would host it at "rfc-editor.org". OTOH, that seem= s mostly OBE now.

-Ekr


On Wed, Aug 4, 2021 at 6:35= PM Mark Nottingham <mnot@mnot.net&= gt; wrote:
= Let's map out the space. Currently, we have a couple of things that are well-defined:

* RFC Production Centre -- the people who actually do the editing
* RFC Publisher -- other bits (e.g., web site, announcements, legal verification)

We also have:
* RFC Series Consulting Editor -- the person we've been talking about a lot. *Not* in charge of the entities above.
= * IETF Executive Director -- contracting authority for the RSCE, RPC and RP.
* RFC Series Working Group -- where the community/communities come together to figure out things about the series.
* RFC Series Approval Board -- oversight of the RSWG, representation of the streams.

If we were to draw a diagram around bits of this a la RFC8728 Section 2, I'd be very interested to know what should be inside a box labeled 'RFC Editor'.

Looking at draft-iab-rfcefdp-rfced-model-00, 'RFC Editor' is used consistently to talk about the set of functions that collectively manages the Series. Calling everything happening the 'RFC Editor' while also having someone whose job title ends in 'Editor' is confusing and arguably misleading to those who aren't steeped in the details of IETF minutia (an ongoing problem, especially for the one part of our work that's actually exposed to non-IETF people on a regular basis).

The problem, of course, is that we've invested a lot in 'rfc-editor.org= '. Even if we plaster 'The RFC Editor is not a person' in red on the top of that web site, the nature of this role is still going to be confusing if it ends with 'Editor.'

So actually, I retract my 'can live with this.' I haven't seen any evidence supporting the notion that people will refuse this position if it doesn't have 'editor' in the title; that seems frankly petty, and if someone were to make it a sticking point for the position, I'd think carefully about whether they're appropriate for the role.

Eliot, consider this an objection, please. If we're going to have 'RFC Editor' refer to the function, it should be clearly and absolutely delineated from the component bodies and people.

Instead, I would suggest 'RFC Series Consulting Expert' -- same acronym. Much clearer, and still looks nice on someone's resume if that's truly important.

Cheers,


> On 5 Aug 2021, at 11:13 am, Martin J. D=C3=BCrst <duerst@it.aoyama.ac.jp> wrote= :
>
> On 2021-08-05 09:05, Mark Nottingham wrote:
>> I can *just* live with this.
>> I would be much happier if we expunged the phrase 'RFC Editor' from our documents (progressively, of course), as it's going to cause confusion.
>
> This seems to be a separate issue. If we no longer have a "RFC Editor" *function*, then the title "RFC Series Consulting Editor" may not make much sense anymore.
>
> But if we'd start expunging the phrase "RFC Editor", what would you replace it with?
>
> Regards,=C2=A0 =C2=A0Martin.
>
>
>> Cheers,
>>> On 4 Aug 2021, at 8:10 pm, Eliot Lear <lear@lear.ch> wrote:
>>>
>>> Unless people voice objections, I'll ask Peter to please use this term in the next revision of the draft.
>>>
>>> Eliot
>>>
>>>
>>> On 03.08.21 00:41, Joel M. Halpern wrote:
>>>> I can live with this.=C2=A0 (I am bad at namin= g, so my actually liking something is largely irrelevant.)
>>>>
>>>> Yours,
>>>> Joel
>>>>
>>>> On 8/2/2021 6:13 PM, Martin Thomson wrote:
= >>>>> On Tue, Aug 3, 2021, at 01:57, Eliot Lear wrote:
>>>>>> I believe someone offered RFC Series Consulting
>>>>>> Editor.=C2=A0 Is that something that w= ould work for people?
>>>>>
>>>>> WFM
>>>>>
>>>>
>>>
>>> --
>>> Rfced-future mailing list
>>> Rfced-future@iab.o= rg
>>> https://www.iab.org/mailman/listinfo/rfced-future
>> --
>> Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/

--
Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/

--
Rfced-future mailing list
Rfced-future@iab.org
https://www.iab.org/mailman/listinfo/rfced-future
--------------E5E9CF2CB279EC103FA4F8F5-- --RL41O4pyckOd2bquJ5o197Qbx6ISGR1Es-- --HIjjqEaMujXT3LRoRtUaYh664WsPUueBI Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmELdDUFAwAAAAAACgkQh7ZrRtnSejPa 3wgAsEsH8qKIduGXQ8HtFNIvyg10o+PPYXR2O2UUWF0arTmDlTmwPCSUhUOo9n4pNo6gAguISApI JRy8vVKpYPZ2Crk2vva5vQb80T8bv0N1O/YW1SZJt3NNdgixeVPgMBOc3xwtfJsD56aTdvMxyOds QME/xImOzTO5DVVp5TQ7cbpAWss8DWFdFsDsr/TebIE96ZoTLoUM4m+yqPEmSuzHLnUK13WOHyS5 FWQnr6ig0BVL6uv+KuIsimYZhKlxFRxLtTzQi5pP+N+c1mUqpP2hm+9HxJz5KkGmC/YAWIX1nFzE iL9aiSW13KViUIgT9FcOZ9kKV8LZ359OR6iLmFgJQQ== =y3ZQ -----END PGP SIGNATURE----- --HIjjqEaMujXT3LRoRtUaYh664WsPUueBI-- From nobody Wed Aug 4 22:28:52 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA8BF3A0AF4 for ; Wed, 4 Aug 2021 22:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 lXejxUPtru7q for ; Wed, 4 Aug 2021 22:28:46 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 256BB3A0AF3 for ; Wed, 4 Aug 2021 22:28:46 -0700 (PDT) Received: from smtpclient.apple (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4GgHG448ZKz31MM; Thu, 5 Aug 2021 07:28:44 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Carsten Bormann In-Reply-To: <2c7d5a3e-87b4-53d6-17c6-3e1814bb35a2@lear.ch> Date: Thu, 5 Aug 2021 07:28:44 +0200 Cc: "rfced-future@iab.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <608f49c6-5e3e-637a-482d-15e48298beb9@joelhalpern.com> <010AEB19-A39C-46BB-8BBF-5BBA4B4B11C5@mnot.net> <2c7d5a3e-87b4-53d6-17c6-3e1814bb35a2@lear.ch> To: Eliot Lear X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2021 05:28:51 -0000 On 5. Aug 2021, at 07:16, Eliot Lear wrote: >=20 > expert Expert is a synonym for human being (where the humanity is optional). = =E2=80=94 Charles Goldfarb Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Aug 5 09:45:47 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50DDE3A18D7 for ; Thu, 5 Aug 2021 09:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 woZ_brJGwitG for ; Thu, 5 Aug 2021 09:45:39 -0700 (PDT) Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (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 21B593A1A62 for ; Thu, 5 Aug 2021 09:45:05 -0700 (PDT) Received: by mail-il1-x12f.google.com with SMTP id i13so5756280ilm.11 for ; Thu, 05 Aug 2021 09:45:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=09So5JLn7FUb2ZM5YjxSIDXf5+Tpv2/PBwrAgPWgSnY=; b=RgpwdyIKWej6MlpjZB3Lny5cg6637YuyzzNO3gPfnJAXAqoNBMDZ/sddC6hDz3s+x1 BBIxMKpY2a2nHFn58UKEs3pNETulWjIlVTGpdXPjDDc8t2zlE1QxG8wJplvDwS4gRQOi QSlXymjSCzMvsJKG1/4nP2w0Wg7VSLJL4i1v0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=09So5JLn7FUb2ZM5YjxSIDXf5+Tpv2/PBwrAgPWgSnY=; b=lyCv2KSFvijoRdAPYO0mGImZ0TR5jbnxVThx4YXY2rgtxgFEBdPhrTHaVQmZ/VH7Tf iy65pFvZvPA7XEU/R+lZTiz8SKbEvj2oElAq1EQ3AUCaOfRzBVrl+w1h6jH3EUT0HEdL RFJ3Vdb0N+qdd7mBcTo4to65J7tY/l8tbMXg6JH/PiRc/ka6hg+Np2BwHP3mc+yVTorn 3Ty3iWcJoIRMuuU2VTxpw2nlJcDNbVJWjftyo4OaC7U3eKhmt54vD5jGXO8fll3E8cRo fbPpSCz2k2C8X1pTa17FLmPBOWSaiwFQJ0EOheJtuqXpzXBPrKNSvEVL1Kdn9N0vMuGg DF8g== X-Gm-Message-State: AOAM531heXWxqFYo760rdTxJHRUThBvuFqGDnKnoiJvpylZO4vq5FHXy b3G8Mcm+575mC5los3h/Nu+X9w== X-Google-Smtp-Source: ABdhPJziyEdkkU8PtB5sksaO0tK4ojSzvk5EPfQhHrAY/US3bvD4/bRskg+dADkR9EJ6FrI7X8h11Q== X-Received: by 2002:a05:6e02:2188:: with SMTP id j8mr466724ila.14.1628181904342; Thu, 05 Aug 2021 09:45:04 -0700 (PDT) Received: from dragon.local (c-73-78-113-156.hsd1.co.comcast.net. [73.78.113.156]) by smtp.gmail.com with ESMTPSA id x6sm1691736ilp.71.2021.08.05.09.45.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 Aug 2021 09:45:03 -0700 (PDT) To: Mark Nottingham Cc: "rfced-future@iab.org" References: <608f49c6-5e3e-637a-482d-15e48298beb9@joelhalpern.com> <010AEB19-A39C-46BB-8BBF-5BBA4B4B11C5@mnot.net> From: Peter Saint-Andre Message-ID: <7a9fca02-8897-bb5e-27cb-efe1b4ed8ab6@mozilla.com> Date: Thu, 5 Aug 2021 10:45:02 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <010AEB19-A39C-46BB-8BBF-5BBA4B4B11C5@mnot.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2021 16:45:46 -0000 [ no hats ] On 8/4/21 7:35 PM, Mark Nottingham wrote: > Let's map out the space. Currently, we have a couple of things that are well-defined: > > * RFC Production Centre -- the people who actually do the editing > * RFC Publisher -- other bits (e.g., web site, announcements, legal verification) It seems that these are effectively the same thing; or, I'm not sure how much value there is in describing them separately. > We also have: > * RFC Series Consulting Editor -- the person we've been talking about a lot. *Not* in charge of the entities above. > * IETF Executive Director -- contracting authority for the RSCE, RPC and RP. Actually I think the contracting authority is IETF LLC. > * RFC Series Working Group -- where the community/communities come together to figure out things about the series. > * RFC Series Approval Board -- oversight of the RSWG, representation of the streams. > > If we were to draw a diagram around bits of this a la RFC8728 Section 2, I'd be very interested to know what should be inside a box labeled 'RFC Editor'. > > Looking at draft-iab-rfcefdp-rfced-model-00, 'RFC Editor' is used consistently to talk about the set of functions that collectively manages the Series. Calling everything happening the 'RFC Editor' while also having someone whose job title ends in 'Editor' is confusing and arguably misleading to those who aren't steeped in the details of IETF minutia (an ongoing problem, especially for the one part of our work that's actually exposed to non-IETF people on a regular basis). As I've said before on this list, I agree that this is confusing. When I suggested not long ago that we might want to pull in text from RFC 4844 / RFC 8729, Brian Carpenter said "a lot of text". Although it's beyond our remit to obsolete those documents, I do think it's reasonable for us to describe the new model accurately, which likely means it is no longer the "RFC Editor Model". Peter From nobody Thu Aug 5 09:53:02 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5F6A3A190C for ; Thu, 5 Aug 2021 09:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 vjE0d88zNiBF for ; Thu, 5 Aug 2021 09:52:57 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDF373A1917 for ; Thu, 5 Aug 2021 09:52:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4GgZRQ5T5Yz1nsXP; Thu, 5 Aug 2021 09:52:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1628182370; bh=ymGRNR3+iCDnZOD1FILt7BSrMdrGh6wJySK7poKb2eY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=fRb13g/qnmHKsTQUPNk3f3YgAUFqJ2e9jwmseQ6C5wVeGrcHM/H2aM0wRcV5egpGv 6+s8U+dHx7/WglmegUsOGRwy8DhgmtOfHb8uKCnSHqN2DAtiEw/5kNrnB9r3oxMkTX x/+qcXTJGffhEHZtmzRRgAn3xFtiLkvPx93GF4DY= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.23.64] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (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 mailb2.tigertech.net (Postfix) with ESMTPSA id 4GgZRQ0vyzz1nwn5; Thu, 5 Aug 2021 09:52:49 -0700 (PDT) To: Peter Saint-Andre Cc: "rfced-future@iab.org" References: <608f49c6-5e3e-637a-482d-15e48298beb9@joelhalpern.com> <010AEB19-A39C-46BB-8BBF-5BBA4B4B11C5@mnot.net> <7a9fca02-8897-bb5e-27cb-efe1b4ed8ab6@mozilla.com> From: "Joel M. Halpern" Message-ID: <3290594c-a920-0ea5-4a28-ff867cbe54f7@joelhalpern.com> Date: Thu, 5 Aug 2021 12:52:48 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <7a9fca02-8897-bb5e-27cb-efe1b4ed8ab6@mozilla.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2021 16:53:02 -0000 I am not following why what we are doing is not describing the "RFC Editor Model". It appears that we are describing the whole process for habndling documents once streams say they want the document published. that includes, policy, strategy, tactics, ... The largest piece of that is the process of editing the documents. Sure, it is not the only piece. Nothing is. But seems to me that it is the single most important part of what happens. Yours, Joel On 8/5/2021 12:45 PM, Peter Saint-Andre wrote: > [ no hats ] > > On 8/4/21 7:35 PM, Mark Nottingham wrote: >> Let's map out the space. Currently, we have a couple of things that are well-defined: >> >> * RFC Production Centre -- the people who actually do the editing >> * RFC Publisher -- other bits (e.g., web site, announcements, legal verification) > > It seems that these are effectively the same thing; or, I'm not sure how > much value there is in describing them separately. > >> We also have: >> * RFC Series Consulting Editor -- the person we've been talking about a lot. *Not* in charge of the entities above. >> * IETF Executive Director -- contracting authority for the RSCE, RPC and RP. > > Actually I think the contracting authority is IETF LLC. > >> * RFC Series Working Group -- where the community/communities come together to figure out things about the series. >> * RFC Series Approval Board -- oversight of the RSWG, representation of the streams. >> >> If we were to draw a diagram around bits of this a la RFC8728 Section 2, I'd be very interested to know what should be inside a box labeled 'RFC Editor'. >> >> Looking at draft-iab-rfcefdp-rfced-model-00, 'RFC Editor' is used consistently to talk about the set of functions that collectively manages the Series. Calling everything happening the 'RFC Editor' while also having someone whose job title ends in 'Editor' is confusing and arguably misleading to those who aren't steeped in the details of IETF minutia (an ongoing problem, especially for the one part of our work that's actually exposed to non-IETF people on a regular basis). > > As I've said before on this list, I agree that this is confusing. When I > suggested not long ago that we might want to pull in text from RFC 4844 > / RFC 8729, Brian Carpenter said "a lot of text". Although it's beyond > our remit to obsolete those documents, I do think it's reasonable for us > to describe the new model accurately, which likely means it is no longer > the "RFC Editor Model". > > Peter > From nobody Thu Aug 5 09:55:59 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2D0B3A19EC for ; Thu, 5 Aug 2021 09:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 l3g6pK4m9U06 for ; Thu, 5 Aug 2021 09:55:55 -0700 (PDT) Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (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 EA2063A199F for ; Thu, 5 Aug 2021 09:55:52 -0700 (PDT) Received: by mail-il1-x12a.google.com with SMTP id h18so5801141ilc.5 for ; Thu, 05 Aug 2021 09:55:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=yXd8Yjy01qd94SVOj43fugYZ//dIRQVXmLKoTgp67No=; b=SL25fx9tXVUsO9E7kSt1RaE/ep7Hvu3CnSpYXFZ0WD9gMyMCGV0e5Dr1nK28fKvwru 4zGIcMO75UVaULUTDLVku2ixc2OD7+I/wd3tGHrufxtPHe4ZakBL3xRR+UmZvPLNO6Gg 05HwynTpyaa5cRAEqkqEGrRgvz2NJT03gRfjs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=yXd8Yjy01qd94SVOj43fugYZ//dIRQVXmLKoTgp67No=; b=rdztHQ3UxhdGiktrdeBww/q2ofY8OCFWRVTSA/6kmaDhTM6wpTzek74Q71ZGI1XTB1 zU/BKcdCrrqYNcPLoynAm2dtt1vbfjzBml8qg/iWtaD3/DhbU7CJ4/iX8yyDr1pv60uB kIE1xUTEYW8m4YHfq/5Y0TrKSJOOmp/Onzj/LsJq2uAWD/XGXly8xQmqtuXUu47O5kQ1 f8rYHzd40MVLiHpif1U26MjqkJIWrkG2HBqMFkHR27mOwmX0mG6LSlr83SgPpATUa7sA R+8kvVCIIX3wPUAcdCDZW1djlmPGkgfRXnaRaE4gLmdammOzLbbH7OMmLN4UZHsjnlS/ O74g== X-Gm-Message-State: AOAM533C0dSAeO/JXz71xgh5l73/mdOtTda8jWtaXbu19lOSvY0EvovC aPbO9BY7NpPsHzr6G0arMCUAhA== X-Google-Smtp-Source: ABdhPJxHRk7T5JSzTA5HoRRIBtexUcseoDkBwHQ2KGEPFOPEA1jvChbvPUfvJH86nEETIwxXyLSFGg== X-Received: by 2002:a05:6e02:14cc:: with SMTP id o12mr745643ilk.76.1628182551067; Thu, 05 Aug 2021 09:55:51 -0700 (PDT) Received: from dragon.local (c-73-78-113-156.hsd1.co.comcast.net. [73.78.113.156]) by smtp.gmail.com with ESMTPSA id f7sm3165820ils.42.2021.08.05.09.55.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 Aug 2021 09:55:50 -0700 (PDT) To: "Joel M. Halpern" Cc: "rfced-future@iab.org" References: <608f49c6-5e3e-637a-482d-15e48298beb9@joelhalpern.com> <010AEB19-A39C-46BB-8BBF-5BBA4B4B11C5@mnot.net> <7a9fca02-8897-bb5e-27cb-efe1b4ed8ab6@mozilla.com> <3290594c-a920-0ea5-4a28-ff867cbe54f7@joelhalpern.com> From: Peter Saint-Andre Message-ID: <5ebab763-f481-a83d-1db6-22a25839b97b@mozilla.com> Date: Thu, 5 Aug 2021 10:55:49 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <3290594c-a920-0ea5-4a28-ff867cbe54f7@joelhalpern.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2021 16:55:58 -0000 On 8/5/21 10:52 AM, Joel M. Halpern wrote: > I am not following why what we are doing is not describing the "RFC > Editor Model".  It appears that we are describing the whole process for > habndling documents once streams say they want the document published. > that includes, policy, strategy, tactics, ...   The largest piece of > that is the process of editing the documents.   Sure, it is not the only > piece.  Nothing  is.   But seems to me that it is the single most > important part of what happens. We could call it "RFC Series Policy Definition and Implementation" - as far as I can see, there's no reason (other than history) to call it the RFC Editor Model. Peter From nobody Thu Aug 5 12:10:25 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 935793A1E97; Thu, 5 Aug 2021 12:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.281 X-Spam-Level: X-Spam-Status: No, score=-1.281 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.399, NICE_REPLY_A=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 hj6cS2Xx0R5Y; Thu, 5 Aug 2021 12:10:19 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 49D453A1E91; Thu, 5 Aug 2021 12:10:19 -0700 (PDT) Received: from Zephyrus.local (76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 175JAFkW096202 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 5 Aug 2021 14:10:16 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1628190617; bh=9VqGXRdKnB5imAN7frJYL2IHXVhefSLDIfsm/EYhkIs=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=viv+rBqlAKI1wxINHyTFXcja7xnNsoBk2g6+nKVvs7KfYyByjwsSh0YXzDCmLn4IY AVmX+NXdNPNq4IpcOXFjzc7dTbo3bYnL761kbsD53HXz9N2Cy+tJmlYEpd0z6duj8V ksgRcGq4gPw5O6cYQnZORzC9Vedw2ZDIlvnASA2Y= X-Authentication-Warning: raven.nostrum.com: Host 76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253] claimed to be Zephyrus.local To: Jay Daley , Eric Rescorla Cc: "rfced-future@iab.org" , Mark Nottingham , =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= , Eliot Lear References: <608f49c6-5e3e-637a-482d-15e48298beb9@joelhalpern.com> <010AEB19-A39C-46BB-8BBF-5BBA4B4B11C5@mnot.net> From: Adam Roach Message-ID: Date: Thu, 5 Aug 2021 14:10:10 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2021 19:10:24 -0000 On 8/4/21 22:12, Jay Daley wrote: > We could partly get around this by using say rfcseries.org but even then it’s not clear that any site that is not closely related to the IETF has the brand necessary to be recognised as the authoritative site for RFCs. I believe that’s why some people have proposed a docs.ietf.org site. This line of discussion is getting very close to the RFCPLUSPLUS question about the meaning of "RFC" and the relationship between the IETF and the RFC series itself. If we are to revisit that conversation, I suggest we have it in a different venue than this one, since it's bigger than the charter of this group. /a From nobody Thu Aug 5 13:06:10 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9D773A20DB for ; Thu, 5 Aug 2021 13:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 owNjmug0p8hL for ; Thu, 5 Aug 2021 13:06:04 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 002673A20D9 for ; Thu, 5 Aug 2021 13:06:03 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id z7so8265838iog.13 for ; Thu, 05 Aug 2021 13:06:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=tQ1JDmkv9vIs51bJJi0eR43MeiKk3WG022OELOJYvhk=; b=Gps3CaBOwSOu6sMfb9QtiC43JDNuiOVY5aEAAJknv/6PnkyCbDT8hn1Eeqj45NbkU3 bUwVVF0ALEA0zCAtM6AjnRGYtlZ2izl5MDmxTqpYZmH4lxR5eInD1XwFLBlvaOJvJNWo C/jOU4TBOK8pwbICEQ8AoI1dacWIe/SQbzYgI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=tQ1JDmkv9vIs51bJJi0eR43MeiKk3WG022OELOJYvhk=; b=poyObtB4JkGBSVjhaMcwNxhX43ypWjErCrwmd3ggQSSUZVrYQLjSPY8d7szN1zl3vP YP1uX9SsxiuXQdOmXz1enEcm7PaH0lgRnE3fmCgYBVhQc7BdziWz/DRVPZRezG6DpLkk TjPr4+BYcxkjHYlhHsmkb4YtUlMd65gEYw03zw1ltDIDapTMScyk8ur7nL2wEz3ZMtff mqr99nukzZTqHpJ+rzLp5Eb9bRfBZnRZbywmekerYJY+2ANaBTEq+v18avskrG0otwGf BYGOEXKMtNsJgbzRWLLO3CbIKP8XUyK/wkYWVeI5e1prtrY1oJh7k1iLhaqw7pYM9KOB l6tg== X-Gm-Message-State: AOAM531I1ciSlg9vDeJ1/i1slELrr8eTCxpmSUHtpIZ79aDxPWxi1bUi A7O2zs/MQ6IIk373DdKwnCMJ0w== X-Google-Smtp-Source: ABdhPJzoAHF/ERi6rkhpXJSHxSfWPX9h7ryLQCtIVe3U02LwcDUHDwjkB2ga9NWW6X/+fXd7ZHusFw== X-Received: by 2002:a05:6602:38d:: with SMTP id f13mr725670iov.153.1628193962381; Thu, 05 Aug 2021 13:06:02 -0700 (PDT) Received: from dragon.local (c-73-78-113-156.hsd1.co.comcast.net. [73.78.113.156]) by smtp.gmail.com with ESMTPSA id x11sm3960840ioa.32.2021.08.05.13.06.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 Aug 2021 13:06:01 -0700 (PDT) To: Adam Roach Cc: "rfced-future@iab.org" References: <608f49c6-5e3e-637a-482d-15e48298beb9@joelhalpern.com> <010AEB19-A39C-46BB-8BBF-5BBA4B4B11C5@mnot.net> From: Peter Saint-Andre Message-ID: Date: Thu, 5 Aug 2021 14:06:00 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2021 20:06:09 -0000 On 8/5/21 1:10 PM, Adam Roach wrote: > On 8/4/21 22:12, Jay Daley wrote: >> We could partly get around this by using say rfcseries.org but even >> then it’s not clear that any site that is not closely related to the >> IETF has the brand necessary to be recognised as the authoritative >> site for RFCs.  I believe that’s why some people have proposed a >> docs.ietf.org site. > > > This line of discussion is getting very close to the RFCPLUSPLUS > question about the meaning of "RFC" and the relationship between the > IETF and the RFC series itself. If we are to revisit that conversation, > I suggest we have it in a different venue than this one, since it's > bigger than the charter of this group. Agreed, and I don't think we need to go there in order to complete the work in our charter. Peter From nobody Thu Aug 5 13:24:26 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 796283A074B for ; Thu, 5 Aug 2021 13:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, 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 0dMPuv_hzAic for ; Thu, 5 Aug 2021 13:24:21 -0700 (PDT) Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (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 28A9B3A0746 for ; Thu, 5 Aug 2021 13:24:21 -0700 (PDT) Received: by mail-pj1-x102b.google.com with SMTP id j1so11729868pjv.3 for ; Thu, 05 Aug 2021 13:24:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=crpCPA8dd36L+Ytdyl9Ww886GbVnwDa0IAFUqk0KV/Q=; b=GGNtW0fLfi9Qde59YLDnnx5rbCShiU1mIMA16QkQo7zLRNk3/hsNzWDUz0Cq+5jg7x ZGRbExLXvTioZbGUL4Gms5kl2qoyVBue5F6eaU3djBVfxYw0K6E4D/n1Ihkc/OiwwLLe ezErRkZDZ6NbEUs+SG24ARYP6mBV7BeCqsAdf2t4XbECrAksqicZy+yXriIJySrVLXpc pKvI1Etrc3Pf5IJ8cvHm/tzuOiU7MwVcLoj7EffSgcjCrhYwWQBsghqjPxjrqRV8N22b ZFcixHBHjxPVCyIY05vZOYQz5OJdicdWHvWlWVSpmQdH93rGBEVz8ODtTe4a/Bov0Yml ZdVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=crpCPA8dd36L+Ytdyl9Ww886GbVnwDa0IAFUqk0KV/Q=; b=RpUU4lS+mopxXcM63YjMHauuuo/gwcMWA2qcwz3hMAHvkrxqpEQ3gzoIYMABPoKb9w WpnOBv3w5wPF42V1L/Q69WJSmt50PmePPCXTKc9GJlpGQaqLv0L1N0zVvCE88XY6IeZc 3/c4RVi4qtkZDCIhOEz81zJyYWxLJqZsy69g4cddxIr5Eck3W9lujdPg3YnrdqCJ5Ffc dl72u4jRPgkEGQsAHfwxyhHPTineBwk1oQTJyMVzucXEYC0MTiaykihGJdiMzDYvJBUC o8Rl+z694j2JAXG9wtJhWcXr3TXB1nJdZRgIwTt6+MNaudseftIFnFYTD0+h4SyoZajO A6jQ== X-Gm-Message-State: AOAM532k3e3g0Beu/+GiUzno2+ufpywMalhOHEeWZdIl5xn/bIjYieX5 vla4eXmIB/v9pl2J4ttEtyMYgAbnVFzddIPu X-Google-Smtp-Source: ABdhPJxmaIpvv/gpq95mPEtlz5DCj+BvJ+olIfwoi66xj5Po/W8IV5HPvzk/EXkuXuXnmL9HW0XGLg== X-Received: by 2002:a17:902:7611:b029:12c:b602:5820 with SMTP id k17-20020a1709027611b029012cb6025820mr5773052pll.6.1628195060109; Thu, 05 Aug 2021 13:24:20 -0700 (PDT) Received: from [10.100.8.98] ([58.84.227.247]) by smtp.gmail.com with ESMTPSA id r7sm8917119pga.44.2021.08.05.13.24.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 Aug 2021 13:24:19 -0700 (PDT) To: Peter Saint-Andre , "Joel M. Halpern" Cc: "rfced-future@iab.org" References: <608f49c6-5e3e-637a-482d-15e48298beb9@joelhalpern.com> <010AEB19-A39C-46BB-8BBF-5BBA4B4B11C5@mnot.net> <7a9fca02-8897-bb5e-27cb-efe1b4ed8ab6@mozilla.com> <3290594c-a920-0ea5-4a28-ff867cbe54f7@joelhalpern.com> <5ebab763-f481-a83d-1db6-22a25839b97b@mozilla.com> From: Brian E Carpenter Message-ID: Date: Fri, 6 Aug 2021 08:24:14 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <5ebab763-f481-a83d-1db6-22a25839b97b@mozilla.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2021 20:24:25 -0000 Peter, On 06-Aug-21 04:55, Peter Saint-Andre wrote: > On 8/5/21 10:52 AM, Joel M. Halpern wrote: >> I am not following why what we are doing is not describing the "RFC >> Editor Model".=C2=A0 It appears that we are describing the whole proce= ss for >> habndling documents once streams say they want the document published.= >> that includes, policy, strategy, tactics, ...=C2=A0=C2=A0 The largest = piece of >> that is the process of editing the documents.=C2=A0=C2=A0 Sure, it is = not the only >> piece.=C2=A0 Nothing=C2=A0 is.=C2=A0=C2=A0 But seems to me that it is = the single most >> important part of what happens. >=20 > We could call it "RFC Series Policy Definition and Implementation" - as= > far as I can see, there's no reason (other than history) to call it the= > RFC Editor Model. I think history is a good reason, to avoid confusing the outside world. E= xpand it to RFC Editor Service perhaps, which is what the phrase has mean= t for many years anyway. Brian From nobody Thu Aug 5 14:02:33 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 251373A094D for ; Thu, 5 Aug 2021 14:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 PdkpvWaRq1ud for ; Thu, 5 Aug 2021 14:02:26 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BECF83A094C for ; Thu, 5 Aug 2021 14:02:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 599ED300C48 for ; Thu, 5 Aug 2021 17:02:26 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 7BPaz8cua8Q9 for ; Thu, 5 Aug 2021 17:02:25 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 1D53E300AEB for ; Thu, 5 Aug 2021 17:02:25 -0400 (EDT) From: Russ Housley Content-Type: multipart/alternative; boundary="Apple-Mail=_43EB7BCC-A579-4AC1-B609-8514C28D1AFF" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) Date: Thu, 5 Aug 2021 17:02:24 -0400 References: <608f49c6-5e3e-637a-482d-15e48298beb9@joelhalpern.com> <010AEB19-A39C-46BB-8BBF-5BBA4B4B11C5@mnot.net> To: "rfced-future@iab.org" In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3445.104.21) Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2021 21:02:31 -0000 --Apple-Mail=_43EB7BCC-A579-4AC1-B609-8514C28D1AFF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > IETF has the brand necessary to be recognised as the authoritative = site for RFCs. I believe that=E2=80=99s why some people have proposed a = docs.ietf.org site. This would be harmful to the IAB, IRTF, and Independent streams. Russ --Apple-Mail=_43EB7BCC-A579-4AC1-B609-8514C28D1AFF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

IETF has the = brand necessary to be recognised as the authoritative site for RFCs. =  I believe that=E2=80=99s why some people have proposed a docs.ietf.org site.

This would be = harmful to the IAB, IRTF, and Independent streams.

Russ

= --Apple-Mail=_43EB7BCC-A579-4AC1-B609-8514C28D1AFF-- From nobody Thu Aug 5 14:11:12 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69A493A09DD for ; Thu, 5 Aug 2021 14:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 focu7qEndeN5 for ; Thu, 5 Aug 2021 14:11:05 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 505D83A09C3 for ; Thu, 5 Aug 2021 14:11:05 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.43/8.16.0.43) with SMTP id 175LAwnp006009; Thu, 5 Aug 2021 22:11:03 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=cBPKOhPiwoT/mxKlejraG08XQToWo3jT0R1p+N6Vyfg=; b=QJlec1uRvXRhvRQRlkRAPjYrcpq84CSkPHUm2YseQEDbp59k/tdZjdXSeA/KfLogRz+a jzNnQAcQQ35Ldb7d+de+d6HHQ4wVJypuVJxAgzKIiilUdsEVWtGHaCGjOtUdbyt8rbPp BHYv2bo23SuIu10RnLvsHltf+J7EgncgX0LPJGL8zXyxLU97De2ybslXmELLdpibhoDi oXPP2JrjcmFJG85apA8WB/BNWz46kt5UMK0KMcxFUOS8egnU1JaxxUGAlFTrEETTCeDV VEyi2nB+ubHTFiOvP5fF828E3PHIL8GsS7AVDKkk2/guukogiBmkO+MSzk547pBoXVBo YA== Received: from prod-mail-ppoint8 (a72-247-45-34.deploy.static.akamaitechnologies.com [72.247.45.34] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 3a8kn877tj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 05 Aug 2021 22:11:03 +0100 Received: from pps.filterd (prod-mail-ppoint8.akamai.com [127.0.0.1]) by prod-mail-ppoint8.akamai.com (8.16.1.2/8.16.1.2) with SMTP id 175L5QND015539; Thu, 5 Aug 2021 17:11:02 -0400 Received: from email.msg.corp.akamai.com ([172.27.165.112]) by prod-mail-ppoint8.akamai.com with ESMTP id 3a7e0u6cn6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 05 Aug 2021 17:11:02 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.165.119) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.165.122) with Microsoft SMTP Server (TLS) id 15.0.1497.23; Thu, 5 Aug 2021 16:11:01 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.165.119]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.165.119]) with mapi id 15.00.1497.023; Thu, 5 Aug 2021 16:11:01 -0500 From: "Salz, Rich" To: Russ Housley , "rfced-future@iab.org" Thread-Topic: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? Thread-Index: AQHXh7cktkW9ZM+/m0qw1EJYogsGzathG4WAgAAIEYCAAlLAgIAA6ScAgAATDgCAAAYvAIAAFXaAgAAFmACAAB2KgIABDXIA//+/WQA= Date: Thu, 5 Aug 2021 21:11:00 +0000 Message-ID: <5B17CCD6-B516-4B92-A9DF-66609F37BD03@akamai.com> References: <608f49c6-5e3e-637a-482d-15e48298beb9@joelhalpern.com> <010AEB19-A39C-46BB-8BBF-5BBA4B4B11C5@mnot.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.51.21071101 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.164.43] Content-Type: multipart/alternative; boundary="_000_5B17CCD6B5164B92A9DF66609F37BD03akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-08-05_10:2021-08-05, 2021-08-05 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 adultscore=0 mlxlogscore=999 mlxscore=0 phishscore=0 bulkscore=0 malwarescore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2107140000 definitions=main-2108050124 X-Proofpoint-GUID: rShCDLsNMhuoMXJqkFfS0nDU77sXPcxx X-Proofpoint-ORIG-GUID: rShCDLsNMhuoMXJqkFfS0nDU77sXPcxx X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-08-05_10:2021-08-05, 2021-08-05 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1015 adultscore=0 phishscore=0 spamscore=0 mlxscore=0 suspectscore=0 lowpriorityscore=0 mlxlogscore=976 bulkscore=0 malwarescore=0 impostorscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2107140000 definitions=main-2108050125 X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 72.247.45.34) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint8 Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2021 21:11:10 -0000 --_000_5B17CCD6B5164B92A9DF66609F37BD03akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCiAgKiAgIFtkb2NzLmlldGYub3JnXSBUaGlzIHdvdWxkIGJlIGhhcm1mdWwgdG8gdGhlIElB QiwgSVJURiwgYW5kIEluZGVwZW5kZW50IHN0cmVhbXMuDQoNCkl04oCZcyBub3QgYW4gb2J2aW91 cyBkZWNpc2lvbi4gIE9uIHRoZSBvbmUgaGFuZCwgd2Ugc2VlbSB0byBvZnRlbiBydW4gaW50byBj YXNlcyB3aGVyZSBvdGhlciBvcmdhbml6YXRpb25zLCBpbmNsdWRpbmcgU0RP4oCZcywgdHJlYXQg dGhvc2Ugc3RyZWFtcyBhcyDigJxJRVRGIFN0YW5kYXJkc+KAnSBIYXZpbmcgYSBzaW5nbGUgcGxh Y2Ugd2hlcmUgc3VjaCDigJxJRVRGIFN0YW5kYXJkc+KAnSBhcmUgZm91bmQgc2VlbXMgbGlrZSBh IGdvb2QgdGhpbmcgdG8gbWUuIE9uIHRoZSBvdGhlciBoYW5kLCBoYXZpbmcgYSB1bmlmaWVkIHBs YWNlIGZvciBBTEwgdGhlIFJGQyBzdHJlYW1zIGFsc28gc2VlbXMgd29ydGh3aGlsZS4gIEx1Y2tp bHkgd2Vic2l0ZXMgYXJlIGNoZWFwIGVub3VnaCB0aGVzZSBkYXlzIHRoYXQgd2UgY2FuIGhhdmUg Ym90aC4gUGVyaGFwcyBkb2NzLmlhYi5vcmcgYW5kIGRvY3MuaXJ0Zi5vcmcgbWFrZSBzZW5zZSwg YWx0aG91Z2ggSSBoYXZlIG5vIGlkZWEgd2hhdCBkb2NzLmluZGVwZW5kYW50LXN0cmVhbS5pZXRm Py5vcmcgc2hvdWxkIGJlIGNhbGxlZC4NCg== --_000_5B17CCD6B5164B92A9DF66609F37BD03akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <02E1D9B8E6EBBD4391B796018BAC9FEF@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0 UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCglt YXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0 LWlkOjk3NTM3OTY2MTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0 ZS1pZHM6LTc0ODYzODQzNiAtMjAxMDczODg4OCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2 NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDps ZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIjsNCgltc28tYmlkaS1mb250LWZhbWlseTpDYWxpYnJpO30NCkBsaXN0IGwwOmxl dmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVs DQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9IndvcmQtd3JhcDpicmVh ay13b3JkOy13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTtsaW5lLWJyZWFrOmFmdGVyLXdoaXRlLXNw YWNlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8dWwgc3R5bGU9Im1h cmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+W2RvY3MuaWV0 Zi5vcmddIFRoaXMgd291bGQgYmUgaGFybWZ1bCB0byB0aGUgSUFCLCBJUlRGLCBhbmQgSW5kZXBl bmRlbnQgc3RyZWFtcy48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdOKA mXMgbm90IGFuIG9idmlvdXMgZGVjaXNpb24uJm5ic3A7IE9uIHRoZSBvbmUgaGFuZCwgd2Ugc2Vl bSB0byBvZnRlbiBydW4gaW50byBjYXNlcyB3aGVyZSBvdGhlciBvcmdhbml6YXRpb25zLCBpbmNs dWRpbmcgU0RP4oCZcywgdHJlYXQgdGhvc2Ugc3RyZWFtcyBhcyDigJxJRVRGIFN0YW5kYXJkc+KA nSBIYXZpbmcgYSBzaW5nbGUgcGxhY2Ugd2hlcmUgc3VjaCDigJxJRVRGIFN0YW5kYXJkc+KAnSBh cmUgZm91bmQgc2VlbXMgbGlrZSBhDQogZ29vZCB0aGluZyB0byBtZS4gT24gdGhlIG90aGVyIGhh bmQsIGhhdmluZyBhIHVuaWZpZWQgcGxhY2UgZm9yIEFMTCB0aGUgUkZDIHN0cmVhbXMgYWxzbyBz ZWVtcyB3b3J0aHdoaWxlLiZuYnNwOyBMdWNraWx5IHdlYnNpdGVzIGFyZSBjaGVhcCBlbm91Z2gg dGhlc2UgZGF5cyB0aGF0IHdlIGNhbiBoYXZlIGJvdGguIFBlcmhhcHMgZG9jcy5pYWIub3JnIGFu ZCBkb2NzLmlydGYub3JnIG1ha2Ugc2Vuc2UsIGFsdGhvdWdoIEkgaGF2ZSBubyBpZGVhIHdoYXQN CiBkb2NzLmluZGVwZW5kYW50LXN0cmVhbS5pZXRmPy5vcmcgc2hvdWxkIGJlIGNhbGxlZC48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_5B17CCD6B5164B92A9DF66609F37BD03akamaicom_-- From nobody Thu Aug 5 16:36:15 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA3EF3A112C for ; Thu, 5 Aug 2021 16:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=nR8haiES; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=tavir3tE 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 H9-OkAtH2bwU for ; Thu, 5 Aug 2021 16:36:09 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E11C93A1129 for ; Thu, 5 Aug 2021 16:36:08 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 0C0305C0131; Thu, 5 Aug 2021 19:36:08 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 05 Aug 2021 19:36:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=6 iY+AtWh0AseB5dWVbzhlG0mLCvRKu/g6kkLBOoC5Y8=; b=nR8haiESpFOcjUL1X oUiAdU6SwvR1Yn4joKEl+xxRAAXkat5gdI56bsAtxqNwJs3lApyuxAV/pHGnwG0+ eoYS/yikIwssJWz1mHoYITo/mtK/y3bDTSL7M67lrrrc/fYygPAsWbhiwD+Fir14 ZxkAzdues/Zcxd+VHm7sTe2neSlyd3ORdWuJSqhw+lckQH07hBX3XIFHSI/9+Vdo tEWqulSx/Fy0zROwGOssOERX3paEavepaaSOi8UoMls3LBsq5iVDDVJDa9hS6fOU 1aIFSWwyhZNjvGZnXfZ8EZYalsMdsQMCxoNzdfoaphHYoYSb5zaSd0NWTJqG1qe/ UBz9Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=6iY+AtWh0AseB5dWVbzhlG0mLCvRKu/g6kkLBOoC5 Y8=; b=tavir3tEG25kxsO3c8beFZUJ1+QYWLdsTbK06Xuw2Vgb0is5LJGqi4jiS xIEnsWzkwen3br5UMOMzL6cck9qPyIjKK894+mdRH8uVaX9mfVmcoLnaQRPGLUM3 cKzyP72XG+oJtmPhhNvxRsiGdWpRu5oTmjxhcGT5GLDWsPpv0oM9bRQCB4NL9rSA Y9N7FNMBqXO8PJn6Rp+6WsN+br0f+Lxe6SmSxot8RfB2/vVQ2tOS34zIKkZroPhK x9+NI7VU9Z45bYI0ts5x8bUkob4SnhlFWqQYqV7WiA6xT3wQyYwxus5Bjf5lqYh+ aZCazC1BnwrxUib6NtpMGu8P57gew== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrjedtgddvtdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepvefffffhudetveevhfeuffeigedtuedtheffleetffeftddtgeegjeehieeuteet necuffhomhgrihhnpehmnhhothdrnhgvthenucevlhhushhtvghrufhiiigvpedtnecurf grrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 5 Aug 2021 19:36:04 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Mark Nottingham In-Reply-To: Date: Fri, 6 Aug 2021 09:36:02 +1000 Cc: Peter Saint-Andre , "Joel M. Halpern" , "rfced-future@iab.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <608f49c6-5e3e-637a-482d-15e48298beb9@joelhalpern.com> <010AEB19-A39C-46BB-8BBF-5BBA4B4B11C5@mnot.net> <7a9fca02-8897-bb5e-27cb-efe1b4ed8ab6@mozilla.com> <3290594c-a920-0ea5-4a28-ff867cbe54f7@joelhalpern.com> <5ebab763-f481-a83d-1db6-22a25839b97b@mozilla.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2021 23:36:14 -0000 > On 6 Aug 2021, at 6:24 am, Brian E Carpenter = wrote: >=20 > I think history is a good reason, to avoid confusing the outside = world. Expand it to RFC Editor Service perhaps, which is what the phrase = has meant for many years anyway. That's a really good idea actually -- it would allow us to keep using = the same domain name and just tweak the documentation a bit.=20 Brian, would you consider using 'RFC Editing Service' in the = documentation as workable? Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Thu Aug 5 16:40:27 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56D9D3A114E for ; Thu, 5 Aug 2021 16:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=k/6PNiAG; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=hypZBVgA 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 TN-Vj9thE9Ri for ; Thu, 5 Aug 2021 16:40:20 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 208733A114F for ; Thu, 5 Aug 2021 16:40:20 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 6E58C5C013F; Thu, 5 Aug 2021 19:40:19 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Thu, 05 Aug 2021 19:40:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=g hTM9a3/OJYlFjGlmZvxXnQ4jBanxusQbxTITxfv7IU=; b=k/6PNiAGyU5AYDihp IWkFMIM0VrSUCvbI6JNP2aMoXgwXSmqPDW03iVk9oWZIzgPKvDI8kSEnJiJJY0fH QpWzikdM8i75xq14XoNNBDyvQp7TTKintYdp3ea4HYw3iNwv3tPWahNi5ZpzOZvi soy67xV6N34XhV2NwY4chchZ9fZ3ti0LomxmGb0VXRkKm8jWNLytwwZQb4YUoFvE 4XxyaJZ+GLRFQVJrtetIbpLhOY3tx4QaLZPSp++hN23F7+5EVNdbkhJe+xDoGaw9 j42NW+pSCiy2LXgWTBEnaaJVxOa5DqbENlNXiBx04Tt2S8O5VC3cGxOuO0L1A3ak hv5ng== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=ghTM9a3/OJYlFjGlmZvxXnQ4jBanxusQbxTITxfv7 IU=; b=hypZBVgA8JZOTFvzNF6UBySceBTL91C1TlX498rUeJP8o7xdWCq0gUbkM AdvcrnfEnUo+22NRDDUBJBB76mQY2n2N6LAssa6lDzTFwin/IxDxvX1vVt4TjV6A D2Qg9YsunDfaoSvmDrfrPzrf+ffQKLZTzD/nhShv49hWvwHiGk0u7VuXwQsCALMR 0MSb3mix8vYUGCfgzfD+hYs2Kl3j+tB4Hb9rNbHZIVTb8mfQFdQfnjaeFWzm8Yon +Rc5fLincuI5JwsuhFS73wX72xgLokWrTG4sfoxMdwW9CeEcRPtQqHwqB/RnOwOV lsrYBCAUfcH4x0aIfBcUHoWnpXTfg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrjedtgddvvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtjehmtdhhtddvnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepueetgeejtdelkeduueejfeethfffhfduieelleefgeduudeuvdfgjeffleeiledv necuffhomhgrihhnpehirggsrdhorhhgpdhmnhhothdrnhgvthenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 5 Aug 2021 19:40:15 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Mark Nottingham In-Reply-To: <5ebab763-f481-a83d-1db6-22a25839b97b@mozilla.com> Date: Fri, 6 Aug 2021 09:40:15 +1000 Cc: "Joel M. Halpern" , "rfced-future@iab.org" Content-Transfer-Encoding: 7bit Message-Id: References: <608f49c6-5e3e-637a-482d-15e48298beb9@joelhalpern.com> <010AEB19-A39C-46BB-8BBF-5BBA4B4B11C5@mnot.net> <7a9fca02-8897-bb5e-27cb-efe1b4ed8ab6@mozilla.com> <3290594c-a920-0ea5-4a28-ff867cbe54f7@joelhalpern.com> <5ebab763-f481-a83d-1db6-22a25839b97b@mozilla.com> To: Peter Saint-Andre X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2021 23:40:25 -0000 That's also a good suggestion. > On 6 Aug 2021, at 2:55 am, Peter Saint-Andre wrote: > > On 8/5/21 10:52 AM, Joel M. Halpern wrote: >> I am not following why what we are doing is not describing the "RFC >> Editor Model". It appears that we are describing the whole process for >> habndling documents once streams say they want the document published. >> that includes, policy, strategy, tactics, ... The largest piece of >> that is the process of editing the documents. Sure, it is not the only >> piece. Nothing is. But seems to me that it is the single most >> important part of what happens. > > We could call it "RFC Series Policy Definition and Implementation" - as > far as I can see, there's no reason (other than history) to call it the > RFC Editor Model. > > Peter > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future -- Mark Nottingham https://www.mnot.net/ From nobody Thu Aug 5 16:56:56 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 161993A1200 for ; Thu, 5 Aug 2021 16:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 1R3mKrERCFIR for ; Thu, 5 Aug 2021 16:56:51 -0700 (PDT) Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (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 96D663A11FD for ; Thu, 5 Aug 2021 16:56:51 -0700 (PDT) Received: by mail-ot1-x32e.google.com with SMTP id 61-20020a9d0d430000b02903eabfc221a9so7037348oti.0 for ; Thu, 05 Aug 2021 16:56:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xb78nVqNwF5uP3aSpmuUl4gYgm+V+3HP6e2KOmcJtrY=; b=OiPPJ/W9c8n09pejfFGeUA//xsANiMQZ76/5BJDn+HT4+XSlHjxRkdyIumgWRch57p e0l96ajyo8in5bPeHXC7gwi4N0OtOO3mVmMwvKm6Ue6qXVNkNtuXxu5uFbj4ninrLO3x Bc0o3dbzycxvgTXnL300d4QlzoHD1ws1+bXjw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xb78nVqNwF5uP3aSpmuUl4gYgm+V+3HP6e2KOmcJtrY=; b=fLn7uqOJaxZguc5pXSjN3TS0BmoMf5ziQuIot9G4wlUA8+Y/f2vWdP8knSyjFX2EKY FvFmPvzaYku4c1UhU1oZvEVb2ArkSsjPAnNUON/IvRc8hJowKUN7Z8yNk9cpAKEkhnxg xYBrmdw4QAleNTGDkfQOQCj774HSBEPcRklntKtaTbkOjRGdDBrCuj4uW+4G3xef5vAJ 6iTFQpHBe+lKr70Rcrtl/5NbHlMzXiFCVzlCFN5BCM2D6njqHhSZkWOpBJBKUZGL1jsC Hw7DCX0AwLt89in5/C66Y4ZvilSd5K2zsreV4S82tDNBU64/9G4gsvOQi/o58KaNWXAL mqOg== X-Gm-Message-State: AOAM530NI1fsoCdt/ybK5JRp4a84DN+88oGri6o3V4FCrDkPcE3Ctnuh ezdMHrb2jlyMbjr8H78PsBQpnz7VITV0Dg== X-Google-Smtp-Source: ABdhPJzByFqbS6yuHF0JLQS5GAlm7YMMVNLpQLcU/o50ADNEgpQiumvseMRZBq2hCRlH8ApgiNVvQg== X-Received: by 2002:a05:6830:15d6:: with SMTP id j22mr5611304otr.41.1628207809740; Thu, 05 Aug 2021 16:56:49 -0700 (PDT) Received: from ?IPv6:fd01:5ca1:ab1e:8d1f:ce9c:57c4:f955:5c81? ([2a09:bac0:98::830:8622]) by smtp.gmail.com with ESMTPSA id b26sm1217078otq.78.2021.08.05.16.56.48 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Aug 2021 16:56:49 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Peter Saint-Andre X-Mailer: iPhone Mail (16H50) In-Reply-To: Date: Thu, 5 Aug 2021 17:56:47 -0600 Cc: "Joel M. Halpern" , "rfced-future@iab.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <608f49c6-5e3e-637a-482d-15e48298beb9@joelhalpern.com> <010AEB19-A39C-46BB-8BBF-5BBA4B4B11C5@mnot.net> <7a9fca02-8897-bb5e-27cb-efe1b4ed8ab6@mozilla.com> <3290594c-a920-0ea5-4a28-ff867cbe54f7@joelhalpern.com> <5ebab763-f481-a83d-1db6-22a25839b97b@mozilla.com> To: Mark Nottingham Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2021 23:56:56 -0000 For the avoidance of doubt, I meant as the title of the document we=E2=80=99= re working on. > On Aug 5, 2021, at 5:40 PM, Mark Nottingham wrote: >=20 > That's also a good suggestion. >=20 >> On 6 Aug 2021, at 2:55 am, Peter Saint-Andre wrote:= >>=20 >> On 8/5/21 10:52 AM, Joel M. Halpern wrote: >>> I am not following why what we are doing is not describing the "RFC >>> Editor Model". It appears that we are describing the whole process for >>> habndling documents once streams say they want the document published. >>> that includes, policy, strategy, tactics, ... The largest piece of >>> that is the process of editing the documents. Sure, it is not the only= >>> piece. Nothing is. But seems to me that it is the single most >>> important part of what happens. >>=20 >> We could call it "RFC Series Policy Definition and Implementation" - as >> far as I can see, there's no reason (other than history) to call it the >> RFC Editor Model. >>=20 >> Peter >>=20 >> --=20 >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 From nobody Thu Aug 5 17:11:10 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2CD3A12A5 for ; Thu, 5 Aug 2021 17:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 bfepcGqo_yhf for ; Thu, 5 Aug 2021 17:11:04 -0700 (PDT) Received: from mx36-out21.antispamcloud.com (mx36-out21.antispamcloud.com [209.126.121.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C90B93A129D for ; Thu, 5 Aug 2021 17:11:04 -0700 (PDT) Received: from xse238.mail2web.com ([66.113.196.238] helo=xse.mail2web.com) by mx135.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1mBnS0-000VMJ-Af for rfced-future@iab.org; Fri, 06 Aug 2021 02:11:03 +0200 Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 4Ggm8n1c9bzmWb for ; Thu, 5 Aug 2021 17:10:49 -0700 (PDT) Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1mBnRp-0007Qw-3V for rfced-future@iab.org; Thu, 05 Aug 2021 17:10:49 -0700 Received: (qmail 14175 invoked from network); 6 Aug 2021 00:10:48 -0000 Received: from unknown (HELO [192.168.1.104]) (Authenticated-user:_huitema@huitema.net@[172.58.43.233]) (envelope-sender ) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 6 Aug 2021 00:10:48 -0000 To: Russ Housley , "rfced-future@iab.org" References: <608f49c6-5e3e-637a-482d-15e48298beb9@joelhalpern.com> <010AEB19-A39C-46BB-8BBF-5BBA4B4B11C5@mnot.net> From: Christian Huitema Message-ID: <92bf81a4-a6ae-b479-d914-653f396610b0@huitema.net> Date: Thu, 5 Aug 2021 17:10:48 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Originating-IP: 66.113.196.238 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.196.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.63) X-Recommended-Action: accept X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT8GEhubP5XdEQM6XF4Sz7PpPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5yXEnUqtuiszqcStXlDoE9S53HEEk0VSrq03gtFxbC/KmtM ts4gcGIGwiWy7eIDHlNwGYjbvhzWX8Co+5c+eruaSxIRXVMlFuiz/acFNeeXtxN2fFxZWB9eYgpR BRu3UlDHMLIJYRi1cXH9Dbm+IxLV0XgtlP1veEWDxFjeo42e2HGFd932lfz+R/06O3Iy4alsvCwp YJpdb4B2L4Z5wQyKkVWClPVvbW5lVyQanRxw5hTHswbbB/ha+ZWrSAi8SkwqWAikMcSxTAWn8RCv ieGEqjG/gXZAaRh1X6LVetRf2ZYIiHqfCgG4wrA3w4/kQTYKxDHA9JN9J4k4XZq11JQkMemT4rxn nByU11Ftkqf3f/PF3GUV+KdBBqrnCX8j0Gi8Ksk+aedMfNWSnJswrtlNtZo3HPHi5Q+jjsF5dcBx ehWYzrkgsp4/Fysgb2cPV4IH0+lPwKr4i5mAANUcVraZYOaeuiH/yEdZH8S1+TgcJBOjh0vPxcQO jKKOrYIQYpwamUdylUIKhf3z2GAHxH7Iiihnln5nLwsYugixy853dgGI409Uexq5zP1TE60A1w5l JnbrqXm52nXpf60dIAlsb3UQT3xbkHqpqmyCe4PiKWIgJ2XxgK7Je5b0uU+cZFhDVPQ6fMev1BMP vQ9qu4cW0z6bhalFEM/pjPCQA+BAlg6DLMwYKqvvUSxfP+dIrF23h1ESmlc3/lS5x7qxkdlaaAJ/ rZSJY1rK1jwEE99YupL8ANDm8RxhsgxUo+ftg2ZRXxKF5tPxTxfD0dMN+t5Zb/aSOylr84Fo+I/w RqPplV0K1XacwNVrdseLPwMNJOyN9/YGRrhMRGhIOTxMW00yF8F1u0YDQf8cLP9taeSLFY0fPBnF 89BphpBNlUg+TzHwBTL1+6vDOMemz/4I88NDcmnEJ4r7C+SwLRamrhQTd3PrpJpP5ewAjeqkzRNl ucyd+NO2McmveAr4ch9F7rE89jihx+Za/cV70jOJzN2r4A== X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2021 00:11:09 -0000 On 8/5/2021 2:02 PM, Russ Housley wrote: >> IETF has the brand necessary to be recognised as the authoritative sit= e for RFCs. I believe that=E2=80=99s why some people have proposed a doc= s.ietf.org site. > This would be harmful to the IAB, IRTF, and Independent streams. Is there a way to quantify how harmful that would be? I observe that=20 drafts targeting the IAB stream, the IRTF or independent stream are=20 commonly indexed in the IETF datatracker, and nobody seems to argue=20 that's causing harm. I think that having the RFC available on an IETF=20 document site would cut both ways -- more visibility for the documents=20 because they will benefit from the reputation of the IETF; but maybe=20 fewer visibility for the IRTF and Independent series as organization.=20 Maybe, because increased visibility of the documents will also increase=20 visibility of IRTF and Independent series, given proper indexing. -- Christian Huitema From nobody Thu Aug 5 17:21:48 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 599023A131F for ; Thu, 5 Aug 2021 17:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 gmCbYMR3HWbM for ; Thu, 5 Aug 2021 17:21:43 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F117B3A131B for ; Thu, 5 Aug 2021 17:21:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4GgmPL4JhJz1nspL; Thu, 5 Aug 2021 17:21:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1628209302; bh=PxdebGmz0SjA/2ZSJax1nldtM0hgvd68eugtCUtGzbc=; h=Subject:To:References:From:Date:In-Reply-To:From; b=ZMG6y2I9plxhVjIaYBR4KKdH/IaQx5AwcJSrgFiF/zGbJTGr9heZYt+jlJHl5fs8S J88nmx9r/+2ay9XV0gw427De+d7XGKwAO6cKuHkuxcdKfyvZdClnd3A9KR7UKS/Ih4 fyDIv54Qx3E8B3eI5VifbkK8QRl/wKdzbn/zvvM0= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.23.64] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4GgmPK5Vm7z1nsXm; Thu, 5 Aug 2021 17:21:41 -0700 (PDT) To: Christian Huitema , "rfced-future@iab.org" References: <608f49c6-5e3e-637a-482d-15e48298beb9@joelhalpern.com> <010AEB19-A39C-46BB-8BBF-5BBA4B4B11C5@mnot.net> <92bf81a4-a6ae-b479-d914-653f396610b0@huitema.net> From: "Joel M. Halpern" Message-ID: <5388c440-67b9-4696-38db-929393c02d54@joelhalpern.com> Date: Thu, 5 Aug 2021 20:21:40 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <92bf81a4-a6ae-b479-d914-653f396610b0@huitema.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2021 00:21:47 -0000 Christian, you seem to be mixing two things here. We (the historic and current RFC community in the large) have always been clear that anyone can index, store, copy, make avaialble, etc. the RFCs. The fact that the IETF does so via the datatracker (and tools) sites fits just fine with that. Moving the official repository for the RFC series under the IETF domain is asserting that the IETF owns the RFC series. it doesn't. that kind of change would be, as far as I can tell, inherently harmful to the nature of the series. And spliting the various parts of the series so that the use different web sites as their official presence would be destroying much of the coherence of the series. I do not think that is a good idea. Yours, Joel On 8/5/2021 8:10 PM, Christian Huitema wrote: > > On 8/5/2021 2:02 PM, Russ Housley wrote: >>> IETF has the brand necessary to be recognised as the authoritative >>> site for RFCs.  I believe that’s why some people have proposed a >>> docs.ietf.org site. >> This would be harmful to the IAB, IRTF, and Independent streams. > > Is there a way to quantify how harmful that would be? I observe that > drafts targeting the IAB stream, the IRTF or independent stream are > commonly indexed in the IETF datatracker, and nobody seems to argue > that's causing harm. I think that having the RFC available on an IETF > document site would cut both ways -- more visibility for the documents > because they will benefit from the reputation of the IETF; but maybe > fewer visibility for the IRTF and Independent series as organization. > Maybe, because increased visibility of the documents will also increase > visibility of IRTF and Independent series, given proper indexing. > > -- Christian Huitema > > From nobody Thu Aug 5 17:28:16 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD323A1360 for ; Thu, 5 Aug 2021 17:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 x2G-r17p9mOl; Thu, 5 Aug 2021 17:28:09 -0700 (PDT) Received: from smtpclient.apple (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id BF8FC3A135B; Thu, 5 Aug 2021 17:28:08 -0700 (PDT) From: Jay Daley Message-Id: <0077D4B0-4954-490C-B98C-D27977F902A6@ietf.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_13A04990-36B1-4CDF-B41C-9B94088D29D6" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Fri, 6 Aug 2021 12:28:04 +1200 In-Reply-To: <5388c440-67b9-4696-38db-929393c02d54@joelhalpern.com> Cc: Christian Huitema , "rfced-future@iab.org" To: "Joel M. Halpern" References: <608f49c6-5e3e-637a-482d-15e48298beb9@joelhalpern.com> <010AEB19-A39C-46BB-8BBF-5BBA4B4B11C5@mnot.net> <92bf81a4-a6ae-b479-d914-653f396610b0@huitema.net> <5388c440-67b9-4696-38db-929393c02d54@joelhalpern.com> X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2021 00:28:15 -0000 --Apple-Mail=_13A04990-36B1-4CDF-B41C-9B94088D29D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 6/08/2021, at 12:21 PM, Joel M. Halpern = wrote: >=20 > Christian, you seem to be mixing two things here. >=20 > We (the historic and current RFC community in the large) have always = been clear that anyone can index, store, copy, make avaialble, etc. the = RFCs. The fact that the IETF does so via the datatracker (and tools) = sites fits just fine with that. I think Christian was talking about I-Ds not RFCs, which are only = available under the Datatracker or tools.ietf.org = (though that part is going) whatever the = stream, Jay >=20 > Moving the official repository for the RFC series under the IETF = domain is asserting that the IETF owns the RFC series. it doesn't. = that kind of change would be, as far as I can tell, inherently harmful = to the nature of the series. >=20 > And spliting the various parts of the series so that the use different = web sites as their official presence would be destroying much of the = coherence of the series. I do not think that is a good idea. >=20 > Yours, > Joel >=20 > On 8/5/2021 8:10 PM, Christian Huitema wrote: >> On 8/5/2021 2:02 PM, Russ Housley wrote: >>>> IETF has the brand necessary to be recognised as the authoritative = site for RFCs. I believe that=E2=80=99s why some people have proposed a = docs.ietf.org site. >>> This would be harmful to the IAB, IRTF, and Independent streams. >> Is there a way to quantify how harmful that would be? I observe that = drafts targeting the IAB stream, the IRTF or independent stream are = commonly indexed in the IETF datatracker, and nobody seems to argue = that's causing harm. I think that having the RFC available on an IETF = document site would cut both ways -- more visibility for the documents = because they will benefit from the reputation of the IETF; but maybe = fewer visibility for the IRTF and Independent series as organization. = Maybe, because increased visibility of the documents will also increase = visibility of IRTF and Independent series, given proper indexing. >> -- Christian Huitema >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future --=20 Jay Daley IETF Executive Director jay@ietf.org --Apple-Mail=_13A04990-36B1-4CDF-B41C-9B94088D29D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 6/08/2021, at 12:21 PM, Joel M. Halpern <jmh@joelhalpern.com>= wrote:

Christian, you seem to be mixing two things here.

We (the historic and current RFC community in = the large) have always been clear that anyone can index, store, copy, = make avaialble, etc. the RFCs.  The fact that the IETF does so via = the datatracker (and tools) sites fits just fine with that.

I = think Christian was talking about I-Ds not RFCs, which are only = available under the Datatracker or tools.ietf.org (though that part is going) whatever = the stream,

Jay


Moving the official repository for the RFC = series under the IETF domain is asserting that the IETF owns the RFC = series.  it doesn't.   that kind of change would be, as = far as I can tell, inherently harmful to the nature of the series.

And spliting the various parts of the series = so that the use different web sites as their official presence would be = destroying much of the coherence of the series.   I do not = think that is a good idea.

Yours,
Joel

On 8/5/2021 8:10 PM, = Christian Huitema wrote:
On 8/5/2021 2:02 PM, Russ Housley wrote:
IETF has the brand necessary to be recognised as the = authoritative site for RFCs.  I believe that=E2=80=99s why some = people have proposed a docs.ietf.org <http://docs.ietf.org/> site.
This would be harmful to the IAB, IRTF, and = Independent streams.
Is there a way to = quantify how harmful that would be? I observe that drafts targeting the = IAB stream, the IRTF or independent stream are commonly indexed in the = IETF datatracker, and nobody seems to argue that's causing harm. I think = that having the RFC available on an IETF document site would cut both = ways -- more visibility for the documents because they will benefit from = the reputation of the IETF; but maybe fewer visibility for the IRTF and = Independent series as organization. Maybe, because increased visibility = of the documents will also increase visibility of IRTF and Independent = series, given proper indexing.
-- Christian Huitema

--
Rfced-future = mailing list
Rfced-future@iab.org
https://www.iab.org/mailman/listinfo/rfced-future

-- 
Jay Daley
IETF = Executive Director
jay@ietf.org

= --Apple-Mail=_13A04990-36B1-4CDF-B41C-9B94088D29D6-- From nobody Thu Aug 5 17:37:50 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1493D3A13BE for ; Thu, 5 Aug 2021 17:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no 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 H8MXFX1iQHJt for ; Thu, 5 Aug 2021 17:37:39 -0700 (PDT) Received: from mx36-out21.antispamcloud.com (mx36-out21.antispamcloud.com [209.126.121.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D54A3A13C1 for ; Thu, 5 Aug 2021 17:37:39 -0700 (PDT) Received: from xse174.mail2web.com ([66.113.196.174] helo=xse.mail2web.com) by mx134.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1mBnri-0005sU-TL for rfced-future@iab.org; Fri, 06 Aug 2021 02:37:37 +0200 Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 4GgmlY5ZshzLb6 for ; Thu, 5 Aug 2021 17:37:29 -0700 (PDT) Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1mBnrd-0005sJ-LN for rfced-future@iab.org; Thu, 05 Aug 2021 17:37:29 -0700 Received: (qmail 9639 invoked from network); 6 Aug 2021 00:37:29 -0000 Received: from unknown (HELO [192.168.1.104]) (Authenticated-user:_huitema@huitema.net@[172.58.43.233]) (envelope-sender ) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 6 Aug 2021 00:37:29 -0000 To: Jay Daley , "Joel M. Halpern" Cc: "rfced-future@iab.org" References: <608f49c6-5e3e-637a-482d-15e48298beb9@joelhalpern.com> <010AEB19-A39C-46BB-8BBF-5BBA4B4B11C5@mnot.net> <92bf81a4-a6ae-b479-d914-653f396610b0@huitema.net> <5388c440-67b9-4696-38db-929393c02d54@joelhalpern.com> <0077D4B0-4954-490C-B98C-D27977F902A6@ietf.org> From: Christian Huitema Message-ID: Date: Thu, 5 Aug 2021 17:37:29 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <0077D4B0-4954-490C-B98C-D27977F902A6@ietf.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Originating-IP: 66.113.196.174 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.196.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9WLQux0N3HQm8ltz8rnu+BPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5yXEnUqtuiszqcStXlDoE9S53HEEk0VSrq03gtFxbC/Ks1N AYn79VOeuiuTZNFHBW1izSh2f1rWsE3ZhyRR3OEySxIRXVMlFuiz/acFNeeXtxN2fFxZWB9eYgpR BRu3UlDHMLIJYRi1cXH9Dbm+IxLV0XgtlP1veEWDxFjeo42e2HGFd932lfz+R/06O3Iy4amLIlhV wP2HQYvX8wxRXZtkkVWClPVvbW5lVyQanRxw5hTHswbbB/ha+ZWrSAi8SkwqWAikMcSxTAWn8RCv ieGEqjG/gXZAaRh1X6LVetRf2ZYIiHqfCgG4wrA3w4/kQTYKxDHA9JN9J4k4XZq11JQkMemT4rxn nByU11Ftkqf3f/PF3GUV+KdBBqrnCX8j0Gi8Ksk+aedMfNWSnJswrtlNtZo3HPHi5Q+jjsF5dcBx ehWYzrkgsp4/Fysgb2cPV4IH0+lPwKr4i5mAANUcVraZYOaeuiH/yEdZH8S1+TgcJBOjh0vPxcQO jKKOrYIQYpwamUdylUIKhf3z2GAHxH7Iiihnln5nLwsYugixy853dlAMC5uyzWopS9Dc1M1eiebL hWiAG1UJOewnqmJFrB62b3UQT3xbkHqpqmyCe4PiKWIgJ2XxgK7Je5b0uU+cZFhDVPQ6fMev1BMP vQ9qu4cW0z6bhalFEM/pjPCQA+BAllMGj5qlFdUz6/ReAYEhjqi3h1ESmlc3/lS5x7qxkdlaMjzK j7zONj0h+FGUqSPTrOstoD7cw8yeto5tp+EaTC9RXxKF5tPxTxfD0dMN+t5ZxogLlovammWbZjS+ Ba2H5i7WcVfvwPW+1tEygn0RV92N9/YGRrhMRGhIOTxMW00yF8F1u0YDQf8cLP9taeSLFY0fPBnF 89BphpBNlUg+TzHwBTL1+6vDOMemz/4I88NDcmnEJ4r7C+SwLRamrhQTd3PrpJpP5ewAjeqkzRNl ucyd+NO2McmveAr4ch9F7rE89jihx+Za/cV70jOJzN2r4A== X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2021 00:37:44 -0000 On 8/5/2021 5:28 PM, Jay Daley wrote: > >> On 6/08/2021, at 12:21 PM, Joel M. Halpern wrote= : >> >> Christian, you seem to be mixing two things here. >> >> We (the historic and current RFC community in the large) have always b= een clear that anyone can index, store, copy, make avaialble, etc. the RF= Cs. The fact that the IETF does so via the datatracker (and tools) sites= fits just fine with that. > I think Christian was talking about I-Ds not RFCs, which are only avail= able under the Datatracker or tools.ietf.org (th= ough that part is going) whatever the stream, No, I was specifically speaking about the idea of publishing RFCs under=20 something like rfc.ietf.org. I understand Joel point about history and=20 ownership, but Russ was making a different argument, that having such a=20 publication structure would hurt the IAB, the IESG and the independent=20 series publishers. I think that this level of hurt is very hard to=20 quantify. The examples of handling draft tells me that an IETF-centered=20 structure cuts both ways, hurt in some ways, benefit in other ways. I=20 would like to understand how we would quantify these effects, a.k.a.,=20 get data instead of opinions. But we may also decide to let sleeping dogs lie. -- Christian Huitema From nobody Thu Aug 5 20:01:07 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12E483A1927 for ; Thu, 5 Aug 2021 20:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 t4uDyO3HoxKU for ; Thu, 5 Aug 2021 20:01:01 -0700 (PDT) Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) (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 870943A1925 for ; Thu, 5 Aug 2021 20:01:01 -0700 (PDT) Received: by mail-pj1-x1032.google.com with SMTP id a8so13819982pjk.4 for ; Thu, 05 Aug 2021 20:01:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=8CdH9drp4n2SPH2xJW9GLrr9dNJ9GAqra5t9sN8IJko=; b=vd/8NdqJX6p0V4cd3WyaqmEceAG27MJI32LP/kik/eef8iBTBZtKJ0UO1TRLCan7do r94+I3ZQkk8lcYYnTb+RcM4NicI3ROgCI5KWeHv/pNnbchBwm9k8bIxdcqzjYq0ft+xi 9PqcwsONK3iMyFhhqtbV/eUjJ5XFFr8FaFCDT7lXHud6avB5T+kUzGLUyPgFdNsRYtF3 /NmkRX74JQbFW70t78BEXTeBbV/3N/agkWPWaKXAIutl0JKVX7KtQjmeqkcOn9YF+cXP 1iT1KHuAKXab6zUbZdRfLpVpCe3rrp3HKrBn5zWxsWuXAukbXa0JJVgukq2QJWzgmv9p wrew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=8CdH9drp4n2SPH2xJW9GLrr9dNJ9GAqra5t9sN8IJko=; b=XXRaWtAiJKf0XZBg/YmmZZ2td9o3s4mebj5Bghmm0hCv2WtITIyHVoFVtzoL0yQnF/ U/3jxchZECM7WYK40Glp+OCFQlEReAcrYfmhlPckyDMyWr1GN73Smtk5V5wHWWjfwBv5 o/UZXU71kCuFGXV6Lk8CBw8kH5q4sTuFa0sAAgXUbDKfE5tVnX6EVGh0qxwyE2Wwl6Da kJ7rMAzCCkFp1paMbSo4uVYYsOIell8y7LxrZrOgsn+zjCG4Hb0dSn6MNeZRkqOGnuJE /6wgPHXdeYkcYf9RUEkHMi/YXlmWW5OEjO12IVTEP6rAPPbPOoiywZ+6i712Ln8dojzj AOQQ== X-Gm-Message-State: AOAM533rbKE7HIoYzdseRIDsIUEYJgC7568dpqnLrI/h3a2nziNZ4P76 HgkB1DB8soxRiWSP4HND4qVJ7oFwCX/Zmue1 X-Google-Smtp-Source: ABdhPJw1M2IIz1IvjkxwmKxMZruOMD1GlzPuPI+mvg/Ez7b8Y/ruDwC4fvqmIsJQSJCl5cU8ODFrng== X-Received: by 2002:a17:90b:8d:: with SMTP id bb13mr7911650pjb.225.1628218859224; Thu, 05 Aug 2021 20:00:59 -0700 (PDT) Received: from [10.100.240.114] ([203.109.195.43]) by smtp.gmail.com with ESMTPSA id o22sm8064336pfu.87.2021.08.05.20.00.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 Aug 2021 20:00:58 -0700 (PDT) To: Mark Nottingham Cc: Peter Saint-Andre , "Joel M. Halpern" , "rfced-future@iab.org" References: <608f49c6-5e3e-637a-482d-15e48298beb9@joelhalpern.com> <010AEB19-A39C-46BB-8BBF-5BBA4B4B11C5@mnot.net> <7a9fca02-8897-bb5e-27cb-efe1b4ed8ab6@mozilla.com> <3290594c-a920-0ea5-4a28-ff867cbe54f7@joelhalpern.com> <5ebab763-f481-a83d-1db6-22a25839b97b@mozilla.com> From: Brian E Carpenter Message-ID: Date: Fri, 6 Aug 2021 15:00:54 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2021 03:01:06 -0000 On 06-Aug-21 11:36, Mark Nottingham wrote: > >> On 6 Aug 2021, at 6:24 am, Brian E Carpenter wrote: >> >> I think history is a good reason, to avoid confusing the outside world. Expand it to RFC Editor Service perhaps, which is what the phrase has meant for many years anyway. > > That's a really good idea actually -- it would allow us to keep using the same domain name and just tweak the documentation a bit. > > Brian, would you consider using 'RFC Editing Service' in the documentation as workable? Yes, at a pinch. It would still convey continuity. Bria > Cheers, > > -- > Mark Nottingham https://www.mnot.net/ > > . > From nobody Thu Aug 5 20:05:16 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9A73A195F for ; Thu, 5 Aug 2021 20:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 wnpRqhAPqmXi for ; Thu, 5 Aug 2021 20:05:10 -0700 (PDT) Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) (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 F157E3A1951 for ; Thu, 5 Aug 2021 20:05:09 -0700 (PDT) Received: by mail-pj1-x1031.google.com with SMTP id u21-20020a17090a8915b02901782c36f543so11006218pjn.4 for ; Thu, 05 Aug 2021 20:05:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=KMilvQEdPerrvnIvI1c16J0D6U+Q+M7FrMwleqt+7Sc=; b=Zo11QVb96uWNp6aAy86cTxgzYcvG8r/FxUff/Kdel1OKrMJZrzM6VMhSAWT+io3Gmx cBf2hv4gb4P3HckGHs+B5c+ScN823mxv5vxapFXEFhryfiiQhqWyK7s9M6GUPp+nRbh9 +twZQlzdq72OSwmYOozabx88KqH8Y6nXLm5/CXeZkqQNyYdMZa6xhkKqTc6P49lWADD3 zIeeyM4YYagtZTcE1Bpz53QhqH5vir4JEMnYU62Sj5OikD8OFxq2J3vkCubplqy7B+LH aTeSnJ3jn/M4tSi4btO/tHnZ+ropRb1sNKJZKlbi4+6P/z6lftTI7v9We4VhtHhUumMU 6Sng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=KMilvQEdPerrvnIvI1c16J0D6U+Q+M7FrMwleqt+7Sc=; b=tmTbFegfyrFqA2onju6HpKBT/bTuougp3r9P0o1ZAKnpYfIczosV8SHg/F7k4kB52d XZ2fmWH6Vsj3T4xT8WZMzIrHQSlWHABoXhxsl2aWWKUk3L1Scay3yRdHwTXHn6XRea8o pdeU2HrmlG6XUmYt3mibS9YSvKk2b+FiuI00BNUm22iIa3AIJg7ZHoZbf80JwiXLxm06 5uX3EOhwU3eGLFEdxz80dBjSyKaymGgbAkixQwc8hu9Mpx6e5WvXA0+dJw5/ZCUmiMFR b2nQUo/PzcKnF46DGrEUUKMuNWVj1PUAOXi8i4wfXQjKlDKqr3a+Lv6ryXm1OY95mZIT pSYg== X-Gm-Message-State: AOAM533dbygJ7KvVFLk8xPTnUaIWyvYTmHjNsYaeySj5VNsggVtY/iV5 UhK2IxczwzH8l9OfX6lMcAk77Qtg+PckyyIO X-Google-Smtp-Source: ABdhPJzwD2jWUcdga8MLlQMS2PqOc1b7P1GrrYMdzJ/7yPtr4s0LfW2vITfIkeVJzT3JCx9F387MKA== X-Received: by 2002:a17:90a:8b81:: with SMTP id z1mr7836980pjn.82.1628219108888; Thu, 05 Aug 2021 20:05:08 -0700 (PDT) Received: from [10.100.240.114] ([203.109.195.43]) by smtp.gmail.com with ESMTPSA id y13sm10691201pjn.34.2021.08.05.20.05.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 Aug 2021 20:05:08 -0700 (PDT) To: Christian Huitema , Jay Daley , "Joel M. Halpern" Cc: "rfced-future@iab.org" References: <608f49c6-5e3e-637a-482d-15e48298beb9@joelhalpern.com> <010AEB19-A39C-46BB-8BBF-5BBA4B4B11C5@mnot.net> <92bf81a4-a6ae-b479-d914-653f396610b0@huitema.net> <5388c440-67b9-4696-38db-929393c02d54@joelhalpern.com> <0077D4B0-4954-490C-B98C-D27977F902A6@ietf.org> From: Brian E Carpenter Message-ID: Date: Fri, 6 Aug 2021 15:05:04 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2021 03:05:14 -0000 If we were actually in the business of selling stuff using the usual emotional nudges that advertisers have been using for 150 years, the domain name would matter. But we aren't, so it doesn't. We already know that very few people even read the boilerplate text in RFCs, so I don't think that badge engineering will have the slightest effect anyway. Regards Brian On 06-Aug-21 12:37, Christian Huitema wrote: > > On 8/5/2021 5:28 PM, Jay Daley wrote: >> >>> On 6/08/2021, at 12:21 PM, Joel M. Halpern wrote: >>> >>> Christian, you seem to be mixing two things here. >>> >>> We (the historic and current RFC community in the large) have always been clear that anyone can index, store, copy, make avaialble, etc. the RFCs. The fact that the IETF does so via the datatracker (and tools) sites fits just fine with that. >> I think Christian was talking about I-Ds not RFCs, which are only available under the Datatracker or tools.ietf.org (though that part is going) whatever the stream, > > No, I was specifically speaking about the idea of publishing RFCs under > something like rfc.ietf.org. I understand Joel point about history and > ownership, but Russ was making a different argument, that having such a > publication structure would hurt the IAB, the IESG and the independent > series publishers. I think that this level of hurt is very hard to > quantify. The examples of handling draft tells me that an IETF-centered > structure cuts both ways, hurt in some ways, benefit in other ways. I > would like to understand how we would quantify these effects, a.k.a., > get data instead of opinions. > > But we may also decide to let sleeping dogs lie. > > -- Christian Huitema > > From nobody Thu Aug 5 20:07:38 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8A23A1973 for ; Thu, 5 Aug 2021 20:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 RuRdD77n3kPa for ; Thu, 5 Aug 2021 20:07:31 -0700 (PDT) Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) (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 065763A1972 for ; Thu, 5 Aug 2021 20:07:30 -0700 (PDT) Received: by mail-pj1-x1035.google.com with SMTP id pj14-20020a17090b4f4eb029017786cf98f9so14645531pjb.2 for ; Thu, 05 Aug 2021 20:07:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=B2IcnOU5sAY0TlUhKZfHa22wE+c62LO24buU+toRVBM=; b=A2VOvgYWdEkwugsrDJhuhTRd9b4kwYviB89vkrykVnfzXstMh2oEGbKKSvlGFhpLkd y9fTqhIqp3Wr0XntBKAQy7aAH89eWWzXI920RDCGxDaU4JHpNIbzDXSFenTInm+IewYF K3R3wPmXTVw3v4GlqKHd/SM0tDaGlSrAfxITfiKksU4gFzQ0dkPdrOztaRaWt6mha2jN 2VdxHwNZj+/OjaFT9e8qj+7fqSJqlPySoENriHylXuAlkUbOtpPDdbO5cu77Z6bAfo/2 wngaHa78+4XaWwPtIXYqFV2wxQNjCfc56j9ecsafPcC4MTsWHKiZbuW13YbMM2RX9JgA QL6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=B2IcnOU5sAY0TlUhKZfHa22wE+c62LO24buU+toRVBM=; b=gFKlV6bPE2CJPUsGproEa/Bu08N19NdWxqg6h/kLRnEs50CSsxL9xZrCYTynrCvIu3 jPj/D/tpcOAmOgbONjXPADreXlvTmMYGUFdlHBYhliazu8UniEQPDdnobyIMHVtUTJ6b q/1OF6zwCoy+DE5XK3TNYBkGsD4d25952rqiClNTmfKnUxepLVzsp7z+Xn8lar/7nLjp 8su75VTFoUUx3e7m66S0LIsmrm2rSRxzztutsCKWQ23DxuKjpNXx6zFeWw9HDo0C8iAI rvAOqGIU1jWWx12mseoiNOERvsP0+KsZwnlfm2hLzq544vc0eX42/wULSrTRo8VgyjrI FrYw== X-Gm-Message-State: AOAM531IgVZVi/0EsBzqFPQx0JclZBOT8plMuex5eK+EfvLomiAcyaCW eIJV9X7Fttmwb90uFJBtXD0XAB8Mgh7YhHDd X-Google-Smtp-Source: ABdhPJyA89c5P7ddAOuA8PnjjGv781Hr3C8TcH9XDJtQ5wjT4KTUyV8ShG1TFGRxX772FZMXfIQSfQ== X-Received: by 2002:a17:902:d389:b029:12b:b3cc:457c with SMTP id e9-20020a170902d389b029012bb3cc457cmr6732842pld.31.1628219249380; Thu, 05 Aug 2021 20:07:29 -0700 (PDT) Received: from [10.100.240.114] ([203.109.195.43]) by smtp.gmail.com with ESMTPSA id lt18sm3906361pjb.18.2021.08.05.20.07.27 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 Aug 2021 20:07:28 -0700 (PDT) To: rfced-future@iab.org References: <608f49c6-5e3e-637a-482d-15e48298beb9@joelhalpern.com> <010AEB19-A39C-46BB-8BBF-5BBA4B4B11C5@mnot.net> <7a9fca02-8897-bb5e-27cb-efe1b4ed8ab6@mozilla.com> <3290594c-a920-0ea5-4a28-ff867cbe54f7@joelhalpern.com> <5ebab763-f481-a83d-1db6-22a25839b97b@mozilla.com> From: Brian E Carpenter Message-ID: <5db59581-e95b-5a38-d26c-b61e2648463c@gmail.com> Date: Fri, 6 Aug 2021 15:07:25 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2021 03:07:36 -0000 Sure, name the document for what it says, not for what it replaces. (However, for the issue list: we do need to work out what loose ends exist in the older IAB documents about the series that need to be obsoleted or amended.) Regards Brian Carpenter On 06-Aug-21 11:40, Mark Nottingham wrote: > That's also a good suggestion. > >> On 6 Aug 2021, at 2:55 am, Peter Saint-Andre wrote: >> >> On 8/5/21 10:52 AM, Joel M. Halpern wrote: >>> I am not following why what we are doing is not describing the "RFC >>> Editor Model". It appears that we are describing the whole process for >>> habndling documents once streams say they want the document published. >>> that includes, policy, strategy, tactics, ... The largest piece of >>> that is the process of editing the documents. Sure, it is not the only >>> piece. Nothing is. But seems to me that it is the single most >>> important part of what happens. >> >> We could call it "RFC Series Policy Definition and Implementation" - as >> far as I can see, there's no reason (other than history) to call it the >> RFC Editor Model. >> >> Peter >> >> -- >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future > > -- > Mark Nottingham https://www.mnot.net/ > From nobody Thu Aug 5 23:40:53 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C31433A2142 for ; Thu, 5 Aug 2021 23:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 TQkMtvlzzQVw; Thu, 5 Aug 2021 23:40:45 -0700 (PDT) Received: from smtpclient.apple (115-189-87-203.mobile.spark.co.nz [115.189.87.203]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id D46243A2140; Thu, 5 Aug 2021 23:40:44 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Jay Daley Mime-Version: 1.0 (1.0) Date: Fri, 6 Aug 2021 18:40:40 +1200 Message-Id: References: Cc: Christian Huitema , "Joel M. Halpern" , rfced-future@iab.org In-Reply-To: To: Brian E Carpenter X-Mailer: iPhone Mail (18F72) Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2021 06:40:51 -0000 It=E2=80=99s not about selling RFCs but something more fundamental than that= - trust. When an uninitiated person searches for an RFC and sees results f= rom rfc-editor.org, tools.ietf.org and datatracker.ietf.org then which do th= ey trust? =46rom my experience of talking to many developers about this (ov= er some years), almost none of them trusted rfc-editor.org on first sight be= cause they could not associate it with the IETF and because the name itself d= id not convey authority/legitimacy.=20 Jay (sent from my phone) --=20 Jay Daley IETF Executive Director +64 21 678840 > On 6/08/2021, at 3:05 PM, Brian E Carpenter w= rote: >=20 > =EF=BB=BFIf we were actually in the business of selling stuff using the us= ual emotional nudges that advertisers have been using for 150 years, the dom= ain name would matter. >=20 > But we aren't, so it doesn't. We already know that very few people even re= ad the boilerplate text in RFCs, so I don't think that badge engineering wil= l have the slightest effect anyway. >=20 > Regards > Brian >=20 >> On 06-Aug-21 12:37, Christian Huitema wrote: >>=20 >>> On 8/5/2021 5:28 PM, Jay Daley wrote: >>>=20 >>>> On 6/08/2021, at 12:21 PM, Joel M. Halpern wrote:= >>>>=20 >>>> Christian, you seem to be mixing two things here. >>>>=20 >>>> We (the historic and current RFC community in the large) have always be= en clear that anyone can index, store, copy, make avaialble, etc. the RFCs. = The fact that the IETF does so via the datatracker (and tools) sites fits j= ust fine with that. >>> I think Christian was talking about I-Ds not RFCs, which are only availa= ble under the Datatracker or tools.ietf.org (though= that part is going) whatever the stream, >>=20 >> No, I was specifically speaking about the idea of publishing RFCs under=20= >> something like rfc.ietf.org. I understand Joel point about history and=20= >> ownership, but Russ was making a different argument, that having such a=20= >> publication structure would hurt the IAB, the IESG and the independent=20= >> series publishers. I think that this level of hurt is very hard to=20 >> quantify. The examples of handling draft tells me that an IETF-centered=20= >> structure cuts both ways, hurt in some ways, benefit in other ways. I=20 >> would like to understand how we would quantify these effects, a.k.a.,=20 >> get data instead of opinions. >>=20 >> But we may also decide to let sleeping dogs lie. >>=20 >> -- Christian Huitema >>=20 >>=20 >=20 From nobody Fri Aug 6 01:01:58 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CACC3A23BF for ; Fri, 6 Aug 2021 01:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 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, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch 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 3_myQe_Uq3o0 for ; Fri, 6 Aug 2021 01:01:50 -0700 (PDT) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0162D3A23BD for ; Fri, 6 Aug 2021 01:01:48 -0700 (PDT) Received: from [IPv6:2001:420:c0c0:1011::5] ([IPv6:2001:420:c0c0:1011:0:0:0:5]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 17681gPJ218912 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Fri, 6 Aug 2021 10:01:43 +0200 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1628236903; bh=Fi7uyri7eO1JyXM+Gg91iSx5PLeb3BrUE4ukN+3BOFs=; h=To:Cc:From:Subject:Date:From; b=i/tgKxtWwqvQRlPCyOYyk52U2eDqNyqv8RlDp/ZKwnMTEQZGFzKq0aZE1bQpkckkX 4bkbgdeABRucYVQ45ixpnvR53e8jORpCR/Bb3HnWlg088MP4+vw+QgC3jJWHuhqznb 6gW8sSC38+JAR/JqkixeB4fbBE2kqeMXtdCtext8= To: "rfced-future@iab.org" Cc: Brian Rosen From: Eliot Lear Message-ID: Date: Fri, 6 Aug 2021 10:01:41 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="IJNjGOSlulhtbW0U3Nqec22zY9GEUzpyh" Archived-At: Subject: [Rfced-future] Please doodle for the next meeting: deadline 11 Aug 2021 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2021 08:01:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IJNjGOSlulhtbW0U3Nqec22zY9GEUzpyh Content-Type: multipart/mixed; boundary="DmoIKKpQqfuoZGndlIKygVvVX0pu2ehRy"; protected-headers="v1" From: Eliot Lear To: "rfced-future@iab.org" Cc: Brian Rosen Message-ID: Subject: Please doodle for the next meeting: deadline 11 Aug 2021 --DmoIKKpQqfuoZGndlIKygVvVX0pu2ehRy Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi everyone, Could you please doodle for the next meeting by this coming Wednesday,=20 11 August? Here's a little bonus: if we can resolve our remaining issues, it is at=20 least conceivable that this could be the last one of these we have to do.= Doodle URL: https://doodle.com/poll/vmg2i48pvur29ghr?utm_source=3Dpoll&utm_medium=3Dl= ink Thanks, Eliot --DmoIKKpQqfuoZGndlIKygVvVX0pu2ehRy-- --IJNjGOSlulhtbW0U3Nqec22zY9GEUzpyh Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmEM7GUFAwAAAAAACgkQh7ZrRtnSejMW PwgAnZ8ZmybOElpSdvnZm9y9gERqVWisQFzHtvtAJYI5Fr8z6qkgoUPVs0hisRb4rahTcD0PTohd xQB+YLJiNtf8kMzZY3LHes+yu3hYKwqsgSXahfAKtLSbiuZa7hMtqndmmeFhdF1pUwaZePkbWk6t 7TRGU9F8iybi5DkM9eB4XO0XlixsUD+pP3O7G0y0RqD0mJN5w054z+ZfWDMDTAoXsn9MSAB322id UNRkCvL2jyoIZ2NfNbGUxB7BijM/edRjgSEQLWnw/U+yMq0+Hz6t+olAeSFy4coXAhm1A+fZnhHl QMinuQfk/SDvAKKsL5nclAbY+/gKt6Q4pjg126ByLQ== =iB5K -----END PGP SIGNATURE----- --IJNjGOSlulhtbW0U3Nqec22zY9GEUzpyh-- From nobody Fri Aug 6 01:06:33 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF71A3A23E9; Fri, 6 Aug 2021 01:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.891 X-Spam-Level: X-Spam-Status: No, score=-0.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=lear.ch 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 bZaSfhBAmET6; Fri, 6 Aug 2021 01:06:27 -0700 (PDT) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 536C73A23E6; Fri, 6 Aug 2021 01:06:25 -0700 (PDT) Received: from [IPv6:2001:420:c0c0:1011::5] ([IPv6:2001:420:c0c0:1011:0:0:0:5]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 17686HbP218938 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Fri, 6 Aug 2021 10:06:18 +0200 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1628237179; bh=E9ttFGVytThBof9q8sX2N4lu7qJ+u42aBYZuEQ1LhNk=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=cKHHC5HTA1rsWdcD3VnQFtrHxtMXqGnKWsOKxxUWLiGnkYxfPqWhCzsEbrmGCMwGX pu05IoY9MiZhLpsEGnp1UEuPCi5doG6h3/V42WSGT54Q7Uml3ej0v0zHPjxhz6zUOb T5sdk01RBRvsOyuohR7v7hC7s40wttCkdWrhWObs= To: Jay Daley , Brian E Carpenter Cc: rfced-future@iab.org, "Joel M. Halpern" , Christian Huitema References: From: Eliot Lear Message-ID: <2ff1860f-c7c1-9a85-a072-166cf0c17b7c@lear.ch> Date: Fri, 6 Aug 2021 10:06:17 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Yk9ClslXDD4MFhkgmIhv5DhC40DVgG4rE" Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2021 08:06:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Yk9ClslXDD4MFhkgmIhv5DhC40DVgG4rE Content-Type: multipart/mixed; boundary="8WrFtQyccC7c9dKIW5ZKVqgMtI3jXOucs"; protected-headers="v1" From: Eliot Lear To: Jay Daley , Brian E Carpenter Cc: rfced-future@iab.org, "Joel M. Halpern" , Christian Huitema Message-ID: <2ff1860f-c7c1-9a85-a072-166cf0c17b7c@lear.ch> Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? References: In-Reply-To: --8WrFtQyccC7c9dKIW5ZKVqgMtI3jXOucs Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Question: Do people believe this is a topic for THIS group or for the (hopefully=20 soon to be created) RSWG?=C2=A0 Are there parts that need to be dealt wit= h=20 NOW and parts that can be dealt with later? Eliot On 06.08.21 08:40, Jay Daley wrote: > It=E2=80=99s not about selling RFCs but something more fundamental than= that - trust. When an uninitiated person searches for an RFC and sees r= esults from rfc-editor.org, tools.ietf.org and datatracker.ietf.org then = which do they trust? From my experience of talking to many developers ab= out this (over some years), almost none of them trusted rfc-editor.org on= first sight because they could not associate it with the IETF and becaus= e the name itself did not convey authority/legitimacy. > > Jay > > (sent from my phone) > --8WrFtQyccC7c9dKIW5ZKVqgMtI3jXOucs-- --Yk9ClslXDD4MFhkgmIhv5DhC40DVgG4rE Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmEM7XkFAwAAAAAACgkQh7ZrRtnSejOs tAf/cT1YDL+uTKI9ogohQxlsMmaqH3Uix/vEXqH6EjM6xjDy/vrRIL6nhiXt2SuLaPA/gk6Y3EC+ cII3JQylThRY2ysZCT8d4oZNDxUSsfGxFSbAXiwbLQ3hpaPo/mqVZflVu6gd5fozwGTOgrUGO+sw D+KbXsesHIbYHd9387KZD84vf+xVilkNM1gZ4lNZynP9S7eEcVkw9l5uvW31y/hUOfN3faXm+ch9 1PggA0tc6IDQgupB7t5ObxLqJBTTinFEL5UQ1iAyAns9o4g6tv15s0NRdpiHypS4Ro7JYwelD7dN vaGkcqcdZVknzT0L/Ykj/n8Xy5yfCAefpposP0p+Bg== =YHl+ -----END PGP SIGNATURE----- --Yk9ClslXDD4MFhkgmIhv5DhC40DVgG4rE-- From nobody Fri Aug 6 02:07:21 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45D943A25E5; Fri, 6 Aug 2021 02:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 KlBiXqioXIOP; Fri, 6 Aug 2021 02:07:14 -0700 (PDT) Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D76BE3A25E6; Fri, 6 Aug 2021 02:07:13 -0700 (PDT) Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id 176975f8015895; Fri, 6 Aug 2021 10:07:05 +0100 Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id ABC364604F; Fri, 6 Aug 2021 10:07:05 +0100 (BST) Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 9BD044604D; Fri, 6 Aug 2021 10:07:05 +0100 (BST) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs1.iomartmail.com (Postfix) with ESMTPS; Fri, 6 Aug 2021 10:07:05 +0100 (BST) Received: from LAPTOPK7AS653V ([84.93.40.162]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id 176974h1013360 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 6 Aug 2021 10:07:04 +0100 Reply-To: From: "Adrian Farrel" To: "'Eliot Lear'" , "'Jay Daley'" , "'Brian E Carpenter'" Cc: , "'Joel M. Halpern'" , "'Christian Huitema'" References: <2ff1860f-c7c1-9a85-a072-166cf0c17b7c@lear.ch> In-Reply-To: <2ff1860f-c7c1-9a85-a072-166cf0c17b7c@lear.ch> Date: Fri, 6 Aug 2021 10:07:03 +0100 Organization: Old Dog Consulting Message-ID: <17be01d78aa2$6db78e00$4926aa00$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJq1aEhtUxU8pVpjXxy17ZiVN9VxQJ7qzs6AaVoJCuqHo3f4A== Content-Language: en-gb X-Originating-IP: 84.93.40.162 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.1.0.2034-8.6.0.1018-26328.006 X-TM-AS-Result: No--5.607-10.0-31-10 X-imss-scan-details: No--5.607-10.0-31-10 X-TMASE-Version: IMSVA-9.1.0.2034-8.6.1018-26328.006 X-TMASE-Result: 10--5.606500-10.000000 X-TMASE-MatchedRID: 8+bhjh9TQnHxIbpQ8BhdbBlJRfzNw8afX93p52Kh3tjHMkjqltnstz9N pZkQo89ilWBWhR6s2HpBajNmTyJuMLtBUAtfd6ph9TCJfXmXS29M8zV+hbhmA7ZrwavUsIfNVdr VvjGE5WEfO3I6PZb3JYx9IrZUoz8VbChbYLl5DJx7iSSJfh7M2XCbs2f+UaFWk+S++edvrOIhgV U1JTxZmP5KTE/C3hv0gAIcTCLsUSV8+ZRBAbr2nFllim4HFeWAK1zvw58EecstferJ/d7Ab/w4v gFVYhZR/ye/3Hc9K1q5hiunv4GcSxtERvAcTMq3gn3kS7B0uSs7g2sl0tC6gbXl40gTGJ5ppTMf Ry1HRznPCIU6ZABSSzHoh8c+Wgveoe5zfF+josbdB/CxWTRRu4as+d5/8j56GQDvcfFd9m6g0n6 OAV/9bFNo4Tm2h3ecAO+Ik+QhV192madUWCN/8Q== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2021 09:07:20 -0000 Eliot, I don't think this is something this group should spend time on: we have = a primary focus and I suspect this would be a substantial distraction = that might even bring the whole thing down. It is possible that the RSWG could consider it. What needs to be dealt with now? Nothing. Well, can't let Jay's comment = go unchallenged. It is entirely possible that he talks to different = developers from those I talk to. Perhaps "trust" is not the right word? I find people trusting = rfc-editor.org as definitive. It is where the DOIs resolve to. It is the = anchor for citations from third-party publications. But I find people use tools.ietf.org and datatracker.ietf.org (each = according entirely to personal preferences) for convenient and quick = access to RFCs. A -----Original Message----- From: Rfced-future On Behalf Of Eliot = Lear Sent: 06 August 2021 09:06 To: Jay Daley ; Brian E Carpenter = Cc: rfced-future@iab.org; Joel M. Halpern ; = Christian Huitema Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? Question: Do people believe this is a topic for THIS group or for the (hopefully=20 soon to be created) RSWG? Are there parts that need to be dealt with=20 NOW and parts that can be dealt with later? Eliot On 06.08.21 08:40, Jay Daley wrote: > It=E2=80=99s not about selling RFCs but something more fundamental = than that - trust. When an uninitiated person searches for an RFC and = sees results from rfc-editor.org, tools.ietf.org and = datatracker.ietf.org then which do they trust? From my experience of = talking to many developers about this (over some years), almost none of = them trusted rfc-editor.org on first sight because they could not = associate it with the IETF and because the name itself did not convey = authority/legitimacy. > > Jay > > (sent from my phone) > From nobody Fri Aug 6 02:24:06 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8F6F3A2667 for ; Fri, 6 Aug 2021 02:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no 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 R3bGcymt043f for ; Fri, 6 Aug 2021 02:24:03 -0700 (PDT) Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE2823A2665 for ; Fri, 6 Aug 2021 02:24:01 -0700 (PDT) Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id 1769O0Yj028208 for ; Fri, 6 Aug 2021 10:24:00 +0100 Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 2B56046051 for ; Fri, 6 Aug 2021 10:24:00 +0100 (BST) Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 292764604B for ; Fri, 6 Aug 2021 10:24:00 +0100 (BST) Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs2.iomartmail.com (Postfix) with ESMTPS for ; Fri, 6 Aug 2021 10:24:00 +0100 (BST) Received: from LAPTOPK7AS653V ([84.93.40.162]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id 1769NxD7017047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 6 Aug 2021 10:23:59 +0100 Reply-To: From: "Adrian Farrel" To: Date: Fri, 6 Aug 2021 10:23:59 +0100 Organization: Old Dog Consulting Message-ID: <17bf01d78aa4$ca65d560$5f318020$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdeKpMPZRHoKDZdYQeySYD108Jh4jQ== Content-Language: en-gb X-Originating-IP: 84.93.40.162 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.1.0.2034-8.6.0.1018-26328.006 X-TM-AS-Result: No--3.755-10.0-31-10 X-imss-scan-details: No--3.755-10.0-31-10 X-TMASE-Version: IMSVA-9.1.0.2034-8.6.1018-26328.006 X-TMASE-Result: 10--3.754700-10.000000 X-TMASE-MatchedRID: GGlWKW7mrCPjNn0Okk5VX8NuWNiwQ5oLOxjb9QQbt+QtMfLCPy3CaAMT qT+LpjRFpUqSCi9d+gdH1yhQFWYpgxha18eHngtztQ/+vhcJdOcgxk+qFPYkG+GZgtEz2baI4rl +FHG3VoD8J63SYyFpGkGMYJrkbfHB6XtK5n1RIZLnh6rB4tZovlx5UEiF/A71rP7fIroeSfN/KC 7BNVcWSpoP7uY47o3Wdc0zmQEEFZnBIi57ZfCVFrzgL/eLACDEStGAgmKqWuXgYraJs1MCD3Awi 8qlmI2ocf21FgsUyRDRr6pL4diplfMS1evlLhWSIjKSH8rlATsETQObWAeuuQJRjXQLiyc9wbL/ 11/xhOkud9SYwRQyASsTGnuQYWzXS0ekx1+tcwri3aa5wOREEW6hg6ePJxJPe3hrNe/ZbVld7QP XAJ51otkwAmBtK/Bc3u4dyASj7czbB3MyTCzxp46MisxJraxHmkdAU3usvKtEAJzPfxN5ylAKyZ 8B6Bt0AnYzh17DSAhS8kbMHAldSca2UtJJH6dnTriaDTRnTsGL4szjQe8SOs4Nicps7/c+NKCFv +lwDDJ3nVkLAl03yhqttMwOzc4NkfRhdidsajM5f9Xw/xqKXSs3zPQeiEbe+gtHj7OwNO25V9z3 vqk3KoF/ooT93asAz8bEWAtXIVWSbjnuk2I4IcClK7cVKL4NIZPyKvTQh+mgBLaHgU/JIAMfpBZ ByqLmIoydrwExaMdsK3pVctzYuLnrea/QXYb3dOnI8WPGJZtXLGtABlf0m8L8HbphQDv4 X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: [Rfced-future] The editing process and job titles X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2021 09:24:05 -0000 I don't know if I am the only one who is finding the discussion of the names of roles (aka job titles) really frustrating. It seems to me that the job title serves three purposes: 1. To make it clear what function a person performs within an organisation 2. To attract people to job advertisements 3. To make an employee feel comfortable with their position Arguments about "does this person actually do any editing?" seems to me to misconstrue the end-to-end process of production where the term "edit" applies to many functions. I think it is unhelpful to take a limited or specific view of the word "editing" and assume that others will share this view. (Of course, it is in the nature of language that it evolves to the commonly accepted meanings, but we don't have to be overly precautionarily predictive.) I feel that the discussion of the job title has been bashed around considerably and yet it is probably the smallest point we have to resolve. Does the dispute reveal an underlying dissatisfaction with the whole of the work so far, does it show a point of serious import, or is it a group of engineers obsessing over words because the bike shed has already been painted? My personal preference remains with "RFC Series Editor" I quite like "RFC Series Consulting Editor" (although I have to point out that many people who are freelance editors advising on content and writing style, sell themselves as consulting editors). "RFC Series Advising Editor" (not "Advisory") is something I could live with. I'd like to explore "RFC Series Expert" a bit. To me the word "expert" in this context raises too many questions. Are they experts in the content? Surely not. So where does their expertise lie? Perhaps deciding what expertise we want them to have would actually allow us to reach agreement on the title. There is one other word to explore: "Publisher". It is almost certain that this word will cause more disagreement. But perhaps that will help us agree that we don't like the word! To some it will have overtones of the "evil owner of a politically biased newspaper". To others it will mean the owner of the series (which is a question we have carefully avoided since it blew up so unfortunately back in the RFC++ days). To yet others it means the person responsible for getting everything to happen through the copy-edit, proofing, production, and presentation phases. Best, Adrian From nobody Fri Aug 6 10:42:10 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74ECB3A0BB2 for ; Fri, 6 Aug 2021 10:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 zoRaKnKFhDtZ for ; Fri, 6 Aug 2021 10:42:06 -0700 (PDT) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 527CF3A0BB8 for ; Fri, 6 Aug 2021 10:42:06 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id f6so12796586ioc.6 for ; Fri, 06 Aug 2021 10:42:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=SROiPlYpUZuO8gvgx4NQR41kIWDxJwN+kr4HZshLp3I=; b=J1jUcoM1Md/R51wTCz90+b5f/ddiz1Ih9Pdn1H38W27QFyTq0CN6G8cxWlvzDEWaqJ yBjtWNaw09cdrToAhTFFch3PRnW+sVIQzI958kj0ozb11iyp+mVXx3MmwGNisEWa2vy4 ZrgdbB2eFX8cTLV/udcE2l5KNHXat/1iKqLBY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=SROiPlYpUZuO8gvgx4NQR41kIWDxJwN+kr4HZshLp3I=; b=r876mQV1QjuvaGq9ihFgltb1pvjdq6VipRG6lMXFBoapglTc4dYpKoOfgTDp9buRln OvirXoUt4CVASVRDEDbDZitLjwchA7/lMtIgDeoOaPDv73c5lv0/WrmuOAb1qnp59SjR qTAjgcJh1BIK501/1db3UeCTlG8OrI8tS2H3hr644wdFlr9EKaqi1QdC8lRHJsGIJ7PK XjkqgMXHpW78AtaGaRWBV8HS0DMLAN1eQTNdDB7x5qgYERMOLCzyDiUnBC+yTn7PsjWF JjwFZyy8x0kRNg5EkZsKoPmf9+noo5JvCFaZ2hipCRexfWpIe73SJOgRArUApArNjKcf RAig== X-Gm-Message-State: AOAM530TFmj+V4t3zesBJxtgOfwwoGfVJucKQ4yGdRcDLIavGiE4m53y sHbtXX7Ea5Aw4YgqZqcXrlKz8Q== X-Google-Smtp-Source: ABdhPJwmYa9M//M1Ju2MmWeVT1WGsoIToVkNIeII7YPYlQi3tbHwD81Mf9u4Vhu+JTuyqfX89EVYuw== X-Received: by 2002:a92:905:: with SMTP id y5mr807854ilg.222.1628271724133; Fri, 06 Aug 2021 10:42:04 -0700 (PDT) Received: from dragon.local (c-73-78-113-156.hsd1.co.comcast.net. [73.78.113.156]) by smtp.gmail.com with ESMTPSA id s9sm5527319iob.10.2021.08.06.10.42.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 06 Aug 2021 10:42:03 -0700 (PDT) To: Brian E Carpenter , rfced-future@iab.org References: <608f49c6-5e3e-637a-482d-15e48298beb9@joelhalpern.com> <010AEB19-A39C-46BB-8BBF-5BBA4B4B11C5@mnot.net> <7a9fca02-8897-bb5e-27cb-efe1b4ed8ab6@mozilla.com> <3290594c-a920-0ea5-4a28-ff867cbe54f7@joelhalpern.com> <5ebab763-f481-a83d-1db6-22a25839b97b@mozilla.com> <5db59581-e95b-5a38-d26c-b61e2648463c@gmail.com> From: Peter Saint-Andre Message-ID: Date: Fri, 6 Aug 2021 11:42:01 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <5db59581-e95b-5a38-d26c-b61e2648463c@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2021 17:42:09 -0000 On 8/5/21 9:07 PM, Brian E Carpenter wrote: > (However, for the issue list: we do need to work out what loose ends exist in the older IAB documents about the series that need to be obsoleted or amended.) Yes. Eliot, if you create this issue and assign it to me I can grep through the relevant RFCs. (Are there also non-RFC documents from the IAB to check?) Peter From nobody Fri Aug 6 11:59:08 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8F03A10C5 for ; Fri, 6 Aug 2021 11:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.89 X-Spam-Level: X-Spam-Status: No, score=-0.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=lear.ch 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 VXapBU5-tObh for ; Fri, 6 Aug 2021 11:59:00 -0700 (PDT) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 832FB3A10BC for ; Fri, 6 Aug 2021 11:58:58 -0700 (PDT) Received: from [IPv6:2a02:aa15:4101:2a80:d0a1:374c:15b7:aa4d] ([IPv6:2a02:aa15:4101:2a80:d0a1:374c:15b7:aa4d]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 176Iwr7M225287 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Fri, 6 Aug 2021 20:58:53 +0200 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1628276333; bh=u8W8jalPNk+aT7/Et56+CdRL+/6M6WdoLaQzALjkmoQ=; h=Subject:To:References:From:Date:In-Reply-To:From; b=QvXAyIqUzVHXTMOFZSjEl3+8kTp/CnoJuL9wsK5Fw3Pha4E2qEsg7k0eunqsjblYU ST9KStL0hCGbMpDYIAYeSXoIBUnu6UP0jiNSHgH0sP6FLtN9oABfos6p1z1WpgNtXX N8BETHlIPNDPN85/Pd/78yk2lmslfQ2pyoBjOOvY= To: Peter Saint-Andre , Brian E Carpenter , rfced-future@iab.org References: <608f49c6-5e3e-637a-482d-15e48298beb9@joelhalpern.com> <010AEB19-A39C-46BB-8BBF-5BBA4B4B11C5@mnot.net> <7a9fca02-8897-bb5e-27cb-efe1b4ed8ab6@mozilla.com> <3290594c-a920-0ea5-4a28-ff867cbe54f7@joelhalpern.com> <5ebab763-f481-a83d-1db6-22a25839b97b@mozilla.com> <5db59581-e95b-5a38-d26c-b61e2648463c@gmail.com> From: Eliot Lear Message-ID: Date: Fri, 6 Aug 2021 20:58:51 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="d1Y6bktPiRkivsGyMw9MO8Dmv3ATSu5Q3" Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2021 18:59:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --d1Y6bktPiRkivsGyMw9MO8Dmv3ATSu5Q3 Content-Type: multipart/mixed; boundary="N6Ws3qoQZoYYWJ1Lsd5cyxAUlZcw2t5Up"; protected-headers="v1" From: Eliot Lear To: Peter Saint-Andre , Brian E Carpenter , rfced-future@iab.org Message-ID: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? References: <608f49c6-5e3e-637a-482d-15e48298beb9@joelhalpern.com> <010AEB19-A39C-46BB-8BBF-5BBA4B4B11C5@mnot.net> <7a9fca02-8897-bb5e-27cb-efe1b4ed8ab6@mozilla.com> <3290594c-a920-0ea5-4a28-ff867cbe54f7@joelhalpern.com> <5ebab763-f481-a83d-1db6-22a25839b97b@mozilla.com> <5db59581-e95b-5a38-d26c-b61e2648463c@gmail.com> In-Reply-To: --N6Ws3qoQZoYYWJ1Lsd5cyxAUlZcw2t5Up Content-Type: multipart/alternative; boundary="------------88C702F0C8C69D1C55E1F67B" Content-Language: en-US This is a multi-part message in MIME format. --------------88C702F0C8C69D1C55E1F67B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi Peter, On 06.08.21 19:42, Peter Saint-Andre wrote: > Yes. Eliot, if you create this issue and assign it to me I can grep > through the relevant RFCs. (Are there also non-RFC documents from the > IAB to check?) Issue 78.=C2=A0 However...=C2=A0 I *think* that was what John Klensin did= for us,=20 that led to the creation of issues 26-35.=C2=A0 These issues cover RFCS 2= 026,=20 2028, BCPs 78, 79, 39, RFC 8729 and 4844, as well as boiler plate.=C2=A0 = I'm=20 not saying that we shouldn't do that again, by the way.=C2=A0 Thus the ne= w=20 tracking issue. Eliot --------------88C702F0C8C69D1C55E1F67B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Peter,

On 06.08.21 19:42, Peter Saint-Andre wrote:
Yes. Eliot, if you create th=
is issue and assign it to me I can grep
through the relevant RFCs. (Are there also non-RFC documents from the
IAB to check?)

Issue 78.=C2=A0 However...=C2=A0 I think that was what John= Klensin did for us, that led to the creation of issues 26-35.=C2=A0 These issues cover RFCS 2026, 2028, BCPs 78, 79, 39, RFC 8729 and 4844, as well as boiler plate.=C2=A0 I'm not saying that we shouldn't do = that again, by the way.=C2=A0 Thus the new tracking issue.

Eliot

--------------88C702F0C8C69D1C55E1F67B-- --N6Ws3qoQZoYYWJ1Lsd5cyxAUlZcw2t5Up-- --d1Y6bktPiRkivsGyMw9MO8Dmv3ATSu5Q3 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmENhmsFAwAAAAAACgkQh7ZrRtnSejPC Kgf/b2EPRliaJFVM2g+Ss0PSA4tsMFVROb+bS5w0N9ca4MXz/y8tNXVLN2NTE0DltrD3G/Znvu1T nHMatNDC4tULHDJDnjvBrQEO9DfBxjwWDqghhHM/XFfaUAg0Qhbb8lAthOCoRgHXUfySJSh+q6Gv nuyP1KjBPTv8jU4i1XDVIj/1LtSK6PzqMC8kJkyMdVd4xdvLNxCbFbrnDIYY3u1zYfeVpJln2gQA uFmhLnUJt09W2s1Zu8gCw0xc3B/PoXpi+QMUgH0Q5jJxQa6XG/Rc5ZjwVZH/jJsDv9nUObIzypUW XEBJqlp/t45Ff9IDg8QXw2a+KdMjQU0kRN30EmZm0A== =iRzw -----END PGP SIGNATURE----- --d1Y6bktPiRkivsGyMw9MO8Dmv3ATSu5Q3-- From nobody Fri Aug 6 12:04:59 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC503A110E for ; Fri, 6 Aug 2021 12:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 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, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch 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 PTbLVgcSNoMK for ; Fri, 6 Aug 2021 12:04:52 -0700 (PDT) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 497A73A1110 for ; Fri, 6 Aug 2021 12:04:49 -0700 (PDT) Received: from [IPv6:2a02:aa15:4101:2a80:d0a1:374c:15b7:aa4d] ([IPv6:2a02:aa15:4101:2a80:d0a1:374c:15b7:aa4d]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 176J4kK3225354 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Fri, 6 Aug 2021 21:04:46 +0200 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1628276686; bh=YCYleIIdQAH0YLK7QNVDnWxGwwJ9EdM9bX8F0gDXyVc=; h=To:From:Subject:Date:From; b=B8RjPvSCmp8U8edbU9N7dnmN9bMj9tkkvG+D4jd2BRxsw3aPjvsUovw8M+STWeNy2 J9yGDLSqrmMwTFQaan0UsCi94qKTjG680qzbrCC1i5zOK/KTFl3tDO6d6IKmcZZ0Dt WWNP0gGq5JjSEK6PrPUbQlnN1bXXHnRHMxSo+y9I= To: "rfced-future@iab.org" From: Eliot Lear Message-ID: <6000b322-9185-a25e-01e4-7f84b4910f8d@lear.ch> Date: Fri, 6 Aug 2021 21:04:45 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="C3cWzqwx2i4fGun1PsdSCh5tk5QJSA1m3" Archived-At: Subject: [Rfced-future] Consensus check: Issue 73: creating new streams X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2021 19:04:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --C3cWzqwx2i4fGun1PsdSCh5tk5QJSA1m3 Content-Type: multipart/mixed; boundary="48EXI2Sy5hIt1BCd64mK4zQ2qXjfuQdzy"; protected-headers="v1" From: Eliot Lear To: "rfced-future@iab.org" Message-ID: <6000b322-9185-a25e-01e4-7f84b4910f8d@lear.ch> Subject: Consensus check: Issue 73: creating new streams --48EXI2Sy5hIt1BCd64mK4zQ2qXjfuQdzy Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US What we currently have is this: > The requirements and process for creating any additional RFC streams ar= e > out of scope in this document. If people have concerns with this text, please comment by August 20th. Eliot --48EXI2Sy5hIt1BCd64mK4zQ2qXjfuQdzy-- --C3cWzqwx2i4fGun1PsdSCh5tk5QJSA1m3 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmENh80FAwAAAAAACgkQh7ZrRtnSejM1 hgf/Xy0UkiAtn6h1xrQkCrpuahXB57hq7V2OS1mgu/6kVaEbcm983P+/kKXF5EiBdMndd7NJP7xo 8g+GtTpud+o08n0z6hKL9YXkvfwAfV/YblniZ0DqNcIQlcgJwK8SY6AhC6wOZValTQmacCnN8fX3 eBNZona7imzYeehiDE1Cw1zem4pM7M+gkYeNzgFxDmiveR12Jbk1EIcWa+5h6kdd9LHJR+rxWEWD qf9szZznq5RMRByx3FVr6HVpsW8gp8KkdKyYG3ssh3oldK5xOvWk6p/YrHzrPEvka/Z2nf2axI48 Io2c2AJ818xXCbTYEqPCvslquxec1XIzeAZqHCbJdQ== =On9F -----END PGP SIGNATURE----- --C3cWzqwx2i4fGun1PsdSCh5tk5QJSA1m3-- From nobody Fri Aug 6 12:06:28 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB1C13A1130 for ; Fri, 6 Aug 2021 12:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 xqA-L5_OSGAG for ; Fri, 6 Aug 2021 12:06:21 -0700 (PDT) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 C0F663A1136 for ; Fri, 6 Aug 2021 12:06:21 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id s184so13347312ios.2 for ; Fri, 06 Aug 2021 12:06:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=f7f03dx9/2eYfq+WUGtyn+cUPWavFtugye7XaMEyR3g=; b=RTVFUVyRL4vvU6h8dKR+tC7ERoyJQYxn53TPa7CE+xXJ4P1axpGaYOkpJBLZCfHF4T BudQOvVR+QC7KnWPxGS+1EQWL0nmrWEwllxwRBoFtY9m7rnYQEvCdCKKnfbYXhviagYW L2vSGIKwXRAY9UFYKSxGDTRBFQ/dITK9b0mtJprQw6PsrZdwrIJXTgJWg+HY4mP76EsS jWrlPinSV6fzQhz2eDregz3dkX+YRw3Gbx8CQoe4aVEkIq/KPSdGhMMRoUxpvT159uvH qRaBUauBdgc53XtSEY/l8eCTpPel9k2H6ET0o9NeTMXsuf43+y/Wq2BZRamoHOsdIovh xc0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=f7f03dx9/2eYfq+WUGtyn+cUPWavFtugye7XaMEyR3g=; b=Xbi6YLIxmmIfcS8lXqW2zESvujA53mpVZnfUD7Ux7BM9Dvud6vBN+IlAfQoGOJlNtg beScuyE28WB9w72WMy/m7/7R0PS7PMJ0pDzl2bzITDvSG7UBUEuYfLge4FsRPgVKfl2e 9WLbSyHBO9tY6fVBS4439z7BDc/unw6JQw/wyADe7y2WasBOHsVW3V0uzeY+lbVdVOXH J1HhpRwLZMRcC0e7UFMHjYbIOTX0OPVYt8S/e+u+M2GeCMJvVGevo+0iJLoceeVZBCSq 6rIo3ECzrBkMZuu3C/zsVCR/QXRTfVMLR1tKevTTXpnUzqGXHufs/0iDzV1+xsYEmaSL 9Uyw== X-Gm-Message-State: AOAM532ORntImIuN/umidscJIkEHfvkloRnsP07dz8KjFpaeJOTUDTBS oOx42eXLVK4UQujE6PEzJ6kQ7K8h07l7MtggtF0sQQ== X-Google-Smtp-Source: ABdhPJyrZRBvkJUlDhNQDhVN/pygAGkTRcpLLtWNrhXDQd4Azl4SOJxD0sfyOy6iNwmoje1OJKnRhLR8GwZEwimtMUA= X-Received: by 2002:a05:6e02:1aae:: with SMTP id l14mr499822ilv.35.1628276775998; Fri, 06 Aug 2021 12:06:15 -0700 (PDT) MIME-Version: 1.0 References: <6000b322-9185-a25e-01e4-7f84b4910f8d@lear.ch> In-Reply-To: <6000b322-9185-a25e-01e4-7f84b4910f8d@lear.ch> From: Eric Rescorla Date: Fri, 6 Aug 2021 12:05:39 -0700 Message-ID: To: Eliot Lear Cc: "rfced-future@iab.org" Content-Type: multipart/alternative; boundary="000000000000d474a305c8e8ba0f" Archived-At: Subject: Re: [Rfced-future] Consensus check: Issue 73: creating new streams X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2021 19:06:27 -0000 --000000000000d474a305c8e8ba0f Content-Type: text/plain; charset="UTF-8" This seems good to me. On Fri, Aug 6, 2021 at 12:05 PM Eliot Lear wrote: > What we currently have is this: > > > The requirements and process for creating any additional RFC streams are > > out of scope in this document. > > If people have concerns with this text, please comment by August 20th. > > Eliot > > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > --000000000000d474a305c8e8ba0f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This seems good to me.

On Fri, Aug 6, 2021 at 12:05 PM = Eliot Lear <lear@lear.ch> wrote:<= br>
What we currentl= y have is this:

> The requirements and process for creating any additional RFC streams a= re
> out of scope in this document.

If people have concerns with this text, please comment by August 20th.

Eliot


--
Rfced-future mailing list
Rfced-future@iab.= org
https://www.iab.org/mailman/listinfo/rfced-future
--000000000000d474a305c8e8ba0f-- From nobody Fri Aug 6 12:11:51 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 873803A1180 for ; Fri, 6 Aug 2021 12:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no 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 HhbwjckFAIsv for ; Fri, 6 Aug 2021 12:11:44 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4B3A3A1182 for ; Fri, 6 Aug 2021 12:11:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id F2F7C300C4F for ; Fri, 6 Aug 2021 15:11:43 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 6U76i9UntZOO for ; Fri, 6 Aug 2021 15:11:42 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id CE4503004A7; Fri, 6 Aug 2021 15:11:41 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) From: Russ Housley In-Reply-To: Date: Fri, 6 Aug 2021 15:11:40 -0400 Cc: Jay Daley , Joel Halpern , "rfced-future@iab.org" Content-Transfer-Encoding: quoted-printable Message-Id: <443C70D9-8869-4C31-992B-8F57C6DCB6C4@vigilsec.com> References: <608f49c6-5e3e-637a-482d-15e48298beb9@joelhalpern.com> <010AEB19-A39C-46BB-8BBF-5BBA4B4B11C5@mnot.net> <92bf81a4-a6ae-b479-d914-653f396610b0@huitema.net> <5388c440-67b9-4696-38db-929393c02d54@joelhalpern.com> <0077D4B0-4954-490C-B98C-D27977F902A6@ietf.org> To: Christian Huitema X-Mailer: Apple Mail (2.3445.104.21) Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2021 19:11:51 -0000 > On Aug 5, 2021, at 8:37 PM, Christian Huitema = wrote: >=20 >=20 > On 8/5/2021 5:28 PM, Jay Daley wrote: >>=20 >>> On 6/08/2021, at 12:21 PM, Joel M. Halpern = wrote: >>>=20 >>> Christian, you seem to be mixing two things here. >>>=20 >>> We (the historic and current RFC community in the large) have always = been clear that anyone can index, store, copy, make avaialble, etc. the = RFCs. The fact that the IETF does so via the datatracker (and tools) = sites fits just fine with that. >> I think Christian was talking about I-Ds not RFCs, which are only = available under the Datatracker or tools.ietf.org = (though that part is going) whatever the = stream, >=20 > No, I was specifically speaking about the idea of publishing RFCs = under something like rfc.ietf.org. I understand Joel point about history = and ownership, but Russ was making a different argument, that having = such a publication structure would hurt the IAB, the IESG and the = independent series publishers. I think that this level of hurt is very = hard to quantify. The examples of handling draft tells me that an = IETF-centered structure cuts both ways, hurt in some ways, benefit in = other ways. I would like to understand how we would quantify these = effects, a.k.a., get data instead of opinions. https://www.ietf.org/rfc/rfc5280.txt This already works. It is a duplicate of the files on rfc-editor.org Russ= From nobody Fri Aug 6 12:18:18 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAF203A11DE for ; Fri, 6 Aug 2021 12:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 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, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch 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 IYePzxImo7GM for ; Fri, 6 Aug 2021 12:18:12 -0700 (PDT) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A1603A11F2 for ; Fri, 6 Aug 2021 12:18:11 -0700 (PDT) Received: from [IPv6:2a02:aa15:4101:2a80:d0a1:374c:15b7:aa4d] ([IPv6:2a02:aa15:4101:2a80:d0a1:374c:15b7:aa4d]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 176JI4Dq225521 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Fri, 6 Aug 2021 21:18:04 +0200 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1628277484; bh=PjxWlUPpuq52NEzC/F8riEYgKGpB3Yhigi2AJ4TKKaU=; h=To:From:Subject:Date:From; b=h1D8vXNVKq3fd/8iXGFiMIP8TqzauQsGJrSL4kA8+NJJlEthxobwlCU1qj4dO1KV+ TGIpHbBIm7pV08TAegIyqReCmR5Hdc/7klEOeQ7JE0TcPPRpQwYVLVqzR4UVjcy32l lcltFf3HeNrDAuJyryYmSH1XAJBFr126k4oEtW5Q= To: "rfced-future@iab.org" From: Eliot Lear Message-ID: Date: Fri, 6 Aug 2021 21:18:03 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8awfkSHrBYmJDvSqgvrHLmQqbK5a4UJLJ" Archived-At: Subject: [Rfced-future] Consensus Check Issue 54: When does the RSAB start its formal review? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2021 19:18:17 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8awfkSHrBYmJDvSqgvrHLmQqbK5a4UJLJ Content-Type: multipart/mixed; boundary="PEKvyTZFCFIReu8wnIrdcRaszHcuxHPWo"; protected-headers="v1" From: Eliot Lear To: "rfced-future@iab.org" Message-ID: Subject: Consensus Check Issue 54: When does the RSAB start its formal review? --PEKvyTZFCFIReu8wnIrdcRaszHcuxHPWo Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: base64 Content-Language: en-US VGhpcyBpc3N1ZSBoYWQgdG8gZG8gd2l0aCBzb21lIGVhcmxpZXIgY29uZnVzaW9uIGluIGVh cmxpZXIgcHJvcG9zYWxzIGFzIAp0byB0aGUgcHJlY2lzZSBvcmRlciBvZiBldmVudHMsIGFu ZCB3aGVuIHRoZSBmb3JtYWwgcmV2aWV3IGJlZ2lucy7CoCBJIApiZWxpZXZlIHRoZSBjdXJy ZW50IHRleHQgaXMgY2xlYXIuwqAgSWYgeW91IGRpc2FncmVlLCBjb3VsZCB5b3UgcGxlYXNl IApjb21tZW50IGJ5IEF1Z3VzdCAyMHRoLgoKRm9yIHlvdXIgY29udmVuaWVuY2UsIGhlcmUg aXMgdGhlIHJlbGV2YW50IHRleHQgZnJvbSAtMDA6CgpbLi4uIGNvbW11bml0eSByZXZldy4u Ll0KCj4gwqDCoCA3LsKgIFNob3VsZCBzdWJzdGFudGlhbCBjaGFuZ2VzIGJlIG1hZGUsIGFk ZGl0aW9uYWwgY29tbXVuaXR5IGNhbGxzCj4gwqDCoMKgwqDCoMKgIGZvciBjb21tZW50IHNo b3VsZCBiZSBpc3N1ZWQgYnkgdGhlIFJTQUIsIGFuZCBhZ2FpbiBjb21tZW50cwo+IMKgwqDC oMKgwqDCoCBjb25zaWRlcmVkIGJ5IHRoZSBSU1dHLgo+Cj4gwqDCoCA4LsKgIE9uY2UgYWxs IGNvbW1lbnRzIGhhdmUgYmVlbiBiZWVuIGFkZHJlc3NlZCwgdGhlIFJTV0cgY2hhaXJzIHdp bGwKPiDCoMKgwqDCoMKgwqAgc3VibWl0IHRoZSBwcm9wb3NhbCB0byB0aGUgUlNBQiBmb3Ig aXRzIGNvbnNpZGVyYXRpb24uCj4KPiDCoMKgIDkuwqAgV2l0aGluIGEgcmVhc29uYWJsZSBw ZXJpb2Qgb2YgdGltZSwgdGhlIFJTQUIgd2lsbCB0aGVuIHBvbGwgb24KPiDCoMKgwqDCoMKg wqAgdGhlIHByb3Bvc2FsLsKgIFBvc2l0aW9ucyBtYXkgYmUgYXMgZm9sbG93czogKiAiWUVT IjogdGhlIHByb3Bvc2FsCj4gwqDCoMKgwqDCoMKgIHNob3VsZCBiZSBhcHByb3ZlZCAqICJD T05DRVJOIjogdGhlIHByb3Bvc2FsIHJhaXNlcyBzdWJzdGFudGlhbAo+IMKgwqDCoMKgwqDC oCBjb25jZXJucyB0aGF0IG11c3QgYmUgYWRkcmVzc2VkLsKgICogIlJFQ1VTRSI6IHRoZSBw ZXJzb24gaG9sZGluZwo+IMKgwqDCoMKgwqDCoCB0aGUgcG9zaXRpb24gaGFzIGEgY29uZmxp Y3Qgb2YgaW50ZXJlc3QuCgpbLi4uIGFwcHJvdmFsIGZsb3cgY29udGludWVzLi4uXQoKRWxp b3QKCg== --PEKvyTZFCFIReu8wnIrdcRaszHcuxHPWo-- --8awfkSHrBYmJDvSqgvrHLmQqbK5a4UJLJ Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmENiuwFAwAAAAAACgkQh7ZrRtnSejMP UQf/UIvoZKPY6GG5oAlX7k64DNefXpfjBerGdEmWO9Try9zt5UKCCdtqKq6dvMtccuqAFf/lmAX7 9LmaqwI57RSAgqYI6P7klDMUqgMD2HkRarqA+iybmALtgNsCNf8BGIgH0Pku0IRHBiEvosqEpCoj XCOSqx74YYpE1VjkpxKjn3KDei7msZRe/nTWRZ3l36ESV9ehNB6MonyM+VtgqiFjCrfngTkdcZbC dbtGxnv6CkiSsU3C4d1fvWbW3j6BfiN7xjZpN1wzvRnaNiVYXG7W3H4bEKPeOa3efCJmw+TRWI39 jkZ2j+4P2hBYouZs5Bre3H0Hhk5HavTmnCZgf1pteg== =F1jA -----END PGP SIGNATURE----- --8awfkSHrBYmJDvSqgvrHLmQqbK5a4UJLJ-- From nobody Fri Aug 6 12:58:13 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD303A1420 for ; Fri, 6 Aug 2021 12:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 cRwowMghcy1t for ; Fri, 6 Aug 2021 12:57:58 -0700 (PDT) Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) (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 9773C3A1400 for ; Fri, 6 Aug 2021 12:57:58 -0700 (PDT) Received: by mail-pj1-x1035.google.com with SMTP id s22-20020a17090a1c16b0290177caeba067so24384574pjs.0 for ; Fri, 06 Aug 2021 12:57:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=XTAWOOy/aoylbQFIPQ9ci6va8F5vK3YHrda6NyoyGWI=; b=g5xLSycywxoblNurfMlASS4WhYs0CCffB0RFGIG+zxt0QD9dC2oOIXN+05gGArv/zW z4vX6WsHNB4slUu+Ywgzuhah0baF1WGE6hBRTBAuHEZpUz/UMzOyLYgeDhXkzPCgIdto MeW8NFLV1YuSFD/88DP3p79gf3ffp2gQKsCRlV25oKpi4ffw/R9146mnk3ZnbqftQ5DY tK8b5z15gdm88hZBwdne9rODkkRFMwHWaifRwK9kwJzP5ucNoh7eYjyWvJ4WJYI0+Ucn 4ITu/YDidf9Az1iBE86Mf92t0Q1WlXeny6F3yutguM7lR4KSPnk48CGzM0G5aaC8Xk/C xAGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=XTAWOOy/aoylbQFIPQ9ci6va8F5vK3YHrda6NyoyGWI=; b=lembYD1omCvCQ2Xm+RJJmLejPaYlql8FjZHoLUffwmgJUz0Ehn0O5NnvQWx0+WsuGK ioND99l20x+12a41JcF+rphsbsylupReZTWcGfooiAc250yUvhHcU4ChkYHzuvooFbRE OiLGZRZPWRqRIcpKjceSTDnS0mV+IpxZMrW2RmlzoqnEO1OOYraU7a+CEE9hIaKqLBXc eiU0EhpbNbWygsl3mY+a+ZIQUewB5iWWO6drmKUIapJpGCk5jJveuPzX6AoBrIBdx/aS EMvW69ZZkKBZk7g+ICaAnLx/5bkOiVYR60V0MckCthHYvKQ9oFF65HO2bIf/YEmtClba +wVQ== X-Gm-Message-State: AOAM530ZdEaoEAREkWLGxU/Avf1HCBmH1SC9ZzjCf2TCk2sdWvcwtsbg c3VywS5v67A9AXenEJAwJG0= X-Google-Smtp-Source: ABdhPJzmABtbFgL6RIs1CJWift4FgBapHLIFB489/iUhdSUX4dzhxBmu87tx9KBwEt5hkAsvQt6Tvg== X-Received: by 2002:a63:aa43:: with SMTP id x3mr1021058pgo.208.1628279876974; Fri, 06 Aug 2021 12:57:56 -0700 (PDT) Received: from [10.100.240.114] ([203.109.195.43]) by smtp.gmail.com with ESMTPSA id c3sm9838116pjs.35.2021.08.06.12.57.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 06 Aug 2021 12:57:56 -0700 (PDT) To: adrian@olddog.co.uk, 'Eliot Lear' , 'Jay Daley' Cc: rfced-future@iab.org, "'Joel M. Halpern'" , 'Christian Huitema' References: <2ff1860f-c7c1-9a85-a072-166cf0c17b7c@lear.ch> <17be01d78aa2$6db78e00$4926aa00$@olddog.co.uk> From: Brian E Carpenter Message-ID: <5fb01e47-4027-c20b-36a0-ea7992a7a13c@gmail.com> Date: Sat, 7 Aug 2021 07:57:51 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <17be01d78aa2$6db78e00$4926aa00$@olddog.co.uk> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2021 19:58:12 -0000 I agree, we can defer this issue. Regards Brian Carpenter On 06-Aug-21 21:07, Adrian Farrel wrote: > Eliot, >=20 > I don't think this is something this group should spend time on: we hav= e a primary focus and I suspect this would be a substantial distraction t= hat might even bring the whole thing down. >=20 > It is possible that the RSWG could consider it. >=20 > What needs to be dealt with now? Nothing. Well, can't let Jay's comment=20 go unchallenged. It is entirely possible that he talks to different devel= opers from those I talk to. > Perhaps "trust" is not the right word? I find people trusting rfc-edito= r.org as definitive. It is where the DOIs resolve to. It is the anchor fo= r citations from third-party publications. > But I find people use tools.ietf.org and datatracker.ietf.org (each acc= ording entirely to personal preferences) for convenient and quick access = to RFCs. >=20 > A > -----Original Message----- > From: Rfced-future On Behalf Of Eliot Le= ar > Sent: 06 August 2021 09:06 > To: Jay Daley ; Brian E Carpenter > Cc: rfced-future@iab.org; Joel M. Halpern ; Christ= ian Huitema > Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? >=20 > Question: >=20 > Do people believe this is a topic for THIS group or for the (hopefully = > soon to be created) RSWG? Are there parts that need to be dealt with=20 > NOW and parts that can be dealt with later? >=20 > Eliot >=20 > On 06.08.21 08:40, Jay Daley wrote: >> It=E2=80=99s not about selling RFCs but something more fundamental tha= n that - trust. When an uninitiated person searches for an RFC and sees = results from rfc-editor.org, tools.ietf.org and datatracker.ietf.org then=20 which do they trust? From my experience of talking to many developers ab= out this (over some years), almost none of them trusted rfc-editor.org on=20 first sight because they could not associate it with the IETF and because=20 the name itself did not convey authority/legitimacy. >> >> Jay >> >> (sent from my phone) >> >=20 >=20 > . >=20 From nobody Fri Aug 6 12:59:47 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1531A3A1417 for ; Fri, 6 Aug 2021 12:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 43YDlycKrny7 for ; Fri, 6 Aug 2021 12:59:41 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E150F3A1411 for ; Fri, 6 Aug 2021 12:59:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id AEF83300C4D for ; Fri, 6 Aug 2021 15:59:40 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id LCgMO-VO7wpY for ; Fri, 6 Aug 2021 15:59:39 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id BE3293004A7; Fri, 6 Aug 2021 15:59:38 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) From: Russ Housley In-Reply-To: <17be01d78aa2$6db78e00$4926aa00$@olddog.co.uk> Date: Fri, 6 Aug 2021 15:59:37 -0400 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <2ff1860f-c7c1-9a85-a072-166cf0c17b7c@lear.ch> <17be01d78aa2$6db78e00$4926aa00$@olddog.co.uk> To: Adrian Farrel , Eliot Lear X-Mailer: Apple Mail (2.3445.104.21) Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2021 19:59:46 -0000 I agree, this is not something that this group should work on at this = time. Russ > On Aug 6, 2021, at 5:07 AM, Adrian Farrel wrote: >=20 > Eliot, >=20 > I don't think this is something this group should spend time on: we = have a primary focus and I suspect this would be a substantial = distraction that might even bring the whole thing down. >=20 > It is possible that the RSWG could consider it. >=20 > What needs to be dealt with now? Nothing. Well, can't let Jay's = comment go unchallenged. It is entirely possible that he talks to = different developers from those I talk to. > Perhaps "trust" is not the right word? I find people trusting = rfc-editor.org as definitive. It is where the DOIs resolve to. It is the = anchor for citations from third-party publications. > But I find people use tools.ietf.org and datatracker.ietf.org (each = according entirely to personal preferences) for convenient and quick = access to RFCs. >=20 > A > -----Original Message----- > From: Rfced-future On Behalf Of Eliot = Lear > Sent: 06 August 2021 09:06 > To: Jay Daley ; Brian E Carpenter = > Cc: rfced-future@iab.org; Joel M. Halpern ; = Christian Huitema > Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? >=20 > Question: >=20 > Do people believe this is a topic for THIS group or for the (hopefully=20= > soon to be created) RSWG? Are there parts that need to be dealt with=20= > NOW and parts that can be dealt with later? >=20 > Eliot >=20 > On 06.08.21 08:40, Jay Daley wrote: >> It=E2=80=99s not about selling RFCs but something more fundamental = than that - trust. When an uninitiated person searches for an RFC and = sees results from rfc-editor.org, tools.ietf.org and = datatracker.ietf.org then which do they trust? =46rom my experience of = talking to many developers about this (over some years), almost none of = them trusted rfc-editor.org on first sight because they could not = associate it with the IETF and because the name itself did not convey = authority/legitimacy. >>=20 >> Jay >>=20 >> (sent from my phone) >>=20 >=20 >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future From nobody Fri Aug 6 14:04:23 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 031BA3A177B for ; Fri, 6 Aug 2021 14:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=me.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 1M1HLngihi5H for ; Fri, 6 Aug 2021 14:04:17 -0700 (PDT) Received: from mr85p00im-ztdg06021201.me.com (mr85p00im-ztdg06021201.me.com [17.58.23.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DE283A1778 for ; Fri, 6 Aug 2021 14:04:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=1a1hai; t=1628283856; bh=cj7IYKkwGMZbOj18nni8mvOzXpLZV3lAE6UOk48mnXg=; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:To; b=PPt6dmBtRVYEMU+hrOtCdOr8foSiNQIQrFx1ayBmUnQzCqdCdL8aBnO6SIhXwRFXz QAHvpA2MwHmNVCk2PF0zpvJ9AY+H8w43fWa1LtPKRpfGlcTmpjescFyszvN/haDjLQ a+I9F9fbLDkXJiNFHT4b6iAYR6k+Ht9TVI7TFlOdRXTOjw//mTjKwhr5R3JZcjg2j7 aP0qntvoyuqXrlEn6r8NDCXyd0HYRVirsdJu8VjH0W2J9O3iYwIBNLbcTXGAdqxlf/ c7rKqe0uOLaOE4quWJgfE7eLxaQP3hmaq/1X+gGI/+a6asDRZ1RtdudYFpXlHXxf97 xZsV8gb5kPK4w== Received: from smtpclient.apple (157-131-155-250.fiber.dynamic.sonic.net [157.131.155.250]) by mr85p00im-ztdg06021201.me.com (Postfix) with ESMTPSA id A5EED12032D; Fri, 6 Aug 2021 21:04:15 +0000 (UTC) From: Ole Jacobsen Message-Id: <6ED4E99D-F8A0-44C5-9BC8-DA41044D7E09@me.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_7005A832-AD33-485E-AEC6-55F397B5D6E1" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Fri, 6 Aug 2021 14:04:15 -0700 In-Reply-To: Cc: Ole Jacobsen , Adrian Farrel , Eliot Lear , rfced-future@iab.org To: Russ Housley References: <2ff1860f-c7c1-9a85-a072-166cf0c17b7c@lear.ch> <17be01d78aa2$6db78e00$4926aa00$@olddog.co.uk> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Proofpoint-Virus-Version: =?UTF-8?Q?vendor=3Dfsecure_engine=3D1.1.170-22c6f66c430a71ce266a39bfe25bc?= =?UTF-8?Q?2903e8d5c8f:6.0.391,18.0.790,17.0.607.475.0000000_definitions?= =?UTF-8?Q?=3D2021-08-06=5F06:2021-08-05=5F02,2021-08-06=5F06,2020-04-07?= =?UTF-8?Q?=5F01_signatures=3D0?= X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 adultscore=0 clxscore=1011 mlxlogscore=999 phishscore=0 bulkscore=0 suspectscore=0 malwarescore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2108060137 Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2021 21:04:22 -0000 --Apple-Mail=_7005A832-AD33-485E-AEC6-55F397B5D6E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This discussion reminds me of a bunch of recent TV ads that have the = following tag line: "Angie's List is now Angi" This change of name is the result of the merger of Home Advisor and = Angie's List into one company. Somehow they believe that the consumer will care and = understand this change in name. Even if there might be subtle differences in the = services offered between the two old companies and the new one, I am going to = guess that nobody at the user side will know or care and thus the new name just = introduces confusion. There used to be a person (or actually several people, so a function) = called the RFC Editor. In the most recent iteration it became the RFC Series Editor = because we're engineers and we like to over-specify and none of us understand = the meaning of the word "approximately." The RFC Editor or the RFC Series Editor was = a point of contact, a function, a website, a place to get started. The fact that = we've replicated documents and built a confusing mesh of "tools.ietf.org = " and "datatracter.ietf.org = " and "rfc-editor.org " where various incarnations = of the RFC documents and the drafts that came before them are hosted, does not make things easier for = *outsiders*. Changing the title based on a precise description of what this role = entails isn't helpful IMO. I get job suggestions from LinkeIn all the time that = includes the word "Editor" but the actual job descriptions are all over the map. We know (or we knew) what the RFC Editor does (approximately). Do we = really need=20 to invent yet another title? Ole Ole J. Jacobsen Editor and Publisher The Internet Protocol Journal Office: +1 415-550-9433 Cell: +1 415-370-4628 Web: protocoljournal.org E-mail: olejacobsen@me.com E-mail: ole@protocoljournal.org Skype: organdemo --Apple-Mail=_7005A832-AD33-485E-AEC6-55F397B5D6E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

This discussion reminds me of a bunch of = recent TV ads that have the following
tag line: "Angie's = List is now Angi"

This change of name is the result of the merger of Home = Advisor and Angie's List
into one company. Somehow = they believe that the consumer will care and understand
this change in name. Even if there might be subtle = differences in the services
offered between the two = old companies and the new one, I am going to guess that
nobody at the user side will know or care and thus the new = name just introduces
confusion.

There used to be a = person (or actually several people, so a function) called the
RFC Editor. In the most recent iteration it became the RFC = Series Editor because
we're engineers and we like = to over-specify and none of us understand the meaning
of the word "approximately." The RFC Editor or the RFC Series = Editor was a point
of contact, a function, a = website, a place to get started. The fact that we've
replicated documents and built a confusing mesh of "tools.ietf.org" and "datatracter.ietf.org"
and "rfc-editor.org" where = various incarnations of the RFC documents and the drafts
that came before them are hosted, does not make things easier = for *outsiders*.

Changing the title based on a precise description of what = this role entails
isn't helpful IMO. I get job = suggestions from LinkeIn all the time that includes
the word "Editor" but the actual job descriptions are all = over the map.

We= know (or we knew) what the RFC Editor does (approximately). Do we = really need 
to invent yet another = title?

Ole


Ole J. Jacobsen
Editor and Publisher
The Internet = Protocol Journal
Office: +1 415-550-9433
Cell:   +1 415-370-4628
Web: protocoljournal.org
E-mail: olejacobsen@me.com
E-mail: ole@protocoljournal.org
Skype: = organdemo



= --Apple-Mail=_7005A832-AD33-485E-AEC6-55F397B5D6E1-- From nobody Fri Aug 6 19:15:24 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 959FF3A24B8 for ; Fri, 6 Aug 2021 19:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=qwPeFSfG; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=XTvZszig 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 T-e8rNHEiL8D for ; Fri, 6 Aug 2021 19:15:17 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D4CF3A1755 for ; Fri, 6 Aug 2021 19:15:17 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id A595A3200946; Fri, 6 Aug 2021 22:15:15 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Fri, 06 Aug 2021 22:15:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=E efYGoCm+3QE+Z14yjqWxO5o6OJCm31jYLJWuuxAdgE=; b=qwPeFSfGEn5/MvS9o eCAhvgM4FROkIZMwjxc5KtkQNT/lhpv7en5GmSj19wfLfbrhyKySbzT5vf+bcfMH prK14s58CB+QSAgOKA2iUht4OKeC5k01zw3o5i5WYdWUweejLVdcxb22CbNX/zNe ydynB1JWzbftt1EdS+wz52KplY7xblAgzzIc3f/GdH9zI4SzVOioVvjykYmurYdM VxORWiwlXP9+0C6FRKt6GCYxOA7Qa1NxbZogaHFvUyW4ZcZT6nw+SB5mFp/TjKAF rKNAL21USmh2SjCk3M32wIFjjfLU4Z99NM0x/HsXRyzc+FuxzT1Y8/TAUnGOrrig r3ybQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=EefYGoCm+3QE+Z14yjqWxO5o6OJCm31jYLJWuuxAd gE=; b=XTvZszigsU7sGWf2+tshlBKWMknK+wP7lXsoB9TzhXEDe4wDUE8rBUShR 66iaICR+m6SW6SU6MozKBKkQOyGmEOq6YP6lP2aosMy+lWQf2MDaCN/tlY1IN4Tp IBSYxa/jZL5sh7Ve4YmfbVdxY86ra/l3E60y63Epsp27QJ4RfOwacQkwNC6oaenN xjxT4NI1IT0FTQBBsVo20xA/jvT0oEI+jsKnaDj4rw2ifeSEo/ICVJGBeVAW1wvW 0PSr+IFacMPrzLBKPn5wEaYdYW4bT8PkDNZeaxCat01sAIBCDb9c3cl4mn4V+otC ODooxUx3ZiEk/naeR+gAmYwYfqo4Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrjedvgdehfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepvefffffhudetveevhfeuffeigedtuedtheffleetffeftddtgeegjeehieeuteet necuffhomhgrihhnpehmnhhothdrnhgvthenucevlhhushhtvghrufhiiigvpedtnecurf grrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 6 Aug 2021 22:15:09 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Mark Nottingham In-Reply-To: <6ED4E99D-F8A0-44C5-9BC8-DA41044D7E09@me.com> Date: Sat, 7 Aug 2021 12:15:07 +1000 Cc: Russ Housley , rfced-future@iab.org, Adrian Farrel , Ole Jacobsen , Eliot Lear Content-Transfer-Encoding: quoted-printable Message-Id: <76A41360-80BC-41B7-AAB2-2609CA11DD82@mnot.net> References: <2ff1860f-c7c1-9a85-a072-166cf0c17b7c@lear.ch> <17be01d78aa2$6db78e00$4926aa00$@olddog.co.uk> <6ED4E99D-F8A0-44C5-9BC8-DA41044D7E09@me.com> To: Ole Jacobsen X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Aug 2021 02:15:22 -0000 > On 7 Aug 2021, at 7:04 am, Ole Jacobsen = wrote: >=20 > We know (or we knew) what the RFC Editor does (approximately). Do we = really need=20 > to invent yet another title? What person or body are you referring to when you ask that question? -- Mark Nottingham https://www.mnot.net/ From nobody Fri Aug 6 21:07:23 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6090D3A27F8 for ; Fri, 6 Aug 2021 21:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=me.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 r-CKPONkbcbg for ; Fri, 6 Aug 2021 21:07:16 -0700 (PDT) Received: from mr85p00im-zteg06021501.me.com (mr85p00im-zteg06021501.me.com [17.58.23.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8CC23A27F6 for ; Fri, 6 Aug 2021 21:07:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=1a1hai; t=1628309236; bh=/Vz2PYbZIiDBdHHyoU3AJ5LqIQ4+SUAzmdoiSwIIpKk=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=WKmeVPxhuHbIyG4LhQr2uXVflzfIWRKPRanBptZfPdhENfQikq32BlEopLJSIMTrD 0IQ72oB6TuCWjfLwoVqOdZyO2kltQYxmmgM9HoQxiUngTMxblK068TxuP04Qghpsoy 4KrpVty9bAvFhFL22pIPkzMysNPsB3jRcS38f94WJphP2yl/QAhOLp9Ughngx0en4a lIhLXV71i0+8BUpEPFnRyf3OK1XR1FD9Gqv56PrqA9Gk3S5/3pJVlXVJ8iDatCR0Lr w4fqETA4Q3aFHcqATfwOvf09ckKFAzGy7wVJjdBX1UOx1Sx5OcIzR1pUklHGQjYQaJ L6kNNIlTXwwdQ== Received: from smtpclient.apple (157-131-155-250.fiber.dynamic.sonic.net [157.131.155.250]) by mr85p00im-zteg06021501.me.com (Postfix) with ESMTPSA id EAC4D380677; Sat, 7 Aug 2021 04:07:15 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) From: Ole Jacobsen In-Reply-To: <76A41360-80BC-41B7-AAB2-2609CA11DD82@mnot.net> Date: Fri, 6 Aug 2021 21:07:14 -0700 Cc: Ole Jacobsen , Russ Housley , rfced-future@iab.org, Adrian Farrel , Eliot Lear Message-Id: <592F3344-C08A-4D38-AD66-2B26D95A37D8@me.com> References: <76A41360-80BC-41B7-AAB2-2609CA11DD82@mnot.net> To: Mark Nottingham X-Mailer: iPhone Mail (18G82) X-Proofpoint-Virus-Version: =?UTF-8?Q?vendor=3Dfsecure_engine=3D1.1.170-22c6f66c430a71ce266a39bfe25bc?= =?UTF-8?Q?2903e8d5c8f:6.0.391,18.0.790,17.0.607.475.0000000_definitions?= =?UTF-8?Q?=3D2021-08-06=5F08:2021-08-05=5F02,2021-08-06=5F08,2020-04-07?= =?UTF-8?Q?=5F01_signatures=3D0?= X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 adultscore=0 bulkscore=0 malwarescore=0 mlxlogscore=950 mlxscore=0 phishscore=0 clxscore=1011 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2108070023 Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Aug 2021 04:07:21 -0000 See $subject-of-this-thread Sent from my iPhone > On 6 Aug 2021, at 19:15, Mark Nottingham wrote: >=20 > =EF=BB=BF >=20 >> On 7 Aug 2021, at 7:04 am, Ole Jacobsen wrote: >>=20 >> We know (or we knew) what the RFC Editor does (approximately). Do we real= ly need=20 >> to invent yet another title? >=20 > What person or body are you referring to when you ask that question? >=20 >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 From nobody Sat Aug 7 08:53:03 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 899533A3E9A for ; Sat, 7 Aug 2021 08:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 WLyZHqVJwo43 for ; Sat, 7 Aug 2021 08:52:57 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD81C3A3E98 for ; Sat, 7 Aug 2021 08:52:56 -0700 (PDT) Received: from smtpclient.apple (ip-109-42-114-213.web.vodafone.de [109.42.114.213]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4Ghn1H5xvbz2xLC; Sat, 7 Aug 2021 17:52:51 +0200 (CEST) Content-Type: multipart/alternative; boundary=Apple-Mail-93F2A3D9-BA37-40D1-BD48-BE2FE4969ECC Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) From: Carsten Bormann In-Reply-To: <443C70D9-8869-4C31-992B-8F57C6DCB6C4@vigilsec.com> Date: Sat, 7 Aug 2021 17:52:51 +0200 Cc: Christian Huitema , rfced-future@iab.org, Joel Halpern , Jay Daley Message-Id: References: <443C70D9-8869-4C31-992B-8F57C6DCB6C4@vigilsec.com> To: Russ Housley X-Mailer: iPhone Mail (18G82) Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Aug 2021 15:53:02 -0000 --Apple-Mail-93F2A3D9-BA37-40D1-BD48-BE2FE4969ECC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I don=E2=80=99t think this groups should try to design doc.Ietf.org. If thi= s is done right, it will be Practical. The source that people will want to use.=20 Informative. Not just a copy of the RFC, but Status, links, =E2=80=A6 Stable. The Uris won=E2=80=99t decay. =20 Non-damaging. Yes, this requires some thinking if it is going to be better t= han what we have.=20 Useful. For our audience, but also for ourselves.=20 Sent from mobile, sorry for terse > On 6. Aug 2021, at 21:12, Russ Housley wrote: >=20 > This already works. It is a duplicate of the files on rfc-editor.org --Apple-Mail-93F2A3D9-BA37-40D1-BD48-BE2FE4969ECC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable I don=E2=80=99t think this groups should tr= y to design doc.Ietf.org.  If this is done right, it will be

Practical. The source that people will want to use. 

Informative.  Not just a copy of the RFC, but Status, l= inks, =E2=80=A6

Stable. The Uris won=E2=80=99t deca= y.  

Non-damaging.  Yes, this requires so= me thinking if it is going to be better than what we have. 
<= br>
Useful. For our audience, but also for ourselves. 

Sent from mobil= e, sorry for terse

On 6. Aug 2021, at 21:12, Russ Housley <housley@vigilsec.com> wrote:=

This a= lready works.  It is a duplicate of the files on rfc-editor.org
= --Apple-Mail-93F2A3D9-BA37-40D1-BD48-BE2FE4969ECC-- From nobody Sat Aug 7 10:22:12 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7F63A0779 for ; Sat, 7 Aug 2021 10:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 iDDoHBXfYnw5 for ; Sat, 7 Aug 2021 10:22:05 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2788A3A0776 for ; Sat, 7 Aug 2021 10:22:05 -0700 (PDT) Received: from smtpclient.apple (ip5886a2c1.dynamic.kabel-deutschland.de [88.134.162.193]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4Ghq0B2WyCz2xLJ; Sat, 7 Aug 2021 19:22:02 +0200 (CEST) Content-Type: multipart/alternative; boundary=Apple-Mail-418E6355-F96D-4198-94D0-B719060C1C73 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) From: Carsten Bormann In-Reply-To: <6ED4E99D-F8A0-44C5-9BC8-DA41044D7E09@me.com> Date: Sat, 7 Aug 2021 19:22:01 +0200 Cc: Russ Housley , rfced-future@iab.org, Adrian Farrel , Ole Jacobsen , Eliot Lear Message-Id: <8F92C365-52B8-4045-98A5-7C94D2663302@tzi.org> References: <6ED4E99D-F8A0-44C5-9BC8-DA41044D7E09@me.com> To: Ole Jacobsen X-Mailer: iPhone Mail (18G82) Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Aug 2021 17:22:10 -0000 --Apple-Mail-418E6355-F96D-4198-94D0-B719060C1C73 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1 Look at outcomes, not at ideological consistency.=20 Sent from mobile, sorry for terse > On 6. Aug 2021, at 23:04, Ole Jacobsen wrote: >=20 > =EF=BB=BF >=20 > This discussion reminds me of a bunch of recent TV ads that have the follo= wing > tag line: "Angie's List is now Angi" >=20 > This change of name is the result of the merger of Home Advisor and Angie'= s List > into one company. Somehow they believe that the consumer will care and und= erstand > this change in name. Even if there might be subtle differences in the serv= ices > offered between the two old companies and the new one, I am going to guess= that > nobody at the user side will know or care and thus the new name just intro= duces > confusion. >=20 > There used to be a person (or actually several people, so a function) call= ed the > RFC Editor. In the most recent iteration it became the RFC Series Editor b= ecause > we're engineers and we like to over-specify and none of us understand the m= eaning > of the word "approximately." The RFC Editor or the RFC Series Editor was a= point > of contact, a function, a website, a place to get started. The fact that w= e've > replicated documents and built a confusing mesh of "tools.ietf.org" and "d= atatracter.ietf.org" > and "rfc-editor.org" where various incarnations of the RFC documents and t= he drafts > that came before them are hosted, does not make things easier for *outside= rs*. >=20 > Changing the title based on a precise description of what this role entail= s > isn't helpful IMO. I get job suggestions from LinkeIn all the time that in= cludes > the word "Editor" but the actual job descriptions are all over the map. >=20 > We know (or we knew) what the RFC Editor does (approximately). Do we reall= y need=20 > to invent yet another title? >=20 > Ole >=20 >=20 > Ole J. Jacobsen > Editor and Publisher > The Internet Protocol Journal > Office: +1 415-550-9433 > Cell: +1 415-370-4628 > Web: protocoljournal.org > E-mail: olejacobsen@me.com > E-mail: ole@protocoljournal.org > Skype: organdemo >=20 >=20 >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future --Apple-Mail-418E6355-F96D-4198-94D0-B719060C1C73 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1

Look at outcomes, not= at ideological consistency. 

Sent from mobile, sorry for terse

On 6. Aug 2021, at 23:04, Ole Jacobsen &= lt;olejacobsen=3D40me.com@dmarc.ietf.org> wrote:

=EF=BB=BF

This discussion reminds me of a bunch of recent TV ads that h= ave the following
tag line: "Angie's List is now Angi"
<= div class=3D"">
This change of name is t= he result of the merger of Home Advisor and Angie's List
into one company. Somehow they believe that the consumer will care and und= erstand
this change in name. Even if there might be sub= tle differences in the services
offered between the two= old companies and the new one, I am going to guess that
nobody at the user side will know or care and thus the new name just intro= duces
confusion.

There used to be a person (or actually several people, s= o a function) called the
RFC Editor. In the most recent= iteration it became the RFC Series Editor because
we'r= e engineers and we like to over-specify and none of us understand the meanin= g
of the word "approximately." The RFC Editor or the RFC= Series Editor was a point
of contact, a function, a we= bsite, a place to get started. The fact that we've
repl= icated documents and built a confusing mesh of "tools.ietf.org" and "datatracter.ietf.org"
and "rfc-editor.org" where various inca= rnations of the RFC documents and the drafts
that came b= efore them are hosted, does not make things easier for *outsiders*.

Changing the title based o= n a precise description of what this role entails
isn't= helpful IMO. I get job suggestions from LinkeIn all the time that includes<= /div>
the word "Editor" but the actual job descriptions are a= ll over the map.

W= e know (or we knew) what the RFC Editor does (approximately). Do we really n= eed 
to invent yet another title?

Ole


Ole J. Jacobsen
Editor= and Publisher
The Internet Protocol Journal
Office: +1 415-550-9433
Cell:   +1 415-370-4628
Web: protocolj= ournal.org
E-mail: olejacobsen@me.com
E-mail: ole@protoco= ljournal.org
Skype: organdemo



--
Rfced-future mailing list
Rfced-future@iab.org
https://www.iab.org/mailma= n/listinfo/rfced-future
= --Apple-Mail-418E6355-F96D-4198-94D0-B719060C1C73-- From nobody Sat Aug 7 13:09:42 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48D333A0E8D for ; Sat, 7 Aug 2021 13:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 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, FREEMAIL_REPLY=1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 60sskHqUlcx7 for ; Sat, 7 Aug 2021 13:09:36 -0700 (PDT) Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (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 8BA043A0E90 for ; Sat, 7 Aug 2021 13:09:36 -0700 (PDT) Received: by mail-pl1-x634.google.com with SMTP id d1so11909252pll.1 for ; Sat, 07 Aug 2021 13:09:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Y0L9QKzmmmB5YYl4Vf/B/addI2ToZE/muEG11Sk/OKs=; b=e6S0lEEw7FjL0YA58yvQrxEn07MylX8ISGMebXtbR9IhnCTiT5YyZ//e1ufh3acHLz F6t+dlSXgtdUEm8jTc6y89YZqprSTOuXjLmoW5jh5IZ2bub6hLVFxgKnCye8akYqIXDX KvyVPJ6Q+43Nz3+BNlKDJ1iRKB5jcWAbPXDuushCaPk37scqYP9lJ+JnmAipKEPr5BhM S41liLPlm4S7P5+ajq4B7O3JCXKSCBHiBzfjDh/Nb6AKzOCMDasppm2ynjrdoQOqcHgw uZqxdcPL12voUHcUIUFrn/k3NM81AbbV8mOc/q541wztCtqWvEhtGf1c4Vb3YGNh6luI MEBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Y0L9QKzmmmB5YYl4Vf/B/addI2ToZE/muEG11Sk/OKs=; b=uM/1nHXVHFOsL1upwMY8TKD/3FRQgt9vlk1zAEPR3o7uo0ZTXPI1KTM68+4DDfvPXd h9AQPBNYr7vO33jEHfBWPvqxfDc4xlKsUY0NcBsx9w2F/UhhOuAf6pcSmph88z7ilW4K RO7x8lz1G7OwF4MhSEao+BH4bQSQQ4cNE0yr5vq3YCI3W62HwQrE6WKL2a4S2CeLH5LT 9qWKX0kWhax88QFl2dzHq1H1s3sC4eabHbxeSAWZdOYkbvU6mYDoL4OV18A8DI09d4Zj eGVUMk/Lel7RQAqyyS44DOC5jgcj7E6pLEUq86MYdIcKvkzpwXBFuhh/6XVI3A39Nq4/ LAMw== X-Gm-Message-State: AOAM533p2khtQTaGcYKC2/tDrJiukf/Gn7IlJxCqhgGHnQWxbLpI/9jp +sq/pO70R5RB61BzjJgT/S4= X-Google-Smtp-Source: ABdhPJybOKU9lfUTWU65IqO1mfOsgVWMLeaqdlV9Xr2gV7xpuyGY6RyOsFaiYNqH/8HlGDFB6rpXMA== X-Received: by 2002:a62:52cc:0:b029:3b1:1f36:8bbc with SMTP id g195-20020a6252cc0000b02903b11f368bbcmr16737715pfb.16.1628366974956; Sat, 07 Aug 2021 13:09:34 -0700 (PDT) Received: from [10.100.240.114] ([203.109.195.43]) by smtp.gmail.com with ESMTPSA id 21sm15347622pfw.67.2021.08.07.13.09.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 07 Aug 2021 13:09:34 -0700 (PDT) To: Carsten Bormann , Ole Jacobsen Cc: rfced-future@iab.org, Adrian Farrel , Ole Jacobsen , Russ Housley , Eliot Lear References: <6ED4E99D-F8A0-44C5-9BC8-DA41044D7E09@me.com> <8F92C365-52B8-4045-98A5-7C94D2663302@tzi.org> From: Brian E Carpenter Message-ID: <074b08f9-7102-d4da-451e-cd8cf5bf1796@gmail.com> Date: Sun, 8 Aug 2021 08:09:28 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <8F92C365-52B8-4045-98A5-7C94D2663302@tzi.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Aug 2021 20:09:41 -0000 Well yes. And the outcome in this particular space is whether we can recr= uit a suitable person for the role whose name we are discussing. The name=20 of the role affects that outcome. Of course there will always be an RFC Editor service. Regards Brian On 08-Aug-21 05:22, Carsten Bormann wrote: > +1 >=20 > Look at outcomes, not at ideological consistency.=C2=A0 >=20 > Sent from=C2=A0mobile, sorry for terse >=20 >> On 6. Aug 2021, at 23:04, Ole Jacobsen wrote: >> >> =EF=BB=BF >> >> This discussion reminds me of a bunch of recent TV ads that have the f= ollowing >> tag line: "Angie's List is now Angi" >> >> This change of name is the result of the merger of Home Advisor and An= gie's List >> into one company. Somehow they believe that the consumer will care and=20 understand >> this change in name. Even if there might be subtle differences in the = services >> offered between the two old companies and the new one, I am going to g= uess that >> nobody at the user side will know or care and thus the new name just i= ntroduces >> confusion. >> >> There used to be a person (or actually several people, so a function) = called the >> RFC Editor. In the most recent iteration it became the RFC Series Edit= or because >> we're engineers and we like to over-specify and none of us understand = the meaning >> of the word "approximately." The RFC Editor or the RFC Series Editor w= as a point >> of contact, a function, a website, a place to get started. The fact th= at we've >> replicated documents and built a confusing mesh of "tools.ietf.org " and "datatracter.ietf.org " >> and "rfc-editor.org " where various incarnation= s of the RFC documents and the drafts >> that came before them are hosted, does not make things easier for *out= siders*. >> >> Changing the title based on a precise description of what this role en= tails >> isn't helpful IMO. I get job suggestions from LinkeIn all the time tha= t includes >> the word "Editor" but the actual job descriptions are all over the map= =2E >> >> We know (or we knew) what the RFC Editor does (approximately). Do we r= eally need=C2=A0 >> to invent yet another title? >> >> Ole >> >> >> Ole J. Jacobsen >> Editor and Publisher >> The Internet Protocol=C2=A0Journal >> Office: +1 415-550-9433 >> Cell: =C2=A0 +1 415-370-4628 >> Web:=C2=A0protocoljournal.org >> E-mail:=C2=A0olejacobsen@me.com >> E-mail:=C2=A0ole@protocoljournal.org >> Skype: organdemo >> >> >> >> --=20 >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future >=20 From nobody Sat Aug 7 13:14:30 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 751C13A0EEC for ; Sat, 7 Aug 2021 13:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no 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 YlHUe0DHiMYX for ; Sat, 7 Aug 2021 13:14:24 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04B593A0EEA for ; Sat, 7 Aug 2021 13:14:23 -0700 (PDT) Received: from xse164.mail2web.com ([66.113.196.164] helo=xse.mail2web.com) by mx136.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1mCShy-000SQS-Nr for rfced-future@iab.org; Sat, 07 Aug 2021 22:14:20 +0200 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 4Ghtpr2nKjzPR9 for ; Sat, 7 Aug 2021 13:14:12 -0700 (PDT) Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1mCShw-0002q2-8a for rfced-future@iab.org; Sat, 07 Aug 2021 13:14:12 -0700 Received: (qmail 16532 invoked from network); 7 Aug 2021 20:14:11 -0000 Received: from unknown (HELO [192.168.1.104]) (Authenticated-user:_huitema@huitema.net@[172.58.46.189]) (envelope-sender ) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 7 Aug 2021 20:14:10 -0000 To: Brian E Carpenter , Carsten Bormann , Ole Jacobsen Cc: rfced-future@iab.org, Adrian Farrel , Russ Housley , Ole Jacobsen , Eliot Lear References: <6ED4E99D-F8A0-44C5-9BC8-DA41044D7E09@me.com> <8F92C365-52B8-4045-98A5-7C94D2663302@tzi.org> <074b08f9-7102-d4da-451e-cd8cf5bf1796@gmail.com> From: Christian Huitema Message-ID: <30c5c94e-4c51-e3eb-9631-4b52ff1f8f1b@huitema.net> Date: Sat, 7 Aug 2021 13:14:10 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <074b08f9-7102-d4da-451e-cd8cf5bf1796@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Originating-IP: 66.113.196.164 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.196.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9WLQux0N3HQm8ltz8rnu+BPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5yXEnUqtuiszqcStXlDoE9S53HEEk0VSrq03gtFxbC/KoTj irp8spbF6zFJ6fnmiRvwbOl0qtP5EgfDRdSDhnwOSxIRXVMlFuiz/acFNeeXtxN2fFxZWB9eYgpR BRu3UlDHMLIJYRi1cXH9Dbm+IxLV0XgtlP1veEWDxFjeo42e2HGFd932lfz+R/06O3Iy4akhy/LP m2rFgOGYwKKX1POmkVWClPVvbW5lVyQanRxw5hTHswbbB/ha+ZWrSAi8SkwqWAikMcSxTAWn8RCv ieGEqjG/gXZAaRh1X6LVetRf2ZYIiHqfCgG4wrA3w4/kQTYKxDHA9JN9J4k4XZq11JQkMemT4rxn nByU11Ftkqf3f/PF3GUV+KdBBqrnCX8j0Gi8Ksk+aedMfNWSnJswrtlNtZo3HPHi5Q+jjsF5dcBx ehWYzrkgsp4/Fysgb2cPV4IH0+lPwKr4i5mAANUcVraZYOaeuiH/yEdZH8S1+TgcJBOjh0vPxcQO jKKOrYIQYpwamUdylUIKhf3z2GAHxH7Iiihnln5nLwsYugixy853dgjI4WE+pjPnfrWRF8b8VMfk hF4k5q+n7ItnyCYBQBa4b3UQT3xbkHqpqmyCe4PiKWIgJ2XxgK7Je5b0uU+cZFhDVPQ6fMev1BMP vQ9qu4cW0z6bhalFEM/pjPCQA+BAlpidDxziDb/uBE29ZM8XfOG3h1ESmlc3/lS5x7qxkdlaBas4 Wvr8fiKvjJAkREiYlZxLVY4E6HXTtTKBacJJohlRXxKF5tPxTxfD0dMN+t5Z9vNU2K0VuFBwFXci VIyl6i7WcVfvwPW+1tEygn0RV92N9/YGRrhMRGhIOTxMW00yF8F1u0YDQf8cLP9taeSLFY0fPBnF 89BphpBNlUg+TzHwBTL1+6vDOMemz/4I88NDcmnEJ4r7C+SwLRamrhQTd3PrpJpP5ewAjeqkzRNl ucyd+NO2McmveAr4ch9F7rE89jihx+Za/cV70jOJzN2r4A== X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Aug 2021 20:14:29 -0000 On 8/7/2021 1:09 PM, Brian E Carpenter wrote: > Well yes. And the outcome in this particular space is whether we can recruit a suitable person for the role whose name we are discussing. The name > of the role affects that outcome. This cuts both ways. Suppose we recruit someone with a lofty title, and then that person realizes that the actual work is not that exhilarating. That too will lead to frustration and undesirable outcomes. -- Christian Huitema > > Of course there will always be an RFC Editor service. > > Regards > Brian > > On 08-Aug-21 05:22, Carsten Bormann wrote: >> +1 >> >> Look at outcomes, not at ideological consistency. >> >> Sent from mobile, sorry for terse >> >>> On 6. Aug 2021, at 23:04, Ole Jacobsen wrote: >>> >>>  >>> >>> This discussion reminds me of a bunch of recent TV ads that have the following >>> tag line: "Angie's List is now Angi" >>> >>> This change of name is the result of the merger of Home Advisor and Angie's List >>> into one company. Somehow they believe that the consumer will care and > understand >>> this change in name. Even if there might be subtle differences in the services >>> offered between the two old companies and the new one, I am going to guess that >>> nobody at the user side will know or care and thus the new name just introduces >>> confusion. >>> >>> There used to be a person (or actually several people, so a function) called the >>> RFC Editor. In the most recent iteration it became the RFC Series Editor because >>> we're engineers and we like to over-specify and none of us understand the meaning >>> of the word "approximately." The RFC Editor or the RFC Series Editor was a point >>> of contact, a function, a website, a place to get started. The fact that we've >>> replicated documents and built a confusing mesh of "tools.ietf.org " and "datatracter.ietf.org " >>> and "rfc-editor.org " where various incarnations of the RFC documents and the drafts >>> that came before them are hosted, does not make things easier for *outsiders*. >>> >>> Changing the title based on a precise description of what this role entails >>> isn't helpful IMO. I get job suggestions from LinkeIn all the time that includes >>> the word "Editor" but the actual job descriptions are all over the map. >>> >>> We know (or we knew) what the RFC Editor does (approximately). Do we really need >>> to invent yet another title? >>> >>> Ole >>> >>> >>> Ole J. Jacobsen >>> Editor and Publisher >>> The Internet Protocol Journal >>> Office: +1 415-550-9433 >>> Cell:   +1 415-370-4628 >>> Web: protocoljournal.org >>> E-mail: olejacobsen@me.com >>> E-mail: ole@protocoljournal.org >>> Skype: organdemo >>> >>> >>> >>> -- >>> Rfced-future mailing list >>> Rfced-future@iab.org >>> https://www.iab.org/mailman/listinfo/rfced-future From nobody Sat Aug 7 13:19:30 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72B1C3A0FC2 for ; Sat, 7 Aug 2021 13:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 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, FREEMAIL_REPLY=1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 jhDJry2cbJEY for ; Sat, 7 Aug 2021 13:19:23 -0700 (PDT) Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (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 ADA383A0EA9 for ; Sat, 7 Aug 2021 13:19:23 -0700 (PDT) Received: by mail-pl1-x62a.google.com with SMTP id a20so11964180plm.0 for ; Sat, 07 Aug 2021 13:19:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=YGwxJVkqpDSKGvOpQFLfY5N6LLoO+Aew6VFX7/UamXE=; b=WfjYD4eHrdwCJqUB0mUS8h08wRDPfetI2GJ2j25sk9HfadQnTye9pdq/HmmZuz1MXW Z2tNmmqX9pBUhUgmZPY+qMytwS3p/Qp/pfi9XpbKlP3iUxz/fx7dXiikbSfsNiwroIDV F56bkNSVKKH2ahwQQR0sLwvQYLl7xx0Xg8HkzH53SJ85Ei/SXbPvNmt8mqQqQT10frvC 8zlLUzThjtcIf+opWGGk0h5WAgvHeoBsUKx7bgg1dcWe1KhCJhAMDrwVYCqLg9E57zpG DkDEXqn1gOVCxmXfsxNxoLdT0P0+MntelVERdowWvWOmmohttRyGaW4iLVoJ/Iv/vIHJ rMZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=YGwxJVkqpDSKGvOpQFLfY5N6LLoO+Aew6VFX7/UamXE=; b=fqJ3Wc5zrGMC7S1gM6PeJf0HlYMjVD8h6ePIbAsjruNvYQS/9V6VuSNvKtoYQbWTlU O0B6smfonudcSDnyVWuEAnzutw2yyMKmqLJw99goeQoCJ8C69VLu9JQw7u79k966dsRF I+fNrN1Po+BBSYYriboW1DMho62gRrQBE+mzpUT6aU/ikMtXW9wA8rpARL7WjrVda8nB VL6eQxnR3Ana7f/62WRSGbENQkC6F3lCTqJzPA2yrHCQy3zhi7a2IR+elTOUMbp0+qQh bWNvD5hQ6VHljwXyMW3y43czUUIDZKaMm8D0LZTyiMhoGUAKExjyXml6hT0W9BXBzRWg GO7w== X-Gm-Message-State: AOAM533LQe1PyV/rEkF2E2NTruxOtGc7EYckkechDt6ku8PD1V/8hLRE azZ9nQ/C4h/nDJMkaXU1jTI= X-Google-Smtp-Source: ABdhPJxR2C57Trbxh4UGai6jMfLWAWvgl52J2fQKlxHETsJk74rh7Tfw1Z1cix6RBU5aFMUiqW66mQ== X-Received: by 2002:a63:5445:: with SMTP id e5mr374707pgm.100.1628367562200; Sat, 07 Aug 2021 13:19:22 -0700 (PDT) Received: from [10.100.240.114] ([203.109.195.43]) by smtp.gmail.com with ESMTPSA id p23sm15136632pff.158.2021.08.07.13.19.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 07 Aug 2021 13:19:21 -0700 (PDT) To: Christian Huitema , Carsten Bormann , Ole Jacobsen Cc: rfced-future@iab.org, Adrian Farrel , Russ Housley , Ole Jacobsen , Eliot Lear References: <6ED4E99D-F8A0-44C5-9BC8-DA41044D7E09@me.com> <8F92C365-52B8-4045-98A5-7C94D2663302@tzi.org> <074b08f9-7102-d4da-451e-cd8cf5bf1796@gmail.com> <30c5c94e-4c51-e3eb-9631-4b52ff1f8f1b@huitema.net> From: Brian E Carpenter Message-ID: <074b7aac-b76c-73cf-7ede-03935a173235@gmail.com> Date: Sun, 8 Aug 2021 08:19:15 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <30c5c94e-4c51-e3eb-9631-4b52ff1f8f1b@huitema.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Aug 2021 20:19:29 -0000 On 08-Aug-21 08:14, Christian Huitema wrote: >=20 > On 8/7/2021 1:09 PM, Brian E Carpenter wrote: >> Well yes. And the outcome in this particular space is whether we can r= ecruit a suitable person for the role whose name we are discussing. The n= ame >> of the role affects that outcome. >=20 > This cuts both ways. Suppose we recruit someone with a lofty title, and=20 > then that person realizes that the actual work is not that exhilarating= =2E=20 > That too will lead to frustration and undesirable outcomes. Yes, and that's exactly why RFC Series Editor no longer works. Brian >=20 > -- Christian Huitema >=20 >=20 >> >> Of course there will always be an RFC Editor service. >> >> Regards >> Brian >> >> On 08-Aug-21 05:22, Carsten Bormann wrote: >>> +1 >>> >>> Look at outcomes, not at ideological consistency. >>> >>> Sent from=C2=A0mobile, sorry for terse >>> >>>> On 6. Aug 2021, at 23:04, Ole Jacobsen wrote: >>>> >>>> =EF=BB=BF >>>> >>>> This discussion reminds me of a bunch of recent TV ads that have the=20 following >>>> tag line: "Angie's List is now Angi" >>>> >>>> This change of name is the result of the merger of Home Advisor and = Angie's List >>>> into one company. Somehow they believe that the consumer will care a= nd >> understand >>>> this change in name. Even if there might be subtle differences in th= e services >>>> offered between the two old companies and the new one, I am going to=20 guess that >>>> nobody at the user side will know or care and thus the new name just=20 introduces >>>> confusion. >>>> >>>> There used to be a person (or actually several people, so a function= ) called the >>>> RFC Editor. In the most recent iteration it became the RFC Series Ed= itor because >>>> we're engineers and we like to over-specify and none of us understan= d the meaning >>>> of the word "approximately." The RFC Editor or the RFC Series Editor=20 was a point >>>> of contact, a function, a website, a place to get started. The fact = that we've >>>> replicated documents and built a confusing mesh of "tools.ietf.org <= http://tools.ietf.org>" and "datatracter.ietf.org " >>>> and "rfc-editor.org " where various incarnati= ons of the RFC documents and the drafts >>>> that came before them are hosted, does not make things easier for *o= utsiders*. >>>> >>>> Changing the title based on a precise description of what this role = entails >>>> isn't helpful IMO. I get job suggestions from LinkeIn all the time t= hat includes >>>> the word "Editor" but the actual job descriptions are all over the m= ap. >>>> >>>> We know (or we knew) what the RFC Editor does (approximately). Do we=20 really need >>>> to invent yet another title? >>>> >>>> Ole >>>> >>>> >>>> Ole J. Jacobsen >>>> Editor and Publisher >>>> The Internet Protocol=C2=A0Journal >>>> Office: +1 415-550-9433 >>>> Cell: =C2=A0 +1 415-370-4628 >>>> Web:=C2=A0protocoljournal.org >>>> E-mail:=C2=A0olejacobsen@me.com >>>> E-mail:=C2=A0ole@protocoljournal.org >>>> Skype: organdemo >>>> >>>> >>>> >>>> --=20 >>>> Rfced-future mailing list >>>> Rfced-future@iab.org >>>> https://www.iab.org/mailman/listinfo/rfced-future From nobody Sun Aug 8 02:54:05 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2B663A23B1; Sun, 8 Aug 2021 02:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 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, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch 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 cmHPrl8KRDwg; Sun, 8 Aug 2021 02:53:58 -0700 (PDT) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FD3C3A23AF; Sun, 8 Aug 2021 02:53:55 -0700 (PDT) Received: from Lear-Air.local ([IPv6:2a02:aa15:4101:2a80:6523:92ee:a18b:cdd]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 1789roYY250094 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Sun, 8 Aug 2021 11:53:51 +0200 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1628416431; bh=QzoSCpJrvYEre6P44G3xHlg/a2CMnq6RrVbn60oT3A8=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=I/lSu5YamzZOs9M8iI8GWOVtRvnocBIgkjzBz9RKCAoct204gCKLC4ybEZ+reHong 6JjJHVSXYc0SyQg/pYxbkSdIjLR+UBs5C9tJltYvfZ6XElf/jFj/89i4/3XxcbADtG jvzSQCV+5sJp/fLmVz4rbjv4kgRwoU0huz24qoMM= To: Ole Jacobsen Cc: rfced-future@iab.org References: <2ff1860f-c7c1-9a85-a072-166cf0c17b7c@lear.ch> <17be01d78aa2$6db78e00$4926aa00$@olddog.co.uk> <6ED4E99D-F8A0-44C5-9BC8-DA41044D7E09@me.com> From: Eliot Lear Message-ID: <7047c95b-1ce3-b8da-9acd-b55aa59c5ce4@lear.ch> Date: Sun, 8 Aug 2021 11:53:49 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <6ED4E99D-F8A0-44C5-9BC8-DA41044D7E09@me.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="a6mV10ltvBUsfeFKhoKiAmQ4WVDbJahBd" Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Aug 2021 09:54:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --a6mV10ltvBUsfeFKhoKiAmQ4WVDbJahBd Content-Type: multipart/mixed; boundary="Mz8CY6qvMSxotNeL7S6mgSd2MEiSdComw"; protected-headers="v1" From: Eliot Lear To: Ole Jacobsen Cc: rfced-future@iab.org Message-ID: <7047c95b-1ce3-b8da-9acd-b55aa59c5ce4@lear.ch> Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? References: <2ff1860f-c7c1-9a85-a072-166cf0c17b7c@lear.ch> <17be01d78aa2$6db78e00$4926aa00$@olddog.co.uk> <6ED4E99D-F8A0-44C5-9BC8-DA41044D7E09@me.com> In-Reply-To: <6ED4E99D-F8A0-44C5-9BC8-DA41044D7E09@me.com> --Mz8CY6qvMSxotNeL7S6mgSd2MEiSdComw Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Ole, On 06.08.21 23:04, Ole Jacobsen wrote: > We know (or we knew) what the RFC Editor does (approximately). Do we=20 > really need > to invent yet another title? May I ask you and others thinking similarly to consider a compromise?=A0 = I=20 don't see people on the other side of this issue ever supporting RFC=20 Editor or RSE. Eliot --Mz8CY6qvMSxotNeL7S6mgSd2MEiSdComw-- --a6mV10ltvBUsfeFKhoKiAmQ4WVDbJahBd Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmEPqa0FAwAAAAAACgkQh7ZrRtnSejOV Kwf/VfGrgVXgv6Hff5fyuUx3BXmeS5mFoRx8s6yhDm6yVVliqXtN8aj5QQkcOOXVd4EGs1wqUxyk lD75Hut67bAXmbwcuh2J+eRdXdEjjofQAEL3Y+u/VWqJTSQjkfgdDB/W+zWW0nphpi37pgZwJjga VrkDpXvc4npRsGbRsz5fCH1X9+3jGmQ8ipcDkECt2i6KipNkAyoI9l8wKwu+ddPteYzv1m8pQTd2 p2RPUKk8xLg8uWsSQM5wlPibCpaXg+nqvS/dT0Z6QWKdhH8NUT+hrYILhQcGx2rTcukbFMmEURKO nKUElmKEqXJuVpEP1fq7onP2Z5AOH0nYG80cJ9SoTw== =V3Jn -----END PGP SIGNATURE----- --a6mV10ltvBUsfeFKhoKiAmQ4WVDbJahBd-- From nobody Sun Aug 8 12:50:19 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D15DF3A09A8 for ; Sun, 8 Aug 2021 12:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, 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 x1CAEey_ZkID for ; Sun, 8 Aug 2021 12:50:15 -0700 (PDT) Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (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 65EE63A1463 for ; Sun, 8 Aug 2021 12:50:15 -0700 (PDT) Received: by mail-pl1-x62a.google.com with SMTP id l11so2503593plk.6 for ; Sun, 08 Aug 2021 12:50:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=IWF8j2M8rmgxXPAviunymaXIEYUOoUhGcenU4p4hvcY=; b=Qlio5lImnB3ft0CgIu9JelAEv4VCGdmYdtnkMwghEcnv8/pUXL+VK7yBV1XvvWhlMU h4KR6ZGfsr0AURf4sNjAxtbFDgpLTRa1oMjjO9deVXxtKBnhLT6BQfK7F07Cll4q1Ssx D7AvOjj0BZbK93ZqD/Uw++bEFPmmA/4Ij1YAic3mEYdtcq5QX91NoJToxDoPDWE7TUCu B/6p0P9ycn+vuu6bXo6UeeYEiT30w4mz1OEXsHtlPvXP875AJvMeSDxgxkfipN3Zlmpd cJDOJRJqmuuK1h5y0aeXeHT4QLRv/52wX+q/dfL69Pgq0YjUkeJ30oDyrpCiF/xZs4QM C3Cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=IWF8j2M8rmgxXPAviunymaXIEYUOoUhGcenU4p4hvcY=; b=QDDFJICO6CZYQ+z5AoYMYNcdHRI4lqhGScLixE00hxH9zYNSum/7PUlrdj7R9KEHpl 3RfMh5gdTtG0OI5NHudDKJU/5tJuWEhDBD4Eyy5SNsLH6VAkrJo+pJ+sOF+t1l8WGG6T of0Eh/3erxqDWzojK4/0e8jEUEoT/79uEf4CJw/tC9W9ToSm3BLHTYL7nX/Z40dHSTZI 3wctHve2Fz+fpLRfP3o2Th2CgTL/Fh1nJ012Q0f0emSqBBy505VJtV/OMjCAl6HX5WsR kJ3btnfiLBSlmz/ZKyL/7NZMbZ0tZzghIuqnZYEoLN9g3BdES1LkyDsY8ArYak7vJDuY loGg== X-Gm-Message-State: AOAM532ArZuaMHcY9OJCMsx3HHn3BlWTpZB6XDj3Cwp+XfcfYjPT9l7p dO9Ut/vF6YRRwTs6Vdlqay4NXXTzubJZuhv4 X-Google-Smtp-Source: ABdhPJzqzI4n+6zX2FLa8b5PYld+Yf+Lx8/56Az2FBR5dgzuIEpfzv3P0OhYUWhyin7hvPQbAImXnw== X-Received: by 2002:a17:90a:ad85:: with SMTP id s5mr20938003pjq.187.1628452213574; Sun, 08 Aug 2021 12:50:13 -0700 (PDT) Received: from [10.100.240.114] ([203.109.195.43]) by smtp.gmail.com with ESMTPSA id v1sm20552795pgj.40.2021.08.08.12.50.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 08 Aug 2021 12:50:12 -0700 (PDT) To: Eliot Lear , Ole Jacobsen Cc: rfced-future@iab.org References: <2ff1860f-c7c1-9a85-a072-166cf0c17b7c@lear.ch> <17be01d78aa2$6db78e00$4926aa00$@olddog.co.uk> <6ED4E99D-F8A0-44C5-9BC8-DA41044D7E09@me.com> <7047c95b-1ce3-b8da-9acd-b55aa59c5ce4@lear.ch> From: Brian E Carpenter Message-ID: Date: Mon, 9 Aug 2021 07:50:08 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <7047c95b-1ce3-b8da-9acd-b55aa59c5ce4@lear.ch> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Aug 2021 19:50:18 -0000 On 08-Aug-21 21:53, Eliot Lear wrote: > Ole, >=20 > On 06.08.21 23:04, Ole Jacobsen wrote: >> We know (or we knew) what the RFC Editor does (approximately). Do we=20 >> really need >> to invent yet another title? >=20 > May I ask you and others thinking similarly to consider a compromise?=C2= =A0 I=20 > don't see people on the other side of this issue ever supporting RFC=20 > Editor or RSE. Can we first agree that "RFC Editor" refers to the service as a whole, which IMHO has been the case for many years (probably from when Jon Poste= l first said "It isn't just me")? Brian From nobody Sun Aug 8 13:05:16 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 330A43A14FC for ; Sun, 8 Aug 2021 13:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=me.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 GlJ0z9bwVxS4 for ; Sun, 8 Aug 2021 13:05:10 -0700 (PDT) Received: from mr85p00im-ztdg06011201.me.com (mr85p00im-ztdg06011201.me.com [17.58.23.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 570443A14F8 for ; Sun, 8 Aug 2021 13:05:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=1a1hai; t=1628453109; bh=Rv33W6b+W2vxs1A5l3dqC/b/ARPRB22FLHMUkMB9MQM=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=GzsOHV3Gpj+2Ji6o/XlUrIh1jXnEfmbyMGHwJpymQqKX3U6IqlDDVTot3d8rhvDsk DAm69hHL4lOtiVwniLXyAqNUskh08lu9cOyv8IZiKVE7XialLttTYDSb58Z2scIzUW 001sAmW5M3U2l5Eg9jwa4WkwxCjEccGIs/ixvP/CJJntkYeuEJj1BfCzSYkuMK/bF7 skCvdcS5q36sMkuVXM7gSbAVOORilhRlrlr9IA9nG0G+IweoJmThv2iuqG5kHlkPwl 1iBSziezI5cyEof8GZd2GRhdkW+Xc7kxb/hyFYlMwOEC+ghjwSWtJ/AXY7bIXazCTR bb4txX2V7Dmjg== Received: from smtpclient.apple (157-131-155-250.fiber.dynamic.sonic.net [157.131.155.250]) by mr85p00im-ztdg06011201.me.com (Postfix) with ESMTPSA id 7394E400176; Sun, 8 Aug 2021 20:05:09 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Ole Jacobsen In-Reply-To: Date: Sun, 8 Aug 2021 13:05:08 -0700 Cc: Ole Jacobsen , Eliot Lear , rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <5269FDAA-DDA7-4592-88D4-02CAD006A737@me.com> References: <2ff1860f-c7c1-9a85-a072-166cf0c17b7c@lear.ch> <17be01d78aa2$6db78e00$4926aa00$@olddog.co.uk> <6ED4E99D-F8A0-44C5-9BC8-DA41044D7E09@me.com> <7047c95b-1ce3-b8da-9acd-b55aa59c5ce4@lear.ch> To: Brian E Carpenter X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Proofpoint-Virus-Version: =?UTF-8?Q?vendor=3Dfsecure_engine=3D1.1.170-22c6f66c430a71ce266a39bfe25bc?= =?UTF-8?Q?2903e8d5c8f:6.0.391,18.0.790,17.0.607.475.0000000_definitions?= =?UTF-8?Q?=3D2021-08-08=5F05:2021-08-05=5F02,2021-08-08=5F05,2020-04-07?= =?UTF-8?Q?=5F01_signatures=3D0?= X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 adultscore=0 bulkscore=0 mlxscore=0 malwarescore=0 mlxlogscore=999 clxscore=1015 phishscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2108080126 Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Aug 2021 20:05:15 -0000 Brian, Yes, I agree that "RFC Editor" refers as the service as a whole and that probably includes the production center in people's "fuzzy" interpretation. RFCs (literally) are no longer really "Request for Comments" that's clearly a historic name BUT it's one with great branding value even if it too suffers from the same fuzziness including misnomers such as "all RFCs are Internet Standards" and so on. So, I propose that we keep RFC in the title. Alternatively, and this is certainly *possible* we could call the role something more reflective of reality such as "IETF Document Editor and Publisher" or something like that. I would still prefer a title that recognizes a bit of the history (even if fuzzy), but I am certainly happy to compromise. I do agree that this all boils down to what the applicants will read in the job description and whether or not they understand any of our history. Ole > On Aug 8, 2021, at 12:50, Brian E Carpenter = wrote: >=20 > On 08-Aug-21 21:53, Eliot Lear wrote: >> Ole, >>=20 >> On 06.08.21 23:04, Ole Jacobsen wrote: >>> We know (or we knew) what the RFC Editor does (approximately). Do we=20= >>> really need >>> to invent yet another title? >>=20 >> May I ask you and others thinking similarly to consider a compromise? = I=20 >> don't see people on the other side of this issue ever supporting RFC=20= >> Editor or RSE. >=20 > Can we first agree that "RFC Editor" refers to the service as a whole, > which IMHO has been the case for many years (probably from when Jon = Postel > first said "It isn't just me")? >=20 > Brian >=20 Ole J. Jacobsen Editor and Publisher The Internet Protocol Journal Office: +1 415-550-9433 Cell: +1 415-370-4628 Web: protocoljournal.org E-mail: olejacobsen@me.com E-mail: ole@protocoljournal.org Skype: organdemo From nobody Mon Aug 9 00:42:29 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F1353A03EF for ; Mon, 9 Aug 2021 00:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch 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 3j9XcQxrRBio for ; Mon, 9 Aug 2021 00:42:20 -0700 (PDT) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8903E3A03EE for ; Mon, 9 Aug 2021 00:42:18 -0700 (PDT) Received: from [IPv6:2a02:aa15:4101:2a80:81cf:53b9:533f:602a] ([IPv6:2a02:aa15:4101:2a80:81cf:53b9:533f:602a]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 1797gEUJ268869 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Mon, 9 Aug 2021 09:42:14 +0200 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1628494934; bh=SxJFczSn/RIATfOdoqZfsqVviZx7G+4OZJxrcgPRspA=; h=Subject:From:To:Cc:References:Date:In-Reply-To:From; b=Lq//+Ibte5o+xGAzLj9pmFEw8/VGLOXRkOVSNlaIGmY9UhX9VUoABqkPiDgWlU6Sz OXR/zLMF+YB672q38fbcs4S32avLsEw7IQ47fn7eBk5Q+5j2+qRIzYM3ciR3Xe+S2D r9na3iOlQqE69Ucf99QPTaaKaLyzfHaoUqCq3sOw= From: Eliot Lear To: "rfced-future@iab.org" Cc: Brian Rosen References: Message-ID: <79fb0d4b-cc8d-a614-7a61-493b917aa5dc@lear.ch> Date: Mon, 9 Aug 2021 09:42:11 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0vylHLCC7LuKPytGr0srfNcz9B3xvi2dz" Archived-At: Subject: [Rfced-future] Reminder Re: Please doodle for the next meeting: deadline 11 Aug 2021 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2021 07:42:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0vylHLCC7LuKPytGr0srfNcz9B3xvi2dz Content-Type: multipart/mixed; boundary="g8jqYxy5x7murTCnXZYWGpBLBn5Aofkn5"; protected-headers="v1" From: Eliot Lear To: "rfced-future@iab.org" Cc: Brian Rosen Message-ID: <79fb0d4b-cc8d-a614-7a61-493b917aa5dc@lear.ch> Subject: Reminder Re: Please doodle for the next meeting: deadline 11 Aug 2021 References: In-Reply-To: --g8jqYxy5x7murTCnXZYWGpBLBn5Aofkn5 Content-Type: multipart/alternative; boundary="------------5D9623B72FEAABCF8DB3E223" Content-Language: en-US This is a multi-part message in MIME format. --------------5D9623B72FEAABCF8DB3E223 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Thanks to those who have already doodled.=C2=A0 A reminder to those who=20 haven't, the Doodle poll is opened until Wednesday. Eliot On 06.08.21 10:01, Eliot Lear wrote: > Hi everyone, > > Could you please doodle for the next meeting by this coming Wednesday, = > 11 August? > > Here's a little bonus: if we can resolve our remaining issues, it is=20 > at least conceivable that this could be the last one of these we have=20 > to do. > > Doodle URL: > > https://doodle.com/poll/vmg2i48pvur29ghr?utm_source=3Dpoll&utm_medium=3D= link > > Thanks, > > Eliot > > > --------------5D9623B72FEAABCF8DB3E223 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Thanks to those who have already doodled.=C2=A0 A reminder to thos= e who haven't, the Doodle poll is opened until Wednesday.

Eliot

On 06.08.21 10:01, Eliot Lear wrote:
Hi everyone,

Could you please doodle for the next meeting by this coming Wednesday, 11 August?

Here's a little bonus: if we can resolve our remaining issues, it is at least conceivable that this could be the last one of these we have to do.

Doodle URL:

https://doodle.com/po= ll/vmg2i48pvur29ghr?utm_source=3Dpoll&utm_medium=3Dlink

Thanks,

Eliot



--------------5D9623B72FEAABCF8DB3E223-- --g8jqYxy5x7murTCnXZYWGpBLBn5Aofkn5-- --0vylHLCC7LuKPytGr0srfNcz9B3xvi2dz Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmEQ3FQFAwAAAAAACgkQh7ZrRtnSejMU HggA2YhaCONDqs472m1UsHD0X3gf1RtSMQEjlz6l5N/GxphhLR8guGIoqONXTltrp/1Pa5zS0k75 ImxsBBXiA9BNvHDYMNV4H8Vm0BCSN0YrJqUkFGYho2PG3eFnlmoRRVnxehAxmSWZIhNb/z39/clS QS5j4U3S1vE11tdYbrOXKwD9mOonbNZEpx8PjdvzqCIlwXjnM8seoTf13BGxUXuNS8opZ6xvztIz gt3jjIe5qUUWaDY4gqh+wR04dxynQeNfQY0M1d+fQcoCZIuGmaq3wwfqD+PnvK1d6U/nXm8hdhDh KU6V4kqNLBxr7d+WuVCNrQWsj4dae9tUn1QtlLR+5Q== =pGn/ -----END PGP SIGNATURE----- --0vylHLCC7LuKPytGr0srfNcz9B3xvi2dz-- From nobody Mon Aug 9 12:07:34 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C00A73A1261; Mon, 9 Aug 2021 12:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 GYk352mRhC0w; Mon, 9 Aug 2021 12:07:25 -0700 (PDT) Received: from smtpclient.apple (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id CAA3C3A1260; Mon, 9 Aug 2021 12:07:24 -0700 (PDT) From: Jay Daley Message-Id: <1CAEA70D-10C9-4D45-A958-2056716E8D99@ietf.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_18C665DE-CA5F-4386-897F-A90DE79DD3FA" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Tue, 10 Aug 2021 07:07:17 +1200 In-Reply-To: <5269FDAA-DDA7-4592-88D4-02CAD006A737@me.com> Cc: Brian E Carpenter , rfced-future@iab.org, Ole Jacobsen , Eliot Lear To: Ole Jacobsen References: <2ff1860f-c7c1-9a85-a072-166cf0c17b7c@lear.ch> <17be01d78aa2$6db78e00$4926aa00$@olddog.co.uk> <6ED4E99D-F8A0-44C5-9BC8-DA41044D7E09@me.com> <7047c95b-1ce3-b8da-9acd-b55aa59c5ce4@lear.ch> <5269FDAA-DDA7-4592-88D4-02CAD006A737@me.com> X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2021 19:07:33 -0000 --Apple-Mail=_18C665DE-CA5F-4386-897F-A90DE79DD3FA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 9/08/2021, at 8:05 AM, Ole Jacobsen = wrote: >=20 > Brian, >=20 > Yes, I agree that "RFC Editor" refers as the service as a whole and > that probably includes the production center in people's "fuzzy" > interpretation. >=20 > RFCs (literally) are no longer really "Request for Comments" that's > clearly a historic name BUT it's one with great branding value even > if it too suffers from the same fuzziness including misnomers such > as "all RFCs are Internet Standards" and so on. So, I propose that > we keep RFC in the title. >=20 > Alternatively, and this is certainly *possible* we could call the > role something more reflective of reality such as "IETF Document > Editor and Publisher" or something like that. The new role as defined is neither an editor nor a publisher, it=E2=80=99s= an expert advisor on editing and publishing. Jay >=20 > I would still prefer a title that recognizes a bit of the history > (even if fuzzy), but I am certainly happy to compromise. I do agree > that this all boils down to what the applicants will read in the > job description and whether or not they understand any of our > history. >=20 > Ole >=20 >> On Aug 8, 2021, at 12:50, Brian E Carpenter = wrote: >>=20 >> On 08-Aug-21 21:53, Eliot Lear wrote: >>> Ole, >>>=20 >>> On 06.08.21 23:04, Ole Jacobsen wrote: >>>> We know (or we knew) what the RFC Editor does (approximately). Do = we=20 >>>> really need >>>> to invent yet another title? >>>=20 >>> May I ask you and others thinking similarly to consider a = compromise? I=20 >>> don't see people on the other side of this issue ever supporting RFC=20= >>> Editor or RSE. >>=20 >> Can we first agree that "RFC Editor" refers to the service as a = whole, >> which IMHO has been the case for many years (probably from when Jon = Postel >> first said "It isn't just me")? >>=20 >> Brian >>=20 >=20 > Ole J. Jacobsen > Editor and Publisher > The Internet Protocol Journal > Office: +1 415-550-9433 > Cell: +1 415-370-4628 > Web: protocoljournal.org > E-mail: olejacobsen@me.com > E-mail: ole@protocoljournal.org > Skype: organdemo >=20 >=20 >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future = --=20 Jay Daley IETF Executive Director jay@ietf.org --Apple-Mail=_18C665DE-CA5F-4386-897F-A90DE79DD3FA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 9/08/2021, at 8:05 AM, Ole Jacobsen <olejacobsen=3D40me.com@dmarc.ietf.org> wrote:

Brian,

Yes, I agree that "RFC Editor" refers as the service as a = whole and
that probably = includes the production center in people's "fuzzy"
interpretation.

RFCs (literally) are no longer = really "Request for Comments" that's
clearly a historic name BUT it's one with great branding = value even
if it too = suffers from the same fuzziness including misnomers such
as "all RFCs are Internet = Standards" and so on. So, I propose that
we keep RFC in the title.

Alternatively, and this is certainly *possible* we could call = the
role = something more reflective of reality such as "IETF Document
Editor and Publisher" or = something like that.

The new role as defined is neither an editor nor a = publisher, it=E2=80=99s an expert advisor on editing and = publishing.

Jay


I would still prefer a title = that recognizes a bit of the history
(even if fuzzy), but I am certainly happy to compromise. I do = agree
that this all = boils down to what the applicants will read in the
job description and whether or = not they understand any of our
history.

Ole

On Aug 8, 2021, at 12:50, Brian E = Carpenter <brian.e.carpenter@gmail.com> wrote:

On 08-Aug-21 21:53, Eliot Lear wrote:
Ole,

On 06.08.21 = 23:04, Ole Jacobsen wrote:
We know (or we knew) what the RFC Editor does = (approximately). Do we 
really = need
to invent yet another title?

May I ask you and others thinking = similarly to consider a compromise?  I 
don't see = people on the other side of this issue ever supporting RFC 
Editor or = RSE.

Can we first agree that = "RFC Editor" refers to the service as a whole,
which IMHO = has been the case for many years (probably from when Jon Postel
first said "It isn't just me")?

  Brian

Ole J. Jacobsen
Editor and Publisher
The Internet Protocol = Journal
Office: +1 = 415-550-9433
Cell: =   +1 415-370-4628
Web: protocoljournal.org
E-mail: olejacobsen@me.com
E-mail: ole@protocoljournal.orgSkype: organdemo



-- 
Rfced-future mailing = list
Rfced-future@iab.org
https://www.iab.org/mailman/listinfo/rfced-future

-- 
Jay Daley
IETF = Executive Director
jay@ietf.org

= --Apple-Mail=_18C665DE-CA5F-4386-897F-A90DE79DD3FA-- From nobody Mon Aug 9 12:17:13 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2A33A12F9 for ; Mon, 9 Aug 2021 12:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 uEghuU2ZAAjD for ; Mon, 9 Aug 2021 12:17:04 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8F903A12F8 for ; Mon, 9 Aug 2021 12:17:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4Gk5S03kbHz6G9vF for ; Mon, 9 Aug 2021 12:17:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1628536624; bh=IuULOpZyJHOI0EGiaYPo+JTss9lynVAnYjGv4tr0Xdc=; h=Subject:To:References:From:Date:In-Reply-To:From; b=nuW2nL6MXsLMOlxgoAOjEgrtBOhQCXkAHYHAEukTvQ9HxjGOHkoglduUrdDRsmp/B 46FR5l3yG1+S+f2YLjYMBKtVACngBvTBTMOeZTESVztNKuRugShtTKDM1KpKO7cxSV I3EK29uJWmnr+sJDkYCpIzNR1P60Er+1kSghyQik= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.23.64] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (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 maila2.tigertech.net (Postfix) with ESMTPSA id 4Gk5S00HSzz6GR9S for ; Mon, 9 Aug 2021 12:17:03 -0700 (PDT) To: "rfced-future@iab.org" References: <2ff1860f-c7c1-9a85-a072-166cf0c17b7c@lear.ch> <17be01d78aa2$6db78e00$4926aa00$@olddog.co.uk> <6ED4E99D-F8A0-44C5-9BC8-DA41044D7E09@me.com> <7047c95b-1ce3-b8da-9acd-b55aa59c5ce4@lear.ch> <5269FDAA-DDA7-4592-88D4-02CAD006A737@me.com> <1CAEA70D-10C9-4D45-A958-2056716E8D99@ietf.org> From: "Joel M. Halpern" Message-ID: Date: Mon, 9 Aug 2021 15:17:02 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <1CAEA70D-10C9-4D45-A958-2056716E8D99@ietf.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2021 19:17:11 -0000 Trimmed, I hope that doing so has not mangled anyone's point. Agreeing with Jay's point below, which is why I can live with RFC Series Consulting Editor (RSCE). On 8/9/2021 3:07 PM, Jay Daley wrote: > > The new role as defined is neither an editor nor a publisher, it’s an > expert advisor on editing and publishing. > > Jay From nobody Mon Aug 9 12:19:50 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF3113A1314 for ; Mon, 9 Aug 2021 12:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=me.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 bwbnwZ2b8Ej2 for ; Mon, 9 Aug 2021 12:19:42 -0700 (PDT) Received: from mr85p00im-hyfv06011301.me.com (mr85p00im-hyfv06011301.me.com [17.58.23.184]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C68913A11EA for ; Mon, 9 Aug 2021 12:19:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=1a1hai; t=1628536782; bh=28+h0sB2G0Ptx/sxHGRvcWR6/w7uZK95zkKRlsKHwZk=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=jLwwAAt/SBeqo/0rDI7FZzCFuuKlBLvQ4R5QaTiNUorb649llJ5k5Ye9R6SNkIyO8 iH96vxufYj70ABMMemwkiJPV5814FjdewOYc2zmb0yC3mrzMKR/0mtrlfVXfr8wfUF 72Las+D7ob7bUgd1kKx35OxCvZVfNBmjVWviRDGTHIfYm885XtPvUAbrfpJojterW3 Efe6s3jE4kD+089kKUU8xNg2gf+llq9Zq4T2ysBdUVR/E5XcqPmsGpOqEluyta8/4S tuCV4ljRl4ZBE5fZumeA+cFMZs/tE/qBXB6Pi6pEIQzY4YRAccpiBStWljaRTPH7k7 QKsqYlshwHNgw== Received: from smtpclient.apple (157-131-155-250.fiber.dynamic.sonic.net [157.131.155.250]) by mr85p00im-hyfv06011301.me.com (Postfix) with ESMTPSA id 3A4FA580867; Mon, 9 Aug 2021 19:19:42 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Ole Jacobsen In-Reply-To: Date: Mon, 9 Aug 2021 12:19:41 -0700 Cc: Ole Jacobsen , "rfced-future@iab.org" Content-Transfer-Encoding: quoted-printable Message-Id: <82804DFF-E64D-4461-AE25-E5A9524FE8D7@me.com> References: <2ff1860f-c7c1-9a85-a072-166cf0c17b7c@lear.ch> <17be01d78aa2$6db78e00$4926aa00$@olddog.co.uk> <6ED4E99D-F8A0-44C5-9BC8-DA41044D7E09@me.com> <7047c95b-1ce3-b8da-9acd-b55aa59c5ce4@lear.ch> <5269FDAA-DDA7-4592-88D4-02CAD006A737@me.com> <1CAEA70D-10C9-4D45-A958-2056716E8D99@ietf.org> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Proofpoint-Virus-Version: =?UTF-8?Q?vendor=3Dfsecure_engine=3D1.1.170-22c6f66c430a71ce266a39bfe25bc?= =?UTF-8?Q?2903e8d5c8f:6.0.391,18.0.790,17.0.607.475.0000000_definitions?= =?UTF-8?Q?=3D2021-08-09=5F06:2021-08-06=5F01,2021-08-09=5F06,2020-04-07?= =?UTF-8?Q?=5F01_signatures=3D0?= X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 malwarescore=0 adultscore=0 suspectscore=0 mlxlogscore=999 bulkscore=0 clxscore=1015 spamscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2108090136 Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2021 19:19:49 -0000 RFC Series Consulting Editor (RSCE) works for me. Ole > On Aug 9, 2021, at 12:17, Joel M. Halpern wrote: >=20 > Trimmed, I hope that doing so has not mangled anyone's point. >=20 > Agreeing with Jay's point below, which is why I can live with RFC = Series Consulting Editor (RSCE). >=20 > On 8/9/2021 3:07 PM, Jay Daley wrote: >=20 >> The new role as defined is neither an editor nor a publisher, it=E2=80=99= s an expert advisor on editing and publishing. >> Jay >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future Ole J. Jacobsen Editor and Publisher The Internet Protocol Journal Office: +1 415-550-9433 Cell: +1 415-370-4628 Web: protocoljournal.org E-mail: olejacobsen@me.com E-mail: ole@protocoljournal.org Skype: organdemo From nobody Mon Aug 9 13:01:50 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6264B3A1539 for ; Mon, 9 Aug 2021 13:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no 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 mdHOSiygdIX3 for ; Mon, 9 Aug 2021 13:01:43 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 751F43A1537 for ; Mon, 9 Aug 2021 13:01:38 -0700 (PDT) Received: from smtpclient.apple (52-165-103-86.dynamic.dsl.tng.de [86.103.165.52]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4Gk6RK1cFNz2xKN; Mon, 9 Aug 2021 22:01:33 +0200 (CEST) Content-Type: multipart/alternative; boundary=Apple-Mail-E100251A-0EE1-4D1A-BAB6-893699F842C3 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) From: Carsten Bormann In-Reply-To: <82804DFF-E64D-4461-AE25-E5A9524FE8D7@me.com> Date: Mon, 9 Aug 2021 22:01:31 +0200 Cc: "Joel M. Halpern" , rfced-future@iab.org, Ole Jacobsen Message-Id: <75731887-5EAA-47E4-B7A9-AA1F82C98388@tzi.org> References: <82804DFF-E64D-4461-AE25-E5A9524FE8D7@me.com> To: Ole Jacobsen X-Mailer: iPhone Mail (18G82) Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2021 20:01:49 -0000 --Apple-Mail-E100251A-0EE1-4D1A-BAB6-893699F842C3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable +1 Sent from mobile, sorry for terse > On 9. Aug 2021, at 21:25, Ole Jacobsen wrote: >=20 > RFC Series Consulting Editor (RSCE) works for me. --Apple-Mail-E100251A-0EE1-4D1A-BAB6-893699F842C3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit +1

Sent from mobile, sorry for terse

On 9. Aug 2021, at 21:25, Ole Jacobsen <olejacobsen=40me.com@dmarc.ietf.org> wrote:

RFC Series Consulting Editor (RSCE) works for me.
--Apple-Mail-E100251A-0EE1-4D1A-BAB6-893699F842C3-- From nobody Mon Aug 9 19:57:32 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 660CA3A237E for ; Mon, 9 Aug 2021 19:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.098 X-Spam-Level: X-Spam-Status: No, score=-1.098 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, FREEMAIL_REPLY=1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 jueoUZn5vSqK for ; Mon, 9 Aug 2021 19:57:24 -0700 (PDT) Received: from mail-vk1-xa2f.google.com (mail-vk1-xa2f.google.com [IPv6:2607:f8b0:4864:20::a2f]) (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 947653A237F for ; Mon, 9 Aug 2021 19:57:24 -0700 (PDT) Received: by mail-vk1-xa2f.google.com with SMTP id u138so609687vku.7 for ; Mon, 09 Aug 2021 19:57:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=FiSDLzaRLzh3C3HHKVfWdRW67cxKeRPN0FKFqZ8GSWw=; b=CN8pMGapjEtug3Dn7lFH5qZJNje86i+MwdjUoqQs0ILYiSDoUO/vbJaUszc8UBBpt7 YdZdeIPydPxs1ghslg9RDnAI9kxzjVqp+PEj6bo7JQmPN1AqeVhavOc9xJmdQFjWzjVI weFoPc819fDW40fgV1m2yrgmdxyNHQgo9pUqv+kzUiNzqLZGBjlMF5M6JV1fF6yboBMu ZbCHm3GFeF/BPlZQJlXb16Ni87mpaNYS0vem6TR/sN9QuYYw40T+pN/ozpCDaaFFnDWd 3hqnApE71KmWb/a/AMtb5j903y2yenS+9ZuPv6zms3r29FRy4huuqdbONnrTvCf72uKB H3DQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=FiSDLzaRLzh3C3HHKVfWdRW67cxKeRPN0FKFqZ8GSWw=; b=NnLuar2iQetK18FoTWZgg0fzC09aKmrezPbqhkRfgvmcdCEPGkzHAvCiTMPs3noVGH OenVEL0xn0tC99xESuMdTmAQEyBAbEmLcd8iqpOBmskArxoTNL+RKdHi9j9655rKJtXg fisSwLncFrdok9Kv9V+RNgXQ9kOEaxF0c51CdrK4isJgSCxC7FBcxvjwXFNCacXxEFLH 6GXZoVGx3tVEkfex1YwoTQS6jvaS2o+7AH/tbfqff8xBgad5UFgHCyisnmROvPZBTTje qTqE5s32Ags5xunLV3raTf/qQXGKdXFyOPb8+CXOzT+PrCwCQzS3tYUTzKOuShJqOQ5E WQyA== X-Gm-Message-State: AOAM531b+PMEndhcUuUrqOX5idIpYxo+tGH2Yw6kvSFHjusmaukrkJkc q+ZXHKUZDAzU7+OubuYu6xVO5+nn2LSFtnLBno0= X-Google-Smtp-Source: ABdhPJynbKYmBULUJsoB/JPE1KuV3FqwLTABb1+Cq+6bK3HIXi0akMBdwGQNmL3/ScTaD11OVNcf7rsXrIpRC5s/SCo= X-Received: by 2002:a05:6122:180d:: with SMTP id ay13mr10075825vkb.8.1628564242382; Mon, 09 Aug 2021 19:57:22 -0700 (PDT) MIME-Version: 1.0 References: <2ff1860f-c7c1-9a85-a072-166cf0c17b7c@lear.ch> <17be01d78aa2$6db78e00$4926aa00$@olddog.co.uk> <6ED4E99D-F8A0-44C5-9BC8-DA41044D7E09@me.com> <7047c95b-1ce3-b8da-9acd-b55aa59c5ce4@lear.ch> <5269FDAA-DDA7-4592-88D4-02CAD006A737@me.com> <1CAEA70D-10C9-4D45-A958-2056716E8D99@ietf.org> In-Reply-To: <1CAEA70D-10C9-4D45-A958-2056716E8D99@ietf.org> From: Nevil Brownlee Date: Tue, 10 Aug 2021 14:56:55 +1200 Message-ID: To: Jay Daley Cc: Ole Jacobsen , rfced-future@iab.org, Ole Jacobsen , Eliot Lear Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] RSE, RSEA, RSCE, or Ruler Of The Universe? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2021 02:57:31 -0000 I reckon RSCE is a good title (as Ole said). Cheers, Nevil On Tue, Aug 10, 2021 at 7:07 AM Jay Daley wrote: > > > > On 9/08/2021, at 8:05 AM, Ole Jacobsen wrote: > > Brian, > > Yes, I agree that "RFC Editor" refers as the service as a whole and > that probably includes the production center in people's "fuzzy" > interpretation. > > RFCs (literally) are no longer really "Request for Comments" that's > clearly a historic name BUT it's one with great branding value even > if it too suffers from the same fuzziness including misnomers such > as "all RFCs are Internet Standards" and so on. So, I propose that > we keep RFC in the title. > > Alternatively, and this is certainly *possible* we could call the > role something more reflective of reality such as "IETF Document > Editor and Publisher" or something like that. > > > The new role as defined is neither an editor nor a publisher, it=E2=80=99= s an expert advisor on editing and publishing. > > Jay > > > I would still prefer a title that recognizes a bit of the history > (even if fuzzy), but I am certainly happy to compromise. I do agree > that this all boils down to what the applicants will read in the > job description and whether or not they understand any of our > history. > > Ole > > On Aug 8, 2021, at 12:50, Brian E Carpenter = wrote: > > On 08-Aug-21 21:53, Eliot Lear wrote: > > Ole, > > On 06.08.21 23:04, Ole Jacobsen wrote: > > We know (or we knew) what the RFC Editor does (approximately). Do we > really need > to invent yet another title? > > > May I ask you and others thinking similarly to consider a compromise? I > don't see people on the other side of this issue ever supporting RFC > Editor or RSE. > > > Can we first agree that "RFC Editor" refers to the service as a whole, > which IMHO has been the case for many years (probably from when Jon Poste= l > first said "It isn't just me")? > > Brian > > > Ole J. Jacobsen > Editor and Publisher > The Internet Protocol Journal > Office: +1 415-550-9433 > Cell: +1 415-370-4628 > Web: protocoljournal.org > E-mail: olejacobsen@me.com > E-mail: ole@protocoljournal.org > Skype: organdemo > > > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > > > -- > Jay Daley > IETF Executive Director > jay@ietf.org > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future --=20 ----------------------------------- Nevil Brownlee, Taupo, NZ From nobody Thu Aug 12 14:08:53 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 855D93A49D1 for ; Thu, 12 Aug 2021 14:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch 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 RNFoMPsZhJWO for ; Thu, 12 Aug 2021 14:08:45 -0700 (PDT) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 587B83A49D9 for ; Thu, 12 Aug 2021 14:08:27 -0700 (PDT) Received: from [IPv6:2001:420:c0c0:1011::1] ([IPv6:2001:420:c0c0:1011:0:0:0:1]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 17CL8OGF339614 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Thu, 12 Aug 2021 23:08:25 +0200 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1628802505; bh=t3K2+2tS/F32zfEoaUXSdSZKF/ejIn8OWmDWhElYWaI=; h=To:From:Subject:Date:From; b=F8ZD27E1pgstTdzZsXO1d2mdn2lah74yQ3oDaazKnauN9N5PKT8bVQ0NDn1NtD7Xl z0m1Gv4tbPkb0wLSpWvZt7/b2J0B5k/+WQ0nXx9nFY2CF1+iK7x00BGbd+ly7kFihf Fnm4B/FEXXBl8dCgxnNjKCIlA+oJcP4OY84Uc2IE= To: "rfced-future@iab.org" From: Eliot Lear Message-ID: <1876a06a-4a53-1c25-def5-d66d80dfb7e5@lear.ch> Date: Thu, 12 Aug 2021 23:08:24 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jTU1te36UZuL2G8vE3s11uOTSA8OBnKnT" Archived-At: Subject: [Rfced-future] New issue 79: Style guide handling X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2021 21:08:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jTU1te36UZuL2G8vE3s11uOTSA8OBnKnT Content-Type: multipart/mixed; boundary="82pla119BwQLl8QuzlRKRQzL0yNPzXJ5i"; protected-headers="v1" From: Eliot Lear To: "rfced-future@iab.org" Message-ID: <1876a06a-4a53-1c25-def5-d66d80dfb7e5@lear.ch> Subject: New issue 79: Style guide handling --82pla119BwQLl8QuzlRKRQzL0yNPzXJ5i Content-Type: multipart/alternative; boundary="------------6F388EA9A269E314321E5BAE" Content-Language: en-US This is a multi-part message in MIME format. --------------6F388EA9A269E314321E5BAE Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Several people have mentioned the style guide, and so I went back and=20 looked at both it and the text we have in the draft. Right now the text in Section 6.1 states: This document creates the Editorial Stream. Any and all future documents produced by the RSWG and approved by the= RSAB shall be published in the Editorial Stream. The style guide consists of RFCs and other documents[1]. The text in the = draft doesn't quite cover that. The RFCs in question are RFC 7322,=20 RFC7997, and RFC 7841 (boiler plate). They are currently in the IAB=20 stream. We should probably explicitly decide to redirect some or all of=20 these to the Editorial Stream. With regard to the things that are *not*=20 RFCs (abbreviations list, terms, and a few other things), the model we=20 have seems to indicate that these documents would go to the RPC unless=20 and until the RSWG and RSAB say otherwise in a new policy RFC. Is my understanding correct or is there some proposal that someone else=20 wants to make to address this?=C2=A0 If people want we can go document by= =20 document in our f2f, but it's important to have a good handle on the mode= l. Eliot [1] https://www.rfc-editor.org/styleguide/ --------------6F388EA9A269E314321E5BAE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Several people have mentioned the style guide, and so I went back and looked at both it and the text we have in the draft.

Right now the text in Section 6.1 states:

This document creates the Editorial Stream.

Any and all future documents produced by the RSWG and approved by the
RSAB shall be published in the Editorial Stream.

The style guide consists of RFCs and other documents[1]. The text in the draft doesn't quite cover that. The RFCs in question are RFC 7322, RFC7997, and RFC 7841 (boiler plate). They are currently in the IAB stream. We should probably explicitly decide to redirect some or all of these to the Editorial Stream. With regard to the things that are not RFCs (abbreviations list, terms, and a few other things), the model we have seems to indicate that these documents would go to the RPC unless and until the RSWG and RSAB say otherwise in a new policy RFC.

Is my understanding correct or is there some proposal that someone else wants to make to address this?=C2=A0 If people want we= can go document by document in our f2f, but it's important to have a good handle on the model.

Eliot

[1] https://www.rfc-editor.org/styleguide/

--------------6F388EA9A269E314321E5BAE-- --82pla119BwQLl8QuzlRKRQzL0yNPzXJ5i-- --jTU1te36UZuL2G8vE3s11uOTSA8OBnKnT Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmEVjcgFAwAAAAAACgkQh7ZrRtnSejOl pQgAyuJJXRnA1YYKEgQ5gwBZJb0HL67Le4N659naXU5fjH2o8kPJQMpRdJ/FSMAawUIucS8NvFEu XSvOQ6FXzFP57nAh+4z8tV84k0pKAehukO9I+sUZrfu5Go5ODFddhmjahIYhDaUxHtk5qAbZ+YH4 iyPQKMEZuKAtIpR6S6G5Q8+9PjXZ7i91bbQz5t6ABx95IE9qdaqJtU0vHFUGfX5p9BkAkv1DXM72 ror30BCfB2wAjQMTgqjCsT59ISxxuezSTeGXhPkz5BfhifxuVUO4i3vdATd0MLVJAEyiG0qvT5cT QEYJUu0XmxxO2ojzNRLXuEciPm+A/+T52dOivmwjQg== =1PO6 -----END PGP SIGNATURE----- --jTU1te36UZuL2G8vE3s11uOTSA8OBnKnT-- From nobody Thu Aug 12 14:20:19 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA0B93A1521 for ; Thu, 12 Aug 2021 14:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 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, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch 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 wslBQS9EckNq for ; Thu, 12 Aug 2021 14:20:11 -0700 (PDT) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 172A23A1577 for ; Thu, 12 Aug 2021 14:20:10 -0700 (PDT) Received: from [IPv6:2001:420:c0c0:1011::1] ([IPv6:2001:420:c0c0:1011:0:0:0:1]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 17CLK7DN339804 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Thu, 12 Aug 2021 23:20:07 +0200 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1628803207; bh=TBatvshashmOGJC3gnRRyrLNfKUsePPe+7yt2h3ab6g=; h=To:From:Subject:Date:From; b=AoKdgxaoIgqG06cCgLkUq2h1b7TgTAs2RS/mMupixrF3XRn7U3zg4Vlg0UwK4HYQm zspK8+UNa0v2JczqMp6u/vQ/b/4X2FImoWGo25WhC5KnRimCAw0mMJdK68ch5IcOHs Y1WtdSaI5xuM1RGNStVOJzjI41EWHg65zWz5bKXA= To: "rfced-future@iab.org" From: Eliot Lear Message-ID: Date: Thu, 12 Aug 2021 23:20:06 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jsLLu9G7TWRauifFiKQC5I5QTROZ3cW0d" Archived-At: Subject: [Rfced-future] Interim meeting: 2021-08-26 20:00 UTC X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2021 21:20:17 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jsLLu9G7TWRauifFiKQC5I5QTROZ3cW0d Content-Type: multipart/mixed; boundary="mKhdwxf5hdhZYnCLuePJNbIeVdYcaW0kM"; protected-headers="v1" From: Eliot Lear To: "rfced-future@iab.org" Message-ID: Subject: Interim meeting: 2021-08-26 20:00 UTC --mKhdwxf5hdhZYnCLuePJNbIeVdYcaW0kM Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi everyone, Based on Doodle and wanting to give people 2 weeks' notice the meeting=20 will occur on the 26th of August at 20:00 UTC.=C2=A0 The agenda will be t= he=20 same.=C2=A0 Plod through our issue list.=C2=A0 The good news is that it i= s shrinking. Eliot --mKhdwxf5hdhZYnCLuePJNbIeVdYcaW0kM-- --jsLLu9G7TWRauifFiKQC5I5QTROZ3cW0d Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmEVkIYFAwAAAAAACgkQh7ZrRtnSejOK LAgAhykgtjFNmZ//QSt2K/FGM58FpZVcuIPDsy+DbHXVLVC5W0lcn4zM6COLy855cf/+41ys94Nh BqCsOW9XjHciMyEbG6/klTw5rc4EiXRy3Fp1iI2X4DfPnc2V2PNub2rVCiOYoni0JXt1XIyOagV0 Aq4fNKxgZd57UvW6s3qtyfB8wUU+zXLOR2WpDn+7jsfy/zlHsAw3MHarzT9dHFFFVOVmhkMwn32j yVp5Y4CxzuFAfaPgulrBj0/IHQ5vgSeArrrhELcp2NoomKL+oaM98Mm+vN5V5scGDfxMhodujt7L iAKvFLF1Ef4OvBvP4ZvonYQLCo4GBfHZJSx7BPJjPA== =BJIF -----END PGP SIGNATURE----- --jsLLu9G7TWRauifFiKQC5I5QTROZ3cW0d-- From nobody Thu Aug 12 15:25:17 2021 Return-Path: X-Original-To: rfced-future@iab.org Delivered-To: rfced-future@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 26BA83A08CF; Thu, 12 Aug 2021 15:25:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IAB Executive Administrative Manager To: "IETF-Announce" Cc: rfced-future@iab.org X-Test-IDTracker: no X-IETF-IDTracker: 7.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162880710503.14167.771695667928293483@ietfa.amsl.com> Date: Thu, 12 Aug 2021 15:25:05 -0700 Archived-At: Subject: [Rfced-future] RFC Editor Future Development (rfcefdp) PROGRAM Virtual Meeting: 2021-08-26 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2021 22:25:05 -0000 The RFC Editor Future Development (rfcefdp) Program will hold a virtual interim meeting on 2021-08-26 from 20:00 to 22:00 UTC. Agenda: We will continue going through our issues list. Information about remote participation: https://cisco.webex.com/cisco/j.php?MTID=mcf0743ad8682dede5c72bb005abe9dc1 From nobody Thu Aug 12 16:43:32 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6D613A0CED for ; Thu, 12 Aug 2021 16:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 t4ZWePYA0IT7 for ; Thu, 12 Aug 2021 16:43:26 -0700 (PDT) Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) (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 188743A0CE8 for ; Thu, 12 Aug 2021 16:43:26 -0700 (PDT) Received: by mail-pj1-x102c.google.com with SMTP id s22-20020a17090a1c16b0290177caeba067so18009181pjs.0 for ; Thu, 12 Aug 2021 16:43:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=gOi+sAzsLGksvKUl56VjHq0o12OphfW72370D80KM+I=; b=CRywbX/1CpLwl/Mq/vzjNlPrQTXq/Y5XJy4q8zvlSmDyAd9lW+bTuvs9lna5z3wh8V Rz2CBTJIH9XusIK8vAnP5I28lmI3HaPrZ4jcb/bNljcc4rJG9FJZhEGE2qfTDdFg8FO3 GcKo0Km1wkUC6wYXEfymF7zWz9p8bKJ6AdPls7B9xi98Dtl0/OLcy8xjfLIeaBuSQm/W elNjV9TN3kP28cK1Uw0338ZpPZRQ7jmrXktNIYoff8Vkncw22KWNE7h5uuR/wxtGA1on yvZkOdRtaIDW5G1+m7gFLklPSwciA6X74VGFE8zf8uQ40PuFRaILjJgtXXoU0K3xmu81 jC8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=gOi+sAzsLGksvKUl56VjHq0o12OphfW72370D80KM+I=; b=ZNHnTJVktee2gVlGIgB2NQ81TQOP6ucQ8plf5ogwFl5JXHp/IVjaomcSXsTVqkLqh6 l0LmefMnW5b6bxdfAL5doIN91d7vRY81gKxpllL+7kXQmir5kGPNiq4kQv6pbTRrR23N ig+30B4egI9sunSE8C6xHbcz7JiXjAzmB3FMvDH+WBECbhxbEKOcdQl7+zaFeJzxIuB4 9tWEo+cndua80KM6jaqsMCAADuORHxAWxlVMDIvgoza0PAK+vQGB3+I0xLR/0HodNNai RfsR47zE3NOg1sqYLyFZBhbjbrjN1PnHVmXYkyWAR7eL7jZ2uxufHfkqbf0sJ7/XoTjR mCoQ== X-Gm-Message-State: AOAM531DZi+6/7pnwNpm9jkeivSgHcwKn8lTZcKea+gNVSb0qOygkhp7 FKnuRBiqcmZ9bv7PZmcvze1wYKgkUtjXvQ== X-Google-Smtp-Source: ABdhPJx0cdBu1aP13I3wprkStkJQkkzaWczPD7v6U8ZQatc3Ujd19aMEMnVQI15J2Z0/k9rLlGfQZQ== X-Received: by 2002:a63:5065:: with SMTP id q37mr5924733pgl.112.1628811803820; Thu, 12 Aug 2021 16:43:23 -0700 (PDT) Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id gd14sm279806pjb.4.2021.08.12.16.43.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 12 Aug 2021 16:43:23 -0700 (PDT) To: Eliot Lear , "rfced-future@iab.org" References: <1876a06a-4a53-1c25-def5-d66d80dfb7e5@lear.ch> From: Brian E Carpenter Message-ID: <7eb6c62b-94cf-48a0-b752-2ec3ca9b7d82@gmail.com> Date: Fri, 13 Aug 2021 11:43:19 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <1876a06a-4a53-1c25-def5-d66d80dfb7e5@lear.ch> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] New issue 79: Style guide handling X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2021 23:43:31 -0000 > the model we have seems to indicate that these documents would go to th= e RPC unless and until the RSWG and RSAB say otherwise That seems exactly right. I'm not even sure we need to say anything in th= e draft; the parts of the style guide that are not in an RFC seem to be o= perational details that the RPC will handle as a matter of course. Regards Brian On 13-Aug-21 09:08, Eliot Lear wrote: > Several people have mentioned the style guide, and so I went back and l= ooked at both it and the text we have in the draft. >=20 > Right now the text in Section 6.1 states: >=20 > This document creates the Editorial Stream. >=20 > Any and all future documents produced by the RSWG and approved by t= he > RSAB shall be published in the Editorial Stream. >=20 > The style guide consists of RFCs and other documents[1]. The text in th= e draft doesn't quite cover that. The RFCs in question are RFC 7322, RFC7= 997, and RFC 7841 (boiler plate). They are currently in the IAB stream. W= e should probably explicitly decide to redirect some or all of these to t= he Editorial Stream. With regard to the things that are *not* RFCs (abbre= viations list, terms, and a few other things), the model we have seems to=20 indicate that these documents would go to the RPC unless and until the RS= WG and RSAB say otherwise in a new policy RFC. >=20 > Is my understanding correct or is there some proposal that someone else=20 wants to make to address this?=C2=A0 If people want we can go document by=20 document in our f2f, but it's important to have a good handle on the mode= l. >=20 > Eliot >=20 > [1] https://www.rfc-editor.org/styleguide/ >=20 >=20 From nobody Fri Aug 13 01:58:16 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3A9D3A0C59 for ; Fri, 13 Aug 2021 01:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.891 X-Spam-Level: X-Spam-Status: No, score=-0.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=lear.ch 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 s6a27gJZFH0L for ; Fri, 13 Aug 2021 01:58:08 -0700 (PDT) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BBA83A0C54 for ; Fri, 13 Aug 2021 01:58:06 -0700 (PDT) Received: from [IPv6:2001:420:c0c0:1011::1] ([IPv6:2001:420:c0c0:1011:0:0:0:1]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 17D8vx9X350403 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Fri, 13 Aug 2021 10:58:00 +0200 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1628845082; bh=/DA5Uxyki97dbB9jUsJtyKAuhvH+g+m4vIuyrOotVbQ=; h=To:References:From:Cc:Subject:Date:In-Reply-To:From; b=mLezTgfQRCNo8+Qv0ykvz2DxwRkKeE1WUY5GAaH6LKeYHouFWwJQdrldrmAYo/WLi rmIgzPDpYR5MuDS4QG4Qh13DASmG9kgWOsc4kcl9fk0fa3Cko0Jqer2fbszZQfWRbP fGuy9qvb7n2BsNB2/b3Bgq01olHvtW7YNGEpSjEY= To: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= References: <1876a06a-4a53-1c25-def5-d66d80dfb7e5@lear.ch> <9e339fb8-8413-b9b3-c792-55955ac43296@it.aoyama.ac.jp> From: Eliot Lear Cc: Brian E Carpenter , "rfced-future@iab.org" Message-ID: Date: Fri, 13 Aug 2021 10:57:57 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <9e339fb8-8413-b9b3-c792-55955ac43296@it.aoyama.ac.jp> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="pDbziWNE4SLLrQ0acg5mw3IzbDnBGTc3v" Archived-At: Subject: Re: [Rfced-future] New issue 79: Style guide handling X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2021 08:58:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --pDbziWNE4SLLrQ0acg5mw3IzbDnBGTc3v Content-Type: multipart/mixed; boundary="5ByMUHsGFAffBrMpZi34sx5huWEmILt74"; protected-headers="v1" From: Eliot Lear To: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Cc: Brian E Carpenter , "rfced-future@iab.org" Message-ID: Subject: Re: New issue 79: Style guide handling References: <1876a06a-4a53-1c25-def5-d66d80dfb7e5@lear.ch> <9e339fb8-8413-b9b3-c792-55955ac43296@it.aoyama.ac.jp> In-Reply-To: <9e339fb8-8413-b9b3-c792-55955ac43296@it.aoyama.ac.jp> --5ByMUHsGFAffBrMpZi34sx5huWEmILt74 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Martin, On 13.08.21 02:55, Martin J. D=C3=BCrst wrote: > > By "new policy RFC", I hope this would NOT mean that a policy RFC=20 > would have to be written first, and then an actual RFC for the=20 > content. I hope it wouldn't even really mean that the RFC being=20 > written would have to explicitly declare policy. I go back to the question I like to ask: do we need to say anything now, = or can we leave the matter in the hands of the RSWG/RSAB?=C2=A0 I always = ask=20 that question not so much to kick a can down the road but because we=20 could try to cover a great many eventualities that might never occur,=20 and our svelte 20 page document could easily balloon. This having been said, the term "policy RFC" probably should just read=20 "RFC".=C2=A0 To Brian's point, perhaps the only thing this group should=20 consider is which RFCs should be considered part of the new stream. Eliot --5ByMUHsGFAffBrMpZi34sx5huWEmILt74-- --pDbziWNE4SLLrQ0acg5mw3IzbDnBGTc3v Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmEWNBUFAwAAAAAACgkQh7ZrRtnSejOo /ggAixa7dSZGA9WcuPaoR1jASFkYUC/rNBrGxi22CvQbw/XETvNBuLC/GV42bETOmJNPWtxHaaAD 1uNNggNGVejsvn633m7pL4uNXbJR1WT1a9bIdDLcoUY6X0HaGhVrrvvwZAd0RoHBRNdZwt/+GZPE p2+HI3rHwMzmtNrbjjgwcXMY2y2vIYnBzjlwqU4xyrO8N4bbVG55FmoCWZWYLkTsaBfVDKKEwtjZ NIrWGy9eAUPQiSl3lN3+Kvhw7rhpTFINF3czQNcHS7Nh3Ds82VOwUDda5Q86X+C6+DECbzO9NyYT LYEDJynZGHfDeVgbrcfrxgbk2s6mBRY/u+WW2lvplw== =oLn1 -----END PGP SIGNATURE----- --pDbziWNE4SLLrQ0acg5mw3IzbDnBGTc3v-- From nobody Fri Aug 13 09:16:48 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C01713A1DF4 for ; Fri, 13 Aug 2021 09:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 Uc7-hbNa_Wq3 for ; Fri, 13 Aug 2021 09:16:43 -0700 (PDT) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 5930B3A1DEA for ; Fri, 13 Aug 2021 09:16:43 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id a13so13935370iol.5 for ; Fri, 13 Aug 2021 09:16:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=HH3FZOwtdPPnn6GAEHfK09ftbBaehD/7R2towLFZ2UI=; b=Tdf/UuDZRA7G6t3mHJgMHKqHk2EejcnmbKBk8bda9rmCFUt1DrAhAP1paRAKkMgrvr LZ2evDZBMPbRG+k01EWHDPzKDLtnQ69UtcIeAebei4aHH8lYwhTRKx3Jzx2UVsDSptF/ EMA7lFhEfn0iLlHIJHzxum+fdPbNWKzaPDX9E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=HH3FZOwtdPPnn6GAEHfK09ftbBaehD/7R2towLFZ2UI=; b=NzTS5so8SPZWioNZVgoa092+qcwNd3hH4UJlqZT0YUZMjU28OzrRmKT+WuXfdTBqZT fhiCinsVxPYR5+7zaAILjqd08CxIvtVLU77MlaHglAXvfWtgvky0oDIqxI+nKncHalf2 6azIVGyJcLkR5GTOmXF/yeiOlKP+nbnJ2H9wKlXP72XvPrHPcFO6WIQTzVc6OWD8M5+q 0ko+C6fj6EUO5gMpQFX1p6XUWhtci4ZMdXs33y0Mx4jd6ndm7bXyAzXuLlipOejaUnCd CHxGcBSYy/TiXQTyWFdzHBrRQQkXKvu9j9cGzsGSSKOk5axrouVlVgbzotHfjIFQ139q suiQ== X-Gm-Message-State: AOAM5329NUvgbGeLonentQVyztXDipnCVgDOaXU2KnVnOHHstrwMkO14 odMjwLyO0b66ybvGoEAYF+bJiA== X-Google-Smtp-Source: ABdhPJxR2rL35tq7tRbmjSx/q3WLXKVFBIQ2fi6TFN4tnLUmWnu/Y4LZz3IkzLFsML2GZsLPEQfcEQ== X-Received: by 2002:a05:6638:304a:: with SMTP id u10mr3083849jak.62.1628871401101; Fri, 13 Aug 2021 09:16:41 -0700 (PDT) Received: from dragon.local (c-73-78-113-156.hsd1.co.comcast.net. [73.78.113.156]) by smtp.gmail.com with ESMTPSA id x4sm1036155ilj.52.2021.08.13.09.16.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 13 Aug 2021 09:16:40 -0700 (PDT) To: Eliot Lear , "rfced-future@iab.org" References: <1876a06a-4a53-1c25-def5-d66d80dfb7e5@lear.ch> From: Peter Saint-Andre Message-ID: Date: Fri, 13 Aug 2021 10:16:38 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <1876a06a-4a53-1c25-def5-d66d80dfb7e5@lear.ch> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] New issue 79: Style guide handling X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2021 16:16:46 -0000 [ no hats ] On 8/12/21 3:08 PM, Eliot Lear wrote: > Several people have mentioned the style guide, and so I went back and > looked at both it and the text we have in the draft. > > Right now the text in Section 6.1 states: > > This document creates the Editorial Stream. > > Any and all future documents produced by the RSWG and approved by the > RSAB shall be published in the Editorial Stream. > > The style guide consists of RFCs and other documents[1]. The text in the > draft doesn't quite cover that. The RFCs in question are RFC 7322, > RFC7997, and RFC 7841 (boiler plate). They are currently in the IAB > stream. We should probably explicitly decide to redirect some or all of > these to the Editorial Stream. It's not clear to me that this document needs to specify the stream in which the style guide RFCs will be handled. The current text says only that documents produced by the RSWG will be published in the Editorial Stream. If the style guide documents are taken up within the RSWG, then they would be published in the Editorial Stream, but that's a matter for the RSWG to address once it has been formed. That seems to me like a reasonable path, but I'm not sure we need to make it explicit at this time. But if folks want to include that level of detail for the avoidance of doubt then as document editor I have no objections to including it. > With regard to the things that are *not* > RFCs (abbreviations list, terms, and a few other things), the model we > have seems to indicate that these documents would go to the RPC unless > and until the RSWG and RSAB say otherwise in a new policy RFC. Agreed. Do people think we need to say that here? Peter From nobody Fri Aug 13 13:48:16 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFA9D3A25F3 for ; Fri, 13 Aug 2021 13:48:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 CxoOiNwajaqc for ; Fri, 13 Aug 2021 13:48:04 -0700 (PDT) Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) (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 9E1B63A25D2 for ; Fri, 13 Aug 2021 13:48:04 -0700 (PDT) Received: by mail-pl1-x62e.google.com with SMTP id w6so6574088plg.9 for ; Fri, 13 Aug 2021 13:48:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=GwCPsT2u7GkQCOcLPTg8bLJCuI4xk79KdyACZ/TKBiY=; b=muHFmA26XbjoCyPtHeBlRvIV6fJjncCbqqFxYP9qAIkvz5ZTS7gDFKtWPOrWg9yroq rEVTQEWzRuEhnGl6aCkF5KOwgYZtLdocC6KWQHCvNkzDV90kHVN6dx4UoM20hAWfn+ti ggYq68DEdZuiBSZLDsufJf4Wc4UWiGAer/Ir7SZqEwdF9IBs9jCq7OROuEscyTTbgfAt QJFEl737KaqRK/Z21300It+sq41ifAo+TuVWE2+tanpJS07HTUSdG2X0LeEVppixuHYI 1lM3dMRx0rBtkronCDLJVeR9MBjPFXSj9S3XNkia9WMaP9awnnbsniJVrX2/3LmITNpX ttWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=GwCPsT2u7GkQCOcLPTg8bLJCuI4xk79KdyACZ/TKBiY=; b=WDFDjpjOuuxFt1d3zPK3B8g7h17a7uvEeAWQZWvnNbrjUmhCChmPgtr9Y+KgwtT99K dt604JZRLew+SAVqcHxccGts4ig3JjPicTXR4IiK16ggxmiqMAFnsp3dyABGK6ehqY4c gJpUco9mQJCCkoOdu/KPuV0aA7LI8yAyH8bFpB+Zn2ZMZCdgUwkypFfjKK/jWEQeihnK eR14UUjaC2ZQLcNCNz6hlLbQdXKs0xZMG0NBFVrUKQkZFmKTZXRkqruIEj2yL2PyMGub IPgVmMuKy0d3SslM3q3BqOKz/HwAOD65AgchTvxDa/FvXeP7cAUnNLtpkQ8GSrA1LH8R zTIw== X-Gm-Message-State: AOAM531HxfndFQyanGAOcHQ/mDBmSDvsj2Rk0UFvlXinbkNHmdDAirFw nbWBVCA9v68Zn5qES2xBMs+/6yTCJws2dg== X-Google-Smtp-Source: ABdhPJzpWem0KIWFlb6FBoqMrYIXYJ2JaVYW3x1QvcvUDIi5hLsnzI7nNntqd+uFKngAYizEruYv/w== X-Received: by 2002:a17:902:e54e:b029:12d:76cd:6744 with SMTP id n14-20020a170902e54eb029012d76cd6744mr3385632plf.0.1628887682082; Fri, 13 Aug 2021 13:48:02 -0700 (PDT) Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id x81sm3141239pfc.22.2021.08.13.13.47.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 13 Aug 2021 13:48:01 -0700 (PDT) To: Peter Saint-Andre , Eliot Lear , "rfced-future@iab.org" References: <1876a06a-4a53-1c25-def5-d66d80dfb7e5@lear.ch> From: Brian E Carpenter Message-ID: <325a38d0-fba0-2917-7e4f-09d6d1aa4dcd@gmail.com> Date: Sat, 14 Aug 2021 08:47:57 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] New issue 79: Style guide handling X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2021 20:48:14 -0000 On 14-Aug-21 04:16, Peter Saint-Andre wrote: > [ no hats ] > > On 8/12/21 3:08 PM, Eliot Lear wrote: >> Several people have mentioned the style guide, and so I went back and >> looked at both it and the text we have in the draft. >> >> Right now the text in Section 6.1 states: >> >> This document creates the Editorial Stream. >> >> Any and all future documents produced by the RSWG and approved by the >> RSAB shall be published in the Editorial Stream. >> >> The style guide consists of RFCs and other documents[1]. The text in the >> draft doesn't quite cover that. The RFCs in question are RFC 7322, >> RFC7997, and RFC 7841 (boiler plate). They are currently in the IAB >> stream. We should probably explicitly decide to redirect some or all of >> these to the Editorial Stream. > > It's not clear to me that this document needs to specify the stream in > which the style guide RFCs will be handled. The current text says only > that documents produced by the RSWG will be published in the Editorial > Stream. If the style guide documents are taken up within the RSWG, then > they would be published in the Editorial Stream, but that's a matter for > the RSWG to address once it has been formed. That seems to me like a > reasonable path, but I'm not sure we need to make it explicit at this > time. But if folks want to include that level of detail for the > avoidance of doubt then as document editor I have no objections to > including it. Well, Eliot wrote: >>> perhaps the only thing this group should >>> consider is which RFCs should be considered part of the new stream. The challenge there is that we could spend a lot of time polishing such text, but I fear we'd end up with "I know it when I see it", as Justice Potter Stewart wrote in 1964. [https://en.wikipedia.org/wiki/I_know_it_when_I_see_it] >> With regard to the things that are *not* >> RFCs (abbreviations list, terms, and a few other things), the model we >> have seems to indicate that these documents would go to the RPC unless >> and until the RSWG and RSAB say otherwise in a new policy RFC. > > Agreed. Do people think we need to say that here? In the end I think we are better off not saying anything. Brian From nobody Sat Aug 14 01:55:29 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB8D73A12D6 for ; Sat, 14 Aug 2021 01:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 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, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch 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 LXxy29FpXd1y for ; Sat, 14 Aug 2021 01:55:21 -0700 (PDT) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80CA63A12CF for ; Sat, 14 Aug 2021 01:55:19 -0700 (PDT) Received: from [IPv6:2001:420:c0c0:1011::2] ([IPv6:2001:420:c0c0:1011:0:0:0:2]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 17E8tEKR388006 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Sat, 14 Aug 2021 10:55:15 +0200 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1628931315; bh=NjqohB0EZhR8/DRfpI8uDh0PmH19t+AU43ukwko2HFU=; h=To:Cc:From:Subject:Date:From; b=exT9L2DgtkJez8nl1anjuNGYXwrXsNBUjN5LypwF5VDZH/XyyBDQ6Kx+2D9Od84zI B9zaq2GT1C6X5IJ6ouZnqsU2YxOwJrk0GoDbKeKxs73hb7Xx3JRVuZZ6KXIQ+eINKe NWiue3G+R7WfGOtLME+6jC7xN/rbFa8cN9eLy8Og= To: "Joel M. Halpern" Cc: "rfced-future@iab.org" From: Eliot Lear Message-ID: <9f3100b9-0b19-a024-e597-dfcd112b0f57@lear.ch> Date: Sat, 14 Aug 2021 10:55:09 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="yYDSgR7XjnvPRNEAaCbH2HTRKdeSMAXnx" Archived-At: Subject: [Rfced-future] Issue 45: When do the WG chairs call rough consensus and what happens next? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Aug 2021 08:55:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --yYDSgR7XjnvPRNEAaCbH2HTRKdeSMAXnx Content-Type: multipart/mixed; boundary="ue2a8pyezgn30mNm1tQ7jEhQteaFuorAJ"; protected-headers="v1" From: Eliot Lear To: "Joel M. Halpern" Cc: "rfced-future@iab.org" Message-ID: <9f3100b9-0b19-a024-e597-dfcd112b0f57@lear.ch> Subject: Issue 45: When do the WG chairs call rough consensus and what happens next? --ue2a8pyezgn30mNm1tQ7jEhQteaFuorAJ Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Joel, > Joel Halpern issue JMH5 > Reading the process, I was struck by a minor gap in the process items. = > specifically in item 4 on issueing the last call. I think the text=20 > should include that the WG Chairs consider the proposal to be=20 > sufficiently developed and refined. We sometimes have situations where = > there is rough consensus for something, but it really needs a little=20 > more work before it is sent out. Obviously, we do not want to require=20 > perfection. But we do want to give the chairs room to say "this needs=20 > more work". This is from an issue in April.=C2=A0 Since then we discussed several=20 eventualities, including what happens if the chairs attempt to block=20 consensus.=C2=A0 The outcome of that conversation seems to be the followi= ng: > =C2=A0=C2=A0 Community members who have concerns about > =C2=A0=C2=A0 the performance of an RSWG chair should direct their feedb= ack to the > =C2=A0=C2=A0 relevant appointing body.=C2=A0 Each appointing body shall= have the power > =C2=A0=C2=A0 to remove its appointed chair at its discretion. That's looking at this issue from the other side, as it were. The way I=20 read this text, the chairs have some latitude on when to start a=20 consensus call, but if it goes too far, complaints will get to the=20 appointing bodies. With that in mind, do you believe the issue is addressed?=C2=A0 If not, i= s=20 there text you would want to add to address the matter? Eliot --ue2a8pyezgn30mNm1tQ7jEhQteaFuorAJ-- --yYDSgR7XjnvPRNEAaCbH2HTRKdeSMAXnx Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmEXhO0FAwAAAAAACgkQh7ZrRtnSejN8 awgAy8lrtEba+IwtnA5MSk3ZlLrqEfr+knm4uUVEkNe4YBbiKysY44BVqsJpkmG331JVddsSO8XR xsTdsyWY//7OaWzhiQV10O3uDkKoX8DKc/KZq+Vf5vBwNalMo+Bjw2o2s2dO88ZJp0/MKfLnR3qR /skSgskdMsi6YuxE2RuiDyXto6sD4jI5kselNofsFpXJmUyzDIpCy4SfJrBwHUUsq9W15zdiNmm+ UdrS5dxWktITji2UyCZqtAkKIoO47NPlD1ASqa0wk3lmZ7uVjz63M99qMxO6mQLTOW3qxdMR38lU O8RaJk+Mm8CfVE38Q4w8XhkTB2ItUg5BZFvr69PtVQ== =wZrr -----END PGP SIGNATURE----- --yYDSgR7XjnvPRNEAaCbH2HTRKdeSMAXnx-- From nobody Sat Aug 14 02:10:03 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05A7C3A03EA for ; Sat, 14 Aug 2021 02:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch 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 XR-VhaY-dQpT for ; Sat, 14 Aug 2021 02:09:56 -0700 (PDT) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 470C13A0365 for ; Sat, 14 Aug 2021 02:09:54 -0700 (PDT) Received: from [IPv6:2001:420:c0c0:1011::2] ([IPv6:2001:420:c0c0:1011:0:0:0:2]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 17E99ov3388198 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Sat, 14 Aug 2021 11:09:51 +0200 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1628932191; bh=BoJmOz6sRLyEGNIT/LV9AGhYIlcGyG0avR6T6AMCrGU=; h=To:From:Cc:Subject:Date:From; b=KNLmkZb96ISTfeHFWVRLJeyTbyBNv+g+1gtETwrE5dxO7nqY0IOfAWqruuZ9RwGIT hiV8vwJ5RUJ/2ZV3/XGvE2aieImnB3qWDMtOTXU0jpjXOuM2ttiwevl3Dycm7iRdpf 11cur6gMnzAZck1hkAhnvd63ZGON+dqZowWtR3K4= To: "Eggert, Lars" From: Eliot Lear Cc: "rfced-future@iab.org" Message-ID: <1a8d5cba-8718-b740-819c-2e4e02babcdc@lear.ch> Date: Sat, 14 Aug 2021 11:09:49 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7wPdeW87NBl183Wl9lpz17jDct4yPLCvN" Archived-At: Subject: [Rfced-future] Proposed Disposition of Issue 46: Lars comments X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Aug 2021 09:10:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7wPdeW87NBl183Wl9lpz17jDct4yPLCvN Content-Type: multipart/mixed; boundary="MIyxw0P26mf1mKnER3IArBscNWM7RUk7E"; protected-headers="v1" From: Eliot Lear To: "Eggert, Lars" Cc: "rfced-future@iab.org" Message-ID: <1a8d5cba-8718-b740-819c-2e4e02babcdc@lear.ch> Subject: Proposed Disposition of Issue 46: Lars comments --MIyxw0P26mf1mKnER3IArBscNWM7RUk7E Content-Type: multipart/alternative; boundary="------------E0C05E735142ED7A556A7B4F" Content-Language: en-US This is a multi-part message in MIME format. --------------E0C05E735142ED7A556A7B4F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi Lars, We need to go through the review that you provided for the first version = of the draft.=C2=A0 As I read this review, there are two issues that need= to=20 be opened, and that this issue be closed.=C2=A0 In the other cases, the=20 matter has been addressed elsewhere.=C2=A0 Could you comment on some or a= ll=20 of the below? > Section 4, paragraph 2, comment: > Continuing publication of RFCs shall be handled by the RFC Production > Center (RPC) function in accordance with current policies in force or > future policies defined as specified in the next section of this > document. > > I'm not quite sure what "Continuing publication" is meant to express - = can > "continuing" be removed, or else, what does it signify? (Or was the=20 > intent to > say "Publication ... shall continue to be handled"? > The word "continuing" is no longer in that text.=C2=A0=C2=A0 Therefore, I= think=20 this is addressed. > Section 5.1.1, paragraph 1, comment: > 5.1.1. RFC Series Working Group (RSWG) > > Calling this group a Working Group will likely be a constant source of = > confusion > for IETF participants that do not pay much attention to organizational > discussions, because this group will be significantly different from=20 > "real" IETF > WGs. I'm wondering if calling it a "Policy Group" or by some other=20 > name may reduce > that possibility for confusion. > We have not discussed this.=C2=A0 I propose to open a new issue. > Section 5.1.1, paragraph 2, comment: > The IETF Chair and the Independent Submissions Editor shall each > appoint and oversee a co-chair of the RSWG. > > I can understand why each separately appoints one chair, but why would = > each then > continue to oversee only the one chair they appointed? > This text is no longer in the document.=C2=A0 I think this is addressed. > Section 5.1.2, paragraph 4, comment: > The voting members of the RSAB shall be as follows: > > Are there members other than voting members on the RSAB? If not, just=20 > call them > members? If yes, who are they? > We have from time to time discussed liaisons.=C2=A0 I do not think we hav= e=20 fully closed this matter, however.=C2=A0 I propose to create a new issue.= > Section 5.1.2, paragraph 7, comment: > Is there an intention for the RSAB to gain additional (voting) members > if new RFC streams are created in the future? > We have discussed this issue and said that this would be a matter for=20 the stream definition RFC. > Section 5.2.2, paragraph 18, comment: > > 1. If a CONCERN exists, discussion will take place within the RSWG. > Again, all RSAB members MUST participate. > > This is an unenforceable MUST. > This text has been changed to say: > Again, all RSAB members are expected to participate. I propose that this issue is addressed. > Section 5.2.2, paragraph 18, comment: > 2. If all CONCERN positions are addressed, then the proposal is > approved. Again, if substantial changes have been made, an > additional call for community input should be made. > > It's not quite clear what "addressed" means. It would be clearer to say= "A > proposal without any CONCERN positions is approved." > The text now reads: > =C2=A0=C2=A0 2.=C2=A0 A proposal without any CONCERN positions is appro= ved.=C2=A0 If > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 substantial changes have been made= in order to address CONCERN > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 positions, an additional call for = community input might be > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 necessary. I proposed that this issue is addressed. > Section 6.1, paragraph 2, comment: > process in confidence. The initial length of service shall be for > one year, but then further extensions will be for three to five > years. > > It will IMO be difficult to hire the desired senior professional on a=20 > one-year > contract. > This text has been removed.=C2=A0 I propose that this issue is addressed.= Eliot --------------E0C05E735142ED7A556A7B4F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Lars,

We need to go through the review that you provided for the first version of the draft.=C2=A0 As I read this review, there are two is= sues that need to be opened, and that this issue be closed.=C2=A0 In the= other cases, the matter has been addressed elsewhere.=C2=A0 Could y= ou comment on some or all of the below?

Section 4, paragraph 2, comment:
Continuing publication of RFCs shall be handled by the RFC Production
Center (RPC) function in accordance with current policies in force or
future policies defined as specified in the next section of this
document.

I'm not quite sure what "Continuing publication" is meant to express - can
"continuing" be removed, or else, what does it signify? (Or was the intent to
say "Publication ... shall continue to be handled"?

The word "continuing" is no longer in that text.=C2=A0=C2=A0 There= fore, I think this is addressed.


Section 5.1.1, paragraph 1, comment:
5.1.1. RFC Series Working Group (RSWG)

Calling this group a Working Group will likely be a constant source of confusion
for IETF participants that do not pay much attention to organizational
discussions, because this group will be significantly different from "real" IETF
WGs. I'm wondering if calling it a "Policy Group" or by some other name may reduce
that possibility for confusion.

We have not discussed this.=C2=A0 I propose to open a new issue.


Section 5.1.1, paragraph 2, comment:
The IETF Chair and the Independent Submissions Editor shall each
appoint and oversee a co-chair of the RSWG.

I can understand why each separately appoints one chair, but why would each then
continue to oversee only the one chair they appointed?

This text is no longer in the document.=C2=A0 I think this is addressed.


Section 5.1.2, paragraph 4, comment:
The voting members of the RSAB shall be as follows:

Are there members other than voting members on the RSAB? If not, just call them
members? If yes, who are they?

We have from time to time discussed liaisons.=C2=A0 I do not think= we have fully closed this matter, however.=C2=A0 I propose to create a= new issue.


Section 5.1.2, paragraph 7, comment:
Is there an intention for the RSAB to gain additional (voting) members
if new RFC streams are created in the future?

We have discussed this issue and said that this would be a matter for the stream definition RFC.

Section 5.2.2, paragraph 18, comment:

  1. If a CONCERN exists, discussion will take place within the RSWG.
    Again, all RSAB members MUST participate.

This is an unenforceable MUST.

This text has been changed to say:

> Again, all RSAB members are expected to participate.

I propose that this issue is addressed.


Section 5.2.2, paragraph 18, comment:
2. If all CONCERN positions are addressed, then the proposal is
approved. Again, if substantial changes have been made, an
additional call for community input should be made.

It's not quite clear what "addressed" means. It would be clearer to say "A
proposal without any CONCERN positions is approved."

The text now reads:

=C2=A0=C2=A0 2.=C2=A0 A proposal without = any CONCERN positions is approved.=C2=A0 If
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 substantial changes have bee= n made in order to address CONCERN
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 positions, an additional cal= l for community input might be
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 necessary.

I proposed that this issue is addressed.


Section 6.1, paragraph 2, comment:
process in confidence. The initial length of service shall be for
one year, but then further extensions will be for three to five
years.

It will IMO be difficult to hire the desired senior professional on a one-year
contract.

This text has been removed.=C2=A0 I propose that this issue is addressed.

Eliot

--------------E0C05E735142ED7A556A7B4F-- --MIyxw0P26mf1mKnER3IArBscNWM7RUk7E-- --7wPdeW87NBl183Wl9lpz17jDct4yPLCvN Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmEXiF4FAwAAAAAACgkQh7ZrRtnSejNg 0wgAv5lDohfZyu7D0p09tfxXyjxHec7QhdCBL/sbglRv3qS82fREMUAMbTtkpBRzec2jlxszBGUJ wBDWJ3UuBAhNAL+iNpsAK0JARHDpqETIwbW4ijwexC3uSSk4t9BVhd+hKzzb1rcxFU9g+UnZ9TUK lndyv1WbQk1p33TkuMjeK3TPuE4mgGq8WiGfg7vaoYxPYWooU7PBDYrrJ+SWnjiBm+GEHzdmL57C 1JGWGtdzXdJEi4zWsM7XfM7MVxEjuE5WGWy9YN6SQd1K8NfJICyDGex1syVJqphDIfhYzdxMIdqV rnR7iaD2YPc+pSweCEYErV1ry27n8RbM3soRIshOzA== =Kzzq -----END PGP SIGNATURE----- --7wPdeW87NBl183Wl9lpz17jDct4yPLCvN-- From nobody Sat Aug 14 02:15:32 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0804D3A073D for ; Sat, 14 Aug 2021 02:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch 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 8NOhH9scyBXu for ; Sat, 14 Aug 2021 02:15:25 -0700 (PDT) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 909BC3A06E7 for ; Sat, 14 Aug 2021 02:15:25 -0700 (PDT) Received: from [IPv6:2001:420:c0c0:1011::2] ([IPv6:2001:420:c0c0:1011:0:0:0:2]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 17E9FLAR388239 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Sat, 14 Aug 2021 11:15:22 +0200 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1628932522; bh=cSU7w3spwKWptVfRyO4K3lJ8aCqBVbbHp7Y57aIr8v8=; h=To:From:Subject:Date:From; b=CTxg9maEIO/gzB1Xk2E0m16E1e8yPh52HVwI7BtOS1y7od7/+YyB6VA6aYFD1mMXI BiCrZB0zMm7Hf4PkBi1pdFY+28YFok/iwi15hmxPxVsQcuud2FSbhxGJfUV0/rQXU0 PCR7Yt0sBh1QstJKihq9XHjLYr0CUCTJMOA3lQl8= To: "rfced-future@iab.org" From: Eliot Lear Message-ID: Date: Sat, 14 Aug 2021 11:15:21 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="TdY0RtvML8Of3u0EBMlKpozawgp34axwO" Archived-At: Subject: [Rfced-future] Propose to close Issue 72: Ability to remove RSWG chairs X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Aug 2021 09:15:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TdY0RtvML8Of3u0EBMlKpozawgp34axwO Content-Type: multipart/mixed; boundary="TFW8U61sanDWn1OhKCAC3Z1sqktE8p1Dv"; protected-headers="v1" From: Eliot Lear To: "rfced-future@iab.org" Message-ID: Subject: Propose to close Issue 72: Ability to remove RSWG chairs --TFW8U61sanDWn1OhKCAC3Z1sqktE8p1Dv Content-Type: multipart/alternative; boundary="------------274D91A87ED21246BED5C3F2" Content-Language: en-US This is a multi-part message in MIME format. --------------274D91A87ED21246BED5C3F2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable According to Peter, the text in -01 will read: > Each appointing body shall have the power > to remove its appointed chair at its discretion. > Please comment by the 28th of August if this poses you concerns. Eliot --------------274D91A87ED21246BED5C3F2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

According to Peter, the text in -01 will read:

Each appointing body shall have the power
to remove its appointed chair at its discretion.

Please comment by the 28th of August if this poses you concerns.

Eliot

--------------274D91A87ED21246BED5C3F2-- --TFW8U61sanDWn1OhKCAC3Z1sqktE8p1Dv-- --TdY0RtvML8Of3u0EBMlKpozawgp34axwO Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmEXiakFAwAAAAAACgkQh7ZrRtnSejPv Mgf/U0css0oy7dSTf3TYosyCeOieJ2WtrUIk2rI+m2clROcIJ26tJem6efqu+oS+TA6RUbS3Er2i eVsaaO3OyK+Luh43S+zn3ViTm+Hz34+RgXN8JgPdyYGb9rG+5Pqe4k3nmtHYw6TUgleuBY5HGLx3 wVxqjhYV5RCJlqvqyDYi/T7VHLGEu2apnKKbtw3X9UJLCcMOMsmp3Wnk/tQ2rB/V5KhhP56en16g E1xNZ9EvCVMDzzBlQmWh73OYZerHdgwH+OJD3U8ZoeGSsSLLubgE/kR8lvLxcrVmujPMbSnNSuVl zsbHP8Y5XMik5iiv32p4ny+prbsmKfEdoVFGWOT1bg== =P8H8 -----END PGP SIGNATURE----- --TdY0RtvML8Of3u0EBMlKpozawgp34axwO-- From nobody Sat Aug 14 02:23:38 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34F9D3A079B for ; Sat, 14 Aug 2021 02:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch 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 GleGkUt-mDWH for ; Sat, 14 Aug 2021 02:23:30 -0700 (PDT) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E2393A079A for ; Sat, 14 Aug 2021 02:23:30 -0700 (PDT) Received: from [IPv6:2001:420:c0c0:1011::2] ([IPv6:2001:420:c0c0:1011:0:0:0:2]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 17E9NQk1388313 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Sat, 14 Aug 2021 11:23:27 +0200 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1628933007; bh=jCa+4rMeirw0REKekXZ1YqQhGcmIlGdn4+dRqJucKOQ=; h=Subject:From:To:Cc:References:Date:In-Reply-To:From; b=o+w9npBL6QJVwCGs/2BQ/tF1B00LN9oC5Ux0qRto7vaUMvXxAguQE+XqL0U+IdVHq oTBBC1uvU0H2X5kKW27ncG/YcRa/VLifEkAs6CcCNxM3lT/3ySR6/AInMFFxVvJY/8 F2JLlJ1BATT5xEoDYhDhPwrPZKkpkOKKgMvf6eHM= From: Eliot Lear To: "Eggert, Lars" Cc: "rfced-future@iab.org" References: <1a8d5cba-8718-b740-819c-2e4e02babcdc@lear.ch> Message-ID: <5b161988-8c9a-cb62-889e-eb8dc16fe03c@lear.ch> Date: Sat, 14 Aug 2021 11:23:26 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <1a8d5cba-8718-b740-819c-2e4e02babcdc@lear.ch> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="BzT6cLHX4TdzegM8z4hIK8vr0KNIKEc1K" Archived-At: Subject: Re: [Rfced-future] Proposed Disposition of Issue 46: Lars comments X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Aug 2021 09:23:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --BzT6cLHX4TdzegM8z4hIK8vr0KNIKEc1K Content-Type: multipart/mixed; boundary="cIO3GEJknIe3fZcxUlSRKEzJQtk2a55kq"; protected-headers="v1" From: Eliot Lear To: "Eggert, Lars" Cc: "rfced-future@iab.org" Message-ID: <5b161988-8c9a-cb62-889e-eb8dc16fe03c@lear.ch> Subject: Re: Proposed Disposition of Issue 46: Lars comments References: <1a8d5cba-8718-b740-819c-2e4e02babcdc@lear.ch> In-Reply-To: <1a8d5cba-8718-b740-819c-2e4e02babcdc@lear.ch> --cIO3GEJknIe3fZcxUlSRKEzJQtk2a55kq Content-Type: multipart/alternative; boundary="------------18D31EE866507011DA80A936" Content-Language: en-US This is a multi-part message in MIME format. --------------18D31EE866507011DA80A936 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable One correction: On 14.08.21 11:09, Eliot Lear wrote: > Section 5.1.2, paragraph 4, comment: >> >> The voting members of the RSAB shall be as follows: >> >> Are there members other than voting members on the RSAB? If not, just = >> call them >> members? If yes, who are they? >> > We have from time to time discussed liaisons.=C2=A0 I do not think we h= ave=20 > fully closed this matter, however.=C2=A0 I propose to create a new issu= e. > We actually did discuss this and came to conclude the following, which=20 is in the document: > =C2=A0=C2=A0 To ensure the smooth functioning of the RFC Series, the RS= AB shall > =C2=A0=C2=A0 include the IETF Executive Director as a non-voting member= since the > =C2=A0=C2=A0 IETF LLC is ultimately responsible for the operation of th= e policy > =C2=A0=C2=A0 implementation function Therefore, I propose to close this as well as addressed. That just=20 leaves the RSWG name as a new issue. Eliot > >> Section 5.1.2, paragraph 7, comment: >> Is there an intention for the RSAB to gain additional (voting) members= >> if new RFC streams are created in the future? >> > We have discussed this issue and said that this would be a matter for=20 > the stream definition RFC. > >> Section 5.2.2, paragraph 18, comment: >> >> 1. If a CONCERN exists, discussion will take place within the RSWG. >> Again, all RSAB members MUST participate. >> >> This is an unenforceable MUST. >> > This text has been changed to say: > > > Again, all RSAB members are expected to participate. > > I propose that this issue is addressed. > > >> Section 5.2.2, paragraph 18, comment: >> 2. If all CONCERN positions are addressed, then the proposal is >> approved. Again, if substantial changes have been made, an >> additional call for community input should be made. >> >> It's not quite clear what "addressed" means. It would be clearer to=20 >> say "A >> proposal without any CONCERN positions is approved." >> > The text now reads: > >> =C2=A0=C2=A0 2.=C2=A0 A proposal without any CONCERN positions is appr= oved.=C2=A0 If >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 substantial changes have been mad= e in order to address CONCERN >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 positions, an additional call for= community input might be >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 necessary. > > I proposed that this issue is addressed. > > >> Section 6.1, paragraph 2, comment: >> process in confidence. The initial length of service shall be for >> one year, but then further extensions will be for three to five >> years. >> >> It will IMO be difficult to hire the desired senior professional on a = >> one-year >> contract. >> > This text has been removed.=C2=A0 I propose that this issue is addresse= d. > > Eliot > > --------------18D31EE866507011DA80A936 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

One correction:

On 14.08.21 11:09, Eliot Lear wrote:
Section 5.1.2, paragraph 4, comment:

The voting members of the RSAB shall be as follows:

Are there members other than voting members on the RSAB? If not, just call them
members? If yes, who are they?

We have from time to time discussed liaisons.=C2=A0 I do not thi= nk we have fully closed this matter, however.=C2=A0 I propose to cre= ate a new issue.

We actually did discuss this and came to conclude the following, which is in the document:

=C2=A0=C2=A0 To ensure the smooth functio= ning of the RFC Series, the RSAB shall
=C2=A0=C2=A0 include the IETF Executive Director as a non-voting = member since the
=C2=A0=C2=A0 IETF LLC is ultimately responsible for the operation= of the policy
=C2=A0=C2=A0 implementation function

Therefore, I propose to close this as well as addressed. That just leaves the RSWG name as a new issue.

Eliot



Section 5.1.2, paragraph 7, comment:
Is there an intention for the RSAB to gain additional (voting) members
if new RFC streams are created in the future?

We have discussed this issue and said that this would be a matter for the stream definition RFC.

Section 5.2.2, paragraph 18, comment:

  1. If a CONCERN exists, discussion will take place within the RSWG.
    Again, all RSAB members MUST participate.

This is an unenforceable MUST.

This text has been changed to say:

> Again, all RSAB members are expected to participate.

I propose that this issue is addressed.


Section 5.2.2, paragraph 18, comment:
2. If all CONCERN positions are addressed, then the proposal is
approved. Again, if substantial changes have been made, an
additional call for community input should be made.

It's not quite clear what "addressed" means. It would be clearer to say "A
proposal without any CONCERN positions is approved."

The text now reads:

=C2=A0=C2=A0 2.=C2=A0 A proposal without = any CONCERN positions is approved.=C2=A0 If
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 substantial changes have bee= n made in order to address CONCERN
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 positions, an additional cal= l for community input might be
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 necessary.

I proposed that this issue is addressed.


Section 6.1, paragraph 2, comment:
process in confidence. The initial length of service shall be for
one year, but then further extensions will be for three to five
years.

It will IMO be difficult to hire the desired senior professional on a one-year
contract.

This text has been removed.=C2=A0 I propose that this issue is addressed.

Eliot


--------------18D31EE866507011DA80A936-- --cIO3GEJknIe3fZcxUlSRKEzJQtk2a55kq-- --BzT6cLHX4TdzegM8z4hIK8vr0KNIKEc1K Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmEXi44FAwAAAAAACgkQh7ZrRtnSejPN bQf+Kna1So5nlz+f4oGCaZs+HNaxWXnK/FKbUNQ5Hn2smXXeaqII6/LNjw1mhcIC1VuzbJwtjELv uFpe6ZL0H63s+0FoPezn1x3gJfJErwSDaYzbyJWigv/1MgB3B4bzi6q6N0hscEnfpOcmGWxeENAu XvIqRiVR7ki3z/I7CQMPn12GEaOU473T3LRqP9t1gBC9Z7j44M3sESJz+3YjmW7n28qKTx3iNJRI b9sD3YuO61rPanzW0xafPCgAGVYGPmq7CU/ll2hrYNO5+wihz3/wPdgu5899OEb/0tNrGJtppszw BAx5FZy/TfWv2Fqo6KQahnUAHIBzrnOd+X5akuqdng== =dUKG -----END PGP SIGNATURE----- --BzT6cLHX4TdzegM8z4hIK8vr0KNIKEc1K-- From nobody Sat Aug 14 02:28:18 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7DE3A07DE for ; Sat, 14 Aug 2021 02:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 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, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch 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 9NG3nMh9jTrx for ; Sat, 14 Aug 2021 02:28:11 -0700 (PDT) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C30D53A07DB for ; Sat, 14 Aug 2021 02:28:11 -0700 (PDT) Received: from [IPv6:2001:420:c0c0:1011::2] ([IPv6:2001:420:c0c0:1011:0:0:0:2]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 17E9S6i6388371 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Sat, 14 Aug 2021 11:28:07 +0200 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1628933288; bh=nj/sIrr5MWbHxbe/oQBriHE+JlZ2u5oT504Cou6VQd4=; h=To:From:Subject:Date:From; b=FYYIQ1A2LM0xfu/xYqTmLAs9H4CLbCCrL2n6D8T3WA+4b0wy5u/hsTJcG0kdzXiAm PC7XJffhWV+oh87oz4r95cn3NphRIxiNhuqDikNRZ0wZPUi5orJxTMtLVAnezH9nA9 O1PX8AsaP+vpKgocBGkDvBP89D3ik4FG6La2jbpc= To: "rfced-future@iab.org" From: Eliot Lear Message-ID: Date: Sat, 14 Aug 2021 11:28:06 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="IUQYmihPGDVIyQepVqraRzbfMvZ5Nd1go" Archived-At: Subject: [Rfced-future] Issue 71: Term limits for RSAB chairs? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Aug 2021 09:28:17 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IUQYmihPGDVIyQepVqraRzbfMvZ5Nd1go Content-Type: multipart/mixed; boundary="u51ypYCFH71OjvknUvdGTtHq74ubNRI4n"; protected-headers="v1" From: Eliot Lear To: "rfced-future@iab.org" Message-ID: Subject: Issue 71: Term limits for RSAB chairs? --u51ypYCFH71OjvknUvdGTtHq74ubNRI4n Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Currently the draft states the following: > =C2=A0=C2=A0 The RSAB shall choose a chair from among its members using= a method > =C2=A0=C2=A0 to be determined by the RSAB. But it says nothing about term limits.=C2=A0 This was mentioned during th= e=20 June interim meeting, but no text has been proposed.=C2=A0 Can those who = support this issue propose some text with some justification, so that=20 the program can consider it? Eliot --u51ypYCFH71OjvknUvdGTtHq74ubNRI4n-- --IUQYmihPGDVIyQepVqraRzbfMvZ5Nd1go Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmEXjKYFAwAAAAAACgkQh7ZrRtnSejOb CAgAxgXB3HpOksuG1WRRcqUdo/DYJ+3awcC3ZX9cA9Se3RT7ndZjDlRxrvq0ej82DtFQo6m112M+ n2XmQC7iZkuLu4Yozwzibies/QH35Z7+erlsePv0eG8nMAkEalc4TKqJ7GO8NktSSPGpATZ0ildK Vs7lLkzMk+QitmR8Ncjf18DgF+aHmn8JoWKWY5W9kSRu57E8mQAUE9OVouVQnjnh1MSWvpzGKOjM kz9J5hFzc2wXjZXrDYPT7Kx1s9Gzrq8XN6KkFFHXPjKAq29pHrz8xS1NY+W/LLif+niCSJasyJKy X6bYDN8ACYxyJARBxlops921hnVBxvQ1qusN+uwqvw== =q9Zg -----END PGP SIGNATURE----- --IUQYmihPGDVIyQepVqraRzbfMvZ5Nd1go-- From nobody Sat Aug 14 03:17:44 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B80A3A1582 for ; Sat, 14 Aug 2021 03:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 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, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch 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 NSOv-BPBi9Ix for ; Sat, 14 Aug 2021 03:17:37 -0700 (PDT) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F8683A1573 for ; Sat, 14 Aug 2021 03:17:36 -0700 (PDT) Received: from Lear-Air.local (31-10-155-187.cgn.dynamic.upc.ch [31.10.155.187]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 17EAHLc4389137 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Sat, 14 Aug 2021 12:17:32 +0200 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1628936253; bh=1rQtIWkK7Hbeg3Cqo0QVtWSH+lls1FEkNUaypTM/zzQ=; h=To:Cc:From:Subject:Date:From; b=BN6hESfZKZxZNRHfPDTnr6hZc04Vg+1PKFF0E16KclA3xiBZoohzMv6YeFXx3lDDz 0DX8i/I07msJ6xovEsySLB0i5rPUiVtXaytA8Mh9kYS4awBK7nClw3/mZKNSP4GIGZ REF1ZmabC1VAN7mrQy+Ok17YHmssgqwzF05ut5rs= To: Michael StJohns Cc: "rfced-future@iab.org" From: Eliot Lear Message-ID: <3ba762ef-09a6-4a7c-a09f-1150b151986c@lear.ch> Date: Sat, 14 Aug 2021 12:17:18 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="842fvD3ghcYlrUTB06LMAn8NueYzb46V0" Archived-At: Subject: [Rfced-future] Issue 18: Contract monitor(s) outside LLC? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Aug 2021 10:17:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --842fvD3ghcYlrUTB06LMAn8NueYzb46V0 Content-Type: multipart/mixed; boundary="7PlMZ1dRWF4j45L4rfgyTKEg0hTik8ihT"; protected-headers="v1" From: Eliot Lear To: Michael StJohns Cc: "rfced-future@iab.org" Message-ID: <3ba762ef-09a6-4a7c-a09f-1150b151986c@lear.ch> Subject: Issue 18: Contract monitor(s) outside LLC? --7PlMZ1dRWF4j45L4rfgyTKEg0hTik8ihT Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Mike, This question was driven by text in your original proposal last year.=C2=A0= =20 The question is whether we need to address text in this draft to discuss = a contract monitor.=C2=A0 Is this issue OBE or is there text you believe = is=20 needed? Thanks, Eliot --7PlMZ1dRWF4j45L4rfgyTKEg0hTik8ihT-- --842fvD3ghcYlrUTB06LMAn8NueYzb46V0 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmEXmC4FAwAAAAAACgkQh7ZrRtnSejMU oggAw1ss1tKpU0HNwgFyjgCE28tdO5ldDB0jza64ldqBd+eGJkxHtaC4FF3dskDIPwmnH02yAVNX ZWVuZQagBtDHQvL+7uRWY1O2u96SmtngP2zvqkGvW1s3br1HQpAI5YG0530SNKsIkw9fi6kQzPba 2NhEgdWdvMB0fujMC6HNSmJEAgZHZEHcSCY0LFDGo1+9IrEgF1dDkqLZVZ4pMGRh1HEpBhJO61Us EVzwBd6ZxNbd6jHJPeBoDiAT7l0R+pVE8vUxp73TmtWJlETJCewMbgove7k+1p8skwwg73YbLGcx GR8g3b78euSdq7GpqsCg7O61omwJrrWCf3owlsTYCg== =t+md -----END PGP SIGNATURE----- --842fvD3ghcYlrUTB06LMAn8NueYzb46V0-- From nobody Sat Aug 14 08:21:33 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 786F63A13BE for ; Sat, 14 Aug 2021 08:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 eh4fkFoc7HqG for ; Sat, 14 Aug 2021 08:21:27 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55F093A13BD for ; Sat, 14 Aug 2021 08:21:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4Gn3zp6Fnrz1nt1F; Sat, 14 Aug 2021 08:21:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1628954486; bh=XJGalLQ/shvAN2nw7fHkgUIPdEmphkk1kpy9Vn7HaTg=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=P+OkOATb/b1YgJRh7U4ag3u+UlmT8fb8R7EG3Pae0Kua67gEYuDoXfP88DeG5SsXw 8Ar7s+RWpl+6JbAaiGHVb6prPuSt2chwxnpHztYDVAPq3AXTEcicQfWggXLd/8JfK/ cXs0vhPXgB0yuuhdUTla1JxW4RnXNQZZt55+DLBk= X-Quarantine-ID: <7TMrafyCiP2N> X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.23.64] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4Gn3zp1M9Dz1nsyG; Sat, 14 Aug 2021 08:21:26 -0700 (PDT) To: Eliot Lear Cc: "rfced-future@iab.org" References: <9f3100b9-0b19-a024-e597-dfcd112b0f57@lear.ch> From: "Joel M. Halpern" Message-ID: <5a2583a5-6d95-7474-58bd-b116dff76fd3@joelhalpern.com> Date: Sat, 14 Aug 2021 11:21:24 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <9f3100b9-0b19-a024-e597-dfcd112b0f57@lear.ch> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Issue 45: When do the WG chairs call rough consensus and what happens next? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Aug 2021 15:21:33 -0000 I was trying to make sure we paid attention to the both sides of the tension. As written, step 4 of section 3.2.2 (combined with other text about the chairs respecting the process, which we need for other reasons) requires that if there is rough consensus the chairs are required to move things forward. I was trying to leave a little room for the case, which I have seen, of "yes, thereis rough consensus, but really, the document isn't done." Now, one can argue from Pete's informational RFC on rough consensus that we do not really have such rough consensus in that case. If folks want to take that tack, I can live with it. I was trying to be clear that document quality is important for these documents. Put differently, no, I do not think the current text really addresses the issue. On the other hand, it is not the among the most important issues we need to address. Yours, Joel On 8/14/2021 4:55 AM, Eliot Lear wrote: > Hi Joel, > >> Joel Halpern issue JMH5 >> Reading the process, I was struck by a minor gap in the process items. >> specifically in item 4 on issueing the last call. I think the text >> should include that the WG Chairs consider the proposal to be >> sufficiently developed and refined. We sometimes have situations where >> there is rough consensus for something, but it really needs a little >> more work before it is sent out. Obviously, we do not want to require >> perfection. But we do want to give the chairs room to say "this needs >> more work". > > > This is from an issue in April.  Since then we discussed several > eventualities, including what happens if the chairs attempt to block > consensus.  The outcome of that conversation seems to be the following: > >>    Community members who have concerns about >>    the performance of an RSWG chair should direct their feedback to the >>    relevant appointing body.  Each appointing body shall have the power >>    to remove its appointed chair at its discretion. > > That's looking at this issue from the other side, as it were. The way I > read this text, the chairs have some latitude on when to start a > consensus call, but if it goes too far, complaints will get to the > appointing bodies. > > With that in mind, do you believe the issue is addressed?  If not, is > there text you would want to add to address the matter? > > Eliot > > > From nobody Sat Aug 14 13:49:27 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 843263A2800 for ; Sat, 14 Aug 2021 13:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, 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 cR-XRxRezvL6 for ; Sat, 14 Aug 2021 13:49:22 -0700 (PDT) Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (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 0B6D93A27FC for ; Sat, 14 Aug 2021 13:49:22 -0700 (PDT) Received: by mail-pj1-x102b.google.com with SMTP id oa17so20526784pjb.1 for ; Sat, 14 Aug 2021 13:49:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=2zwIMGZYQJT9Ehf2MlXkES/lYRoakyIX4ZRntBBvlSg=; b=KSzqNBOr4/bhAiD+6mN4M7fxjPC9bPRwvY4CIBYlerxX8z9SYvwhu88B6tyiXX2r6b fDVnutYOYX3R0bwTc5tpCpOe1tq2pYz9bB5or+BKjjIuwS8f5CrqqC/hF682bFysshnW +AgUtDsXEiJjYwHLpbRNApmS9uc37YrksucTX/dztdbXSMAuJqIeJ7+V/Mtb6VL7QHqC q8WCOMYxz62hy3YyB5NckyspC1g7v035yb1/DE7higm9PeIiDbx1SPJXM0nUqV1EumpG DzLrWhKkHBmgk5+/iFpfZHu1TDfhcIBa4f/TWZhPtri+Lk0afpGQhFBfNvCVC4g+FcA4 OAoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=2zwIMGZYQJT9Ehf2MlXkES/lYRoakyIX4ZRntBBvlSg=; b=G29BVq7Go2rOlnLolWchnarMXqYlCKnorhll5STrn8yvas2aOwtKy8Iq+kzSttD/3s u9YlCkklKZg4Rf7+eYFMntGSZDqgCgtz0Jm8pL+R5R0ORdpDTl8HiyD00pGKCQhlFg+5 bHgC50oK16S2VNTYE1y/xezbnb32tJFad/JhY/KCMqT4/EZEze5UUDP92Dl2u3bm6gjZ CnB1LZVDP/knE2+HWDF1MUDKUWFw+aiSmfN8k4pJQHSaPGdAoqaiRe/IZIKObtCk3VIc d59MP6VOZrnlA/uyb8YMr+dI4KEvp9XsEF0oWtUVcWzUmg0KmnX5dNSGT5IrtPpxNPAT lPKw== X-Gm-Message-State: AOAM530Ge1SERcIuqnTVwN3n8PeMWxzEUTHCT4F9kl9ZKTN8k3tutae1 C9hBHPXQy0HJmlovHNsVWpuypnPCu9OEqA== X-Google-Smtp-Source: ABdhPJwUZT32c74Cy32AU7PNL31oFjeVgTRAzg2wT+NOvjAARDx0TkoEdM2K+TgJZKnWhfFLcrVvdw== X-Received: by 2002:a17:90a:8b07:: with SMTP id y7mr8965539pjn.30.1628974160449; Sat, 14 Aug 2021 13:49:20 -0700 (PDT) Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id k6sm5180504pjl.55.2021.08.14.13.49.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 14 Aug 2021 13:49:19 -0700 (PDT) To: "Joel M. Halpern" , Eliot Lear Cc: "rfced-future@iab.org" References: <9f3100b9-0b19-a024-e597-dfcd112b0f57@lear.ch> <5a2583a5-6d95-7474-58bd-b116dff76fd3@joelhalpern.com> From: Brian E Carpenter Message-ID: Date: Sun, 15 Aug 2021 08:49:15 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <5a2583a5-6d95-7474-58bd-b116dff76fd3@joelhalpern.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Issue 45: When do the WG chairs call rough consensus and what happens next? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Aug 2021 20:49:25 -0000 Up levelling slightly, I think it's the case that when we have closed all the major issues, and the text has been updated accordingly, we'll all have to read the document with some care, to detect remaining issues. At the moment I'd put Joel's issue into "fix later" rather than "closed".=20 Regards Brian On 15-Aug-21 03:21, Joel M. Halpern wrote: > I was trying to make sure we paid attention to the both sides of the=20 > tension. As written, step 4 of section 3.2.2 (combined with other text=20 > about the chairs respecting the process, which we need for other=20 > reasons) requires that if there is rough consensus the chairs are=20 > required to move things forward. >=20 > I was trying to leave a little room for the case, which I have seen, of=20 > "yes, thereis rough consensus, but really, the document isn't done."=20 > Now, one can argue from Pete's informational RFC on rough consensus tha= t=20 > we do not really have such rough consensus in that case. If folks want=20 > to take that tack, I can live with it. I was trying to be clear that=20 > document quality is important for these documents. >=20 > Put differently, no, I do not think the current text really addresses=20 > the issue. On the other hand, it is not the among the most important=20 > issues we need to address. >=20 > Yours, > Joel >=20 > On 8/14/2021 4:55 AM, Eliot Lear wrote: >> Hi Joel, >> >>> Joel Halpern issue JMH5 >>> Reading the process, I was struck by a minor gap in the process items= =2E=20 >>> specifically in item 4 on issueing the last call. I think the text=20 >>> should include that the WG Chairs consider the proposal to be=20 >>> sufficiently developed and refined. We sometimes have situations wher= e=20 >>> there is rough consensus for something, but it really needs a little = >>> more work before it is sent out. Obviously, we do not want to require=20 >>> perfection. But we do want to give the chairs room to say "this needs=20 >>> more work". >> >> >> This is from an issue in April.=C2=A0 Since then we discussed several = >> eventualities, including what happens if the chairs attempt to block=20 >> consensus.=C2=A0 The outcome of that conversation seems to be the foll= owing: >> >>> =C2=A0=C2=A0 Community members who have concerns about >>> =C2=A0=C2=A0 the performance of an RSWG chair should direct their fee= dback to the >>> =C2=A0=C2=A0 relevant appointing body.=C2=A0 Each appointing body sha= ll have the power >>> =C2=A0=C2=A0 to remove its appointed chair at its discretion. >> >> That's looking at this issue from the other side, as it were. The way = I=20 >> read this text, the chairs have some latitude on when to start a=20 >> consensus call, but if it goes too far, complaints will get to the=20 >> appointing bodies. >> >> With that in mind, do you believe the issue is addressed?=C2=A0 If not= , is=20 >> there text you would want to add to address the matter? >> >> Eliot >> >> >> >=20 From nobody Sat Aug 14 13:59:12 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A508C3A288F for ; Sat, 14 Aug 2021 13:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, 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 1w-F1K4tWEcS for ; Sat, 14 Aug 2021 13:59:09 -0700 (PDT) Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (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 740DA3A288D for ; Sat, 14 Aug 2021 13:59:09 -0700 (PDT) Received: by mail-pl1-x635.google.com with SMTP id w6so9269491plg.9 for ; Sat, 14 Aug 2021 13:59:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=k4zXZCx0vzOMammQ3eZ6J+ubcL//OQmUe/ypnkKVXls=; b=GTTpgMh99Iw7l8B1uCTglA4LyYq5NFNBocg0kjtXVvgXio6/bTG7PvobQl/ex1K7df IrTnudTjoiWAgbtmPOgTz90r2avOqVBzJ6giXNQ1ptgmJo5LgnNHmy6GqEMgugWT99zN qlHsI6N2P+mI0AmFQw7rzLKO39njbiXR0TS3rxSmiTgeXFg+96kscP19myA5xlCiHjZN z3Po7i0bzTIeNnWoFfLo4gor5KZLsY+bxzSuf3Gj1BKZF8YjAABmy3BTqv2o3XFIceMm CGggu6T6vZnOSE7LboB0IX4iOd1eOhvO0oSNElwcuWBKvl6hU50uOcJ3WTLcaf0C6F6s Xrgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=k4zXZCx0vzOMammQ3eZ6J+ubcL//OQmUe/ypnkKVXls=; b=UUziYEBxIMGjYCREygx6qg6+TC9FRPqGkYF5+CUUPvMjgvYNB6l5HEjfWxWBcchNRC AWYXE/WhTwAuKsV8LjMpLBspnJuf3q7q7D4YPgGcYoyoddaIuEkYjXKcy7iQrMQFQE8z eDL4BsmwEr5c/JQQmvbLnKbNhguUA6h3QVnwnj4AI01sVfWIiIKJd1pi3tEgyqsq1Ln4 50w8hZVAsKbbAuwF5Vc6PdRzSjoTfL5OKIIF76vhYD3211vo5lqOaIUhXB8M2fYT4Pyo v7LWAxiY4HqSVqm78fu1HxXHyjTEpI+7qFg4AxLx34f9hzcvUNtH0TR8lV0TDc1XS6yx p7Tw== X-Gm-Message-State: AOAM533u8fBNgQ34QeETLJc3k5WPoeYo+U2Cjkt9+RBXGc7sfbJWOUpK mugGqH0J/K43ouV8LTXCDEtynX3jvtXD3w== X-Google-Smtp-Source: ABdhPJywjzSHeR3aHLEUtv6DHXicp57nKOdtP0yXvQapo6JJNiVpkqNSXrV2t6TpbpfFLGAGX75Rrw== X-Received: by 2002:a17:903:3106:b029:12d:306a:55bf with SMTP id w6-20020a1709033106b029012d306a55bfmr6891184plc.11.1628974748414; Sat, 14 Aug 2021 13:59:08 -0700 (PDT) Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id m194sm6710931pfd.58.2021.08.14.13.59.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 14 Aug 2021 13:59:07 -0700 (PDT) To: Eliot Lear , "rfced-future@iab.org" References: From: Brian E Carpenter Message-ID: <543fe2a4-d36b-27de-56a6-84bf8c637d6a@gmail.com> Date: Sun, 15 Aug 2021 08:59:04 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Issue 71: Term limits for RSAB chairs? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Aug 2021 20:59:12 -0000 On 14-Aug-21 21:28, Eliot Lear wrote: > Currently the draft states the following: >=20 >> =C2=A0=C2=A0 The RSAB shall choose a chair from among its members usin= g a method >> =C2=A0=C2=A0 to be determined by the RSAB. >=20 > But it says nothing about term limits.=C2=A0 This was mentioned during = the=20 > June interim meeting, but no text has been proposed.=C2=A0 Can those wh= o=20 > support this issue propose some text with some justification, so that=20 > the program can consider it? I'm not sure I exactly "support" the issue but I'd be inclined to simply insert "annually" in that sentence, to make it clear that it isn't a job for life. I don't think that a specific term limit is advisable in such a small committee, because it would over-constrain the choice of chair. Brian From nobody Sat Aug 14 14:24:07 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA423A29DA for ; Sat, 14 Aug 2021 14:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no 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 YWOdp-O5ACt5 for ; Sat, 14 Aug 2021 14:24:04 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95B7C3A29D8 for ; Sat, 14 Aug 2021 14:24:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id E74D5300BFD for ; Sat, 14 Aug 2021 17:24:03 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 3GQ7WjFb1Zzg for ; Sat, 14 Aug 2021 17:24:02 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id AAC51300AEC for ; Sat, 14 Aug 2021 17:24:02 -0400 (EDT) From: Russ Housley Content-Type: multipart/signed; boundary="Apple-Mail=_3608A38A-BD83-49BB-B04D-FE8798859BC3"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) Date: Sat, 14 Aug 2021 17:24:01 -0400 References: To: "rfced-future@iab.org" In-Reply-To: Message-Id: <96B41DDE-F8F9-4AE6-922F-F36EAFFBC0E7@vigilsec.com> X-Mailer: Apple Mail (2.3445.104.21) Archived-At: Subject: Re: [Rfced-future] Propose to close Issue 72: Ability to remove RSWG chairs X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Aug 2021 21:24:06 -0000 --Apple-Mail=_3608A38A-BD83-49BB-B04D-FE8798859BC3 Content-Type: multipart/alternative; boundary="Apple-Mail=_EBA86835-5947-4C42-A24A-EBF40184D5C2" --Apple-Mail=_EBA86835-5947-4C42-A24A-EBF40184D5C2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > According to Peter, the text in -01 will read: >=20 >> Each appointing body shall have the power >> to remove its appointed chair at its discretion. >>=20 > Please comment by the 28th of August if this poses you concerns. >=20 >=20 I think we should say: Each appointing body shall have the power to remove its appointed chair = at its discretion at any time. Russ --Apple-Mail=_EBA86835-5947-4C42-A24A-EBF40184D5C2 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

According to Peter, the text in -01 will read:

Each appointing body shall have the power
to remove its appointed chair at its discretion.

Please comment by the 28th of August if this poses you concerns.


I think we should say:

Each appointing body shall have the power to remove its appointed chair at its discretion at any time.

Russ

--Apple-Mail=_EBA86835-5947-4C42-A24A-EBF40184D5C2-- --Apple-Mail=_3608A38A-BD83-49BB-B04D-FE8798859BC3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEE3ZgmxD9TboJgMKMUcGKjIhkfjnwFAmEYNHEACgkQcGKjIhkf jnxxLhAAhuHARXLOnUi09PdBAt/VvmBBLflYvIvcHu74BVsM0fSVe9cRX3cS1fJY Tt7QUzCc8hn2h5HCkAr6TSvoo6eh5voLG3PYKgrl4iaGQaIcH6n2fKpESSIPyw5U 7nomzKXJit6Pde+hFuIGQRsQO9f+gchQ38v2ZqmEKiC8xgcs2xDCzigVeCMxVjIb /X3P1uUbfFTgrLlIFxcUmh7ZvliUY4oncpTMeCzz8cYh+LvkxiNQ2V6B3yyRne3e R2yDLB/zJ9P6gNTcim2Hcx0RzACLwJoPiqfYNCWqPUdxrha5Jv/GieceotOS6gQJ GZ3rPSZDcQV2pg2X3LnRBpKKSx7qn6cTLEE5foIbjXwIGGkP0RJa3mCj01m/SVIo 5Nr44mYAWtqwIdz3ZCNWXbVNkdoXXZZccvMvH6uinBX3Md/ztwleNue9EUA1yVaC 8H3PpKW3K3WXPE4KZF2B7X5Vz4xODoG1WgUfNs4rTBhop2TRlrGBA6B1oM8E9qyZ MdyZpmgTAG+07L2A+J4VLuKvL0WqlOlWlEd7W/9km4rV8fmNU+cDrACJd9w7u7Gq A5lrs4pGYVx4h+ZjU8TFGPlL45Y5xKu/Os7hP+nkeyKqIXuDu2GuzDR1Q2Gv/LuA 3IeR/V66XLDKx3aXlggo03JIbfyosU9y508l+YQJ48J0YODson4= =CWdV -----END PGP SIGNATURE----- --Apple-Mail=_3608A38A-BD83-49BB-B04D-FE8798859BC3-- From nobody Sat Aug 14 15:17:38 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B50DC3A2DD3 for ; Sat, 14 Aug 2021 15:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 6lQMVEYoecQr for ; Sat, 14 Aug 2021 15:17:29 -0700 (PDT) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 749DA3A2DD2 for ; Sat, 14 Aug 2021 15:17:29 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id a21so3154491ioq.6 for ; Sat, 14 Aug 2021 15:17:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GB9hPRIDyfhXJDXDqkV+NHwjJlpNCtrfdDNInVQ1ZNc=; b=F7DcH8N7l1IXcv/1hKK2nWv2QR4EAJOmQyDtKhJbxHpgRlGw5Ar7kJpOu8MMGAasiS 48ZJ3vU3ht5psOmaSMTWtsdHlEAD2rIKF1cSSBoujNQZuTStwGuLEd9f/loTmnaoem3n mUkD5kqAYtsq8FI7XxSNkVtCEtluQ0z1gHAWA3nv61fUEnhwIvxlGCNVUFtSMbzj/Ji7 pVTkS6nYhHTK+ZaVwylHO3ebxaZr5n8Up2BTZyd6PeaEg7SOjZfLWQX1cyfW3ClfTk/H UNoDHAGclLNycJjIJg/oKql7rbsjGM9mMmJPxXRrTC6ArW5n2K9Dbm2uxuW7891i8wxX 54Rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GB9hPRIDyfhXJDXDqkV+NHwjJlpNCtrfdDNInVQ1ZNc=; b=TkhX26JXiipdNR2m88WUvk/J43ftoyuK7G8YC/ypyemLw2TG7eaAUcBZSPl0Tt9jTT lqIYUj8BgY/x9/giCA7xA+umb8oJqdP0nk7dBy4wbpM8t1BD5xX5hldiYFGY3ixNAknm SB8jNhBYv6kbFA/QleRVFakoM41kXDaXwOPTwcKrP5Y3MNCcncN/FqQbpBAvI/psz5h/ t46R2/cvpZh0IQCJTeqGFdOOR+2Q1UGy2vzPgfo9QMii1ajZqsClKV5AWEHAi0Ur06TT O0qxSnPqlUMgbRp3NaaK9UE16tlcObIH2RDrL0gxz1CY6fhOyR3cCCe3WlsqYHS7iPog RP7A== X-Gm-Message-State: AOAM532KIXFLPMCrC4EeIzvQAdBHYYrUooFu/cUzdw5m72/CRHJ9TTjU AhiK/VpuWWPLLtttCXtrwItWfJsoU6AxUFJTbo6ATuv0KDhoJA== X-Google-Smtp-Source: ABdhPJxPtX72CZ1RDtK79xwgpVROeqHSPbvhieBOqG/HJKHeAICQSjUlaRdY1OALkvs/Joa8HR5wZfnQ1X66tvx3yyk= X-Received: by 2002:a5d:818b:: with SMTP id u11mr6820093ion.43.1628979448007; Sat, 14 Aug 2021 15:17:28 -0700 (PDT) MIME-Version: 1.0 References: <96B41DDE-F8F9-4AE6-922F-F36EAFFBC0E7@vigilsec.com> In-Reply-To: <96B41DDE-F8F9-4AE6-922F-F36EAFFBC0E7@vigilsec.com> From: Eric Rescorla Date: Sat, 14 Aug 2021 15:16:52 -0700 Message-ID: To: Russ Housley Cc: "rfced-future@iab.org" Content-Type: multipart/alternative; boundary="000000000000585e9f05c98c5501" Archived-At: Subject: Re: [Rfced-future] Propose to close Issue 72: Ability to remove RSWG chairs X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Aug 2021 22:17:36 -0000 --000000000000585e9f05c98c5501 Content-Type: text/plain; charset="UTF-8" On Sat, Aug 14, 2021 at 2:24 PM Russ Housley wrote: > According to Peter, the text in -01 will read: > > Each appointing body shall have the power > to remove its appointed chair at its discretion. > > Please comment by the 28th of August if this poses you concerns. > > I think we should say: > > Each appointing body shall have the power to remove its appointed chair at > its discretion at any time. > I agree with Russ. I thought the previous text was OK but it's good to be clear. -Ekr > Russ > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > --000000000000585e9f05c98c5501 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --000000000000585e9f05c98c5501-- From nobody Sun Aug 15 08:28:45 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F30133A19F7 for ; Sun, 15 Aug 2021 08:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.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 bK59PHLQ4mWF for ; Sun, 15 Aug 2021 08:28:37 -0700 (PDT) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 ED15D3A19F5 for ; Sun, 15 Aug 2021 08:28:36 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id n17so29473583lft.13 for ; Sun, 15 Aug 2021 08:28:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=thwvf4eouKfxpoiIRu8h3d5W0yMpgnkPruu5hpjqU2c=; b=npyKnELfaCipUJCV0eDvTrFIu5WnxGygiCzCFuBv/dmbac6ZZTVgY0KKcZKlGQR7sc Lx42Y5Zwj951Rxazog/CymRk0IOMWedB9UKR8f+wZb0+My83bMFhSCWs/RYbaDvHrRnj Z4anj/QGyx/MeXTDugAGk7eOkJb9ebE5miU4IsKrIUD1EdUXFMlUMuiEPmuIyFliIO4W JC8f7rVw1RvaZNf84eWsobsb+5tnNh9o654Xsu2TOgJb18K84eZzyZN0uHbmrhxotbNE 98Mc8b7UX2eLHa6VbRRjYTCO22mbjp6srmxunSIqXtO4wWFOL9wdV5tmqIdlX3Ztt5au jy+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=thwvf4eouKfxpoiIRu8h3d5W0yMpgnkPruu5hpjqU2c=; b=Vm32WT6AMb74MA1Cos5qxikpTeJsKWl/PufEyMcm3hNMrYe0e8t5MJPnXTFaFk97l2 2IYqJpIvW0gQBR9Ig0lR+DTxxeDJS4P1lDDhd87lllCacKm7MMqASeL6UmvOFMaFFEzN RlMPulc5MGxsbi1BQ0eSXebPO6qw/3O9IZiIGmjBs9PUFsN7gXqu4yTzVzHAvY/3033s zUEzminKLG0Y26U2oh7vDlKdoAB8vy63vPs1pq8JjNP97VNdcPOpKu/WheS8zWNuRpYQ c7qsG+Ijw+VZj0JvIirKuGQnYiQHTsb46pF/iwIqRRayRo4Cqv0A0bt0fLgeH65swJrJ 2hFA== X-Gm-Message-State: AOAM5329WQfVntCJePf0b5w+rWHYZ4O1TkXlVTEJdrdpVQjarBOXZ/W8 ukNxxM5+pgfwtKUOc+Aq6ueL1xVig0cMuR9KIwmsRk6pUEjOyw== X-Google-Smtp-Source: ABdhPJzzBLxnoiZ87PYa/P/HgU4lrJ29bo00e2dX0PA/e5NBQ0NEPo1h7kWc/V8yiwnywvT9UR71ORkOI1rBa45pD5I= X-Received: by 2002:a05:6512:1144:: with SMTP id m4mr5170641lfg.267.1629041312986; Sun, 15 Aug 2021 08:28:32 -0700 (PDT) MIME-Version: 1.0 References: <96B41DDE-F8F9-4AE6-922F-F36EAFFBC0E7@vigilsec.com> In-Reply-To: <96B41DDE-F8F9-4AE6-922F-F36EAFFBC0E7@vigilsec.com> From: "StJohns, Michael" Date: Sun, 15 Aug 2021 11:28:22 -0400 Message-ID: To: Russ Housley Cc: "rfced-future@iab.org" Content-Type: multipart/alternative; boundary="000000000000c906bb05c99abce7" Archived-At: Subject: Re: [Rfced-future] Propose to close Issue 72: Ability to remove RSWG chairs X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Aug 2021 15:28:43 -0000 --000000000000c906bb05c99abce7 Content-Type: text/plain; charset="UTF-8" S/appointed chair/appointed member/ On Sat, Aug 14, 2021 at 17:24 Russ Housley wrote: > According to Peter, the text in -01 will read: > > Each appointing body shall have the power > to remove its appointed chair at its discretion. > > Please comment by the 28th of August if this poses you concerns. > > I think we should say: > > Each appointing body shall have the power to remove its appointed chair at > its discretion at any time. > > Russ > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > --000000000000c906bb05c99abce7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
S/appointed chair/appointed member/

On Sat, Aug 14, 2= 021 at 17:24 Russ Housley <housl= ey@vigilsec.com> wrote:

According to Peter, the text in -01= will read:

Each appointing body shall have the power
to remove its appointed chair at its discretion.

Please comment by the 28th of August if this poses you co= ncerns.


I think we s= hould say:

Each appointing body shall have th= e power to remove its appointed chair at its discretion at any time.
<= /div>

Russ

--
Rfced-future mailing list
Rfced-future@iab.= org
https://www.iab.org/mailman/listinfo/rfced-future
--000000000000c906bb05c99abce7-- From nobody Sun Aug 15 09:21:40 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B00E93A1B77 for ; Sun, 15 Aug 2021 09:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.89 X-Spam-Level: X-Spam-Status: No, score=-0.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=lear.ch 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 TqgQ61fFWVZq for ; Sun, 15 Aug 2021 09:21:32 -0700 (PDT) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EB353A1B78 for ; Sun, 15 Aug 2021 09:21:30 -0700 (PDT) Received: from Lear-Air.local ([31.10.155.187]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 17FGL3xG003224 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Sun, 15 Aug 2021 18:21:10 +0200 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1629044486; bh=SLAMZOp2oD5rVOPLFqnckSZRSNMx1cWCvd+Pz0Blwb4=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=Kuo99fqgDBkfQsMP/CR3ksfdAiaLTRtaxnzGobLQYjY6wdL8yw43UcCNN0lsAA0k+ x2sQmS+R9qrVvAVvR57D0Rkr1vKRXG+o26hi4DEpil8u/N+7vlGKxxSOv/Epxsp5U4 uDEeqM6JQ5CAj1VLv9naWYHIg1dwfFM4W4eiDKUQ= To: "StJohns, Michael" , Russ Housley Cc: "rfced-future@iab.org" References: <96B41DDE-F8F9-4AE6-922F-F36EAFFBC0E7@vigilsec.com> From: Eliot Lear Message-ID: <3b7feb42-bf32-c98d-4de8-7d1dcb39ef5c@lear.ch> Date: Sun, 15 Aug 2021 18:20:47 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NeG0gYrcbmZQ257GdZyqYpz49wKdKqcxi" Archived-At: Subject: Re: [Rfced-future] Propose to close Issue 72: Ability to remove RSWG chairs X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Aug 2021 16:21:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --NeG0gYrcbmZQ257GdZyqYpz49wKdKqcxi Content-Type: multipart/mixed; boundary="AjkCqGj9r3I1zwHnQzP1OHTmAMU4SUrxd"; protected-headers="v1" From: Eliot Lear To: "StJohns, Michael" , Russ Housley Cc: "rfced-future@iab.org" Message-ID: <3b7feb42-bf32-c98d-4de8-7d1dcb39ef5c@lear.ch> Subject: Re: [Rfced-future] Propose to close Issue 72: Ability to remove RSWG chairs References: <96B41DDE-F8F9-4AE6-922F-F36EAFFBC0E7@vigilsec.com> In-Reply-To: --AjkCqGj9r3I1zwHnQzP1OHTmAMU4SUrxd Content-Type: multipart/alternative; boundary="------------14689DBF32AC3E2D5D2EC6DB" Content-Language: en-US This is a multi-part message in MIME format. --------------14689DBF32AC3E2D5D2EC6DB Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Ok, more context (my apologies for not giving more earlier): This is about the RSWG chairs.=C2=A0 The text around it reads as follows:= When the RSWG is formed, the chair appointed by the IESG shall serve for a term of one (1) year and the chair appointed by the IAB shall serve for a term of two (2) years; thereafter, chairs shall serve for a term of two (2) years, with no term limits on renewal. The appointing bodies shall determine their own processes for making these appointments, such as provision for an= open nominations period. Community members who have concerns about the performance of an RSWG chair should direct their feedback to the relevant appointing body. Each appointing body shall have the power to remove its appointed chair at its discretion. What Russ is proposing is changing the last sentence. There is no formal membership for the RSWG.=C2=A0 I believe your comment = pertains to the RSAB, and what the group has agreed there is that each=20 appointing body will establish their own procedures for their delegates=20 to the RSAB. Eliot On 15.08.21 17:28, StJohns, Michael wrote: > S/appointed chair/appointed member/ > > On Sat, Aug 14, 2021 at 17:24 Russ Housley > wrote: > >> According to Peter, the text in -01 will read: >> >>> Each appointing body shall have the power >>> to remove its appointed chair at its discretion. >>> >> Please comment by the 28th of August if this poses you concerns. >> >> > I think we should say: > > Each appointing body shall have the power to remove its appointed > chair at its discretion at any time. > > Russ > > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > > > --------------14689DBF32AC3E2D5D2EC6DB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Ok, more context (my apologies for not giving more earlier):

This is about the RSWG chairs.=C2=A0 The text around it reads as follows:

   When the RSWG is formed, the chair
   appointed by the IESG shall serve for a term of one (1) year and the
   chair appointed by the IAB shall serve for a term of two (2) years;
   thereafter, chairs shall serve for a term of two (2) years, with no
   term limits on renewal.  The appointing bodies shall determine their
   own processes for making these appointments, such as provision for an
   open nominations period.  Community members who have concerns about
   the performance of an RSWG chair should direct their feedback to the
   relevant appointing body.  Each appointing body shall have the power
   to remove its appointed chair at its discretion.

What Russ is proposing is changing the last sentence.

There is no formal membership for the RSWG.=C2=A0 I believe your comment pertains to the RSAB, and what the group has agreed there is that each appointing body will establish their own procedures for their delegates to the RSAB.

Eliot


On 15.08.21 17:28, StJohns, Michael wrote:
S/appointed chair/appointed member/

On Sat, Aug 14, 2021 at 17:24 Russ Housley <housley@vigilsec.com> wrote= :

According to Peter, the text in -01 will read:

Each appointing body shall have the power
to remove its appointed chair at its discretion.

Please comment by the 28th of August if this poses you concerns.


I think we should say:

Each appointing body shall have the power to remove its appointed chair at its discretion at any time.

Russ

--
Rfced-future mailing list
Rfced-future@iab.org
https://www.iab.org/mailman/listinfo/rfced-future

--------------14689DBF32AC3E2D5D2EC6DB-- --AjkCqGj9r3I1zwHnQzP1OHTmAMU4SUrxd-- --NeG0gYrcbmZQ257GdZyqYpz49wKdKqcxi Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmEZPt8FAwAAAAAACgkQh7ZrRtnSejPS lAf/TxPzMPyxIo0lfppHDYr+qe5NZEd8KGl7R7Mm1U4ADVuQ+Z7G2Q+TkpUpaR4n0CSffNFu1Pq+ Vs09hFB04zzo2ig05Wcp3EqeFi6xs0O2Br7iBfWTZX/Geuviv2MplbZg+SSQMbxsFlfqhPFUqJSD CplmtZmhQh+Hgf5pkPWsk+GU6pmvHBgHoDVJkzuoHuLrF+p6K1nv68EiOZCqXeNH69NeW4w/GLFH r6pnMX8s6b8y3xFbwHOioN6XNj31Zmjcivuwrc7O3+nsf9S30vgAACLsa7Mfeud2fpRce+sm63qV Kmu8vUNnH4jpPE2UcrwxG6rN1xL9ai+AUkyFG7hhsQ== =/tmz -----END PGP SIGNATURE----- --NeG0gYrcbmZQ257GdZyqYpz49wKdKqcxi-- From nobody Sun Aug 15 11:16:38 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75A663A1F04 for ; Sun, 15 Aug 2021 11:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.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 rRoTFSI0QQ8J for ; Sun, 15 Aug 2021 11:16:31 -0700 (PDT) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 A445E3A1F07 for ; Sun, 15 Aug 2021 11:16:31 -0700 (PDT) Received: by mail-qt1-x831.google.com with SMTP id z24so12592051qtn.8 for ; Sun, 15 Aug 2021 11:16:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=4xrmC8ppIHZX6KftarfOXBch9Sz+lF9OFfj8Aq9hz+g=; b=L1AkIJX6vPnb7bMhKERkXgR+awBJLgGy7UctBq1l5VXH1tz6aWPY+4jLInWJ9cwNjj 69w1uum05xxC9Xy3ITXtL0aIZFCD8ukZmUzA485PpFeYhYKeNqdBfsra7yDbflAzkxoj wEJLqD6fWE9mSdPs2GhDvzfVllWg/J5k12jZMBz5VXBd0VecTHoIZam2BOISD/se5Ghq NYTsXVsqYVuoY+mCyDQdQZoWo78O3KNLeNVz+l085NUkeX35ulTRDAJEXNrCihPTuS2q 31kVR/9i/kVeUul5nY2re652sO/mS+LNvku/5LAfQKmKhqs23EM1qsTLjXd0Wl7QTYs/ qWAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=4xrmC8ppIHZX6KftarfOXBch9Sz+lF9OFfj8Aq9hz+g=; b=NOQezheSMBz6o1LFuCuTY7D2gnqP+3UblsNc/fV/yOnqZsNsgQo0XIM30VGN5rs6kI shkn3Kb92joekYK1/yyuXjQzf18fv+4gXwKZUeYA0LdH9s2xOh1ixSSuCZilkVVu0m9d uSKy2wN3BCV611KHVh99Xs5IiB4jKpZ599XFzR+AUY4FM041D6Rk4nMV3Rj1MvBn94cP pRGuujU54XO47Z1jXzY88onzVT4Q/w0ZrfqdfQAUk5T6fsC18HdIbKfIpfvLb4LdRWSL FXBFGi2qFyOJfS2VUm9kApboaSVAmqVtjZPT6C07fMlqMdfYnym0PKbKhdQE6Mq/d2UM qAlA== X-Gm-Message-State: AOAM53039XHSdyY5zDFgW6/98VQy5JMNxcpis9jIFtjb7HmkjZGUqS07 r6w+x428lalZ82QkHTYkXDDAHi1aippImBBO X-Google-Smtp-Source: ABdhPJyczUGUj5MVsC3yTdXYAyl8azB6oB+itlmQdcXqCX25ngz7DAQ+wbY4xQ/JIoZb/hTOWSrflg== X-Received: by 2002:ac8:5311:: with SMTP id t17mr2632401qtn.364.1629051388723; Sun, 15 Aug 2021 11:16:28 -0700 (PDT) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id h6sm3689377qtb.44.2021.08.15.11.16.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 15 Aug 2021 11:16:28 -0700 (PDT) To: Eliot Lear , Russ Housley Cc: "rfced-future@iab.org" References: <96B41DDE-F8F9-4AE6-922F-F36EAFFBC0E7@vigilsec.com> <3b7feb42-bf32-c98d-4de8-7d1dcb39ef5c@lear.ch> From: Michael StJohns Message-ID: Date: Sun, 15 Aug 2021 14:16:26 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <3b7feb42-bf32-c98d-4de8-7d1dcb39ef5c@lear.ch> Content-Type: multipart/alternative; boundary="------------CA0D13B315AD3FE65E2932C2" Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Propose to close Issue 72: Ability to remove RSWG chairs X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Aug 2021 18:16:37 -0000 This is a multi-part message in MIME format. --------------CA0D13B315AD3FE65E2932C2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Oh - it's *that* section... In that case,   s/remove/replace   and add "and such replacement shall serve the remainder of the term of the chair they are replacing." to Russ' amendment.    Otherwise you could end up with some confusion of the replacement's term. But if we're giving the groups carte blanche to replace their members at any time, and no term limits, then terms are mostly irrelevant. So maybe delete from "When the RSWG..." to "... limits on renewal." and s/remove/replace/ in Russ' amendment. Other tweaking may actually be necessary - it may take a few months to get the appointing bodies to appoint a chair.  Maybe provide provision for interims appointed from the bodies themselves for a shorter term? Lastly, what happens if either of the two groups decline to provide a chair? Mike On 8/15/2021 12:20 PM, Eliot Lear wrote: > > Ok, more context (my apologies for not giving more earlier): > > This is about the RSWG chairs.  The text around it reads as follows: > > When the RSWG is formed, the chair > appointed by the IESG shall serve for a term of one (1) year and the > chair appointed by the IAB shall serve for a term of two (2) years; > thereafter, chairs shall serve for a term of two (2) years, with no > term limits on renewal. The appointing bodies shall determine their > own processes for making these appointments, such as provision for an > open nominations period. Community members who have concerns about > the performance of an RSWG chair should direct their feedback to the > relevant appointing body. Each appointing body shall have the power > to remove its appointed chair at its discretion. > > What Russ is proposing is changing the last sentence. > > There is no formal membership for the RSWG.  I believe your comment > pertains to the RSAB, and what the group has agreed there is that each > appointing body will establish their own procedures for their > delegates to the RSAB. > > Eliot > > > On 15.08.21 17:28, StJohns, Michael wrote: >> S/appointed chair/appointed member/ >> >> On Sat, Aug 14, 2021 at 17:24 Russ Housley > > wrote: >> >>> According to Peter, the text in -01 will read: >>> >>>> Each appointing body shall have the power >>>> to remove its appointed chair at its discretion. >>>> >>> Please comment by the 28th of August if this poses you concerns. >>> >>> >> I think we should say: >> >> Each appointing body shall have the power to remove its appointed >> chair at its discretion at any time. >> >> Russ >> >> -- >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future >> >> >> --------------CA0D13B315AD3FE65E2932C2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Oh - it's *that* section...

In that case,   s/remove/replace   and add "and such replacement shall serve the remainder of the term of the chair they are replacing." to Russ' amendment.    Otherwise you could end up with some confusion of the replacement's term.

But if we're giving the groups carte blanche to replace their members at any time, and no term limits, then terms are mostly irrelevant. 

So maybe delete from "When the RSWG..." to "... limits on renewal." and s/remove/replace/ in Russ' amendment.

Other tweaking may actually be necessary - it may take a few months to get the appointing bodies to appoint a chair.  Maybe provide provision for interims appointed from the bodies themselves for a shorter term?

Lastly, what happens if either of the two groups decline to provide a chair? 

Mike


On 8/15/2021 12:20 PM, Eliot Lear wrote:

Ok, more context (my apologies for not giving more earlier):

This is about the RSWG chairs.  The text around it reads as follows:

   When the RSWG is formed, the chair
   appointed by the IESG shall serve for a term of one (1) year and the
   chair appointed by the IAB shall serve for a term of two (2) years;
   thereafter, chairs shall serve for a term of two (2) years, with no
   term limits on renewal.  The appointing bodies shall determine their
   own processes for making these appointments, such as provision for an
   open nominations period.  Community members who have concerns about
   the performance of an RSWG chair should direct their feedback to the
   relevant appointing body.  Each appointing body shall have the power
   to remove its appointed chair at its discretion.

What Russ is proposing is changing the last sentence.

There is no formal membership for the RSWG.  I believe your comment pertains to the RSAB, and what the group has agreed there is that each appointing body will establish their own procedures for their delegates to the RSAB.

Eliot


On 15.08.21 17:28, StJohns, Michael wrote:
S/appointed chair/appointed member/

On Sat, Aug 14, 2021 at 17:24 Russ Housley <housley@vigilsec.com> wrote:

According to Peter, the text in -01 will read:

Each appointing body shall have the power
to remove its appointed chair at its discretion.

Please comment by the 28th of August if this poses you concerns.


I think we should say:

Each appointing body shall have the power to remove its appointed chair at its discretion at any time.

Russ

--
Rfced-future mailing list
Rfced-future@iab.org
https://www.iab.org/mailman/listinfo/rfced-future


--------------CA0D13B315AD3FE65E2932C2-- From nobody Sun Aug 15 18:13:27 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 358993A0B66 for ; Sun, 15 Aug 2021 18:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=G86O/mMy; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=uuobmRqd 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 1BPVGGKU0Ghl for ; Sun, 15 Aug 2021 18:13:19 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A26AE3A0B63 for ; Sun, 15 Aug 2021 18:13:19 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 7191A5C00CB for ; Sun, 15 Aug 2021 21:13:18 -0400 (EDT) Received: from imap41 ([10.202.2.91]) by compute5.internal (MEProxy); Sun, 15 Aug 2021 21:13:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=A4OfmLfBqw23M6gkAKIWipVcFnDMQ/n Ls/dVIfXr/70=; b=G86O/mMyif35FxGd+kDhxSAiBkKCGlmcLk7ar8B863ciAL3 p7myNZ9JTXZzFfpMPVSl5KFPe2sEDunQioUHKuS/bRmpJ9Qz9z3FdCtpGFJGBCQx bxMeH82UIVKZ0I2Ti8KsN0ToJj5/fC+x/8Am8CR4Rp4OWrBsweCyod5XQy7HL/YI VA6zLlyNR26zyi4eindJdWWDvpnZ+lj0VG1JjoJs6q+/Eg8Mg0uQ9F79CP2reXNu rpfcpdhAKT8C5EHHXdADxVkJ9asDZ+COF1+X3a2J+qURaTFJgBHtSocAFBQUNv5Q xEV9+Ksod6s/dKF0hbuue47Xj27ZMVunm+TKgCg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=A4OfmL fBqw23M6gkAKIWipVcFnDMQ/nLs/dVIfXr/70=; b=uuobmRqduUQP6JkWk+43vQ /XYimxX9UD9D3/3HmIfdX04mI7KHXNmAm+advYBvu5Zn92d5jbzDDIALo89XBaFl ha3fMGXa4ghk1oX3CRwg704SwqC9gFdy60UdEGP6nhYEba65bhUKTOy2bpCN6943 o8Kbony04D+NAvnfm9go+hVTIQCYbaxYyTJo0QP+P2U1SIHPAnXEKyWnq/FKiuY9 io+BuHLXLvkhsUFyZozutNeazbHgOtelRN/eyokXVNPzxXvDeRJkQDIEuAoMSqZa Mxl7FoolxuS9LLGbZM1duQkOUa6h9lrLaDjhQLgpujG70wW67mXUiOBaPMU7rufg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrledtgdegfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepkeetueeikedtkeelfeekve fhkeffvedvvefgkefgleeugfdvjeejgeffieegtdejnecuvehluhhsthgvrhfuihiivgep tdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 229FA3C0453; Sun, 15 Aug 2021 21:13:18 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1082-gccb13bca62-fm-ubox-20210811.001-gccb13bca Mime-Version: 1.0 Message-Id: In-Reply-To: <543fe2a4-d36b-27de-56a6-84bf8c637d6a@gmail.com> References: <543fe2a4-d36b-27de-56a6-84bf8c637d6a@gmail.com> Date: Mon, 16 Aug 2021 11:12:58 +1000 From: "Martin Thomson" To: rfced-future@iab.org Content-Type: text/plain Archived-At: Subject: Re: [Rfced-future] Issue 71: Term limits for RSAB chairs? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2021 01:13:25 -0000 On Sun, Aug 15, 2021, at 06:59, Brian E Carpenter wrote: > I'm not sure I exactly "support" the issue but I'd be inclined to > simply insert "annually" in that sentence, to make it clear that it > isn't a job for life. I don't think that a specific term limit is > advisable in such a small committee, because it would over-constrain > the choice of chair. That would be fine. From nobody Sun Aug 15 18:30:54 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1277F3A0CB9 for ; Sun, 15 Aug 2021 18:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.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 f4GUECglHWC8 for ; Sun, 15 Aug 2021 18:30:50 -0700 (PDT) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (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 13BA13A0CB4 for ; Sun, 15 Aug 2021 18:30:49 -0700 (PDT) Received: by mail-qk1-x734.google.com with SMTP id n11so12688985qkk.1 for ; Sun, 15 Aug 2021 18:30:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=/FRv42PPnsA5+4/TX4G19LDiUEIjMYu9mQtk6cFiIyg=; b=hnZdQpvZRvvz3NEPDPXSIPNOSJjoJvSixBvylLTzTM8X8LIbmHInmRLIdyrliqzsnZ zG61y28tvrynrcALnG7/JB6dPH8adEDRePr96WwxaKSk4209gZm8bDqwtoaQS/Jkf7vU PCfEn7p3QS1j0vuvSdMCBJrWXfKT+pLBhgQji4JngeIi6b/TXJY/tC4uZr2oLpE7v+Jb Kf26xQ8zAJpqWrW/tHR41QxIpwU8blLXPBjLUZiyZ7OBqak4HBYc5OpIbug9Kymmn1it 9bw/sL04EXLpGHhUaw8+MSBhj+1rKiaz0HuXcqOyKljWnFZCQvFt6cRU+IfLoyz9JaLK WIuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=/FRv42PPnsA5+4/TX4G19LDiUEIjMYu9mQtk6cFiIyg=; b=fjIpohKfmdYjN7XoVWhqcSQxyyBJreKJuo35PH0l2EnezECxWnDlPTALcCHD77bWW9 aR5l06UPaV1+q3Lw00RVU6Q05fjmgr0XMXOzdcUqkU8a5+SzKv2uOYA6ZhnKgKNeSKNX TXIvxD4idEXv3Tj705ehCf3NLMaNqFb0BCr62CK9/fx6oq0HiCbx4zuaJ5nXgT9LdISA xFYInufW/rAWIJ9hZpkLhhBr4CE7FvBTSuS376G1fyX3SjdUhMaYLB5Trg7O7u4/h/ie zn0UlF9kIAAzwanx3P87qLJq+j+K/Bfr3dVLpXcL/HmGnMPCr3QMcgypsHFHEJJ359US ylPw== X-Gm-Message-State: AOAM530cMhousYQE/7DtYRvnSzf7UU+lTrIvU4R8WbSiVfBgBwIaDaiW WjTsdFdH4IfcCgMyFruKDFDuQOzHnFGAumFK X-Google-Smtp-Source: ABdhPJxHJnVJSGjaXS90njvWWnS/BNqEMFzkk7VA1uuSojUjxCZWID1oWM4G/NvcPZD0MRzbrkeKHg== X-Received: by 2002:a05:620a:2488:: with SMTP id i8mr3880593qkn.58.1629077447489; Sun, 15 Aug 2021 18:30:47 -0700 (PDT) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id v27sm1299661qkj.129.2021.08.15.18.30.46 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 15 Aug 2021 18:30:47 -0700 (PDT) To: rfced-future@iab.org References: From: Michael StJohns Message-ID: <4338a0bb-32f3-9b92-5ed6-1be5ac3c0b86@nthpermutation.com> Date: Sun, 15 Aug 2021 21:30:44 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------6D72FFAA15D1CB76B2D4C6D4" Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Issue 71: Term limits for RSAB chairs? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2021 01:30:52 -0000 This is a multi-part message in MIME format. --------------6D72FFAA15D1CB76B2D4C6D4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 8/14/2021 5:28 AM, Eliot Lear wrote: > Currently the draft states the following: > >>    The RSAB shall choose a chair from among its members using a method >>    to be determined by the RSAB. > > But it says nothing about term limits.  This was mentioned during the > June interim meeting, but no text has been proposed.  Can those who > support this issue propose some text with some justification, so that > the program can consider it? > > Eliot > > > > Actually, I've been thinking about this.  The Chair position isn't anything special (e.g. unlike the IAB/IESG/IRTF chairs) - it's just "additional duties as assigned" and mainly to preside over processing requests from the RSWG.  Rather than causing sturm und drang over worrying about "job for life" and "fairness", let's just rotate the position. So text: The RSAB chair duties shall rotate annually between each of its members in the following order: IAB, RSCE, IESG, IRTF, ISE.  That order was chosen to mirror the historical order of creation of the appointing organizations.   The RSAB may choose to follow a strict annual rotation, or may adjust the term to coincide with the end of a specific IETF meeting similar to the terms of the IAB and IESG. Mike --------------6D72FFAA15D1CB76B2D4C6D4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 8/14/2021 5:28 AM, Eliot Lear wrote:
Currently the draft states the following:

   The RSAB shall choose a chair from among its members using a method
   to be determined by the RSAB.

But it says nothing about term limits.  This was mentioned during the June interim meeting, but no text has been proposed.  Can those who support this issue propose some text with some justification, so that the program can consider it?

Eliot





Actually, I've been thinking about this.  The Chair position isn't anything special (e.g. unlike the IAB/IESG/IRTF chairs) - it's just "additional duties as assigned" and mainly to preside over processing requests from the RSWG.  Rather than causing sturm und drang over worrying about "job for life" and "fairness", let's just rotate the position.

So text:

The RSAB chair duties shall rotate annually between each of its members in the following order: IAB, RSCE, IESG, IRTF, ISE.  That order was chosen to mirror the historical order of creation of the appointing organizations.   The RSAB may choose to follow a strict annual rotation, or may adjust the term to coincide with the end of a specific IETF meeting similar to the terms of the IAB and IESG.

Mike


--------------6D72FFAA15D1CB76B2D4C6D4-- From nobody Sun Aug 15 18:40:49 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6CC3A0D66 for ; Sun, 15 Aug 2021 18:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.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 mJqNHXLLgQXt for ; Sun, 15 Aug 2021 18:40:46 -0700 (PDT) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 2C9FF3A0D64 for ; Sun, 15 Aug 2021 18:40:46 -0700 (PDT) Received: by mail-qk1-x72b.google.com with SMTP id az7so17555823qkb.5 for ; Sun, 15 Aug 2021 18:40:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=tqOjUFDuN8RGZwVzF4otYInAcJqNa9MWEhgP62OVjqI=; b=JW7QBazHurT7qwqf7BUnW6v5IQg5TeMCHZ6ndMa07qvzYoO2fUPEivGZ6N1Cf9D8+y lc9vnXU+SRsHLmi36WhfAfOFFpoMRUbZO+U0MRplPxCARiKcb2a1YLKNknRP96fmFXOs J+uzHssfkFn0d/o/1x+9jUU5ZZXmu/rCtlVLx5jfleKHvqjsJVn9ji9mAb8lX5e3SWjs 8xTLGb0krGx4qh3m7QBygZJRlJKbXcZz055seYxOTdDAWkbcLHJ6CKpBziLl0LgaKzjk QYIgi8oYPDpqBKYZ9zetMnFLeawXTujuBpgu1M44KJcBa83CWlrXYmthK1NT3LWeSftL k+mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=tqOjUFDuN8RGZwVzF4otYInAcJqNa9MWEhgP62OVjqI=; b=mGH/qNPpmmwZPH/qHrF5DicTNRvFqOklbyJvtUkNOk+VIVNbxYon+bakmpB7HXMVq4 r2lW7KgcYj2z8mazOFSW0czRS5J57ckYV+AS+U4/UNycGKg3Tp92//Ga91oFbeupZpq9 +m5WL1gB3nLF+JfAAv0z9bsut1rrEsELDdufmrRLn+3hRQKIdcSsg6yLPzOX+lqRhCKh HtJIqqK+WupnQr3RJ9YUSZ7J/O4X6xiltlem1oqyMLoAuDJ4qnt2mQSxzoaWeomAEfnX bgZGg3kLAG0g1s79EnDNIawhQH4PpzTwMFTFUGaBczxWuOSoXilHGOn3+NW/P3Tusq3f a93A== X-Gm-Message-State: AOAM533ek9S8IZsxff81yFMZ4HCYQEncH8rXPot7M/gsPNL9Aqrd/OIU 4lIIjOpOpJEW5Glq5pPX5YggjmzC02FqbTWv X-Google-Smtp-Source: ABdhPJx4qMjkCjPpd6hB1F1WUrbzknCisnR8J42pV1SsBnkkjsD/GESkIR3wkNxEc4ZWak9DG80E4A== X-Received: by 2002:a37:8406:: with SMTP id g6mr13738509qkd.105.1629078043810; Sun, 15 Aug 2021 18:40:43 -0700 (PDT) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id i3sm1216557qtm.17.2021.08.15.18.40.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 15 Aug 2021 18:40:43 -0700 (PDT) To: Eliot Lear Cc: "rfced-future@iab.org" References: <3ba762ef-09a6-4a7c-a09f-1150b151986c@lear.ch> From: Michael StJohns Message-ID: Date: Sun, 15 Aug 2021 21:40:41 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <3ba762ef-09a6-4a7c-a09f-1150b151986c@lear.ch> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Issue 18: Contract monitor(s) outside LLC? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2021 01:40:49 -0000 On 8/14/2021 6:17 AM, Eliot Lear wrote: > Mike, > > This question was driven by text in your original proposal last year.  > The question is whether we need to address text in this draft to > discuss a contract monitor.  Is this issue OBE or is there text you > believe is needed? > > Thanks, > > Eliot > > This is tied inextricably to how much direction we purport to give to the LLC over hiring, firing, and management practices.  If we remove the various text directing that the LLC do x, y and z for evaluations, this can be removed.  If not, then I want to be clear that the LLC can't just delegate its contract management responsibilities to a random group of people ala the RSOC. Typically, contract managers are employees of the contracting organization, or contractors specifically hired AND PAID to manage other contractors.  Both of those provide protection for the managed contractor in that the managers are bound directly and legally by the contracting organization's policies, and they can be fired for screwing up. Later, Mike From nobody Sun Aug 15 22:35:31 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0806F3A158E for ; Sun, 15 Aug 2021 22:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.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 ik_D9OClRjHz for ; Sun, 15 Aug 2021 22:35:20 -0700 (PDT) Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-eopbgr1300122.outbound.protection.outlook.com [40.107.130.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5CBE3A1587 for ; Sun, 15 Aug 2021 22:35:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=n5Caxq0GknQ4xolUY2HppDlBxNyAQbJzjrz8Wuv7d1t7L7yj9Jkr+jrVxdQ5J+qdzOj5SReeL17mjLbZ9b5CSZoyRXOHkJPz3jgiAtOsqTYy03OE38b3BqEvqUJkQ+sRMbWAmfcmHyArJzaCRCIaImwwoGZxZp999oMtdfoLfZo11QpEuBdK4qHTIlAq9x5Fd7pk9W+uWfheUb7WyOG2b/Nf/2/iS64aMEkwmP2vtG4lYc6Yy/pHZyqAogW/a6dewABS84ZkYA4lxVWpoXlwV4FjqXhTGKl3+T1g53wjNWQAnBz6z6xOvK4WcRDHUy9EsQ2lfiFRotVdKZFkCdT5Pw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/ccLxUad9I/tNr5kzF0LceFYUDfP/duPVaZ/XecRXew=; b=aKhZ++5wqAz8M/li4WFNIqX5S4YOizc11M/4mLkH5oorhN0ZWs+xm/aXsT4dhe6Orl3P+YMwp8Oh5q1FCFNLgWDaoualWq4Z2129WXevCYZEQagQ4DJvE1t8cLetbio9euVvUwiStHFjFrdCd4mQ5uwRw9iQ1eJi++ABLgLkbPhxJSR1RjdAIsgHafY9oBNGAr6iRnnKNgrCE8d6eHJA1TS5nk7vcUyt+vUDwvr/bRT1hY85Fi6fOYgZ3gujTYjlUrmiOVqne3jRM7UfnpACjiLSw590uJQdwJMPKib0DN+x/H4Bt/3heRNvEcWQV/8Aoao9gUWlhdbT7AVaLY0Ilg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=it.aoyama.ac.jp; dmarc=pass action=none header.from=it.aoyama.ac.jp; dkim=pass header.d=it.aoyama.ac.jp; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector2-itaoyama-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/ccLxUad9I/tNr5kzF0LceFYUDfP/duPVaZ/XecRXew=; b=jEG4m2qiqf1KEW7NYQmJslW06JQKiKVotL+GGKmxtZzQLN/DxokS0FF5ABfO8he6Zg630Fuei0gFbNiJ/wz0vE1/l2XIyq2Y+v1sdgy9e7m6BmSUKYrpsguietnynvhD4o599e+43pIf8QLCMModhAvYS97Vc8WD3+h+hPbqTmo= Authentication-Results: mozilla.com; dkim=none (message not signed) header.d=none;mozilla.com; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) by TY2PR01MB2316.jpnprd01.prod.outlook.com (2603:1096:404:d::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4415.17; Mon, 16 Aug 2021 05:35:11 +0000 Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::a944:554a:8cd3:e12a]) by TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::a944:554a:8cd3:e12a%9]) with mapi id 15.20.4415.023; Mon, 16 Aug 2021 05:35:11 +0000 From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= To: Jay Daley Cc: rfced-future@iab.org, Eliot Lear , Peter Saint-Andre References: <538d1ce7-6e4b-fea0-f04b-36669c43dec1@nthpermutation.com> <996b71fc-6ebd-06a1-9a0a-2695a6044381@nthpermutation.com> <4ad09680-b067-4475-9232-e8f69101e7c0@lear.ch> <3295300e-d396-36fc-2137-6452de7f5296@nthpermutation.com> <848d287a-d2e5-7e61-90c4-e3718c010906@gmail.com> <086c5844-ef49-4221-94f2-67408182c6a6@it.aoyama.ac.jp> <3b86de0d-6823-c740-7928-4258a420d990@gmail.com> <6140c31e-3f8a-a1f0-8c4b-39be146bb82a@it.aoyama.ac.jp> Organization: Aoyama Gakuin University Message-ID: Date: Mon, 16 Aug 2021 14:35:09 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-ClientProxiedBy: TYCPR01CA0094.jpnprd01.prod.outlook.com (2603:1096:405:3::34) To TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [133.2.210.39] (133.2.210.39) by TYCPR01CA0094.jpnprd01.prod.outlook.com (2603:1096:405:3::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4415.16 via Frontend Transport; Mon, 16 Aug 2021 05:35:10 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 9525cc90-a201-4adb-9b63-08d960779da9 X-MS-TrafficTypeDiagnostic: TY2PR01MB2316: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: VSp1zXXE9oeixh/qECLtmPUXknpn4dhNFCFhnLH26DKEoI6EYZLLbzSP43oqsGHjQXAseosp6kVXtHCYfoNFo5hAPz4/6+qszXa3ozpzfZuHS9cTQHVmxY70Pmj7VwOS4sFoOG0yj1vXk/nOijbk/VFkMsk8U/iyoxj7amI/TJxQFdeN7/XX62y5bOg8xmZTGCtTCU1M6A78n809pOTTeR+S8qkWLmi8v+111JAbT5wP8SdH1/S6HKL+LZ7wQOaLV03tR0r9IvfkpY+DaGtff0edTV/g4UpgWhEmZUtRu22+j+bQesLGcWyl5KdSBK3m/mc0G+PLtH9Ozd9ikl8dXTuedMKIsv1kwjlIhbHlgss/6ek7elrxK7g5xzXYGUQZga08HSyg19Hzlrp0abe+IOHzgE0ZiJNGy8LQK9HH6SGWKYf/sDPvzdrP6Jy8fERp2QVa0iJUAe70vbY68kJzzqyuDZjQu3Fes7hwDrvLzOnl7HFDS9Dhy44N0iAiT2nqlsHeLP5h7JbEvFrq+WDlGjngq3MzQ6NAPPcb5oHbyDvciXuvMPCb3+nkVfxpkCiyzhXHXk4obpDFblHV/Uh0San9zc5LdD1pGLylfAqlF/jelG+aFToWrettWk1wBWJmGf0Unx/N3N+Bl02KyaO7FlbBfBEFjN+8WgOvouLDw4gWXgYOsr+vC3qQukuCcIBiEmpAv0GgJxPjnF4PaEj89ieJb6F3F0x2y9swtj9DEVpi80us8Ux/hf6ITPc5IDuAzaVxdqHDpEjPWR7kFyOIv1AkMc+LOct9XbK6hqf6JBq7zK+TB6WmH0zEXkcNPmPG+m4Sc0fMHx6OMzfu/tkfK3V76W1OVk29ffvaoL84xPChtOw1a8yXgrwaob5lsBwp X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYAPR01MB5689.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(346002)(396003)(366004)(39840400004)(136003)(54906003)(86362001)(31686004)(956004)(2616005)(53546011)(186003)(8676002)(36916002)(52116002)(26005)(31696002)(316002)(786003)(966005)(16576012)(8936002)(478600001)(6486002)(38350700002)(66556008)(66946007)(66476007)(2906002)(6706004)(5660300002)(83380400001)(66574015)(6916009)(4326008)(38100700002)(3940600001)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?NXQ2NzdQZGxlMGRCK1NLTzBjQkVCOEN3OXhSTGpLL3NPbFZIV0NMUmw0NzFv?= =?utf-8?B?YWN5b0c5MXArYkN4cFRkY1JZMEsvOUN5UEUzUEhZK0pCOFpRdmROVlp2TlZH?= =?utf-8?B?R1RsNlhTU1lld0xuOGY2c0Vhd1d2RGRpRTkrUlEybHJyZHlSTTExK1BqUHBw?= =?utf-8?B?Wjd3TXN2NVQ0WUFqQkVBNnY2d0JhWVhOU1BBeGFzeDJVOHNwZUxsRWgzekFO?= =?utf-8?B?YjVqN0F4aithL2tFKzZJUXBBQk1GQTN6U29BclUxRXZjcmpIVDJoejVIcFpM?= =?utf-8?B?dEYyQUVuekFRaFlDQzg0Q2VvYUJlYzJxclVkaE5sSzBiREZvODNENkZ3elVo?= =?utf-8?B?dFdSUjBFOXpHR3dkcjIrME9hM1UweHk3N3orUmRnUXF5bUI3ZmhhUGlSRDJq?= =?utf-8?B?TDdNREhmQWtyYldHYzJjT3JOZzZqM2tvNXBaSG43dXdnMDBiZXZERWtDVVJo?= =?utf-8?B?ZytEQ2xRaThJcitGaUdZWGNTMHZvUDZtNUUrUzBUWENtMjhycDV5Q2lXRmVN?= =?utf-8?B?bnpBZ3A0M0tySWxzbmh4QTN5Y3VnUUIzM0IrZVNZUTNBMUg3Wmgvd24yQ0o0?= =?utf-8?B?c2JJZ0dLR2p0OFQ5YU1JbmQ5SDJ5ajBLdFNkZHZ6bXVHb0JpVkVzdmcyMWsx?= =?utf-8?B?Ri9sU1FMdDZqSWFxaDJOaDlUZmpKdDJ5VitrTkFDOGxXVjQrWFNBMk1hd3RN?= =?utf-8?B?elhmWm1WRzdLMDBmdUwyMm8wWEU2ZS9DUUMwTjg4OU5aRERJeDdKc0hURnY1?= =?utf-8?B?TXMzaUEzRWJPMGhWU1FZU2thY0N4MkJzUGtldEgzekxmcjdTL25mcVRUaUhZ?= =?utf-8?B?Uy9LeEcreWtlbHJYWWFMMG9ZZkdTTTJYWTdsUk5Pb253U0VlYU56VGhhc244?= =?utf-8?B?V2tRQjZLcy9ReWhEVGdSZkswT25Ma29lYmxVRHM0VDVoNlNXdlFwY0dTVVBy?= =?utf-8?B?eklWblNNOFZ2bWwyUlZNd2dkNTY3WUM2MnVCWXd5eW5UaGZzSk84YklrcE1V?= =?utf-8?B?Z1RuYXQ0VmZETVV0QWVpMHRET0gxUHJCL0Nnc255enVZOTlWUFhvNllwVkxX?= =?utf-8?B?cVlkeWJza0MxbGlGQXZGVDNTYUFjWEcvOUg0emxtb0hVS3l2SE1DNitjY3JK?= =?utf-8?B?bVZoeEVWMmJsZklpNUJ4R0ltSXFFNHd1REpXUkZXT3U3ME1raHRWeVdjbXp5?= =?utf-8?B?SUo2RmRBcDlZcjJZYnlhWnZpcUhHRHlIM3VXZ05SeS8rOUc3WGRBNE9ndzJI?= =?utf-8?B?aGF6bUtBd1dCcjRabk5WbHIxdlZpblNhd1BQaXA0VjhseW9kYmJHVHpWWTd5?= =?utf-8?B?WGltQlhwVTh0NzhUZzY2NnNEemZqL1dWNHVYOURzSEJ5RDdmVDMrektHNmR0?= =?utf-8?B?d2NwTGRFM2xia3A0SkZHcnFLQ2U5VVlZVVE4ck1PdDUxZE9JUzErL0VaUXpl?= =?utf-8?B?Y1dFQUtBd0dJb3BUY1hSQzlaalNZL2xSUDBwTFVvNFovdjc4YnBXaHB6ZFIx?= =?utf-8?B?QzBhSFlNOVNpVlBnRVplUVZaSVJRdlFPbkpuWWlGVkZxQ0dIa1ArUktWeTUr?= =?utf-8?B?UE9iUGVQaXljSnpEUGNkRjRQZ2Z2cTlkRzMvSGpUeHNBTUlFeENpSW5QcVEv?= =?utf-8?B?TGc4S0E1RDVMdWFLdGZIMUxVbGVGQngrMHVKdTNyRjhQVEp4eVVSM0NOZFZt?= =?utf-8?B?RDAyWCs2RDMyU29wWkR4TEo3MzBIelBQL0tZaUJOT3ZGNlBxRnVoUERvSzFs?= =?utf-8?Q?F5UrOC95zRm8PW9CQA9YBMca0a9vBpELA7VBCwY?= X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 9525cc90-a201-4adb-9b63-08d960779da9 X-MS-Exchange-CrossTenant-AuthSource: TYAPR01MB5689.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Aug 2021 05:35:11.4169 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: e02030e7-4d45-463e-a968-0290e738c18e X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: nq3wIPWvarmtLQNDmI2+FDwpk3iC1vjATmxdoK+BKmAOewV73RWH4lHhszPOEmpMJrbab0WxGpLcQ3QTzLLh0A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY2PR01MB2316 Archived-At: Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2021 05:35:29 -0000 Hello Jay, others, I'm very sorry it took me over two weeks for an answer, On 2021-07-29 04:52, Jay Daley wrote: > Mrtin > >> On 28/07/2021, at 8:51 PM, Martin J. Dürst wrote: >> >> Hello Jay, others, >> >> On 2021-07-28 07:48, Jay Daley wrote: >>> Eliot asked me to propose some additional text to close off issues #56, #57, #61, #62 which I’ve done below. It doesn’t have the elegance of Peter’s prose so may require some work to align with that. >>> Much of this is already covered in the latest draft at: >>> https://github.com/intarchboard/program-rfced-future/blob/master/draft-iab-rfcefdp-rfced-model.md#roles-and-processes >>> My suggested additions are in red and my suggested text moves are in blue. >> >> Sorry, but please avoid using colors for such distinctions. I usually view all my mail as plain text, and I think there are quite a few others on this list who do so, too. I switched to HTML view just for this mail, but I'd prefer to avoid this. >> >>> Jay >>> —— >>> ## Role of the RPC >>> Publication of RFCs shall be continue to be handled by the RFC Production Center (RPC) function in accordance with high-level policies currently in force or yet to be defined following the processes specified in the foregoing sections of this document. >>> ### RPC work program >>> The RPC follows a work program based on requirements it has gathered from a variety of sources, including policies that have been through the RSWG/RSAB process, and from direct discussions with the RSEA, stream managers, IETF LLC, authors and other IETF participants. In developing this work program, the RPC makes some key decisions which impact the IETF community: >>> 1. For each requirement that is gathered, can it be directly incorporated into the work program or must it first be subject to community consultation. >>> 2. Setting the relative priorities for the various requirements within the work program. >>> 3. Determining if all the important requirements have been gathered. >>> It is likely that the RPC will require advice during the drafting of its work program, which it should seek from at least the RSAB and if required, the chairs of the RSWG. >>> In order to ensure community oversight of the RPC work program: >>> * The RPC must present a draft work program for community feedback at least annually and then publish a final work program incorporating any agreed feedback. >>> * The RPC shall report regularly to the RSAB, RSWG, and broader community regarding the contents and progress of its work program and any key risks or issues affecting it. >>> In the event that the RPC is required to make a decision without consultation that would normally deserve consultation, or makes a decision against the advice of the RSAB, then it must notify the RSAB. >>> All matters of budget, timetable and impact on its performance targets, are between the RPC and IETF LLC. >> >> I have difficulties to see how "work program" and "performance targets" are related. The above description lets them look quite independent, but if that's the case, things won't work out very well. The work program may look very nice, but because it's not part of the performance targets, it may get ignored. If the work program is just a matter between RSAB/RSWG and RPC, without involving the LLC, it may be dead on arrival. > > By definition, the role of the RPC is to follow the RFCs that define the role of the RPC and so if there is an RFC that says they must have a work program and consult on it then that is part of their role. The LLC is responsible for ensuring that the RPC follows its defined role and so, again by definition, the LLC will ensure that the RPC has a work program and follows it. I don’t think we need to say anything about this explicitly but I would not object to in principle to any text that makes that explicit. I think it would be helpful to have something like a definition of "work program" that makes clear that it's subsidiary to the RFCs, the contract with the LLC, and the performance targets. So what about: The work program lays out in some detail how and in what timeframe the RPC plans to execute its work to implement applicable RFCs, execute the contract with the LLC, and achieve its performance targets. An alternative text (taking into account the discussion below) would be: The work program lays out in some detail how and in what timeframe the RPC plans to execute its work to implement new work defined in applicable RFCs, separate from the RPC's day-to-day publishing activity to meet its performance targets. >> >> Also, the terms "work program" and "performance targets" suggest different stuff. Under "work program", I could imagine stuff similar to past items such as introducing DOIs and ISSNs; under "performance targets", I'd imagine "number of RFCs published", "number of RFC pages published", "average delay between some defined states in the editing pipeline", and so on. > > That’s spot on. It's good if I got that right. But I'd prefer not having to read between the lines, and I guess some others also have the same preference. > The RPC needs to balance what resources it puts into the work program and what it puts into day-to-day work to ensure that its performance targets are met. As per the text, that balance and the key factors that affect it - budget, timetable and impact on performance - are between the RPC and LLC. > >> >> Also, all this "work program" stuff seems to somehow be at odds with the process that we are currently working on. To take a past example, let's say the RSWG creates a document that says that RFCs should have DOIs. That document is approved by the RSWG (and published as an RFC), and thus supposed to represent community consensus. But if we follow the above points, it looks like everything might have to be rehashed or regurgitated for the "work program". > > In that scenario the document simply becomes an action on the work plan and the only decision for the RPC is how to prioritise it. There’s no text that gives the RPC any leeway to rehash or regurgitate. Again I don’t see a need to say anything about this explicitly but I would not object to in principle to any text that makes that explicit. My two proposed text variants are attempts to make the relationship between the relevant RFCs, the work program, and the performance targets more explicit. I'm sure they can be improved, but something like one of these would be very helpful to have in the document. Regards,   Martin. > Jay > >> >> So I think we need to clarify the relationship between RSWG consensus documents, LLC performance targets, and RPC work program. >> >> Regards, Martin. >> >> >>> ### Relationship between the RPC and the IETF LLC >>> This document does not specify the exact relationship between the IETF LLC and the RPC function; for example, the RPC function could be provided by a separate corporate entity under contract to the IETF LLC, it could be performed by employees of the IETF LLC, or the IETF LLC could work with independent contractors for some or all aspects of the RPC function. The exact relationship is a matter for the IETF LLC and the IETF Executive Director to determine. >>> The IETF LLC has authority over negotiating performance targets for the RPC and also has responsibility for ensuring that those targets are adhered to. The IETF LLC is empowered to appoint a manager or to convene a committee to complete these activities. >>> Community members who have concerns about the performance of the RPC can request that the IETF LLC look into the matter. Even if the IETF LLC opts to delegate this activity, concerns should be raised with the IETF LLC. The IETF LLC is ultimately responsible to the community via the mechanisms outlined in its charter. >> >> > -- Prof. Dr.sc. Martin J. Dürst Department of Intelligent Information Technology College of Science and Engineering Aoyama Gakuin University Fuchinobe 5-1-10, Chuo-ku, Sagamihara 252-5258 Japan From nobody Mon Aug 16 05:15:25 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B31AF3A0B8C; Mon, 16 Aug 2021 05:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 9htidaCIAAdA; Mon, 16 Aug 2021 05:14:44 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5361A3A0B8A; Mon, 16 Aug 2021 05:14:44 -0700 (PDT) Received: from p200300dee73ba500548241e1a05c4aff.dip0.t-ipconnect.de ([2003:de:e73b:a500:5482:41e1:a05c:4aff]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1mFbVm-0001jk-78; Mon, 16 Aug 2021 14:14:38 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Mirja Kuehlewind In-Reply-To: Date: Mon, 16 Aug 2021 14:14:36 +0200 Cc: rfced-future@iab.org, Eliot Lear , Peter Saint-Andre Content-Transfer-Encoding: quoted-printable Message-Id: References: <896D122F-C341-4B1F-9467-48040F691A42@ietf.org> <096215b8-ba95-7406-fbe5-fcf145417fc3@gmail.com> <9114EB06-AB70-4E6A-A72B-0D7D5867C74A@ietf.org> <538d1ce7-6e4b-fea0-f04b-36669c43dec1@nthpermutation.com> <996b71fc-6ebd-06a1-9a0a-2695a6044381@nthpermutation.com> <4ad09680-b067-4475-9232-e8f69101e7c0@lear.ch> <3295300e-d396-36fc-2137-6452de7f5296@nthpermutation.com> <848d287a-d2e5-7e61-90c4-e3718c010906@gmail.com> <086c5844-ef49-4221-94f2-67408182c6a6@it.aoyama.ac.jp> <3b86de0d-6823-c740-7928-4258a420d990@gmail.com> To: Jay Daley X-Mailer: Apple Mail (2.3608.120.23.2.4) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1629116084;e4dff66c; X-HE-SMSGID: 1mFbVm-0001jk-78 Archived-At: Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2021 12:14:52 -0000 Hi Jay, hi all, Replying to this original mail. The additional text is helpful to better = explain what is meant by work program. I=E2=80=99m still slightly concerned that we are over-specifying this in = the RFC. I think the process as described is fine, but writing it down = in an RFC means we can't easily change anything in future if we see room = or need for optimisation. However, if other people feel it=E2=80=99s important to have it in this = level of details in this RFC, the text looks fine for me. Three small comments/questions below. > On 28. Jul 2021, at 00:48, Jay Daley wrote: >=20 > Eliot asked me to propose some additional text to close off issues = #56, #57, #61, #62 which I=E2=80=99ve done below. It doesn=E2=80=99t = have the elegance of Peter=E2=80=99s prose so may require some work to = align with that. >=20 > Much of this is already covered in the latest draft at: >=20 > = https://github.com/intarchboard/program-rfced-future/blob/master/draft-iab= -rfcefdp-rfced-model.md#roles-and-processes >=20 > My suggested additions are in red and my suggested text moves are in = blue. =20 >=20 > Jay >=20 > =E2=80=94=E2=80=94=20 >=20 > ## Role of the RPC >=20 > Publication of RFCs shall be continue to be handled by the RFC = Production Center (RPC) function in accordance with high-level policies = currently in force or yet to be defined following the processes = specified in the foregoing sections of this document. >=20 > ### RPC work program >=20 > The RPC follows a work program based on requirements it has gathered = from a variety of sources, including policies that have been through the = RSWG/RSAB process, and from direct discussions with the RSEA, stream = managers, IETF LLC, authors and other IETF participants. In developing = this work program, the RPC makes some key decisions which impact the = IETF community: >=20 > 1. For each requirement that is gathered, can it be directly = incorporated into the work program or must it first be subject to = community consultation. >=20 > 2. Setting the relative priorities for the various requirements = within the work program. >=20 > 3. Determining if all the important requirements have been gathered. >=20 > It is likely that the RPC will require advice during the drafting of = its work program, which it should seek from at least the RSAB and if = required, the chairs of the RSWG. Why are the chairs or the RSWG mentioned here? I guess the RPC is free = to ask anybody for advise they want but the main contact point for me = would be the RSAB (given it includes the stream managers). >=20 > In order to ensure community oversight of the RPC work program: >=20 > * The RPC must present a draft work program for community feedback at = least annually and then publish a final work program incorporating any = agreed feedback. How and with whom is the feedback agreed? >=20 > * The RPC shall report regularly to the RSAB, RSWG, and broader = community regarding the contents and progress of its work program and = any key risks or issues affecting it. How does the RPC report to the broader community. Isn=E2=80=99t it = enough to report to RSWG?=20 >=20 > In the event that the RPC is required to make a decision without = consultation that would normally deserve consultation, or makes a = decision against the advice of the RSAB, then it must notify the RSAB. >=20 > All matters of budget, timetable and impact on its performance = targets, are between the RPC and IETF LLC. >=20 > ### Relationship between the RPC and the IETF LLC >=20 > This document does not specify the exact relationship between the IETF = LLC and the RPC function; for example, the RPC function could be = provided by a separate corporate entity under contract to the IETF LLC, = it could be performed by employees of the IETF LLC, or the IETF LLC = could work with independent contractors for some or all aspects of the = RPC function. The exact relationship is a matter for the IETF LLC and = the IETF Executive Director to determine. >=20 > The IETF LLC has authority over negotiating performance targets for = the RPC and also has responsibility for ensuring that those targets are = adhered to. The IETF LLC is empowered to appoint a manager or to convene = a committee to complete these activities. >=20 > Community members who have concerns about the performance of the RPC = can request that the IETF LLC look into the matter. Even if the IETF LLC = opts to delegate this activity, concerns should be raised with the IETF = LLC. The IETF LLC is ultimately responsible to the community via the = mechanisms outlined in its charter. >=20 > =E2=80=94=E2=80=94=20 >=20 > --=20 > Jay Daley > IETF Executive Director > jay@ietf.org >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future From nobody Mon Aug 16 13:52:53 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79BA93A111C for ; Mon, 16 Aug 2021 13:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 4QENiECrff4H for ; Mon, 16 Aug 2021 13:52:45 -0700 (PDT) Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) (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 BC4FC3A1117 for ; Mon, 16 Aug 2021 13:52:45 -0700 (PDT) Received: by mail-pj1-x1036.google.com with SMTP id n5so7972797pjt.4 for ; Mon, 16 Aug 2021 13:52:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Tioo6gBQldbITrzZkScUEVIuQvPCs7gPH7xOrBAsplU=; b=GEGnPmdbxdh7l/aTcvusQZibhRIYfmPy3fLQxJSnvsStzMZTN2vaXVcnIgLIUF1ZY8 J6D0YvQtJA4vxaXcDEF6EHk0T1eXpRUnzmOKFhWKHfFzEmEUv8a0eaA0Lh9Ehh6wzfRk j5AaTwykxiBIMe2bffqa4FgcRiaN/b9VpkvzQ+xowh6BQryTpwx/m57SkaGnisBIwU1B D4+iL9zK/UcRnQjEO/tRIZ3MIE67GhR+iFHmIdlDvgAsO+qdYZ9WloILv/RlrS3lScLc sDyQu73pJ1lLuOwsBAuBOYKm5pGspwpO1dL1lAD+pjbx/woMVaVFCRDfu02uXagk9Clz wSQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Tioo6gBQldbITrzZkScUEVIuQvPCs7gPH7xOrBAsplU=; b=B41l9W0r3VzZlYCeAQUPxTLTTxok/RGn+H0r7mDSMi7iUGCfJUUwxipMfZXXMfrGhZ LeJr8PsDeq40O1R1VFzmVC3+0zPEwF/S198er668KSHYdmEzoUhWKGdnuGxg+WIoGCj6 5rWmYVOd8yhhANjoqOmke+d/vD7r1+xKK09QL3bC28ViSqDoSojWwojp00D3Hv37v49r 834Vk59uNjdWrFiKgUVgPYduCYRHQsnl3Duz/nYiHkIiEW3JLKknUTyfih25hJHQWVdC hr8tZrwj2D66cHXfEtJMf7nB8VZe2rQmRLUgLQNRPiZRGA7JwIZxqXBz+nirpbOimKzy NXQw== X-Gm-Message-State: AOAM531wszOU7knPv/SDIOo5f0LGV8wNFsAT2kR3gIJ2oPfQEz+npEW+ 3biqSDTpGguvqfG6/FWzf50= X-Google-Smtp-Source: ABdhPJwhjlkPnV+Qd1gO7fR52LIV9CrYwM6By/8yClBNRa6gChf3JxYtg2MzuLVh3vXofjQtVQU22g== X-Received: by 2002:a17:903:4112:b029:12d:3ba8:7888 with SMTP id r18-20020a1709034112b029012d3ba87888mr10pld.52.1629147164018; Mon, 16 Aug 2021 13:52:44 -0700 (PDT) Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id n23sm50513pgv.76.2021.08.16.13.52.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 16 Aug 2021 13:52:43 -0700 (PDT) To: Mirja Kuehlewind , Jay Daley Cc: rfced-future@iab.org, Peter Saint-Andre , Eliot Lear References: <9114EB06-AB70-4E6A-A72B-0D7D5867C74A@ietf.org> <538d1ce7-6e4b-fea0-f04b-36669c43dec1@nthpermutation.com> <996b71fc-6ebd-06a1-9a0a-2695a6044381@nthpermutation.com> <4ad09680-b067-4475-9232-e8f69101e7c0@lear.ch> <3295300e-d396-36fc-2137-6452de7f5296@nthpermutation.com> <848d287a-d2e5-7e61-90c4-e3718c010906@gmail.com> <086c5844-ef49-4221-94f2-67408182c6a6@it.aoyama.ac.jp> <3b86de0d-6823-c740-7928-4258a420d990@gmail.com> From: Brian E Carpenter Message-ID: Date: Tue, 17 Aug 2021 08:52:38 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2021 20:52:52 -0000 > I=E2=80=99m still slightly concerned that we are over-specifying this i= n the RFC. I'm more than slightly concerned. Obviously there should be a work plan, and if there isn't, the contract manager (i.e. the LLC) should complain. Management 101, so why should we bikeshed the details in an RFC? Personally I'd remove most of the detailed text quoted below, or rather, move it to the actual contract between the LLC and the contractor. Regards Brian On 17-Aug-21 00:14, Mirja Kuehlewind wrote: > Hi Jay, hi all, >=20 > Replying to this original mail. The additional text is helpful to bette= r explain what is meant by work program. >=20 > I=E2=80=99m still slightly concerned that we are over-specifying this i= n the RFC. I think the process as described is fine, but writing it down = in an RFC means we can't easily change anything in future if we see room = or need for optimisation. >=20 > However, if other people feel it=E2=80=99s important to have it in this=20 level of details in this RFC, the text looks fine for me. >=20 > Three small comments/questions below. >=20 >=20 >> On 28. Jul 2021, at 00:48, Jay Daley wrote: >> >> Eliot asked me to propose some additional text to close off issues #56= , #57, #61, #62 which I=E2=80=99ve done below. It doesn=E2=80=99t have t= he elegance of Peter=E2=80=99s prose so may require some work to align wi= th that. >> >> Much of this is already covered in the latest draft at: >> >> https://github.com/intarchboard/program-rfced-future/blob/master/draf= t-iab-rfcefdp-rfced-model.md#roles-and-processes >> >> My suggested additions are in red and my suggested text moves are in b= lue. =20 >> >> Jay >> >> =E2=80=94=E2=80=94=20 >> >> ## Role of the RPC >> >> Publication of RFCs shall be continue to be handled by the RFC Product= ion Center (RPC) function in accordance with high-level policies currentl= y in force or yet to be defined following the processes specified in the = foregoing sections of this document. >> >> ### RPC work program >> >> The RPC follows a work program based on requirements it has gathered f= rom a variety of sources, including policies that have been through the R= SWG/RSAB process, and from direct discussions with the RSEA, stream manag= ers, IETF LLC, authors and other IETF participants. In developing this w= ork program, the RPC makes some key decisions which impact the IETF commu= nity: >> >> 1. For each requirement that is gathered, can it be directly incorpor= ated into the work program or must it first be subject to community consu= ltation. >> >> 2. Setting the relative priorities for the various requirements withi= n the work program. >> >> 3. Determining if all the important requirements have been gathered. >> >> It is likely that the RPC will require advice during the drafting of i= ts work program, which it should seek from at least the RSAB and if requi= red, the chairs of the RSWG. >=20 > Why are the chairs or the RSWG mentioned here? I guess the RPC is free = to ask anybody for advise they want but the main contact point for me wou= ld be the RSAB (given it includes the stream managers). >=20 >> >> In order to ensure community oversight of the RPC work program: >> >> * The RPC must present a draft work program for community feedback at = least annually and then publish a final work program incorporating any ag= reed feedback. >=20 > How and with whom is the feedback agreed? >=20 >> >> * The RPC shall report regularly to the RSAB, RSWG, and broader commun= ity regarding the contents and progress of its work program and any key r= isks or issues affecting it. >=20 > How does the RPC report to the broader community. Isn=E2=80=99t it enou= gh to report to RSWG?=20 >=20 >> >> In the event that the RPC is required to make a decision without consu= ltation that would normally deserve consultation, or makes a decision aga= inst the advice of the RSAB, then it must notify the RSAB. >> >> All matters of budget, timetable and impact on its performance targets= , are between the RPC and IETF LLC. >> >> ### Relationship between the RPC and the IETF LLC >> >> This document does not specify the exact relationship between the IETF=20 LLC and the RPC function; for example, the RPC function could be provided=20 by a separate corporate entity under contract to the IETF LLC, it could b= e performed by employees of the IETF LLC, or the IETF LLC could work with=20 independent contractors for some or all aspects of the RPC function. The = exact relationship is a matter for the IETF LLC and the IETF Executive Di= rector to determine. >> >> The IETF LLC has authority over negotiating performance targets for th= e RPC and also has responsibility for ensuring that those targets are adh= ered to. The IETF LLC is empowered to appoint a manager or to convene a c= ommittee to complete these activities. >> >> Community members who have concerns about the performance of the RPC c= an request that the IETF LLC look into the matter. Even if the IETF LLC o= pts to delegate this activity, concerns should be raised with the IETF LL= C. The IETF LLC is ultimately responsible to the community via the mechan= isms outlined in its charter. >> >> =E2=80=94=E2=80=94=20 >> >> --=20 >> Jay Daley >> IETF Executive Director >> jay@ietf.org >> >> --=20 >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future >=20 From nobody Mon Aug 16 17:08:00 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A98F3A073E for ; Mon, 16 Aug 2021 17:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.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 rPRFkUV-dTvD for ; Mon, 16 Aug 2021 17:07:44 -0700 (PDT) Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-eopbgr1320128.outbound.protection.outlook.com [40.107.132.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13DDE3A03F8 for ; Mon, 16 Aug 2021 17:07:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=i9D1yaiOdxiqeqOlxx7xbEiP8Yj1qUR8tcv1LYwnTAmETiKLzoCZ+hqiAW7e85RmJu4bqMmo3L0ItbKC4bqriUINP2F+Lqqs5I4Rx1dZPTtSc5rmJnW7KHLMa9JM7Pofod5611bJCkpgY1ex6k/Y6hJf2QWzalbsDV4FQm/iOTVFeCBgr8V4RJknu7lqUav5rhRpCpFk5Ms4GfdpwDyLE6bJ+K49wO4wW0hw/78r1zGXuB9zTUsAlNq0WaWPMLHoPUlS2Sif5HxBkLC2ccT5ysj2GAHzLOOAa5nPwJLuEomX1+Z22QFbOvGf+KsPiJgCvjSyaJ7RJbU5aAPaQNbkLg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2Nj0s1T+bVJ+Is9VPS1Wsdr1tWbhJWN6kCD3LMTvhIo=; b=lRrLDuVr09tWvONva9EX8ESiRlOAxDChB7jZu9/WoWb0maTSzI04AnSuItPhjt2AhKFfF3uENm3qyAfvd78cXoy0mlmG8m/d3NagwLVpsF6VkCWWlH8GKZg2wJwbJrw4P6p42lLvBPFFmLmdY6rhjf7H8QoNovkhFNvum3icNyeEWVdH1maT/C6BOrH4dA/UDRnbotuG/Q555BdesN6tNMx3b+gFe0ouRsDQjLcOg3X+vNJVfvpD9Eq06exAn/1SkJc7DdpE7Dim1JKM+PkCGE0wMC4dub7e6Ax0nzS4vVc41eeN0soh7lZurUKItTe8w7z6RTZQah4Q+sJ37TTaHg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=it.aoyama.ac.jp; dmarc=pass action=none header.from=it.aoyama.ac.jp; dkim=pass header.d=it.aoyama.ac.jp; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector2-itaoyama-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2Nj0s1T+bVJ+Is9VPS1Wsdr1tWbhJWN6kCD3LMTvhIo=; b=QzE7OzA4oIS7S+QPjHFmc6As/XBtLRSvKPc/yRy9DDY29EpwLyYdWUsk8izrx7aVJwJXsHN0Ud7iI5OivGAZopeTS5CW71rwdSDBxjkWYPymCYI/pfxzN8Qmy75kaOtA/+NMQ6auFIEG/iK6cPkbc8dacJzmj2lbf8tbguCN72A= Authentication-Results: mozilla.com; dkim=none (message not signed) header.d=none;mozilla.com; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) by TY2PR01MB4172.jpnprd01.prod.outlook.com (2603:1096:404:d9::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4415.16; Tue, 17 Aug 2021 00:07:39 +0000 Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::a944:554a:8cd3:e12a]) by TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::a944:554a:8cd3:e12a%9]) with mapi id 15.20.4415.024; Tue, 17 Aug 2021 00:07:39 +0000 To: Brian E Carpenter , Mirja Kuehlewind , Jay Daley Cc: rfced-future@iab.org, Eliot Lear , Peter Saint-Andre References: <538d1ce7-6e4b-fea0-f04b-36669c43dec1@nthpermutation.com> <996b71fc-6ebd-06a1-9a0a-2695a6044381@nthpermutation.com> <4ad09680-b067-4475-9232-e8f69101e7c0@lear.ch> <3295300e-d396-36fc-2137-6452de7f5296@nthpermutation.com> <848d287a-d2e5-7e61-90c4-e3718c010906@gmail.com> <086c5844-ef49-4221-94f2-67408182c6a6@it.aoyama.ac.jp> <3b86de0d-6823-c740-7928-4258a420d990@gmail.com> From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <3a52a1a6-3bc6-3cd3-f862-436ba0f41d8d@it.aoyama.ac.jp> Date: Tue, 17 Aug 2021 09:07:36 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-ClientProxiedBy: TYWPR01CA0015.jpnprd01.prod.outlook.com (2603:1096:400:a9::20) To TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.5] (114.185.21.49) by TYWPR01CA0015.jpnprd01.prod.outlook.com (2603:1096:400:a9::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4415.15 via Frontend Transport; Tue, 17 Aug 2021 00:07:39 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: d2a7244b-d82d-4dd4-8d5b-08d9611306ad X-MS-TrafficTypeDiagnostic: TY2PR01MB4172: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: MGXs0imgvTG32eN0iqFkW0UxvePDHYv+ZV8a9iptP7wcsHv5xIt7EdK74XNkR1SxG2Ye6vf+g2307PFiG67S2b2qR3ACjwaBKcnS/5TQOkEAo87qA47APenGdODU19Pu5g8eMBGNrmkIapk9/ZpmIZCqzuqlc5o8qUv5vMNvQ9ovJ/4kOqiY887XWY5ahusBuypJeDX1KGmbBNiViFw9FKvg9pC7Sc91kXZLmt8H3UYIvku3AK4bCgjfQJT89ome2bQD7SWQonZzuhUzrDmYQ5jS2XHKH4jzGY4TwXNLEljkoyNd1zz2w7uL94ofRZkaaNNMyQItLenaer4iMO0ADB140vY0KpdKZa3MxaltN3fiC4OD+V25M4R/OcgzH7u91pM//K9rM/nBRWmlbX/x8KZX/PZaWil07qYXjgvKO6ZI4Uf21IrTiVqLPDWOJzar5OVgr82hmMHPlu/xJHyrWBFNS21wAi+Ws+/h1Dt7jsVzcZYKMjLIGPb2cMJFhNfVensHV2Pb/612R3erEXga7E8WPA3tP5CvhAGAOUZy1QwTUkZK4vvoEgg96vqSaBteeDjHRBZdeDW+wIKA0HNdm4+AtolaMe0HnBqVChscNnQCEn+OCXTuwJL7prgGNKTIdWe5EjfmziDSvxAIRZT/64KkS4i0uOfk0b+PxHzoaNHzoNM0RnyH1K/YpL8RTfTMT6DWbMHHIRAas8V6DQjNzpPyVGJ/kcbMA4LK+qLqgV9jKQzNBlmIe41Wx92M0EYdBeLbzJ6K2vedfnK7f6aJl1bDLZggUx25idcFZKhLRImOjZg+j8defkRXYj4fdVE8lWC4TZosV4XoP/3Uxf5t+g== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYAPR01MB5689.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(376002)(346002)(39840400004)(136003)(396003)(8676002)(36916002)(16576012)(966005)(8936002)(478600001)(52116002)(956004)(53546011)(26005)(5660300002)(110136005)(2616005)(316002)(54906003)(786003)(6486002)(38350700002)(38100700002)(66574015)(83380400001)(31686004)(6666004)(4326008)(186003)(2906002)(31696002)(86362001)(66556008)(66946007)(66476007)(43740500002)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?dHRZZmVGdzNHdmttSU4vSWJOVkxRUUNtTjdOa3EvQW1ndTFWRE1rdnI2ZEdI?= =?utf-8?B?VVBPaVJ0UWhaWUQrMWQ3ZCtueS8zTk9HRGZqZ2dWZWFWZWRlT1NHRlVTNHgy?= =?utf-8?B?VmtFUEh1WE42ZmlBSWllTThpZVdvaS9NREhXZFV3c21tMS9vUzd0K2VQdUlw?= =?utf-8?B?aTZMYzkyaU14RW80d3I3MVM0QjZmZDY3SzNORm9lSGhrRXRGNVQwcTBRRUxX?= =?utf-8?B?S2QyNDFWdDBhWkh1enhRRW5nMkttVFNjcVNaYzE2S2YxeUR2d3JsSVB0MTBP?= =?utf-8?B?Z0V2ZEhBR29hbkt1OVJjNmJERzc0Kyt6WndlTUVGcmwvcEYrZTNNMkxUNUx0?= =?utf-8?B?WlIwSDJ3aHlmeC85aWJtUzJ2MTdxdkZWVkhsdUoxeUdoODhYREJNUGVrdzZM?= =?utf-8?B?U2lxa05GM0RRUU55djJJU21YWFlhaUR0cnh2a09hRjNqejRnOVFWTk1teGVk?= =?utf-8?B?QTlGbUhNMU1hOFY1VXdXdkJTV3A2VldNRTYyWVRNUis3dWtQVzRaT2NqUkh6?= =?utf-8?B?Z0dQUnU1WWN1TWR1SktYTjJFUnNrZkRwWnY3dm9SN2NVb2Q4UUNONW0wdXhL?= =?utf-8?B?cHNzbGZRY2QzVWpIK01Va0JHZ0ZDalVTaUpXQnZubTV4SVhVeU5aemZDZnBM?= =?utf-8?B?UURQOGJOL3BiVTIzcW1zMWxUaFpha0JLZGp6VElheGxsOVNqYm00ZmFSUEV3?= =?utf-8?B?emRyVi96OHl6cEVDZkZqNzVMWEVGd0c4dEQvalp4N2ZZZTRrbmVuU1NBSytE?= =?utf-8?B?amkrYmZHdGJJT21vYlVJWU1CNEQ5K3h4aXQ4L2plR3dMdldZUEdha2p6TVFK?= =?utf-8?B?N251azNSY1ptNWJVMCtaMlcvQUtJWUkrYitSR3ZJZkpURklYb3lDbEloMFV6?= =?utf-8?B?QXlyZWlNdndVYndMUUs1dnZoaXk0ZEhSMWJCbnIrNXR5SCtKaFJ1TGdZQkRm?= =?utf-8?B?ejVqVXZrNHJ6U0dsTk8yc21LR0lYSWhhc3VyeHg2ZGZkYmI5dy9yUWtwMktr?= =?utf-8?B?WE0xMWJieHJUVVdqNWlBaTJYNGlTY1FySmlERVBVb3RLTDhzVTJxS1FFOHh1?= =?utf-8?B?MmpIeTlGTGEvU3ROVDBlbEtTbk96bHRScHZFWElxc0Q5dnlpY3YvaUhoblNs?= =?utf-8?B?TG5RYnNiYm5nbnpuWUtjK0Q0TnZxWlBuSFBWbjRLbkZNaFNzUDU5SXpIVkFU?= =?utf-8?B?dVd5YlJSTWQrZTRDTUVpZFRRMEU2bkVpR0xMa1UvR1ZsZDBtZ3VhNDVRQm5R?= =?utf-8?B?TXljQk9hc25mY040L3d6RDNha0ducGxOLzUrNmNBWkRLeGFnRnpnaXl5M2Fr?= =?utf-8?B?MDFNSU42ODlTWE9rYU4xZW9WSENBNWh1SVBpQ29lbFlyekVaUUtEZiszYm93?= =?utf-8?B?VU9kZi9xdHZRc3N5RmV1bEVGRElKd3RZVDlab1Zqd0diMTZseW1XNTU2VlZn?= =?utf-8?B?ZHorQisrL1FRYW91eDhQbm1TR0ZXckc2SEtlYlRZQnlWS1h3ZWlWVUZrVlVo?= =?utf-8?B?M2hqV053ZVBNOVgrMU10SnNYRlRrTGlJUHRxcWtxS2FKd05QMkMyeFlnSzJo?= =?utf-8?B?MUFwRW96dnN0ZDJZWjBCclRwZ3VWVC9RZStJdE9WUGs3VjJkZzZheFcxcUl4?= =?utf-8?B?T2t5SEN6UWZCWEgzS0Njd0d3dHQ0clFKcExXOFg5YjVWOHdUWmVHc3BSczZw?= =?utf-8?B?RmZKNjRyRWt1OTRsanpJck1XNVRPditXZDZtUGhSZVhGVGc0MUlZcTk2NExP?= =?utf-8?Q?IkQx6wOOaL/qL5LiehnnwxBAdI4XQ6Ib/bUhJmt?= X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: d2a7244b-d82d-4dd4-8d5b-08d9611306ad X-MS-Exchange-CrossTenant-AuthSource: TYAPR01MB5689.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Aug 2021 00:07:39.6305 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: e02030e7-4d45-463e-a968-0290e738c18e X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: BnfzJ4J9LS2Zl5wyn3RU0XnFI+lf9fxE0LVaprqh5b5bdOhDswuJBU2Li9DNlmfMJP0KtyKVRx/omIC1RCc5xQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY2PR01MB4172 Archived-At: Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2021 00:07:59 -0000 Hello everybody, On 2021-08-17 05:52, Brian E Carpenter wrote: >> I’m still slightly concerned that we are over-specifying this in the RFC. > > I'm more than slightly concerned. Obviously there should be a work plan, > and if there isn't, the contract manager (i.e. the LLC) should complain. > Management 101, so why should we bikeshed the details in an RFC? > > Personally I'd remove most of the detailed text quoted below, or rather, > move it to the actual contract between the LLC and the contractor. I would be fine with that. In that case, it's those people's responsibility to make clear how the various parts are related. I think my concern was created because the work program and the RFCs were in the same document. Regards,   Martin. > Regards > Brian > > On 17-Aug-21 00:14, Mirja Kuehlewind wrote: >> Hi Jay, hi all, >> >> Replying to this original mail. The additional text is helpful to better explain what is meant by work program. >> >> I’m still slightly concerned that we are over-specifying this in the RFC. I think the process as described is fine, but writing it down in an RFC means we can't easily change anything in future if we see room or need for optimisation. >> >> However, if other people feel it’s important to have it in this > level of details in this RFC, the text looks fine for me. >> >> Three small comments/questions below. >> >> >>> On 28. Jul 2021, at 00:48, Jay Daley wrote: >>> >>> Eliot asked me to propose some additional text to close off issues #56, #57, #61, #62 which I’ve done below. It doesn’t have the elegance of Peter’s prose so may require some work to align with that. >>> >>> Much of this is already covered in the latest draft at: >>> >>> https://github.com/intarchboard/program-rfced-future/blob/master/draft-iab-rfcefdp-rfced-model.md#roles-and-processes >>> >>> My suggested additions are in red and my suggested text moves are in blue. >>> >>> Jay >>> >>> —— >>> >>> ## Role of the RPC >>> >>> Publication of RFCs shall be continue to be handled by the RFC Production Center (RPC) function in accordance with high-level policies currently in force or yet to be defined following the processes specified in the foregoing sections of this document. >>> >>> ### RPC work program >>> >>> The RPC follows a work program based on requirements it has gathered from a variety of sources, including policies that have been through the RSWG/RSAB process, and from direct discussions with the RSEA, stream managers, IETF LLC, authors and other IETF participants. In developing this work program, the RPC makes some key decisions which impact the IETF community: >>> >>> 1. For each requirement that is gathered, can it be directly incorporated into the work program or must it first be subject to community consultation. >>> >>> 2. Setting the relative priorities for the various requirements within the work program. >>> >>> 3. Determining if all the important requirements have been gathered. >>> >>> It is likely that the RPC will require advice during the drafting of its work program, which it should seek from at least the RSAB and if required, the chairs of the RSWG. >> >> Why are the chairs or the RSWG mentioned here? I guess the RPC is free to ask anybody for advise they want but the main contact point for me would be the RSAB (given it includes the stream managers). >> >>> >>> In order to ensure community oversight of the RPC work program: >>> >>> * The RPC must present a draft work program for community feedback at least annually and then publish a final work program incorporating any agreed feedback. >> >> How and with whom is the feedback agreed? >> >>> >>> * The RPC shall report regularly to the RSAB, RSWG, and broader community regarding the contents and progress of its work program and any key risks or issues affecting it. >> >> How does the RPC report to the broader community. Isn’t it enough to report to RSWG? >> >>> >>> In the event that the RPC is required to make a decision without consultation that would normally deserve consultation, or makes a decision against the advice of the RSAB, then it must notify the RSAB. >>> >>> All matters of budget, timetable and impact on its performance targets, are between the RPC and IETF LLC. >>> >>> ### Relationship between the RPC and the IETF LLC >>> >>> This document does not specify the exact relationship between the IETF > LLC and the RPC function; for example, the RPC function could be provided > by a separate corporate entity under contract to the IETF LLC, it could be performed by employees of the IETF LLC, or the IETF LLC could work with > independent contractors for some or all aspects of the RPC function. The exact relationship is a matter for the IETF LLC and the IETF Executive Director to determine. >>> >>> The IETF LLC has authority over negotiating performance targets for the RPC and also has responsibility for ensuring that those targets are adhered to. The IETF LLC is empowered to appoint a manager or to convene a committee to complete these activities. >>> >>> Community members who have concerns about the performance of the RPC can request that the IETF LLC look into the matter. Even if the IETF LLC opts to delegate this activity, concerns should be raised with the IETF LLC. The IETF LLC is ultimately responsible to the community via the mechanisms outlined in its charter. >>> >>> —— >>> >>> -- >>> Jay Daley >>> IETF Executive Director >>> jay@ietf.org >>> >>> -- >>> Rfced-future mailing list >>> Rfced-future@iab.org >>> https://www.iab.org/mailman/listinfo/rfced-future >> > -- Prof. Dr.sc. Martin J. Dürst Department of Intelligent Information Technology College of Science and Engineering Aoyama Gakuin University Fuchinobe 5-1-10, Chuo-ku, Sagamihara 252-5258 Japan From nobody Mon Aug 16 21:31:43 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC4B43A114D for ; Mon, 16 Aug 2021 21:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 N-zmrD1IVGhA; Mon, 16 Aug 2021 21:31:34 -0700 (PDT) Received: from smtpclient.apple (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id 8CD7A3A0BB9; Mon, 16 Aug 2021 21:31:33 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Jay Daley In-Reply-To: Date: Tue, 17 Aug 2021 16:31:29 +1200 Cc: Mirja Kuehlewind , rfced-future@iab.org, Peter Saint-Andre , Eliot Lear Content-Transfer-Encoding: quoted-printable Message-Id: <173EC03C-E7C8-4965-AABB-49DAF4002F48@ietf.org> References: <9114EB06-AB70-4E6A-A72B-0D7D5867C74A@ietf.org> <538d1ce7-6e4b-fea0-f04b-36669c43dec1@nthpermutation.com> <996b71fc-6ebd-06a1-9a0a-2695a6044381@nthpermutation.com> <4ad09680-b067-4475-9232-e8f69101e7c0@lear.ch> <3295300e-d396-36fc-2137-6452de7f5296@nthpermutation.com> <848d287a-d2e5-7e61-90c4-e3718c010906@gmail.com> <086c5844-ef49-4221-94f2-67408182c6a6@it.aoyama.ac.jp> <3b86de0d-6823-c740-7928-4258a420d990@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2021 04:31:41 -0000 > On 17/08/2021, at 8:52 AM, Brian E Carpenter = wrote: >=20 >> I=E2=80=99m still slightly concerned that we are over-specifying this = in the RFC. >=20 > I'm more than slightly concerned. Obviously there should be a work = plan, > and if there isn't, the contract manager (i.e. the LLC) should = complain. > Management 101, so why should we bikeshed the details in an RFC? >=20 > Personally I'd remove most of the detailed text quoted below, or = rather, > move it to the actual contract between the LLC and the contractor. I think that=E2=80=99s inconsistent with the level of specification in = the rest of this RFC but consistent with others that cover the LLC. If = the group chooses to go that way, then I would suggest that there are = some general requirements set in this document to ensure that someone in = the future doesn=E2=80=99t do away with things the community feels is = important. Some examples: - the RPC/LLC is expected to implement any and all RFCs that come from = the RSWG - the priorities of the RPC must reflect those of the community - the RPC priorities and plans are public and consulted on - no constraints on how the RPC communicates with the community or = vice-versa Jay >=20 > Regards > Brian >=20 > On 17-Aug-21 00:14, Mirja Kuehlewind wrote: >> Hi Jay, hi all, >>=20 >> Replying to this original mail. The additional text is helpful to = better explain what is meant by work program. >>=20 >> I=E2=80=99m still slightly concerned that we are over-specifying this = in the RFC. I think the process as described is fine, but writing it = down in an RFC means we can't easily change anything in future if we see = room or need for optimisation. >>=20 >> However, if other people feel it=E2=80=99s important to have it in = this=20 > level of details in this RFC, the text looks fine for me. >>=20 >> Three small comments/questions below. >>=20 >>=20 >>> On 28. Jul 2021, at 00:48, Jay Daley wrote: >>>=20 >>> Eliot asked me to propose some additional text to close off issues = #56, #57, #61, #62 which I=E2=80=99ve done below. It doesn=E2=80=99t = have the elegance of Peter=E2=80=99s prose so may require some work to = align with that. >>>=20 >>> Much of this is already covered in the latest draft at: >>>=20 >>> = https://github.com/intarchboard/program-rfced-future/blob/master/draft-iab= -rfcefdp-rfced-model.md#roles-and-processes >>>=20 >>> My suggested additions are in red and my suggested text moves are in = blue. =20 >>>=20 >>> Jay >>>=20 >>> =E2=80=94=E2=80=94=20 >>>=20 >>> ## Role of the RPC >>>=20 >>> Publication of RFCs shall be continue to be handled by the RFC = Production Center (RPC) function in accordance with high-level policies = currently in force or yet to be defined following the processes = specified in the foregoing sections of this document. >>>=20 >>> ### RPC work program >>>=20 >>> The RPC follows a work program based on requirements it has gathered = from a variety of sources, including policies that have been through the = RSWG/RSAB process, and from direct discussions with the RSEA, stream = managers, IETF LLC, authors and other IETF participants. In developing = this work program, the RPC makes some key decisions which impact the = IETF community: >>>=20 >>> 1. For each requirement that is gathered, can it be directly = incorporated into the work program or must it first be subject to = community consultation. >>>=20 >>> 2. Setting the relative priorities for the various requirements = within the work program. >>>=20 >>> 3. Determining if all the important requirements have been = gathered. >>>=20 >>> It is likely that the RPC will require advice during the drafting of = its work program, which it should seek from at least the RSAB and if = required, the chairs of the RSWG. >>=20 >> Why are the chairs or the RSWG mentioned here? I guess the RPC is = free to ask anybody for advise they want but the main contact point for = me would be the RSAB (given it includes the stream managers). >>=20 >>>=20 >>> In order to ensure community oversight of the RPC work program: >>>=20 >>> * The RPC must present a draft work program for community feedback = at least annually and then publish a final work program incorporating = any agreed feedback. >>=20 >> How and with whom is the feedback agreed? >>=20 >>>=20 >>> * The RPC shall report regularly to the RSAB, RSWG, and broader = community regarding the contents and progress of its work program and = any key risks or issues affecting it. >>=20 >> How does the RPC report to the broader community. Isn=E2=80=99t it = enough to report to RSWG?=20 >>=20 >>>=20 >>> In the event that the RPC is required to make a decision without = consultation that would normally deserve consultation, or makes a = decision against the advice of the RSAB, then it must notify the RSAB. >>>=20 >>> All matters of budget, timetable and impact on its performance = targets, are between the RPC and IETF LLC. >>>=20 >>> ### Relationship between the RPC and the IETF LLC >>>=20 >>> This document does not specify the exact relationship between the = IETF=20 > LLC and the RPC function; for example, the RPC function could be = provided=20 > by a separate corporate entity under contract to the IETF LLC, it = could be performed by employees of the IETF LLC, or the IETF LLC could = work with=20 > independent contractors for some or all aspects of the RPC function. = The exact relationship is a matter for the IETF LLC and the IETF = Executive Director to determine. >>>=20 >>> The IETF LLC has authority over negotiating performance targets for = the RPC and also has responsibility for ensuring that those targets are = adhered to. The IETF LLC is empowered to appoint a manager or to convene = a committee to complete these activities. >>>=20 >>> Community members who have concerns about the performance of the RPC = can request that the IETF LLC look into the matter. Even if the IETF LLC = opts to delegate this activity, concerns should be raised with the IETF = LLC. The IETF LLC is ultimately responsible to the community via the = mechanisms outlined in its charter. >>>=20 >>> =E2=80=94=E2=80=94=20 >>>=20 >>> --=20 >>> Jay Daley >>> IETF Executive Director >>> jay@ietf.org >>>=20 >>> --=20 >>> Rfced-future mailing list >>> Rfced-future@iab.org >>> https://www.iab.org/mailman/listinfo/rfced-future >>=20 >=20 --=20 Jay Daley IETF Executive Director exec-director@ietf.org From nobody Mon Aug 16 22:02:33 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B80CE3A0AE7 for ; Mon, 16 Aug 2021 22:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 sAKo9D2i_ecr for ; Mon, 16 Aug 2021 22:02:25 -0700 (PDT) Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) (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 336333A0ADB for ; Mon, 16 Aug 2021 22:02:25 -0700 (PDT) Received: by mail-pj1-x1034.google.com with SMTP id mq3so622651pjb.5 for ; Mon, 16 Aug 2021 22:02:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=ynWZAPD9y/HzpflDuN7/Nb5Ai8PgquUCd2BhThXqpPs=; b=nJUqRvazYl1tvxuwXubv9qLUlDihl5o3TQUtcoZXC+mqrn+9/T+KppCZHpxbKREQWR SN4GZ6KjCuNqUjRXDs39UwOzgPuVFP0H8TOH+zz/TIKoaNUvVYTbsW6f6wxtiCrN5M6U 364hWlyBNb0e7RxELdLSBnH83YMiYOcUkFTk7cQVCUkSKEmkf9frf+xPWzG6f/z6Mj+M gQQrxYY+e/rgSjfhx1muqJal1Jc4hd2c8V1838+4aAywdpfWrEpobIZ2j0YZymngGT/V 2yDqOerFs222AzFvmuwaeHo8Y5bP3DOC6ZZ2d+rBJq/5Hpmq7MeYm2buU52gjy/RsmWv wdLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ynWZAPD9y/HzpflDuN7/Nb5Ai8PgquUCd2BhThXqpPs=; b=bCHJX/t5DHrUSUjuQjWOJdAnlEpYxnENaqC1W3xcPvmobMvYKlNZrT4pK5G6y2/fdp A6lsZ6RZCkeQWhWEbhqVXEQn+9EtkH2YO2cQk9XXLplUmsHDmBgB9pv1/LilPzLkuNMx QirXWELS/NdVmhu7QyWKJlKJFGQAqpkNl7O5CJJ0nPcvwDstdczp+V40r9Azbc1f69+I D4knsswlFkdqPTBlAgbVklns4Zseex4DGeRwe+wpLA5YxailiqJVnvbmO5cONzIyYW9w VdQf8i3ik9PtjBTkXn9mGW05j06gXT/Z83XgPLo2QDnU06YYOVFuASowuqvrYhThMm38 pLLw== X-Gm-Message-State: AOAM531q40gjXGJJdTeBHNHa3VqK4i5ldQTAKQ9JeZ3Gjg+Xk2GeByJG 1AC+hI/TF/U7XcBmoITChlI= X-Google-Smtp-Source: ABdhPJzQazOumuocMfSiFKaxCGGcFywagZLTrvLLK1Gj08sdQRdtmSEGa93nVGOQBKfIe8dZ/D9Mqg== X-Received: by 2002:a65:410a:: with SMTP id w10mr1716186pgp.343.1629176543360; Mon, 16 Aug 2021 22:02:23 -0700 (PDT) Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id v63sm1044299pgv.59.2021.08.16.22.02.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 16 Aug 2021 22:02:22 -0700 (PDT) To: Jay Daley Cc: Mirja Kuehlewind , rfced-future@iab.org, Peter Saint-Andre , Eliot Lear References: <996b71fc-6ebd-06a1-9a0a-2695a6044381@nthpermutation.com> <4ad09680-b067-4475-9232-e8f69101e7c0@lear.ch> <3295300e-d396-36fc-2137-6452de7f5296@nthpermutation.com> <848d287a-d2e5-7e61-90c4-e3718c010906@gmail.com> <086c5844-ef49-4221-94f2-67408182c6a6@it.aoyama.ac.jp> <3b86de0d-6823-c740-7928-4258a420d990@gmail.com> <173EC03C-E7C8-4965-AABB-49DAF4002F48@ietf.org> From: Brian E Carpenter Message-ID: <671a516f-2f77-75aa-dad4-2c4037264f05@gmail.com> Date: Tue, 17 Aug 2021 17:02:18 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <173EC03C-E7C8-4965-AABB-49DAF4002F48@ietf.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2021 05:02:32 -0000 On 17-Aug-21 16:31, Jay Daley wrote: >=20 >=20 >> On 17/08/2021, at 8:52 AM, Brian E Carpenter wrote: >> >>> I=E2=80=99m still slightly concerned that we are over-specifying this=20 in the RFC. >> >> I'm more than slightly concerned. Obviously there should be a work pla= n, >> and if there isn't, the contract manager (i.e. the LLC) should complai= n. >> Management 101, so why should we bikeshed the details in an RFC? >> >> Personally I'd remove most of the detailed text quoted below, or rathe= r, >> move it to the actual contract between the LLC and the contractor. >=20 > I think that=E2=80=99s inconsistent with the level of specification in = the rest of this RFC but consistent with others that cover the LLC. If t= he group chooses to go that way, then I would suggest that there are some=20 general requirements set in this document to ensure that someone in the f= uture doesn=E2=80=99t do away with things the community feels is importan= t. >=20 > Some examples: >=20 > - the RPC/LLC is expected to implement any and all RFCs that come from = the RSWG > - the priorities of the RPC must reflect those of the community > - the RPC priorities and plans are public and consulted on > - no constraints on how the RPC communicates with the community or vice= -versa Yes. I think in general we should be asserting general principles like th= at (and perhaps we need a critical pass over the next version of the draft, looking for any cases where we are micro-managing by RFC.) Rgds Brian >=20 > Jay >=20 >> >> Regards >> Brian >> >> On 17-Aug-21 00:14, Mirja Kuehlewind wrote: >>> Hi Jay, hi all, >>> >>> Replying to this original mail. The additional text is helpful to bet= ter explain what is meant by work program. >>> >>> I=E2=80=99m still slightly concerned that we are over-specifying this=20 in the RFC. I think the process as described is fine, but writing it down=20 in an RFC means we can't easily change anything in future if we see room = or need for optimisation. >>> >>> However, if other people feel it=E2=80=99s important to have it in th= is=20 >> level of details in this RFC, the text looks fine for me. >>> >>> Three small comments/questions below. >>> >>> >>>> On 28. Jul 2021, at 00:48, Jay Daley wrote: >>>> >>>> Eliot asked me to propose some additional text to close off issues #= 56, #57, #61, #62 which I=E2=80=99ve done below. It doesn=E2=80=99t have=20 the elegance of Peter=E2=80=99s prose so may require some work to align w= ith that. >>>> >>>> Much of this is already covered in the latest draft at: >>>> >>>> https://github.com/intarchboard/program-rfced-future/blob/master/dr= aft-iab-rfcefdp-rfced-model.md#roles-and-processes >>>> >>>> My suggested additions are in red and my suggested text moves are in=20 blue. =20 >>>> >>>> Jay >>>> >>>> =E2=80=94=E2=80=94=20 >>>> >>>> ## Role of the RPC >>>> >>>> Publication of RFCs shall be continue to be handled by the RFC Produ= ction Center (RPC) function in accordance with high-level policies curren= tly in force or yet to be defined following the processes specified in th= e foregoing sections of this document. >>>> >>>> ### RPC work program >>>> >>>> The RPC follows a work program based on requirements it has gathered=20 from a variety of sources, including policies that have been through the = RSWG/RSAB process, and from direct discussions with the RSEA, stream mana= gers, IETF LLC, authors and other IETF participants. In developing this = work program, the RPC makes some key decisions which impact the IETF comm= unity: >>>> >>>> 1. For each requirement that is gathered, can it be directly incorp= orated into the work program or must it first be subject to community con= sultation. >>>> >>>> 2. Setting the relative priorities for the various requirements wit= hin the work program. >>>> >>>> 3. Determining if all the important requirements have been gathered= =2E >>>> >>>> It is likely that the RPC will require advice during the drafting of=20 its work program, which it should seek from at least the RSAB and if requ= ired, the chairs of the RSWG. >>> >>> Why are the chairs or the RSWG mentioned here? I guess the RPC is fre= e to ask anybody for advise they want but the main contact point for me w= ould be the RSAB (given it includes the stream managers). >>> >>>> >>>> In order to ensure community oversight of the RPC work program: >>>> >>>> * The RPC must present a draft work program for community feedback a= t least annually and then publish a final work program incorporating any = agreed feedback. >>> >>> How and with whom is the feedback agreed? >>> >>>> >>>> * The RPC shall report regularly to the RSAB, RSWG, and broader comm= unity regarding the contents and progress of its work program and any key=20 risks or issues affecting it. >>> >>> How does the RPC report to the broader community. Isn=E2=80=99t it en= ough to report to RSWG?=20 >>> >>>> >>>> In the event that the RPC is required to make a decision without con= sultation that would normally deserve consultation, or makes a decision a= gainst the advice of the RSAB, then it must notify the RSAB. >>>> >>>> All matters of budget, timetable and impact on its performance targe= ts, are between the RPC and IETF LLC. >>>> >>>> ### Relationship between the RPC and the IETF LLC >>>> >>>> This document does not specify the exact relationship between the IE= TF=20 >> LLC and the RPC function; for example, the RPC function could be provi= ded=20 >> by a separate corporate entity under contract to the IETF LLC, it coul= d be performed by employees of the IETF LLC, or the IETF LLC could work w= ith=20 >> independent contractors for some or all aspects of the RPC function. T= he exact relationship is a matter for the IETF LLC and the IETF Executive=20 Director to determine. >>>> >>>> The IETF LLC has authority over negotiating performance targets for = the RPC and also has responsibility for ensuring that those targets are a= dhered to. The IETF LLC is empowered to appoint a manager or to convene a=20 committee to complete these activities. >>>> >>>> Community members who have concerns about the performance of the RPC=20 can request that the IETF LLC look into the matter. Even if the IETF LLC = opts to delegate this activity, concerns should be raised with the IETF L= LC. The IETF LLC is ultimately responsible to the community via the mecha= nisms outlined in its charter. >>>> >>>> =E2=80=94=E2=80=94=20 >>>> >>>> --=20 >>>> Jay Daley >>>> IETF Executive Director >>>> jay@ietf.org >>>> >>>> --=20 >>>> Rfced-future mailing list >>>> Rfced-future@iab.org >>>> https://www.iab.org/mailman/listinfo/rfced-future >>> >> >=20 From nobody Mon Aug 16 23:11:07 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BFAA3A1766 for ; Mon, 16 Aug 2021 23:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=zg61Mc+o; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nWSBDYCh 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 vEg9y3EBM9pi for ; Mon, 16 Aug 2021 23:10:58 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 935203A1763 for ; Mon, 16 Aug 2021 23:10:58 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 9ABDF320005D; Tue, 17 Aug 2021 02:10:54 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Tue, 17 Aug 2021 02:10:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=p u8ylhuCl3sxQbmJQGhyzLnld3VUfPtKZcj24yMQ5nA=; b=zg61Mc+o902LtF5VR bqeghS4u1rsSuEt6tc/jnOcww0PhF2jtu+Cye31A3rIRKskhB6K5ap0dPEN0RVLD HPnBRaKo3xc5iOwx9CayfC8YJ7qS4UXQiXQcmmNPbDerUns23/Mz/BWE8Phcr2Lb u/9j4mbK2NLPjtd7t5Zg4TpFmgRMbw3mcsbW4vqMsY8RxCny6RAPxRk3sC/dlF/a PYtWPbrvnSDr/A6oD7CiV0mv5E+zCIkeH/xWmuTKBZ9ulizGARQ1MSbp3kfYtTU2 Potp01ZeKP+oSUpw6HFxV3NYeUll9iRorh9/1bnbS9PYB7bJFIiTv5rOY1dA1P+N J2pgQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=pu8ylhuCl3sxQbmJQGhyzLnld3VUfPtKZcj24yMQ5 nA=; b=nWSBDYChpAwUhcuwmJZ7/6UXPvWgtwXPoneD8FjW1WlyvmOp8L3mMxWaO hvb5LekKsGFkqsGGsqev5JRIjX+y4Bjo8hbEcQc6Df2x2jQLTZ2/49eWMVwu039q I+s0ojG7TlQFfsNTr1PWEd7ZULWviJmWMYKswoXhk2eURr6lP2gMZaw9Ni3sGOpn N3+VSG1QAagdqe/bCLx6WN47BdFbx6pwjNkws00jlQ2oY7Oetj1tzsf5WdkCkDnz c5AYr7Oa85KdYmPRkIlLCRqDPrxOKeGyRaH2n+SC/oS+HZFP2Xwd5rvdgIBUlxoR fQ9hJWPDCyoIh4bNsnPq73NRSDiWw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrledvgddutddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfuhfgjfffgkfhfvffosehtqh hmtdhhtddvnecuhfhrohhmpeforghrkhcupfhothhtihhnghhhrghmuceomhhnohhtsehm nhhothdrnhgvtheqnecuggftrfgrthhtvghrnhepvefffffhudetveevhfeuffeigedtue dtheffleetffeftddtgeegjeehieeuteetnecuffhomhgrihhnpehmnhhothdrnhgvthen ucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhoth esmhhnohhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 17 Aug 2021 02:10:52 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Mark Nottingham In-Reply-To: <4338a0bb-32f3-9b92-5ed6-1be5ac3c0b86@nthpermutation.com> Date: Tue, 17 Aug 2021 16:10:51 +1000 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <4338a0bb-32f3-9b92-5ed6-1be5ac3c0b86@nthpermutation.com> To: Michael StJohns X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [Rfced-future] Issue 71: Term limits for RSAB chairs? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2021 06:11:06 -0000 Hi Michael, > On 16 Aug 2021, at 11:30 am, Michael StJohns = wrote: >=20 > The RSAB chair duties shall rotate annually between each of its = members in the following order: IAB, RSCE, IESG, IRTF, ISE. That order = was chosen to mirror the historical order of creation of the appointing = organizations. The RSAB may choose to follow a strict annual rotation, = or may adjust the term to coincide with the end of a specific IETF = meeting similar to the terms of the IAB and IESG. Hmm. It strikes me that doing it this way might complicate the selection = process for the various bodies. Finding someone who's willing to head up = a stream and serve on the RSAB is different from finding someone who can = do those _and_ take on extra chairing duties -- especially if they might = occur down the track a bit, and especially if the candidates have other = commitments coming and going as well. -- Mark Nottingham https://www.mnot.net/ From nobody Tue Aug 17 00:58:26 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8444D3A086C; Tue, 17 Aug 2021 00:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 r5cJcdKDVXhI; Tue, 17 Aug 2021 00:58:18 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BE6E3A0869; Tue, 17 Aug 2021 00:58:18 -0700 (PDT) Received: from p200300dee73ba500ac7bc2501316418e.dip0.t-ipconnect.de ([2003:de:e73b:a500:ac7b:c250:1316:418e]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1mFtz9-0002pg-0U; Tue, 17 Aug 2021 09:58:11 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Mirja Kuehlewind In-Reply-To: <173EC03C-E7C8-4965-AABB-49DAF4002F48@ietf.org> Date: Tue, 17 Aug 2021 09:58:09 +0200 Cc: Brian E Carpenter , rfced-future@iab.org, Eliot Lear , Peter Saint-Andre Content-Transfer-Encoding: quoted-printable Message-Id: References: <9114EB06-AB70-4E6A-A72B-0D7D5867C74A@ietf.org> <538d1ce7-6e4b-fea0-f04b-36669c43dec1@nthpermutation.com> <996b71fc-6ebd-06a1-9a0a-2695a6044381@nthpermutation.com> <4ad09680-b067-4475-9232-e8f69101e7c0@lear.ch> <3295300e-d396-36fc-2137-6452de7f5296@nthpermutation.com> <848d287a-d2e5-7e61-90c4-e3718c010906@gmail.com> <086c5844-ef49-4221-94f2-67408182c6a6@it.aoyama.ac.jp> <3b86de0d-6823-c740-7928-4258a420d990@gmail.com> <173EC03C-E7C8-4965-AABB-49DAF4002F48@ietf.org> To: Jay Daley X-Mailer: Apple Mail (2.3608.120.23.2.4) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1629187098;bbe8cbcd; X-HE-SMSGID: 1mFtz9-0002pg-0U Archived-At: Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2021 07:58:25 -0000 That sounds good to me. > On 17. Aug 2021, at 06:31, Jay Daley wrote: >=20 >=20 >=20 >> On 17/08/2021, at 8:52 AM, Brian E Carpenter = wrote: >>=20 >>> I=E2=80=99m still slightly concerned that we are over-specifying = this in the RFC. >>=20 >> I'm more than slightly concerned. Obviously there should be a work = plan, >> and if there isn't, the contract manager (i.e. the LLC) should = complain. >> Management 101, so why should we bikeshed the details in an RFC? >>=20 >> Personally I'd remove most of the detailed text quoted below, or = rather, >> move it to the actual contract between the LLC and the contractor. >=20 > I think that=E2=80=99s inconsistent with the level of specification in = the rest of this RFC but consistent with others that cover the LLC. If = the group chooses to go that way, then I would suggest that there are = some general requirements set in this document to ensure that someone in = the future doesn=E2=80=99t do away with things the community feels is = important. >=20 > Some examples: >=20 > - the RPC/LLC is expected to implement any and all RFCs that come from = the RSWG > - the priorities of the RPC must reflect those of the community > - the RPC priorities and plans are public and consulted on > - no constraints on how the RPC communicates with the community or = vice-versa >=20 > Jay >=20 >>=20 >> Regards >> Brian >>=20 >> On 17-Aug-21 00:14, Mirja Kuehlewind wrote: >>> Hi Jay, hi all, >>>=20 >>> Replying to this original mail. The additional text is helpful to = better explain what is meant by work program. >>>=20 >>> I=E2=80=99m still slightly concerned that we are over-specifying = this in the RFC. I think the process as described is fine, but writing = it down in an RFC means we can't easily change anything in future if we = see room or need for optimisation. >>>=20 >>> However, if other people feel it=E2=80=99s important to have it in = this=20 >> level of details in this RFC, the text looks fine for me. >>>=20 >>> Three small comments/questions below. >>>=20 >>>=20 >>>> On 28. Jul 2021, at 00:48, Jay Daley wrote: >>>>=20 >>>> Eliot asked me to propose some additional text to close off issues = #56, #57, #61, #62 which I=E2=80=99ve done below. It doesn=E2=80=99t = have the elegance of Peter=E2=80=99s prose so may require some work to = align with that. >>>>=20 >>>> Much of this is already covered in the latest draft at: >>>>=20 >>>> = https://github.com/intarchboard/program-rfced-future/blob/master/draft-iab= -rfcefdp-rfced-model.md#roles-and-processes >>>>=20 >>>> My suggested additions are in red and my suggested text moves are = in blue. =20 >>>>=20 >>>> Jay >>>>=20 >>>> =E2=80=94=E2=80=94=20 >>>>=20 >>>> ## Role of the RPC >>>>=20 >>>> Publication of RFCs shall be continue to be handled by the RFC = Production Center (RPC) function in accordance with high-level policies = currently in force or yet to be defined following the processes = specified in the foregoing sections of this document. >>>>=20 >>>> ### RPC work program >>>>=20 >>>> The RPC follows a work program based on requirements it has = gathered from a variety of sources, including policies that have been = through the RSWG/RSAB process, and from direct discussions with the = RSEA, stream managers, IETF LLC, authors and other IETF participants. = In developing this work program, the RPC makes some key decisions which = impact the IETF community: >>>>=20 >>>> 1. For each requirement that is gathered, can it be directly = incorporated into the work program or must it first be subject to = community consultation. >>>>=20 >>>> 2. Setting the relative priorities for the various requirements = within the work program. >>>>=20 >>>> 3. Determining if all the important requirements have been = gathered. >>>>=20 >>>> It is likely that the RPC will require advice during the drafting = of its work program, which it should seek from at least the RSAB and if = required, the chairs of the RSWG. >>>=20 >>> Why are the chairs or the RSWG mentioned here? I guess the RPC is = free to ask anybody for advise they want but the main contact point for = me would be the RSAB (given it includes the stream managers). >>>=20 >>>>=20 >>>> In order to ensure community oversight of the RPC work program: >>>>=20 >>>> * The RPC must present a draft work program for community feedback = at least annually and then publish a final work program incorporating = any agreed feedback. >>>=20 >>> How and with whom is the feedback agreed? >>>=20 >>>>=20 >>>> * The RPC shall report regularly to the RSAB, RSWG, and broader = community regarding the contents and progress of its work program and = any key risks or issues affecting it. >>>=20 >>> How does the RPC report to the broader community. Isn=E2=80=99t it = enough to report to RSWG?=20 >>>=20 >>>>=20 >>>> In the event that the RPC is required to make a decision without = consultation that would normally deserve consultation, or makes a = decision against the advice of the RSAB, then it must notify the RSAB. >>>>=20 >>>> All matters of budget, timetable and impact on its performance = targets, are between the RPC and IETF LLC. >>>>=20 >>>> ### Relationship between the RPC and the IETF LLC >>>>=20 >>>> This document does not specify the exact relationship between the = IETF=20 >> LLC and the RPC function; for example, the RPC function could be = provided=20 >> by a separate corporate entity under contract to the IETF LLC, it = could be performed by employees of the IETF LLC, or the IETF LLC could = work with=20 >> independent contractors for some or all aspects of the RPC function. = The exact relationship is a matter for the IETF LLC and the IETF = Executive Director to determine. >>>>=20 >>>> The IETF LLC has authority over negotiating performance targets for = the RPC and also has responsibility for ensuring that those targets are = adhered to. The IETF LLC is empowered to appoint a manager or to convene = a committee to complete these activities. >>>>=20 >>>> Community members who have concerns about the performance of the = RPC can request that the IETF LLC look into the matter. Even if the IETF = LLC opts to delegate this activity, concerns should be raised with the = IETF LLC. The IETF LLC is ultimately responsible to the community via = the mechanisms outlined in its charter. >>>>=20 >>>> =E2=80=94=E2=80=94=20 >>>>=20 >>>> --=20 >>>> Jay Daley >>>> IETF Executive Director >>>> jay@ietf.org >>>>=20 >>>> --=20 >>>> Rfced-future mailing list >>>> Rfced-future@iab.org >>>> https://www.iab.org/mailman/listinfo/rfced-future >>>=20 >>=20 >=20 > --=20 > Jay Daley > IETF Executive Director > exec-director@ietf.org >=20 >=20 >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future From nobody Tue Aug 17 10:10:24 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11D2D3A22EC for ; Tue, 17 Aug 2021 10:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.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 Nbt9q9KH5rut for ; Tue, 17 Aug 2021 10:10:16 -0700 (PDT) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (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 D91583A22E9 for ; Tue, 17 Aug 2021 10:10:15 -0700 (PDT) Received: by mail-qt1-x836.google.com with SMTP id e15so17764067qtx.1 for ; Tue, 17 Aug 2021 10:10:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=TVzSFlX9AWrcJNInFG8QYZTwxFtVr0EpH1DZQGXSvWE=; b=bP2X+6URjXsE9Th8keZBZ7OuKHz73b3GGB94xOhmS2vp4VhD6H2aqi1KaUnNPUBPCs cT6tD5FD8l/jdUBnCj2Y+QT6aOFY6zOobwGrNWjB77p0yaefjg6coavGr3Jyn3Es0/Nl ciiFHc0ywPQIPvrJpHSNh8o8wpL3DLDLqXgJVm8WO6qHsNsWJzpVc/1VwQ5l4gqGBJGn Oa3VMmuUsd3nkGEsk1GjkgarWuJUgM/Ek2CVp7K+x2htIAFJSG+4ObIY3jLXB0IzLf1Y k45m1NJ08IKuQmdWvPNS5uoOkHd2FCSPZ55xqWLJ6iJ1iH+hJXtp4BQWbIY9VVEDMqYw zSrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=TVzSFlX9AWrcJNInFG8QYZTwxFtVr0EpH1DZQGXSvWE=; b=SLLQlE+uonsjvnybktF0kf6nA/J8YDHmb23PkhbalGaarvUpgHMOzzySzCm5hL4EqU Ow5yTJehJOU+xGN1YmiHFCuNcZWIHoOcVoOvLLq6lqNMKvhRxQ2gWZX1/qKOazHrJIJi efTT6xBpacPOFDvDA6eSD+8nd6XP16RrcbRVKrKBnrvDhUP9FFj5Q/iqlDbZabDw8uVz /yGFfooIgfUsYILyBZNGueb663bfmM0tohmTx0UKFZeJ9WRNAD9l1QlLc1FSiGfrVdjX 9dCMW/txK8cdXQ799B+P2iE6PIbayPEHMt0RR+jcVFDlqcduKa1idx/kxDpms2kXA0i3 Nl1g== X-Gm-Message-State: AOAM5325V/m2TZpMW83jVqCC1q/q70t/Upy7LSdF556P+wk334dgr6MR zuSDPu2Ff4akAjTFurEMCRf5WLf70TcRcz8p X-Google-Smtp-Source: ABdhPJxhpYnuUNxkdyPgPcxXIry3krkLvTMJT+bgY7uwGf2aCchDgKCd7T0iSp+uVrAhlUPRPYoiaw== X-Received: by 2002:ac8:668a:: with SMTP id d10mr4194848qtp.145.1629220213078; Tue, 17 Aug 2021 10:10:13 -0700 (PDT) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id y26sm1733587qkm.65.2021.08.17.10.10.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 17 Aug 2021 10:10:12 -0700 (PDT) To: Mark Nottingham Cc: rfced-future@iab.org References: <4338a0bb-32f3-9b92-5ed6-1be5ac3c0b86@nthpermutation.com> From: Michael StJohns Message-ID: Date: Tue, 17 Aug 2021 13:10:10 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Issue 71: Term limits for RSAB chairs? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2021 17:10:22 -0000 On 8/17/2021 2:10 AM, Mark Nottingham wrote: > Hi Michael, > >> On 16 Aug 2021, at 11:30 am, Michael StJohns wrote: >> >> The RSAB chair duties shall rotate annually between each of its members in the following order: IAB, RSCE, IESG, IRTF, ISE. That order was chosen to mirror the historical order of creation of the appointing organizations. The RSAB may choose to follow a strict annual rotation, or may adjust the term to coincide with the end of a specific IETF meeting similar to the terms of the IAB and IESG. > Hmm. It strikes me that doing it this way might complicate the selection process for the various bodies. Finding someone who's willing to head up a stream and serve on the RSAB is different from finding someone who can do those _and_ take on extra chairing duties -- especially if they might occur down the track a bit, and especially if the candidates have other commitments coming and going as well. > > > -- > Mark Nottingham https://www.mnot.net/ > So you'd rather have the various members of the RSAB play "not me" on an annual basis, with the probable result that the IAB and IRTF members will end up handing the position back and forth?  (I base this on your statement above that it might be difficult to find willing members and the following probable arguments:  RSCE - I'm not paid to do this - add it to my task order first; ISE - I'm only one person and a volunteer at that, find someone else; IESG - I've got 20 WGs to oversee, I don't have the time to chair).   I don't find this all that palatable. Of those, I actually have sympathy with the ISE's argument and would add "The ISE at its discretion may pass on its opportunity to chair with the chair position rotating to the representative from the next organization in line." So once every 4-5 years one of these groups has to find someone to do a bit of administrivia?  If it's that much of a problem, how about we go back to my first suggestion and set up the RSCE as the permanent chair? If we pay the RSCE for the role, that would render moot your comments above.  And, as I've noted a few times, the chair position has some responsibility, but almost no authority. Later, Mike From nobody Tue Aug 17 10:58:10 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBE463A24E7 for ; Tue, 17 Aug 2021 10:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 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, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch 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 zZxnqyK4UXHO for ; Tue, 17 Aug 2021 10:58:01 -0700 (PDT) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27D463A24CC for ; Tue, 17 Aug 2021 10:57:58 -0700 (PDT) Received: from [IPv6:2001:420:c0c0:1011::2] ([IPv6:2001:420:c0c0:1011:0:0:0:2]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 17HHvsAB030583 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Tue, 17 Aug 2021 19:57:55 +0200 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1629223075; bh=J4pMwPmdrOEBZ8mlPNDBnrKPAmfWsBPGdDORk/ovOhM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=QhKnQzpVTa+qlMm+2+EuPDfgpDBOqN6q+lm8FfzXOrUE0YLIkenAe2hZZj0250WGI gZH8LJRqfY/5khivfrVM4KYACsC8E12lJuGsWhLOHNcKbKx0kyoxngeYkQ9nMxgOdA /kVWh2lyVFriuWNm2PvMDKnEBNf9e0jNLpRJdeCg= To: Michael StJohns Cc: rfced-future@iab.org References: <4338a0bb-32f3-9b92-5ed6-1be5ac3c0b86@nthpermutation.com> From: Eliot Lear Message-ID: Date: Tue, 17 Aug 2021 19:57:51 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="l0OO008d7qnMC6jpCG0sYAmMyIougtjID" Archived-At: Subject: Re: [Rfced-future] Issue 71: Term limits for RSAB chairs? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2021 17:58:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --l0OO008d7qnMC6jpCG0sYAmMyIougtjID Content-Type: multipart/mixed; boundary="IbQWntYPNtZvjBblza9eR5ydOgr9vCOmq"; protected-headers="v1" From: Eliot Lear To: Michael StJohns Cc: rfced-future@iab.org Message-ID: Subject: Re: [Rfced-future] Issue 71: Term limits for RSAB chairs? References: <4338a0bb-32f3-9b92-5ed6-1be5ac3c0b86@nthpermutation.com> In-Reply-To: --IbQWntYPNtZvjBblza9eR5ydOgr9vCOmq Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Mike, just to boil things down a bit, I'm going to ask the obvious Eliot = question: Can you distill down what you think MUST be in the draft now and what=20 might wait for some operational experience?=C2=A0 That is to say, in your= =20 opinion, does the community have the option to add this sort of rotation = scheme in later if the situation seems to warrant? More generally, should we create perhaps a bit of a checklist of things=20 we decided not to decide so that those items get some attention just to=20 see that things haven't broken? Eliot On 17.08.21 19:10, Michael StJohns wrote: > On 8/17/2021 2:10 AM, Mark Nottingham wrote: >> Hi Michael, >> >>> On 16 Aug 2021, at 11:30 am, Michael StJohns=20 >>> wrote: >>> >>> The RSAB chair duties shall rotate annually between each of its=20 >>> members in the following order: IAB, RSCE, IESG, IRTF, ISE.=C2=A0 Tha= t=20 >>> order was chosen to mirror the historical order of creation of the=20 >>> appointing organizations.=C2=A0=C2=A0 The RSAB may choose to follow a= strict=20 >>> annual rotation, or may adjust the term to coincide with the end of=20 >>> a specific IETF meeting similar to the terms of the IAB and IESG. >> Hmm. It strikes me that doing it this way might complicate the=20 >> selection process for the various bodies. Finding someone who's=20 >> willing to head up a stream and serve on the RSAB is different from=20 >> finding someone who can do those _and_ take on extra chairing duties=20 >> -- especially if they might occur down the track a bit, and=20 >> especially if the candidates have other commitments coming and going=20 >> as well. >> >> >> --=20 >> Mark Nottingham=C2=A0=C2=A0 https://www.mnot.net/ >> > > So you'd rather have the various members of the RSAB play "not me" on=20 > an annual basis, with the probable result that the IAB and IRTF=20 > members will end up handing the position back and forth?=C2=A0 (I base = this=20 > on your statement above that it might be difficult to find willing=20 > members and the following probable arguments:=C2=A0 RSCE - I'm not paid= to=20 > do this - add it to my task order first; ISE - I'm only one person and = > a volunteer at that, find someone else; IESG - I've got 20 WGs to=20 > oversee, I don't have the time to chair).=C2=A0=C2=A0 I don't find this= all that=20 > palatable. > > Of those, I actually have sympathy with the ISE's argument and would=20 > add "The ISE at its discretion may pass on its opportunity to chair=20 > with the chair position rotating to the representative from the next=20 > organization in line." > > So once every 4-5 years one of these groups has to find someone to do=20 > a bit of administrivia?=C2=A0 If it's that much of a problem, how about= we=20 > go back to my first suggestion and set up the RSCE as the permanent=20 > chair? > > If we pay the RSCE for the role, that would render moot your comments=20 > above.=C2=A0 And, as I've noted a few times, the chair position has som= e=20 > responsibility, but almost no authority. > > Later, Mike > > > > --IbQWntYPNtZvjBblza9eR5ydOgr9vCOmq-- --l0OO008d7qnMC6jpCG0sYAmMyIougtjID Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmEb+J8FAwAAAAAACgkQh7ZrRtnSejNX kgf+N+NMy5XG6ayY0AxVUSRM3vJei3xYkTCEYDze41dKWQZ8o461cgMKjlxtbXkj8xSYufLn+yw7 YDBL8KQ6dXmh5fdvxEGFdkjQ/C8Taa6FaVsez/XbZvepVAxINAeE9xgescPf598NmT0SamrNkPJS IYk9bvvBehxY34VxVg9BC9Jcnr9VXlPK5BfHcLph6Siy94RwD4IXg/DrkR2xqxa8lKphrV6iAM3n R1GonFkYD5JrBAjz3WuiFGdwr991Ae55r2yhchkQFxVF3zvbI1omN5p5J/tU+qcdbRMicP/VVq3W pjreGc+SsbxjC5+V38JjkI99bAK5OPGURTNjYC7BDA== =QMAJ -----END PGP SIGNATURE----- --l0OO008d7qnMC6jpCG0sYAmMyIougtjID-- From nobody Tue Aug 17 11:56:02 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB36F3A2AE5 for ; Tue, 17 Aug 2021 11:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.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 3ijDb_yYvLeN for ; Tue, 17 Aug 2021 11:55:52 -0700 (PDT) Received: from mail-qv1-xf31.google.com (mail-qv1-xf31.google.com [IPv6:2607:f8b0:4864:20::f31]) (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 B4C863A2AE2 for ; Tue, 17 Aug 2021 11:55:52 -0700 (PDT) Received: by mail-qv1-xf31.google.com with SMTP id j9so240998qvt.4 for ; Tue, 17 Aug 2021 11:55:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=unPJwh/xN+xv+ZDvb+JjMBMH1gxc4o70AHfQmp+bL9s=; b=G4TvDOowp5x8nXd0197+OWRnOtsImxI9hYIEELvXK09FgLOfsdzeXRx9lKED49KAsM 3aTr78ekF/PERwffcpVdHWQAcdwHBR8p19TAM9BDDuoWMizQnBBlZtZ5PNUl5/c5N5sD 47b0yA9rkmfGS3wdKw5J6E+kCMlqdBHbcK9Qi0Ky6I6cKrXNIRgMuDKJMYH3Kn4Rnn23 bQCuB4adEurXg4OTED8Wghe29rw+bctibNHy8wBeXM8Qsv7UTHzSzJ14WId5A2ScjWGe oKcnLBL4YFN8ORj7xGMC7lb+0lSmFqnAHDQAPD9p0d6r/J5OB+ugWXea3wQjoLc5fots ADdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=unPJwh/xN+xv+ZDvb+JjMBMH1gxc4o70AHfQmp+bL9s=; b=ROcysXAUA6F1Wuzfm/Hew+J3qlIEJz0OuOYLNdAi82LjvUZQ0NuX9YH7Wj9A69FY2z cZp905f1BqKhX18Fal4zv4RzHr2GOWAGXgKQnqz/roZl93HqRUJzBP4tBacwK83VqaiV HkzVRgZnF9fUJnqjNSj+Yh3kww+MB+5vgej1JdezkM24CYMtFmQLpIlEVhbPKvFxaldE 9KJxFxGDp6FcopGOzA4yM3Jl9tYbjWyiC1s6iz35DrO+ORUqO7tlZHYAL48Wf2IVRW2Y PfCjfj5WlnOvhMesHVDuFiVt+WPw01/+UdbVlrzp/NtcwU2o6rWT+CnqvvxCbMiEPn7W HiGw== X-Gm-Message-State: AOAM5336T82fNyYA0/PVRWNxZEnv/lvo1/jp+vZ31oPBWq6vKkd42qGt gdKOzAQCoN4cEthGOC907bXS06wXTcfrSqz5 X-Google-Smtp-Source: ABdhPJzvXwiNoP3+kXsNs2HTmHWxErAXQv4xQjjXOYo6lo/fyRRO85ppY2+jGv7NpY5SZwdDzs6UyQ== X-Received: by 2002:a0c:8525:: with SMTP id n34mr4844081qva.19.1629226549162; Tue, 17 Aug 2021 11:55:49 -0700 (PDT) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id n189sm2006548qka.69.2021.08.17.11.55.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 17 Aug 2021 11:55:48 -0700 (PDT) To: Eliot Lear Cc: rfced-future@iab.org References: <4338a0bb-32f3-9b92-5ed6-1be5ac3c0b86@nthpermutation.com> From: Michael StJohns Message-ID: <8bcab165-0de0-0820-c916-7ef12cd30d85@nthpermutation.com> Date: Tue, 17 Aug 2021 14:55:46 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Issue 71: Term limits for RSAB chairs? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2021 18:55:59 -0000 On 8/17/2021 1:57 PM, Eliot Lear wrote: > Mike, just to boil things down a bit, I'm going to ask the obvious > Eliot question: > > Can you distill down what you think MUST be in the draft now and what > might wait for some operational experience?  That is to say, in your > opinion, does the community have the option to add this sort of > rotation scheme in later if the situation seems to warrant? If this is going to require the RSCE to perform chair duties at any time, that needs to be included so the LLC can budget for it and include it in the contract.     That's the mandatory part. But!  Mark has already indicated that he feels the job will not be desirable and that various orgs will resist taking a turn as chair.  I think as part of giving them a voice on the RSAB (authority...) we need to bind that to whatever responsibilities also come from those positions.  So, yes, I think this needs to be specified in a manner that either a) requires everyone to take a turn, or b) pays the RSCE to do the administrivia of the chair job.  I don't think that should be deferred. Note that I also suggested that the RSAB include non-ex officio members appointed by the Nomcom and that had we done that, sticking one of them with the chair job would moot the whole "its too much work" argument that Mark made. Later, Mike > > More generally, should we create perhaps a bit of a checklist of > things we decided not to decide so that those items get some attention > just to see that things haven't broken? > > Eliot > > On 17.08.21 19:10, Michael StJohns wrote: >> On 8/17/2021 2:10 AM, Mark Nottingham wrote: >>> Hi Michael, >>> >>>> On 16 Aug 2021, at 11:30 am, Michael StJohns >>>> wrote: >>>> >>>> The RSAB chair duties shall rotate annually between each of its >>>> members in the following order: IAB, RSCE, IESG, IRTF, ISE.  That >>>> order was chosen to mirror the historical order of creation of the >>>> appointing organizations.   The RSAB may choose to follow a strict >>>> annual rotation, or may adjust the term to coincide with the end of >>>> a specific IETF meeting similar to the terms of the IAB and IESG. >>> Hmm. It strikes me that doing it this way might complicate the >>> selection process for the various bodies. Finding someone who's >>> willing to head up a stream and serve on the RSAB is different from >>> finding someone who can do those _and_ take on extra chairing duties >>> -- especially if they might occur down the track a bit, and >>> especially if the candidates have other commitments coming and going >>> as well. >>> >>> >>> -- >>> Mark Nottingham   https://www.mnot.net/ >>> >> >> So you'd rather have the various members of the RSAB play "not me" on >> an annual basis, with the probable result that the IAB and IRTF >> members will end up handing the position back and forth?  (I base >> this on your statement above that it might be difficult to find >> willing members and the following probable arguments:  RSCE - I'm not >> paid to do this - add it to my task order first; ISE - I'm only one >> person and a volunteer at that, find someone else; IESG - I've got 20 >> WGs to oversee, I don't have the time to chair).   I don't find this >> all that palatable. >> >> Of those, I actually have sympathy with the ISE's argument and would >> add "The ISE at its discretion may pass on its opportunity to chair >> with the chair position rotating to the representative from the next >> organization in line." >> >> So once every 4-5 years one of these groups has to find someone to do >> a bit of administrivia?  If it's that much of a problem, how about we >> go back to my first suggestion and set up the RSCE as the permanent >> chair? >> >> If we pay the RSCE for the role, that would render moot your comments >> above.  And, as I've noted a few times, the chair position has some >> responsibility, but almost no authority. >> >> Later, Mike >> >> >> >> > From nobody Tue Aug 17 12:28:03 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 944B63A0F0C for ; Tue, 17 Aug 2021 12:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 VAYUigH8wAkG for ; Tue, 17 Aug 2021 12:27:55 -0700 (PDT) Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (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 170CD3A0EFA for ; Tue, 17 Aug 2021 12:27:55 -0700 (PDT) Received: by mail-il1-x129.google.com with SMTP id j18so23376370ile.8 for ; Tue, 17 Aug 2021 12:27:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iMdKZ2oy2vczX7yYE5883Ds7GQedOf4uQRDsMd0Uj28=; b=iMYMAMXpwIxXCLBpLT8V3sv5BF0y8l7H21zfZQYXMEwTRKMfy0JNlpml0mXt7bD9Nn ZGe53bKnt/XYTc8kvZRbqrZxjT8usTkovyWbw10wT4PDsgP82+Toy5SdDi4H+rDuF/DG l+siMWnERzrv/f5Q2RPD9+a6IU4WcD1Z9J2uOma6UPAfAOIazmuzBCwzKEwxOlPlIQsH c3mpxb2c8VLthw+78FfspILPvJ8NyGEQZByffvT52Dpm/Y2rgRTJCo3xRJB1F+Pt4Rr+ x/n7UjvJk8P/mci5HVhwSsrUTvejzj0F7Q352RaykLGC0IlQIXMr1rVTyPcco2ScU3nc aMNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iMdKZ2oy2vczX7yYE5883Ds7GQedOf4uQRDsMd0Uj28=; b=E+CSemGdNZ0VAtzexg7pN+G4oSD4MZdu+VqVcxNJjNd/G1ilBoRUqGJ9YDaL3Syrge 3sL82wC14IRF1olihyEyIOqxs/2FaKOAdfwGGyJsTGLh3vaD/C3rvTWOyX5kSAY8fMCA EKcQ3WXzrsG1l+BcW2yk0whRbigRNXqm5hyCuAtmV1xdqB0YdTDkOjTJCX2P5hJIYL+e 5tNyZxmmNxfkTBGylFEwAW3IqRJt3o65NXDiAN4ss1vlaO6uxlmRefHx3W7ZgsOQ0DWU FBNpNMHPg5pWHlR654LU/wBBzCrZxf/WgZTEYm5Hi8OrciF2MGtWt8jACSOOp0TlSKHn H5wA== X-Gm-Message-State: AOAM531qprvOTDV/EnRBXbRVQ4J3wi4j5NRZL1WFa+e3gPnGkBj9RuSn P6NaAU1WlbeYmrsMKPk4JeIluKsTe/0P685yrCtUvA== X-Google-Smtp-Source: ABdhPJyaTZOqTwrqLJnUEK46zN4gaeWAoBTcc6EPUCc4FyK3AdWOVvzrqCMkC4dNnLR8q1uqmk5PrdtoypGucqwFseU= X-Received: by 2002:a92:d741:: with SMTP id e1mr3492189ilq.18.1629228473930; Tue, 17 Aug 2021 12:27:53 -0700 (PDT) MIME-Version: 1.0 References: <4338a0bb-32f3-9b92-5ed6-1be5ac3c0b86@nthpermutation.com> <8bcab165-0de0-0820-c916-7ef12cd30d85@nthpermutation.com> In-Reply-To: <8bcab165-0de0-0820-c916-7ef12cd30d85@nthpermutation.com> From: Eric Rescorla Date: Tue, 17 Aug 2021 12:27:17 -0700 Message-ID: To: Michael StJohns Cc: Eliot Lear , rfced-future@iab.org Content-Type: multipart/alternative; boundary="000000000000726b2405c9c65031" Archived-At: Subject: Re: [Rfced-future] Issue 71: Term limits for RSAB chairs? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2021 19:28:02 -0000 --000000000000726b2405c9c65031 Content-Type: text/plain; charset="UTF-8" I guess we all have different forecasts about the future, because I don't anticipate it will be that hard to find a chair, and I don't think we should rotate. I also think we should consider whether the RSCE should in fact be allowed to be chair. They stand in a different relationship to things than the other members. -Ekr On Tue, Aug 17, 2021 at 11:56 AM Michael StJohns wrote: > On 8/17/2021 1:57 PM, Eliot Lear wrote: > > Mike, just to boil things down a bit, I'm going to ask the obvious > > Eliot question: > > > > Can you distill down what you think MUST be in the draft now and what > > might wait for some operational experience? That is to say, in your > > opinion, does the community have the option to add this sort of > > rotation scheme in later if the situation seems to warrant? > > If this is going to require the RSCE to perform chair duties at any > time, that needs to be included so the LLC can budget for it and include > it in the contract. That's the mandatory part. > > But! Mark has already indicated that he feels the job will not be > desirable and that various orgs will resist taking a turn as chair. I > think as part of giving them a voice on the RSAB (authority...) we need > to bind that to whatever responsibilities also come from those > positions. So, yes, I think this needs to be specified in a manner that > either a) requires everyone to take a turn, or b) pays the RSCE to do > the administrivia of the chair job. I don't think that should be deferred. > > Note that I also suggested that the RSAB include non-ex officio members > appointed by the Nomcom and that had we done that, sticking one of them > with the chair job would moot the whole "its too much work" argument > that Mark made. > > Later, Mike > > > > > > > More generally, should we create perhaps a bit of a checklist of > > things we decided not to decide so that those items get some attention > > just to see that things haven't broken? > > > > Eliot > > > > On 17.08.21 19:10, Michael StJohns wrote: > >> On 8/17/2021 2:10 AM, Mark Nottingham wrote: > >>> Hi Michael, > >>> > >>>> On 16 Aug 2021, at 11:30 am, Michael StJohns > >>>> wrote: > >>>> > >>>> The RSAB chair duties shall rotate annually between each of its > >>>> members in the following order: IAB, RSCE, IESG, IRTF, ISE. That > >>>> order was chosen to mirror the historical order of creation of the > >>>> appointing organizations. The RSAB may choose to follow a strict > >>>> annual rotation, or may adjust the term to coincide with the end of > >>>> a specific IETF meeting similar to the terms of the IAB and IESG. > >>> Hmm. It strikes me that doing it this way might complicate the > >>> selection process for the various bodies. Finding someone who's > >>> willing to head up a stream and serve on the RSAB is different from > >>> finding someone who can do those _and_ take on extra chairing duties > >>> -- especially if they might occur down the track a bit, and > >>> especially if the candidates have other commitments coming and going > >>> as well. > >>> > >>> > >>> -- > >>> Mark Nottingham https://www.mnot.net/ > >>> > >> > >> So you'd rather have the various members of the RSAB play "not me" on > >> an annual basis, with the probable result that the IAB and IRTF > >> members will end up handing the position back and forth? (I base > >> this on your statement above that it might be difficult to find > >> willing members and the following probable arguments: RSCE - I'm not > >> paid to do this - add it to my task order first; ISE - I'm only one > >> person and a volunteer at that, find someone else; IESG - I've got 20 > >> WGs to oversee, I don't have the time to chair). I don't find this > >> all that palatable. > >> > >> Of those, I actually have sympathy with the ISE's argument and would > >> add "The ISE at its discretion may pass on its opportunity to chair > >> with the chair position rotating to the representative from the next > >> organization in line." > >> > >> So once every 4-5 years one of these groups has to find someone to do > >> a bit of administrivia? If it's that much of a problem, how about we > >> go back to my first suggestion and set up the RSCE as the permanent > >> chair? > >> > >> If we pay the RSCE for the role, that would render moot your comments > >> above. And, as I've noted a few times, the chair position has some > >> responsibility, but almost no authority. > >> > >> Later, Mike > >> > >> > >> > >> > > > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > --000000000000726b2405c9c65031 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I guess we all have different forecasts about the fut= ure, because I don't anticipate it will be that hard to find a chair, a= nd I don't think we should rotate.

I also thin= k we should consider whether the RSCE should in fact be allowed to be chair= . They stand in a different relationship to things than the other members.<= br>

-Ekr


On Tue, Aug 17, 2021= at 11:56 AM Michael StJohns <= msj@nthpermutation.com> wrote:
On 8/17/2021 1:57 PM, Eliot Lear wrote:
> Mike, just to boil things down a bit, I'm going to ask the obvious=
> Eliot question:
>
> Can you distill down what you think MUST be in the draft now and what =
> might wait for some operational experience?=C2=A0 That is to say, in y= our
> opinion, does the community have the option to add this sort of
> rotation scheme in later if the situation seems to warrant?

If this is going to require the RSCE to perform chair duties at any
time, that needs to be included so the LLC can budget for it and include it in the contract.=C2=A0=C2=A0=C2=A0=C2=A0 That's the mandatory part.<= br>
But!=C2=A0 Mark has already indicated that he feels the job will not be desirable and that various orgs will resist taking a turn as chair.=C2=A0 I=
think as part of giving them a voice on the RSAB (authority...) we need to bind that to whatever responsibilities also come from those
positions.=C2=A0 So, yes, I think this needs to be specified in a manner th= at
either a) requires everyone to take a turn, or b) pays the RSCE to do
the administrivia of the chair job.=C2=A0 I don't think that should be = deferred.

Note that I also suggested that the RSAB include non-ex officio members appointed by the Nomcom and that had we done that, sticking one of them with the chair job would moot the whole "its too much work" argum= ent
that Mark made.

Later, Mike



>
> More generally, should we create perhaps a bit of a checklist of
> things we decided not to decide so that those items get some attention=
> just to see that things haven't broken?
>
> Eliot
>
> On 17.08.21 19:10, Michael StJohns wrote:
>> On 8/17/2021 2:10 AM, Mark Nottingham wrote:
>>> Hi Michael,
>>>
>>>> On 16 Aug 2021, at 11:30 am, Michael StJohns
>>>> <msj@nthpermutation.com> wrote:
>>>>
>>>> The RSAB chair duties shall rotate annually between each o= f its
>>>> members in the following order: IAB, RSCE, IESG, IRTF, ISE= .=C2=A0 That
>>>> order was chosen to mirror the historical order of creatio= n of the
>>>> appointing organizations.=C2=A0=C2=A0 The RSAB may choose = to follow a strict
>>>> annual rotation, or may adjust the term to coincide with t= he end of
>>>> a specific IETF meeting similar to the terms of the IAB an= d IESG.
>>> Hmm. It strikes me that doing it this way might complicate the=
>>> selection process for the various bodies. Finding someone who&= #39;s
>>> willing to head up a stream and serve on the RSAB is different= from
>>> finding someone who can do those _and_ take on extra chairing = duties
>>> -- especially if they might occur down the track a bit, and >>> especially if the candidates have other commitments coming and= going
>>> as well.
>>>
>>>
>>> --
>>> Mark Nottingham=C2=A0=C2=A0 https://www.mnot.net/
>>>
>>
>> So you'd rather have the various members of the RSAB play &quo= t;not me" on
>> an annual basis, with the probable result that the IAB and IRTF >> members will end up handing the position back and forth?=C2=A0 (I = base
>> this on your statement above that it might be difficult to find >> willing members and the following probable arguments:=C2=A0 RSCE -= I'm not
>> paid to do this - add it to my task order first; ISE - I'm onl= y one
>> person and a volunteer at that, find someone else; IESG - I've= got 20
>> WGs to oversee, I don't have the time to chair).=C2=A0=C2=A0 I= don't find this
>> all that palatable.
>>
>> Of those, I actually have sympathy with the ISE's argument and= would
>> add "The ISE at its discretion may pass on its opportunity to= chair
>> with the chair position rotating to the representative from the ne= xt
>> organization in line."
>>
>> So once every 4-5 years one of these groups has to find someone to= do
>> a bit of administrivia?=C2=A0 If it's that much of a problem, = how about we
>> go back to my first suggestion and set up the RSCE as the permanen= t
>> chair?
>>
>> If we pay the RSCE for the role, that would render moot your comme= nts
>> above.=C2=A0 And, as I've noted a few times, the chair positio= n has some
>> responsibility, but almost no authority.
>>
>> Later, Mike
>>
>>
>>
>>
>

--
Rfced-future mailing list
Rfced-future@iab.= org
https://www.iab.org/mailman/listinfo/rfced-future
--000000000000726b2405c9c65031-- From nobody Tue Aug 17 12:34:34 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A86A3A1341 for ; Tue, 17 Aug 2021 12:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.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 hsYlcqOYw3sC for ; Tue, 17 Aug 2021 12:34:26 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 47F093A140D for ; Tue, 17 Aug 2021 12:34:19 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id a21so14341812ioq.6 for ; Tue, 17 Aug 2021 12:34:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=zmXb3HHC68KtM3vU7EGn0leUy0/HDXSwQ8dY//zwd3Y=; b=YFSTaiNJ66YBmaZ6GTkZ4+zyhcklSdG3h5YtYLDjWK66eo0ziXs2dduDLDbNIUU5/J HKVthfAFMgDkYN9Tr9g/CYOAZ9jYl39j9eRftq2vV1+Nva3lSCptgrwvvBXoX88OkbNG 2C5eynmCqQjrBnZJuya57YbRtFZm6pok4fcI1lKuqkbH/p7vzI59DHXhTRP6J7PblPVN XsjAy5Y+H+9mGQQb/6KbSsoPWB3r29pyY0ImqpB/vRl4PW9VP+w5dkR1QSl3sHN7/Bzt ENhG2HzWc6h/FghOyzkVgXpVn0KXF8LLLZi/I4PbG0KJ6ryyje4g2cAIPtxyQDIapt5Q Q/Ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=zmXb3HHC68KtM3vU7EGn0leUy0/HDXSwQ8dY//zwd3Y=; b=slI8KixjEOSioAHHJu7dQvfeRektlpBmKDkmmdxOHfaoyoY0aOTn6G8nzH8USTz2x9 JhzGVzCiIZk0K0vcySL0tmNHuPTsfszBSGRwDc2EHio197u4mmcZuYWk8HEniGMvHSue lxkbUavb7GNoR2tzS5/nunniZKQ2UixURYCWK5iY6Ab0zM/04QaygyzJ7lrxxvBRNuM1 azSCGpIzXqdkTMu2MwlIQtpPWupiyuZJW/f0OoATAHA4k1N5McYeuZBYJoxB9Ks8Qcnw KrTChigPGu3isC5HLWxev/OpxIgVxneL6mf2/IHImKigop7B3+bqxLjJ+cLFL6FqVOpv x+RA== X-Gm-Message-State: AOAM531rTAtbPELBTpQ1dUQwMjdjYKb5g8apk35mxuQaSkLf6cGJdlIa gnlZjQIgHi1DM6+zelgQgUKBFw== X-Google-Smtp-Source: ABdhPJxwup2izmpdS2B25lTW/8ox7DXYXgzoE6WbUVQ8urjJ6sbbbz1OUtuUj96nwsGOKTZRHQKDNA== X-Received: by 2002:a05:6638:304a:: with SMTP id u10mr4462174jak.62.1629228857808; Tue, 17 Aug 2021 12:34:17 -0700 (PDT) Received: from smtpclient.apple (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id m26sm1543221ioj.54.2021.08.17.12.34.16 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Aug 2021 12:34:17 -0700 (PDT) From: Brian Rosen Message-Id: <2ECB1495-CDBD-49B7-BD2C-A643BE4CA9C8@brianrosen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_6374D490-9E7B-47BD-8CC9-931A7CF27396" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Tue, 17 Aug 2021 15:34:15 -0400 In-Reply-To: Cc: Michael StJohns , rfced-future@iab.org, Eliot Lear To: Eric Rescorla References: <4338a0bb-32f3-9b92-5ed6-1be5ac3c0b86@nthpermutation.com> <8bcab165-0de0-0820-c916-7ef12cd30d85@nthpermutation.com> X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Rfced-future] Issue 71: Term limits for RSAB chairs? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2021 19:34:32 -0000 --Apple-Mail=_6374D490-9E7B-47BD-8CC9-931A7CF27396 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 But chair here doesn=E2=80=99t have a lot of power. If we don=E2=80=99t = specifying a specific way to pick a chair, then, as the current text = says, it=E2=80=99s up to the RSAB members to decide, and they can decide = to allow the RSCE to be a chair or not. It may be more who are the = actual people involved vs what their positions or membership line on the = RSAB is. If we=E2=80=99re not tying the RSABs hands, then let them = decide, change their minds, or evolve. No need to limit. Brian > On Aug 17, 2021, at 3:27 PM, Eric Rescorla wrote: >=20 > I guess we all have different forecasts about the future, because I = don't anticipate it will be that hard to find a chair, and I don't think = we should rotate. >=20 > I also think we should consider whether the RSCE should in fact be = allowed to be chair. They stand in a different relationship to things = than the other members. >=20 > -Ekr >=20 >=20 > On Tue, Aug 17, 2021 at 11:56 AM Michael StJohns = > wrote: > On 8/17/2021 1:57 PM, Eliot Lear wrote: > > Mike, just to boil things down a bit, I'm going to ask the obvious=20= > > Eliot question: > > > > Can you distill down what you think MUST be in the draft now and = what=20 > > might wait for some operational experience? That is to say, in your=20= > > opinion, does the community have the option to add this sort of=20 > > rotation scheme in later if the situation seems to warrant? >=20 > If this is going to require the RSCE to perform chair duties at any=20 > time, that needs to be included so the LLC can budget for it and = include=20 > it in the contract. That's the mandatory part. >=20 > But! Mark has already indicated that he feels the job will not be=20 > desirable and that various orgs will resist taking a turn as chair. I=20= > think as part of giving them a voice on the RSAB (authority...) we = need=20 > to bind that to whatever responsibilities also come from those=20 > positions. So, yes, I think this needs to be specified in a manner = that=20 > either a) requires everyone to take a turn, or b) pays the RSCE to do=20= > the administrivia of the chair job. I don't think that should be = deferred. >=20 > Note that I also suggested that the RSAB include non-ex officio = members=20 > appointed by the Nomcom and that had we done that, sticking one of = them=20 > with the chair job would moot the whole "its too much work" argument=20= > that Mark made. >=20 > Later, Mike >=20 >=20 >=20 > > > > More generally, should we create perhaps a bit of a checklist of=20 > > things we decided not to decide so that those items get some = attention=20 > > just to see that things haven't broken? > > > > Eliot > > > > On 17.08.21 19:10, Michael StJohns wrote: > >> On 8/17/2021 2:10 AM, Mark Nottingham wrote: > >>> Hi Michael, > >>> > >>>> On 16 Aug 2021, at 11:30 am, Michael StJohns=20 > >>>> > wrote: > >>>> > >>>> The RSAB chair duties shall rotate annually between each of its=20= > >>>> members in the following order: IAB, RSCE, IESG, IRTF, ISE. That=20= > >>>> order was chosen to mirror the historical order of creation of = the=20 > >>>> appointing organizations. The RSAB may choose to follow a = strict=20 > >>>> annual rotation, or may adjust the term to coincide with the end = of=20 > >>>> a specific IETF meeting similar to the terms of the IAB and IESG. > >>> Hmm. It strikes me that doing it this way might complicate the=20 > >>> selection process for the various bodies. Finding someone who's=20 > >>> willing to head up a stream and serve on the RSAB is different = from=20 > >>> finding someone who can do those _and_ take on extra chairing = duties=20 > >>> -- especially if they might occur down the track a bit, and=20 > >>> especially if the candidates have other commitments coming and = going=20 > >>> as well. > >>> > >>> > >>> --=20 > >>> Mark Nottingham https://www.mnot.net/ > >>> > >> > >> So you'd rather have the various members of the RSAB play "not me" = on=20 > >> an annual basis, with the probable result that the IAB and IRTF=20 > >> members will end up handing the position back and forth? (I base=20= > >> this on your statement above that it might be difficult to find=20 > >> willing members and the following probable arguments: RSCE - I'm = not=20 > >> paid to do this - add it to my task order first; ISE - I'm only one=20= > >> person and a volunteer at that, find someone else; IESG - I've got = 20=20 > >> WGs to oversee, I don't have the time to chair). I don't find = this=20 > >> all that palatable. > >> > >> Of those, I actually have sympathy with the ISE's argument and = would=20 > >> add "The ISE at its discretion may pass on its opportunity to chair=20= > >> with the chair position rotating to the representative from the = next=20 > >> organization in line." > >> > >> So once every 4-5 years one of these groups has to find someone to = do=20 > >> a bit of administrivia? If it's that much of a problem, how about = we=20 > >> go back to my first suggestion and set up the RSCE as the permanent=20= > >> chair? > >> > >> If we pay the RSCE for the role, that would render moot your = comments=20 > >> above. And, as I've noted a few times, the chair position has some=20= > >> responsibility, but almost no authority. > >> > >> Later, Mike > >> > >> > >> > >> > > >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future = > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future --Apple-Mail=_6374D490-9E7B-47BD-8CC9-931A7CF27396 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <no hats>
But chair here doesn=E2=80=99t = have a lot of power.  If we don=E2=80=99t specifying a specific way = to pick a chair, then, as the current text says, it=E2=80=99s up to the = RSAB members to decide, and they can decide to allow the RSCE to be a = chair or not.  It may be more who are the actual people involved vs = what their positions or membership line on the RSAB is.  If we=E2=80=99= re not tying the RSABs hands, then let them decide, change their minds, = or evolve.   No need to limit.

Brian

On Aug = 17, 2021, at 3:27 PM, Eric Rescorla <ekr@rtfm.com> wrote:

I guess we all have different forecasts about = the future, because I don't anticipate it will be that hard to find a = chair, and I don't think we should rotate.

I also think we should consider whether = the RSCE should in fact be allowed to be chair. They stand in a = different relationship to things than the other members.

-Ekr


On Tue, Aug 17, 2021 at 11:56 AM Michael StJohns = <msj@nthpermutation.com> wrote:
On 8/17/2021 1:57 PM, Eliot Lear = wrote:
> Mike, just to boil things down a bit, I'm going to ask the obvious =
> Eliot question:
>
> Can you distill down what you think MUST be in the draft now and = what
> might wait for some operational experience?  That is to say, = in your
> opinion, does the community have the option to add this sort of
> rotation scheme in later if the situation seems to warrant?

If this is going to require the RSCE to perform chair duties at any
time, that needs to be included so the LLC can budget for it and include =
it in the contract.     That's the mandatory = part.

But!  Mark has already indicated that he feels the job will not be =
desirable and that various orgs will resist taking a turn as = chair.  I
think as part of giving them a voice on the RSAB (authority...) we need =
to bind that to whatever responsibilities also come from those
positions.  So, yes, I think this needs to be specified in a manner = that
either a) requires everyone to take a turn, or b) pays the RSCE to do =
the administrivia of the chair job.  I don't think that should be = deferred.

Note that I also suggested that the RSAB include non-ex officio members =
appointed by the Nomcom and that had we done that, sticking one of them =
with the chair job would moot the whole "its too much work" argument
that Mark made.

Later, Mike



>
> More generally, should we create perhaps a bit of a checklist of =
> things we decided not to decide so that those items get some = attention
> just to see that things haven't broken?
>
> Eliot
>
> On 17.08.21 19:10, Michael StJohns wrote:
>> On 8/17/2021 2:10 AM, Mark Nottingham wrote:
>>> Hi Michael,
>>>
>>>> On 16 Aug 2021, at 11:30 am, Michael StJohns
>>>> <msj@nthpermutation.com> wrote:
>>>>
>>>> The RSAB chair duties shall rotate annually between = each of its
>>>> members in the following order: IAB, RSCE, IESG, IRTF, = ISE.  That
>>>> order was chosen to mirror the historical order of = creation of the
>>>> appointing organizations.   The RSAB may = choose to follow a strict
>>>> annual rotation, or may adjust the term to coincide = with the end of
>>>> a specific IETF meeting similar to the terms of the IAB = and IESG.
>>> Hmm. It strikes me that doing it this way might complicate = the
>>> selection process for the various bodies. Finding someone = who's
>>> willing to head up a stream and serve on the RSAB is = different from
>>> finding someone who can do those _and_ take on extra = chairing duties
>>> -- especially if they might occur down the track a bit, and =
>>> especially if the candidates have other commitments coming = and going
>>> as well.
>>>
>>>
>>> --
>>> Mark Nottingham   https://www.mnot.net/
>>>
>>
>> So you'd rather have the various members of the RSAB play "not = me" on
>> an annual basis, with the probable result that the IAB and IRTF =
>> members will end up handing the position back and forth?  = (I base
>> this on your statement above that it might be difficult to find =
>> willing members and the following probable arguments:  = RSCE - I'm not
>> paid to do this - add it to my task order first; ISE - I'm only = one
>> person and a volunteer at that, find someone else; IESG - I've = got 20
>> WGs to oversee, I don't have the time to chair).   I = don't find this
>> all that palatable.
>>
>> Of those, I actually have sympathy with the ISE's argument and = would
>> add "The ISE at its discretion may pass on its opportunity to = chair
>> with the chair position rotating to the representative from the = next
>> organization in line."
>>
>> So once every 4-5 years one of these groups has to find someone = to do
>> a bit of administrivia?  If it's that much of a problem, = how about we
>> go back to my first suggestion and set up the RSCE as the = permanent
>> chair?
>>
>> If we pay the RSCE for the role, that would render moot your = comments
>> above.  And, as I've noted a few times, the chair position = has some
>> responsibility, but almost no authority.
>>
>> Later, Mike
>>
>>
>>
>>
>

--
Rfced-future mailing list
Rfced-future@iab.org
https://www.iab.org/mailman/listinfo/rfced-future
--
Rfced-future mailing list
Rfced-future@iab.org
https://www.iab.org/mailman/listinfo/rfced-future

= --Apple-Mail=_6374D490-9E7B-47BD-8CC9-931A7CF27396-- From nobody Tue Aug 17 13:46:50 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 593753A238A for ; Tue, 17 Aug 2021 13:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Wmkuj6IHPnEE for ; Tue, 17 Aug 2021 13:46:42 -0700 (PDT) Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (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 50C153A2379 for ; Tue, 17 Aug 2021 13:46:42 -0700 (PDT) Received: by mail-pj1-x102b.google.com with SMTP id n13-20020a17090a4e0d00b0017946980d8dso7311757pjh.5 for ; Tue, 17 Aug 2021 13:46:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=ODRBJ4exCoInkQOBmACB9t7uwOAY1McyWNP8GT3zOR0=; b=iMBmxIpFZqMNtHnSN6jq8Uu2f4Hfg3IHCvNfRNq6Y1fzzH2YZkmEW59gZiEJkrb4Cv pF+4+ZAYmfjKc8baFSl91SJ3E5U4u/fpUalQBSF+xm27xtoiqFf/aRoZUYVz8qkyvxP0 Ek44kYRM9qRjPUGzEHnBkucFQR54TLPj/nQiV87AkLWG0XFKmyKKjNdgPQmvAD2uEtE4 MMu2JMmswdfZRYUauD80F97L0LygHEuHxcRPiW0h8faBd8eoCWLEI6omN3F7hor0+05t qoyqjw0vA7L7qJZFXZjQMebudoLxkq/DiGe6KTn/DZGCfBIkjWZdL//qBZQNdyh3jJRg Oz2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ODRBJ4exCoInkQOBmACB9t7uwOAY1McyWNP8GT3zOR0=; b=szbEW5Hh3ujPopqTq4GKQW1CxVN1CI/+nPPBevxVoI5ubcqw2nxGt+RjK0qsAp0Jul OHJq1cyEbY2lfLiZQtEULFCJmp0OjzNzZ/6XdF7xi7GbpCizNIIPLNRAfkq6jZCcfl4/ 8ICY3OZylhQkAho61kdMUaWLMpdq6H0ujiFXLDGIkwf9A9xRC7untQoFGT2py3vSpa5X u37cD9APmwn4nwiXh/fHXRa14Je4bMAqeN3Rdb561wGLE0mZe56pD3IMHs8qNZKn76xb W9ByJWsm/5JuyezcioSFkmHXaeDf7kncDsI1FdHbruRvGqCNo8M9xqWPH6tpBuPiEHg5 Qang== X-Gm-Message-State: AOAM531s2VXjp/FsQvL+Hq/hZsBeAKgNL/IyyHr3uSLrLKoNegPJbJJc uH2OV2pFLW6s9JzkopE9Akk= X-Google-Smtp-Source: ABdhPJzr34TeUDgMaOM8RTAv8pjLZBTg6/lcmmiNuDmh9xUy9ibgcC0S7OvJwfLZRHqvDoTlooyICA== X-Received: by 2002:a17:90a:d702:: with SMTP id y2mr5540926pju.127.1629233200766; Tue, 17 Aug 2021 13:46:40 -0700 (PDT) Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id z7sm3741551pff.177.2021.08.17.13.46.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 17 Aug 2021 13:46:40 -0700 (PDT) To: Brian Rosen , Eric Rescorla Cc: rfced-future@iab.org, Eliot Lear , Michael StJohns References: <4338a0bb-32f3-9b92-5ed6-1be5ac3c0b86@nthpermutation.com> <8bcab165-0de0-0820-c916-7ef12cd30d85@nthpermutation.com> <2ECB1495-CDBD-49B7-BD2C-A643BE4CA9C8@brianrosen.net> From: Brian E Carpenter Message-ID: Date: Wed, 18 Aug 2021 08:46:36 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <2ECB1495-CDBD-49B7-BD2C-A643BE4CA9C8@brianrosen.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Issue 71: Term limits for RSAB chairs? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2021 20:46:49 -0000 On 18-Aug-21 07:34, Brian Rosen wrote: > > But chair here doesn=E2=80=99t have a lot of power. =C2=A0If we don=E2=80= =99t specifying a specific way to pick a chair, then, as the current text=20 says, it=E2=80=99s up to the RSAB members to decide, and they can decide = to allow the RSCE to be a chair or not. =C2=A0It may be more who are the = actual people involved vs what their positions or membership line on the = RSAB is. =C2=A0If we=E2=80=99re not tying the RSABs hands, then let them = decide, change their minds, or evolve. =C2=A0 No need to limit. I agree, with the caveat I suggested a few days ago: the Chair is appoint= ed annually. Brian (the other one) >=20 > Brian >=20 >> On Aug 17, 2021, at 3:27 PM, Eric Rescorla > wrote: >> >> I guess we all have different forecasts about the future, because I do= n't anticipate it will be that hard to find a chair, and I don't think we=20 should rotate. >> >> I also think we should consider whether the RSCE should in fact be all= owed to be chair. They stand in a different relationship to things than t= he other members. >> >> -Ekr >> >> >> On Tue, Aug 17, 2021 at 11:56 AM Michael StJohns > wrote: >> >> On 8/17/2021 1:57 PM, Eliot Lear wrote: >> > Mike, just to boil things down a bit, I'm going to ask the obvio= us >> > Eliot question: >> > >> > Can you distill down what you think MUST be in the draft now and=20 what >> > might wait for some operational experience?=C2=A0 That is to say= , in your >> > opinion, does the community have the option to add this sort of >> > rotation scheme in later if the situation seems to warrant? >> >> If this is going to require the RSCE to perform chair duties at an= y >> time, that needs to be included so the LLC can budget for it and i= nclude >> it in the contract.=C2=A0=C2=A0=C2=A0=C2=A0 That's the mandatory p= art. >> >> But!=C2=A0 Mark has already indicated that he feels the job will n= ot be >> desirable and that various orgs will resist taking a turn as chair= =2E=C2=A0 I >> think as part of giving them a voice on the RSAB (authority...) we=20 need >> to bind that to whatever responsibilities also come from those >> positions.=C2=A0 So, yes, I think this needs to be specified in a = manner that >> either a) requires everyone to take a turn, or b) pays the RSCE to=20 do >> the administrivia of the chair job.=C2=A0 I don't think that shoul= d be deferred. >> >> Note that I also suggested that the RSAB include non-ex officio me= mbers >> appointed by the Nomcom and that had we done that, sticking one of=20 them >> with the chair job would moot the whole "its too much work" argume= nt >> that Mark made. >> >> Later, Mike >> >> >> >> > >> > More generally, should we create perhaps a bit of a checklist of= >> > things we decided not to decide so that those items get some att= ention >> > just to see that things haven't broken? >> > >> > Eliot >> > >> > On 17.08.21 19:10, Michael StJohns wrote: >> >> On 8/17/2021 2:10 AM, Mark Nottingham wrote: >> >>> Hi Michael, >> >>> >> >>>> On 16 Aug 2021, at 11:30 am, Michael StJohns >> >>>> > wrot= e: >> >>>> >> >>>> The RSAB chair duties shall rotate annually between each of i= ts >> >>>> members in the following order: IAB, RSCE, IESG, IRTF, ISE.=C2= =A0 That >> >>>> order was chosen to mirror the historical order of creation o= f the >> >>>> appointing organizations.=C2=A0=C2=A0 The RSAB may choose to = follow a strict >> >>>> annual rotation, or may adjust the term to coincide with the = end of >> >>>> a specific IETF meeting similar to the terms of the IAB and I= ESG. >> >>> Hmm. It strikes me that doing it this way might complicate the= >> >>> selection process for the various bodies. Finding someone who'= s >> >>> willing to head up a stream and serve on the RSAB is different=20 from >> >>> finding someone who can do those _and_ take on extra chairing = duties >> >>> -- especially if they might occur down the track a bit, and >> >>> especially if the candidates have other commitments coming and=20 going >> >>> as well. >> >>> >> >>> >> >>> -- >> >>> Mark Nottingham=C2=A0=C2=A0 https://www.mnot.net/ >> >>> >> >> >> >> So you'd rather have the various members of the RSAB play "not = me" on >> >> an annual basis, with the probable result that the IAB and IRTF= >> >> members will end up handing the position back and forth?=C2=A0 = (I base >> >> this on your statement above that it might be difficult to find= >> >> willing members and the following probable arguments:=C2=A0 RSC= E - I'm not >> >> paid to do this - add it to my task order first; ISE - I'm only=20 one >> >> person and a volunteer at that, find someone else; IESG - I've = got 20 >> >> WGs to oversee, I don't have the time to chair).=C2=A0=C2=A0 I = don't find this >> >> all that palatable. >> >> >> >> Of those, I actually have sympathy with the ISE's argument and = would >> >> add "The ISE at its discretion may pass on its opportunity to c= hair >> >> with the chair position rotating to the representative from the=20 next >> >> organization in line." >> >> >> >> So once every 4-5 years one of these groups has to find someone=20 to do >> >> a bit of administrivia?=C2=A0 If it's that much of a problem, h= ow about we >> >> go back to my first suggestion and set up the RSCE as the perma= nent >> >> chair? >> >> >> >> If we pay the RSCE for the role, that would render moot your co= mments >> >> above.=C2=A0 And, as I've noted a few times, the chair position=20 has some >> >> responsibility, but almost no authority. >> >> >> >> Later, Mike >> >> >> >> >> >> >> >> >> > >> >> --=20 >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future >> >> --=20 >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future >=20 >=20 From nobody Tue Aug 17 16:24:46 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA4583A11F4 for ; Tue, 17 Aug 2021 16:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=SMQpx4ZI; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=YX9VDjKZ 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 Fbvrf5oEJP41 for ; Tue, 17 Aug 2021 16:24:38 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B225D3A11F1 for ; Tue, 17 Aug 2021 16:24:38 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 26D32320091E; Tue, 17 Aug 2021 19:24:34 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Tue, 17 Aug 2021 19:24:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=l uW3o0PFdCbsqVbGcCDTZWEHSG4hL1dd4ZGAj1JMb6U=; b=SMQpx4ZIfu8Yo72D9 /4h96fq7FvCphVwRFY3NOi0F8xQn9KoocdkXABaf12Hg025ho+bdMu4Wl6v9O8KR V+OZxS07rAhvqc88uiu3aySUseOB8vpC1wcJQAlwi4p2r09f7M9GzBXV8ivz0YB7 7zFEJGHL0EnevnnaJTH7vPurQ7bJIPaDSkV7xg4bjp7dgy2eV34lpFvIHh0Wp2wZ JOKceHk+R0ldyUeBfTGkR6WtJnV+tT+hwjUPg6ROrWVHd3aDOFQGfkK1MnZy+yOn zb1fQ1rHHEn1fWJuBRR3JHPDqq6HvTHx0oivXN1t8daKFhG8hVdr/ffKt62sojMk OzELQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=luW3o0PFdCbsqVbGcCDTZWEHSG4hL1dd4ZGAj1JMb 6U=; b=YX9VDjKZAMqv437GgD5zrJyvVxtaIX77MZ71id9AqxwNIEhD4RobtFzOr aM8sWqZspXCWfOQmTziwCZ0qZGnproyxBGmkqFgX5cb3FuLmzsiFpfdGH4Z6gqrK T0Wg1JJogWggF7MLHc+Zuu5sCRR3App3f5agXARTg/YWVNE6dFPV2Q+mdOj8C9Hb CqswCKg56xfEXWeixJmBv+70n4l9xhiBrySRAL/lQdPVPDrCaMKH8sfbRyJKqhgT mynU7xA9Ivz++j93k39XClsBfgHO3i8VoM3jJtiY8gUgDyqAziKuaOPpL6fvtdUl 7Z4hNG1R3OgFoDhUbTPYIBoJHrOtw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrleeggddvtdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnheptefhvdefffeghfelieeflefhleethedtheevteetgeeuhedtveevjeekffehveet necuffhomhgrihhnpehmnhhothdrnhgvthdpihgrsgdrohhrghenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 17 Aug 2021 19:24:29 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Mark Nottingham In-Reply-To: <8bcab165-0de0-0820-c916-7ef12cd30d85@nthpermutation.com> Date: Wed, 18 Aug 2021 09:24:28 +1000 Cc: Eliot Lear , rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <1F7A6FE3-E875-4112-A2D0-3F606B720894@mnot.net> References: <4338a0bb-32f3-9b92-5ed6-1be5ac3c0b86@nthpermutation.com> <8bcab165-0de0-0820-c916-7ef12cd30d85@nthpermutation.com> To: Michael StJohns X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [Rfced-future] Issue 71: Term limits for RSAB chairs? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2021 23:24:45 -0000 Mike,=20 Please don't put words in my mouth. I expressed concern about making it = more difficult to find the right person for the job, given people's = other constraints, strengths and weaknesses -- not 'the job will not be = desirable.' I see no reason to tie the hands of these bodies when choosing their = chair; we don't do that anywhere else.=20 Cheers, > On 18 Aug 2021, at 4:55 am, Michael StJohns = wrote: >=20 > On 8/17/2021 1:57 PM, Eliot Lear wrote: >> Mike, just to boil things down a bit, I'm going to ask the obvious = Eliot question: >>=20 >> Can you distill down what you think MUST be in the draft now and what = might wait for some operational experience? That is to say, in your = opinion, does the community have the option to add this sort of rotation = scheme in later if the situation seems to warrant? >=20 > If this is going to require the RSCE to perform chair duties at any = time, that needs to be included so the LLC can budget for it and include = it in the contract. That's the mandatory part. >=20 > But! Mark has already indicated that he feels the job will not be = desirable and that various orgs will resist taking a turn as chair. I = think as part of giving them a voice on the RSAB (authority...) we need = to bind that to whatever responsibilities also come from those = positions. So, yes, I think this needs to be specified in a manner that = either a) requires everyone to take a turn, or b) pays the RSCE to do = the administrivia of the chair job. I don't think that should be = deferred. >=20 > Note that I also suggested that the RSAB include non-ex officio = members appointed by the Nomcom and that had we done that, sticking one = of them with the chair job would moot the whole "its too much work" = argument that Mark made. >=20 > Later, Mike >=20 >=20 >=20 >>=20 >> More generally, should we create perhaps a bit of a checklist of = things we decided not to decide so that those items get some attention = just to see that things haven't broken? >>=20 >> Eliot >>=20 >> On 17.08.21 19:10, Michael StJohns wrote: >>> On 8/17/2021 2:10 AM, Mark Nottingham wrote: >>>> Hi Michael, >>>>=20 >>>>> On 16 Aug 2021, at 11:30 am, Michael StJohns = wrote: >>>>>=20 >>>>> The RSAB chair duties shall rotate annually between each of its = members in the following order: IAB, RSCE, IESG, IRTF, ISE. That order = was chosen to mirror the historical order of creation of the appointing = organizations. The RSAB may choose to follow a strict annual rotation, = or may adjust the term to coincide with the end of a specific IETF = meeting similar to the terms of the IAB and IESG. >>>> Hmm. It strikes me that doing it this way might complicate the = selection process for the various bodies. Finding someone who's willing = to head up a stream and serve on the RSAB is different from finding = someone who can do those _and_ take on extra chairing duties -- = especially if they might occur down the track a bit, and especially if = the candidates have other commitments coming and going as well. >>>>=20 >>>>=20 >>>> --=20 >>>> Mark Nottingham https://www.mnot.net/ >>>>=20 >>>=20 >>> So you'd rather have the various members of the RSAB play "not me" = on an annual basis, with the probable result that the IAB and IRTF = members will end up handing the position back and forth? (I base this = on your statement above that it might be difficult to find willing = members and the following probable arguments: RSCE - I'm not paid to do = this - add it to my task order first; ISE - I'm only one person and a = volunteer at that, find someone else; IESG - I've got 20 WGs to oversee, = I don't have the time to chair). I don't find this all that palatable. >>>=20 >>> Of those, I actually have sympathy with the ISE's argument and would = add "The ISE at its discretion may pass on its opportunity to chair with = the chair position rotating to the representative from the next = organization in line." >>>=20 >>> So once every 4-5 years one of these groups has to find someone to = do a bit of administrivia? If it's that much of a problem, how about we = go back to my first suggestion and set up the RSCE as the permanent = chair? >>>=20 >>> If we pay the RSCE for the role, that would render moot your = comments above. And, as I've noted a few times, the chair position has = some responsibility, but almost no authority. >>>=20 >>> Later, Mike >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future -- Mark Nottingham https://www.mnot.net/ From nobody Tue Aug 17 17:08:56 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E6363A1516 for ; Tue, 17 Aug 2021 17:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.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 8Ka6_HGInY91 for ; Tue, 17 Aug 2021 17:08:45 -0700 (PDT) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (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 2B5F23A1532 for ; Tue, 17 Aug 2021 17:08:44 -0700 (PDT) Received: by mail-lj1-x233.google.com with SMTP id d16so1762721ljq.4 for ; Tue, 17 Aug 2021 17:08:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mbJEDPxAc9/uDvZjDZI+HmzY0KD55hc5Kqg9NYb7e7Y=; b=NivZWsmJqNOJkP1QhxqhwacQfVkI582kb3urlb1q1+x9IEmctIX3JiTejMnITQapNB oxFhTN5smC0/NPH2te/o7JbbLPLDbvC9QgwJDrcwIbDa62AwL271keETUOCkjnNOVh9m 2rgOo/ri8KeDxFcp4r1GnBf4TLeEDk4R9M9iyR5X7w5N0BI6Z5ZtpPxJIy0mVv5TqY26 WGBCtq+jCXRRwUVR0WL2C5eSa8VDQTL1RXy2nVlcwULjidLG9B5dTjOUL2eitwSwtihi DPoAawAG7s76ykPnn8SlOlAaxGtkdWctvAIIVuBtcgGRF01AcXA/IlQpEnYyCFQJBxH5 r1ZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mbJEDPxAc9/uDvZjDZI+HmzY0KD55hc5Kqg9NYb7e7Y=; b=iVigdy8soMtq3QUl6gqZCpNmfzYwIZ5ZRVVz4uwaOUif0T4LgFO6c1bkDzunoEXIIs kceCqJzi7Twp5x4soEBUVbq0KBjTZK3niRqCgXGRwnpV5hD48ZKnRPOicP0f1zGfu1TT t/gxYH4D0CsLebrLhszRS4pmoxnL170sQ68hZOKoGtXdsyNzjuEtASFuvwjNusuvoILw LRQ1irIMA5ZuaqYMBinuMEkAOb8w2zq2LsA92jyug5FtA3OOSlGOsoKQ5mzobgWBgvnn o6LjcKoCmT/MMg4Gg3qJWPfwis6nCN4SkhX1crbZrh5SyHum5E4/rV4/MbQddiySKcl9 vjCA== X-Gm-Message-State: AOAM531APhF/CYdt46E1VVaT3l9GLtdt8l8jWPTpPlBT0usXwjKxRro3 +HlzVZ2GdV3CyeZ8O2Bkb/oHZDWYg8N0mGsoKaT/Kg== X-Google-Smtp-Source: ABdhPJwYZewtc3ukEmUII5jGHbUqCnWjsqMLeYrLTM2sacFiVIzI4GQjzyWNSwuNl7bDqrW8zz4zBpAOfNGqVI/S/Ao= X-Received: by 2002:a2e:9803:: with SMTP id a3mr1774465ljj.423.1629245316937; Tue, 17 Aug 2021 17:08:36 -0700 (PDT) MIME-Version: 1.0 References: <4338a0bb-32f3-9b92-5ed6-1be5ac3c0b86@nthpermutation.com> <8bcab165-0de0-0820-c916-7ef12cd30d85@nthpermutation.com> <1F7A6FE3-E875-4112-A2D0-3F606B720894@mnot.net> In-Reply-To: <1F7A6FE3-E875-4112-A2D0-3F606B720894@mnot.net> From: "StJohns, Michael" Date: Tue, 17 Aug 2021 20:08:26 -0400 Message-ID: To: Mark Nottingham Cc: Eliot Lear , rfced-future@iab.org Content-Type: multipart/alternative; boundary="0000000000005e4e2605c9ca3c61" Archived-At: Subject: Re: [Rfced-future] Issue 71: Term limits for RSAB chairs? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2021 00:08:53 -0000 --0000000000005e4e2605c9ca3c61 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I read this email and my email multiple times and I still don=E2=80=99t kno= w how I =E2=80=9Cput words in your mouth". WRT tying the hands of the bodies: by RFC, the IETF chair is selected by the nomcom. By RFC, the chair of the IAB is selected by the IAB. By RFC, the chair of the IAB is selected annually by the IAB members. By RFC, the chair of the IRTF is selected by the IAB. And I believe, but haven=E2=80= =99t verified, that an RFC specifies that the chair of the LLC and trust are each selected by their members. E.g. there is no one right way of doing this and a rotation, or sticking the RSCE with the job is as viable an approach as having the members select their chair. In this particular case, I believe the chair job to be thankless, and would rather impose a requirement to rotate the pain than just leave it to an annual not me fight. Later, Mike On Tue, Aug 17, 2021 at 19:24 Mark Nottingham wrote: > Mike, > > Please don't put words in my mouth. I expressed concern about making it > more difficult to find the right person for the job, given people's other > constraints, strengths and weaknesses -- not 'the job will not be > desirable.' > > I see no reason to tie the hands of these bodies when choosing their > chair; we don't do that anywhere else. > > Cheers, > > > > On 18 Aug 2021, at 4:55 am, Michael StJohns > wrote: > > > > On 8/17/2021 1:57 PM, Eliot Lear wrote: > >> Mike, just to boil things down a bit, I'm going to ask the obvious > Eliot question: > >> > >> Can you distill down what you think MUST be in the draft now and what > might wait for some operational experience? That is to say, in your > opinion, does the community have the option to add this sort of rotation > scheme in later if the situation seems to warrant? > > > > If this is going to require the RSCE to perform chair duties at any > time, that needs to be included so the LLC can budget for it and include = it > in the contract. That's the mandatory part. > > > > But! Mark has already indicated that he feels the job will not be > desirable and that various orgs will resist taking a turn as chair. I > think as part of giving them a voice on the RSAB (authority...) we need t= o > bind that to whatever responsibilities also come from those positions. S= o, > yes, I think this needs to be specified in a manner that either a) requir= es > everyone to take a turn, or b) pays the RSCE to do the administrivia of t= he > chair job. I don't think that should be deferred. > > > > Note that I also suggested that the RSAB include non-ex officio members > appointed by the Nomcom and that had we done that, sticking one of them > with the chair job would moot the whole "its too much work" argument that > Mark made. > > > > Later, Mike > > > > > > > >> > >> More generally, should we create perhaps a bit of a checklist of thing= s > we decided not to decide so that those items get some attention just to s= ee > that things haven't broken? > >> > >> Eliot > >> > >> On 17.08.21 19:10, Michael StJohns wrote: > >>> On 8/17/2021 2:10 AM, Mark Nottingham wrote: > >>>> Hi Michael, > >>>> > >>>>> On 16 Aug 2021, at 11:30 am, Michael StJohns > wrote: > >>>>> > >>>>> The RSAB chair duties shall rotate annually between each of its > members in the following order: IAB, RSCE, IESG, IRTF, ISE. That order w= as > chosen to mirror the historical order of creation of the appointing > organizations. The RSAB may choose to follow a strict annual rotation, = or > may adjust the term to coincide with the end of a specific IETF meeting > similar to the terms of the IAB and IESG. > >>>> Hmm. It strikes me that doing it this way might complicate the > selection process for the various bodies. Finding someone who's willing t= o > head up a stream and serve on the RSAB is different from finding someone > who can do those _and_ take on extra chairing duties -- especially if the= y > might occur down the track a bit, and especially if the candidates have > other commitments coming and going as well. > >>>> > >>>> > >>>> -- > >>>> Mark Nottingham https://www.mnot.net/ > >>>> > >>> > >>> So you'd rather have the various members of the RSAB play "not me" on > an annual basis, with the probable result that the IAB and IRTF members > will end up handing the position back and forth? (I base this on your > statement above that it might be difficult to find willing members and th= e > following probable arguments: RSCE - I'm not paid to do this - add it to > my task order first; ISE - I'm only one person and a volunteer at that, > find someone else; IESG - I've got 20 WGs to oversee, I don't have the ti= me > to chair). I don't find this all that palatable. > >>> > >>> Of those, I actually have sympathy with the ISE's argument and would > add "The ISE at its discretion may pass on its opportunity to chair with > the chair position rotating to the representative from the next > organization in line." > >>> > >>> So once every 4-5 years one of these groups has to find someone to do > a bit of administrivia? If it's that much of a problem, how about we go > back to my first suggestion and set up the RSCE as the permanent chair? > >>> > >>> If we pay the RSCE for the role, that would render moot your comments > above. And, as I've noted a few times, the chair position has some > responsibility, but almost no authority. > >>> > >>> Later, Mike > >>> > >>> > >>> > >>> > >> > > > > -- > > Rfced-future mailing list > > Rfced-future@iab.org > > https://www.iab.org/mailman/listinfo/rfced-future > > -- > Mark Nottingham https://www.mnot.net/ > > --0000000000005e4e2605c9ca3c61 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I read this email and my email multiple times and I still= don=E2=80=99t know how I =E2=80=9Cput words in your mouth". =C2=A0

WRT tying the hands of the= bodies: =C2=A0by RFC, the IETF chair is selected by the nomcom.=C2=A0 By R= FC, the chair of the IAB is selected by the IAB.=C2=A0 By RFC, the chair of= the IAB is selected annually by the IAB members.=C2=A0 By RFC, the chair o= f the IRTF is selected by the IAB.=C2=A0 And I believe, but haven=E2=80=99t= verified, that an RFC specifies that the chair of the LLC and trust are ea= ch selected by their members. =C2=A0

E.g. there is no one right way of doing this and a rotation, o= r sticking the RSCE with the job is as viable an approach as having the mem= bers select their chair.=C2=A0 In this particular case, I believe the chair= job to be thankless, and would =C2=A0rather impose a requirement to rotate= the pain than just leave it to an annual not me fight. =C2=A0=C2=A0
<= div dir=3D"auto">
Later, Mike

On Tue, Aug 17= , 2021 at 19:24 Mark Nottingham <mnot@m= not.net> wrote:
Mike,

Please don't put words in my mouth. I expressed concern about making it= more difficult to find the right person for the job, given people's ot= her constraints, strengths and weaknesses -- not 'the job will not be d= esirable.'

I see no reason to tie the hands of these bodies when choosing their chair;= we don't do that anywhere else.

Cheers,


> On 18 Aug 2021, at 4:55 am, Michael StJohns <msj@nthpermutation.com> wrote:=
>
> On 8/17/2021 1:57 PM, Eliot Lear wrote:
>> Mike, just to boil things down a bit, I'm going to ask the obv= ious Eliot question:
>>
>> Can you distill down what you think MUST be in the draft now and w= hat might wait for some operational experience?=C2=A0 That is to say, in yo= ur opinion, does the community have the option to add this sort of rotation= scheme in later if the situation seems to warrant?
>
> If this is going to require the RSCE to perform chair duties at any ti= me, that needs to be included so the LLC can budget for it and include it i= n the contract.=C2=A0 =C2=A0 =C2=A0That's the mandatory part.
>
> But!=C2=A0 Mark has already indicated that he feels the job will not b= e desirable and that various orgs will resist taking a turn as chair.=C2=A0= I think as part of giving them a voice on the RSAB (authority...) we need = to bind that to whatever responsibilities also come from those positions.= =C2=A0 So, yes, I think this needs to be specified in a manner that either = a) requires everyone to take a turn, or b) pays the RSCE to do the administ= rivia of the chair job.=C2=A0 I don't think that should be deferred. >
> Note that I also suggested that the RSAB include non-ex officio member= s appointed by the Nomcom and that had we done that, sticking one of them w= ith the chair job would moot the whole "its too much work" argume= nt that Mark made.
>
> Later, Mike
>
>
>
>>
>> More generally, should we create perhaps a bit of a checklist of t= hings we decided not to decide so that those items get some attention just = to see that things haven't broken?
>>
>> Eliot
>>
>> On 17.08.21 19:10, Michael StJohns wrote:
>>> On 8/17/2021 2:10 AM, Mark Nottingham wrote:
>>>> Hi Michael,
>>>>
>>>>> On 16 Aug 2021, at 11:30 am, Michael StJohns <msj@nthpermutation.c= om> wrote:
>>>>>
>>>>> The RSAB chair duties shall rotate annually between ea= ch of its members in the following order: IAB, RSCE, IESG, IRTF, ISE.=C2=A0= That order was chosen to mirror the historical order of creation of the ap= pointing organizations.=C2=A0 =C2=A0The RSAB may choose to follow a strict = annual rotation, or may adjust the term to coincide with the end of a speci= fic IETF meeting similar to the terms of the IAB and IESG.
>>>> Hmm. It strikes me that doing it this way might complicate= the selection process for the various bodies. Finding someone who's wi= lling to head up a stream and serve on the RSAB is different from finding s= omeone who can do those _and_ take on extra chairing duties -- especially i= f they might occur down the track a bit, and especially if the candidates h= ave other commitments coming and going as well.
>>>>
>>>>
>>>> --
>>>> Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/
>>>>
>>>
>>> So you'd rather have the various members of the RSAB play = "not me" on an annual basis, with the probable result that the IA= B and IRTF members will end up handing the position back and forth?=C2=A0 (= I base this on your statement above that it might be difficult to find will= ing members and the following probable arguments:=C2=A0 RSCE - I'm not = paid to do this - add it to my task order first; ISE - I'm only one per= son and a volunteer at that, find someone else; IESG - I've got 20 WGs = to oversee, I don't have the time to chair).=C2=A0 =C2=A0I don't fi= nd this all that palatable.
>>>
>>> Of those, I actually have sympathy with the ISE's argument= and would add "The ISE at its discretion may pass on its opportunity = to chair with the chair position rotating to the representative from the ne= xt organization in line."
>>>
>>> So once every 4-5 years one of these groups has to find someon= e to do a bit of administrivia?=C2=A0 If it's that much of a problem, h= ow about we go back to my first suggestion and set up the RSCE as the perma= nent chair?
>>>
>>> If we pay the RSCE for the role, that would render moot your c= omments above.=C2=A0 And, as I've noted a few times, the chair position= has some responsibility, but almost no authority.
>>>
>>> Later, Mike
>>>
>>>
>>>
>>>
>>
>
> --
> Rfced-future mailing list
> Rfced-future= @iab.org
> https://www.iab.org/mailman/listinfo/rfced-fut= ure

--
Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/

--0000000000005e4e2605c9ca3c61-- From nobody Tue Aug 17 18:39:00 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 769593A1CD1 for ; Tue, 17 Aug 2021 18:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 DsuYqIZhmh9Z for ; Tue, 17 Aug 2021 18:38:54 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 177853A1CC9 for ; Tue, 17 Aug 2021 18:38:53 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1mGAXa-000JWk-Pq; Tue, 17 Aug 2021 21:38:50 -0400 Date: Tue, 17 Aug 2021 21:38:43 -0400 From: John C Klensin To: Michael StJohns , Eliot Lear cc: rfced-future@iab.org Message-ID: <5991A8718340DD092F273C6D@PSB> In-Reply-To: <8bcab165-0de0-0820-c916-7ef12cd30d85@nthpermutation.com> References: <4338a0bb-32f3-9b92-5ed6-1be5ac3c0b86@nthpermutation.com> <8bcab165-0de0-0820-c916-7ef12cd30d85@nthpermutation.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfced-future] Issue 71: Term limits for RSAB chairs? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2021 01:38:59 -0000 --On Tuesday, August 17, 2021 14:55 -0400 Michael StJohns wrote: >... > If this is going to require the RSCE to perform chair duties > at any time, that needs to be included so the LLC can budget > for it and include it in the contract.=C2=A0=C2=A0=C2=A0=C2=A0 = That's the > mandatory part. >... Independent of the other questions please think about whether adding this type of mostly administrative responsibility to the RSCE role will make it easier or harder to recruit the person we'd like to have in that role or whether it would have any effect. I don't know the answer but I believe we should try to ask the question each time we specify a role for the RSCE that is not somehow critical to our perception of the job. There will be cases in which it is worth the risk of not being able to find any qualified people who would take the job and ones where it is not. For the latter, let's not make the odds of being able to find someone worse. john =20 From nobody Tue Aug 17 19:26:40 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5DC13A2032 for ; Tue, 17 Aug 2021 19:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.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 Crjfvm7aS1ad for ; Tue, 17 Aug 2021 19:26:32 -0700 (PDT) Received: from mail-qv1-xf32.google.com (mail-qv1-xf32.google.com [IPv6:2607:f8b0:4864:20::f32]) (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 89DE13A2034 for ; Tue, 17 Aug 2021 19:26:32 -0700 (PDT) Received: by mail-qv1-xf32.google.com with SMTP id eh1so887783qvb.11 for ; Tue, 17 Aug 2021 19:26:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=oIPF+XfqszijTDQAMyEKbGmTuFmwZ6NE4+fy8fwdRsw=; b=QUNuY/BL1hG7HN1n2Ny+7KjDZVATTjvU06ydjaQIKvCIfhpc0LU99pz6wNQvAihgHv xS6kHS60VpReJ+qrc2JVAKToS3vpKCmJEqjbZQg90xnnL7ru+w0BIMYL4h2qLqTW+Sxy i6rj/a7Qwt59SaVFo9Eof9cXr4yN+oqmaV/DzwvAk6FKFGuy6UDyDBr8rJLNVOT9+dpQ sBXGXdzm1vBbcvGmrtcgD2j6LYzq1b+nkD+1WLH/xZ/ooQB7vLMdp9NWPN91wPXqMtRQ nvHEHMym7CsY0BKqujMLib00HeP+CVWEBxZNDPYwVn63aK2zNHdFbfKDha8o9SR9XSz/ aYRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=oIPF+XfqszijTDQAMyEKbGmTuFmwZ6NE4+fy8fwdRsw=; b=jVqd15McrIu4EaDbCLgKkzLADp8ja0LVJBX4/dz1lzI97iYF6uhS7jBuz+XkRIMqxv IXP73hbVizxbExmanRo/ObetVbm6biw+dYYqfGcpgLHnq49f+fJOhZaz35uCD2mN+IW8 VMRPzl3C4wFpXTtVa5t5atWuLcrbjwq9XLv3EseIA9UHtffRXi4eJJrl3uVwE9ryXz1X e8+4cb6Uxeu5re0KRm4KHVFvAKqz4MKUC4PTiZZf5mqFu3REzIK3WH0WSBQDJ/PwmoCR JTHlpZNiPtp8OVjva8iVaUzbmXBZaYSUZ5Rq1GiI54U3b9qByNw9On7w4Pmen9V0RdxP uE8g== X-Gm-Message-State: AOAM532DIuHCUSN6altG1EtYUZsjBH2sZhDN8zlXR070XkKE/OasDFk1 Oj1T3HyaWEC0JVO1fjgslaz0tThRxbdZfmx9 X-Google-Smtp-Source: ABdhPJzoJOfYGG9vCIXNcC24Dt34wzV37TUhkzK/9+YfPhtnmixKNgIZj44lCN5qbSv8oVsy0ReJCw== X-Received: by 2002:a0c:ff4b:: with SMTP id y11mr6679957qvt.50.1629253589945; Tue, 17 Aug 2021 19:26:29 -0700 (PDT) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id b19sm2678717qkc.7.2021.08.17.19.26.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 17 Aug 2021 19:26:29 -0700 (PDT) To: John C Klensin , Eliot Lear Cc: rfced-future@iab.org References: <4338a0bb-32f3-9b92-5ed6-1be5ac3c0b86@nthpermutation.com> <8bcab165-0de0-0820-c916-7ef12cd30d85@nthpermutation.com> <5991A8718340DD092F273C6D@PSB> From: Michael StJohns Message-ID: Date: Tue, 17 Aug 2021 22:26:27 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <5991A8718340DD092F273C6D@PSB> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Issue 71: Term limits for RSAB chairs? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2021 02:26:38 -0000 On 8/17/2021 9:38 PM, John C Klensin wrote: > > --On Tuesday, August 17, 2021 14:55 -0400 Michael StJohns > wrote: > >> ... >> If this is going to require the RSCE to perform chair duties >> at any time, that needs to be included so the LLC can budget >> for it and include it in the contract.     That's the >> mandatory part. >> ... > Independent of the other questions please think about whether > adding this type of mostly administrative responsibility to the > RSCE role will make it easier or harder to recruit the person > we'd like to have in that role or whether it would have any > effect. I don't know the answer but I believe we should try to > ask the question each time we specify a role for the RSCE that > is not somehow critical to our perception of the job. There > will be cases in which it is worth the risk of not being able to > find any qualified people who would take the job and ones where > it is not. For the latter, let's not make the odds of being > able to find someone worse. > > john > > Hi John - Good points, but I think the admin burden is small and would not materially affect either the LOE or scope of the RSCE if the document specified them as chair.  My argument for rotation is based on that judgement and the desire to specify an organization that doesn't necessarily depend on altruistic behavior of the members to function. If the counter argument is that the burden is larger and that it might affect the ability to find stuckees from each sending organization who might find themselves acting as chair: That suggests both that leaving the choice of chair to the RSAB as constituted could end up with some unfairness as various members could duck out of responsibility, and that hiring the job to be done (e.g. either the RSCE or maybe the ISE) would act to mitigate such unfairness. I have seen no good argument for why chairing the RSAB is a heavy burden given the proposed  constraining of the scope of the RSAB's remit in the current document. To restate:  I don't think any of the possible choices will materially affect the ability to attract and contract with an RSCE to specifically include the assignment of the RSCE as chair or not.  If the assignment of the RSCE as chair is a possibility then it needs to be scoped and included in the proposed SOW offered to the RSCE candidates. Later, Mike From nobody Tue Aug 17 20:30:28 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 699BA3A090D for ; Tue, 17 Aug 2021 20:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 TFm0HGpuYpB3; Tue, 17 Aug 2021 20:30:19 -0700 (PDT) Received: from smtpclient.apple (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id 3E9F33A0908; Tue, 17 Aug 2021 20:30:17 -0700 (PDT) From: Jay Daley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_63338F2B-B939-4D7F-9127-D77E3C3DB7EC" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Wed, 18 Aug 2021 15:30:14 +1200 In-Reply-To: Cc: John C Klensin , Eliot Lear , rfced-future@iab.org To: Michael StJohns References: <4338a0bb-32f3-9b92-5ed6-1be5ac3c0b86@nthpermutation.com> <8bcab165-0de0-0820-c916-7ef12cd30d85@nthpermutation.com> <5991A8718340DD092F273C6D@PSB> X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Rfced-future] Issue 71: Term limits for RSAB chairs? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2021 03:30:27 -0000 --Apple-Mail=_63338F2B-B939-4D7F-9127-D77E3C3DB7EC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 18/08/2021, at 2:26 PM, Michael StJohns = wrote: >=20 > On 8/17/2021 9:38 PM, John C Klensin wrote: >>=20 >> --On Tuesday, August 17, 2021 14:55 -0400 Michael StJohns >> wrote: >>=20 >>> ... >>> If this is going to require the RSCE to perform chair duties >>> at any time, that needs to be included so the LLC can budget >>> for it and include it in the contract. That's the >>> mandatory part. >>> ... >> Independent of the other questions please think about whether >> adding this type of mostly administrative responsibility to the >> RSCE role will make it easier or harder to recruit the person >> we'd like to have in that role or whether it would have any >> effect. I don't know the answer but I believe we should try to >> ask the question each time we specify a role for the RSCE that >> is not somehow critical to our perception of the job. There >> will be cases in which it is worth the risk of not being able to >> find any qualified people who would take the job and ones where >> it is not. For the latter, let's not make the odds of being >> able to find someone worse. >>=20 >> john >> =20 > Hi John - >=20 > Good points, but I think the admin burden is small and would not = materially affect either the LOE or scope of the RSCE if the document = specified them as chair. My argument for rotation is based on that = judgement and the desire to specify an organization that doesn't = necessarily depend on altruistic behavior of the members to function. >=20 > If the counter argument is that the burden is larger and that it might = affect the ability to find stuckees from each sending organization who = might find themselves acting as chair: That suggests both that leaving = the choice of chair to the RSAB as constituted could end up with some = unfairness as various members could duck out of responsibility, and that = hiring the job to be done (e.g. either the RSCE or maybe the ISE) would = act to mitigate such unfairness. >=20 > I have seen no good argument for why chairing the RSAB is a heavy = burden given the proposed constraining of the scope of the RSAB's remit = in the current document. >=20 > To restate: I don't think any of the possible choices will materially = affect the ability to attract and contract with an RSCE to specifically = include the assignment of the RSCE as chair or not.=20 I agree. > If the assignment of the RSCE as chair is a possibility then it needs = to be scoped and included in the proposed SOW offered to the RSCE = candidates. It would help, yes. Jay >=20 > Later, Mike >=20 >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future = --=20 Jay Daley IETF Executive Director jay@ietf.org --Apple-Mail=_63338F2B-B939-4D7F-9127-D77E3C3DB7EC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On 18/08/2021, at 2:26 PM, Michael StJohns <msj@nthpermutation.com> wrote:

On 8/17/2021 9:38 PM, John C Klensin wrote:

--On Tuesday, August 17, 2021 14:55 -0400 Michael StJohns
<msj@nthpermutation.com> wrote:

...
If = this is going to require the RSCE to perform chair duties
at= any time, that needs to be included so the LLC can budget
for it and include it in the = contract.     That's the
mandatory = part.
...
Independent of the = other questions please think about whether
adding this = type of mostly administrative responsibility to the
RSCE = role will make it easier or harder to recruit the person
we'd like to have in that role or whether it would have = any
effect.  I don't know the answer but I believe we = should try to
ask the question each time we specify a role = for the RSCE that
is not somehow critical to our = perception of the job.  There
will be cases in which = it is worth the risk of not being able to
find any = qualified people who would take the job and ones where
it = is not.  For the latter, let's not make the odds of being
able to find someone worse.

   john
 
Hi John -

Good points, but I think the admin burden is small and would = not materially affect either the LOE or scope of the RSCE if the = document specified them as chair.  My argument for rotation is = based on that judgement and the desire to specify an organization that = doesn't necessarily depend on altruistic behavior of the members to = function.

If the = counter argument is that the burden is larger and that it might affect = the ability to find stuckees from each sending organization who might = find themselves acting as chair: That suggests both that leaving the = choice of chair to the RSAB as constituted could end up with some = unfairness as various members could duck out of responsibility, and that = hiring the job to be done (e.g. either the RSCE or maybe the ISE) would = act to mitigate such unfairness.

I have seen no good argument for why chairing the RSAB is a = heavy burden given the proposed  constraining of the scope of the = RSAB's remit in the current document.

To restate:  I don't think any of the possible choices = will materially affect the ability to attract and contract with an RSCE = to specifically include the assignment of the RSCE as chair or = not. 

I = agree.

If the = assignment of the RSCE as chair is a possibility then it needs to be = scoped and included in the proposed SOW offered to the RSCE = candidates.

It = would help, yes.

Jay


Later, Mike


-- 
Rfced-future mailing = list
Rfced-future@iab.org
https://www.iab.org/mailman/listinfo/rfced-future

-- 
Jay Daley
IETF = Executive Director
jay@ietf.org

= --Apple-Mail=_63338F2B-B939-4D7F-9127-D77E3C3DB7EC-- From nobody Thu Aug 19 00:51:54 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4D183A11CE for ; Thu, 19 Aug 2021 00:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=netapp.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 kVZLWYOn17Gm for ; Thu, 19 Aug 2021 00:51:44 -0700 (PDT) Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2062.outbound.protection.outlook.com [40.107.236.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A74F03A11CC for ; Thu, 19 Aug 2021 00:51:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=a/BEPs2OoRlD01DvZDYwrG+sh3s1Wi7bAhRxIm4zbQljNsLdUZlJhr2o7R8VXk9LKqpc6l7MP8HsCGpfYrmioNQGtRtBV6c0WATv0O4sY0QAz5/voW1vr5qVvKTgFIdrnXFpjL2Guw5OSCkJtb6aBwUGM4g6nsegduDtHxg8s4qREZmGTKZ+TEo1LhaMfyzxNxAUGc4UGPd1RPm//fKcx8oWby7F3+v+aYfaCG2pORBs2lS5a7B32QmF6wRw57oZWSQtYJp3ZKvh9W9XPUZqtgkBYbmkObKQEv6FEA2UOWr/daqq73QIRnQHRma/dm4xIRd7D9GoSZo5rrTegqLVRQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OQbiUGs2KyPzUXIyQ4qkJ8yaugtNY7wZheBRLcc27lA=; b=CGFtB+S3R7jkx4TADXnXXupJawvAYfW4LBwz9su1KAoe77iah35hRiIN3WLJQ8NL2BIWzT5r8zwKuFOBFN8zZQIbWmOE47/N+RPbAw1bwDuwTkGNXEgzZYy0P0eIMXdPp6u4CMSGf2/2HYzlRFca7ABOjh3BxMxCZ848uaP/jxIdHYqOCKiIn6i36uV4G5/YwsoQtX/NwYgvm4DwkyO8Yw8xyrVHmxgRdHfWoiLy+XVJh/LkqKGqelWA4kOaFZxaDPUlsaN+TbPIivWIKHw0lCPf4B01PCazyuqIMucHM1zq+vcTKUpDgDpAkMfe//ixTDQtKZYOWTFSRcXuKaw1UQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=netapp.com; dmarc=pass action=none header.from=netapp.com; dkim=pass header.d=netapp.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OQbiUGs2KyPzUXIyQ4qkJ8yaugtNY7wZheBRLcc27lA=; b=qW5IPn35F8nukUqmWvH8tEGUEBUGE/PK5DecfTzcxSlbCR1wPxH/o6tP1EVRK1VnR/Hvt+uHn4IGAz437QciGSGRZu5JsY9SnvxpXwGm0ZWcAOp+zN+lasrz2w0VyNN4S2UwfjOHCZnVh8eL4malGXWnBRlSrH+P93/yPz2PJF+Tky61lsEHtAHVpTGpYypK+JmsKlrv91q5sHIwesYw4nadGOhy7Zy/dAtj2JeUB+foKSjRbXkpjKZ18ejEiut3jlQ9e6HQNgMEMzBrLIgC8Pecjr/nrcaja3QDGtA6jmFhzBDSVtVunRq19Qz2M7Ll3JO6DUJuQ2KapVNLLOcO8A== Received: from PH0PR06MB7351.namprd06.prod.outlook.com (2603:10b6:510:4e::23) by PH0PR06MB7270.namprd06.prod.outlook.com (2603:10b6:510:2c::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4415.18; Thu, 19 Aug 2021 07:51:42 +0000 Received: from PH0PR06MB7351.namprd06.prod.outlook.com ([fe80::2841:1c86:e93:a5ac]) by PH0PR06MB7351.namprd06.prod.outlook.com ([fe80::2841:1c86:e93:a5ac%5]) with mapi id 15.20.4415.024; Thu, 19 Aug 2021 07:51:42 +0000 From: "Eggert, Lars" To: Eliot Lear CC: "rfced-future@iab.org" Thread-Topic: [Rfced-future] Proposed Disposition of Issue 46: Lars comments Thread-Index: AQHXkOwroqRCcOIDp0SQMGW2g3DinKtyujkAgAfCBoA= Date: Thu, 19 Aug 2021 07:51:42 +0000 Message-ID: References: <1a8d5cba-8718-b740-819c-2e4e02babcdc@lear.ch> <5b161988-8c9a-cb62-889e-eb8dc16fe03c@lear.ch> In-Reply-To: <5b161988-8c9a-cb62-889e-eb8dc16fe03c@lear.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3654.120.0.1.13) authentication-results: lear.ch; dkim=none (message not signed) header.d=none;lear.ch; dmarc=none action=none header.from=netapp.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cbf63376-a579-453d-a849-08d962e62f2a x-ms-traffictypediagnostic: PH0PR06MB7270: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 4JPeYQQfSe/ac6zZBGW0Y3DZ567XkYoXJ77Kaw8t6ugiSvIOnT1Vv6CpSsnvWgNV45eq5fdU8AV9qoT1cwuSEXzXvTyDnksYeoMe5+AJvf+Xo8R3zRk4pbGkSYLcEuNCyrSwUetxpw6dlWE7cBP6O/s74mTkeFtHb9G8MJtriA1p4EAsBPlHkM9Rc1SsQObLPDR71ZjScObaT0nmlsnzmma7YGHeuxsjNEz3h03AT44qAL/ADFsPcgvuk+/NN7ySd+To1HGxH7H23g+kX7mJRZIXJq6fXt+3v0bKHY1uKKQ70cI4Gc/yezEjkIJgQiFqsrjOjznPMOxw7mUBrMf9eCq+ancJgGAzb8fIcmMMrJTLceiOoWrzL85jA0LXunTZZ7UxGz1yCQUnuyPMpabYz+Mo7D37N/qTzJD2D5Ww/faFzVn7H5O7oRLdl0iqe5J6KQPaL0kNMxtjg+nkwGQTnXEfXpbtpd1IGXs8DcGITGGUcKiWirQNixtyf3FQZcucrWlMxIWfM2RP2WzmXhGg2xTHVHzUE3b3xsrQyPz1rw/78AqS25tVjyPmW1AiWxEoIcxP72aX/Wk9VSU5TpcKmAugvLQenevOQfMCwtlcvGLnF+RPOl0u9GbpfyBlJ0nGVuTsJRExp4+pg/p/X2YX3KpQpDc/AmO2b2by/bD/2lQSphx8VwbrlBkpTqTNxkEg5br81Mjkd3S2M/5n4jS2FsOhzyz1sQmCLXhJVejABXlP33QKSek11+UL2ebMqn8K x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR06MB7351.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(86362001)(6506007)(33656002)(53546011)(6512007)(66446008)(316002)(5660300002)(66556008)(6486002)(71200400001)(508600001)(38100700002)(122000001)(6916009)(186003)(83380400001)(38070700005)(2906002)(76116006)(91956017)(66476007)(66946007)(66616009)(2616005)(4001150100001)(8676002)(36756003)(8936002)(4326008)(64756008)(99936003)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?WERvd2NKU1NyQXBCL0pHWkxxR0Q0amhaQWxLaEZNdDBwOFFHSy9WM2kyTW9I?= =?utf-8?B?Y0dmVVdUVGprUnFzVDNyTXRIQ3p5VTQ3cXVkRkZYRkRGNmdwVDhrWXEyNUlU?= =?utf-8?B?TVBjelJBTWRYVDFwQlpIcjhXMXpEWEx1TXVuWmNRc3NHK3NabUVOVzJYTkRU?= =?utf-8?B?OXVwM1krWW1FcFNnekQwQnA4L3JrdDQ5R0Zkb3RwazRXUUwyTk8xdFZvQ2hH?= =?utf-8?B?M3dXU0duOWpLK1JobGNSLzJKb2lSckZObFlRL2JDYXQ1ODVraHprcXB3OUxW?= =?utf-8?B?ZDJwNHozU0JGT2dOSUFkcXVJeUNlRGhUN1NLaWthTzhBekFlYWlRZUtiZEU2?= =?utf-8?B?U0lEallyRUYvdnZwRDVIL0ZTdlRXQzlGR3Zxa2oxYU41QmpSQ3g3bWpGZ21r?= =?utf-8?B?cDVkT28vMU5pbXl2aVR5S3Y2MEtWOEx4UnYvbXJMK3VMSXJZeUF6Sm0yT0Rn?= =?utf-8?B?NXlrMjduSVN5TXJpSXVsaFUzRGJWMXp3MHBhYmhpOW9CL3pvTUJiNUFsaXJa?= =?utf-8?B?dloyMHdGb0lNdmlFekcvSVRKazBxTWkxS3dLSDJWems1ZlpjRW84eGJpNG5y?= =?utf-8?B?UXZMYlJYRTFhbjR2emc2Q3U0RG1ZR2tXekdibTFYTnFiaWxraDlIUnVpVjZh?= =?utf-8?B?dnk1QnRvMzc0aXlUa3U3eHFTbkNYYkM2c2MvUkhNdDhFM2ZieVl5OWRKazhO?= =?utf-8?B?bm9rZWVIUUZsNGQ1aEJBOVpRK2t1VHIwcCtHdkMwbXgvUkVIelRHdVk2WkVz?= =?utf-8?B?ZU9Hb1lLeDE3UFltZVVOYTJYU3lWdWVnVlVNR1R4ZUVwMWROMElUYXBmRTVh?= =?utf-8?B?VE9NdUMzNEJqa2J0UHZnOGFicnFlNENzOG5ocHAvMWtDSEpZTWV5WWhsbFMx?= =?utf-8?B?RWFzUXlERm5ub3grYzAzZUZKU1F2a2lxWG03RVNUdytQQ1Bkcmp4d1FYSHpY?= =?utf-8?B?S3c5dUE4Q0dST3JQcUNzYzlDSVhiRGNNVmx1dXovSWlGcFVaMkcrWWVucHhN?= =?utf-8?B?QjJPeTN1T2s5aDNjY3ZVUDVoSWFFVkczOGdoY1NHTTNjNXRoTUlkL2cyK1FZ?= =?utf-8?B?N3M5UTBkZUVKYWVZREdzV3o0ajZKYklQVi9HcWlEa3F1c0dqV2dTWWd4ZDJr?= =?utf-8?B?TWw2azYxeFhhSk1TMnBqSDNFQ2Z4YlFuOGQzTEZwOXd0eEN4TnEvT1BmUGdP?= =?utf-8?B?eURSdEJUdWtIb1JQSlBTcHFNRHNCWTFjd29jMkNnNXEvMUdpamR5Y3RqdE1l?= =?utf-8?B?MXE1OTlOQlM1aG1zVGlUakZqczdXaktRTDhtZHY1MnNUY3ZjaTgyTkcxVGQ0?= =?utf-8?B?cCtHd0Q5K1YxTUZielFqYUptbDlUYW02TDc0MzBSVXI2cDgyZi9UTFUxYndP?= =?utf-8?B?Y3FGQURyeW1zZjdrMjJDckJZNHkrdGlQM085NnJDUDRYSStJa3hxczAvYi9T?= =?utf-8?B?YTV2SHBBWE1IRXh4OFRtdkZPM0dDeC9qWmw5Q1dhZXJ0b3JJbGplWjVvTXM3?= =?utf-8?B?R3ZYUkJGMDhHeWJLdjlQOWlhS3dzd1dsSVRPU1BCcFFQTm5BcWlFN2tVTGc2?= =?utf-8?B?MElTTjlROWZFQUltY2dUNlkzNW0rejcrU3FpVXJEbUUzUVpWczZTWGVySlZ3?= =?utf-8?B?Umxqc0ZIbzNhNFo0OTN4ajBQL0p5OVpXaG5iVGhBdmV4UjJvWURRMmF2SE1q?= =?utf-8?B?V2pFazRiSVpSdXdYM2VEK1ZEWDNpOVpyRmpqTFZqcWJGSURneHd1RlFBMHFT?= =?utf-8?B?VG9jbk5xREhTb1AzM3RmellKQ3I3L01meW5La0tBekNFb1pVN29ubEl4TTNa?= =?utf-8?B?U3pPYlhlKzJQOHZ5QUQ2MDBna0FKQktjQk1RclFCMU14ekZGK0RDRmFjOEZq?= =?utf-8?B?b1M1OFhoR2lhUjJuakkwUjVHOE0xdjFnbWIySGtlTzFpTFE9PQ==?= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; boundary="Apple-Mail=_9473452F-6457-4128-8393-7DC8F5F4AFB2"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-OriginatorOrg: netapp.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR06MB7351.namprd06.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: cbf63376-a579-453d-a849-08d962e62f2a X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Aug 2021 07:51:42.1616 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: OCAaeGZImvTr+sk3vP2+AgC5jJo4C+tALoBQoJYdDVth6BMToYjnDrGYAdM+Enb9/7zHGuwxS2Adi9RtXhTlzw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR06MB7270 Archived-At: Subject: Re: [Rfced-future] Proposed Disposition of Issue 46: Lars comments X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2021 07:51:51 -0000 --Apple-Mail=_9473452F-6457-4128-8393-7DC8F5F4AFB2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, thanks for going through these - I agree with the resolutions (and that = one remains open, per below). Thanks, Lars > On 2021-8-14, at 12:23, Eliot Lear wrote: >=20 > Signed PGP part > One correction: >=20 > On 14.08.21 11:09, Eliot Lear wrote: >> Section 5.1.2, paragraph 4, comment: >>> The voting members of the RSAB shall be as follows: >>>=20 >>> Are there members other than voting members on the RSAB? If not, = just call them >>> members? If yes, who are they? >>>=20 >> We have from time to time discussed liaisons. I do not think we have = fully closed this matter, however. I propose to create a new issue. >>=20 > We actually did discuss this and came to conclude the following, which = is in the document: >=20 >=20 >> To ensure the smooth functioning of the RFC Series, the RSAB shall >> include the IETF Executive Director as a non-voting member since = the >> IETF LLC is ultimately responsible for the operation of the policy >> implementation function >=20 > Therefore, I propose to close this as well as addressed. That just = leaves the RSWG name as a new issue. >=20 > Eliot >=20 >=20 >=20 >>=20 >>=20 >>> Section 5.1.2, paragraph 7, comment: >>> Is there an intention for the RSAB to gain additional (voting) = members >>> if new RFC streams are created in the future? >>>=20 >> We have discussed this issue and said that this would be a matter for = the stream definition RFC. >>=20 >>> Section 5.2.2, paragraph 18, comment: >>>=20 >>> =E2=80=A2 If a CONCERN exists, discussion will take place within = the RSWG. >>> Again, all RSAB members MUST participate. >>> This is an unenforceable MUST. >>>=20 >> This text has been changed to say: >>=20 >> > Again, all RSAB members are expected to participate. >>=20 >> I propose that this issue is addressed. >>=20 >>=20 >>=20 >>> Section 5.2.2, paragraph 18, comment: >>> 2. If all CONCERN positions are addressed, then the proposal is >>> approved. Again, if substantial changes have been made, an >>> additional call for community input should be made. >>>=20 >>> It's not quite clear what "addressed" means. It would be clearer to = say "A >>> proposal without any CONCERN positions is approved." >>>=20 >> The text now reads: >>=20 >>=20 >>> 2. A proposal without any CONCERN positions is approved. If >>> substantial changes have been made in order to address = CONCERN >>> positions, an additional call for community input might be >>> necessary. >> I proposed that this issue is addressed. >>=20 >>=20 >>=20 >>> Section 6.1, paragraph 2, comment: >>> process in confidence. The initial length of service shall be for >>> one year, but then further extensions will be for three to five >>> years. >>>=20 >>> It will IMO be difficult to hire the desired senior professional on = a one-year >>> contract. >>>=20 >> This text has been removed. I propose that this issue is addressed. >>=20 >> Eliot >>=20 >>=20 >=20 >=20 >=20 --Apple-Mail=_9473452F-6457-4128-8393-7DC8F5F4AFB2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmEeDY0ACgkQVLXDCb9w wVdoehAAuR+Z9MU4Ryr2OL60Bvyz4/EUSLN00GYEKsKypgsp7JQSm8Uo3rQ9R0Rn dB2qouurVX983+Dc3PuoAgxluQh+NjrB2fG1xkOs5m6MlZktVET5lDQMYzjF7p9D DHbrvuMQ8WPt4lp+oV0mJ+v2w3vKKYvhU/qL28iBY8BnbKzZyZe360n1Y2dO60QY 2ZPQyAdIdzBjVIM+ztt9Qzp7I9TXCeGL4GxtDVx0X7rVAuh698mrwGyxGGCpd0Mm X08QLbCdRAzu6dd4rrEsJ8HfbGkE9TATOpgBDsPnhA9Fi354NrG+chZhztdDw/dT OF/FUFJgFuF1COVl++VPrPHL9MPiZbCkmqb3qzITJ784UvyJBlBcs4dj/py1r/x7 NO+p80JRRaOoqS+uHkUHVPsD52HT0sIvH9b1peM1Tw/WU7Gn6PZ3+NgOXWC+9W2X udoQGnAN3RDoTtuVLLyVAk7b9xk8uCxvnzNllJKe1ClcW7pNhhBTXtJAjwY13FcA yluQnBk5OvxUjRSypp8uMP0nqdxSpk4lBBd19tL9/8Q+G6pWpRUD5a/mdjtA50gi 1L3CDlxDhd0Uk9aLbkHTA6WA4kk3QN4rboNulijA5Jws1oRdHv+1jeMnhEABeXyN n43pY9kMSu7SdtPBqOl/F77FCgisD66Sx35wV2JHmwxbXPOBo/0= =EUa8 -----END PGP SIGNATURE----- --Apple-Mail=_9473452F-6457-4128-8393-7DC8F5F4AFB2-- From nobody Thu Aug 19 01:15:38 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7759D3A087F for ; Thu, 19 Aug 2021 01:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org 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 TojIKn6x2SGA for ; Thu, 19 Aug 2021 01:15:30 -0700 (PDT) Received: from mail.eggert.org (mail.eggert.org [IPv6:2a00:ac00:4000:400:211:32ff:fe22:186f]) (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 B4DC63A087D for ; Thu, 19 Aug 2021 01:15:30 -0700 (PDT) Received: from smtpclient.apple (unknown [IPv6:2a00:ac00:4000:400:21f6:18fc:5ac9:4ac4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 76F3F600370; Thu, 19 Aug 2021 11:15:10 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1629360910; bh=c8oLEA+dX4M0liI55iFniaOqvusIeym39doWjPr8uho=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=jt8hsf9Aeo3yjaOjUp2Ns4SE2ZldEVTZBDkBBr7wXioa9f/BZzHjcC6Kx9UQpYV6m HTVMJ3S+imYoFfoXWSHj7kkZNatwV4YRwAcpo3X9fBs5Gsxmx/1cl9iiZplvnm9Pbd 8x4J220oARhZ3c1KQVMWd8uLmRoyEhKbWURsqK3o= From: Lars Eggert Message-Id: <002D1322-C65A-448D-BFA3-A0BA884AE0C4@eggert.org> Content-Type: multipart/signed; boundary="Apple-Mail=_51C6483B-5B33-4812-BAE6-7D09B4D55CE0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Thu, 19 Aug 2021 11:15:09 +0300 In-Reply-To: <1876a06a-4a53-1c25-def5-d66d80dfb7e5@lear.ch> Cc: "rfced-future@iab.org" To: Eliot Lear References: <1876a06a-4a53-1c25-def5-d66d80dfb7e5@lear.ch> X-MailScanner-ID: 76F3F600370.AF4B1 X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [Rfced-future] New issue 79: Style guide handling X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2021 08:15:37 -0000 --Apple-Mail=_51C6483B-5B33-4812-BAE6-7D09B4D55CE0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2021-8-13, at 0:08, Eliot Lear wrote: > The style guide consists of RFCs and other documents[1]. The text in = the draft doesn't quite cover that. The RFCs in question are RFC 7322, = RFC7997, and RFC 7841 (boiler plate). They are currently in the IAB = stream. We should probably explicitly decide to redirect some or all of = these to the Editorial Stream. With regard to the things that are not = RFCs (abbreviations list, terms, and a few other things), the model we = have seems to indicate that these documents would go to the RPC unless = and until the RSWG and RSAB say otherwise in a new policy RFC. also with regards to things that are not RFCs, there is the "Guidelines = to Authors of Internet-Drafts", which are currently being revised at = https://github.com/ietf/id-guidelines, and which are technically owned = by the IESG. There is of course some overlap between the various parts that make up = the "RFC style guide" and the "I-D guidelines", and it would IMO be a = service to authors if the two didn't diverge and ideally were = practically identical (apart from minor RFC specifics). Thanks, Lars --Apple-Mail=_51C6483B-5B33-4812-BAE6-7D09B4D55CE0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmEeEw0ACgkQVLXDCb9w wVdbwxAAtgxm4dcOt4fumnB4nxSGH3kGMW4yKIZMdD1ESWF5eV2hU7fiPV5vCujE /p+buu1ljOSoYsOYXrsJ7y/xGdqlbgaFuv7YW79ftTNCK4ek5+sP8QuM6YIlcXe+ sVrgI4tOWOqc1uxd/+Cy0sBfYMZAoAvjXdguLzjnRv+UsIFoJKGodu8kq4RCrri2 JFMefpppx8FuuSgNKqaUOouxf7VCohULTNXAOEfaxyh+lIlbL5ot8Of5mvDiAK/C NY5S4JmbPPybTXWES1dcN4h+A7WJ7B+zvBcFxR1ZMUb80EXJuJxwrARvQbUBMspU FvaDr8AemVcdhPh5BVjr89VjnmaGAU7m+YCcpz2HKIaxRepuTMx/cEOJkcIAjJQa ZPRMx8AGVLZgzGYcmFfqvX04Xx9VmInGoXRoGjgwYQTYkrzB4NAD67b/v7tuVrso plZVl/HdPocsnl6+6x2f9gxoq4xnt79b55ZoZRlA9ESPw6U1tcna2pYLCItomgGA l8uUxLESK3HPRcidM6yiuIY/LmbHtTlHkkr2Tf2+9tC3+DjEOcexVIUqDdpaQ9Gf hv8cy1lgZgrJF/LWIR9h9TWvDGNtqYQOy9IcTHMxjtX4kITzqUJnbqTrR8+2iOdx NBieBMGIv6Q1qDVvDIbxDZx1oNEdURzGKICTEv+v65PZqi/q/2Q= =u6FR -----END PGP SIGNATURE----- --Apple-Mail=_51C6483B-5B33-4812-BAE6-7D09B4D55CE0-- From nobody Thu Aug 19 05:14:28 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E39F13A115F; Thu, 19 Aug 2021 05:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 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, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch 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 nFaFrBnNn-nJ; Thu, 19 Aug 2021 05:14:19 -0700 (PDT) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 164343A1164; Thu, 19 Aug 2021 05:14:17 -0700 (PDT) Received: from [IPv6:2001:420:c0c0:1011::2] ([IPv6:2001:420:c0c0:1011:0:0:0:2]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 17JCED03065617 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Thu, 19 Aug 2021 14:14:13 +0200 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1629375254; bh=l+hAqVlq8aOodBafcZHBJYBoM06aB8a6i3usWaJ6m0s=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=WQ5PzdWIwffRVVRPI5C70hs84F2//3aVl7iLXC1O+a8SqlX6exYXHDExYLY03nTil 6gDdLEBrs+tLerDnx8cTyNT0JMw7mcTMMwgkWrPsB13kS13i9OhqjbUuUBucuhlY95 5G00bz6L5M3Br1NU4wgXnWTBYYpg5w670rnZGQig= To: Jay Daley , Brian E Carpenter Cc: rfced-future@iab.org, Mirja Kuehlewind References: <996b71fc-6ebd-06a1-9a0a-2695a6044381@nthpermutation.com> <4ad09680-b067-4475-9232-e8f69101e7c0@lear.ch> <3295300e-d396-36fc-2137-6452de7f5296@nthpermutation.com> <848d287a-d2e5-7e61-90c4-e3718c010906@gmail.com> <086c5844-ef49-4221-94f2-67408182c6a6@it.aoyama.ac.jp> <3b86de0d-6823-c740-7928-4258a420d990@gmail.com> <173EC03C-E7C8-4965-AABB-49DAF4002F48@ietf.org> From: Eliot Lear Message-ID: <5a47b37b-234e-a0d5-e529-6de68e0177c6@lear.ch> Date: Thu, 19 Aug 2021 14:14:12 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <173EC03C-E7C8-4965-AABB-49DAF4002F48@ietf.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="JDkmJW7HoGMBkvI0KHANFWASRxnXGMbUW" Archived-At: Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2021 12:14:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --JDkmJW7HoGMBkvI0KHANFWASRxnXGMbUW Content-Type: multipart/mixed; boundary="ZCcpRvNvKnEpzodOF5NM1CAALl6takuIj"; protected-headers="v1" From: Eliot Lear To: Jay Daley , Brian E Carpenter Cc: rfced-future@iab.org, Mirja Kuehlewind Message-ID: <5a47b37b-234e-a0d5-e529-6de68e0177c6@lear.ch> Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 References: <9114EB06-AB70-4E6A-A72B-0D7D5867C74A@ietf.org> <538d1ce7-6e4b-fea0-f04b-36669c43dec1@nthpermutation.com> <996b71fc-6ebd-06a1-9a0a-2695a6044381@nthpermutation.com> <4ad09680-b067-4475-9232-e8f69101e7c0@lear.ch> <3295300e-d396-36fc-2137-6452de7f5296@nthpermutation.com> <848d287a-d2e5-7e61-90c4-e3718c010906@gmail.com> <086c5844-ef49-4221-94f2-67408182c6a6@it.aoyama.ac.jp> <3b86de0d-6823-c740-7928-4258a420d990@gmail.com> <173EC03C-E7C8-4965-AABB-49DAF4002F48@ietf.org> In-Reply-To: <173EC03C-E7C8-4965-AABB-49DAF4002F48@ietf.org> --ZCcpRvNvKnEpzodOF5NM1CAALl6takuIj Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Ok. I think where we are on this issue is that some would like to see LESS=20 detail about how the work programme is managed.=C2=A0 Jay has made the po= int=20 below about stating the high level principles to be adhered.=C2=A0 Can I = ask=20 Mirja and Brian perhaps to work together to come up with whatever=20 substitute text they think the right level should be? We can then discuss and perhaps wordsmith this at the interim next week. Eliot On 17.08.21 06:31, Jay Daley wrote: > > I think that=E2=80=99s inconsistent with the level of specification in = the rest of this RFC but consistent with others that cover the LLC. If t= he group chooses to go that way, then I would suggest that there are some= general requirements set in this document to ensure that someone in the = future doesn=E2=80=99t do away with things the community feels is importa= nt. > > Some examples: > > - the RPC/LLC is expected to implement any and all RFCs that come from = the RSWG > - the priorities of the RPC must reflect those of the community > - the RPC priorities and plans are public and consulted on > - no constraints on how the RPC communicates with the community or vice= -versa > > Jay >> Regards >> Brian >> >> On 17-Aug-21 00:14, Mirja Kuehlewind wrote: >>> Hi Jay, hi all, >>> >>> Replying to this original mail. The additional text is helpful to bet= ter explain what is meant by work program. >>> >>> I=E2=80=99m still slightly concerned that we are over-specifying this= in the RFC. I think the process as described is fine, but writing it dow= n in an RFC means we can't easily change anything in future if we see roo= m or need for optimisation. >>> >>> However, if other people feel it=E2=80=99s important to have it in th= is >> level of details in this RFC, the text looks fine for me. >>> Three small comments/questions below. >>> >>> >>>> On 28. Jul 2021, at 00:48, Jay Daley wrote: >>>> >>>> Eliot asked me to propose some additional text to close off issues #= 56, #57, #61, #62 which I=E2=80=99ve done below. It doesn=E2=80=99t have= the elegance of Peter=E2=80=99s prose so may require some work to align = with that. >>>> >>>> Much of this is already covered in the latest draft at: >>>> >>>> https://github.com/intarchboard/program-rfced-future/blob/master/dr= aft-iab-rfcefdp-rfced-model.md#roles-and-processes >>>> >>>> My suggested additions are in red and my suggested text moves are in= blue. >>>> >>>> Jay >>>> >>>> =E2=80=94=E2=80=94 >>>> >>>> ## Role of the RPC >>>> >>>> Publication of RFCs shall be continue to be handled by the RFC Produ= ction Center (RPC) function in accordance with high-level policies curren= tly in force or yet to be defined following the processes specified in th= e foregoing sections of this document. >>>> >>>> ### RPC work program >>>> >>>> The RPC follows a work program based on requirements it has gathered= from a variety of sources, including policies that have been through the= RSWG/RSAB process, and from direct discussions with the RSEA, stream man= agers, IETF LLC, authors and other IETF participants. In developing this= work program, the RPC makes some key decisions which impact the IETF com= munity: >>>> >>>> 1. For each requirement that is gathered, can it be directly incorp= orated into the work program or must it first be subject to community con= sultation. >>>> >>>> 2. Setting the relative priorities for the various requirements wit= hin the work program. >>>> >>>> 3. Determining if all the important requirements have been gathered= =2E >>>> >>>> It is likely that the RPC will require advice during the drafting of= its work program, which it should seek from at least the RSAB and if req= uired, the chairs of the RSWG. >>> Why are the chairs or the RSWG mentioned here? I guess the RPC is fre= e to ask anybody for advise they want but the main contact point for me w= ould be the RSAB (given it includes the stream managers). >>> >>>> In order to ensure community oversight of the RPC work program: >>>> >>>> * The RPC must present a draft work program for community feedback a= t least annually and then publish a final work program incorporating any = agreed feedback. >>> How and with whom is the feedback agreed? >>> >>>> * The RPC shall report regularly to the RSAB, RSWG, and broader comm= unity regarding the contents and progress of its work program and any key= risks or issues affecting it. >>> How does the RPC report to the broader community. Isn=E2=80=99t it en= ough to report to RSWG? >>> >>>> In the event that the RPC is required to make a decision without con= sultation that would normally deserve consultation, or makes a decision a= gainst the advice of the RSAB, then it must notify the RSAB. >>>> >>>> All matters of budget, timetable and impact on its performance targe= ts, are between the RPC and IETF LLC. >>>> >>>> ### Relationship between the RPC and the IETF LLC >>>> >>>> This document does not specify the exact relationship between the IE= TF >> LLC and the RPC function; for example, the RPC function could be provi= ded >> by a separate corporate entity under contract to the IETF LLC, it coul= d be performed by employees of the IETF LLC, or the IETF LLC could work w= ith >> independent contractors for some or all aspects of the RPC function. T= he exact relationship is a matter for the IETF LLC and the IETF Executive= Director to determine. >>>> The IETF LLC has authority over negotiating performance targets for = the RPC and also has responsibility for ensuring that those targets are a= dhered to. The IETF LLC is empowered to appoint a manager or to convene a= committee to complete these activities. >>>> >>>> Community members who have concerns about the performance of the RPC= can request that the IETF LLC look into the matter. Even if the IETF LLC= opts to delegate this activity, concerns should be raised with the IETF = LLC. The IETF LLC is ultimately responsible to the community via the mech= anisms outlined in its charter. >>>> >>>> =E2=80=94=E2=80=94 >>>> >>>> --=20 >>>> Jay Daley >>>> IETF Executive Director >>>> jay@ietf.org >>>> >>>> --=20 >>>> Rfced-future mailing list >>>> Rfced-future@iab.org >>>> https://www.iab.org/mailman/listinfo/rfced-future --ZCcpRvNvKnEpzodOF5NM1CAALl6takuIj-- --JDkmJW7HoGMBkvI0KHANFWASRxnXGMbUW Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmEeSxQFAwAAAAAACgkQh7ZrRtnSejNq UQf/W9nQ4NSe0I3UuiSpNwRezejSzOIdkcV7y2442KP9pV5vGqvaAoOrZlP95hbzUdTf7XHaAB6K HqvUhHZXdWFHr1LPLYwZd9RgvzDISJKiMQCRL4KmNPqDijGHyshS18sJdqsML4W9yZqwAeoZXyCb jUq9jBQvmHfm4ZRb5wHT/hPftrJQPaAN9zlzJQeZtvhv4uB2IhI0wXeYxjsfOCNUj8NcAfror1W6 gKycGa3Wz0KSkyCkGdAatPMhAhg6yiRprdqtJBkrpbVxRVlkiTD97J3aAGrqcr3Ce7JNIqBvxLrN zpJIv2xY5I11rsO4HFazAJ5jac7DQnOB5MbmmtJQAQ== =Y1x8 -----END PGP SIGNATURE----- --JDkmJW7HoGMBkvI0KHANFWASRxnXGMbUW-- From nobody Tue Aug 24 02:20:36 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 535DB3A18F1; Tue, 24 Aug 2021 02:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 fTMTWiPXxinA; Tue, 24 Aug 2021 02:20:27 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6DBC3A18EE; Tue, 24 Aug 2021 02:20:26 -0700 (PDT) Received: from p200300dee734c300f877e77634d82596.dip0.t-ipconnect.de ([2003:de:e734:c300:f877:e776:34d8:2596]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1mISbV-0002Dr-GR; Tue, 24 Aug 2021 11:20:21 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Mirja Kuehlewind In-Reply-To: <5a47b37b-234e-a0d5-e529-6de68e0177c6@lear.ch> Date: Tue, 24 Aug 2021 11:20:20 +0200 Cc: Jay Daley , Brian E Carpenter , Eliot Lear Content-Transfer-Encoding: quoted-printable Message-Id: References: <996b71fc-6ebd-06a1-9a0a-2695a6044381@nthpermutation.com> <4ad09680-b067-4475-9232-e8f69101e7c0@lear.ch> <3295300e-d396-36fc-2137-6452de7f5296@nthpermutation.com> <848d287a-d2e5-7e61-90c4-e3718c010906@gmail.com> <086c5844-ef49-4221-94f2-67408182c6a6@it.aoyama.ac.jp> <3b86de0d-6823-c740-7928-4258a420d990@gmail.com> <173EC03C-E7C8-4965-AABB-49DAF4002F48@ietf.org> <5a47b37b-234e-a0d5-e529-6de68e0177c6@lear.ch> To: rfced-future@iab.org X-Mailer: Apple Mail (2.3608.120.23.2.4) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1629796827;3bdf459d; X-HE-SMSGID: 1mISbV-0002Dr-GR Archived-At: Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2021 09:20:34 -0000 Brian and I have been working on some text proposal. This text is mainly = based on the current text in the draft and Jay=E2=80=99s proposal for = requirements but avoids the term work program. Here it is: -------- # Roles and Processes ## RFC Production Center (RPC) Publication of RFCs shall continue to be handled by the RFC Production = Center (RPC) function in accordance with high-level policies that have = been=20 specified through the RSWG/RSAB process as well as based on advice from = direct discussions with the RSEA, stream managers, IETF LLC, authors and = other community memberss in cases where the implementation of a policy = is not clear or not sufficient. The RPC shall proactively implement the policies specified by the = RSWG/RSAB process reflecting the priorities of the community. The RPC = shall report regularly to the RSAB, RSWG, and broader community = regarding their plan and time line for implementation as well as any key = risks or issues affecting it. The RPC is expected to revise their plan = based on community input if concern regarding the implementation plan = or priorities of work are raised. In case of conflicting requirements = from the community, the RPC shall consult with the RSAB. This document does not constrain how the RPC and the community = communicate with each other. In the event that the RPC is required to = make a decision without consultation that would normally deserve = consultation, or makes a decision against the advice of the RSAB, then = it must notify the RSAB. All matters of budget, timetable and impact on its performance targets, = are between the RPC and IETF LLC. ### Relationship between the RPC and the IETF LLC This document does not specify the exact relationship between the IETF = LLC and the RPC function; for example, the RPC function could be = provided by a separate corporate entity under contract to the IETF LLC, = it could be=20 performed by employees of the IETF LLC, or the IETF LLC could work with = independent contractors for some or all aspects of the RPC function. The = exact relationship is a matter for the IETF LLC and the IETF Executive = Director to determine. The IETF LLC has authority over negotiating performance targets for the = RPC and also has responsibility for ensuring that those targets are = adhered to.=20 If individuals or groups within the community have concerns about the = performance of the RPC, they can request that the IETF LLC look into the = matter. Even if the IETF LLC opts to delegate this activity, concerns = should=20 be raised with the IETF LLC. The IETF LLC is ultimately responsible to = the community via the mechanisms outlined in its charter. -------- > On 19. Aug 2021, at 14:14, Eliot Lear wrote: >=20 > Ok. >=20 > I think where we are on this issue is that some would like to see LESS = detail about how the work programme is managed. Jay has made the point = below about stating the high level principles to be adhered. Can I ask = Mirja and Brian perhaps to work together to come up with whatever = substitute text they think the right level should be? >=20 > We can then discuss and perhaps wordsmith this at the interim next = week. >=20 > Eliot >=20 > On 17.08.21 06:31, Jay Daley wrote: >>=20 >> I think that=E2=80=99s inconsistent with the level of specification = in the rest of this RFC but consistent with others that cover the LLC. = If the group chooses to go that way, then I would suggest that there are = some general requirements set in this document to ensure that someone in = the future doesn=E2=80=99t do away with things the community feels is = important. >>=20 >> Some examples: >>=20 >> - the RPC/LLC is expected to implement any and all RFCs that come = from the RSWG >> - the priorities of the RPC must reflect those of the community >> - the RPC priorities and plans are public and consulted on >> - no constraints on how the RPC communicates with the community or = vice-versa >>=20 >> Jay >=20 >>> Regards >>> Brian >>>=20 >>> On 17-Aug-21 00:14, Mirja Kuehlewind wrote: >>>> Hi Jay, hi all, >>>>=20 >>>> Replying to this original mail. The additional text is helpful to = better explain what is meant by work program. >>>>=20 >>>> I=E2=80=99m still slightly concerned that we are over-specifying = this in the RFC. I think the process as described is fine, but writing = it down in an RFC means we can't easily change anything in future if we = see room or need for optimisation. >>>>=20 >>>> However, if other people feel it=E2=80=99s important to have it in = this >>> level of details in this RFC, the text looks fine for me. >>>> Three small comments/questions below. >>>>=20 >>>>=20 >>>>> On 28. Jul 2021, at 00:48, Jay Daley wrote: >>>>>=20 >>>>> Eliot asked me to propose some additional text to close off issues = #56, #57, #61, #62 which I=E2=80=99ve done below. It doesn=E2=80=99t = have the elegance of Peter=E2=80=99s prose so may require some work to = align with that. >>>>>=20 >>>>> Much of this is already covered in the latest draft at: >>>>>=20 >>>>> = https://github.com/intarchboard/program-rfced-future/blob/master/draft-iab= -rfcefdp-rfced-model.md#roles-and-processes >>>>>=20 >>>>> My suggested additions are in red and my suggested text moves are = in blue. >>>>>=20 >>>>> Jay >>>>>=20 >>>>> =E2=80=94=E2=80=94 >>>>>=20 >>>>> ## Role of the RPC >>>>>=20 >>>>> Publication of RFCs shall be continue to be handled by the RFC = Production Center (RPC) function in accordance with high-level policies = currently in force or yet to be defined following the processes = specified in the foregoing sections of this document. >>>>>=20 >>>>> ### RPC work program >>>>>=20 >>>>> The RPC follows a work program based on requirements it has = gathered from a variety of sources, including policies that have been = through the RSWG/RSAB process, and from direct discussions with the = RSEA, stream managers, IETF LLC, authors and other IETF participants. = In developing this work program, the RPC makes some key decisions which = impact the IETF community: >>>>>=20 >>>>> 1. For each requirement that is gathered, can it be directly = incorporated into the work program or must it first be subject to = community consultation. >>>>>=20 >>>>> 2. Setting the relative priorities for the various requirements = within the work program. >>>>>=20 >>>>> 3. Determining if all the important requirements have been = gathered. >>>>>=20 >>>>> It is likely that the RPC will require advice during the drafting = of its work program, which it should seek from at least the RSAB and if = required, the chairs of the RSWG. >>>> Why are the chairs or the RSWG mentioned here? I guess the RPC is = free to ask anybody for advise they want but the main contact point for = me would be the RSAB (given it includes the stream managers). >>>>=20 >>>>> In order to ensure community oversight of the RPC work program: >>>>>=20 >>>>> * The RPC must present a draft work program for community feedback = at least annually and then publish a final work program incorporating = any agreed feedback. >>>> How and with whom is the feedback agreed? >>>>=20 >>>>> * The RPC shall report regularly to the RSAB, RSWG, and broader = community regarding the contents and progress of its work program and = any key risks or issues affecting it. >>>> How does the RPC report to the broader community. Isn=E2=80=99t it = enough to report to RSWG? >>>>=20 >>>>> In the event that the RPC is required to make a decision without = consultation that would normally deserve consultation, or makes a = decision against the advice of the RSAB, then it must notify the RSAB. >>>>>=20 >>>>> All matters of budget, timetable and impact on its performance = targets, are between the RPC and IETF LLC. >>>>>=20 >>>>> ### Relationship between the RPC and the IETF LLC >>>>>=20 >>>>> This document does not specify the exact relationship between the = IETF >>> LLC and the RPC function; for example, the RPC function could be = provided >>> by a separate corporate entity under contract to the IETF LLC, it = could be performed by employees of the IETF LLC, or the IETF LLC could = work with >>> independent contractors for some or all aspects of the RPC function. = The exact relationship is a matter for the IETF LLC and the IETF = Executive Director to determine. >>>>> The IETF LLC has authority over negotiating performance targets = for the RPC and also has responsibility for ensuring that those targets = are adhered to. The IETF LLC is empowered to appoint a manager or to = convene a committee to complete these activities. >>>>>=20 >>>>> Community members who have concerns about the performance of the = RPC can request that the IETF LLC look into the matter. Even if the IETF = LLC opts to delegate this activity, concerns should be raised with the = IETF LLC. The IETF LLC is ultimately responsible to the community via = the mechanisms outlined in its charter. >>>>>=20 >>>>> =E2=80=94=E2=80=94 >>>>>=20 >>>>> --=20 >>>>> Jay Daley >>>>> IETF Executive Director >>>>> jay@ietf.org >>>>>=20 >>>>> --=20 >>>>> Rfced-future mailing list >>>>> Rfced-future@iab.org >>>>> https://www.iab.org/mailman/listinfo/rfced-future >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future From nobody Tue Aug 24 03:01:29 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78BC13A1D94; Tue, 24 Aug 2021 03:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 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, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch 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 zbAUV6ybPt_m; Tue, 24 Aug 2021 03:01:20 -0700 (PDT) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECFB73A09FD; Tue, 24 Aug 2021 03:01:18 -0700 (PDT) Received: from [IPv6:2001:420:c0c0:1011::3] ([IPv6:2001:420:c0c0:1011:0:0:0:3]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 17OA1Dpo198404 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Tue, 24 Aug 2021 12:01:13 +0200 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1629799274; bh=jCywmGbHaizMQkqv2P2hcPw+QuSvSgr3nP0YJs1UAOU=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=XFSRbXaDeSSSc9WvLutGzQ7DMFYfM0+Q9Xt6Bg2TX3UAaF7MacLT3ggMAqjRVXgf3 XAFW4nfaVdWEjVUkd1HWX3v2/baieUGm8TVvrlIaUEplu6p5qatauc4HJU7sZG0xdm m/J9rEeNX0uKkq3j4BUCskkY4mFoA/egUt7QY3gQ= To: Mirja Kuehlewind , rfced-future@iab.org Cc: Jay Daley , Brian E Carpenter References: <4ad09680-b067-4475-9232-e8f69101e7c0@lear.ch> <3295300e-d396-36fc-2137-6452de7f5296@nthpermutation.com> <848d287a-d2e5-7e61-90c4-e3718c010906@gmail.com> <086c5844-ef49-4221-94f2-67408182c6a6@it.aoyama.ac.jp> <3b86de0d-6823-c740-7928-4258a420d990@gmail.com> <173EC03C-E7C8-4965-AABB-49DAF4002F48@ietf.org> <5a47b37b-234e-a0d5-e529-6de68e0177c6@lear.ch> From: Eliot Lear Message-ID: <6719c176-92fb-fbde-f5ce-6bdfbbafb68e@lear.ch> Date: Tue, 24 Aug 2021 12:01:11 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Fq8YFQI4OjlTW2Q6KoOVDe0Ryh47xAVM4" Archived-At: Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2021 10:01:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Fq8YFQI4OjlTW2Q6KoOVDe0Ryh47xAVM4 Content-Type: multipart/mixed; boundary="yJHoFOEmzcplSGve7MT7Dy5nsDhgrCFrf"; protected-headers="v1" From: Eliot Lear To: Mirja Kuehlewind , rfced-future@iab.org Cc: Jay Daley , Brian E Carpenter Message-ID: <6719c176-92fb-fbde-f5ce-6bdfbbafb68e@lear.ch> Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 References: <996b71fc-6ebd-06a1-9a0a-2695a6044381@nthpermutation.com> <4ad09680-b067-4475-9232-e8f69101e7c0@lear.ch> <3295300e-d396-36fc-2137-6452de7f5296@nthpermutation.com> <848d287a-d2e5-7e61-90c4-e3718c010906@gmail.com> <086c5844-ef49-4221-94f2-67408182c6a6@it.aoyama.ac.jp> <3b86de0d-6823-c740-7928-4258a420d990@gmail.com> <173EC03C-E7C8-4965-AABB-49DAF4002F48@ietf.org> <5a47b37b-234e-a0d5-e529-6de68e0177c6@lear.ch> In-Reply-To: --yJHoFOEmzcplSGve7MT7Dy5nsDhgrCFrf Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Mirja and Brian, Thanks very much for this.=C2=A0 Could people comment?=C2=A0 We'll also t= alk about=20 this at our interim. Eliot On 24.08.21 11:20, Mirja Kuehlewind wrote: > Brian and I have been working on some text proposal. This text is mainl= y based on the current text in the draft and Jay=E2=80=99s proposal for r= equirements but avoids the term work program. Here it is: > > -------- > # Roles and Processes > > ## RFC Production Center (RPC) > > Publication of RFCs shall continue to be handled by the RFC Production = Center (RPC) function in accordance with high-level policies that have be= en > specified through the RSWG/RSAB process as well as based on advice from= direct discussions with the RSEA, stream managers, IETF LLC, authors and= other community memberss in cases where the implementation of a policy i= s not clear or not sufficient. > > The RPC shall proactively implement the policies specified by the RSWG/= RSAB process reflecting the priorities of the community. The RPC shall re= port regularly to the RSAB, RSWG, and broader community regarding their p= lan and time line for implementation as well as any key risks or issues a= ffecting it. The RPC is expected to revise their plan based on community = input if concern regarding the implementation plan or priorities of work= are raised. In case of conflicting requirements from the community, the = RPC shall consult with the RSAB. > > This document does not constrain how the RPC and the community communic= ate with each other. In the event that the RPC is required to make a deci= sion without consultation that would normally deserve consultation, or ma= kes a decision against the advice of the RSAB, then it must notify the RS= AB. > > All matters of budget, timetable and impact on its performance targets,= are between the RPC and IETF LLC. > > ### Relationship between the RPC and the IETF LLC > > This document does not specify the exact relationship between the IETF = LLC and the RPC function; for example, the RPC function could be provided= by a separate corporate entity under contract to the IETF LLC, it could = be > performed by employees of the IETF LLC, or the IETF LLC could work with= independent contractors for some or all aspects of the RPC function. The= exact relationship is a matter for the IETF LLC and the IETF Executive D= irector to determine. > > The IETF LLC has authority over negotiating performance targets for the= RPC and also has responsibility for ensuring that those targets are adhe= red to. > > If individuals or groups within the community have concerns about the p= erformance of the RPC, they can request that the IETF LLC look into the m= atter. Even if the IETF LLC opts to delegate this activity, concerns shou= ld > be raised with the IETF LLC. The IETF LLC is ultimately responsible to = the community via the mechanisms outlined in its charter. > -------- > > > >> On 19. Aug 2021, at 14:14, Eliot Lear wrote: >> >> Ok. >> >> I think where we are on this issue is that some would like to see LESS= detail about how the work programme is managed. Jay has made the point = below about stating the high level principles to be adhered. Can I ask M= irja and Brian perhaps to work together to come up with whatever substitu= te text they think the right level should be? >> >> We can then discuss and perhaps wordsmith this at the interim next wee= k. >> >> Eliot >> >> On 17.08.21 06:31, Jay Daley wrote: >>> I think that=E2=80=99s inconsistent with the level of specification i= n the rest of this RFC but consistent with others that cover the LLC. If= the group chooses to go that way, then I would suggest that there are so= me general requirements set in this document to ensure that someone in th= e future doesn=E2=80=99t do away with things the community feels is impor= tant. >>> >>> Some examples: >>> >>> - the RPC/LLC is expected to implement any and all RFCs that come fro= m the RSWG >>> - the priorities of the RPC must reflect those of the community >>> - the RPC priorities and plans are public and consulted on >>> - no constraints on how the RPC communicates with the community or vi= ce-versa >>> >>> Jay >>>> Regards >>>> Brian >>>> >>>> On 17-Aug-21 00:14, Mirja Kuehlewind wrote: >>>>> Hi Jay, hi all, >>>>> >>>>> Replying to this original mail. The additional text is helpful to b= etter explain what is meant by work program. >>>>> >>>>> I=E2=80=99m still slightly concerned that we are over-specifying th= is in the RFC. I think the process as described is fine, but writing it d= own in an RFC means we can't easily change anything in future if we see r= oom or need for optimisation. >>>>> >>>>> However, if other people feel it=E2=80=99s important to have it in = this >>>> level of details in this RFC, the text looks fine for me. >>>>> Three small comments/questions below. >>>>> >>>>> >>>>>> On 28. Jul 2021, at 00:48, Jay Daley wrote: >>>>>> >>>>>> Eliot asked me to propose some additional text to close off issues= #56, #57, #61, #62 which I=E2=80=99ve done below. It doesn=E2=80=99t ha= ve the elegance of Peter=E2=80=99s prose so may require some work to alig= n with that. >>>>>> >>>>>> Much of this is already covered in the latest draft at: >>>>>> >>>>>> https://github.com/intarchboard/program-rfced-future/blob/master/= draft-iab-rfcefdp-rfced-model.md#roles-and-processes >>>>>> >>>>>> My suggested additions are in red and my suggested text moves are = in blue. >>>>>> >>>>>> Jay >>>>>> >>>>>> =E2=80=94=E2=80=94 >>>>>> >>>>>> ## Role of the RPC >>>>>> >>>>>> Publication of RFCs shall be continue to be handled by the RFC Pro= duction Center (RPC) function in accordance with high-level policies curr= ently in force or yet to be defined following the processes specified in = the foregoing sections of this document. >>>>>> >>>>>> ### RPC work program >>>>>> >>>>>> The RPC follows a work program based on requirements it has gather= ed from a variety of sources, including policies that have been through t= he RSWG/RSAB process, and from direct discussions with the RSEA, stream m= anagers, IETF LLC, authors and other IETF participants. In developing th= is work program, the RPC makes some key decisions which impact the IETF c= ommunity: >>>>>> >>>>>> 1. For each requirement that is gathered, can it be directly inco= rporated into the work program or must it first be subject to community c= onsultation. >>>>>> >>>>>> 2. Setting the relative priorities for the various requirements w= ithin the work program. >>>>>> >>>>>> 3. Determining if all the important requirements have been gather= ed. >>>>>> >>>>>> It is likely that the RPC will require advice during the drafting = of its work program, which it should seek from at least the RSAB and if r= equired, the chairs of the RSWG. >>>>> Why are the chairs or the RSWG mentioned here? I guess the RPC is f= ree to ask anybody for advise they want but the main contact point for me= would be the RSAB (given it includes the stream managers). >>>>> >>>>>> In order to ensure community oversight of the RPC work program: >>>>>> >>>>>> * The RPC must present a draft work program for community feedback= at least annually and then publish a final work program incorporating an= y agreed feedback. >>>>> How and with whom is the feedback agreed? >>>>> >>>>>> * The RPC shall report regularly to the RSAB, RSWG, and broader co= mmunity regarding the contents and progress of its work program and any k= ey risks or issues affecting it. >>>>> How does the RPC report to the broader community. Isn=E2=80=99t it = enough to report to RSWG? >>>>> >>>>>> In the event that the RPC is required to make a decision without c= onsultation that would normally deserve consultation, or makes a decision= against the advice of the RSAB, then it must notify the RSAB. >>>>>> >>>>>> All matters of budget, timetable and impact on its performance tar= gets, are between the RPC and IETF LLC. >>>>>> >>>>>> ### Relationship between the RPC and the IETF LLC >>>>>> >>>>>> This document does not specify the exact relationship between the = IETF >>>> LLC and the RPC function; for example, the RPC function could be pro= vided >>>> by a separate corporate entity under contract to the IETF LLC, it co= uld be performed by employees of the IETF LLC, or the IETF LLC could work= with >>>> independent contractors for some or all aspects of the RPC function.= The exact relationship is a matter for the IETF LLC and the IETF Executi= ve Director to determine. >>>>>> The IETF LLC has authority over negotiating performance targets fo= r the RPC and also has responsibility for ensuring that those targets are= adhered to. The IETF LLC is empowered to appoint a manager or to convene= a committee to complete these activities. >>>>>> >>>>>> Community members who have concerns about the performance of the R= PC can request that the IETF LLC look into the matter. Even if the IETF L= LC opts to delegate this activity, concerns should be raised with the IET= F LLC. The IETF LLC is ultimately responsible to the community via the me= chanisms outlined in its charter. >>>>>> >>>>>> =E2=80=94=E2=80=94 >>>>>> >>>>>> --=20 >>>>>> Jay Daley >>>>>> IETF Executive Director >>>>>> jay@ietf.org >>>>>> >>>>>> --=20 >>>>>> Rfced-future mailing list >>>>>> Rfced-future@iab.org >>>>>> https://www.iab.org/mailman/listinfo/rfced-future >> --=20 >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future > --yJHoFOEmzcplSGve7MT7Dy5nsDhgrCFrf-- --Fq8YFQI4OjlTW2Q6KoOVDe0Ryh47xAVM4 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmEkw2cFAwAAAAAACgkQh7ZrRtnSejMT Xgf+Myv8KlXsvteMW/gLLABVphyI5QRGmLQll4tq2kpKkepi581conqujxWY7R+xYPqj7Ii32OWU Y8nDHIwIxbmowJqCzC6EdQV/ZCx80b+yPwtp/Ck5kd/PIoNip7RZQqSLcYURbZ5qKjRQbFBtz8pV MjHcTlfy45pKtgU6IYZo7FiPw3T2rz/pwDJLSPGnIbIDrpO9OZM4A4fm/qx/Zpf1jHOZXy2z4qPl ygPV7zCzQ7RkUqWoNdDF3B+nYOzsGhK1U+ypekukRi+MN9b8M5Ax2Ai2mClPpqG2rKcJ5s/3Kvsx ET3s81Vpy5oviVqADWg9aA8E0NMUvBmps6iH+N2n9w== =7R+T -----END PGP SIGNATURE----- --Fq8YFQI4OjlTW2Q6KoOVDe0Ryh47xAVM4-- From nobody Tue Aug 24 03:55:01 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 329C73A21D6 for ; Tue, 24 Aug 2021 03:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org 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 NAdYQkDjPsc2 for ; Tue, 24 Aug 2021 03:54:52 -0700 (PDT) Received: from mail.eggert.org (mail.eggert.org [IPv6:2a00:ac00:4000:400:211:32ff:fe22:186f]) (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 4CFCF3A21D7 for ; Tue, 24 Aug 2021 03:54:52 -0700 (PDT) Received: from smtpclient.apple (unknown [IPv6:2a00:ac00:4000:400:1815:5480:b768:b865]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id DCAB9600370; Tue, 24 Aug 2021 13:54:35 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1629802475; bh=51rfHdIj+Moae0J4PVevDkziDwx/E1LB+cvD0roollE=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=bZSjdiZh2P7/8wpKTw4aiNGQsERw1l0pr4vHoSN/WnuGtyccs1ap4y83DaQ49AuBa r6pQcaujC1FMuoS4+tSom3F09w9DaAcK4I11IaB1O67zY33xLSiyVNFVTTY6ybi/rb NYtEBbqWh/MaN/lC9ovp6aFb2/qTWS+xN/a9YASM= From: Lars Eggert Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_0667EC95-466D-4E91-A0C7-9A8B6248A9AE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Tue, 24 Aug 2021 13:54:35 +0300 In-Reply-To: Cc: rfced-future@iab.org, Jay Daley , Eliot Lear To: =?utf-8?Q?Mirja_K=C3=BChlewind?= References: <996b71fc-6ebd-06a1-9a0a-2695a6044381@nthpermutation.com> <4ad09680-b067-4475-9232-e8f69101e7c0@lear.ch> <3295300e-d396-36fc-2137-6452de7f5296@nthpermutation.com> <848d287a-d2e5-7e61-90c4-e3718c010906@gmail.com> <086c5844-ef49-4221-94f2-67408182c6a6@it.aoyama.ac.jp> <3b86de0d-6823-c740-7928-4258a420d990@gmail.com> <173EC03C-E7C8-4965-AABB-49DAF4002F48@ietf.org> <5a47b37b-234e-a0d5-e529-6de68e0177c6@lear.ch> X-MailScanner-ID: DCAB9600370.A46D6 X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2021 10:54:58 -0000 --Apple-Mail=_0667EC95-466D-4E91-A0C7-9A8B6248A9AE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, some initial reactions based on a first read. On 2021-8-24, at 12:20, Mirja Kuehlewind wrote: > # Roles and Processes >=20 > ## RFC Production Center (RPC) >=20 > Publication of RFCs shall continue to be handled by the RFC Production = Center (RPC) function in accordance with high-level policies that have = been > specified through the RSWG/RSAB process as well as based on advice = from direct discussions with the RSEA, stream managers, IETF LLC, = authors and other community memberss in cases where the implementation = of a policy is not clear or not sufficient. Why include "authors and other community members" here? I can understand = why the RPC would consult with the other bodies/roles listed, since they = have defined roles in terms of setting policy and may hence be able to = offer additional guidance. But acting based on advice from authors = and/or otherwise unidentified community members seems unmotivated? > The RPC shall proactively implement the policies specified by the = RSWG/RSAB process reflecting the priorities of the community. Is "proactively" a no-op filler word, in which case it could just be = removed, or is it supposed to convey some meaning, e.g., that the RPC = shall implement policies while they are still in the process of being = defined (or some other meaning)? > The RPC shall report regularly to the RSAB, RSWG, and broader = community regarding their plan and time line for implementation as well = as any key risks or issues affecting it. No issues with a report to the community, obviously. > The RPC is expected to revise their plan based on community input if = concern regarding the implementation plan or priorities of work are = raised. In case of conflicting requirements from the community, the RPC = shall consult with the RSAB. But this sentence turns the reporting into a discussion, and the RPC is = asked to somehow judge community consensus on its operation, and then = act on that. Part of the problem here is that "the community" is pretty = undefined. I could maybe see this working if the RPC was asked to take = input from the RSWG that the chairs have declared consensus on into = account. That would also allow for managing input that overlaps with = areas the LLC is responsible for. I find the open model defined above = too unclear. > This document does not constrain how the RPC and the community = communicate with each other. In the event that the RPC is required to = make a decision without consultation that would normally deserve = consultation, or makes a decision against the advice of the RSAB, then = it must notify the RSAB. >=20 > All matters of budget, timetable and impact on its performance = targets, are between the RPC and IETF LLC. >=20 > ### Relationship between the RPC and the IETF LLC >=20 > This document does not specify the exact relationship between the IETF = LLC and the RPC function; for example, the RPC function could be = provided by a separate corporate entity under contract to the IETF LLC, = it could be > performed by employees of the IETF LLC, or the IETF LLC could work = with independent contractors for some or all aspects of the RPC = function. The exact relationship is a matter for the IETF LLC and the = IETF Executive Director to determine. >=20 > The IETF LLC has authority over negotiating performance targets for = the RPC and also has responsibility for ensuring that those targets are = adhered to. >=20 > If individuals or groups within the community have concerns about the = performance of the RPC, they can request that the IETF LLC look into the = matter. Even if the IETF LLC opts to delegate this activity, concerns = should > be raised with the IETF LLC. The IETF LLC is ultimately responsible to = the community via the mechanisms outlined in its charter. Thanks, Lars --Apple-Mail=_0667EC95-466D-4E91-A0C7-9A8B6248A9AE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmEkz+sACgkQVLXDCb9w wVclrhAAts7TgIJgnwRrWBGMoGoSn/L0V3gF4fdxtd6nWAf95HIUCAJG06V6bdkK e6Ns6LEh4L4cUKij/X5biAs1IhPAbQASUfYy6stddXjIzuXxkC7PUOF6i0xV66ig HIgyhGevRQS5RMXxH5eOjhXw9snTALMDrCAvYJYHBZowOHgJVeQC264ihZCISR8c DiIPWFgIeXvWibwOViKggtvwsxJtd7LPiFDUoKzzgBOUiKspHmaokaSTO/u1DX+S kF/1cTdIEgAdQrutLul+5PzKYmsN2r6yG7ZKsQ00nBqgwLCemi1PIRQPudVC9/aA CYm8d06apON6+SXhGPov/GdK3IovlE1e2vT1St309wfF3gYxlmgjFxdc/mE2LJI+ o2hl6hc8rybFOwdMGoM9YvJ8n/OC75VwAiyyZzKplxGEg81eXNMmElukqiOOPsWq U5elcOJJFIuocfyuUOGhnuNa7z954YKHm2qaIV7J+bwbHGpoPi5E5DI1B68xgNL1 SnxEKQhjnuque8QLItgFy+HyRuZz1Ry6djYyA5c+f96DXbwL39Jagh5r+bRL0v07 QaImt2QVYIXav03uCnCJs2hwE3zvFRYycZN0oH+LSSWTWxJ5QeuDU/UtsJDu3KL9 BBHvIQ5eUmEFpKQJlIha20wICgCLjryMhbSYSyGLmtWSgoHhgxk= =mEKw -----END PGP SIGNATURE----- --Apple-Mail=_0667EC95-466D-4E91-A0C7-9A8B6248A9AE-- From nobody Tue Aug 24 04:09:09 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA6413A0DB0; Tue, 24 Aug 2021 04:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 01aQXAuPX2Bh; Tue, 24 Aug 2021 04:09:01 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 669303A22E0; Tue, 24 Aug 2021 04:09:01 -0700 (PDT) Received: from p200300dee734c300f877e77634d82596.dip0.t-ipconnect.de ([2003:de:e734:c300:f877:e776:34d8:2596]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1mIUIX-0001xX-9v; Tue, 24 Aug 2021 13:08:53 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Mirja Kuehlewind In-Reply-To: Date: Tue, 24 Aug 2021 13:08:51 +0200 Cc: rfced-future@iab.org, Jay Daley , Eliot Lear Content-Transfer-Encoding: quoted-printable Message-Id: References: <996b71fc-6ebd-06a1-9a0a-2695a6044381@nthpermutation.com> <4ad09680-b067-4475-9232-e8f69101e7c0@lear.ch> <3295300e-d396-36fc-2137-6452de7f5296@nthpermutation.com> <848d287a-d2e5-7e61-90c4-e3718c010906@gmail.com> <086c5844-ef49-4221-94f2-67408182c6a6@it.aoyama.ac.jp> <3b86de0d-6823-c740-7928-4258a420d990@gmail.com> <173EC03C-E7C8-4965-AABB-49DAF4002F48@ietf.org> <5a47b37b-234e-a0d5-e529-6de68e0177c6@lear.ch> To: Lars Eggert X-Mailer: Apple Mail (2.3608.120.23.2.4) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1629803341;31703561; X-HE-SMSGID: 1mIUIX-0001xX-9v Archived-At: Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2021 11:09:08 -0000 Some quick comments below. > On 24. Aug 2021, at 12:54, Lars Eggert wrote: >=20 > Hi, >=20 > some initial reactions based on a first read. >=20 > On 2021-8-24, at 12:20, Mirja Kuehlewind wrote: >> # Roles and Processes >>=20 >> ## RFC Production Center (RPC) >>=20 >> Publication of RFCs shall continue to be handled by the RFC = Production Center (RPC) function in accordance with high-level policies = that have been >> specified through the RSWG/RSAB process as well as based on advice = from direct discussions with the RSEA, stream managers, IETF LLC, = authors and other community memberss in cases where the implementation = of a policy is not clear or not sufficient. >=20 > Why include "authors and other community members" here? I can = understand why the RPC would consult with the other bodies/roles listed, = since they have defined roles in terms of setting policy and may hence = be able to offer additional guidance. But acting based on advice from = authors and/or otherwise unidentified community members seems = unmotivated? I took this from the original proposed text from Jay. I agree that = listing "RSEA, stream managers, IETF LLC=E2=80=9D here should be = sufficient. However, I let Jay reply if he had more specific cases in = mind. >=20 >> The RPC shall proactively implement the policies specified by the = RSWG/RSAB process reflecting the priorities of the community. >=20 > Is "proactively" a no-op filler word, in which case it could just be = removed, or is it supposed to convey some meaning, e.g., that the RPC = shall implement policies while they are still in the process of being = defined (or some other meaning)? Maybe. The intention was to make it clear that this sentence does say = something else/more than the previous sentence, in that the RPC in that = the RPC should not only follow set policy but also actively plan for = implementation of procedural changed based on new policies. I guess = =E2=80=9Cproactively=E2=80=9D is not really the right word. Maybe just = =E2=80=9Cactively=E2=80=9D or =E2=80=9Cplan to implement=E2=80=9D? >=20 >> The RPC shall report regularly to the RSAB, RSWG, and broader = community regarding their plan and time line for implementation as well = as any key risks or issues affecting it. >=20 > No issues with a report to the community, obviously. >=20 >> The RPC is expected to revise their plan based on community input if = concern regarding the implementation plan or priorities of work are = raised. In case of conflicting requirements from the community, the RPC = shall consult with the RSAB. >=20 > But this sentence turns the reporting into a discussion, and the RPC = is asked to somehow judge community consensus on its operation, and then = act on that. Part of the problem here is that "the community" is pretty = undefined. I could maybe see this working if the RPC was asked to take = input from the RSWG that the chairs have declared consensus on into = account. That would also allow for managing input that overlaps with = areas the LLC is responsible for. I find the open model defined above = too unclear. I don=E2=80=99t think that what this text says. My understanding of the = desired process is that the RPC should provide a plan, ask for feedback, = and then might provide a revised plan. So the RPC keeps the authority = about the plan and it=E2=80=99s probably more the LLC that will finally = accept the plan or not. So if at all it=E2=80=99s the LLC board that has = to consider consensus. This text on purpose only describes expectations and not requirements = because it=E2=80=99s on the LLC how to handle it in details. However, my = impression of the feedback from the group was that people find it = important to note that there is an expectation that the community is = consulted. Is there anything we can or should say to clarify this text? >=20 >> This document does not constrain how the RPC and the community = communicate with each other. In the event that the RPC is required to = make a decision without consultation that would normally deserve = consultation, or makes a decision against the advice of the RSAB, then = it must notify the RSAB. >>=20 >> All matters of budget, timetable and impact on its performance = targets, are between the RPC and IETF LLC. >>=20 >> ### Relationship between the RPC and the IETF LLC >>=20 >> This document does not specify the exact relationship between the = IETF LLC and the RPC function; for example, the RPC function could be = provided by a separate corporate entity under contract to the IETF LLC, = it could be >> performed by employees of the IETF LLC, or the IETF LLC could work = with independent contractors for some or all aspects of the RPC = function. The exact relationship is a matter for the IETF LLC and the = IETF Executive Director to determine. >>=20 >> The IETF LLC has authority over negotiating performance targets for = the RPC and also has responsibility for ensuring that those targets are = adhered to. >>=20 >> If individuals or groups within the community have concerns about the = performance of the RPC, they can request that the IETF LLC look into the = matter. Even if the IETF LLC opts to delegate this activity, concerns = should >> be raised with the IETF LLC. The IETF LLC is ultimately responsible = to the community via the mechanisms outlined in its charter. >=20 > Thanks, > Lars >=20 >=20 >=20 >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future From nobody Tue Aug 24 04:12:01 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 657C33A230A; Tue, 24 Aug 2021 04:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no 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 5WUTngHQrtKN; Tue, 24 Aug 2021 04:11:56 -0700 (PDT) Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D7BA3A2308; Tue, 24 Aug 2021 04:11:55 -0700 (PDT) Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta5.iomartmail.com (8.14.4/8.14.4) with ESMTP id 17OBBn11005172; Tue, 24 Aug 2021 12:11:49 +0100 Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 31AA346050; Tue, 24 Aug 2021 12:11:49 +0100 (BST) Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 21C264604F; Tue, 24 Aug 2021 12:11:49 +0100 (BST) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs3.iomartmail.com (Postfix) with ESMTPS; Tue, 24 Aug 2021 12:11:49 +0100 (BST) Received: from LAPTOPK7AS653V ([195.166.134.103]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id 17OBBlOe004645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 24 Aug 2021 12:11:48 +0100 Reply-To: From: "Adrian Farrel" To: "'Lars Eggert'" , "=?iso-8859-1?Q?'Mirja_K=FChlewind'?=" Cc: , "'Jay Daley'" , "'Eliot Lear'" References: <996b71fc-6ebd-06a1-9a0a-2695a6044381@nthpermutation.com> <4ad09680-b067-4475-9232-e8f69101e7c0@lear.ch> <3295300e-d396-36fc-2137-6452de7f5296@nthpermutation.com> <848d287a-d2e5-7e61-90c4-e3718c010906@gmail.com> <086c5844-ef49-4221-94f2-67408182c6a6@it.aoyama.ac.jp> <3b86de0d-6823-c740-7928-4258a420d990@gmail.com> <173EC03C-E7C8-4965-AABB-49DAF4002F48@ietf.org> <5a47b37b-2! 34e-a0d5-e529-6de68e017 7c6@lear.ch> In-Reply-To: Date: Tue, 24 Aug 2021 12:11:44 +0100 Organization: Old Dog Consulting Message-ID: <027801d798d8$d4e31a10$7ea94e30$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJwJyO/s82oIoKUMQfOOhTzO749mAKjDre8Ah9M32wB6+d7pgGnFhSTAtsMptMCCs6WygJywZm9AtRB+C4BqNB3cwFh2dO5AWGmpZABdoeq6AH0wtPPAYO0qhsDS9f6twJrAf15Ai48M90C4w/1cgJ2DfXzAmAjiuQBWb84qqjqtI8w Content-Language: en-gb X-Originating-IP: 195.166.134.103 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.1.0.2034-8.6.0.1018-26364.007 X-TM-AS-Result: No--0.666-10.0-31-10 X-imss-scan-details: No--0.666-10.0-31-10 X-TMASE-Version: IMSVA-9.1.0.2034-8.6.1018-26364.007 X-TMASE-Result: 10--0.666400-10.000000 X-TMASE-MatchedRID: y/2oPz6gbvjxIbpQ8BhdbPHkpkyUphL9yptxwteXfPu2zFWqrVN4BVJ1 y2ijxk6+JJ2h2GTS7J9ey2BxkkqaAmysaVYsUnJrutvHF25zoU8yyi+n+H050Zc8uqoSQW2WB+E vqmMuRzmX5BxTRNgxFwt+7cHI5ZhBb581EchakiP0hv/rD7WVZPfjx7YIT/BiteXjSBMYnmlEdO S93F1NzoPkY+UN7onQsuEAWoIuI0ZAeNM98bIejDOmaQkQOI7Zs+A++/BnIBFfqFieeMpX7Nj+R gXaVonz8DRYXhYkzdmXLQarBvbWDFEAzLC+cfSyngIgpj8eDcAWi1nwOKnDgYtkBWmEtb9tKrau Xd3MZDUosTpwYfBvilEJWsBguoZKdWfLogWfLkjBODaIvXG3Uw7ef06U1+J0AR3/nuOSux9PLJZ estkrMEiybJiVV0GE+QRpEs2UR2fAppDA86U3VqfItuohgjfnw/3NmPJsa4pNWfnUnboMLyBJEZ lhLWrQQwymtxuJ6y0= X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2021 11:12:01 -0000 >> ## RFC Production Center (RPC) >> >> Publication of RFCs shall continue to be handled by the RFC Production >> Center (RPC) function in accordance with high-level policies that have been >> specified through the RSWG/RSAB process as well as based on advice from >> direct discussions with the RSEA, stream managers, IETF LLC, authors and >> other community memberss in cases where the implementation of a policy >> is not clear or not sufficient. > > Why include "authors and other community members" here? I can understand > why the RPC would consult with the other bodies/roles listed, since they have > defined roles in terms of setting policy and may hence be able to offer additional > guidance. But acting based on advice from authors and/or otherwise unidentified > community members seems unmotivated? Yeah, heaven forfend we should involve the community in any discussions :-Z Example 1: What is the correct expansion of an abbreviation? Surely the authors or experts in the community are best placed to give advice to the RPC. Example 2: What did you intend this paragraph to say? Surely the authors would answer this. Note: The text does not say that policies will be set by the authors and community, but that, "Publication of RFCs shall continue [...] based on advice from direct discussions with the [...] authors and other community members..." I agree that the punctuation of the sentence could give rise to ambiguity. Cheers, Adrian From nobody Tue Aug 24 04:52:24 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2003E3A0A88 for ; Tue, 24 Aug 2021 04:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 JjDrnYxALOFg; Tue, 24 Aug 2021 04:52:16 -0700 (PDT) Received: from smtpclient.apple (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id 608613A0A73; Tue, 24 Aug 2021 04:52:16 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-661AB0C0-E2FD-4F6E-83C7-52181C6A339B Content-Transfer-Encoding: 7bit From: Jay Daley Mime-Version: 1.0 (1.0) Date: Tue, 24 Aug 2021 23:52:12 +1200 Message-Id: <2B46402F-5268-46B7-890F-7C5CA159EF13@ietf.org> References: Cc: Lars Eggert , rfced-future@iab.org, Eliot Lear In-Reply-To: To: Mirja Kuehlewind X-Mailer: iPad Mail (18G82) Archived-At: Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2021 11:52:23 -0000 --Apple-Mail-661AB0C0-E2FD-4F6E-83C7-52181C6A339B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable (Resending from the correct address) > On 24/08/2021, at 11:09 PM, Mirja Kuehlewind wrote: >=20 > =EF=BB=BFSome quick comments below. >=20 >> On 24. Aug 2021, at 12:54, Lars Eggert wrote: >>=20 >> Hi, >>=20 >> some initial reactions based on a first read. >>=20 >>> On 2021-8-24, at 12:20, Mirja Kuehlewind wrote: >>> # Roles and Processes >>>=20 >>> ## RFC Production Center (RPC) >>>=20 >>> Publication of RFCs shall continue to be handled by the RFC Production C= enter (RPC) function in accordance with high-level policies that have been >>> specified through the RSWG/RSAB process as well as based on advice from d= irect discussions with the RSEA, stream managers, IETF LLC, authors and othe= r community memberss in cases where the implementation of a policy is not cl= ear or not sufficient. >>=20 >> Why include "authors and other community members" here? I can understand w= hy the RPC would consult with the other bodies/roles listed, since they have= defined roles in terms of setting policy and may hence be able to offer add= itional guidance. But acting based on advice from authors and/or otherwise u= nidentified community members seems unmotivated? >=20 > I took this from the original proposed text from Jay. I agree that listing= "RSEA, stream managers, IETF LLC=E2=80=9D here should be sufficient. Howeve= r, I let Jay reply if he had more specific cases in mind. This text has merged text I didn=E2=80=99t write with text I did write and n= ow has quite a different meaning from what I intended.=20 My text mentioned =E2=80=9C direct discussions with the RSEA, stream manager= s, IETF LLC, authors and other community members=E2=80=9D in the context of t= he requirements for the work program not the policies. In other words - the= RPC should be open to saying =E2=80=9Cwe had this great suggestion from X t= o improve Y that we plan to implement=E2=80=9D.=20 The phrase =E2=80=9Chigh level policies=E2=80=9D originally appeared in a di= fferent context: > Publication of RFCs shall be continue to be handled by the RFC Production C= enter (RPC) function in accordance with high-level policies currently in for= ce or yet to be defined following the processes specified in the foregoing s= ections of this document. This was followed by my text below, which I think is still the best way to e= xplain this, it=E2=80=99s the detail following that needs changing not this t= ext.=20 > The RPC follows a work program based on requirements it has gathered from a= variety of sources, including policies that have been through the RSWG/RSAB= process, and from direct discussions with the RSEA, stream managers, IETF L= LC, authors and other IETF participants. Jay --=20 Jay Daley IETF Executive Director >=20 >>=20 >>> The RPC shall proactively implement the policies specified by the RSWG/R= SAB process reflecting the priorities of the community. >>=20 >> Is "proactively" a no-op filler word, in which case it could just be remo= ved, or is it supposed to convey some meaning, e.g., that the RPC shall impl= ement policies while they are still in the process of being defined (or some= other meaning)? >=20 > Maybe. The intention was to make it clear that this sentence does say some= thing else/more than the previous sentence, in that the RPC in that the RPC s= hould not only follow set policy but also actively plan for implementation o= f procedural changed based on new policies. I guess =E2=80=9Cproactively=E2=80= =9D is not really the right word. Maybe just =E2=80=9Cactively=E2=80=9D or =E2= =80=9Cplan to implement=E2=80=9D? >=20 >>=20 >>> The RPC shall report regularly to the RSAB, RSWG, and broader community r= egarding their plan and time line for implementation as well as any key risk= s or issues affecting it. >>=20 >> No issues with a report to the community, obviously. >>=20 >>> The RPC is expected to revise their plan based on community input if con= cern regarding the implementation plan or priorities of work are raised. In= case of conflicting requirements from the community, the RPC shall consult w= ith the RSAB. >>=20 >> But this sentence turns the reporting into a discussion, and the RPC is a= sked to somehow judge community consensus on its operation, and then act on t= hat. Part of the problem here is that "the community" is pretty undefined. I= could maybe see this working if the RPC was asked to take input from the RS= WG that the chairs have declared consensus on into account. That would also a= llow for managing input that overlaps with areas the LLC is responsible for.= I find the open model defined above too unclear. >=20 > I don=E2=80=99t think that what this text says. My understanding of the de= sired process is that the RPC should provide a plan, ask for feedback, and t= hen might provide a revised plan. So the RPC keeps the authority about the p= lan and it=E2=80=99s probably more the LLC that will finally accept the plan= or not. So if at all it=E2=80=99s the LLC board that has to consider consen= sus. >=20 > This text on purpose only describes expectations and not requirements beca= use it=E2=80=99s on the LLC how to handle it in details. However, my impress= ion of the feedback from the group was that people find it important to note= that there is an expectation that the community is consulted. >=20 > Is there anything we can or should say to clarify this text? >=20 >=20 >>=20 >>> This document does not constrain how the RPC and the community communica= te with each other. In the event that the RPC is required to make a decision= without consultation that would normally deserve consultation, or makes a d= ecision against the advice of the RSAB, then it must notify the RSAB. >>>=20 >>> All matters of budget, timetable and impact on its performance targets, a= re between the RPC and IETF LLC. >>>=20 >>> ### Relationship between the RPC and the IETF LLC >>>=20 >>> This document does not specify the exact relationship between the IETF L= LC and the RPC function; for example, the RPC function could be provided by a= separate corporate entity under contract to the IETF LLC, it could be >>> performed by employees of the IETF LLC, or the IETF LLC could work with i= ndependent contractors for some or all aspects of the RPC function. The exac= t relationship is a matter for the IETF LLC and the IETF Executive Director t= o determine. >>>=20 >>> The IETF LLC has authority over negotiating performance targets for the R= PC and also has responsibility for ensuring that those targets are adhered t= o. >>>=20 >>> If individuals or groups within the community have concerns about the pe= rformance of the RPC, they can request that the IETF LLC look into the matte= r. Even if the IETF LLC opts to delegate this activity, concerns should >>> be raised with the IETF LLC. The IETF LLC is ultimately responsible to t= he community via the mechanisms outlined in its charter. >>=20 >> Thanks, >> Lars >>=20 >>=20 >>=20 >>=20 >> --=20 >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future --Apple-Mail-661AB0C0-E2FD-4F6E-83C7-52181C6A339B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable (Resending from the correct address)

On 24/08/2021, at 11:09 PM, Mirja Kuehlewind <ietf@kuehlewind.net> wrote:

=EF=BB=BFSome quick comments below.

On 24. Aug 2021, at 12:54, Lars Eggert <lars@eggert.org> wrote:

Hi,

some initial re= actions based on a first read.
On 2021-8-24, at 12:20, Mirja Kuehlewind <ietf@kuehlewind.net> wrote:
# Roles and Processes

## RFC Production Center (RPC)

=
Publication of RFCs shal= l continue to be handled by the RFC Production Center (RPC) function in acco= rdance with high-level policies that have been
=
specified through the RS= WG/RSAB process as well as based on advice from direct discussions with the R= SEA, stream managers, IETF LLC, authors and other community memberss in case= s where the implementation of a policy is not clear or not sufficient.

Why include "authors and other community members" here? I c= an understand why the RPC would consult with the other bodies/roles listed, s= ince they have defined roles in terms of setting policy and may hence be abl= e to offer additional guidance. But acting based on advice from authors and/= or otherwise unidentified community members seems unmotivated?

I took this from the original proposed text from Jay. I agree that li= sting "RSEA, stream managers, IETF LLC=E2=80=9D here should be sufficient. H= owever, I let Jay reply if he had more specific cases in mind.

This text has merged text I didn=E2=80=99= t write with text I did write and now has quite a different meaning from wha= t I intended. 

=
My text mentioned =E2=80= =9C direct discussions with the RSEA, stream managers, IETF LLC, authors and= other community members=E2=80=9D in the context of the requirements for the= work program not the  policies. In other words - the RPC should be ope= n to saying =E2=80=9Cwe had this great suggestion from X to improve Y that w= e plan to implement=E2=80=9D. 

The phr= ase =E2=80=9Chigh level policies=E2=80=9D originally appeared in a different= context:

Publication of RFCs shall be c= ontinue to be handled by the RFC Production Center (RPC) function in accorda= nce with high-level policies currently in force or yet to be defined fo= llowing the processes specified in the foregoing sections of this document.<= /span>

=
This was followed by my= text below, which I think is still the best way to explain this, it=E2=80=99= s the detail following that needs changing not this text. 

The RPC follows a wor= k program based on requirements it has gathered from a variety of sources, i= ncluding policies that have been through the RSWG/RSAB process, and from dir= ect discussions with the RSEA, stream managers, IETF LLC, authors and o= ther IETF participants.

Jay
-- Jay Daley
IETF Executive Director

<= br>

The RPC shall proactively implement the policies speci= fied by the RSWG/RSAB process reflecting the priorities of the community.

Is "proactively" a no-op filler word, in which case it c= ould just be removed, or is it supposed to convey some meaning, e.g., that t= he RPC shall implement policies while they are still in the process of being= defined (or some other meaning)?

Maybe. The intention w= as to make it clear that this sentence does say something else/more than the= previous sentence, in that the RPC in that the RPC should not only follow s= et policy but also actively plan for implementation of procedural changed ba= sed on new policies. I guess =E2=80=9Cproactively=E2=80=9D is not really the= right word. Maybe just =E2=80=9Cactively=E2=80=9D or =E2=80=9Cplan to imple= ment=E2=80=9D?


The RPC shall report regularly to t= he RSAB, RSWG, and broader community regarding their plan and time line for i= mplementation as well as any key risks or issues affecting it.

No issues with a report to the community, obviously.
=

The RPC is expected to revise their plan based on communi= ty input if concern regarding the  implementation plan or priorities of= work are raised. In case of conflicting requirements from the community, th= e RPC shall consult with the RSAB.

But this sentence tu= rns the reporting into a discussion, and the RPC is asked to somehow judge c= ommunity consensus on its operation, and then act on that. Part of the probl= em here is that "the community" is pretty undefined. I could maybe see this w= orking if the RPC was asked to take input from the RSWG that the chairs have= declared consensus on into account. That would also allow for managing inpu= t that overlaps with areas the LLC is responsible for. I find the open model= defined above too unclear.

I don=E2=80=99t think that w= hat this text says. My understanding of the desired process is that the RPC s= hould provide a plan, ask for feedback, and then might provide a revised pla= n. So the RPC keeps the authority about the plan and it=E2=80=99s probably m= ore the LLC that will finally accept the plan or not. So if at all it=E2=80=99= s the LLC board that has to consider consensus.

This text on purpose o= nly describes expectations and not requirements because it=E2=80=99s on the L= LC how to handle it in details. However, my impression of the feedback from t= he group was that people find it important to note that there is an expectat= ion that the community is consulted.

Is there anything we can or shou= ld say to clarify this text?



This document doe= s not constrain how the RPC and the community communicate with each other. I= n the event that the RPC is required to make a decision without consultation= that would normally deserve consultation, or makes a decision against the a= dvice of the RSAB, then it must notify the RSAB.

All matters of b= udget, timetable and impact on its performance targets, are between the RPC a= nd IETF LLC.

### Relationship between the RPC and the IETF LLC

This document does not specify the exact relationship between the IET= F LLC and the RPC function; for example, the RPC function could be provided b= y a separate corporate entity under contract to the IETF LLC, it could be
performed by employees of the IETF LLC, or the IETF LLC could work with i= ndependent contractors for some or all aspects of the RPC function. The exac= t relationship is a matter for the IETF LLC and the IETF Executive Director t= o determine.

The IETF LLC has authority over negotiating performa= nce targets for the RPC and also has responsibility for ensuring that those t= argets are adhered to.

If individuals or groups within the communi= ty have concerns about the performance of the RPC, they can request that the= IETF LLC look into the matter. Even if the IETF LLC opts to delegate this a= ctivity, concerns should
be raised with the IETF LLC. The IETF LLC is u= ltimately responsible to the community via the mechanisms outlined in its ch= arter.

Thanks,
Lars




--&nbs= p;
Rfced-future mailing list
Rfced-future@iab.org<= /span>
https://w= ww.iab.org/mailman/listinfo/rfced-future

= --Apple-Mail-661AB0C0-E2FD-4F6E-83C7-52181C6A339B-- From nobody Tue Aug 24 05:04:07 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E928E3A0ABB; Tue, 24 Aug 2021 05:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 bPQtyq4hgYhG; Tue, 24 Aug 2021 05:03:58 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B3123A0BCD; Tue, 24 Aug 2021 05:03:58 -0700 (PDT) Received: from p200300dee734c300f877e77634d82596.dip0.t-ipconnect.de ([2003:de:e734:c300:f877:e776:34d8:2596]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1mIV9i-0008GA-9k; Tue, 24 Aug 2021 14:03:50 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Mirja Kuehlewind In-Reply-To: <2B46402F-5268-46B7-890F-7C5CA159EF13@ietf.org> Date: Tue, 24 Aug 2021 14:03:49 +0200 Cc: Lars Eggert , rfced-future@iab.org, Eliot Lear Content-Transfer-Encoding: quoted-printable Message-Id: <25FCCF71-ED00-48CA-8A15-4BB63B632F73@kuehlewind.net> References: <2B46402F-5268-46B7-890F-7C5CA159EF13@ietf.org> To: Jay Daley X-Mailer: Apple Mail (2.3608.120.23.2.4) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1629806638;6d63f762; X-HE-SMSGID: 1mIV9i-0008GA-9k Archived-At: Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2021 12:04:05 -0000 See inline. > On 24. Aug 2021, at 13:52, Jay Daley wrote: >=20 > (Resending from the correct address) >=20 >> On 24/08/2021, at 11:09 PM, Mirja Kuehlewind = wrote: >>=20 >> =EF=BB=BFSome quick comments below. >>=20 >>> On 24. Aug 2021, at 12:54, Lars Eggert wrote: >>>=20 >>> Hi, >>>=20 >>> some initial reactions based on a first read. >>>=20 >>>> On 2021-8-24, at 12:20, Mirja Kuehlewind = wrote: >>>> # Roles and Processes >>>>=20 >>>> ## RFC Production Center (RPC) >>>>=20 >>>> Publication of RFCs shall continue to be handled by the RFC = Production Center (RPC) function in accordance with high-level policies = that have been >>>> specified through the RSWG/RSAB process as well as based on advice = from direct discussions with the RSEA, stream managers, IETF LLC, = authors and other community memberss in cases where the implementation = of a policy is not clear or not sufficient. >>>=20 >>> Why include "authors and other community members" here? I can = understand why the RPC would consult with the other bodies/roles listed, = since they have defined roles in terms of setting policy and may hence = be able to offer additional guidance. But acting based on advice from = authors and/or otherwise unidentified community members seems = unmotivated? >>=20 >> I took this from the original proposed text from Jay. I agree that = listing "RSEA, stream managers, IETF LLC=E2=80=9D here should be = sufficient. However, I let Jay reply if he had more specific cases in = mind. >=20 > This text has merged text I didn=E2=80=99t write with text I did write = and now has quite a different meaning from what I intended.=20 Yes, you are right. I combined these sentences and this got scrambled. >=20 > My text mentioned =E2=80=9C direct discussions with the RSEA, stream = managers, IETF LLC, authors and other community members=E2=80=9D in the = context of the requirements for the work program not the policies. In = other words - the RPC should be open to saying =E2=80=9Cwe had this = great suggestion from X to improve Y that we plan to implement=E2=80=9D.=20= I wouldn=E2=80=99t call this a requirement though. As long as this idea = doesn=E2=80=99t violate any policy or would require a new policy, I = don=E2=80=99t see a reason why the RPC cannot just improve their = processes (independent of the fact where the idea came from). Not sure = we need to say anything about that in this document though. >=20 > The phrase =E2=80=9Chigh level policies=E2=80=9D originally appeared = in a different context: >=20 >> Publication of RFCs shall be continue to be handled by the RFC = Production Center (RPC) function in accordance with high-level policies = currently in force or yet to be defined following the processes = specified in the foregoing sections of this document. >=20 > This was followed by my text below, which I think is still the best = way to explain this, it=E2=80=99s the detail following that needs = changing not this text.=20 >=20 >> The RPC follows a work program based on requirements it has gathered = from a variety of sources, including policies that have been through the = RSWG/RSAB process, and from direct discussions with the RSEA, stream = managers, IETF LLC, authors and other IETF participants. This is the part that I tried to remove because it talks about a =E2=80=9C= work program=E2=80=9D without defining what that is intended to imply.=20= Mirja =20 >=20 > Jay > --=20 > Jay Daley > IETF Executive Director >=20 >>=20 >>>=20 >>>> The RPC shall proactively implement the policies specified by the = RSWG/RSAB process reflecting the priorities of the community. >>>=20 >>> Is "proactively" a no-op filler word, in which case it could just be = removed, or is it supposed to convey some meaning, e.g., that the RPC = shall implement policies while they are still in the process of being = defined (or some other meaning)? >>=20 >> Maybe. The intention was to make it clear that this sentence does say = something else/more than the previous sentence, in that the RPC in that = the RPC should not only follow set policy but also actively plan for = implementation of procedural changed based on new policies. I guess = =E2=80=9Cproactively=E2=80=9D is not really the right word. Maybe just = =E2=80=9Cactively=E2=80=9D or =E2=80=9Cplan to implement=E2=80=9D? >>=20 >>>=20 >>>> The RPC shall report regularly to the RSAB, RSWG, and broader = community regarding their plan and time line for implementation as well = as any key risks or issues affecting it. >>>=20 >>> No issues with a report to the community, obviously. >>>=20 >>>> The RPC is expected to revise their plan based on community input = if concern regarding the implementation plan or priorities of work are = raised. In case of conflicting requirements from the community, the RPC = shall consult with the RSAB. >>>=20 >>> But this sentence turns the reporting into a discussion, and the RPC = is asked to somehow judge community consensus on its operation, and then = act on that. Part of the problem here is that "the community" is pretty = undefined. I could maybe see this working if the RPC was asked to take = input from the RSWG that the chairs have declared consensus on into = account. That would also allow for managing input that overlaps with = areas the LLC is responsible for. I find the open model defined above = too unclear. >>=20 >> I don=E2=80=99t think that what this text says. My understanding of = the desired process is that the RPC should provide a plan, ask for = feedback, and then might provide a revised plan. So the RPC keeps the = authority about the plan and it=E2=80=99s probably more the LLC that = will finally accept the plan or not. So if at all it=E2=80=99s the LLC = board that has to consider consensus. >>=20 >> This text on purpose only describes expectations and not requirements = because it=E2=80=99s on the LLC how to handle it in details. However, my = impression of the feedback from the group was that people find it = important to note that there is an expectation that the community is = consulted. >>=20 >> Is there anything we can or should say to clarify this text? >>=20 >>=20 >>>=20 >>>> This document does not constrain how the RPC and the community = communicate with each other. In the event that the RPC is required to = make a decision without consultation that would normally deserve = consultation, or makes a decision against the advice of the RSAB, then = it must notify the RSAB. >>>>=20 >>>> All matters of budget, timetable and impact on its performance = targets, are between the RPC and IETF LLC. >>>>=20 >>>> ### Relationship between the RPC and the IETF LLC >>>>=20 >>>> This document does not specify the exact relationship between the = IETF LLC and the RPC function; for example, the RPC function could be = provided by a separate corporate entity under contract to the IETF LLC, = it could be >>>> performed by employees of the IETF LLC, or the IETF LLC could work = with independent contractors for some or all aspects of the RPC = function. The exact relationship is a matter for the IETF LLC and the = IETF Executive Director to determine. >>>>=20 >>>> The IETF LLC has authority over negotiating performance targets for = the RPC and also has responsibility for ensuring that those targets are = adhered to. >>>>=20 >>>> If individuals or groups within the community have concerns about = the performance of the RPC, they can request that the IETF LLC look into = the matter. Even if the IETF LLC opts to delegate this activity, = concerns should >>>> be raised with the IETF LLC. The IETF LLC is ultimately responsible = to the community via the mechanisms outlined in its charter. >>>=20 >>> Thanks, >>> Lars >>>=20 >>>=20 >>>=20 >>>=20 >>> --=20 >>> Rfced-future mailing list >>> Rfced-future@iab.org >>> https://www.iab.org/mailman/listinfo/rfced-future >=20 From nobody Tue Aug 24 05:29:41 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 391AE3A0ECC for ; Tue, 24 Aug 2021 05:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.08 X-Spam-Level: X-Spam-Status: No, score=-2.08 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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch 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 NjvNtFA_Fmfa for ; Tue, 24 Aug 2021 05:29:33 -0700 (PDT) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA18D3A0E2F for ; Tue, 24 Aug 2021 05:29:32 -0700 (PDT) Received: from [IPv6:2001:420:c0c0:1011::3] ([IPv6:2001:420:c0c0:1011:0:0:0:3]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 17OCTRHO202041 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Tue, 24 Aug 2021 14:29:28 +0200 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1629808168; bh=qmqAJsG7/L8dYj3pfqBBxLCRPWXuQaowHBYYtsLsCxY=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=AVUJtIyA2iU6IgJ2g3GbG5ozzmI+75kdgY2bBe/F8Ra0FIC7g5XmhBZ+oGgVK27DW nm59i5d2EdMYqt4mGOmdSYHfrWcnUlTMN5yKhZF1/oBpYuEwh1EhGP4/mahvNmZyBJ lXv0Yp4Lcl3obu6B1/iQHQhuDIU2c0GQH4LVeBp0= To: Mirja Kuehlewind References: <2B46402F-5268-46B7-890F-7C5CA159EF13@ietf.org> <25FCCF71-ED00-48CA-8A15-4BB63B632F73@kuehlewind.net> Cc: "rfced-future@iab.org" From: Eliot Lear Message-ID: Date: Tue, 24 Aug 2021 14:29:26 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <25FCCF71-ED00-48CA-8A15-4BB63B632F73@kuehlewind.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="F3bvUqw77XI9fXIO6a7PD790IgU1sJ0T5" Archived-At: Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2021 12:29:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --F3bvUqw77XI9fXIO6a7PD790IgU1sJ0T5 Content-Type: multipart/mixed; boundary="AeFJqrmW08CMbzj51AWpLYd44FgKoJidh"; protected-headers="v1" From: Eliot Lear To: Mirja Kuehlewind Cc: "rfced-future@iab.org" Message-ID: Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 References: <2B46402F-5268-46B7-890F-7C5CA159EF13@ietf.org> <25FCCF71-ED00-48CA-8A15-4BB63B632F73@kuehlewind.net> In-Reply-To: <25FCCF71-ED00-48CA-8A15-4BB63B632F73@kuehlewind.net> --AeFJqrmW08CMbzj51AWpLYd44FgKoJidh Content-Type: multipart/alternative; boundary="------------528AC3DC6EC8175C8BEEE8E8" Content-Language: en-US This is a multi-part message in MIME format. --------------528AC3DC6EC8175C8BEEE8E8 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Ok. I have, perhaps poorly, attempted to piece together what I think is=20 roughly what we're all talking about.=C2=A0 I may have entirely gotten th= is=20 wrong, and so please nitpick.=C2=A0 There is one sentence in brackets tha= t I=20 think is redundant.=C2=A0 I have not really touched the relationship text= =2E Eliot # Roles and Processes ## RFC Production Center (RPC) Publication of RFCs shall continue to be handled by the RFC Production=20 Center (RPC) function in accordance with high-level policies that have=20 been specified through the RSWG/RSAB process.=C2=A0 [[The RPC shall imple= ment=20 the policies specified by the RSWG/RSAB process reflecting the=20 priorities of the community.]] They shall report regularly to and=20 consult with the RSAB, RSWG, and broader community regarding status of=20 work undertaken and plans for work to be done, including timeline for=20 implementation as well as any key risks they identify.=C2=A0 In doing so,= the=20 RPC will observe the principle of transparency. The RPC shall consult=20 with the RSAB for advice on how to resolve any conflicts that arise from = community input. All matters of budget, timetable and impact on its performance targets,=20 are between the RPC and IETF LLC. ### Relationship between the RPC and the IETF LLC This document does not specify the exact relationship between the IETF=20 LLC and the RPC function; for example, the RPC function could be=20 provided by a separate corporate entity under contract to the IETF LLC,=20 it could be performed by employees of the IETF LLC, or the IETF LLC=20 could work with independent contractors for some or all aspects of the=20 RPC function. The exact relationship is a matter for the IETF LLC and=20 the IETF Executive Director to determine. The IETF LLC has authority over negotiating performance targets for the=20 RPC and also has responsibility for ensuring that those targets are=20 adhered to. If individuals or groups within the community have concerns about the=20 performance of the RPC, they can request that the IETF LLC look into the = matter. Even if the IETF LLC opts to delegate this activity, concerns=20 should be raised with the IETF LLC. The IETF LLC is ultimately=20 responsible to the community via the mechanisms outlined in its charter. -------- --------------528AC3DC6EC8175C8BEEE8E8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Ok.

<no hats>

I have, perhaps poorly, attempted to piece together what I think is roughly what we're all talking about.=C2=A0 I may have entirely gotten this wrong, and so please nitpick.=C2=A0 There is one senten= ce in brackets that I think is redundant.=C2=A0 I have not really touc= hed the relationship text.

Eliot

# Roles and Processes


## RFC Production Center (RPC)


Publication of RFCs shall continue to be handled by the RFC Productio= n Center (RPC) function in accordance with high-level policies that have = been specified through the RSWG/RSAB process.=C2=A0 [[The RPC shall imple= ment the policies specified by the RSWG/RSAB process reflecting the prior= ities of the community.]] They shall report regularly to and consult with= the RSAB, RSWG, and broader community regarding status of work undertake= n and plans for work to be done, including timeline for implementation as= well as any key risks they identify.=C2=A0 In doing so, the RPC will obs= erve the principle of transparency. The RPC shall consult with the RSAB f= or advice on how to resolve any conflicts that arise from community input= =2E


All matters of budget, timetable and impact on its performance target= s, are between the RPC and IETF LLC.


### Relationship between the RPC and the IETF LLC


This document does not specify the exact relationship between the IET= F LLC and the RPC function; for example, the RPC function could be provid= ed by a separate corporate entity under contract to the IETF LLC, it coul= d be performed by employees of the IETF LLC, or the IETF LLC could work w= ith independent contractors for some or all aspects of the RPC function. = The exact relationship is a matter for the IETF LLC and the IETF Executiv= e Director to determine.


The IETF LLC has authority over negotiating performance targets for t= he RPC and also has responsibility for ensuring that those targets are ad= hered to.=C2=A0


If individuals or groups within the community have concerns about the= performance of the RPC, they can request that the IETF LLC look into the= matter. Even if the IETF LLC opts to delegate this activity, concerns sh= ould be raised with the IETF LLC. The IETF LLC is ultimately responsible = to the community via the mechanisms outlined in its charter.

--------





--------------528AC3DC6EC8175C8BEEE8E8-- --AeFJqrmW08CMbzj51AWpLYd44FgKoJidh-- --F3bvUqw77XI9fXIO6a7PD790IgU1sJ0T5 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmEk5iYFAwAAAAAACgkQh7ZrRtnSejPn 5wgAsDjcNIhrtZ1yA2kFr+8HvRroz28XB2hoMe0tFVt4Ke/zJtq8IPtqMBipyPyIBtqIqCZ3hdEt lENB1kq7zTcAQ9gtfLraKl3kNWveDvfAFfV+oKYri1Vbd4FSKBUEtWrRsZeKok5xvXFPinXiU8oo 4aW7aSfHoLeZcHn21v+YevIEfqA9HO2yvV782/F2zmpEHXwTPH3gXoxZM/eMCTlp90LFLHfShcrV WsW/QlXUV5WLLaNZz9URSNW4qXYUkrmDCcZpnt15f9orf4JaMMecyFKzZ9VsbX59HXTWLNLN7m7p ddB1bTv6k/ciFSn/lpyfwgZoXBnG4v1y/CZ9hr5L4w== =s3DE -----END PGP SIGNATURE----- --F3bvUqw77XI9fXIO6a7PD790IgU1sJ0T5-- From nobody Tue Aug 24 05:34:06 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C56063A0FC9 for ; Tue, 24 Aug 2021 05:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org 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 Vp5v296vuHrL for ; Tue, 24 Aug 2021 05:33:46 -0700 (PDT) Received: from mail.eggert.org (mail.eggert.org [91.190.195.94]) (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 052DC3A102C for ; Tue, 24 Aug 2021 05:33:46 -0700 (PDT) Received: from smtpclient.apple (unknown [IPv6:2a00:ac00:4000:400:1815:5480:b768:b865]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 1A832600370; Tue, 24 Aug 2021 15:33:39 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1629808419; bh=3TOLZVawuHDzC0yLxXqYGHNVG9cYqtMg7eoZ1W70RIQ=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=A+Da9j/qgDbeSo9lSIGrCXy3ozET4eXXDr3jdyJgaUI3Fx+27+wFb9ryYOBeFtYZA c6PMAUWgW6742Y1yVS2mhOPeMpaOyLipdTC0Zty/QZMgWI5wl4ky+bcak2F3gz/V55 oWFgkoqkn/2ilf/B4ku0NG0URiMc6HUR8RiuHc5w= From: Lars Eggert Message-Id: <5E519E19-58BC-4ED6-A110-2D0B8B585827@eggert.org> Content-Type: multipart/signed; boundary="Apple-Mail=_A8A1C625-2C66-4306-82E4-8F5C17A18B3A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Tue, 24 Aug 2021 15:33:37 +0300 In-Reply-To: Cc: =?utf-8?Q?Mirja_K=C3=BChlewind?= , "rfced-future@iab.org" To: Eliot Lear References: <2B46402F-5268-46B7-890F-7C5CA159EF13@ietf.org> <25FCCF71-ED00-48CA-8A15-4BB63B632F73@kuehlewind.net> X-MailScanner-ID: 1A832600370.A2B8C X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2021 12:34:05 -0000 --Apple-Mail=_A8A1C625-2C66-4306-82E4-8F5C17A18B3A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2021-8-24, at 15:29, Eliot Lear wrote: > I have, perhaps poorly, attempted to piece together what I think is = roughly what we're all talking about. I may have entirely gotten this = wrong, and so please nitpick. There is one sentence in brackets that I = think is redundant. I have not really touched the relationship text. >=20 > Eliot >=20 > # Roles and Processes this would work for me, with or without the sentence in brackets. Thanks, Lars --Apple-Mail=_A8A1C625-2C66-4306-82E4-8F5C17A18B3A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmEk5yEACgkQVLXDCb9w wVc0bA/+P90t6N9AXG5+X5P3b9bvPx+qmBu6YvUNCIGVLE40yaHiV/7fW7Tiig/y gkPCQIgtDNV0M7rzH4hJ+/2n4DELSp9r8fCtXqkLbkS7+oNJl7EQo0sHNXPIONkf THufv3LCVrAKC+wStFIxhWC85e09oCJS4guzkBi8WM3prV1kkR8FMPsjkNVe5tv7 mKs9/eAhJI9BoSF3DuPCaX6K1W6RaI18GgDNSecEoBZOL5jfTBbHv8xkuzTLGh1V 24xAiWb40IZY11L2HNp07pu9pSZzz2KPWrceTZaU3VuNOkydeQZQkLErQq3Mnoc/ Q7/rZ21Xy0WZ1a8Qu76peF/HiIkFUv6CQGFW/s6ubGkmd5TSXmUnaXO8slLZRoPc JTB3ql6NhnegD8ORGmFkySYuRzzHWvkbtyw9/t71byLhyKGOPcmlbUOCKLMFWQp/ +ETFiyvaqPaGcMrNpTxRw6rm0Qyfrl0MEzsJNJqoBIC3K8RdlCpJutnPr9QrRQsM 1sArpu6nsSIJjn9mJSXxATZvY9MPx1a1ACFjuRNa1MbtUAVv2/+IyoZfCxW1S1n/ Gx6TtOK/zoydmstGdHaVF5G9O+teVsM5a1qxBOC1eqpZ/xUnKMVBEr53r0HP9dnO 9V+yVG5lG2kMPhIrOG10KD/ZzvQGowLW+X/jPdz/7Yz/ntuz528= =ftCp -----END PGP SIGNATURE----- --Apple-Mail=_A8A1C625-2C66-4306-82E4-8F5C17A18B3A-- From nobody Tue Aug 24 07:22:01 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6CAB3A0FCF for ; Tue, 24 Aug 2021 07:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 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, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch 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 p_-OReBMleiA for ; Tue, 24 Aug 2021 07:21:51 -0700 (PDT) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BB643A0FCD for ; Tue, 24 Aug 2021 07:21:50 -0700 (PDT) Received: from [IPv6:2001:420:c0c0:1011::3] ([IPv6:2001:420:c0c0:1011:0:0:0:3]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 17OELiuo203387 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Tue, 24 Aug 2021 16:21:45 +0200 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1629814905; bh=DfyG/DimhB+OijZOmbMztovSZeiNHrthzmq/57tO//Y=; h=To:Cc:From:Subject:Date:From; b=mvdLvhFNdPSxofAX7K0AUrTDplDLtqX32VvY0X0XfogxDBT9SarVktnDzwDKc4yZE 2srRRzSr2g2SKL3NCqvFKsKjukFBpomRrVfMnSq+f5QL/JWW3AtPR1HPER69rZOIaK vItKr11Cb0CGeDWlkBNaOabJJaabgavDN6ioku78= To: "rfced-future@iab.org" Cc: Brian Rosen From: Eliot Lear Message-ID: <8f30de10-af84-adbd-783e-169b637ddd3d@lear.ch> Date: Tue, 24 Aug 2021 16:21:41 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ITRcL0d9HcZaexItmgOEUoHAhOW7aXRxV" Archived-At: Subject: [Rfced-future] Thursday interim 20:00 GMT X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2021 14:21:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ITRcL0d9HcZaexItmgOEUoHAhOW7aXRxV Content-Type: multipart/mixed; boundary="nSCFm71rzJHTxSqwm3ml3HQ4fJYEYRdsv"; protected-headers="v1" From: Eliot Lear To: "rfced-future@iab.org" Cc: Brian Rosen Message-ID: <8f30de10-af84-adbd-783e-169b637ddd3d@lear.ch> Subject: Thursday interim 20:00 GMT --nSCFm71rzJHTxSqwm3ml3HQ4fJYEYRdsv Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Slides for Thursday's interim are now available for your perusal: https://datatracker.ietf.org/doc/slides-interim-2021-rfcefdp-06-sessa-cha= irs-slides/ The meeting will use the following Webex: https://cisco.webex.com/cisco/j.php?MTID=3Dmcf0743ad8682dede5c72bb005abe9= dc Your chairs seek a volunteer to take minutes.=C2=A0 Apply within ;-) --nSCFm71rzJHTxSqwm3ml3HQ4fJYEYRdsv-- --ITRcL0d9HcZaexItmgOEUoHAhOW7aXRxV Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmElAHYFAwAAAAAACgkQh7ZrRtnSejMI zwf/VmxB9w6HbnrKNRa63pz1BR9NTgU+MZ3Lh3llfCWWt6Xwc00AThxyEhMF7u3Gxz8qHNngC7xL z1YRiR3QLfBkaFJVy7cxatwXjnNKsLUVISEkKW5I18Ju9ThAH5vYXg5BuhNK4Zgj9/iGnePDU41w 5sZgFhAMmgNT7vTVQvi8JW7SrAwmdZniUtrBLXXLE/WXn3Biq+nxp0kMxGH799F3P/hgmutgk5/y cGjNzorB5MefjdNE0BA7KoE/kyzeDS2xRGOzx+FlDXHRqVPayAxkiqj9FMLoVHDq3MA3TK4uyr7j AgkwHkkqTa178rsTxV94JaizrP7Qh3xGOVwEP3YB0Q== =26gP -----END PGP SIGNATURE----- --ITRcL0d9HcZaexItmgOEUoHAhOW7aXRxV-- From nobody Tue Aug 24 08:14:37 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91BC83A17D2 for ; Tue, 24 Aug 2021 08:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 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, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch 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 stbSmds6VAld for ; Tue, 24 Aug 2021 08:14:29 -0700 (PDT) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA56A3A1714 for ; Tue, 24 Aug 2021 08:14:28 -0700 (PDT) Received: from [IPv6:2001:420:c0c0:1011::3] ([IPv6:2001:420:c0c0:1011:0:0:0:3]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 17OFENsr204276 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Tue, 24 Aug 2021 17:14:24 +0200 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1629818064; bh=4PtqVPeBZsduwPZ9zqMjtfIUrNEUYsf9dNBC9cktK4U=; h=Subject:From:To:Cc:References:Date:In-Reply-To:From; b=o0WiILAmOi75OA6m3M+SEkPj9d4cxOzXjDmixmCb5Mi/TYIrEBcxZ1TzygnwLwA9y lvJKoMo5aSMCzusTZo4tHO4G5K0KvtjDjw0d6/S5G7wrXatWcNbgDcFt4gPIh4CKDu WPU0TLPDz9jvoLQmWLViyGNk5kkHyE+z9330FtOo= From: Eliot Lear To: "rfced-future@iab.org" Cc: Brian Rosen References: <8f30de10-af84-adbd-783e-169b637ddd3d@lear.ch> Message-ID: <122e59d0-6c26-a1c6-172f-86402838ea4e@lear.ch> Date: Tue, 24 Aug 2021 17:14:22 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <8f30de10-af84-adbd-783e-169b637ddd3d@lear.ch> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="f7TmRBlIfKxx48kRggAFA0Uiy9ZhsOjw5" Archived-At: Subject: [Rfced-future] Slight correction: Re: Thursday interim 20:00 GMT X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2021 15:14:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --f7TmRBlIfKxx48kRggAFA0Uiy9ZhsOjw5 Content-Type: multipart/mixed; boundary="BLMulMOf0zgyW9PNGS4jjaxgRXjMyVSDf"; protected-headers="v1" From: Eliot Lear To: "rfced-future@iab.org" Cc: Brian Rosen Message-ID: <122e59d0-6c26-a1c6-172f-86402838ea4e@lear.ch> Subject: Slight correction: Re: Thursday interim 20:00 GMT References: <8f30de10-af84-adbd-783e-169b637ddd3d@lear.ch> In-Reply-To: <8f30de10-af84-adbd-783e-169b637ddd3d@lear.ch> --BLMulMOf0zgyW9PNGS4jjaxgRXjMyVSDf Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US On 24.08.21 16:21, Eliot Lear wrote: > > The meeting will use the following Webex: > > https://cisco.webex.com/cisco/j.php?MTID=3Dmcf0743ad8682dede5c72bb005ab= e9dc1 > (I accidentally clipped the 1 at the end in the previous email) --BLMulMOf0zgyW9PNGS4jjaxgRXjMyVSDf-- --f7TmRBlIfKxx48kRggAFA0Uiy9ZhsOjw5 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmElDM4FAwAAAAAACgkQh7ZrRtnSejMU mgf+JZroFlTlkZ/MRvDepPIizrGzkOH8x0BhQqCyYxKboHzHdx+5dQDsIKO0Ozmy1ygKEM0XHvJG +rdHe0cmbQJWr2OOauu3pG9vSaqGawg6xlBj3LPy2vilgxdbdSHrBJ5mxPi6bGfXG44DNSiEYhfG yQZUPJmhLLk9LpZFjEWKQ9FYbn/pRv9E0c8TBEzMwFIZBDYM7M8DPi74iQeyC4veg7ayNpAwC4v2 chUGAaD9QE3y+BIWyQE9dKk+Q4RHKl1fCRRVhhJS84pgPW2bC5VEGvnY4CgpEO6y/GBETdZUQuxb kKQ5pRt3kAbKRsrn95n/ArBE23K6aZHsLURjDOK5BQ== =yZM2 -----END PGP SIGNATURE----- --f7TmRBlIfKxx48kRggAFA0Uiy9ZhsOjw5-- From nobody Tue Aug 24 08:26:06 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B642D3A183B for ; Tue, 24 Aug 2021 08:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 cQ5c6Ebd0dwE for ; Tue, 24 Aug 2021 08:25:58 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73DDD3A1841 for ; Tue, 24 Aug 2021 08:25:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4GvCcP5sw3z6G9vS; Tue, 24 Aug 2021 08:25:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1629818757; bh=w34CrOCEWe4W4P30pdcSpWU9iSa2jqs1XLlkueC+3E8=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=NZJ+CY8cDPJxfWrNDjLiO9aBmGTSLi6UEBN8iV/o/R2R74WsyekvlLB/mVDjFGNy0 ohumCvjt3nC0ojgX1CCrTWJuWaxfvoA3G82KZvVXYL61WOIcJ2r1YtKwTAd6Do63mk EvGTGGx2r7n1+SVznKgDuYmGVHpR86sRNTZMXkbs= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.23.64] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4GvCcP1X3Jz6G9pB; Tue, 24 Aug 2021 08:25:57 -0700 (PDT) To: Eliot Lear , Mirja Kuehlewind Cc: "rfced-future@iab.org" References: <2B46402F-5268-46B7-890F-7C5CA159EF13@ietf.org> <25FCCF71-ED00-48CA-8A15-4BB63B632F73@kuehlewind.net> From: "Joel M. Halpern" Message-ID: Date: Tue, 24 Aug 2021 11:25:56 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2021 15:26:04 -0000 I think that the bracketed sentence should e deleted. It seems to require that once the RSWG / RSAB have approved a policy, the RPC must implement it. Even if it costs money and the LLC has not yet allocated the funds. That would seem to put them in a very difficult position. Yours, Joel On 8/24/2021 8:29 AM, Eliot Lear wrote: > Ok. > > > > I have, perhaps poorly, attempted to piece together what I think is > roughly what we're all talking about.  I may have entirely gotten this > wrong, and so please nitpick.  There is one sentence in brackets that I > think is redundant.  I have not really touched the relationship text. > > Eliot > > # Roles and Processes > > > ## RFC Production Center (RPC) > > > Publication of RFCs shall continue to be handled by the RFC Production > Center (RPC) function in accordance with high-level policies that have > been specified through the RSWG/RSAB process.  [[The RPC shall implement > the policies specified by the RSWG/RSAB process reflecting the > priorities of the community.]] They shall report regularly to and > consult with the RSAB, RSWG, and broader community regarding status of > work undertaken and plans for work to be done, including timeline for > implementation as well as any key risks they identify.  In doing so, the > RPC will observe the principle of transparency. The RPC shall consult > with the RSAB for advice on how to resolve any conflicts that arise from > community input. > > > All matters of budget, timetable and impact on its performance targets, > are between the RPC and IETF LLC. > > > ### Relationship between the RPC and the IETF LLC > > > This document does not specify the exact relationship between the IETF > LLC and the RPC function; for example, the RPC function could be > provided by a separate corporate entity under contract to the IETF LLC, > it could be performed by employees of the IETF LLC, or the IETF LLC > could work with independent contractors for some or all aspects of the > RPC function. The exact relationship is a matter for the IETF LLC and > the IETF Executive Director to determine. > > > The IETF LLC has authority over negotiating performance targets for the > RPC and also has responsibility for ensuring that those targets are > adhered to. > > > If individuals or groups within the community have concerns about the > performance of the RPC, they can request that the IETF LLC look into the > matter. Even if the IETF LLC opts to delegate this activity, concerns > should be raised with the IETF LLC. The IETF LLC is ultimately > responsible to the community via the mechanisms outlined in its charter. > > -------- > > > > > > From nobody Tue Aug 24 08:29:51 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5B013A1868 for ; Tue, 24 Aug 2021 08:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=me.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 QcJyiPILuGF9 for ; Tue, 24 Aug 2021 08:29:43 -0700 (PDT) Received: from mr85p00im-ztdg06011801.me.com (mr85p00im-ztdg06011801.me.com [17.58.23.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D98BD3A1865 for ; Tue, 24 Aug 2021 08:29:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=1a1hai; t=1629818983; bh=IWlP2pWT+zfmBtMLFXn3neWBcXYW8i4XNQGheFleOpw=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=zNNLcc72XrZYsCqHybIPKc8W4/G8+PrfzrW/bW7XBzkpggTs8XK18HYi9fNHM5GSQ VSYa6sRhZbHeN76eZcJgREmCHXV2Q3+Jj92kuLQTiDEMB8XKooASZfhyYBubLgCxY+ CKkW12PUrRwIHctg3+S4PdPNSdGDw6gF7m7Da0DL99s8kR1eItSjodR5pc4+w8oU5m olmi6kfOzLUwHjv69bgH4QFd8zyGOrMmYeags4pXDpI6aiZGr/Hgzp/sGDXQR5brmZ rONN7+RPM+57LQ/zXTcuGhEg0igN7MB7Y34b12la24ueB2EprBhet4GrJXcVygJYVI O6PZkoVKVCVKg== Received: from smtpclient.apple (157-131-155-250.fiber.dynamic.sonic.net [157.131.155.250]) by mr85p00im-ztdg06011801.me.com (Postfix) with ESMTPSA id 522EBC06BD; Tue, 24 Aug 2021 15:29:43 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Ole Jacobsen In-Reply-To: <122e59d0-6c26-a1c6-172f-86402838ea4e@lear.ch> Date: Tue, 24 Aug 2021 08:29:42 -0700 Cc: Ole Jacobsen , "rfced-future@iab.org" , Brian Rosen Content-Transfer-Encoding: 7bit Message-Id: References: <8f30de10-af84-adbd-783e-169b637ddd3d@lear.ch> <122e59d0-6c26-a1c6-172f-86402838ea4e@lear.ch> To: Eliot Lear X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Proofpoint-Virus-Version: =?UTF-8?Q?vendor=3Dfsecure_engine=3D1.1.170-22c6f66c430a71ce266a39bfe25bc?= =?UTF-8?Q?2903e8d5c8f:6.0.391,18.0.790,17.0.607.475.0000000_definitions?= =?UTF-8?Q?=3D2021-08-24=5F04:2021-08-23=5F01,2021-08-24=5F04,2020-04-07?= =?UTF-8?Q?=5F01_signatures=3D0?= X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1015 mlxlogscore=999 phishscore=0 bulkscore=0 suspectscore=0 adultscore=0 malwarescore=0 mlxscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2108240102 Archived-At: Subject: Re: [Rfced-future] Slight correction: Re: Thursday interim 20:00 GMT X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2021 15:29:50 -0000 Suggestion: When you send out announcements for meetings, include a calendar invite file (.ics or other standard). That way, we will know not only how to join the meeting, but also when the meeting is. Embedded in the calendar file can be the WebEx links, notes, pointers to docs, anything... Ole > On Aug 24, 2021, at 08:14, Eliot Lear wrote: > > > On 24.08.21 16:21, Eliot Lear wrote: >> >> The meeting will use the following Webex: >> >> https://cisco.webex.com/cisco/j.php?MTID=mcf0743ad8682dede5c72bb005abe9dc1 >> > (I accidentally clipped the 1 at the end in the previous email) > > > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future Ole J. Jacobsen Editor and Publisher The Internet Protocol Journal Office: +1 415-550-9433 Cell: +1 415-370-4628 Web: protocoljournal.org E-mail: olejacobsen@me.com E-mail: ole@protocoljournal.org Skype: organdemo From nobody Tue Aug 24 08:32:18 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0483A1882 for ; Tue, 24 Aug 2021 08:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 I_mQRFHZ_fxF for ; Tue, 24 Aug 2021 08:32:10 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E93693A1880 for ; Tue, 24 Aug 2021 08:32:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4GvClZ5qWmz6G9ry; Tue, 24 Aug 2021 08:32:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1629819130; bh=mWuVLt259vrBC+M+xSOQWQ1+TSq8zJaY2YL6fG3Spb4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=FmPKwRNDOP+HAEGsjDirCVCaUefLg3AfnFrfCFvEg/qvDNATDZw/s1vMqTRsYk5PA 3JFbgoJiVnSWLK54bsSlyNrJ9evUZkxP8wq6G7ApBXtW6TsX5/TA0q7zrdM/eSyVks baypvY+tmBuzEm5WDvk7GPYpHFgL9QnWb0D8O9Hc= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.23.64] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4GvClZ1Yrgz6G99T; Tue, 24 Aug 2021 08:32:10 -0700 (PDT) To: Eliot Lear Cc: "rfced-future@iab.org" References: <9f3100b9-0b19-a024-e597-dfcd112b0f57@lear.ch> From: "Joel M. Halpern" Message-ID: <14522b15-ec15-6c3e-530e-34de0103aec1@joelhalpern.com> Date: Tue, 24 Aug 2021 11:32:09 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <9f3100b9-0b19-a024-e597-dfcd112b0f57@lear.ch> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Issue 45: When do the WG chairs call rough consensus and what happens next? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2021 15:32:16 -0000 After discussing the below with Eliot, he raised an idea which I think will work. What if we added a little text saying that: o chairs call consensus o chairs do their best to judge the actual rough consensus of the WG o chairs are also expected to participate as individuals in the work of the WG o chairs are expected to consider their own input as individuals along with all other input in judging rough consensus. That seems to give them the room to raise "but this isn't good enough", but require them to move the document forward if the WG does not agree. This is how I tend to assume things work in IETF WGs. It seems to me to be worth stating here since this is not an IETF WG. Yours, Joel PS: I am happy to leave the task of weaving that into the existing text to the editor :-) If it is harder than I think, I am also happy to help. On 8/14/2021 4:55 AM, Eliot Lear wrote: > Hi Joel, > >> Joel Halpern issue JMH5 >> Reading the process, I was struck by a minor gap in the process items. >> specifically in item 4 on issueing the last call. I think the text >> should include that the WG Chairs consider the proposal to be >> sufficiently developed and refined. We sometimes have situations where >> there is rough consensus for something, but it really needs a little >> more work before it is sent out. Obviously, we do not want to require >> perfection. But we do want to give the chairs room to say "this needs >> more work". > > > This is from an issue in April.  Since then we discussed several > eventualities, including what happens if the chairs attempt to block > consensus.  The outcome of that conversation seems to be the following: > >>    Community members who have concerns about >>    the performance of an RSWG chair should direct their feedback to the >>    relevant appointing body.  Each appointing body shall have the power >>    to remove its appointed chair at its discretion. > > That's looking at this issue from the other side, as it were. The way I > read this text, the chairs have some latitude on when to start a > consensus call, but if it goes too far, complaints will get to the > appointing bodies. > > With that in mind, do you believe the issue is addressed?  If not, is > there text you would want to add to address the matter? > > Eliot > > > From nobody Tue Aug 24 08:33:42 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C2A23A1889 for ; Tue, 24 Aug 2021 08:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 qMaNcZqHXK8K for ; Tue, 24 Aug 2021 08:33:34 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F61C3A1886 for ; Tue, 24 Aug 2021 08:33:34 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1mIYQY-000Esr-1V; Tue, 24 Aug 2021 11:33:26 -0400 Date: Tue, 24 Aug 2021 11:33:20 -0400 From: John C Klensin To: "Joel M. Halpern" , Eliot Lear , Mirja Kuehlewind cc: rfced-future@iab.org Message-ID: <9F88E9DAC50B257953403E71@PSB> In-Reply-To: References: <2B46402F-5268-46B7-890F-7C5CA159EF13@ietf.org> <25FCCF71-ED00-48CA-8A15-4BB63B632F73@kuehlewind.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2021 15:33:40 -0000 Joel, While the phrasing may be wrong for the reason you identify, the sentence is probably a useful statement of intent. This is a question because I'm not sure, but I wonder if, rather than removing the sentence, it would be useful to add a few qualifying words such as "resources permitting", "in coordination with the LLC about resources", or something like that. best, john --On Tuesday, August 24, 2021 11:25 -0400 "Joel M. Halpern" wrote: > I think that the bracketed sentence should e deleted. >=20 > It seems to require that once the RSWG / RSAB have approved a > policy, the RPC must implement it. Even if it costs money and > the LLC has not yet allocated the funds. That would seem to > put them in a very difficult position. >=20 > Yours, > Joel >=20 > On 8/24/2021 8:29 AM, Eliot Lear wrote: >> Ok. >>=20 >> >>=20 >> I have, perhaps poorly, attempted to piece together what I >> think is roughly what we're all talking about.=C2=A0 I may = have >> entirely gotten this wrong, and so please nitpick.=C2=A0 = There >> is one sentence in brackets that I think is redundant.=C2=A0 = I >> have not really touched the relationship text. >>=20 >> Eliot >>=20 >> # Roles and Processes >>=20 >>=20 >> ## RFC Production Center (RPC) >>=20 >>=20 >> Publication of RFCs shall continue to be handled by the RFC >> Production Center (RPC) function in accordance with >> high-level policies that have been specified through the >> RSWG/RSAB process.=C2=A0 [[The RPC shall implement the = policies >> specified by the RSWG/RSAB process reflecting the priorities >> of the community.]] They shall report regularly to and=20 >> consult with the RSAB, RSWG, and broader community regarding >> status of work undertaken and plans for work to be done, >> including timeline for implementation as well as any key >> risks they identify.=C2=A0 In doing so, the RPC will observe = the >> principle of transparency. The RPC shall consult with the >> RSAB for advice on how to resolve any conflicts that arise >> from community input. >>=20 >>=20 >> All matters of budget, timetable and impact on its >> performance targets, are between the RPC and IETF LLC. >>=20 >>=20 >> ### Relationship between the RPC and the IETF LLC >>=20 >>=20 >> This document does not specify the exact relationship between >> the IETF LLC and the RPC function; for example, the RPC >> function could be provided by a separate corporate entity >> under contract to the IETF LLC, it could be performed by >> employees of the IETF LLC, or the IETF LLC could work with >> independent contractors for some or all aspects of the RPC >> function. The exact relationship is a matter for the IETF LLC >> and the IETF Executive Director to determine. >>=20 >>=20 >> The IETF LLC has authority over negotiating performance >> targets for the RPC and also has responsibility for ensuring >> that those targets are adhered to. >>=20 >>=20 >> If individuals or groups within the community have concerns >> about the performance of the RPC, they can request that the >> IETF LLC look into the matter. Even if the IETF LLC opts to >> delegate this activity, concerns should be raised with the >> IETF LLC. The IETF LLC is ultimately responsible to the >> community via the mechanisms outlined in its charter. >>=20 >> -------- >>=20 >>=20 >>=20 >>=20 >>=20 From nobody Tue Aug 24 08:40:24 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A56DD3A18C2; Tue, 24 Aug 2021 08:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 yTPIPEbIj83H; Tue, 24 Aug 2021 08:40:16 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76D703A18BF; Tue, 24 Aug 2021 08:40:16 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1mIYX8-000EtS-4g; Tue, 24 Aug 2021 11:40:14 -0400 Date: Tue, 24 Aug 2021 11:40:08 -0400 From: John C Klensin To: Ole Jacobsen , Eliot Lear cc: rfced-future@iab.org, Ole Jacobsen , Brian Rosen Message-ID: In-Reply-To: References: <8f30de10-af84-adbd-783e-169b637ddd3d@lear.ch> <122e59d0-6c26-a1c6-172f-86402838ea4e@lear.ch> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfced-future] Slight correction: Re: Thursday interim 20:00 GMT X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2021 15:40:23 -0000 Just please do not make the ICS (or equivalent) file a substitute for the information in the announcement rather than an alternate way to provide that information. Some of us, for privacy and security reasons, will not use any of the common cloud-based calendars. I can read and use an ICS file if need be, but it is extra work. thanks, john --On Tuesday, August 24, 2021 08:29 -0700 Ole Jacobsen wrote: > > Suggestion: > > When you send out announcements for meetings, include a > calendar invite file (.ics or other standard). That way, we > will know not only how to join the meeting, but also when the > meeting is. Embedded in the calendar file can be the WebEx > links, notes, pointers to docs, anything... > > Ole > >> On Aug 24, 2021, at 08:14, Eliot Lear wrote: >> >> >> On 24.08.21 16:21, Eliot Lear wrote: >>> >>> The meeting will use the following Webex: >>> >>> https://cisco.webex.com/cisco/j.php?MTID=mcf0743ad8682dede5c >>> 72bb005abe9dc1 >>> >> (I accidentally clipped the 1 at the end in the previous >> email) >> >> >> >> -- >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future > > Ole J. Jacobsen > Editor and Publisher > The Internet Protocol Journal > Office: +1 415-550-9433 > Cell: +1 415-370-4628 > Web: protocoljournal.org > E-mail: olejacobsen@me.com > E-mail: ole@protocoljournal.org > Skype: organdemo From nobody Tue Aug 24 08:50:06 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E75ED3A1966 for ; Tue, 24 Aug 2021 08:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 SR17BZeXhwpM for ; Tue, 24 Aug 2021 08:49:48 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EEAC3A191A for ; Tue, 24 Aug 2021 08:49:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4GvD7w1jC1z6G9vS; Tue, 24 Aug 2021 08:49:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1629820188; bh=Cb/n8MScChpEM4mRVu3w0TudKb1jP6BUHPOZjCdjqCQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=hZZ04bjB/14ZfgM4v5rATX7Ap81B0g4uos5nH1YnfiLDV7Elpbgqjjln/Ial6jaZQ rmGwF9k7ER5YToEVKQeNuUbjd43eIkysU8PvJT+YisDUvo5fehHzrxBYKfDVIK94kx LkqizUz87l4lee4VYdHxiOUnXzbFY5wtyys76T3Y= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.23.64] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (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 maila2.tigertech.net (Postfix) with ESMTPSA id 4GvD7t5VKDz6G7X8; Tue, 24 Aug 2021 08:49:46 -0700 (PDT) To: John C Klensin , Eliot Lear , Mirja Kuehlewind Cc: rfced-future@iab.org References: <2B46402F-5268-46B7-890F-7C5CA159EF13@ietf.org> <25FCCF71-ED00-48CA-8A15-4BB63B632F73@kuehlewind.net> <9F88E9DAC50B257953403E71@PSB> From: "Joel M. Halpern" Message-ID: <6c544af8-b60c-1f4a-8730-3c923196eab6@joelhalpern.com> Date: Tue, 24 Aug 2021 11:49:45 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <9F88E9DAC50B257953403E71@PSB> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2021 15:50:04 -0000 I could live with "in coordination with the LLC about resources". Part of my thought on removing it is that we already have text that says that the RSWG / RSAB sets strategic policy. Not sure what this adds. Yours, Joel On 8/24/2021 11:33 AM, John C Klensin wrote: > Joel, > > While the phrasing may be wrong for the reason you identify, the > sentence is probably a useful statement of intent. > > This is a question because I'm not sure, but I wonder if, rather > than removing the sentence, it would be useful to add a few > qualifying words such as "resources permitting", "in > coordination with the LLC about resources", or something like > that. > > best, > john > > > > --On Tuesday, August 24, 2021 11:25 -0400 "Joel M. Halpern" > wrote: > >> I think that the bracketed sentence should e deleted. >> >> It seems to require that once the RSWG / RSAB have approved a >> policy, the RPC must implement it. Even if it costs money and >> the LLC has not yet allocated the funds. That would seem to >> put them in a very difficult position. >> >> Yours, >> Joel >> >> On 8/24/2021 8:29 AM, Eliot Lear wrote: >>> Ok. >>> >>> >>> >>> I have, perhaps poorly, attempted to piece together what I >>> think is roughly what we're all talking about.  I may have >>> entirely gotten this wrong, and so please nitpick.  There >>> is one sentence in brackets that I think is redundant.  I >>> have not really touched the relationship text. >>> >>> Eliot >>> >>> # Roles and Processes >>> >>> >>> ## RFC Production Center (RPC) >>> >>> >>> Publication of RFCs shall continue to be handled by the RFC >>> Production Center (RPC) function in accordance with >>> high-level policies that have been specified through the >>> RSWG/RSAB process.  [[The RPC shall implement the policies >>> specified by the RSWG/RSAB process reflecting the priorities >>> of the community.]] They shall report regularly to and >>> consult with the RSAB, RSWG, and broader community regarding >>> status of work undertaken and plans for work to be done, >>> including timeline for implementation as well as any key >>> risks they identify.  In doing so, the RPC will observe the >>> principle of transparency. The RPC shall consult with the >>> RSAB for advice on how to resolve any conflicts that arise >>> from community input. >>> >>> >>> All matters of budget, timetable and impact on its >>> performance targets, are between the RPC and IETF LLC. >>> >>> >>> ### Relationship between the RPC and the IETF LLC >>> >>> >>> This document does not specify the exact relationship between >>> the IETF LLC and the RPC function; for example, the RPC >>> function could be provided by a separate corporate entity >>> under contract to the IETF LLC, it could be performed by >>> employees of the IETF LLC, or the IETF LLC could work with >>> independent contractors for some or all aspects of the RPC >>> function. The exact relationship is a matter for the IETF LLC >>> and the IETF Executive Director to determine. >>> >>> >>> The IETF LLC has authority over negotiating performance >>> targets for the RPC and also has responsibility for ensuring >>> that those targets are adhered to. >>> >>> >>> If individuals or groups within the community have concerns >>> about the performance of the RPC, they can request that the >>> IETF LLC look into the matter. Even if the IETF LLC opts to >>> delegate this activity, concerns should be raised with the >>> IETF LLC. The IETF LLC is ultimately responsible to the >>> community via the mechanisms outlined in its charter. >>> >>> -------- >>> >>> >>> >>> >>> > > From nobody Tue Aug 24 09:14:22 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03A2F3A1BB7 for ; Tue, 24 Aug 2021 09:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 nWHBsguJkzpB for ; Tue, 24 Aug 2021 09:14:14 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 850B03A162A for ; Tue, 24 Aug 2021 09:14:13 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1mIZ3t-000Ewv-MG; Tue, 24 Aug 2021 12:14:05 -0400 Date: Tue, 24 Aug 2021 12:14:00 -0400 From: John C Klensin To: "Joel M. Halpern" , Eliot Lear , Mirja Kuehlewind cc: rfced-future@iab.org Message-ID: In-Reply-To: <6c544af8-b60c-1f4a-8730-3c923196eab6@joelhalpern.com> References: <2B46402F-5268-46B7-890F-7C5CA159EF13@ietf.org> <25FCCF71-ED00-48CA-8A15-4BB63B632F73@kuehlewind.net> <9F88E9DAC50B257953403E71@PSB> <6c544af8-b60c-1f4a-8730-3c923196eab6@joelhalpern.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2021 16:14:20 -0000 --On Tuesday, August 24, 2021 11:49 -0400 "Joel M. Halpern" wrote: > I could live with "in coordination with the LLC about > resources". > > Part of my thought on removing it is that we already have text > that says that the RSWG / RSAB sets strategic policy. Not > sure what this adds. it depends on how much we feel is required to be specified. My general bias is that we are specifying far too many details. Instead, we should be laying out general roles and principles, trusting people to Do the Right Thing, and being sure there is effective accountability if, for whatever reason (certainly including ones whose specifics we can't anticipate) they do not. On that basis, I think we would be better off dropping this sentence (and many more). However, I am clearly in the rough about that approach and even trying to express some of its implications has gotten me into trouble. Within the context of the current approach and document, some words about the RPC's obligations to implement strategic policy set by the other bodies seems perfectly reasonable. best, john From nobody Tue Aug 24 10:33:13 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAFF83A082B for ; Tue, 24 Aug 2021 10:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.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 t6EEPkA6K7E8 for ; Tue, 24 Aug 2021 10:33:05 -0700 (PDT) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 2234D3A082A for ; Tue, 24 Aug 2021 10:33:04 -0700 (PDT) Received: by mail-qk1-x72e.google.com with SMTP id m21so23978062qkm.13 for ; Tue, 24 Aug 2021 10:33:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=qHbrH6rHjAIWRLV/YoOEV+e9syShifCPrpmTd6vx0O4=; b=aeilMvuaaKNXwzzQdsvekTCr7zLU6+xfvQn+d7l5X2s3p45XF7e8IAbZBSV/JNmiDb //T2IoaPimsGqFEnzJ+5EBsxD14oziu/ieVHoyvriJZid23G3kq8oP5T7xK5ggQi6xtX ZJUuj5+U4IpAYWpP2s/cI32WwuMIQ4ukBC+lfJW1yKU6YUUJfGdaTodHjMOy2NdTVfoE tYN4D5v38AUWX1FLC2WftK8sz4D8R9TdGYVxnHOjlFoZy0xXRjcs90nMwFU0ilo6DPJK Mij6QGXGhaeC4KzKdte8PU5krcLJ6Yd7XSWXJGMfsJL5lY3L/zUgSFPh0bIFtPSAmIki JkpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=qHbrH6rHjAIWRLV/YoOEV+e9syShifCPrpmTd6vx0O4=; b=jo8oAqMz8esZC5xdjhHBBaXT+2iWjNe8fUjDY2VWrOTeYWQYRnWLJsBwBfc9MTGpk0 G7PDkzt8dW9BPxPHjKCPEvRc4tQy+Ub7sfJZ0ZJJhbCX9u499nplP/KqOndgzpM8kHzW xLWQVKlp/+QV66pJZKBmUrQkVG30zkgoPPtSKwG2vh2xeKQEw64iOUvwjuoRWKskZ0Iu iOlC1lHBEZF1O6wtFMMpQGd6wAg5ySg3r4YUfBZhZMqdrbQPmb/MZ0gM9/fjO34wNPw6 cpQPTJ/p/BUjPRYFCx15i3VX3Qjxd5gtDe167vBOvwWYhS0k6hPHLVqaSmcvxtuX9oTq dB2A== X-Gm-Message-State: AOAM530PjuWLjLWXj7thkBAyn9dlDdjK6gj5l3hyiKHF7GVM4ez6ZWUU vgn25/aQme47RxbcOrPIzOFmO1IWLig2KNUK X-Google-Smtp-Source: ABdhPJwLa5GbA56MsDzXd/jE1fnd6CRIjUxmBdTzR+UkYP97H3aX24nluH6kkpsVVaeAWJB/oUd3sw== X-Received: by 2002:a37:6303:: with SMTP id x3mr27817534qkb.214.1629826381046; Tue, 24 Aug 2021 10:33:01 -0700 (PDT) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id f12sm8697370qtj.40.2021.08.24.10.33.00 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 24 Aug 2021 10:33:00 -0700 (PDT) To: rfced-future@iab.org References: <2B46402F-5268-46B7-890F-7C5CA159EF13@ietf.org> <25FCCF71-ED00-48CA-8A15-4BB63B632F73@kuehlewind.net> <9F88E9DAC50B257953403E71@PSB> <6c544af8-b60c-1f4a-8730-3c923196eab6@joelhalpern.com> From: Michael StJohns Message-ID: Date: Tue, 24 Aug 2021 13:32:58 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <6c544af8-b60c-1f4a-8730-3c923196eab6@joelhalpern.com> Content-Type: multipart/alternative; boundary="------------D341C654A7FA89F970919D9E" Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2021 17:33:11 -0000 This is a multi-part message in MIME format. --------------D341C654A7FA89F970919D9E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi - Unfortunately I can't live with the paragraph in general, even with the various changes.   Basically, this section still reads as if there is a oversight, monitoring, or directive relationship between the RSWG/RSAB/community and the RPC.  It also does a poor job of describing the relationship between the RPC and the RSAB and RSCE for the advisory purposes. So instead: ## RFC Production Center (RPC) Publication of RFCs shall continue to be handled by the RFC Production  Center (RPC) function in accordance with policies described in the Editorial series of RFCs, and consistent with the engagement agreement(s) between the RPC and the LLC. * The LLC is requested to negotiate a deliverable with the RPC that results in regular updates to the community regarding status of work undertaken, planned work,  implementation timelines, and any identified risks to those timelines. * The LLC is requested to negotiate a task with the RPC that permits and requires the RPC to collaborate in at least an advisory capacity in the content creation of the Editorial series RFCs as they affect the RPC and that collaboration is expected to be the main path for community input into the RPC processes. The RPC shall consult  with the RSAB generally and the RSCE specifically for advice on how to resolve any conflicts that arise between the RSWG proposed documents, the Editorial series,  the RPC's existing engagement agreement's scope, and any technical or cost limitations for implementing the Editorial series policies, and if necessary, shall refer any issues unresolved after such consultation to the LLC or the IED for final resolution. ## Relationship between the RPC and the RSAB or RSWG Neither the RSAB nor the RSWG has any oversight, monitoring, or directive relationship with respect to the RPC.  The RSAB and RSCE have an advisory relationship with the RPC as described above. -30- Mike On 8/24/2021 11:49 AM, Joel M. Halpern wrote: > I could live with "in coordination with the LLC about resources". > > Part of my thought on removing it is that we already have text that > says that the RSWG / RSAB sets strategic policy.  Not sure what this > adds. > > Yours, > Joel > > On 8/24/2021 11:33 AM, John C Klensin wrote: >> Joel, >> >> While the phrasing may be wrong for the reason you identify, the >> sentence is probably a useful statement of intent. >> >> This is a question because I'm not sure, but I wonder if, rather >> than removing the sentence, it would be useful to add a few >> qualifying words such as "resources permitting", "in >> coordination with the LLC about resources", or something like >> that. >> >> best, >>     john >> >> >> >> --On Tuesday, August 24, 2021 11:25 -0400 "Joel M. Halpern" >> wrote: >> >>> I think that the bracketed sentence should e deleted. >>> >>> It seems to require that once the RSWG / RSAB have approved a >>> policy, the RPC must implement it.  Even if it costs money and >>> the LLC has not yet allocated the funds.  That would seem to >>> put them in a very difficult position. >>> >>> Yours, >>> Joel >>> >>> On 8/24/2021 8:29 AM, Eliot Lear wrote: >>>> Ok. >>>> >>>> >>>> >>>> I have, perhaps poorly, attempted to piece together what I >>>> think is  roughly what we're all talking about.  I may have >>>> entirely gotten this  wrong, and so please nitpick.  There >>>> is one sentence in brackets that I  think is redundant.  I >>>> have not really touched the relationship text. >>>> >>>> Eliot >>>> >>>> # Roles and Processes >>>> >>>> >>>> ## RFC Production Center (RPC) >>>> >>>> >>>> Publication of RFCs shall continue to be handled by the RFC >>>> Production  Center (RPC) function in accordance with >>>> high-level policies that have  been specified through the >>>> RSWG/RSAB process.  [[The RPC shall implement  the policies >>>> specified by the RSWG/RSAB process reflecting the priorities >>>> of the community.]] They shall report regularly to and >>>> consult with the RSAB, RSWG, and broader community regarding >>>> status of  work undertaken and plans for work to be done, >>>> including timeline for  implementation as well as any key >>>> risks they identify.  In doing so, the  RPC will observe the >>>> principle of transparency. The RPC shall consult  with the >>>> RSAB for advice on how to resolve any conflicts that arise >>>> from  community input. >>>> >>>> >>>> All matters of budget, timetable and impact on its >>>> performance targets,  are between the RPC and IETF LLC. >>>> >>>> >>>> ### Relationship between the RPC and the IETF LLC >>>> >>>> >>>> This document does not specify the exact relationship between >>>> the IETF  LLC and the RPC function; for example, the RPC >>>> function could be  provided by a separate corporate entity >>>> under contract to the IETF LLC,  it could be performed by >>>> employees of the IETF LLC, or the IETF LLC  could work with >>>> independent contractors for some or all aspects of the  RPC >>>> function. The exact relationship is a matter for the IETF LLC >>>> and  the IETF Executive Director to determine. >>>> >>>> >>>> The IETF LLC has authority over negotiating performance >>>> targets for the  RPC and also has responsibility for ensuring >>>> that those targets are  adhered to. >>>> >>>> >>>> If individuals or groups within the community have concerns >>>> about the  performance of the RPC, they can request that the >>>> IETF LLC look into the  matter. Even if the IETF LLC opts to >>>> delegate this activity, concerns  should be raised with the >>>> IETF LLC. The IETF LLC is ultimately  responsible to the >>>> community via the mechanisms outlined in its charter. >>>> >>>> -------- >>>> >>>> >>>> >>>> >>>> >> >> > --------------D341C654A7FA89F970919D9E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi -

Unfortunately I can't live with the paragraph in general, even with the various changes.   Basically, this section still reads as if there is a oversight, monitoring, or directive relationship between the RSWG/RSAB/community and the RPC.  It also does a poor job of describing the relationship between the RPC and the RSAB and RSCE for the advisory purposes.

So instead:

## RFC Production Center (RPC)

Publication of RFCs shall continue to be handled by the RFC Production  Center (RPC) function in accordance with policies described in the Editorial series of RFCs, and consistent with the engagement agreement(s) between the RPC and the LLC. 
  • The LLC is requested to negotiate a deliverable with the RPC that results in regular updates to the community regarding status of work undertaken, planned work,  implementation timelines, and any identified risks to those timelines.
  • The LLC is requested to negotiate a task with the RPC that permits and requires the RPC to collaborate in at least an advisory capacity in the content creation of the Editorial series RFCs as they affect the RPC and that collaboration is expected to be the main path for community input into the RPC processes.

The RPC shall consult  with the RSAB generally and the RSCE specifically for advice on how to resolve any conflicts that arise between the RSWG proposed documents, the Editorial series,  the RPC's existing engagement agreement's scope, and any technical or cost limitations for implementing the Editorial series policies, and if necessary,  shall refer any issues unresolved after such consultation to the LLC or the IED for final resolution.

## Relationship between the RPC and the RSAB or RSWG

Neither the RSAB nor the RSWG has any oversight, monitoring, or directive relationship with respect to the RPC.  The RSAB and RSCE have an advisory relationship with the RPC as described above.


-30-

Mike


On 8/24/2021 11:49 AM, Joel M. Halpern wrote:
I could live with "in coordination with the LLC about resources".

Part of my thought on removing it is that we already have text that says that the RSWG / RSAB sets strategic policy.  Not sure what this adds.

Yours,
Joel

On 8/24/2021 11:33 AM, John C Klensin wrote:
Joel,

While the phrasing may be wrong for the reason you identify, the
sentence is probably a useful statement of intent.

This is a question because I'm not sure, but I wonder if, rather
than removing the sentence, it would be useful to add a few
qualifying words such as "resources permitting", "in
coordination with the LLC about resources", or something like
that.

best,
    john



--On Tuesday, August 24, 2021 11:25 -0400 "Joel M. Halpern"
<jmh@joelhalpern.com> wrote:

I think that the bracketed sentence should e deleted.

It seems to require that once the RSWG / RSAB have approved a
policy, the RPC must implement it.  Even if it costs money and
the LLC has not yet allocated the funds.  That would seem to
put them in a very difficult position.

Yours,
Joel

On 8/24/2021 8:29 AM, Eliot Lear wrote:
Ok.

<no hats>

I have, perhaps poorly, attempted to piece together what I
think is  roughly what we're all talking about.  I may have
entirely gotten this  wrong, and so please nitpick.  There
is one sentence in brackets that I  think is redundant.  I
have not really touched the relationship text.

Eliot

# Roles and Processes


## RFC Production Center (RPC)


Publication of RFCs shall continue to be handled by the RFC
Production  Center (RPC) function in accordance with
high-level policies that have  been specified through the
RSWG/RSAB process.  [[The RPC shall implement  the policies
specified by the RSWG/RSAB process reflecting the  priorities
of the community.]] They shall report regularly to and
consult with the RSAB, RSWG, and broader community regarding
status of  work undertaken and plans for work to be done,
including timeline for  implementation as well as any key
risks they identify.  In doing so, the  RPC will observe the
principle of transparency. The RPC shall consult  with the
RSAB for advice on how to resolve any conflicts that arise
from  community input.


All matters of budget, timetable and impact on its
performance targets,  are between the RPC and IETF LLC.


### Relationship between the RPC and the IETF LLC


This document does not specify the exact relationship between
the IETF  LLC and the RPC function; for example, the RPC
function could be  provided by a separate corporate entity
under contract to the IETF LLC,  it could be performed by
employees of the IETF LLC, or the IETF LLC  could work with
independent contractors for some or all aspects of the  RPC
function. The exact relationship is a matter for the IETF LLC
and  the IETF Executive Director to determine.


The IETF LLC has authority over negotiating performance
targets for the  RPC and also has responsibility for ensuring
that those targets are  adhered to.


If individuals or groups within the community have concerns
about the  performance of the RPC, they can request that the
IETF LLC look into the  matter. Even if the IETF LLC opts to
delegate this activity, concerns  should be raised with the
IETF LLC. The IETF LLC is ultimately  responsible to the
community via the mechanisms outlined in its charter.

--------









--------------D341C654A7FA89F970919D9E-- From nobody Tue Aug 24 11:14:05 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59FA33A0A0C for ; Tue, 24 Aug 2021 11:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 eBys4iUayC4e for ; Tue, 24 Aug 2021 11:13:56 -0700 (PDT) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 502393A0A1E for ; Tue, 24 Aug 2021 11:13:56 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id q3so10089786iot.3 for ; Tue, 24 Aug 2021 11:13:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pa2GXYvARW4VPLkKJfBo9z2lIVKd1giXn+0X3VibwQQ=; b=WRYjCIYx5v6Xics7r3aR4R3hbmE5gNwrIWhuNOWCkVY3yWFebtf0EmC37LLbhG9uEz eo9hxrEdyN3smnlUxza97fJ1q8Ad9o4JbJf7VN6PXO81pyu0YIuO1rRUPnE1ScATJVPg Wkti0Jf1vGzOseMrcOpsSwOlsyMEYDgaARivjjhXZiepLUUhmCLNIwzYRgUhHKgyyo4K QHx6CqHnDimQrjNF7DsGHN7chrVzpnXoA91aMwHyP09KQ1lcmkCB85r9TVv0bCvs0J8D Q43IdU+zVZPpLR3wQPkPH+TdmT7hTKvWSue8SBSYKMBHsp62HIyO1kRlLaabiNOsiM6Q sY9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pa2GXYvARW4VPLkKJfBo9z2lIVKd1giXn+0X3VibwQQ=; b=mziEommr+a9A2MF/EjPekXByAP80Khp6RbzXxdqhu/j5hljjWwsQxFQN3N2/vjVh3e Lo4nB+qpIURRFpLIBOL6cLXdQ9g9MLWVdBjrj5Dhqe3sY7VEWhyxjk3zzcZfh74DRU9L NUTAHJmxaQuOgLrnuXD3dDyUy7JGj5nOfTPzLrMRxVuDCVvJDOGDPXToWVtyt/I/dEal JW2To0+PU5l5IYVhZbJ71V2MmWjskTbTys1hkReNMYVmRitnCUGNOOL1EKXKrUYr/W8w iWEl342466T6nLjxDzPoBDDVX08q35GrPcEoB8vyqVb5ZVlJXUNaGIzDi1dwcbnNV3Sq HoMg== X-Gm-Message-State: AOAM533uT9wXm2htyfhfBvDVeZb+XJuRDQ/xXEAeVYi7pX3Qgh0RREDg Uf5czUSkltGWezQAlDvakyaUkB7Q0raY74caEZ0OMQ== X-Google-Smtp-Source: ABdhPJzu87JW0K/TqUgbIYVFe2HweDH2Nm7e0T5VauRa6pozFy0gRZ46C3mzfUg+h42wSl0rDpIAkJbxD0yh7xgCIPg= X-Received: by 2002:a02:cd09:: with SMTP id g9mr35030134jaq.87.1629828834334; Tue, 24 Aug 2021 11:13:54 -0700 (PDT) MIME-Version: 1.0 References: <2B46402F-5268-46B7-890F-7C5CA159EF13@ietf.org> <25FCCF71-ED00-48CA-8A15-4BB63B632F73@kuehlewind.net> <9F88E9DAC50B257953403E71@PSB> <6c544af8-b60c-1f4a-8730-3c923196eab6@joelhalpern.com> In-Reply-To: From: Eric Rescorla Date: Tue, 24 Aug 2021 11:13:18 -0700 Message-ID: To: Michael StJohns Cc: rfced-future@iab.org Content-Type: multipart/alternative; boundary="000000000000b72c8905ca521852" Archived-At: Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2021 18:14:03 -0000 --000000000000b72c8905ca521852 Content-Type: text/plain; charset="UTF-8" On Tue, Aug 24, 2021 at 10:33 AM Michael StJohns wrote: > Hi - > > Unfortunately I can't live with the paragraph in general, even with the > various changes. Basically, this section still reads as if there is a > oversight, monitoring, or directive relationship between the > RSWG/RSAB/community and the RPC. It also does a poor job of describing the > relationship between the RPC and the RSAB and RSCE for the advisory > purposes. > > So instead: > > ## RFC Production Center (RPC) > > Publication of RFCs shall continue to be handled by the RFC Production > Center (RPC) function in accordance with policies described in the > Editorial series of RFCs, and consistent with the engagement agreement(s) > between the RPC and the LLC. > > - The LLC is requested to negotiate a deliverable with the RPC that > results in regular updates to the community regarding status of work > undertaken, planned work, implementation timelines, and any identified > risks to those timelines. > > > - The LLC is requested to negotiate a task with the RPC that permits > and requires the RPC to collaborate in at least an advisory capacity in the > content creation of the Editorial series RFCs as they affect the RPC and > that collaboration is expected to be the main path for community input into > the RPC processes. > > > The RPC shall consult with the RSAB generally and the RSCE specifically > for advice on how to resolve any conflicts that arise between the RSWG > proposed documents, the Editorial series, the RPC's existing engagement > agreement's scope, and any technical or cost limitations for implementing > the Editorial series policies, and if necessary, shall refer any issues > unresolved after such consultation to the LLC or the IED for final > resolution. > > ## Relationship between the RPC and the RSAB or RSWG > > Neither the RSAB nor the RSWG has any oversight, monitoring, or directive > relationship with respect to the RPC. The RSAB and RSCE have an advisory > relationship with the RPC as described above. > This seems incorrect to me just as a matter of fact. When the RSWG and RSAB publish an RFC describing how the RPC ought to behave, then this is in fact directive. -Ekr > > -30- > > Mike > > > On 8/24/2021 11:49 AM, Joel M. Halpern wrote: > > I could live with "in coordination with the LLC about resources". > > Part of my thought on removing it is that we already have text that says > that the RSWG / RSAB sets strategic policy. Not sure what this adds. > > Yours, > Joel > > On 8/24/2021 11:33 AM, John C Klensin wrote: > > Joel, > > While the phrasing may be wrong for the reason you identify, the > sentence is probably a useful statement of intent. > > This is a question because I'm not sure, but I wonder if, rather > than removing the sentence, it would be useful to add a few > qualifying words such as "resources permitting", "in > coordination with the LLC about resources", or something like > that. > > best, > john > > > > --On Tuesday, August 24, 2021 11:25 -0400 "Joel M. Halpern" > wrote: > > I think that the bracketed sentence should e deleted. > > It seems to require that once the RSWG / RSAB have approved a > policy, the RPC must implement it. Even if it costs money and > the LLC has not yet allocated the funds. That would seem to > put them in a very difficult position. > > Yours, > Joel > > On 8/24/2021 8:29 AM, Eliot Lear wrote: > > Ok. > > > > I have, perhaps poorly, attempted to piece together what I > think is roughly what we're all talking about. I may have > entirely gotten this wrong, and so please nitpick. There > is one sentence in brackets that I think is redundant. I > have not really touched the relationship text. > > Eliot > > # Roles and Processes > > > ## RFC Production Center (RPC) > > > Publication of RFCs shall continue to be handled by the RFC > Production Center (RPC) function in accordance with > high-level policies that have been specified through the > RSWG/RSAB process. [[The RPC shall implement the policies > specified by the RSWG/RSAB process reflecting the priorities > of the community.]] They shall report regularly to and > consult with the RSAB, RSWG, and broader community regarding > status of work undertaken and plans for work to be done, > including timeline for implementation as well as any key > risks they identify. In doing so, the RPC will observe the > principle of transparency. The RPC shall consult with the > RSAB for advice on how to resolve any conflicts that arise > from community input. > > > All matters of budget, timetable and impact on its > performance targets, are between the RPC and IETF LLC. > > > ### Relationship between the RPC and the IETF LLC > > > This document does not specify the exact relationship between > the IETF LLC and the RPC function; for example, the RPC > function could be provided by a separate corporate entity > under contract to the IETF LLC, it could be performed by > employees of the IETF LLC, or the IETF LLC could work with > independent contractors for some or all aspects of the RPC > function. The exact relationship is a matter for the IETF LLC > and the IETF Executive Director to determine. > > > The IETF LLC has authority over negotiating performance > targets for the RPC and also has responsibility for ensuring > that those targets are adhered to. > > > If individuals or groups within the community have concerns > about the performance of the RPC, they can request that the > IETF LLC look into the matter. Even if the IETF LLC opts to > delegate this activity, concerns should be raised with the > IETF LLC. The IETF LLC is ultimately responsible to the > community via the mechanisms outlined in its charter. > > -------- > > > > > > > > > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > --000000000000b72c8905ca521852 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Aug 24, 2021 at 10:33 AM Mich= ael StJohns <msj@nthpermutatio= n.com> wrote:
=20 =20 =20
Hi -

Unfortunately I can't live with the paragraph in general, even with the various changes.=C2=A0=C2=A0 Basi= cally, this section still reads as if there is a oversight, monitoring, or directive relationship between the RSWG/RSAB/community and the RPC.=C2=A0 It also does a poor job of describing the relationship between the RPC and the RSAB and RSCE for the advisory purposes.

So instead:

## RFC Production Center (RPC)

Publication of RFCs shall continue to be handled by the RFC Production=C2=A0 Center (RPC) function in accordance with policies described in the Editorial series of RFCs, and consistent with the engagement agreement(s) between the RPC and the LLC.=C2=A0 <= br>
  • The LLC is requested to negotiate a deliverable with the RPC that results in regular updates to the community regarding status of work undertaken, planned work,=C2=A0 implementation timelines, and any identified risks to those timelines.
  • The LLC is requested to negotiate a task with the RPC that permits and requires the RPC to collaborate in at least an advisory capacity in the content creation of the Editorial series RFCs as they affect the RPC and that collaboration is expected to be the main path for community input into the RPC processes.

The RPC shall consult=C2=A0 with the RSAB generally and the RSCE specifically for advice on how to resolve any conflicts that arise between the RSWG proposed documents, the Editorial series,=C2=A0 the RPC's existing engagem= ent agreement's scope, and any technical or cost limitations for implementing the Editorial series policies, and if necessary,=C2=A0 shall refer any issues unresolved after such consultation to the LLC or the IED for final resolution.

## Relationship between the RPC and the RSAB or RSWG

Neither the RSAB nor the RSWG has any oversight, monitoring, or directive relationship with respect to the RPC.=C2=A0 The RSAB and RSCE have an advisory relationship with t= he RPC as described above.

This seems incorrect to me just as a matter of fact. When the RSWG and R= SAB publish an RFC describing how the RPC ought to behave, then this is in = fact directive.

-Ekr


=


-30-

Mike


On 8/24/2021 11:49 AM, Joel M. Halpern wrote:
I could live with "in coordination with the LLC about resources&qu= ot;.

Part of my thought on removing it is that we already have text that says that the RSWG / RSAB sets strategic policy.=C2=A0 Not sure what this adds.

Yours,
Joel

On 8/24/2021 11:33 AM, John C Klensin wrote:
Joel,

While the phrasing may be wrong for the reason you identify, the
sentence is probably a useful statement of intent.

This is a question because I'm not sure, but I wonder if, rathe= r
than removing the sentence, it would be useful to add a few
qualifying words such as "resources permitting", "in
coordination with the LLC about resources", or something like
that.

best,
=C2=A0=C2=A0=C2=A0 john



--On Tuesday, August 24, 2021 11:25 -0400 "Joel M. Halpern&quo= t;
<jmh@jo= elhalpern.com> wrote:

I think that the bracketed sentence should e deleted.

It seems to require that once the RSWG / RSAB have approved a
policy, the RPC must implement it.=C2=A0 Even if it costs money a= nd
the LLC has not yet allocated the funds.=C2=A0 That would seem to
put them in a very difficult position.

Yours,
Joel

On 8/24/2021 8:29 AM, Eliot Lear wrote:
Ok.

<no hats>

I have, perhaps poorly, attempted to piece together what I
think is=C2=A0 roughly what we're all talking about.=C2=A0 = I may have
entirely gotten this=C2=A0 wrong, and so please nitpick.=C2=A0 = There
is one sentence in brackets that I=C2=A0 think is redundant.=C2= =A0 I
have not really touched the relationship text.

Eliot

# Roles and Processes


## RFC Production Center (RPC)


Publication of RFCs shall continue to be handled by the RFC
Production=C2=A0 Center (RPC) function in accordance with
high-level policies that have=C2=A0 been specified through the
RSWG/RSAB process.=C2=A0 [[The RPC shall implement=C2=A0 the po= licies
specified by the RSWG/RSAB process reflecting the=C2=A0 priorities
of the community.]] They shall report regularly to and
consult with the RSAB, RSWG, and broader community regarding
status of=C2=A0 work undertaken and plans for work to be done,
including timeline for=C2=A0 implementation as well as any key
risks they identify.=C2=A0 In doing so, the=C2=A0 RPC will obse= rve the
principle of transparency. The RPC shall consult=C2=A0 with the
RSAB for advice on how to resolve any conflicts that arise
from=C2=A0 community input.


All matters of budget, timetable and impact on its
performance targets,=C2=A0 are between the RPC and IETF LLC.


### Relationship between the RPC and the IETF LLC


This document does not specify the exact relationship between
the IETF=C2=A0 LLC and the RPC function; for example, the RPC
function could be=C2=A0 provided by a separate corporate entity
under contract to the IETF LLC,=C2=A0 it could be performed by
employees of the IETF LLC, or the IETF LLC=C2=A0 could work wit= h
independent contractors for some or all aspects of the=C2=A0 RP= C
function. The exact relationship is a matter for the IETF LLC
and=C2=A0 the IETF Executive Director to determine.


The IETF LLC has authority over negotiating performance
targets for the=C2=A0 RPC and also has responsibility for ensuring
that those targets are=C2=A0 adhered to.


If individuals or groups within the community have concerns
about the=C2=A0 performance of the RPC, they can request that t= he
IETF LLC look into the=C2=A0 matter. Even if the IETF LLC opts = to
delegate this activity, concerns=C2=A0 should be raised with th= e
IETF LLC. The IETF LLC is ultimately=C2=A0 responsible to the
community via the mechanisms outlined in its charter.

--------









--
Rfced-future mailing list
Rfced-future@iab.= org
https://www.iab.org/mailman/listinfo/rfced-future
--000000000000b72c8905ca521852-- From nobody Tue Aug 24 11:34:38 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6AC3A0B18 for ; Tue, 24 Aug 2021 11:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.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 x_UiRTJT6zc6 for ; Tue, 24 Aug 2021 11:34:33 -0700 (PDT) Received: from mail-qv1-xf34.google.com (mail-qv1-xf34.google.com [IPv6:2607:f8b0:4864:20::f34]) (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 73F703A0B06 for ; Tue, 24 Aug 2021 11:34:33 -0700 (PDT) Received: by mail-qv1-xf34.google.com with SMTP id e18so7316691qvo.1 for ; Tue, 24 Aug 2021 11:34:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=P8GANuXJfwHgm8/T1X3G7P7J9jaEo7a8j2GhANWkdf8=; b=B/swOm7XmAX5vSgtTqUQVbN521OgazyGkDUvCzpslCjSAljMcteG8IpqX7oJeVnMsx l3pANj1PpDIsy+AezN5ke2WeSEkH2/PH/ZmArS0gDfh5bi/MZtPZratABCaXPaqpFReQ FZNSnj1WFnvFPeBeS8KcsNlBdB8sn+qUZ9PsaXn1tQQWhI2wPNp9ZFt/7FgmONrgCAtC DypeyK28pNNl6fQTmf86JvPJ0X7NsU2815mUgju07y1bQXMihZh/WqrlcNOPfPuaRtqc oGnXgH7J7FlTcXrQFagvtiqtEXudNLiJ134LSRw8hJ1v5It4O+tymdZvKxiIGO5fwZ6O 4flw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=P8GANuXJfwHgm8/T1X3G7P7J9jaEo7a8j2GhANWkdf8=; b=a58RuhLsWhRODV+drmyrNliONyh1XfaixSOa165tGH0RpfukrnlGEv8yW1rN+/G62P ZnzC/1dOTn52LxQ28713XlkCvqf3rjvf+DJzBcWtUYOH0pk43lLsPmcUCXUZcwPLjiNM rb6RsLVtblRKr28QAqAGJL2ds8XcW+H1XA3Lex9SOEuusTk9NHaUirGAkzea8LfIow39 u1SpApWu/8q5skVpNp/qmUJesSxM+PI9hI2xl3nruiV7RV2KOYe9Ul1f+zhp1+I7ecZU Pm72NGzV7MTe8GWR2/VGIZXWcLs2hRnYD+Q1qqtMx14/AZv1bbtEz5BM1wqRfHACCMFo aliQ== X-Gm-Message-State: AOAM531G6HYI7zni6dnakWezRIzBRgOm0YsTO1FqghHr6/B+qSPl+JJh chxtZKUPuxlJtFKjh9oUZf3vjEo/juf3iH+u X-Google-Smtp-Source: ABdhPJxlMIk/QB3pBx65whqyW1GzwI3lqwDJ2J919BBQcyfU7jzX1UTObBlaVaboF49l1y9E806N6w== X-Received: by 2002:ad4:5be4:: with SMTP id k4mr17530891qvc.46.1629830070523; Tue, 24 Aug 2021 11:34:30 -0700 (PDT) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id bl26sm10576458qkb.34.2021.08.24.11.34.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 24 Aug 2021 11:34:29 -0700 (PDT) To: Eric Rescorla Cc: rfced-future@iab.org References: <2B46402F-5268-46B7-890F-7C5CA159EF13@ietf.org> <25FCCF71-ED00-48CA-8A15-4BB63B632F73@kuehlewind.net> <9F88E9DAC50B257953403E71@PSB> <6c544af8-b60c-1f4a-8730-3c923196eab6@joelhalpern.com> From: Michael StJohns Message-ID: <7ce1368a-7bd2-73e3-5410-0e951f40fa00@nthpermutation.com> Date: Tue, 24 Aug 2021 14:34:27 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8130472504BB311E7D4BA34C" Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2021 18:34:37 -0000 This is a multi-part message in MIME format. --------------8130472504BB311E7D4BA34C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 8/24/2021 2:13 PM, Eric Rescorla wrote: > > ## Relationship between the RPC and the RSAB or RSWG > > Neither the RSAB nor the RSWG has any oversight, monitoring, or > directive relationship with respect to the RPC.  The RSAB and RSCE > have an advisory relationship with the RPC as described above. > > > This seems incorrect to me just as a matter of fact. When the RSWG and > RSAB publish an RFC describing how the RPC ought to behave, then this > is in fact directive. > > -Ekr > I believe you're missing the difference between the noun "directive" (e.g. the RFC is a policy directive which describes the operation of the RPC) which has the meaning: "an official or authoritative instruction". And the adjective "directive" (e.g. the RSWG has no directive relationship with the RPC) which has the meaning: "involving the management or guidance of operations" - To put it another way, your state executive or legislature may issue a directive (or a law) with respect to the wearing of masks, but the state does not have a directive relationship with you unless you actually work for the state.   I am personally subject to 1000s of directives of various forms, but since I work for myself, I am not the subject of a directive relationship in the meaning above. I believe we've agreed that the RSAB and RSWG don't get to directly tell the RPC or the RSCE what to do - e.g. they may NOT direct either of those entities to perform specific work - all they can do is publish the RFCs and then ask the LLC to craft a contract or engagement agreement reflecting those RFCs. Later, Mike --------------8130472504BB311E7D4BA34C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 8/24/2021 2:13 PM, Eric Rescorla wrote:
## Relationship between the RPC and the RSAB or RSWG

Neither the RSAB nor the RSWG has any oversight, monitoring, or directive relationship with respect to the RPC.  The RSAB and RSCE have an advisory relationship with the RPC as described above.

This seems incorrect to me just as a matter of fact. When the RSWG and RSAB publish an RFC describing how the RPC ought to behave, then this is in fact directive.

-Ekr

I believe you're missing the difference between the noun "directive" (e.g. the RFC is a policy directive which describes the operation of the RPC) which has the meaning:

"an official or authoritative instruction".

And the adjective "directive" (e.g. the RSWG has no directive relationship with the RPC) which has the meaning:

"involving the management or guidance of operations" -

To put it another way, your state executive or legislature may issue a directive (or a law) with respect to the wearing of masks, but the state does not have a directive relationship with you unless you actually work for the state.   I am personally subject to 1000s of directives of various forms, but since I work for myself, I am not the subject of a directive relationship in the meaning above.

I believe we've agreed that the RSAB and RSWG don't get to directly tell the RPC or the RSCE what to do - e.g. they may NOT direct either of those entities to perform specific work - all they can do is publish the RFCs and then ask the LLC to craft a contract or engagement agreement reflecting those RFCs.

Later, Mike



--------------8130472504BB311E7D4BA34C-- From nobody Tue Aug 24 11:39:23 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E71603A0B67 for ; Tue, 24 Aug 2021 11:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 cX-cz4aHThH9 for ; Tue, 24 Aug 2021 11:39:16 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 A77CC3A0B68 for ; Tue, 24 Aug 2021 11:39:16 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id j18so27523102ioj.8 for ; Tue, 24 Aug 2021 11:39:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aq9KfPnR3mvigSjMGPXyRvrSFhMgtRHIQFummQHkjAQ=; b=vodgczNU4asjv8zX5xAEjpiKxmVVHf+udhJu8mt94HN8rIKPInsf5D24Az1n9adkDk QepyFKZAxA2kTxIkYQL84OIId/Suwg5eg2e+zwaUXNbJXvrqXfxilk9nEVEv+gBFktKb 8H7DAs7fMbxd02jVf+gQMJqwHj4ymyBNEqOb4uwcv4F50dq1tn6NUTg1Y1PTP82isvTN z1UzLu8oiX4qB6W0BdoeVALx1Na6WN2dGB+aU+OpdOzmdW6f9byzBYRgmiaQb5R40Lk0 BXeSBw3dk5mCsv63uBCDokKRylxHQjFtr6nxMxtJrV2HMSQ85lkAN2Ogh7bjxZRfEQfc 19sQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aq9KfPnR3mvigSjMGPXyRvrSFhMgtRHIQFummQHkjAQ=; b=eQWe4v3imhmpb0b9J2rfT0cjUCJKLVVeFvb5t6lTEBI6tp7DpTJmG9YhJ+PFRcpO6Z hTGkMoUJMJ/ivZKZHJCjl1OpKGcabu3HzOxwNfqZ0POffLqIqMQ3aSkbWEHGaz1fptmi twXh+xTILQhwRCeTPMLqRkgC1hqsFG8Id0DZK6EicBlBBkQ6QFtDmLjSWZNM0Gt9DR6z D5to5yLAxFYd6h1tCJRdw/GIZvtUHGP1q92m1oKGgViV6/Jhk6wpF1o8idmHBGTLZbPh GIFqsGqxxwn92NlEUYLfkVtzYhh1sPNNs/fYK44+HcXqWUUF5Icn+zQC9AZZdW7b2j/e 9Ftg== X-Gm-Message-State: AOAM533qkhmQI/t4X3PMSL5lDPGESFm+SLF4T1kxLF+bn8sltjSQJo/f P9Eab4wZVg0mYViiKN5q5a9mAFVbcmavhZTou19TMA== X-Google-Smtp-Source: ABdhPJzRAEbJ8rpQWVUUEAyNIVg2xxXOF9ifzDFKZtR6wkHvqLqIa4511yeCXEMc58W4aYVI9ZhkEV0daKdcThH596k= X-Received: by 2002:a05:6638:974:: with SMTP id o20mr35390635jaj.10.1629830354483; Tue, 24 Aug 2021 11:39:14 -0700 (PDT) MIME-Version: 1.0 References: <2B46402F-5268-46B7-890F-7C5CA159EF13@ietf.org> <25FCCF71-ED00-48CA-8A15-4BB63B632F73@kuehlewind.net> <9F88E9DAC50B257953403E71@PSB> <6c544af8-b60c-1f4a-8730-3c923196eab6@joelhalpern.com> <7ce1368a-7bd2-73e3-5410-0e951f40fa00@nthpermutation.com> In-Reply-To: <7ce1368a-7bd2-73e3-5410-0e951f40fa00@nthpermutation.com> From: Eric Rescorla Date: Tue, 24 Aug 2021 11:38:38 -0700 Message-ID: To: Michael StJohns Cc: rfced-future@iab.org Content-Type: multipart/alternative; boundary="00000000000052d04a05ca527345" Archived-At: Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2021 18:39:22 -0000 --00000000000052d04a05ca527345 Content-Type: text/plain; charset="UTF-8" On Tue, Aug 24, 2021 at 11:34 AM Michael StJohns wrote: > On 8/24/2021 2:13 PM, Eric Rescorla wrote: > > ## Relationship between the RPC and the RSAB or RSWG >> >> Neither the RSAB nor the RSWG has any oversight, monitoring, or directive >> relationship with respect to the RPC. The RSAB and RSCE have an advisory >> relationship with the RPC as described above. >> > > This seems incorrect to me just as a matter of fact. When the RSWG and > RSAB publish an RFC describing how the RPC ought to behave, then this is in > fact directive. > > -Ekr > > I believe you're missing the difference between the noun "directive" (e.g. > the RFC is a policy directive which describes the operation of the RPC) > which has the meaning: > > "an official or authoritative instruction". > > And the adjective "directive" (e.g. the RSWG has no directive relationship > with the RPC) which has the meaning: > > "involving the management or guidance of operations" - > > To put it another way, your state executive or legislature may issue a > directive (or a law) with respect to the wearing of masks, but the state > does not have a directive relationship with you unless you actually work > for the state. I am personally subject to 1000s of directives of various > forms, but since I work for myself, I am not the subject of a directive > relationship in the meaning above. > It seems to me that if we are having to refer to this kind of dictionary-based interpretation, then a rewrite is in order. I believe we've agreed that the RSAB and RSWG don't get to directly tell > the RPC or the RSCE what to do - e.g. they may NOT direct either of those > entities to perform specific work - all they can do is publish the RFCs and > then ask the LLC to craft a contract or engagement agreement reflecting > those RFCs. > I think you're drawing too sharp a distinction. Suppose that the RSAWG were to publish an RFC saying that heretoforth authors should be listed in alphabetical order. I would expect the RPC to comply with that without some new contractual term from the LLC. Do you disagree? -Ekr Later, Mike > > > > --00000000000052d04a05ca527345 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Aug 24, 2021 at 11:34 AM Mich= ael StJohns <msj@nthpermutatio= n.com> wrote:
=20 =20 =20
On 8/24/2021 2:13 PM, Eric Rescorla wrote:
## Relationship between the RPC and the RSAB or RSWG

Neither the RSAB nor the RSWG has any oversight, monitoring, or directive relationship with respect to the RPC.=C2=A0 The RSAB and RSCE have an advisory relationship with the RPC as described above.

This seems incorrect to me just as a matter of fact. When the RSWG and RSAB publish an RFC describing how the RPC ought to behave, then this is in fact directive.

-Ekr

I believe you're missing the difference between the noun "directive" (e.g. the RFC is a policy directive which descr= ibes the operation of the RPC) which has the meaning:

"an official or authoritative instruction".

And the adjective "directive" (e.g. the RSWG has no direct= ive relationship with the RPC) which has the meaning:

"involving the management or guidance of operations" -

To put it another way, your state executive or legislature may issue a directive (or a law) with respect to the wearing of masks, but the state does not have a directive relationship with you unless you actually work for the state.=C2=A0=C2=A0 I am personally s= ubject to 1000s of directives of various forms, but since I work for myself, I am not the subject of a directive relationship in the meaning above.


It seems to = me that if we are having to refer to this kind of dictionary-based interpre= tation, then a rewrite is in order.

I believe we've agreed that the RSAB and RSWG don't get to directly tell the RPC or the RSCE what to do - e.g. they may NOT direct either of those entities to perform specific work - all they can do is publish the RFCs and then ask the LLC to craft a contract or engagement agreement reflecting those RFCs.

I think you're drawing too sharp a distinction.

Suppose that the RSAWG were to publish an RFC saying that h= eretoforth authors should be listed in alphabetical order. I would expect t= he RPC to comply with that without some new contractual term from the LLC. = Do you disagree?

-Ekr

Later, Mike



--00000000000052d04a05ca527345-- From nobody Tue Aug 24 12:33:15 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D40D73A0E63 for ; Tue, 24 Aug 2021 12:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.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 0PyXsF7fuS0k for ; Tue, 24 Aug 2021 12:33:05 -0700 (PDT) Received: from mail-qv1-xf2a.google.com (mail-qv1-xf2a.google.com [IPv6:2607:f8b0:4864:20::f2a]) (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 6F6393A0E53 for ; Tue, 24 Aug 2021 12:33:05 -0700 (PDT) Received: by mail-qv1-xf2a.google.com with SMTP id eh1so12351179qvb.11 for ; Tue, 24 Aug 2021 12:33:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=7TsbGlgLZncQho941jya4K/uRs7PSA37itlTX+ANpo0=; b=c+GLnbqZy7ZCrpSJjHRpgp0EPOOGjuxZtNrxiK7iwIVKbWocoLHikBnObltkIFz4EO 7TRq2Hg7OzH+jojQTXaXpteXh+Yx5YUiWcWh65rpxfKEUtGQXKl31Z9+BT/AF0MdwnoD bWxWIxN5mfX6iU1FDYMw+yThoqoN2CDxyPuYEQBRMHZJu86wT7pz6s/oNijeL/Pcl2ND SHEINnY7Bvki+k7/B3mEAhNic1Hc6ZQC4uuTsnT9YiIjmihbnK5LsdvBC6ul2ICmXRaA XTTQldayDq81yelpzj/miWQ+4nvcx/gxmcAuOJcfsy7GLal/iSJz177X10RqyM0rTj2J 6lgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=7TsbGlgLZncQho941jya4K/uRs7PSA37itlTX+ANpo0=; b=nuuoTEdLgbVBNBh0MMhjjvpRMoFBMN9f1vUZOVXmDZzlq+tsqwoQsn9ZqoFn4yWP5I Ltz7g74PDBZsfXvzTjP+CAhuIoO3ViYsWBkgHbsKA4PS+D19FLf9/+2/OJSYQitimyC7 PZG6t4cTKuPQNtvMUzKrCZkpeM4YkVlYRAlIIe9sIXPdAqb8UrPGL5wXiN2kbKDKHb9F Zzm6f/Hhpqc4jxRfTEbof0HSvwRwyg/PwcUDBI2gC0P6o3ym/Xy3GfIp7Xl4C+2pwMe6 X6guf+1uKweqFMua3TTRIrmr3FXOSDDsoGC+WZiFEx1nXOv4RVrV2WYcHeHXwrSp+JRa bZgQ== X-Gm-Message-State: AOAM533necYc7JfO1KqzC7Jnf91ROyb+nDmsKES6nMaiqiji5FgMErir P5yLXwgU40DTr3cZthEj+QUidlv+df2Z6RmA X-Google-Smtp-Source: ABdhPJyD4GkopCRTEoEdTrpeEWk9U/UNUYM2btTRRxismTDp5j7JDddM9Q7eM3Yf9ZYHHvztU0e5wQ== X-Received: by 2002:a05:6214:10e6:: with SMTP id q6mr40984190qvt.11.1629833582081; Tue, 24 Aug 2021 12:33:02 -0700 (PDT) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id m8sm11143841qkk.130.2021.08.24.12.33.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 24 Aug 2021 12:33:01 -0700 (PDT) To: Eric Rescorla Cc: rfced-future@iab.org References: <2B46402F-5268-46B7-890F-7C5CA159EF13@ietf.org> <25FCCF71-ED00-48CA-8A15-4BB63B632F73@kuehlewind.net> <9F88E9DAC50B257953403E71@PSB> <6c544af8-b60c-1f4a-8730-3c923196eab6@joelhalpern.com> <7ce1368a-7bd2-73e3-5410-0e951f40fa00@nthpermutation.com> From: Michael StJohns Message-ID: <761bf2d8-759e-72e1-4c92-7419cea693bb@nthpermutation.com> Date: Tue, 24 Aug 2021 15:32:59 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------BD211A0EB20AA16C5896B73B" Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2021 19:33:12 -0000 This is a multi-part message in MIME format. --------------BD211A0EB20AA16C5896B73B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 8/24/2021 2:38 PM, Eric Rescorla wrote: > > > On Tue, Aug 24, 2021 at 11:34 AM Michael StJohns > > wrote: > > On 8/24/2021 2:13 PM, Eric Rescorla wrote: >> >> ## Relationship between the RPC and the RSAB or RSWG >> >> Neither the RSAB nor the RSWG has any oversight, monitoring, >> or directive relationship with respect to the RPC.  The RSAB >> and RSCE have an advisory relationship with the RPC as >> described above. >> >> >> This seems incorrect to me just as a matter of fact. When the >> RSWG and RSAB publish an RFC describing how the RPC ought to >> behave, then this is in fact directive. >> >> -Ekr >> > I believe you're missing the difference between the noun > "directive" (e.g. the RFC is a policy directive which describes > the operation of the RPC) which has the meaning: > > "an official or authoritative instruction". > > And the adjective "directive" (e.g. the RSWG has no directive > relationship with the RPC) which has the meaning: > > "involving the management or guidance of operations" - > > To put it another way, your state executive or legislature may > issue a directive (or a law) with respect to the wearing of masks, > but the state does not have a directive relationship with you > unless you actually work for the state.   I am personally subject > to 1000s of directives of various forms, but since I work for > myself, I am not the subject of a directive relationship in the > meaning above. > > > It seems to me that if we are having to refer to this kind of > dictionary-based interpretation, then a rewrite is in order. I referred to a dictionary only for your convenience.  But "directive" in conjunction with "relationship"  is the appropriate term here.  I guess you could use governing, or  control as replacements with some work, but those aren't as clear. > > I believe we've agreed that the RSAB and RSWG don't get to > directly tell the RPC or the RSCE what to do - e.g. they may NOT > direct either of those entities to perform specific work - all > they can do is publish the RFCs and then ask the LLC to craft a > contract or engagement agreement reflecting those RFCs. > > I think you're drawing too sharp a distinction. > > Suppose that the RSAWG were to publish an RFC saying that heretoforth > authors should be listed in alphabetical order. I would expect the RPC > to comply with that without some new contractual term from the LLC. Do > you disagree? The other section has this: > Publication of RFCs shall continue to be handled by the RFC > Production  Center (RPC) function in accordance with policies > described in the Editorial series of RFCs, and consistent with the > engagement agreement(s) between the RPC and the LLC. Assuming that the change in the RFC's does not require a change in the costs, or impose more work and where the change is consistent with the agreement between the RPC and the LLC, then there is no requirement to change the contract.   And actually, if this requires a tooling change (not saying it will, but who knows), it might require LLC approval to spend the money so... it may not be a contract change, but it may require LLC (or IED) buy in.  That seems something that a) the RPC would hopefully bring up during the RFC creation, b) the LLC would analyze before RFC approval, and c) the LLC would be proactive in working with the RPC to implement the new RFC policies.   Or d) the LLC would say - we're not payinf for this. The counter example is that you write a new RFC that says that the RPC shall maintain a GIT instance tracking all of the changes made between submission and publication of an RFC candidate and that wasn't part of the contract, then yes it requires a change. So the general answer to the more general question: "Will Editorial stream RFCs published by RSAB/RSWG require contract changes to the RPC?" is "It depends" which I think you probably already knew. Later, Mike > > -Ekr > > Later, Mike > > > --------------BD211A0EB20AA16C5896B73B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 8/24/2021 2:38 PM, Eric Rescorla wrote:


On Tue, Aug 24, 2021 at 11:34 AM Michael StJohns <msj@nthpermutation.com> wrote:
On 8/24/2021 2:13 PM, Eric Rescorla wrote:
## Relationship between the RPC and the RSAB or RSWG

Neither the RSAB nor the RSWG has any oversight, monitoring, or directive relationship with respect to the RPC.  The RSAB and RSCE have an advisory relationship with the RPC as described above.

This seems incorrect to me just as a matter of fact. When the RSWG and RSAB publish an RFC describing how the RPC ought to behave, then this is in fact directive.

-Ekr

I believe you're missing the difference between the noun "directive" (e.g. the RFC is a policy directive which describes the operation of the RPC) which has the meaning:

"an official or authoritative instruction".

And the adjective "directive" (e.g. the RSWG has no directive relationship with the RPC) which has the meaning:

"involving the management or guidance of operations" -

To put it another way, your state executive or legislature may issue a directive (or a law) with respect to the wearing of masks, but the state does not have a directive relationship with you unless you actually work for the state.   I am personally subject to 1000s of directives of various forms, but since I work for myself, I am not the subject of a directive relationship in the meaning above.


It seems to me that if we are having to refer to this kind of dictionary-based interpretation, then a rewrite is in order.

I referred to a dictionary only for your convenience.  But "directive" in conjunction with "relationship"  is the appropriate term here.  I guess you could use governing, or  control as replacements with some work, but those aren't as clear.


I believe we've agreed that the RSAB and RSWG don't get to directly tell the RPC or the RSCE what to do - e.g. they may NOT direct either of those entities to perform specific work - all they can do is publish the RFCs and then ask the LLC to craft a contract or engagement agreement reflecting those RFCs.

I think you're drawing too sharp a distinction.

Suppose that the RSAWG were to publish an RFC saying that heretoforth authors should be listed in alphabetical order. I would expect the RPC to comply with that without some new contractual term from the LLC. Do you disagree?


The other section has this:


Publication of RFCs shall continue to be handled by the RFC Production  Center (RPC) function in accordance with policies described in the Editorial series of RFCs, and consistent with the engagement agreement(s) between the RPC and the LLC.

Assuming that the change in the RFC's does not require a change in the costs, or impose more work and where the change is consistent with the agreement between the RPC and the LLC, then there is no requirement to change the contract.   And actually, if this requires a tooling change (not saying it will, but who knows), it might require LLC approval to spend the money so... it may not be a contract change, but it may require LLC (or IED) buy in.  That seems something that a) the RPC would hopefully bring up during the RFC creation, b) the LLC would analyze before RFC approval, and c) the LLC would be proactive in working with the RPC to implement the new RFC policies.   Or d) the LLC would say - we're not payinf for this.

The counter example is that you write a new RFC that says that the RPC shall maintain a GIT instance tracking all of the changes made between submission and publication of an RFC candidate and that wasn't part of the contract, then yes it requires a change.

So the general answer to the more general question: "Will Editorial stream RFCs published by RSAB/RSWG require contract changes to the RPC?" is "It depends" which I think you probably already knew.

Later, Mike




-Ekr

Later, Mike




--------------BD211A0EB20AA16C5896B73B-- From nobody Tue Aug 24 14:10:45 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD243A1356 for ; Tue, 24 Aug 2021 14:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=isi.edu 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 5BLlVLNaKRQ1 for ; Tue, 24 Aug 2021 14:10:32 -0700 (PDT) Received: from mail-ua1-x931.google.com (mail-ua1-x931.google.com [IPv6:2607:f8b0:4864:20::931]) (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 C657F3A134E for ; Tue, 24 Aug 2021 14:10:32 -0700 (PDT) Received: by mail-ua1-x931.google.com with SMTP id y36so12350479uad.7 for ; Tue, 24 Aug 2021 14:10:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isi.edu; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Xz+XXOl8PZcBzJpiTszZP+9GWs24ecRFtGC1UWIWhck=; b=GdywFhnUgyIrss9seDf6H8DU7vJa0HKQiE8rlVfqrsBRzps4/ylAYTElHPYVqY47Oo 1EZY74Ximz5MjSKXLl2MOXLfdSenHoGr5gbqKgqrAIfdyUaoImxdGvs6KVTtLf7MbXnI npwGKlp6njFiV5XfOjW2C0k0v41veoO1JnI50NbO7W9jcnbKR05hQ8LK1px0TSNjtRel b+5tXu91TffTj3mEs9Dfj3FUSEuU8GBguSYgFi1GzLl4jOUKfoLfaGTNsGNkAa24/uRY pgeCcIUfJLHmFZOSr0DZiTwz88ycMM6D+jLN/doP/ttpGcrbGPpJxJ5vLMq6i7CSlyQc ycMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Xz+XXOl8PZcBzJpiTszZP+9GWs24ecRFtGC1UWIWhck=; b=db7r6tovPRE7omSw3GmI3Oh40FnO+p/Vs6pwUrmGgkzsrLqKo6oCv6JM/1PAv9d9DJ tUqn/gVlukRw6umxCelLn+HKvC/6QZ75sUVPv7HRMKwCIckAFsSMjHgK+1O67947+H8V cThH4ZbxxiaCiEwTUNUaJEHd2V6j770QeeZ7GzkNsXPP1EJzNsViQMTwucOt8wnadPYW Xc5lzTJNdXxhbNFOpgLLmEslOsuNHd0UW4ykCnEtmWB5ioFGxtXxdZmqM8tUUKZhV/fN YcUDqg+2NtwcdDShTjPU5I0I1T+K6+O5hEAoqdBLw+CeloqIOkpuW75MFcwVnTqLyRXW 0c8Q== X-Gm-Message-State: AOAM531YMmRUD9EQVJjShvs2Y4Hw+WRfaosAvr6Iu7yKiyze8CR0AbSL Ga5PlMMaHp/e9B1up+jpS+kLAZkH5y5IeAnElEQZ1Q== X-Google-Smtp-Source: ABdhPJzRsqBHkzNaVNKKKA/EjX/rEPYTSBbX9qSIjX76ecLDaQuggmTI/8z5Ng3tqXDMdXHP5HQsIJ+7vF2r/7Zd6tU= X-Received: by 2002:a67:df85:: with SMTP id x5mr30801513vsk.3.1629839430380; Tue, 24 Aug 2021 14:10:30 -0700 (PDT) MIME-Version: 1.0 References: <8f30de10-af84-adbd-783e-169b637ddd3d@lear.ch> <122e59d0-6c26-a1c6-172f-86402838ea4e@lear.ch> In-Reply-To: From: Wes Hardaker Date: Tue, 24 Aug 2021 14:09:54 -0700 Message-ID: To: John C Klensin Cc: Ole Jacobsen , Eliot Lear , rfced-future@iab.org, Ole Jacobsen , Brian Rosen Content-Type: multipart/alternative; boundary="0000000000004a11ad05ca54906c" Archived-At: Subject: Re: [Rfced-future] Slight correction: Re: Thursday interim 20:00 GMT X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2021 21:10:39 -0000 --0000000000004a11ad05ca54906c Content-Type: text/plain; charset="UTF-8" Psst webcal://datatracker.ietf.org/meeting/upcoming.ics --0000000000004a11ad05ca54906c Content-Type: text/html; charset="UTF-8" --0000000000004a11ad05ca54906c-- From nobody Tue Aug 24 15:05:28 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1393A1598; Tue, 24 Aug 2021 15:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 KcU0IB1sNZgZ; Tue, 24 Aug 2021 15:05:18 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43CA73A1597; Tue, 24 Aug 2021 15:05:18 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1mIeXi-000Fkk-LN; Tue, 24 Aug 2021 18:05:14 -0400 Date: Tue, 24 Aug 2021 18:05:08 -0400 From: John C Klensin To: Wes Hardaker cc: Ole Jacobsen , Eliot Lear , rfced-future@iab.org, Ole Jacobsen , Brian Rosen Message-ID: <1B483BC9E28260B5F2463D6B@PSB> In-Reply-To: References: <8f30de10-af84-adbd-783e-169b637ddd3d@lear.ch> <122e59d0-6c26-a1c6-172f-86402838ea4e@lear.ch> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfced-future] Slight correction: Re: Thursday interim 20:00 GMT X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2021 22:05:25 -0000 --On Tuesday, August 24, 2021 14:09 -0700 Wes Hardaker wrote: > Psst > > webcal://datatracker.ietf.org/meeting/upcoming.ics I know. I was just responding to Ole's suggestion about what I understood he saw as a change to the status quo. john From nobody Tue Aug 24 16:06:56 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11F413A180F for ; Tue, 24 Aug 2021 16:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=me.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 PhXjK7rpWZA1 for ; Tue, 24 Aug 2021 16:06:49 -0700 (PDT) Received: from mr85p00im-ztdg06011101.me.com (mr85p00im-ztdg06011101.me.com [17.58.23.185]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FB373A1813 for ; Tue, 24 Aug 2021 16:06:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=1a1hai; t=1629846408; bh=EfpHMpy0luCq9DasziJ7wNB9P9qMlXFB85qiK+WP4f4=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=n21H0U6Y1c0/4ENUE4Stst7FKX6CxWiGGH27cQj8Xq5FzNjjiTI+yG62cv6XPwzbk 4KjvH1PV9v2IE4yawCV+SqzAnouUjSXMMXbKCwaPiN/vXcfwSGRd9cgoAQExaxHqvd gP8f33jWz00xMQHfseRgR15j0cZsDJ6wLp9OxfppVhn0bK4yA0RyKoOrDhza5fGYq8 fmJGYIlZuL5toEcO2xHM7GMb81CNmwsb9Q/AWcjJfPF9iSifDutWGI+WBxxhOVEwtD NvrtSLgvsn3y/j/qQc4+P75Xzp2Dqz7yGl6YH5cJraVlGoK/3DPLzkmCPS2aO0fjcY t46Yi0el5Uc2A== Received: from smtpclient.apple (157-131-155-250.fiber.dynamic.sonic.net [157.131.155.250]) by mr85p00im-ztdg06011101.me.com (Postfix) with ESMTPSA id 7030C4A04EB; Tue, 24 Aug 2021 23:06:48 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Ole Jacobsen In-Reply-To: <1B483BC9E28260B5F2463D6B@PSB> Date: Tue, 24 Aug 2021 16:06:47 -0700 Cc: Ole Jacobsen , Wes Hardaker , Eliot Lear , rfced-future@iab.org, Brian Rosen Content-Transfer-Encoding: quoted-printable Message-Id: <47C28524-FD06-4FBD-AB32-1874F78FAC68@me.com> References: <8f30de10-af84-adbd-783e-169b637ddd3d@lear.ch> <122e59d0-6c26-a1c6-172f-86402838ea4e@lear.ch> <1B483BC9E28260B5F2463D6B@PSB> To: John C Klensin X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Proofpoint-Virus-Version: =?UTF-8?Q?vendor=3Dfsecure_engine=3D1.1.170-22c6f66c430a71ce266a39bfe25bc?= =?UTF-8?Q?2903e8d5c8f:6.0.391,18.0.790,17.0.607.475.0000000_definitions?= =?UTF-8?Q?=3D2021-08-24=5F07:2021-08-23=5F01,2021-08-24=5F07,2020-04-07?= =?UTF-8?Q?=5F01_signatures=3D0?= X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 bulkscore=0 adultscore=0 malwarescore=0 spamscore=0 mlxlogscore=992 clxscore=1011 suspectscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2108240144 Archived-At: Subject: Re: [Rfced-future] Slight correction: Re: Thursday interim 20:00 GMT X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2021 23:06:55 -0000 Hi, First of all, that looks like a VERY generic URL even if it does indeed take me to: * The agenda * The draft * The Chair's slides ... but not the WebEx information. Second, it's not clear to me how to find that initial generic-looking = URL. So, my suggestion remains: Include a calendar invite in a message that = should include (in the text) at least the time and date of the meeting and = information on how to join the meeting. As John points out, not everybody uses = calendaring programs (local or otherwise), but such as attachment would help for = those who do. As a result of what Wes just sent, I now have TWO entries for the = same event in my calendar because one of them is needed for the crucial "how to = join" info that is not included in the other one. Ole > On Aug 24, 2021, at 15:05, John C Klensin wrote: >=20 >=20 >=20 > --On Tuesday, August 24, 2021 14:09 -0700 Wes Hardaker > wrote: >=20 >> Psst >>=20 >> webcal://datatracker.ietf.org/meeting/upcoming.ics >=20 > I know. I was just responding to Ole's suggestion about what I > understood he saw as a change to the status quo. >=20 > john >=20 Ole J. Jacobsen Editor and Publisher The Internet Protocol Journal Office: +1 415-550-9433 Cell: +1 415-370-4628 Web: protocoljournal.org E-mail: olejacobsen@me.com E-mail: ole@protocoljournal.org Skype: organdemo From nobody Tue Aug 24 16:44:19 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61A123A195F for ; Tue, 24 Aug 2021 16:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=isi.edu 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 UqonUEnEpFCw for ; Tue, 24 Aug 2021 16:44:13 -0700 (PDT) Received: from mail-vk1-xa31.google.com (mail-vk1-xa31.google.com [IPv6:2607:f8b0:4864:20::a31]) (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 D0F653A195C for ; Tue, 24 Aug 2021 16:44:12 -0700 (PDT) Received: by mail-vk1-xa31.google.com with SMTP id bb10so6036966vkb.9 for ; Tue, 24 Aug 2021 16:44:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isi.edu; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tU4fkgxFkj2N3tqbIMfvMtiLO8aZOIzxjaYQ4ODP4G4=; b=QrXcgTJGK69s5IHaA47VIGkG4QpJmKslofmem6ADLysi+r7oOWDYOfN0/akm2N8yb4 0GQfoTILpF+luOOXP+uoAy2Z0tYgyYrYaBnTKgrytIQRJaV+DJtLrNwXoaSaNNHCKXYj jDnRG0IjtG3HjboSBTpYUGCJbWFR/XcsL8/7OnwJ3QaKkqTmDkGlrMqJR6d7pHCTQoI9 1s4qNDLfYFB5z9HoXQGHiACm/6FxInXyZK+9xIg08piiiXJnuV+bCo9T99xEFTMoWBKU tq05buGPCemvnNcl6Ry1vpTTY9gTWHpnmdoNGkE2+24vo01Ol9U3Bt3NGl9hWkRQlL1J CKkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tU4fkgxFkj2N3tqbIMfvMtiLO8aZOIzxjaYQ4ODP4G4=; b=ppEP8mSC43551daGj5TS30zg6bvfAko82777ZTnxWf1KeCcfr9Oe+kEPr2u071z6j0 vqLa5/hEzhl8uHL/roZN8a02P5VjbzjDJ0cawp6vs0B7FCV7mBIhO2Lms3OWXvTFFj/H 07erscUyeXkKcObZiVhBFh9DrAhYtRRPxBkuSYcobiKk47vyZKlsXQ19Z+baPmGky0JM powtu7YB8YuneV/QimiiZIAwRdttUS3Y17Osw1Ml07v0AcMXIcWsxporC3rAQ2qIhIPG 4+8iDQ3Z5i1sUtzKGqbqIWenMucmNSOclpsPV3r2L0aRP8Fokunpg35XMkgXJwF1Oid8 Hm2w== X-Gm-Message-State: AOAM533f/QCjStvMKJK03+zV1i7QTuzxxYh03jODQxXxCKX0dGHvJn8+ XsOr4tunmRUFR5q4bLgy/ILVsCWmvEWn8KgX2j5I6g== X-Google-Smtp-Source: ABdhPJxqm+4+sXDYrvamjs6yZWJKPrPk3xsmIR7QFZxJRUFXkMIo3l8ndT3g/hmzwJU4YEsWApfnAi/b3IUpQGfkuFk= X-Received: by 2002:a05:6122:809:: with SMTP id 9mr3082929vkj.4.1629848649902; Tue, 24 Aug 2021 16:44:09 -0700 (PDT) MIME-Version: 1.0 References: <8f30de10-af84-adbd-783e-169b637ddd3d@lear.ch> <122e59d0-6c26-a1c6-172f-86402838ea4e@lear.ch> <1B483BC9E28260B5F2463D6B@PSB> <47C28524-FD06-4FBD-AB32-1874F78FAC68@me.com> In-Reply-To: <47C28524-FD06-4FBD-AB32-1874F78FAC68@me.com> From: Wes Hardaker Date: Tue, 24 Aug 2021 16:43:33 -0700 Message-ID: To: Ole Jacobsen Cc: John C Klensin , Eliot Lear , rfced-future@iab.org, Brian Rosen Content-Type: multipart/alternative; boundary="000000000000d0c20b05ca56b586" Archived-At: Subject: Re: [Rfced-future] Slight correction: Re: Thursday interim 20:00 GMT X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2021 23:44:19 -0000 --000000000000d0c20b05ca56b586 Content-Type: text/plain; charset="UTF-8" > > > > First of all, that looks like a VERY generic URL even if it does indeed > take me to: > > * The agenda > * The draft > * The Chair's slides > Yes, it lists all upcoming events. Normally [ahem] the chairs include an agenda with the URL in it :-) -- Wes Hardaker USC/ISI --000000000000d0c20b05ca56b586 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


First of all, that looks like a VERY generic URL even if it does indeed
take me to:

* The agenda
* The draft
* The Chair's slides

Yes, it lists = all upcoming events.=C2=A0 Normally [ahem] the chairs include an agenda wit= h the URL in it :-)

--
Wes Hardaker
USC/ISI
<= /div>
--000000000000d0c20b05ca56b586-- From nobody Tue Aug 24 19:37:48 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A21BC3A1FB5 for ; Tue, 24 Aug 2021 19:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, 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 ImL_NS1VhlHY for ; Tue, 24 Aug 2021 19:37:42 -0700 (PDT) Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (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 CC80F3A1FB7 for ; Tue, 24 Aug 2021 19:37:42 -0700 (PDT) Received: by mail-pj1-x102b.google.com with SMTP id u11-20020a17090adb4b00b00181668a56d6so3708362pjx.5 for ; Tue, 24 Aug 2021 19:37:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=lafvyjvID/jJreE0JniZgbIsV7zit1Th6sYgCOmpvNU=; b=Zk2VWTWCE9FQGNwKOUViQC7JA6dwqaMUjjsB/QuqXgXgyK9QXclH0amA1BtJ8U7WPY HB+4TS4+tOJ/ByvRjzkmCCsbl1wz2a37wS2aGIbxE/q9Lr1cy7DJwPP23mGKqH6fRYTf eTvsZDPBfgLOSGzqwBWEEZC082R8Ku/NxULyRR47dq3ZAVQVzHDk0iN17GECJytOa2FN ++SkVuiWuG077IGP+1m9rwAUss4IrQhdeOREDSO+k/zZCLpPYRufFPRciUuaFFQIqNGx wIUpChhFfxYixJ2hrBMCY+n1qRFq6b2vj9xem4WPWy7tQQyTrql8hDbXqOCz/Q/cACdU GZKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=lafvyjvID/jJreE0JniZgbIsV7zit1Th6sYgCOmpvNU=; b=gclkUPsvde+BGxLur2V/lzlNmAf2F/pVARx2IzhcKEDMDEAJZbn4o6ArbmaYmapi61 JfmEVpj9LKpR7VN7yVn9kLqx60+1BMn4IZxpY2J6tCHt6sevBIRXUeYG9B1PXrrnuUqg 3bVtt6YwhiHGAsrBdL6N/ZEPsikhLL3ntfHCw0f4TzU50Pak28+iQE0xlaSHX/2hAX2A hCalnMRrw4E4FUouRk2lvTEm7le8E1d24qFNEFmME+8oNMSBH/7q+nUbL73NP4sx46JC 3SGmQST93vo3dx/HBR6aVvDzrTn3mDhEBAUpBZD7MBHqTg86ryYcPkFn8C/DGZaZTRF2 7JKw== X-Gm-Message-State: AOAM530L+HeOLCLpnXejVClQws2xBa3aZ1e+x4E2QilLlFIMUmRimXG4 RuIKSQ9TrFwmoTDt+CnpZaOwx8us/mY= X-Google-Smtp-Source: ABdhPJxTA8c4VmZIl1J2oDygfN27RTZXGWqTtuZVJp9kHiy7IHc/vX0wBb2e+XR5SZvRuWNDHGnmMw== X-Received: by 2002:a17:902:7585:b0:135:2585:e261 with SMTP id j5-20020a170902758500b001352585e261mr9891666pll.21.1629859060884; Tue, 24 Aug 2021 19:37:40 -0700 (PDT) Received: from ?IPv6:2406:e003:100e:1e01:80b2:5c79:2266:e431? ([2406:e003:100e:1e01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id z4sm3662023pjl.53.2021.08.24.19.37.39 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 24 Aug 2021 19:37:40 -0700 (PDT) To: rfced-future@iab.org References: <8f30de10-af84-adbd-783e-169b637ddd3d@lear.ch> <122e59d0-6c26-a1c6-172f-86402838ea4e@lear.ch> <1B483BC9E28260B5F2463D6B@PSB> <47C28524-FD06-4FBD-AB32-1874F78FAC68@me.com> From: Brian E Carpenter Message-ID: <27fc23d0-5cb2-6dc0-a6e4-cb256110418f@gmail.com> Date: Wed, 25 Aug 2021 14:37:37 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Slight correction: Re: Thursday interim 20:00 GMT X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2021 02:37:47 -0000 Hopefully, by the time this (old) issue is resolved, this group will have=20 finished its work and disbanded. Regards Brian On 25-Aug-21 11:43, Wes Hardaker wrote: >=20 >=20 > First of all, that looks like a VERY generic URL even if it does in= deed > take me to: >=20 > * The agenda > * The draft > * The Chair's slides >=20 >=20 > Yes, it lists all upcoming events.=C2=A0 Normally [ahem] the chairs inc= lude an agenda with the URL in it :-) >=20 > --=20 > Wes Hardaker > USC/ISI >=20 From nobody Tue Aug 24 19:54:17 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3442A3A202A for ; Tue, 24 Aug 2021 19:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, 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 Ct8jc-aI4RuA for ; Tue, 24 Aug 2021 19:54:14 -0700 (PDT) Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (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 26A9E3A2027 for ; Tue, 24 Aug 2021 19:54:14 -0700 (PDT) Received: by mail-pf1-x42e.google.com with SMTP id 18so20050559pfh.9 for ; Tue, 24 Aug 2021 19:54:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=e0QN70mmwvj6A8X3U4dfS8KKEOem9CQTwfPCThFlcPg=; b=t4GsnR7wLak8g8iiJa6GFbNUaP2aGZc4b4g6FOuYhQ2fEvXnOOiWltc8FPmMhVeEVT RogBQ0N/YwXtENl1nqGvYsLZa25kmyA1w3dSnoYCG7m7SivikNRctqrbMOfo03gWK05H +vA+4SOt9PUjdjsvv1Mx+Ij4hx1wcYOifk20ddMzctqGfEpTMk7JLVsPQXtMC/rP08Xm a3m3x+8dWQqTJLYNelUELMCymFTB8evgxGzdHiRWMiP5kWoFeSr2GUy03WqbLpJ9St48 OS+MuTaBFXW3c6KWRO7yk6yL5R7Zg7q4cKIqtVxSXkfkMhlDuaqpGDLhkuAuvvYK9Ncv YNOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=e0QN70mmwvj6A8X3U4dfS8KKEOem9CQTwfPCThFlcPg=; b=pvfBB/6h1yDuSeL66LEyPOTyh26cgAR72Qyg/KRpX81bVRFxf7qM/XxcKjVYHYkgWH sMZ3fub9VoDPfLK2eUyWT/sIthkucxPb0IgH7cfAX8vIQ7d2EgHlVBuPvvFK+DWk0TF5 atInMgKVrW4Df19rlQaO3QZxJQIpNVH9LLAYUDW9eUhGozVjKI4JHRgcYDNTySfAlLIc 1lY/Q7ZnjClLFt8S7ZQD0MjAK/4HwalG0gQLfCqARBE+A0EM1X98dsjmf3bZEPGzwOAf CiJbEfXsWUEmV8CvuncErR+UNtxC/ljq8lrcltpQtCx5abFgGsg0Ae+53d9SpELLTFYT 6F9g== X-Gm-Message-State: AOAM532vLu/n0SB0MyKUbzvqDZPpAKELuOXzYC7s6yKm0OViBzeYs30i nsTgtHoqOnjDT1FwHWdxVgVe8UqypoQ= X-Google-Smtp-Source: ABdhPJyt5OSIrCeHvOZhZZcPAIXUVdb/+JbwqhgeA0zZA+9PhDCrp8VFU1OiK0ltmHHZ6u3xoHbmpA== X-Received: by 2002:a65:4486:: with SMTP id l6mr39401057pgq.145.1629860053068; Tue, 24 Aug 2021 19:54:13 -0700 (PDT) Received: from ?IPv6:2406:e003:100e:1e01:80b2:5c79:2266:e431? ([2406:e003:100e:1e01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id t13sm3639578pjg.25.2021.08.24.19.54.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 24 Aug 2021 19:54:12 -0700 (PDT) To: "Joel M. Halpern" , Eliot Lear Cc: "rfced-future@iab.org" References: <9f3100b9-0b19-a024-e597-dfcd112b0f57@lear.ch> <14522b15-ec15-6c3e-530e-34de0103aec1@joelhalpern.com> From: Brian E Carpenter Message-ID: <1fd347c5-9863-45ec-7693-23b78f96d402@gmail.com> Date: Wed, 25 Aug 2021 14:54:09 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <14522b15-ec15-6c3e-530e-34de0103aec1@joelhalpern.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Issue 45: When do the WG chairs call rough consensus and what happens next? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2021 02:54:16 -0000 On 25-Aug-21 03:32, Joel M. Halpern wrote: > After discussing the below with Eliot, he raised an idea which I think = > will work. >=20 > What if we added a little text saying that: > o chairs call consensus > o chairs do their best to judge the actual rough consensus of the WG These two points are covered by RFC2418, so could be supported by a reference. > o chairs are also expected to participate as individuals in the work of=20 > the WG > o chairs are expected to consider their own input as individuals along = > with all other input in judging rough consensus. I think that's true (and it's why we like to have two chairs) but I'm not sure it's actually written in the RFC process documents. However, we do expect chairs to be alive to the potential for conflict of interest= -- so a friendly rewrite: o chairs are also entitled to participate as individuals in the work of=20 the WG o chairs are expected to consider their own input as individuals along=20 with all other input in judging rough consensus, paying attention to their possible conflict of interest. Brian >=20 > That seems to give them the room to raise "but this isn't good enough",=20 > but require them to move the document forward if the WG does not agree.= >=20 > This is how I tend to assume things work in IETF WGs. It seems to me t= o=20 > be worth stating here since this is not an IETF WG. >=20 > Yours, > Joel >=20 > PS: I am happy to leave the task of weaving that into the existing text=20 > to the editor :-) If it is harder than I think, I am also happy to hel= p. >=20 >=20 > On 8/14/2021 4:55 AM, Eliot Lear wrote: >> Hi Joel, >> >>> Joel Halpern issue JMH5 >>> Reading the process, I was struck by a minor gap in the process items= =2E=20 >>> specifically in item 4 on issueing the last call. I think the text=20 >>> should include that the WG Chairs consider the proposal to be=20 >>> sufficiently developed and refined. We sometimes have situations wher= e=20 >>> there is rough consensus for something, but it really needs a little = >>> more work before it is sent out. Obviously, we do not want to require=20 >>> perfection. But we do want to give the chairs room to say "this needs=20 >>> more work". >> >> >> This is from an issue in April.=C2=A0 Since then we discussed several = >> eventualities, including what happens if the chairs attempt to block=20 >> consensus.=C2=A0 The outcome of that conversation seems to be the foll= owing: >> >>> =C2=A0=C2=A0 Community members who have concerns about >>> =C2=A0=C2=A0 the performance of an RSWG chair should direct their fee= dback to the >>> =C2=A0=C2=A0 relevant appointing body.=C2=A0 Each appointing body sha= ll have the power >>> =C2=A0=C2=A0 to remove its appointed chair at its discretion. >> >> That's looking at this issue from the other side, as it were. The way = I=20 >> read this text, the chairs have some latitude on when to start a=20 >> consensus call, but if it goes too far, complaints will get to the=20 >> appointing bodies. >> >> With that in mind, do you believe the issue is addressed?=C2=A0 If not= , is=20 >> there text you would want to add to address the matter? >> >> Eliot >> >> >> >=20 From nobody Tue Aug 24 20:03:05 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9953A2067 for ; Tue, 24 Aug 2021 20:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 nj3eF__tjN57 for ; Tue, 24 Aug 2021 20:02:58 -0700 (PDT) Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (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 A6C2D3A2069 for ; Tue, 24 Aug 2021 20:02:58 -0700 (PDT) Received: by mail-pj1-x102b.google.com with SMTP id w19-20020a17090aaf9300b00191e6d10a19so3248809pjq.1 for ; Tue, 24 Aug 2021 20:02:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=eiwQYWsJNn0+JhZtYlsS968lzdEzA1zJtk+rJVQHxFU=; b=K9EAygEVkzQLim+/M+Ef4wNwtbVTTLsOFQZWfOvLgw+biFqrqVI/UrAczw06s+haUb EAxQV+UMUOfnHK68iCoIoPgUXTSon/m+aMzn3eOBYNFVEtcrk8PNOaJn3VRcaEyYoDNg VYf94eSK6FtCg4KUpSxG/kslrhaHcHi5z1U9mkrFCp6PGeWKmfSYWfwSjXVOESaMUyBy QiBy8iR7JmmsbPE2Vf0rJGlbYo2jVuX94KHEvmI0sN9W+fFKDF+GIV3umvCEn6zsv7AC oWb5u90C+LZpgKE4nLDfdt1Sd9bwUsNGNMXiuh1smG+kt0vBLxJKLLtQeWqMnbUoThoW zpkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=eiwQYWsJNn0+JhZtYlsS968lzdEzA1zJtk+rJVQHxFU=; b=c0PM/QXcxkEGejJStqzu0sErYBsZPbFfmEQJ16uJ6O76mPUM+IGtQK8UITxWYPXmoi RtNt0jAwQC10ak6rPglhV3XvML70BcdDWwzMcAtbprUCsWdSuJE0L7W4aXCLaJtidat3 pQTkOJyBLX9XmQEDqBYiCeV7Ki/2KkvAZGkerBHogiQhqEoS378Eg1HcpzILgptUifN7 GmWuW+8ZQODGXEeSkCApi/NFb7mC8Gwfo8UC/M9G08uvHsGm5atMUxbFQIbtmWPg5zdd jBeJAcabvLfy7Z7VKWdQyAZIMXdLqowpRlDhWzIHtQ4mEKFrs3ncvnJS/NQYHizT9zqJ 1wKA== X-Gm-Message-State: AOAM533Vw1CUrVNOSigSMw8HEwh4+ElSJt1s05L80f6q18Wil5ZG6KI4 AG262MHFBeL4VTbC4S8R845YwxR3J1c= X-Google-Smtp-Source: ABdhPJzmjOPwpqpNG3yu1KgB5PL9hOE+cyX0mEGfkgErSySdf49Tn1kppXb6UhYKOYLSDkpJe4kYcw== X-Received: by 2002:a17:90b:384f:: with SMTP id nl15mr7800957pjb.203.1629860576337; Tue, 24 Aug 2021 20:02:56 -0700 (PDT) Received: from ?IPv6:2406:e003:100e:1e01:80b2:5c79:2266:e431? ([2406:e003:100e:1e01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id m23sm3619949pjr.38.2021.08.24.20.02.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 24 Aug 2021 20:02:55 -0700 (PDT) To: John C Klensin , "Joel M. Halpern" , Eliot Lear , Mirja Kuehlewind Cc: rfced-future@iab.org References: <2B46402F-5268-46B7-890F-7C5CA159EF13@ietf.org> <25FCCF71-ED00-48CA-8A15-4BB63B632F73@kuehlewind.net> <9F88E9DAC50B257953403E71@PSB> From: Brian E Carpenter Message-ID: <43994b46-18ea-88a5-32b5-8e3ddbb156f0@gmail.com> Date: Wed, 25 Aug 2021 15:02:50 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <9F88E9DAC50B257953403E71@PSB> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2021 03:03:04 -0000 On 25-Aug-21 03:33, John C Klensin wrote: > Joel, >=20 > While the phrasing may be wrong for the reason you identify, the > sentence is probably a useful statement of intent. >=20 > This is a question because I'm not sure, but I wonder if, rather > than removing the sentence, it would be useful to add a few > qualifying words such as "resources permitting", "in > coordination with the LLC about resources", or something like > that. Yes. The concern behind the sentence (with or without "proactively") was to ensure that an agreed policy does get transformed into action. But definitely, that might require resources that the LLC has to provide. Brian >=20 > best, > john >=20 >=20 >=20 > --On Tuesday, August 24, 2021 11:25 -0400 "Joel M. Halpern" > wrote: >=20 >> I think that the bracketed sentence should e deleted. >> >> It seems to require that once the RSWG / RSAB have approved a >> policy, the RPC must implement it. Even if it costs money and >> the LLC has not yet allocated the funds. That would seem to >> put them in a very difficult position. >> >> Yours, >> Joel >> >> On 8/24/2021 8:29 AM, Eliot Lear wrote: >>> Ok. >>> >>> >>> >>> I have, perhaps poorly, attempted to piece together what I >>> think is roughly what we're all talking about.=C2=A0 I may have >>> entirely gotten this wrong, and so please nitpick.=C2=A0 There >>> is one sentence in brackets that I think is redundant.=C2=A0 I >>> have not really touched the relationship text. >>> >>> Eliot >>> >>> # Roles and Processes >>> >>> >>> ## RFC Production Center (RPC) >>> >>> >>> Publication of RFCs shall continue to be handled by the RFC >>> Production Center (RPC) function in accordance with >>> high-level policies that have been specified through the >>> RSWG/RSAB process.=C2=A0 [[The RPC shall implement the policies >>> specified by the RSWG/RSAB process reflecting the priorities >>> of the community.]] They shall report regularly to and=20 >>> consult with the RSAB, RSWG, and broader community regarding >>> status of work undertaken and plans for work to be done, >>> including timeline for implementation as well as any key >>> risks they identify.=C2=A0 In doing so, the RPC will observe the >>> principle of transparency. The RPC shall consult with the >>> RSAB for advice on how to resolve any conflicts that arise >>> from community input. >>> >>> >>> All matters of budget, timetable and impact on its >>> performance targets, are between the RPC and IETF LLC. >>> >>> >>> ### Relationship between the RPC and the IETF LLC >>> >>> >>> This document does not specify the exact relationship between >>> the IETF LLC and the RPC function; for example, the RPC >>> function could be provided by a separate corporate entity >>> under contract to the IETF LLC, it could be performed by >>> employees of the IETF LLC, or the IETF LLC could work with >>> independent contractors for some or all aspects of the RPC >>> function. The exact relationship is a matter for the IETF LLC >>> and the IETF Executive Director to determine. >>> >>> >>> The IETF LLC has authority over negotiating performance >>> targets for the RPC and also has responsibility for ensuring >>> that those targets are adhered to. >>> >>> >>> If individuals or groups within the community have concerns >>> about the performance of the RPC, they can request that the >>> IETF LLC look into the matter. Even if the IETF LLC opts to >>> delegate this activity, concerns should be raised with the >>> IETF LLC. The IETF LLC is ultimately responsible to the >>> community via the mechanisms outlined in its charter. >>> >>> -------- >>> >>> >>> >>> >>> >=20 >=20 From nobody Tue Aug 24 20:15:39 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBF7F3A20F9 for ; Tue, 24 Aug 2021 20:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 og0R89QRQVt2 for ; Tue, 24 Aug 2021 20:15:33 -0700 (PDT) Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) (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 4BCBD3A20F4 for ; Tue, 24 Aug 2021 20:15:33 -0700 (PDT) Received: by mail-pj1-x1032.google.com with SMTP id j1so15601609pjv.3 for ; Tue, 24 Aug 2021 20:15:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Zn6AKIUXt3B1Re+wEN3AmCx8SvlTkJH2Yz69S9Whk5Q=; b=bJ6u3DNMthxC8tR4N5yRIC3oW7IIYwV7hcDypz71P6uDUKwAKuzwnG3xzdtsgAY/25 vALkYBj9lzjWi2KLKhX4Do8rgDQrVNbClJgVgbHwc5rCYZSBeFGTJf8POHlPF3SxSQyM Rx9dYTC1LhgB1bffHKiCzTckPKsAjNbwBooFS+q1QGQW2rXknU7OMFGSLw0Eau71Tmww zNZOs5dkyQimPZFknlqc2xsU9T5cR0HRLEGXyQsl5WPNN8Lzcg1HvlNyWFeuZ6Sly/5+ YoffXqQ7RdMCeANe2sexLz83ZKNc8/QPHqHW3goE3C0ihZx3OErqwWO0Za8VKiHJTp++ 8J4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Zn6AKIUXt3B1Re+wEN3AmCx8SvlTkJH2Yz69S9Whk5Q=; b=IrIEjRLU3zYOOyULnG1TRb0RQs84oPWeGtx74kdRS+sttUK+NhLCASbYScvYqOW865 8P0E4OVeEEDM7pqQjbMNevmgp9ej9K9Z3D44nLP+zx+gWZM58nJzRcn007rdPGATECBi t9/b1tBNDpi6Vx26D44Un6HKaL4+M8j2CQmicINfGlzPwJmMOpOxUNpcxcti1/9mZ1SE CTfbXJIre2ODR7rTiiEQ6NuQdlY8faCprjHxJjr7TCmBSyZsffsqNUVZ/9wf1fPnkKY3 ODZXY2WLsEBmMyWZiO6g8OP0nKo8QNCYTx0YzYc8EV47GVYWypfZqzdOzMzK1Sgsyvt7 Metw== X-Gm-Message-State: AOAM531P2uRD0KXDIV4jYhn+opu1To++BRE9VljdSjD8dYR4Ttrl0GsG s2rF1215iMbBmAaDkHa+VAPGNzso1Kw= X-Google-Smtp-Source: ABdhPJz6Yw2b8znK0YP7asBcPn2AkpfxH2riCE7HXGRM/GdTg5yFuHmxlH+qtpcZzeh/c3O9iZKF5Q== X-Received: by 2002:a17:902:d709:b0:130:6b05:be3e with SMTP id w9-20020a170902d70900b001306b05be3emr24362504ply.21.1629861331788; Tue, 24 Aug 2021 20:15:31 -0700 (PDT) Received: from ?IPv6:2406:e003:100e:1e01:80b2:5c79:2266:e431? ([2406:e003:100e:1e01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id g3sm24238878pgj.66.2021.08.24.20.15.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 24 Aug 2021 20:15:31 -0700 (PDT) To: Michael StJohns , Eric Rescorla Cc: rfced-future@iab.org References: <2B46402F-5268-46B7-890F-7C5CA159EF13@ietf.org> <25FCCF71-ED00-48CA-8A15-4BB63B632F73@kuehlewind.net> <9F88E9DAC50B257953403E71@PSB> <6c544af8-b60c-1f4a-8730-3c923196eab6@joelhalpern.com> <7ce1368a-7bd2-73e3-5410-0e951f40fa00@nthpermutation.com> <761bf2d8-759e-72e1-4c92-7419cea693bb@nthpermutation.com> From: Brian E Carpenter Message-ID: <1148ee5c-11da-6979-1056-2d7464ade5af@gmail.com> Date: Wed, 25 Aug 2021 15:15:26 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <761bf2d8-759e-72e1-4c92-7419cea693bb@nthpermutation.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2021 03:15:38 -0000 Front posting for cause: I think Mike's concern about Eliot's text derives from the way it starts.= So I'd suggest: OLD: Publication of RFCs shall continue to be handled by the RFC Production Ce= nter (RPC) function in accordance with high-level policies that have been=20 specified through the RSWG/RSAB process. [[The RPC shall implement the p= olicies specified by the RSWG/RSAB process reflecting the priorities of t= he community.]] NEW: Publication of RFCs shall continue to be handled by the RFC Production Ce= nter (RPC) function under direction from the IETF LLC, in accordance with=20 high-level policies that have been specified through the RSWG/RSAB proces= s, and subject to the IETF LLC providing the necessary resources. I wouldn't want to lose the text that discusses the RPC consulting direct= ly with and reporting directly to the community. Regards Brian Carpenter On 25-Aug-21 07:32, Michael StJohns wrote: > On 8/24/2021 2:38 PM, Eric Rescorla wrote: >> >> >> On Tue, Aug 24, 2021 at 11:34 AM Michael StJohns > wrote: >> >> On 8/24/2021 2:13 PM, Eric Rescorla wrote: >>> >>> ## Relationship between the RPC and the RSAB or RSWG >>> >>> Neither the RSAB nor the RSWG has any oversight, monitoring, = or directive relationship with respect to the RPC.=C2=A0 The RSAB and RSC= E have an advisory relationship with the RPC as described above. >>> >>> >>> This seems incorrect to me just as a matter of fact. When the RSW= G and RSAB publish an RFC describing how the RPC ought to behave, then th= is is in fact directive. >>> >>> -Ekr >>> >> I believe you're missing the difference between the noun "directiv= e" (e.g. the RFC is a policy directive which describes the operation of t= he RPC) which has the meaning: >> >> "an official or authoritative instruction". >> >> And the adjective "directive" (e.g. the RSWG has no directive rela= tionship with the RPC) which has the meaning: >> >> "involving the management or guidance of operations" - >> >> To put it another way, your state executive or legislature may iss= ue a directive (or a law) with respect to the wearing of masks, but the s= tate does not have a directive relationship with you unless you actually = work for the state.=C2=A0=C2=A0 I am personally subject to 1000s of direc= tives of various forms, but since I work for myself, I am not the subject=20 of a directive relationship in the meaning above. >> >> >> It seems to me that if we are having to refer to this kind of dictiona= ry-based interpretation, then a rewrite is in order. >=20 > I referred to a dictionary only for your convenience.=C2=A0 But "direct= ive" in conjunction with "relationship"=C2=A0 is the appropriate term her= e.=C2=A0 I guess you could use governing, or=C2=A0 control as replacement= s with some work, but those aren't as clear. >=20 >> >> I believe we've agreed that the RSAB and RSWG don't get to directl= y tell the RPC or the RSCE what to do - e.g. they may NOT direct either o= f those entities to perform specific work - all they can do is publish th= e RFCs and then ask the LLC to craft a contract or engagement agreement r= eflecting those RFCs. >> >> I think you're drawing too sharp a distinction. >> >> Suppose that the RSAWG were to publish an RFC saying that heretoforth = authors should be listed in alphabetical order. I would expect the RPC to=20 comply with that without some new contractual term from the LLC. Do you d= isagree? >=20 >=20 > The other section has this: >=20 >=20 >> Publication of RFCs shall continue to be handled by the RFC Production= =C2=A0 Center (RPC) function in accordance with policies described in the=20 Editorial series of RFCs, and consistent with the engagement agreement(s)=20 between the RPC and the LLC. >=20 > Assuming that the change in the RFC's does not require a change in the = costs, or impose more work and where the change is consistent with the ag= reement between the RPC and the LLC, then there is no requirement to chan= ge the contract.=C2=A0=C2=A0 And actually, if this requires a tooling cha= nge (not saying it will, but who knows), it might require LLC approval to=20 spend the money so... it may not be a contract change, but it may require=20 LLC (or IED) buy in.=C2=A0 That seems something that a) the RPC would hop= efully bring up during the RFC creation, b) the LLC would analyze before = RFC approval, and c) the LLC would be proactive in working with the RPC t= o implement the new RFC policies.=C2=A0=C2=A0 Or d) the LLC would say - w= e're not payinf for this. >=20 > The counter example is that you write a new RFC that says that the RPC = shall maintain a GIT instance tracking all of the changes made between su= bmission and publication of an RFC candidate and that wasn't part of the = contract, then yes it requires a change. >=20 > So the general answer to the more general question: "Will Editorial str= eam RFCs published by RSAB/RSWG require contract changes to the RPC?" is = "It depends" which I think you probably already knew. >=20 > Later, Mike >=20 >=20 >=20 >> >> -Ekr >> >> Later, Mike >> >> >> >=20 >=20 From nobody Tue Aug 24 21:47:02 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9D2D3A080E for ; Tue, 24 Aug 2021 21:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.891 X-Spam-Level: X-Spam-Status: No, score=-0.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=lear.ch 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 25t-Vkew6OJM for ; Tue, 24 Aug 2021 21:46:54 -0700 (PDT) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8BE43A080B for ; Tue, 24 Aug 2021 21:46:51 -0700 (PDT) Received: from Lear-Air.local ([IPv6:2a02:aa15:4101:2a80:90a8:e80e:64e6:f9a8]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 17P4kkmA216222 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 25 Aug 2021 06:46:46 +0200 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1629866807; bh=6eyvKou5Ks5YiwCBMaapU+3e+kkFSoyq7045LYSDEqI=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=qskF+63jTf5Qd0tnqDxybryVZxA+YkT5V64zbsZdHvkIi3fXtXeK8DeNnZnDmVbzl vHkGn1Wc8b30bj8mofKb3YxIk+fEBlH6R0PvACkU5Ni3jfOox7zNICgK+WVxz95V0m Tq7n6Y5v638lfkCWF3ifr1a3bn15TYhIbIpKEfM8= To: Brian E Carpenter , Michael StJohns , Eric Rescorla Cc: rfced-future@iab.org References: <2B46402F-5268-46B7-890F-7C5CA159EF13@ietf.org> <25FCCF71-ED00-48CA-8A15-4BB63B632F73@kuehlewind.net> <9F88E9DAC50B257953403E71@PSB> <6c544af8-b60c-1f4a-8730-3c923196eab6@joelhalpern.com> <7ce1368a-7bd2-73e3-5410-0e951f40fa00@nthpermutation.com> <761bf2d8-759e-72e1-4c92-7419cea693bb@nthpermutation.com> <1148ee5c-11da-6979-1056-2d7464ade5af@gmail.com> From: Eliot Lear Message-ID: <589efbbe-7804-acf0-191a-2f9206c9c18e@lear.ch> Date: Wed, 25 Aug 2021 06:46:42 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <1148ee5c-11da-6979-1056-2d7464ade5af@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="R6UJcEbuDtXQTn6q7RfIC2gg6J8ZlnkwH" Archived-At: Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2021 04:47:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --R6UJcEbuDtXQTn6q7RfIC2gg6J8ZlnkwH Content-Type: multipart/mixed; boundary="IMdu1bzYKlLq8RN7XjMeSlPL7HoWskb9U"; protected-headers="v1" From: Eliot Lear To: Brian E Carpenter , Michael StJohns , Eric Rescorla Cc: rfced-future@iab.org Message-ID: <589efbbe-7804-acf0-191a-2f9206c9c18e@lear.ch> Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 References: <2B46402F-5268-46B7-890F-7C5CA159EF13@ietf.org> <25FCCF71-ED00-48CA-8A15-4BB63B632F73@kuehlewind.net> <9F88E9DAC50B257953403E71@PSB> <6c544af8-b60c-1f4a-8730-3c923196eab6@joelhalpern.com> <7ce1368a-7bd2-73e3-5410-0e951f40fa00@nthpermutation.com> <761bf2d8-759e-72e1-4c92-7419cea693bb@nthpermutation.com> <1148ee5c-11da-6979-1056-2d7464ade5af@gmail.com> In-Reply-To: <1148ee5c-11da-6979-1056-2d7464ade5af@gmail.com> --IMdu1bzYKlLq8RN7XjMeSlPL7HoWskb9U Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Just one point below: On 25.08.21 05:15, Brian E Carpenter wrote: > Front posting for cause: > > I think Mike's concern about Eliot's text derives from the way it start= s. > So I'd suggest: > > OLD: > Publication of RFCs shall continue to be handled by the RFC Production = Center (RPC) function in accordance with high-level policies that have be= en > specified through the RSWG/RSAB process. [[The RPC shall implement the= policies specified by the RSWG/RSAB process reflecting the priorities of= the community.]] > > NEW: > Publication of RFCs shall continue to be handled by the RFC Production = Center (RPC) function under direction from the IETF LLC, in accordance wi= th > high-level policies that have been specified through the RSWG/RSAB proc= ess, and subject to the IETF LLC providing the necessary resources. > > I wouldn't want to lose the text that discusses the RPC consulting dire= ctly with and reporting directly to the community. We say that slightly differently- instead of reporting to the community, = providing reports to the community. Eliot > ( > > Regards > Brian Carpenter > > On 25-Aug-21 07:32, Michael StJohns wrote: >> On 8/24/2021 2:38 PM, Eric Rescorla wrote: >>> >>> On Tue, Aug 24, 2021 at 11:34 AM Michael StJohns > wrote: >>> >>> On 8/24/2021 2:13 PM, Eric Rescorla wrote: >>>> ## Relationship between the RPC and the RSAB or RSWG >>>> >>>> Neither the RSAB nor the RSWG has any oversight, monitoring= , or directive relationship with respect to the RPC.=C2=A0 The RSAB and R= SCE have an advisory relationship with the RPC as described above. >>>> >>>> >>>> This seems incorrect to me just as a matter of fact. When the R= SWG and RSAB publish an RFC describing how the RPC ought to behave, then = this is in fact directive. >>>> >>>> -Ekr >>>> >>> I believe you're missing the difference between the noun "direct= ive" (e.g. the RFC is a policy directive which describes the operation of= the RPC) which has the meaning: >>> >>> "an official or authoritative instruction". >>> >>> And the adjective "directive" (e.g. the RSWG has no directive re= lationship with the RPC) which has the meaning: >>> >>> "involving the management or guidance of operations" - >>> >>> To put it another way, your state executive or legislature may i= ssue a directive (or a law) with respect to the wearing of masks, but the= state does not have a directive relationship with you unless you actuall= y work for the state.=C2=A0=C2=A0 I am personally subject to 1000s of dir= ectives of various forms, but since I work for myself, I am not the subje= ct > of a directive relationship in the meaning above. >>> >>> It seems to me that if we are having to refer to this kind of diction= ary-based interpretation, then a rewrite is in order. >> I referred to a dictionary only for your convenience.=C2=A0 But "direc= tive" in conjunction with "relationship"=C2=A0 is the appropriate term he= re.=C2=A0 I guess you could use governing, or=C2=A0 control as replacemen= ts with some work, but those aren't as clear. >> >>> I believe we've agreed that the RSAB and RSWG don't get to direc= tly tell the RPC or the RSCE what to do - e.g. they may NOT direct either= of those entities to perform specific work - all they can do is publish = the RFCs and then ask the LLC to craft a contract or engagement agreement= reflecting those RFCs. >>> >>> I think you're drawing too sharp a distinction. >>> >>> Suppose that the RSAWG were to publish an RFC saying that heretoforth= authors should be listed in alphabetical order. I would expect the RPC t= o > comply with that without some new contractual term from the LLC. Do you= disagree? >> >> The other section has this: >> >> >>> Publication of RFCs shall continue to be handled by the RFC Productio= n=C2=A0 Center (RPC) function in accordance with policies described in th= e > Editorial series of RFCs, and consistent with the engagement agreement(= s) > between the RPC and the LLC. >> Assuming that the change in the RFC's does not require a change in the= costs, or impose more work and where the change is consistent with the a= greement between the RPC and the LLC, then there is no requirement to cha= nge the contract.=C2=A0=C2=A0 And actually, if this requires a tooling ch= ange (not saying it will, but who knows), it might require LLC approval t= o > spend the money so... it may not be a contract change, but it may requi= re > LLC (or IED) buy in.=C2=A0 That seems something that a) the RPC would h= opefully bring up during the RFC creation, b) the LLC would analyze befor= e RFC approval, and c) the LLC would be proactive in working with the RPC= to implement the new RFC policies.=C2=A0=C2=A0 Or d) the LLC would say -= we're not payinf for this. >> The counter example is that you write a new RFC that says that the RPC= shall maintain a GIT instance tracking all of the changes made between s= ubmission and publication of an RFC candidate and that wasn't part of the= contract, then yes it requires a change. >> >> So the general answer to the more general question: "Will Editorial st= ream RFCs published by RSAB/RSWG require contract changes to the RPC?" is= "It depends" which I think you probably already knew. >> >> Later, Mike >> >> >> >>> -Ekr >>> >>> Later, Mike >>> >>> >>> >> --IMdu1bzYKlLq8RN7XjMeSlPL7HoWskb9U-- --R6UJcEbuDtXQTn6q7RfIC2gg6J8ZlnkwH Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmElyzIFAwAAAAAACgkQh7ZrRtnSejPS NAf/bPmZQvVAkMKfYLutTq/seiXg5klMmiMhCfQurhIGu5R7xO9isUSRVk0ZeErJfT12KNj6yux7 HfK4bUL+U10DifxPphi+qBTZ99DmEvMlrVn5NGTIpX3VLn7pkYfkv7W77E2O2JL4xw0IQ25hGAAq 1TV6ErfweMM2zAJkaZ7eQg6gpvHJZXV4sB+vbE0B7Vf/Ae4AfhBN21ZOhgkjh/AO6x1fBn/YOBDM KuoyqzUL5+B71BLUzQ4pRK3z8bV9GFOi4eZyvBc3LkXGaf+MRdL8jp0QSsP4JFqLII7vLiMTBGSA MmBZ+sF/b4iyuNA4rL6/1UN7JOP6Y5BakF73SFxsbg== =RyoK -----END PGP SIGNATURE----- --R6UJcEbuDtXQTn6q7RfIC2gg6J8ZlnkwH-- From nobody Tue Aug 24 22:29:02 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 355373A00CF for ; Tue, 24 Aug 2021 22:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 A4b_GgVe4GiF for ; Tue, 24 Aug 2021 22:28:55 -0700 (PDT) Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (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 C6ADC3A00C1 for ; Tue, 24 Aug 2021 22:28:54 -0700 (PDT) Received: by mail-pl1-x62f.google.com with SMTP id d17so13610444plr.12 for ; Tue, 24 Aug 2021 22:28:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=v119iQJHQ5StYBSLe/UQHxvalLZg0KnC8Rp+EtF3gGY=; b=AzVTwLQTOI0lF0SwObab1Qp4AVcSQPV4OEpb1yswPLA/wfyzu1wTC92JLDiY4MGTZc ytues3TalOl8qVOh5ANetdsvm0ZtS/S1SR/k/UGy57JYLFDKeJs64fhxPo0VGduj6x4d 70MwkOYu0L0tZGXUuVuQKNQSC10po26QHDWuVRKMDYT5W0DAMDR6v615zzKqwHgxD1r9 LvMpej4+QocCN6uaUEV/rZpBzTBjxM2C7QlxcheFvCT+ApbG2EToDT0iVTbzeJJegKOi M8E+WAAAqEPZW832oRh7i3jFpgiqh3bt0pINnIoixI2Ty3sWlZ0waY5NmAae3hTaQKEa 092A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=v119iQJHQ5StYBSLe/UQHxvalLZg0KnC8Rp+EtF3gGY=; b=cK7MuHrSHJZC0Rgw68fagTNXzZjHZfKJ57d0WthHTs6H/47ue9H09jCPo2sTb9dNDF GFvCXhMZbapuRqlzUe99pJ80h6xeIcPGtLbPsCW10qFXsFkGlo17CkG2heXUoj7QIiez Oi0VBFY5mPAmDCwRpkLMck6jFaZYnr3IONgTYyKXRsq4RFeXPlOjVW+SqWhhMp/BZiXm OC47vn3+4zxfXHgdSFLFoRtKFMUSGO5yBmJlAWmeSg1QYqV+pHigbiPy71jjlvoFtTwq jKfSEALegwdeZaz1jNrmgTPvR8fmIH+YmTEuff1viWUMbChKQ/Me/2+SUK6Pc+wzlmIt xijA== X-Gm-Message-State: AOAM530kt5kRPAOyVr40LuxMf7r2CrrvFqyRjWnb7pG14LghPO1v13at AlznviwsoHli1mftE9cyjloaDXOJxLA= X-Google-Smtp-Source: ABdhPJywGSvPDsKI7RuX4zDxw4Bb4BKk29jUnDEFnx6U+qNi1XazeDeWvcm5ag9kf5WXGcHiypZ56A== X-Received: by 2002:a17:90a:5305:: with SMTP id x5mr8291579pjh.135.1629869332841; Tue, 24 Aug 2021 22:28:52 -0700 (PDT) Received: from ?IPv6:2406:e003:100e:1e01:80b2:5c79:2266:e431? ([2406:e003:100e:1e01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id d22sm230501pfq.158.2021.08.24.22.28.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 24 Aug 2021 22:28:52 -0700 (PDT) To: Eliot Lear , Michael StJohns , Eric Rescorla Cc: rfced-future@iab.org References: <2B46402F-5268-46B7-890F-7C5CA159EF13@ietf.org> <25FCCF71-ED00-48CA-8A15-4BB63B632F73@kuehlewind.net> <9F88E9DAC50B257953403E71@PSB> <6c544af8-b60c-1f4a-8730-3c923196eab6@joelhalpern.com> <7ce1368a-7bd2-73e3-5410-0e951f40fa00@nthpermutation.com> <761bf2d8-759e-72e1-4c92-7419cea693bb@nthpermutation.com> <1148ee5c-11da-6979-1056-2d7464ade5af@gmail.com> <589efbbe-7804-acf0-191a-2f9206c9c18e@lear.ch> From: Brian E Carpenter Message-ID: <3fd2fdbe-3318-13b0-6154-4f57b3481b80@gmail.com> Date: Wed, 25 Aug 2021 17:28:48 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <589efbbe-7804-acf0-191a-2f9206c9c18e@lear.ch> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2021 05:29:00 -0000 On 25-Aug-21 16:46, Eliot Lear wrote: > Just one point below: >=20 > On 25.08.21 05:15, Brian E Carpenter wrote: >> Front posting for cause: >> >> I think Mike's concern about Eliot's text derives from the way it star= ts. >> So I'd suggest: >> >> OLD: >> Publication of RFCs shall continue to be handled by the RFC Production=20 Center (RPC) function in accordance with high-level policies that have be= en >> specified through the RSWG/RSAB process. [[The RPC shall implement th= e policies specified by the RSWG/RSAB process reflecting the priorities o= f the community.]] >> >> NEW: >> Publication of RFCs shall continue to be handled by the RFC Production=20 Center (RPC) function under direction from the IETF LLC, in accordance wi= th >> high-level policies that have been specified through the RSWG/RSAB pro= cess, and subject to the IETF LLC providing the necessary resources. >> >> I wouldn't want to lose the text that discusses the RPC consulting dir= ectly with and reporting directly to the community. >=20 > We say that slightly differently- instead of reporting to the community= ,=20 > providing reports to the community. Indeed. I momentarily forgot the distortion of meaning of the phrase "report to" to mean "grovel and obey" in HR land. Brian > Eliot >=20 >=20 >> ( >> >> Regards >> Brian Carpenter >> >> On 25-Aug-21 07:32, Michael StJohns wrote: >>> On 8/24/2021 2:38 PM, Eric Rescorla wrote: >>>> >>>> On Tue, Aug 24, 2021 at 11:34 AM Michael StJohns > wrote: >>>> >>>> On 8/24/2021 2:13 PM, Eric Rescorla wrote: >>>>> ## Relationship between the RPC and the RSAB or RSWG >>>>> >>>>> Neither the RSAB nor the RSWG has any oversight, monitorin= g, or directive relationship with respect to the RPC.=C2=A0 The RSAB and = RSCE have an advisory relationship with the RPC as described above. >>>>> >>>>> >>>>> This seems incorrect to me just as a matter of fact. When the = RSWG and RSAB publish an RFC describing how the RPC ought to behave, then=20 this is in fact directive. >>>>> >>>>> -Ekr >>>>> >>>> I believe you're missing the difference between the noun "direc= tive" (e.g. the RFC is a policy directive which describes the operation o= f the RPC) which has the meaning: >>>> >>>> "an official or authoritative instruction". >>>> >>>> And the adjective "directive" (e.g. the RSWG has no directive r= elationship with the RPC) which has the meaning: >>>> >>>> "involving the management or guidance of operations" - >>>> >>>> To put it another way, your state executive or legislature may = issue a directive (or a law) with respect to the wearing of masks, but th= e state does not have a directive relationship with you unless you actual= ly work for the state.=C2=A0=C2=A0 I am personally subject to 1000s of di= rectives of various forms, but since I work for myself, I am not the subj= ect >> of a directive relationship in the meaning above. >>>> >>>> It seems to me that if we are having to refer to this kind of dictio= nary-based interpretation, then a rewrite is in order. >>> I referred to a dictionary only for your convenience.=C2=A0 But "dire= ctive" in conjunction with "relationship"=C2=A0 is the appropriate term h= ere.=C2=A0 I guess you could use governing, or=C2=A0 control as replaceme= nts with some work, but those aren't as clear. >>> >>>> I believe we've agreed that the RSAB and RSWG don't get to dire= ctly tell the RPC or the RSCE what to do - e.g. they may NOT direct eithe= r of those entities to perform specific work - all they can do is publish=20 the RFCs and then ask the LLC to craft a contract or engagement agreement=20 reflecting those RFCs. >>>> >>>> I think you're drawing too sharp a distinction. >>>> >>>> Suppose that the RSAWG were to publish an RFC saying that heretofort= h authors should be listed in alphabetical order. I would expect the RPC = to >> comply with that without some new contractual term from the LLC. Do yo= u disagree? >>> >>> The other section has this: >>> >>> >>>> Publication of RFCs shall continue to be handled by the RFC Producti= on=C2=A0 Center (RPC) function in accordance with policies described in t= he >> Editorial series of RFCs, and consistent with the engagement agreement= (s) >> between the RPC and the LLC. >>> Assuming that the change in the RFC's does not require a change in th= e costs, or impose more work and where the change is consistent with the = agreement between the RPC and the LLC, then there is no requirement to ch= ange the contract.=C2=A0=C2=A0 And actually, if this requires a tooling c= hange (not saying it will, but who knows), it might require LLC approval = to >> spend the money so... it may not be a contract change, but it may requ= ire >> LLC (or IED) buy in.=C2=A0 That seems something that a) the RPC would = hopefully bring up during the RFC creation, b) the LLC would analyze befo= re RFC approval, and c) the LLC would be proactive in working with the RP= C to implement the new RFC policies.=C2=A0=C2=A0 Or d) the LLC would say = - we're not payinf for this. >>> The counter example is that you write a new RFC that says that the RP= C shall maintain a GIT instance tracking all of the changes made between = submission and publication of an RFC candidate and that wasn't part of th= e contract, then yes it requires a change. >>> >>> So the general answer to the more general question: "Will Editorial s= tream RFCs published by RSAB/RSWG require contract changes to the RPC?" i= s "It depends" which I think you probably already knew. >>> >>> Later, Mike >>> >>> >>> >>>> -Ekr >>>> >>>> Later, Mike >>>> >>>> >>>> >>> >=20 From nobody Wed Aug 25 00:29:21 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57AFE3A117A for ; Wed, 25 Aug 2021 00:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch 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 RHFD7Zcu6lVU for ; Wed, 25 Aug 2021 00:29:11 -0700 (PDT) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AD013A0AAD for ; Wed, 25 Aug 2021 00:29:09 -0700 (PDT) Received: from [IPv6:2001:420:c0c0:1011::3] ([IPv6:2001:420:c0c0:1011:0:0:0:3]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 17P7T3HB218106 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 25 Aug 2021 09:29:03 +0200 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1629876544; bh=715orWjjEPzLKQoZQ43KE3IVMA5vnTwViCo/wMBoinc=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=XHl1APzLGwD0Ql+2sd+mdIY7RUG53Fkel+DPlNnWQW7LY13Qf85Wu3t6hxp6eLj9E e5yel+4jaoOpS//cihZqpSvSCNThKRjSZcmfLojGnI0apTYnNb/OwoaNOoOf0IIO9L VIq4CbGHNi7YrKtVhdfxREsDqXrlVx4cYvFr+4lY= To: Wes Hardaker Cc: rfced-future@iab.org, Brian Rosen References: <8f30de10-af84-adbd-783e-169b637ddd3d@lear.ch> <122e59d0-6c26-a1c6-172f-86402838ea4e@lear.ch> <1B483BC9E28260B5F2463D6B@PSB> <47C28524-FD06-4FBD-AB32-1874F78FAC68@me.com> From: Eliot Lear Message-ID: <98a8199c-2d7e-749d-262f-69eced01c5fa@lear.ch> Date: Wed, 25 Aug 2021 09:29:01 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="izr3pdHo5JgbutvjSsn3EgR8MNHSbhgpr" Archived-At: Subject: Re: [Rfced-future] Slight correction: Re: Thursday interim 20:00 GMT X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2021 07:29:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --izr3pdHo5JgbutvjSsn3EgR8MNHSbhgpr Content-Type: multipart/mixed; boundary="88QgG95jZBkkFAEk2YV7QRxmkF3TJsFwX"; protected-headers="v1" From: Eliot Lear To: Wes Hardaker Cc: rfced-future@iab.org, Brian Rosen Message-ID: <98a8199c-2d7e-749d-262f-69eced01c5fa@lear.ch> Subject: Re: [Rfced-future] Slight correction: Re: Thursday interim 20:00 GMT References: <8f30de10-af84-adbd-783e-169b637ddd3d@lear.ch> <122e59d0-6c26-a1c6-172f-86402838ea4e@lear.ch> <1B483BC9E28260B5F2463D6B@PSB> <47C28524-FD06-4FBD-AB32-1874F78FAC68@me.com> In-Reply-To: --88QgG95jZBkkFAEk2YV7QRxmkF3TJsFwX Content-Type: multipart/alternative; boundary="------------C45453B7117B942655834D0C" Content-Language: en-US This is a multi-part message in MIME format. --------------C45453B7117B942655834D0C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable There's nothing like a little activity to demonstrate how silly it is to = upload slides too early.=C2=A0 I've updated the slides based on the=20 discussion that has taken place in the last day or so. https://datatracker.ietf.org/doc/slides-interim-2021-rfcefdp-06-sessa-cha= irs-slides/ Agendawise, please see the slides for issues to be addressed. The group=20 may be plesaed to note that all remaining issues (at least for the=20 moment) fit on one slide, and the font isn't too small.=C2=A0 Here is the= =20 to-be-bashed agenda: 1. Note Well 2. Agenda Bashing 3. Getting to done- the approval flow 4. Issues 5. Next meeting 6. AOB Eliot On 25.08.21 01:43, Wes Hardaker wrote: > > > > First of all, that looks like a VERY generic URL even if it does > indeed > take me to: > > * The agenda > * The draft > * The Chair's slides > > > Yes, it lists all upcoming events.=C2=A0 Normally [ahem] the chairs inc= lude=20 > an agenda with the URL in it :-) > > --=20 > Wes Hardaker > USC/ISI --------------C45453B7117B942655834D0C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

There's nothing like a little activity to demonstrate how silly it is to upload slides too early.=C2=A0 I've updated the slides bas= ed on the discussion that has taken place in the last day or so.

https://da= tatracker.ietf.org/doc/slides-interim-2021-rfcefdp-06-sessa-chairs-slides= /

Agendawise, please see the slides for issues to be addressed.=C2=A0= The group may be plesaed to note that all remaining issues (at least for the moment) fit on one slide, and the font isn't too small.=C2=A0 Here is the to-be-bashed agenda:

  1. Note Well
  2. Agenda Bashing
  3. Getting to done- the approval flow
  4. Issues
  5. Next meeting
  6. AOB

Eliot

On 25.08.21 01:43, Wes Hardaker wrote:=


First of all, that looks like a VERY generic URL even if it does indeed
take me to:

* The agenda
* The draft
* The Chair's slides

Yes, it lists all upcoming events.=C2=A0 Normally [ahem] t= he chairs include an agenda with the URL in it :-)

--
Wes Hardaker
USC/ISI
--------------C45453B7117B942655834D0C-- --88QgG95jZBkkFAEk2YV7QRxmkF3TJsFwX-- --izr3pdHo5JgbutvjSsn3EgR8MNHSbhgpr Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmEl8T0FAwAAAAAACgkQh7ZrRtnSejOu bggAm/ED847IklgDp7aeSUtD/SoAPzk1UpROsAhpf4qtqc6hS30ME2cmPLgCBFniKT/rqy1ZahOO ZS04evXFPF79kDoh+QCbDlYVXWqFw9U/yN9RsOFnXo+KDwhpEyCjHrw1QnzW5XjbEi7omheOKBzL 2GMuSd7MrUH9xTQWI7F9FxmP8jBYwQmdwcVVR7y9UtKXGIwjEErB0sySzzOaXO3NSwnPLMWMPR+h zNPZatKc628btRm/aaNXz2cxq2kfkl8pRNxBXJv0qVh6no/RmQMLZckx6hrmn4iB5ei4W+q+zlKa 6YKp7lCVat/4VEslBl4aIuPPjA3Xt2tBrgM5+eo1sw== =85tB -----END PGP SIGNATURE----- --izr3pdHo5JgbutvjSsn3EgR8MNHSbhgpr-- From nobody Wed Aug 25 13:38:16 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B82D13A099E for ; Wed, 25 Aug 2021 13:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.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 YJzhiWTNamjG for ; Wed, 25 Aug 2021 13:38:08 -0700 (PDT) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 A22D63A098E for ; Wed, 25 Aug 2021 13:38:08 -0700 (PDT) Received: by mail-qt1-x831.google.com with SMTP id b1so607092qtx.0 for ; Wed, 25 Aug 2021 13:38:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=Ka0X6d98nulceBh9rwNU874DjcuKnlqSc/Oe5exgBt8=; b=cgD8nRqRUs/tpq1EpGmR+MWvpCvOZ3h0DBzyPHCafpK3qB/p/WudsKTwLPBzQZ1iw4 EiMm7lpBi5O1OntETx4YE/k+MiP6o92jX/TGEsHA48S7zIMkpnUZdxuFqSNG2ahQ50GJ Iop6yBVbpCXp7hdeo8w1tLlabC0hWg7AUck5e/ibSHX6mjhL3V2EY6AUzHD5IpRIwL83 EPSiGrHcsR1So2/CVgIyAvAnkmQUahwMuW5DkLi3W+wIqpkMOrqUCoOPiZd2uj5VueMo r6txMB0be2cioCjCitMOk66OkoPn7N0Jopzj/bhmx0wdrFuFIG8mkZicp9j4JClSBciK og/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=Ka0X6d98nulceBh9rwNU874DjcuKnlqSc/Oe5exgBt8=; b=Z8Yj4eb+gcH6AzR6pR9+WhmVVm8DgsRUM27vu8oZ/z2lHIWgali19gfXEbfx9Eg84r EDlGQAOgsLH6IC1Gi/8h+5/Ae/WkI8T+oxvBdp8TN7qxQBmus6agKh/dvpidcDRGoBch RyRuo9cH7VAh2/ZUdVVz6t8a43r6Ji/0+x9wkUC5ngHMUD59nKWawLbadNl1Pp5cFLxw aaxLRltBURYGoJhzd3z+cRfP4pL4GyaHupZSRtGznsa6Htpxr27PLWCxOe8eMiHDN7Au aDxiqhGDC8lS9UhHRBX7MYgZ7uy0/iMxwekUcqrkPLaA2jTrcW0+dBefjU4cGrhc0Eja 7pyw== X-Gm-Message-State: AOAM532evdNw+IHzT0BP/HApUfsEgNZbe2tRlbnVeueqxdnPr9ju4L5e +kiSnupWwLq1ijQ5njmY0CQx39/hawf3FxP8 X-Google-Smtp-Source: ABdhPJzKdj1TbL6DyjyNShOlVFgH1121jpP9f59iNQnbLQy+2sT1Aw9wfgaqVMO1HqJUuS1b3jT3lg== X-Received: by 2002:ac8:794e:: with SMTP id r14mr89743qtt.333.1629923885160; Wed, 25 Aug 2021 13:38:05 -0700 (PDT) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id g27sm496985qts.79.2021.08.25.13.38.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 25 Aug 2021 13:38:04 -0700 (PDT) To: Brian E Carpenter , Eric Rescorla Cc: rfced-future@iab.org References: <2B46402F-5268-46B7-890F-7C5CA159EF13@ietf.org> <25FCCF71-ED00-48CA-8A15-4BB63B632F73@kuehlewind.net> <9F88E9DAC50B257953403E71@PSB> <6c544af8-b60c-1f4a-8730-3c923196eab6@joelhalpern.com> <7ce1368a-7bd2-73e3-5410-0e951f40fa00@nthpermutation.com> <761bf2d8-759e-72e1-4c92-7419cea693bb@nthpermutation.com> <1148ee5c-11da-6979-1056-2d7464ade5af@gmail.com> From: Michael StJohns Message-ID: <1af8e9db-5ea4-e002-bfe3-832d432fd34e@nthpermutation.com> Date: Wed, 25 Aug 2021 16:38:03 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <1148ee5c-11da-6979-1056-2d7464ade5af@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2021 20:38:15 -0000 On 8/24/2021 11:15 PM, Brian E Carpenter wrote: > Front posting for cause: > > I think Mike's concern about Eliot's text derives from the way it starts. > So I'd suggest: Hi Brian - If I thought that was the problem I would have provided changes to your text rather than new text.  I'm too lazy to write if I don't have to. WRT to your text, I really need it to not link the RPC with the RSWG/RSAB and instead link it to the documents.  While this group has finally gotten the point that the RPC does not "report to" those groups, nor can those groups command the RPC, what I'm afraid of is 3-5 years down the road where someone uses the text to justify the RSWG giving operational directions to the RPC. I also want to get the point made that the RPC works with the RSWG as it tries to form strategic policy and that the RSWG is the primary place for the RPC interaction rather than - as your text seems to imply - the RPC is responsible for interacting with all comer directly on matters of strategy. None of the above is meant to imply that the RPC doesn't work with authors on their documents - but that's not the thrust of the text you and Mirja crafted and I think is handled elsewhere?  If not, a simple line that indicates that set of interactions would be useful. The RPC has both a role in the strategic process (e.g. sanity checks on whether things will work, or the costs of doing new things as specified by the Editorial series - e.g. with the RSWG), and the tactical process (publishing documents while adhering to the aforesaid Editorial series documents - with the RSCE and RSAB I would expect).  Those need to be teased apart and specified separately and the RPC interaction with the community on strategy ideally given a single specified place to happen.  That will help both the LLC and RPC scope the tasking required to support the strategic process. By the way - I'm not sure how you would have come to the conclusion you came given the text I wrote.  Could you explain how you got there? Thanks, Mike > > OLD: > Publication of RFCs shall continue to be handled by the RFC Production Center (RPC) function in accordance with high-level policies that have been > specified through the RSWG/RSAB process. [[The RPC shall implement the policies specified by the RSWG/RSAB process reflecting the priorities of the community.]] > > NEW: > Publication of RFCs shall continue to be handled by the RFC Production Center (RPC) function under direction from the IETF LLC, in accordance with > high-level policies that have been specified through the RSWG/RSAB process, and subject to the IETF LLC providing the necessary resources. > > I wouldn't want to lose the text that discusses the RPC consulting directly with and reporting directly to the community. > > Regards > Brian Carpenter > > On 25-Aug-21 07:32, Michael StJohns wrote: >> On 8/24/2021 2:38 PM, Eric Rescorla wrote: >>> >>> On Tue, Aug 24, 2021 at 11:34 AM Michael StJohns > wrote: >>> >>> On 8/24/2021 2:13 PM, Eric Rescorla wrote: >>>> ## Relationship between the RPC and the RSAB or RSWG >>>> >>>> Neither the RSAB nor the RSWG has any oversight, monitoring, or directive relationship with respect to the RPC.  The RSAB and RSCE have an advisory relationship with the RPC as described above. >>>> >>>> >>>> This seems incorrect to me just as a matter of fact. When the RSWG and RSAB publish an RFC describing how the RPC ought to behave, then this is in fact directive. >>>> >>>> -Ekr >>>> >>> I believe you're missing the difference between the noun "directive" (e.g. the RFC is a policy directive which describes the operation of the RPC) which has the meaning: >>> >>> "an official or authoritative instruction". >>> >>> And the adjective "directive" (e.g. the RSWG has no directive relationship with the RPC) which has the meaning: >>> >>> "involving the management or guidance of operations" - >>> >>> To put it another way, your state executive or legislature may issue a directive (or a law) with respect to the wearing of masks, but the state does not have a directive relationship with you unless you actually work for the state.   I am personally subject to 1000s of directives of various forms, but since I work for myself, I am not the subject > of a directive relationship in the meaning above. >>> >>> It seems to me that if we are having to refer to this kind of dictionary-based interpretation, then a rewrite is in order. >> I referred to a dictionary only for your convenience.  But "directive" in conjunction with "relationship"  is the appropriate term here.  I guess you could use governing, or  control as replacements with some work, but those aren't as clear. >> >>> I believe we've agreed that the RSAB and RSWG don't get to directly tell the RPC or the RSCE what to do - e.g. they may NOT direct either of those entities to perform specific work - all they can do is publish the RFCs and then ask the LLC to craft a contract or engagement agreement reflecting those RFCs. >>> >>> I think you're drawing too sharp a distinction. >>> >>> Suppose that the RSAWG were to publish an RFC saying that heretoforth authors should be listed in alphabetical order. I would expect the RPC to > comply with that without some new contractual term from the LLC. Do you disagree? >> >> The other section has this: >> >> >>> Publication of RFCs shall continue to be handled by the RFC Production  Center (RPC) function in accordance with policies described in the > Editorial series of RFCs, and consistent with the engagement agreement(s) > between the RPC and the LLC. >> Assuming that the change in the RFC's does not require a change in the costs, or impose more work and where the change is consistent with the agreement between the RPC and the LLC, then there is no requirement to change the contract.   And actually, if this requires a tooling change (not saying it will, but who knows), it might require LLC approval to > spend the money so... it may not be a contract change, but it may require > LLC (or IED) buy in.  That seems something that a) the RPC would hopefully bring up during the RFC creation, b) the LLC would analyze before RFC approval, and c) the LLC would be proactive in working with the RPC to implement the new RFC policies.   Or d) the LLC would say - we're not payinf for this. >> The counter example is that you write a new RFC that says that the RPC shall maintain a GIT instance tracking all of the changes made between submission and publication of an RFC candidate and that wasn't part of the contract, then yes it requires a change. >> >> So the general answer to the more general question: "Will Editorial stream RFCs published by RSAB/RSWG require contract changes to the RPC?" is "It depends" which I think you probably already knew. >> >> Later, Mike >> >> >> >>> -Ekr >>> >>> Later, Mike >>> >>> >>> >> From nobody Wed Aug 25 15:34:08 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5338D3A0824 for ; Wed, 25 Aug 2021 15:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 N9zelnJrMzxG for ; Wed, 25 Aug 2021 15:33:59 -0700 (PDT) Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) (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 4E0383A08DB for ; Wed, 25 Aug 2021 15:33:59 -0700 (PDT) Received: by mail-pj1-x102f.google.com with SMTP id u11-20020a17090adb4b00b00181668a56d6so823198pjx.5 for ; Wed, 25 Aug 2021 15:33:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Ac9ejOv1EYtqMrz+UWa04skkpvWGwnRkuIOXK2XLLig=; b=ZBdDU+4briUNQY9Xfd8qpoork5FutE0rM97Mzmat5cb+n4Mg8Z9pLuav9wtKeM+Say bP9ni5J1Vw+zt0m5DKJ/3rSlJQ/5hgWA8B00+Jhoq1wNHpjeY/UMIOMiS2A37tHJntlO /F+OlAzrFutwQHoPwm3xWt1ZYIiZ6JmZzo06isJfsLgbR0ORfuPeG6jADc1dtDyGzXVS WpBkJLav5XUFzZ81kdf1IhBQDeCeI5O1B9BbScRnehdyS5JDnJq05V+4Cb8OIxyQL3wJ tN5GnKpL812Ia/7tNQmwIgtNm0Lxhv7AIW7D5edqB2Zm+bsr9irdhuz+K2XQuvdUizbu 5NrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Ac9ejOv1EYtqMrz+UWa04skkpvWGwnRkuIOXK2XLLig=; b=oHmMLOsODRJpGO805AgaoT3LXXDKoaCRgnaYaMH42jyjgv3OtWXK2/Ds6RVfSJBiUc PRopfl09JWxV6/wtnfo+5RZy9o1pxKUZtTeARZ49sCzTaOIZBODl9ZxsKklQ/ZxTY6a5 a7eOZzxa3OYsVDP2kOdOt/s0ZaJZ5S8J4jqFC/lr8jLTmTsAlnY4oWgPRMulFNdY6MkU //VAcGnaS4+KraiRuJ4p1XxWkAxPru4WT/xbV5+ahESXk2mWio0mRcv6V52LXxda2+TC KzorynvEE4diB9p3+AvgvihaQRpXK9gQp+sXJbDKkcMQdTy6gAOYOAhU8axn1DCq7Ko6 Z+Rg== X-Gm-Message-State: AOAM532NOxX5HnXY8zYZQhtKQyDbx2Fy3mcI6Mq+DHiMytLFGprANh4j 5Hy9Lzz/AWHQ98+hGRi8/papvnGBWrE= X-Google-Smtp-Source: ABdhPJyMDa2XK4huxW5P41zpsL0MnxfxwZgHjHYnJPsomTRMAIT2yOUq3YwwW2f76CxzZ0WH9A5rAw== X-Received: by 2002:a17:90a:4285:: with SMTP id p5mr633351pjg.162.1629930837888; Wed, 25 Aug 2021 15:33:57 -0700 (PDT) Received: from ?IPv6:2406:e003:11d3:cf01:80b2:5c79:2266:e431? ([2406:e003:11d3:cf01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id u22sm642626pfi.143.2021.08.25.15.33.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 25 Aug 2021 15:33:57 -0700 (PDT) To: Michael StJohns , Eric Rescorla Cc: rfced-future@iab.org References: <2B46402F-5268-46B7-890F-7C5CA159EF13@ietf.org> <25FCCF71-ED00-48CA-8A15-4BB63B632F73@kuehlewind.net> <9F88E9DAC50B257953403E71@PSB> <6c544af8-b60c-1f4a-8730-3c923196eab6@joelhalpern.com> <7ce1368a-7bd2-73e3-5410-0e951f40fa00@nthpermutation.com> <761bf2d8-759e-72e1-4c92-7419cea693bb@nthpermutation.com> <1148ee5c-11da-6979-1056-2d7464ade5af@gmail.com> <1af8e9db-5ea4-e002-bfe3-832d432fd34e@nthpermutation.com> From: Brian E Carpenter Message-ID: <02e5c6a6-cb93-a2b2-8621-97a1389f17a7@gmail.com> Date: Thu, 26 Aug 2021 10:33:54 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <1af8e9db-5ea4-e002-bfe3-832d432fd34e@nthpermutation.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2021 22:34:05 -0000 On 26-Aug-21 08:38, Michael StJohns wrote: > On 8/24/2021 11:15 PM, Brian E Carpenter wrote: >> Front posting for cause: >> >> I think Mike's concern about Eliot's text derives from the way it star= ts. >> So I'd suggest: >=20 > Hi Brian - >=20 > If I thought that was the problem I would have provided changes to your=20 > text rather than new text.=C2=A0 I'm too lazy to write if I don't have = to. >=20 > WRT to your text, I really need it to not link the RPC with the=20 > RSWG/RSAB and instead link it to the documents.=C2=A0 While this group = has=20 > finally gotten the point that the RPC does not "report to" those groups= ,=20 > nor can those groups command the RPC, what I'm afraid of is 3-5 years=20 > down the road where someone uses the text to justify the RSWG giving=20 > operational directions to the RPC. >=20 > I also want to get the point made that the RPC works with the RSWG as i= t=20 > tries to form strategic policy and that the RSWG is the primary place=20 > for the RPC interaction rather than - as your text seems to imply - the=20 > RPC is responsible for interacting with all comer directly on matters o= f=20 > strategy. >=20 > None of the above is meant to imply that the RPC doesn't work with=20 > authors on their documents - but that's not the thrust of the text you = > and Mirja crafted and I think is handled elsewhere?=C2=A0 If not, a sim= ple=20 > line that indicates that set of interactions would be useful. >=20 > The RPC has both a role in the strategic process (e.g. sanity checks on=20 > whether things will work, or the costs of doing new things as specified=20 > by the Editorial series - e.g. with the RSWG), and the tactical process=20 > (publishing documents while adhering to the aforesaid Editorial series = > documents - with the RSCE and RSAB I would expect).=C2=A0 Those need to=20 be=20 > teased apart and specified separately and the RPC interaction with the = > community on strategy ideally given a single specified place to happen.= =C2=A0=20 > That will help both the LLC and RPC scope the tasking required to=20 > support the strategic process. >=20 > By the way - I'm not sure how you would have come to the conclusion you=20 > came given the text I wrote.=C2=A0 Could you explain how you got there?= Simply because the thrust of your text was to say that the line of command was policy --> IETF LLC --> RPC and Eliot's text seemed to dilute that. Whereas yours seemed to emphasise that and dilute the RPC's ability to interact widely with the community as well as with authors. (I don't dispute that RSWG is the *primary* place for such interaction.) Brian >=20 > Thanks, Mike >=20 >=20 >=20 >> >> OLD: >> Publication of RFCs shall continue to be handled by the RFC Production=20 Center (RPC) function in accordance with high-level policies that have be= en >> specified through the RSWG/RSAB process. [[The RPC shall implement th= e policies specified by the RSWG/RSAB process reflecting the priorities o= f the community.]] >> >> NEW: >> Publication of RFCs shall continue to be handled by the RFC Production=20 Center (RPC) function under direction from the IETF LLC, in accordance wi= th >> high-level policies that have been specified through the RSWG/RSAB pro= cess, and subject to the IETF LLC providing the necessary resources. >> >> I wouldn't want to lose the text that discusses the RPC consulting dir= ectly with and reporting directly to the community. >> >> Regards >> Brian Carpenter >> >> On 25-Aug-21 07:32, Michael StJohns wrote: >>> On 8/24/2021 2:38 PM, Eric Rescorla wrote: >>>> >>>> On Tue, Aug 24, 2021 at 11:34 AM Michael StJohns > wrote: >>>> >>>> On 8/24/2021 2:13 PM, Eric Rescorla wrote: >>>>> ## Relationship between the RPC and the RSAB or RSWG >>>>> >>>>> Neither the RSAB nor the RSWG has any oversight, monitorin= g, or directive relationship with respect to the RPC.=C2=A0 The RSAB and = RSCE have an advisory relationship with the RPC as described above. >>>>> >>>>> >>>>> This seems incorrect to me just as a matter of fact. When the = RSWG and RSAB publish an RFC describing how the RPC ought to behave, then=20 this is in fact directive. >>>>> >>>>> -Ekr >>>>> >>>> I believe you're missing the difference between the noun "direc= tive" (e.g. the RFC is a policy directive which describes the operation o= f the RPC) which has the meaning: >>>> >>>> "an official or authoritative instruction". >>>> >>>> And the adjective "directive" (e.g. the RSWG has no directive r= elationship with the RPC) which has the meaning: >>>> >>>> "involving the management or guidance of operations" - >>>> >>>> To put it another way, your state executive or legislature may = issue a directive (or a law) with respect to the wearing of masks, but th= e state does not have a directive relationship with you unless you actual= ly work for the state.=C2=A0=C2=A0 I am personally subject to 1000s of di= rectives of various forms, but since I work for myself, I am not the subj= ect >> of a directive relationship in the meaning above. >>>> >>>> It seems to me that if we are having to refer to this kind of dictio= nary-based interpretation, then a rewrite is in order. >>> I referred to a dictionary only for your convenience.=C2=A0 But "dire= ctive" in conjunction with "relationship"=C2=A0 is the appropriate term h= ere.=C2=A0 I guess you could use governing, or=C2=A0 control as replaceme= nts with some work, but those aren't as clear. >>> >>>> I believe we've agreed that the RSAB and RSWG don't get to dire= ctly tell the RPC or the RSCE what to do - e.g. they may NOT direct eithe= r of those entities to perform specific work - all they can do is publish=20 the RFCs and then ask the LLC to craft a contract or engagement agreement=20 reflecting those RFCs. >>>> >>>> I think you're drawing too sharp a distinction. >>>> >>>> Suppose that the RSAWG were to publish an RFC saying that heretofort= h authors should be listed in alphabetical order. I would expect the RPC = to >> comply with that without some new contractual term from the LLC. Do yo= u disagree? >>> >>> The other section has this: >>> >>> >>>> Publication of RFCs shall continue to be handled by the RFC Producti= on=C2=A0 Center (RPC) function in accordance with policies described in t= he >> Editorial series of RFCs, and consistent with the engagement agreement= (s) >> between the RPC and the LLC. >>> Assuming that the change in the RFC's does not require a change in th= e costs, or impose more work and where the change is consistent with the = agreement between the RPC and the LLC, then there is no requirement to ch= ange the contract.=C2=A0=C2=A0 And actually, if this requires a tooling c= hange (not saying it will, but who knows), it might require LLC approval = to >> spend the money so... it may not be a contract change, but it may requ= ire >> LLC (or IED) buy in.=C2=A0 That seems something that a) the RPC would = hopefully bring up during the RFC creation, b) the LLC would analyze befo= re RFC approval, and c) the LLC would be proactive in working with the RP= C to implement the new RFC policies.=C2=A0=C2=A0 Or d) the LLC would say = - we're not payinf for this. >>> The counter example is that you write a new RFC that says that the RP= C shall maintain a GIT instance tracking all of the changes made between = submission and publication of an RFC candidate and that wasn't part of th= e contract, then yes it requires a change. >>> >>> So the general answer to the more general question: "Will Editorial s= tream RFCs published by RSAB/RSWG require contract changes to the RPC?" i= s "It depends" which I think you probably already knew. >>> >>> Later, Mike >>> >>> >>> >>>> -Ekr >>>> >>>> Later, Mike >>>> >>>> >>>> >>> >=20 From nobody Wed Aug 25 16:10:39 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF203A1002 for ; Wed, 25 Aug 2021 16:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.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 TQ3aM7gR_a7K for ; Wed, 25 Aug 2021 16:10:33 -0700 (PDT) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 0A4AB3A0EFD for ; Wed, 25 Aug 2021 16:10:32 -0700 (PDT) Received: by mail-qk1-x729.google.com with SMTP id a10so1256348qka.12 for ; Wed, 25 Aug 2021 16:10:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=OO6XANKZejXSdtmVjsQOqJlM0Wxb2yzERq4fotTBy5s=; b=ynJYcciFQNFaECLe79/5q2j/To+Oiq5JSXbTBVFbtYF5W9IRK3da+ugFWmSGje6Dkz P/FnpGUnwceHBpicNC0IBn/3RaTIZJoYuuWE68peFobp9hyoFEURiqJlX/8pJn/EuIdg CKnN7luZKYmAmYUklWal1rpeX/qEh7hh2/om0SfAIFJXeHSdRVVW611Vur0OcDIeimLp kZPtnfIGeMFxtehSotzpv9hbTvmpYSObKbWVa9X+HjHdl1XLJ5CyYChgydM5tOrjPD3p JMrjbKFu0+PGX+14QbfwlhTCmZ+omZue5WblGZDYPnd4MCYKIb4Omn6cDRRkzPAdp5s7 aOEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=OO6XANKZejXSdtmVjsQOqJlM0Wxb2yzERq4fotTBy5s=; b=jzd9U1VxuxVinPXSvl6uRMseAveFNVHPOGTLZDtyHT3RmbG4xZvVH2j52aPk0Wg03r y09AL1A2NfbvcN348NXhpebT4oWVyw9H+2vp7PJJf6ueuGcJ6xuU18O/30VbQwCBiPsE DnZj2XGl0a/lWYR7+isVIbiM74KRt3orYEbjDDmbCV/9QlvTxTVcOvGD4DkD/DeGS7qU F+PCbI0khIFKdVIsFauhTWceSCjblCkMzXaxwyUumxFlkZ7aDPbDRZRE6GCz0EnOWEol 3NbgkQlMHsOi7dsbCTfQJoFZRdDGC02uGAwLI3q/D+ZtTKyUC+bbhpm1zU8oFxxQzsNn VUDA== X-Gm-Message-State: AOAM531eLsVG3xo8TguwjlzWWUmeh8ddT3z9JNZmA5P3nw0D4LtQ9B78 32LC9knzDIFHDe1NQ6+Q9fpz/XhZ/xoMSNLn X-Google-Smtp-Source: ABdhPJwAI0TrAMOqHmnXNAYgbWgj+7CHqQd+XOB7jxqIxBNAfxO3/OZGMs8R/LI0lfyTF0OG3DNF5A== X-Received: by 2002:a37:8242:: with SMTP id e63mr999546qkd.294.1629933029939; Wed, 25 Aug 2021 16:10:29 -0700 (PDT) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id v5sm1088308qkh.39.2021.08.25.16.10.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 25 Aug 2021 16:10:29 -0700 (PDT) To: Brian E Carpenter , Eric Rescorla Cc: rfced-future@iab.org References: <2B46402F-5268-46B7-890F-7C5CA159EF13@ietf.org> <25FCCF71-ED00-48CA-8A15-4BB63B632F73@kuehlewind.net> <9F88E9DAC50B257953403E71@PSB> <6c544af8-b60c-1f4a-8730-3c923196eab6@joelhalpern.com> <7ce1368a-7bd2-73e3-5410-0e951f40fa00@nthpermutation.com> <761bf2d8-759e-72e1-4c92-7419cea693bb@nthpermutation.com> <1148ee5c-11da-6979-1056-2d7464ade5af@gmail.com> <1af8e9db-5ea4-e002-bfe3-832d432fd34e@nthpermutation.com> <02e5c6a6-cb93-a2b2-8621-97a1389f17a7@gmail.com> From: Michael StJohns Message-ID: <51221c6a-1adc-c32f-90d5-1d2d3d3852b4@nthpermutation.com> Date: Wed, 25 Aug 2021 19:10:28 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <02e5c6a6-cb93-a2b2-8621-97a1389f17a7@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2021 23:10:37 -0000 On 8/25/2021 6:33 PM, Brian E Carpenter wrote: > On 26-Aug-21 08:38, Michael StJohns wrote: >> On 8/24/2021 11:15 PM, Brian E Carpenter wrote: >>> Front posting for cause: >>> >>> I think Mike's concern about Eliot's text derives from the way it starts. >>> So I'd suggest: >> Hi Brian - >> >> If I thought that was the problem I would have provided changes to your >> text rather than new text.  I'm too lazy to write if I don't have to. >> >> WRT to your text, I really need it to not link the RPC with the >> RSWG/RSAB and instead link it to the documents.  While this group has >> finally gotten the point that the RPC does not "report to" those groups, >> nor can those groups command the RPC, what I'm afraid of is 3-5 years >> down the road where someone uses the text to justify the RSWG giving >> operational directions to the RPC. >> >> I also want to get the point made that the RPC works with the RSWG as it >> tries to form strategic policy and that the RSWG is the primary place >> for the RPC interaction rather than - as your text seems to imply - the >> RPC is responsible for interacting with all comer directly on matters of >> strategy. >> >> None of the above is meant to imply that the RPC doesn't work with >> authors on their documents - but that's not the thrust of the text you >> and Mirja crafted and I think is handled elsewhere?  If not, a simple >> line that indicates that set of interactions would be useful. >> >> The RPC has both a role in the strategic process (e.g. sanity checks on >> whether things will work, or the costs of doing new things as specified >> by the Editorial series - e.g. with the RSWG), and the tactical process >> (publishing documents while adhering to the aforesaid Editorial series >> documents - with the RSCE and RSAB I would expect).  Those need to > be >> teased apart and specified separately and the RPC interaction with the >> community on strategy ideally given a single specified place to happen. >> That will help both the LLC and RPC scope the tasking required to >> support the strategic process. >> >> By the way - I'm not sure how you would have come to the conclusion you >> came given the text I wrote.  Could you explain how you got there? > Simply because the thrust of your text was to say that the line of > command was policy --> IETF LLC --> RPC and Eliot's text seemed > to dilute that. Whereas yours seemed to emphasise that and dilute > the RPC's ability to interact widely with the community as well as > with authors. (I don't dispute that RSWG is the *primary* place > for such interaction.) Actually, the line of authority is more generally: Community -> RSWG -> RSAB ->  Editorial Series -> RPC and LLC -> RPC.   Both of the "->" indicators pointing to the RPC are constrained by the terms of the engagement agreement.   There's also   RSAB - advise when requested -> RPC. I phrased it as I did because there's a large difference between an ability and a requirement.   The following has "They shall report ... to and consult with ... the broader community regarding...".   Which implies a requirement that RPC engages with the community on the strategic stuff outside of the RSWG.   Maybe I'm parsing this too tightly, but the RSWG (and the RSWG mailing list for sure) is the place where the community gets to engage this process and specifying them as separate entities in this instance (not generally), muddies the water for this specific partner. I guess I don't understand what RPC ability you think I removed?   Maybe you could describe a scenario which is prohibited by my text? > They shall report regularly to and > consult with the RSAB, RSWG, and broader community regarding > status of work undertaken and plans for work to be done, > including timeline for implementation as well as any key > risks they identify. Then there is this clause: > The LLC is requested to negotiate a task with the RPC that permits and > requires the RPC to collaborate in at least an advisory capacity in > the content creation of the Editorial series RFCs as they affect the > RPC and that collaboration is expected to be the main path for > community input into the RPC processes. Which enhances the *ability* of the RPC to participate in the RFC series process discussions as a partner rather than as a supplicant or afterthought. Thanks for the response! Mike > > Brian > >> Thanks, Mike >> >> From nobody Wed Aug 25 16:21:41 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B83E43A1178 for ; Wed, 25 Aug 2021 16:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, 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 ZqYkESAwkeDH for ; Wed, 25 Aug 2021 16:21:35 -0700 (PDT) Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) (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 A823E3A1174 for ; Wed, 25 Aug 2021 16:21:35 -0700 (PDT) Received: by mail-pl1-x62e.google.com with SMTP id u15so507360plg.13 for ; Wed, 25 Aug 2021 16:21:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=82DTAEPqw9rCcvRMftNRMWeWXBDTybNXeCZyjSd9pWU=; b=rU/EZ3TFsrzerXr4+KhKyqOf/+JEALPkI8ETkVWsY52HYtjSz/sL1fRe28iAN5gJi5 R+9xnEO0S9u0QKQnlz3NyPD9PEguvJ4iAZK94lEntGxzX4LpUwARKwUWKf4mxyiJ31te Jd+2BPVR8VYGIczF/eeWRdK2rdllioLPyC6Li62bwpa3r0LvxttxFUuQtvv0MRprHukQ riZFyahjrU8XCdK4PGy694vJPWWlE4mg35zm8QZ2W23df4PY6JvXAdoX59silTDaHpxL wG9YrTICXSDg53P4PKNpF2emxs29Ri9r/dml1lMgnZ/Sl4xSWTjUrv3hr/nALFTBaOhg yYDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=82DTAEPqw9rCcvRMftNRMWeWXBDTybNXeCZyjSd9pWU=; b=poneU2xNA1QF+zRMeNLELTWo6yNpVu1RGmbkNPjnXsKPDAsEC4R3ZhmXg47yXmZV5v FcSn83FH6EIFDFUrKbSAzW69N9NGYBpJWAOs1DLQBVBQx+k2ugUfWxzEXd8jcLxIIER6 k0GCG8ZR1MxXPx2qGCFL4mLq+FDj2nY80yfvLdE5TK99BV/70wk0Gg+Y+tGi5Ctt6Rpo K77e2zRPWULIdR2ezieAn5CnFkgW8FP5mBxKVz9LBAQpVMU/uAPluxCoioZKITa21QNo Kta80lAIiUysZrXoKz6RbNeWQevA46trx7NQDPtS4XEXHXXabRYVv6G+95wcuaq4Sxgu WC8Q== X-Gm-Message-State: AOAM532s66QLkSKDqJnXpQ6WSHamLvoL5S0yOSFZ5s3FN4eQUF5ZOiwC Ol438KWDzIIrwbsholKGpRNHIT3WSdtlcg== X-Google-Smtp-Source: ABdhPJyaid7aDhxmau8G+ZmNsqulClK9yzi+Qo9fcTBBLEGBjk+YGgcZxFuJUx9S+vWB3fPj4eWhXQ== X-Received: by 2002:a17:90a:1a49:: with SMTP id 9mr4861471pjl.43.1629933693070; Wed, 25 Aug 2021 16:21:33 -0700 (PDT) Received: from ?IPv6:2406:e003:11d3:cf01:80b2:5c79:2266:e431? ([2406:e003:11d3:cf01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id c124sm699551pfc.216.2021.08.25.16.21.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 25 Aug 2021 16:21:32 -0700 (PDT) To: Michael StJohns Cc: rfced-future@iab.org References: <2B46402F-5268-46B7-890F-7C5CA159EF13@ietf.org> <25FCCF71-ED00-48CA-8A15-4BB63B632F73@kuehlewind.net> <9F88E9DAC50B257953403E71@PSB> <6c544af8-b60c-1f4a-8730-3c923196eab6@joelhalpern.com> <7ce1368a-7bd2-73e3-5410-0e951f40fa00@nthpermutation.com> <761bf2d8-759e-72e1-4c92-7419cea693bb@nthpermutation.com> <1148ee5c-11da-6979-1056-2d7464ade5af@gmail.com> <1af8e9db-5ea4-e002-bfe3-832d432fd34e@nthpermutation.com> <02e5c6a6-cb93-a2b2-8621-97a1389f17a7@gmail.com> <51221c6a-1adc-c32f-90d5-1d2d3d3852b4@nthpermutation.com> From: Brian E Carpenter Message-ID: Date: Thu, 26 Aug 2021 11:21:29 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <51221c6a-1adc-c32f-90d5-1d2d3d3852b4@nthpermutation.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2021 23:21:38 -0000 Front posting to say that I could in fact live either with Mike's text or with Eliot's as amended. I think that we are really trying to say the same thing and it's a question of which is clearest. Regards Brian On 26-Aug-21 11:10, Michael StJohns wrote: > On 8/25/2021 6:33 PM, Brian E Carpenter wrote: >> On 26-Aug-21 08:38, Michael StJohns wrote: >>> On 8/24/2021 11:15 PM, Brian E Carpenter wrote: >>>> Front posting for cause: >>>> >>>> I think Mike's concern about Eliot's text derives from the way it st= arts. >>>> So I'd suggest: >>> Hi Brian - >>> >>> If I thought that was the problem I would have provided changes to yo= ur >>> text rather than new text.=C2=A0 I'm too lazy to write if I don't hav= e to. >>> >>> WRT to your text, I really need it to not link the RPC with the >>> RSWG/RSAB and instead link it to the documents.=C2=A0 While this grou= p has >>> finally gotten the point that the RPC does not "report to" those grou= ps, >>> nor can those groups command the RPC, what I'm afraid of is 3-5 years= >>> down the road where someone uses the text to justify the RSWG giving >>> operational directions to the RPC. >>> >>> I also want to get the point made that the RPC works with the RSWG as=20 it >>> tries to form strategic policy and that the RSWG is the primary place= >>> for the RPC interaction rather than - as your text seems to imply - t= he >>> RPC is responsible for interacting with all comer directly on matters=20 of >>> strategy. >>> >>> None of the above is meant to imply that the RPC doesn't work with >>> authors on their documents - but that's not the thrust of the text yo= u >>> and Mirja crafted and I think is handled elsewhere?=C2=A0 If not, a s= imple >>> line that indicates that set of interactions would be useful. >>> >>> The RPC has both a role in the strategic process (e.g. sanity checks = on >>> whether things will work, or the costs of doing new things as specifi= ed >>> by the Editorial series - e.g. with the RSWG), and the tactical proce= ss >>> (publishing documents while adhering to the aforesaid Editorial serie= s >>> documents - with the RSCE and RSAB I would expect).=C2=A0 Those need = to >> be >>> teased apart and specified separately and the RPC interaction with th= e >>> community on strategy ideally given a single specified place to happe= n. >>> That will help both the LLC and RPC scope the tasking required to >>> support the strategic process. >>> >>> By the way - I'm not sure how you would have come to the conclusion y= ou >>> came given the text I wrote.=C2=A0 Could you explain how you got ther= e? >> Simply because the thrust of your text was to say that the line of >> command was policy --> IETF LLC --> RPC and Eliot's text seemed >> to dilute that. Whereas yours seemed to emphasise that and dilute >> the RPC's ability to interact widely with the community as well as >> with authors. (I don't dispute that RSWG is the *primary* place >> for such interaction.) >=20 > Actually, the line of authority is more generally: >=20 > Community -> RSWG -> RSAB ->=C2=A0 Editorial Series -> RPC and LLC -> R= PC.=C2=A0=C2=A0=20 > Both of the "->" indicators pointing to the RPC are constrained by the = > terms of the engagement agreement.=C2=A0=C2=A0 There's also=C2=A0=C2=A0=20 RSAB - advise when=20 > requested -> RPC. >=20 > I phrased it as I did because there's a large difference between an=20 > ability and a requirement.=C2=A0=C2=A0 The following has "They shall re= port ... to=20 > and consult with ... the broader community regarding...".=C2=A0=C2=A0 W= hich=20 > implies a requirement that RPC engages with the community on the=20 > strategic stuff outside of the RSWG.=C2=A0=C2=A0 Maybe I'm parsing this=20 too=20 > tightly, but the RSWG (and the RSWG mailing list for sure) is the place=20 > where the community gets to engage this process and specifying them as = > separate entities in this instance (not generally), muddies the water=20 > for this specific partner. >=20 > I guess I don't understand what RPC ability you think I removed?=C2=A0=C2= =A0 Maybe=20 > you could describe a scenario which is prohibited by my text? >=20 >> They shall report regularly to and >> consult with the RSAB, RSWG, and broader community regarding >> status of work undertaken and plans for work to be done, >> including timeline for implementation as well as any key >> risks they identify. >=20 > Then there is this clause: >=20 >> The LLC is requested to negotiate a task with the RPC that permits and=20 >> requires the RPC to collaborate in at least an advisory capacity in=20 >> the content creation of the Editorial series RFCs as they affect the=20 >> RPC and that collaboration is expected to be the main path for=20 >> community input into the RPC processes. >=20 > Which enhances the *ability* of the RPC to participate in the RFC serie= s=20 > process discussions as a partner rather than as a supplicant or=20 > afterthought. >=20 > Thanks for the response! Mike >=20 >=20 >> >> Brian >> >>> Thanks, Mike >>> >>> >=20 From nobody Wed Aug 25 17:13:55 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7003A1238 for ; Wed, 25 Aug 2021 17:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 d1ZCEJf9rWMl; Wed, 25 Aug 2021 17:13:47 -0700 (PDT) Received: from smtpclient.apple (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id E91833A1225; Wed, 25 Aug 2021 17:13:46 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: IETF Executive Director In-Reply-To: Date: Thu, 26 Aug 2021 12:13:43 +1200 Cc: Michael StJohns , rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <15252DEB-290D-4F4B-90E2-B188FFFBBFB5@ietf.org> References: <2B46402F-5268-46B7-890F-7C5CA159EF13@ietf.org> <25FCCF71-ED00-48CA-8A15-4BB63B632F73@kuehlewind.net> <9F88E9DAC50B257953403E71@PSB> <6c544af8-b60c-1f4a-8730-3c923196eab6@joelhalpern.com> <7ce1368a-7bd2-73e3-5410-0e951f40fa00@nthpermutation.com> <761bf2d8-759e-72e1-4c92-7419cea693bb@nthpermutation.com> <1148ee5c-11da-6979-1056-2d7464ade5af@gmail.com> <1af8e9db-5ea4-e002-bfe3-832d432fd34e@nthpermutation.com> <02e5c6a6-cb93-a2b2-8621-97a1389f17a7@gmail.com> <51221c6a-1adc-c32f-90d5-1d2d3d3852b4@nthpermutation.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2021 00:13:55 -0000 =46rom my reading of all of this, we are trying to encode the following = separate things but each set of suggested text so far only identifies a = subset of these: # externalities that affect the RPC - the RPC is *instructed by* RFCs (not the RSAB/RSWG) - the RPC is *advised by* the RSAB and has a duty to ask for that advice = under specific circumstances - the RPC is *contractually overseen by* the LLC to ensure that it = delivers # RPC behaviours - the RPC *participates* in the creation of new RFCs, at least in an = advisory capacity - the RPC *reports* to the community on its performance and plans - the RPC *consults* with the community on its plans - the RPC *negotiates* its resources with the LLC Perhaps if we could agree this list we could then turn it into text? Jay > On 26/08/2021, at 11:21 AM, Brian E Carpenter = wrote: >=20 > Front posting to say that I could in fact live either with Mike's text > or with Eliot's as amended. I think that we are really trying to say > the same thing and it's a question of which is clearest. >=20 > Regards > Brian >=20 > On 26-Aug-21 11:10, Michael StJohns wrote: >> On 8/25/2021 6:33 PM, Brian E Carpenter wrote: >>> On 26-Aug-21 08:38, Michael StJohns wrote: >>>> On 8/24/2021 11:15 PM, Brian E Carpenter wrote: >>>>> Front posting for cause: >>>>>=20 >>>>> I think Mike's concern about Eliot's text derives from the way it = starts. >>>>> So I'd suggest: >>>> Hi Brian - >>>>=20 >>>> If I thought that was the problem I would have provided changes to = your >>>> text rather than new text. I'm too lazy to write if I don't have = to. >>>>=20 >>>> WRT to your text, I really need it to not link the RPC with the >>>> RSWG/RSAB and instead link it to the documents. While this group = has >>>> finally gotten the point that the RPC does not "report to" those = groups, >>>> nor can those groups command the RPC, what I'm afraid of is 3-5 = years >>>> down the road where someone uses the text to justify the RSWG = giving >>>> operational directions to the RPC. >>>>=20 >>>> I also want to get the point made that the RPC works with the RSWG = as=20 > it >>>> tries to form strategic policy and that the RSWG is the primary = place >>>> for the RPC interaction rather than - as your text seems to imply - = the >>>> RPC is responsible for interacting with all comer directly on = matters=20 > of >>>> strategy. >>>>=20 >>>> None of the above is meant to imply that the RPC doesn't work with >>>> authors on their documents - but that's not the thrust of the text = you >>>> and Mirja crafted and I think is handled elsewhere? If not, a = simple >>>> line that indicates that set of interactions would be useful. >>>>=20 >>>> The RPC has both a role in the strategic process (e.g. sanity = checks on >>>> whether things will work, or the costs of doing new things as = specified >>>> by the Editorial series - e.g. with the RSWG), and the tactical = process >>>> (publishing documents while adhering to the aforesaid Editorial = series >>>> documents - with the RSCE and RSAB I would expect). Those need to >>> be >>>> teased apart and specified separately and the RPC interaction with = the >>>> community on strategy ideally given a single specified place to = happen. >>>> That will help both the LLC and RPC scope the tasking required to >>>> support the strategic process. >>>>=20 >>>> By the way - I'm not sure how you would have come to the conclusion = you >>>> came given the text I wrote. Could you explain how you got there? >>> Simply because the thrust of your text was to say that the line of >>> command was policy --> IETF LLC --> RPC and Eliot's text seemed >>> to dilute that. Whereas yours seemed to emphasise that and dilute >>> the RPC's ability to interact widely with the community as well as >>> with authors. (I don't dispute that RSWG is the *primary* place >>> for such interaction.) >>=20 >> Actually, the line of authority is more generally: >>=20 >> Community -> RSWG -> RSAB -> Editorial Series -> RPC and LLC -> RPC. = =20 >> Both of the "->" indicators pointing to the RPC are constrained by = the=20 >> terms of the engagement agreement. There's also =20 > RSAB - advise when=20 >> requested -> RPC. >>=20 >> I phrased it as I did because there's a large difference between an=20= >> ability and a requirement. The following has "They shall report ... = to=20 >> and consult with ... the broader community regarding...". Which=20 >> implies a requirement that RPC engages with the community on the=20 >> strategic stuff outside of the RSWG. Maybe I'm parsing this=20 > too=20 >> tightly, but the RSWG (and the RSWG mailing list for sure) is the = place=20 >=20 >> where the community gets to engage this process and specifying them = as=20 >> separate entities in this instance (not generally), muddies the water=20= >> for this specific partner. >>=20 >> I guess I don't understand what RPC ability you think I removed? = Maybe=20 >> you could describe a scenario which is prohibited by my text? >>=20 >>> They shall report regularly to and >>> consult with the RSAB, RSWG, and broader community regarding >>> status of work undertaken and plans for work to be done, >>> including timeline for implementation as well as any key >>> risks they identify. >>=20 >> Then there is this clause: >>=20 >>> The LLC is requested to negotiate a task with the RPC that permits = and=20 >=20 >>> requires the RPC to collaborate in at least an advisory capacity in=20= >>> the content creation of the Editorial series RFCs as they affect the=20= >>> RPC and that collaboration is expected to be the main path for=20 >>> community input into the RPC processes. >>=20 >> Which enhances the *ability* of the RPC to participate in the RFC = series=20 >> process discussions as a partner rather than as a supplicant or=20 >> afterthought. >>=20 >> Thanks for the response! Mike >>=20 >>=20 >>>=20 >>> Brian >>>=20 >>>> Thanks, Mike >>>>=20 >>>>=20 >>=20 >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future --=20 Jay Daley IETF Executive Director exec-director@ietf.org From nobody Wed Aug 25 18:31:13 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA0393A0DA2 for ; Wed, 25 Aug 2021 18:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 WW0rmkiuUOk7 for ; Wed, 25 Aug 2021 18:31:06 -0700 (PDT) Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (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 138C93A0D9C for ; Wed, 25 Aug 2021 18:31:05 -0700 (PDT) Received: by mail-il1-x135.google.com with SMTP id z2so1661163iln.0 for ; Wed, 25 Aug 2021 18:31:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=cLSp9ezfmf6cWD39Rt+OfigM3d8dEuNgRf1npSzQBtw=; b=YWX7KMhd9y2gqWIU5eJrTId3n18EX3qKnJabJLVMXwdX2TypIlrB17XPIgwMlp5eTG FdMtJzRVEwVrJUO9o9RuqBS16YH9LwxDxXyRTV/KI7jHbt5CvFs6i6tB8SCbGqs1dX84 Y1RTx+hUB0AEBOe4ja9EBOXci+XbKxLfHB/yE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=cLSp9ezfmf6cWD39Rt+OfigM3d8dEuNgRf1npSzQBtw=; b=W1nYZjusgVThVZU3YGiy4t8L6SBAY10QA0q4+2MzdQ56sqeVMXXbUEPCJYkrIvr/Sz irrj4YqgsvylkrNWDnsYmSf/VICZ6FATijjuwFlAO29ksTBhLJjeHW2WiMR6NJ+hEjM/ M/fNGlLbBTEJeDLQSnCgqJUW+83p5z0A9VrM25cdDjRPfa7quNT4OuXg4mHqeiBCtuT5 W/WQdXvlH0Vcw8eGaCPSHKjkOgY9qZR1+aAl4jiWmATiKmafKCdnvVmwmaAEuvHKOkxk PRjDOzB4D69+QdljrHTLhNsKY509TBIta2Jwbdihh1iYPuIYScfL/01uQye2Ngw+7iq5 xk+g== X-Gm-Message-State: AOAM5318pU5rz/EkLGbUwNkN4kY49FI1INOJsNwVqNNizdAjpN5dyoxd Xd+pCT/5kOwWJKUxNF5Wa2IIEhoBchW2kA== X-Google-Smtp-Source: ABdhPJxWH5XZIvEiFKNS68GLL+ynAkb1zNi1Uw4nsegf4TY5Bf4Uw435/1tyksy2vyXPC8ryAJHAvw== X-Received: by 2002:a92:c609:: with SMTP id p9mr850637ilm.135.1629941464245; Wed, 25 Aug 2021 18:31:04 -0700 (PDT) Received: from dragon.local (c-73-78-113-156.hsd1.co.comcast.net. [73.78.113.156]) by smtp.gmail.com with ESMTPSA id f9sm952563ilk.56.2021.08.25.18.31.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 25 Aug 2021 18:31:03 -0700 (PDT) To: "rfced-future@iab.org" From: Peter Saint-Andre Message-ID: <667f4a94-ab2a-b97d-f961-243e383d46a8@mozilla.com> Date: Wed, 25 Aug 2021 19:31:01 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Rfced-future] -01 draft X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2021 01:31:11 -0000 Hi all, My apologies for the late notice, but I've just uploaded version -01 of the program draft: https://datatracker.ietf.org/doc/html/draft-iab-rfcefdp-rfced-model-01 This should enable us to close some issues. I shall post -02 much farther in advance of the next meeting. Peter From nobody Wed Aug 25 20:24:27 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BED533A1184 for ; Wed, 25 Aug 2021 20:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 1vudJXOK8sHZ for ; Wed, 25 Aug 2021 20:24:20 -0700 (PDT) Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 E80B73A1181 for ; Wed, 25 Aug 2021 20:24:19 -0700 (PDT) Received: by mail-pg1-x52f.google.com with SMTP id 17so1882031pgp.4 for ; Wed, 25 Aug 2021 20:24:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=WuY8f4GjuLUxT5NAeVJa+O3/ahFQvr1bNmVI/smaS9w=; b=FWPLz2dgNfLDSsKtSeVgskzRj47VUdgPLv6+wLLPTmNE5zfd4E+AaydGU0dZnnnaDV 9OurOj6hHNge9V8dkGDeUZ7miDI3oM3RYF92OFO9VT0vcbazURUC5Cg7nexR8Mp5f3Ro OWQiYf3yChda6Mt6n5hSdIqQqq+QcE3X5FX/ewivA2alXyNd7+jjoQLtQN8rKcPwPrxi 3qo6AeLfoPhS7ZZb566o9qo/Uk+Uep1UTLhTcXTS5CCoSpY8i7iblHnt5MlucneIgCDO 5RSXuQZgTwxLkNEZwB6hmTw4zl2br7Ay1k2EsIdQnuVg13gk7mIJY0ztVoR5coi+cLVt g/NA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=WuY8f4GjuLUxT5NAeVJa+O3/ahFQvr1bNmVI/smaS9w=; b=W+QYosVROVBsWDY1HC8Jq97pNj8bAYqkTgxh+/3w7YLq+q+BNABr0Q8YV+9Ch94MJ2 rTziVtYi1T8CDugHVzmQDKVITKnuNmTGorEUOkHWlUwvGqbLq7g/tjvJVn4R54oEwgpY AJJaKYNwpPNX1aZnT9p8zcEJcziFqFotAWA+BwBpKSlNkpKR2kReCJ95HFLci1Qz7sp9 4SFWaft6CThCQHYrh3D4TDT+ysD4n8V122C77yacSSPc+VEIPOIXD4ivCpCznITkrCY6 8ngKYTQvz55O8wXIvl6nDdjxDn+pZe6Q6Kf50SzD4UazoAGubR8Ah6AhYAAsE2v0nY4Q jDPw== X-Gm-Message-State: AOAM530Da1jDlVZ7Z87LgytLemlFcfZiUmkZVrILJYwQ8Saheup5Tciq ckj79KfjwU2BEwycNoPArG9hDoWAKwVCig== X-Google-Smtp-Source: ABdhPJyyMIaft1lvhvhI2RdJKW2OWSlSJp0wctdAi7v2rJ6VTfXM6F6CdKWxUbCCIytKNMU5bniNEQ== X-Received: by 2002:a05:6a00:a85:b0:3eb:1934:de53 with SMTP id b5-20020a056a000a8500b003eb1934de53mr1494606pfl.71.1629948257656; Wed, 25 Aug 2021 20:24:17 -0700 (PDT) Received: from ?IPv6:2406:e003:11d3:cf01:80b2:5c79:2266:e431? ([2406:e003:11d3:cf01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id d22sm1331335pgi.73.2021.08.25.20.24.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 25 Aug 2021 20:24:17 -0700 (PDT) To: IETF Executive Director Cc: Michael StJohns , rfced-future@iab.org References: <2B46402F-5268-46B7-890F-7C5CA159EF13@ietf.org> <25FCCF71-ED00-48CA-8A15-4BB63B632F73@kuehlewind.net> <9F88E9DAC50B257953403E71@PSB> <6c544af8-b60c-1f4a-8730-3c923196eab6@joelhalpern.com> <7ce1368a-7bd2-73e3-5410-0e951f40fa00@nthpermutation.com> <761bf2d8-759e-72e1-4c92-7419cea693bb@nthpermutation.com> <1148ee5c-11da-6979-1056-2d7464ade5af@gmail.com> <1af8e9db-5ea4-e002-bfe3-832d432fd34e@nthpermutation.com> <02e5c6a6-cb93-a2b2-8621-97a1389f17a7@gmail.com> <51221c6a-1adc-c32f-90d5-1d2d3d3852b4@nthpermutation.com> <15252DEB-290D-4F4B-90E2-B188FFFBBFB5@ietf.org> From: Brian E Carpenter Message-ID: Date: Thu, 26 Aug 2021 15:24:13 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <15252DEB-290D-4F4B-90E2-B188FFFBBFB5@ietf.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2021 03:24:25 -0000 Good analysis. Regards Brian On 26-Aug-21 12:13, IETF Executive Director wrote: > From my reading of all of this, we are trying to encode the following separate things but each set of suggested text so far only identifies a subset of these: > > # externalities that affect the RPC > > - the RPC is *instructed by* RFCs (not the RSAB/RSWG) > > - the RPC is *advised by* the RSAB and has a duty to ask for that advice under specific circumstances > > - the RPC is *contractually overseen by* the LLC to ensure that it delivers > > > # RPC behaviours > > - the RPC *participates* in the creation of new RFCs, at least in an advisory capacity > > - the RPC *reports* to the community on its performance and plans > > - the RPC *consults* with the community on its plans > > - the RPC *negotiates* its resources with the LLC > > > Perhaps if we could agree this list we could then turn it into text? > > Jay > > >> On 26/08/2021, at 11:21 AM, Brian E Carpenter wrote: >> >> Front posting to say that I could in fact live either with Mike's text >> or with Eliot's as amended. I think that we are really trying to say >> the same thing and it's a question of which is clearest. >> >> Regards >> Brian >> >> On 26-Aug-21 11:10, Michael StJohns wrote: >>> On 8/25/2021 6:33 PM, Brian E Carpenter wrote: >>>> On 26-Aug-21 08:38, Michael StJohns wrote: >>>>> On 8/24/2021 11:15 PM, Brian E Carpenter wrote: >>>>>> Front posting for cause: >>>>>> >>>>>> I think Mike's concern about Eliot's text derives from the way it starts. >>>>>> So I'd suggest: >>>>> Hi Brian - >>>>> >>>>> If I thought that was the problem I would have provided changes to your >>>>> text rather than new text. I'm too lazy to write if I don't have to. >>>>> >>>>> WRT to your text, I really need it to not link the RPC with the >>>>> RSWG/RSAB and instead link it to the documents. While this group has >>>>> finally gotten the point that the RPC does not "report to" those groups, >>>>> nor can those groups command the RPC, what I'm afraid of is 3-5 years >>>>> down the road where someone uses the text to justify the RSWG giving >>>>> operational directions to the RPC. >>>>> >>>>> I also want to get the point made that the RPC works with the RSWG as >> it >>>>> tries to form strategic policy and that the RSWG is the primary place >>>>> for the RPC interaction rather than - as your text seems to imply - the >>>>> RPC is responsible for interacting with all comer directly on matters >> of >>>>> strategy. >>>>> >>>>> None of the above is meant to imply that the RPC doesn't work with >>>>> authors on their documents - but that's not the thrust of the text you >>>>> and Mirja crafted and I think is handled elsewhere? If not, a simple >>>>> line that indicates that set of interactions would be useful. >>>>> >>>>> The RPC has both a role in the strategic process (e.g. sanity checks on >>>>> whether things will work, or the costs of doing new things as specified >>>>> by the Editorial series - e.g. with the RSWG), and the tactical process >>>>> (publishing documents while adhering to the aforesaid Editorial series >>>>> documents - with the RSCE and RSAB I would expect). Those need to >>>> be >>>>> teased apart and specified separately and the RPC interaction with the >>>>> community on strategy ideally given a single specified place to happen. >>>>> That will help both the LLC and RPC scope the tasking required to >>>>> support the strategic process. >>>>> >>>>> By the way - I'm not sure how you would have come to the conclusion you >>>>> came given the text I wrote. Could you explain how you got there? >>>> Simply because the thrust of your text was to say that the line of >>>> command was policy --> IETF LLC --> RPC and Eliot's text seemed >>>> to dilute that. Whereas yours seemed to emphasise that and dilute >>>> the RPC's ability to interact widely with the community as well as >>>> with authors. (I don't dispute that RSWG is the *primary* place >>>> for such interaction.) >>> >>> Actually, the line of authority is more generally: >>> >>> Community -> RSWG -> RSAB -> Editorial Series -> RPC and LLC -> RPC. >>> Both of the "->" indicators pointing to the RPC are constrained by the >>> terms of the engagement agreement. There's also >> RSAB - advise when >>> requested -> RPC. >>> >>> I phrased it as I did because there's a large difference between an >>> ability and a requirement. The following has "They shall report ... to >>> and consult with ... the broader community regarding...". Which >>> implies a requirement that RPC engages with the community on the >>> strategic stuff outside of the RSWG. Maybe I'm parsing this >> too >>> tightly, but the RSWG (and the RSWG mailing list for sure) is the place >> >>> where the community gets to engage this process and specifying them as >>> separate entities in this instance (not generally), muddies the water >>> for this specific partner. >>> >>> I guess I don't understand what RPC ability you think I removed? Maybe >>> you could describe a scenario which is prohibited by my text? >>> >>>> They shall report regularly to and >>>> consult with the RSAB, RSWG, and broader community regarding >>>> status of work undertaken and plans for work to be done, >>>> including timeline for implementation as well as any key >>>> risks they identify. >>> >>> Then there is this clause: >>> >>>> The LLC is requested to negotiate a task with the RPC that permits and >> >>>> requires the RPC to collaborate in at least an advisory capacity in >>>> the content creation of the Editorial series RFCs as they affect the >>>> RPC and that collaboration is expected to be the main path for >>>> community input into the RPC processes. >>> >>> Which enhances the *ability* of the RPC to participate in the RFC series >>> process discussions as a partner rather than as a supplicant or >>> afterthought. >>> >>> Thanks for the response! Mike >>> >>> >>>> >>>> Brian >>>> >>>>> Thanks, Mike >>>>> >>>>> >>> >> >> -- >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future > From nobody Wed Aug 25 21:10:34 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C09963A13BC for ; Wed, 25 Aug 2021 21:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 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, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch 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 zhQf-TCVv_38 for ; Wed, 25 Aug 2021 21:10:27 -0700 (PDT) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9702A3A13B6 for ; Wed, 25 Aug 2021 21:10:25 -0700 (PDT) Received: from [IPv6:2001:420:c0c0:1011::1] ([IPv6:2001:420:c0c0:1011:0:0:0:1]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 17Q4ABeq234819 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Thu, 26 Aug 2021 06:10:21 +0200 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1629951021; bh=7SF6H7AwRHqWHS8iII7aJjV3Js5WQEY9efXDiZdVVNg=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=TbBnX5GB6r35BzarL00qwV3J6pglzx6vEpxh7ya7EDe2AyB1j59VCno/dIyVyhwSD E8Gk+Tfvu3FpaksrnZoNIsNH3ZIntvOfOGZDnroeY2t6ewi8bmpn63yuYVtkTPZF/P WqG7MX4nhYo7041x/bjgYPxY4KgeLtBNR9RdpG9I= To: Peter Saint-Andre References: <667f4a94-ab2a-b97d-f961-243e383d46a8@mozilla.com> Cc: "rfced-future@iab.org" From: Eliot Lear Message-ID: <53d3839d-0a7d-df14-9050-d758ed867ead@lear.ch> Date: Thu, 26 Aug 2021 06:10:04 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <667f4a94-ab2a-b97d-f961-243e383d46a8@mozilla.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="34fevv49KEf4sA7pJyQnDhs3HbPewNTOd" Archived-At: Subject: Re: [Rfced-future] -01 draft X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2021 04:10:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --34fevv49KEf4sA7pJyQnDhs3HbPewNTOd Content-Type: multipart/mixed; boundary="h33mVdVwE4fpXRGtd3w34JpqLwIR7fDTX"; protected-headers="v1" From: Eliot Lear To: Peter Saint-Andre Cc: "rfced-future@iab.org" Message-ID: <53d3839d-0a7d-df14-9050-d758ed867ead@lear.ch> Subject: Re: [Rfced-future] -01 draft References: <667f4a94-ab2a-b97d-f961-243e383d46a8@mozilla.com> In-Reply-To: <667f4a94-ab2a-b97d-f961-243e383d46a8@mozilla.com> --h33mVdVwE4fpXRGtd3w34JpqLwIR7fDTX Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Thanks for this, Peter! On 26.08.21 03:31, Peter Saint-Andre wrote: > Hi all, > > My apologies for the late notice, but I've just uploaded version -01 of= > the program draft: > > https://datatracker.ietf.org/doc/html/draft-iab-rfcefdp-rfced-model-01 > > This should enable us to close some issues. I shall post -02 much > farther in advance of the next meeting. > > Peter > --h33mVdVwE4fpXRGtd3w34JpqLwIR7fDTX-- --34fevv49KEf4sA7pJyQnDhs3HbPewNTOd Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmEnFBwFAwAAAAAACgkQh7ZrRtnSejOp iQf+K/PO3dnw6Aytp68VvGBOH1bp4pM45G2aBUyt2XZGiWWhueg+pMAxiS40gxuwYWnPyY5tvakq vWSHpGVyWbkbBLt7ZoZz4tVhcF+bNhUBF2lKzumuyGfbuK5ha6zJVwCucua708V6aSl+V9kNkuWR F3FWhaQLMDEWN4rIqXR5uxkcXBsEeEQzXDF0ACW96pfiVTq22TzMmQY2rkjSAhZ127y3lEjOFblQ Zh2Qedy3LGawakO74ELDFEuJNnJZwmR/BmDzncU635n31vEcPiTwp9pZokUKKH/VL80zIF6BujV/ GR0CYPJL0TSJexDPqVTN0OrpgQBWeHiu+WDh4YQtxw== =qYYQ -----END PGP SIGNATURE----- --34fevv49KEf4sA7pJyQnDhs3HbPewNTOd-- From nobody Wed Aug 25 21:34:34 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B96C3A14AE; Wed, 25 Aug 2021 21:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.879 X-Spam-Level: X-Spam-Status: No, score=-0.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=lear.ch 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 5YQ2J1dyp80j; Wed, 25 Aug 2021 21:34:25 -0700 (PDT) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9BA93A14AD; Wed, 25 Aug 2021 21:34:24 -0700 (PDT) Received: from [IPv6:2001:420:c0c0:1011::1] ([IPv6:2001:420:c0c0:1011:0:0:0:1]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 17Q4YIDG235528 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Thu, 26 Aug 2021 06:34:19 +0200 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1629952460; bh=LcqlUJtSyVSi/CSrk/5w1dNS4x7SXG80w6t9BOMXyCk=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=VPpXD4ZvdG2LL6mm00qlKtkgMCOwBFMnhvOGy9nyEPLyVNViAWPZT8YJmvmzZP9J6 8lnTKo65n3cvXt8lXV9KA9HcmePLXiAoxMgnQrvZIWYwGWSxQ/GQQloD1Fs8OvqJos 4bN+RReB8Jze2oHiad4liKdPNWHHniA/4TKFZKqM= To: IETF Executive Director , Brian E Carpenter Cc: rfced-future@iab.org, Michael StJohns References: <2B46402F-5268-46B7-890F-7C5CA159EF13@ietf.org> <25FCCF71-ED00-48CA-8A15-4BB63B632F73@kuehlewind.net> <9F88E9DAC50B257953403E71@PSB> <6c544af8-b60c-1f4a-8730-3c923196eab6@joelhalpern.com> <7ce1368a-7bd2-73e3-5410-0e951f40fa00@nthpermutation.com> <761bf2d8-759e-72e1-4c92-7419cea693bb@nthpermutation.com> <1148ee5c-11da-6979-1056-2d7464ade5af@gmail.com> <1af8e9db-5ea4-e002-bfe3-832d432fd34e@nthpermutation.com> <02e5c6a6-cb93-a2b2-8621-97a1389f17a7@gmail.com> <51221c6a-1adc-c32f-90d5-1d2d3d3852b4@nthpermutation.com> <15252DEB-290D-4F4B-90E2-B188FFFBBFB5@ietf.org> From: Eliot Lear Message-ID: <41ce9265-4226-114a-768c-ddd06ff0c102@lear.ch> Date: Thu, 26 Aug 2021 06:34:18 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <15252DEB-290D-4F4B-90E2-B188FFFBBFB5@ietf.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="eOC9xpdyWIyZOfuZS7t7mikwCzhVatSDo" Archived-At: Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2021 04:34:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --eOC9xpdyWIyZOfuZS7t7mikwCzhVatSDo Content-Type: multipart/mixed; boundary="40mo5B6LiTMJl0Eg4XEhXA5r6V7GsOdZv"; protected-headers="v1" From: Eliot Lear To: IETF Executive Director , Brian E Carpenter Cc: rfced-future@iab.org, Michael StJohns Message-ID: <41ce9265-4226-114a-768c-ddd06ff0c102@lear.ch> Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 References: <2B46402F-5268-46B7-890F-7C5CA159EF13@ietf.org> <25FCCF71-ED00-48CA-8A15-4BB63B632F73@kuehlewind.net> <9F88E9DAC50B257953403E71@PSB> <6c544af8-b60c-1f4a-8730-3c923196eab6@joelhalpern.com> <7ce1368a-7bd2-73e3-5410-0e951f40fa00@nthpermutation.com> <761bf2d8-759e-72e1-4c92-7419cea693bb@nthpermutation.com> <1148ee5c-11da-6979-1056-2d7464ade5af@gmail.com> <1af8e9db-5ea4-e002-bfe3-832d432fd34e@nthpermutation.com> <02e5c6a6-cb93-a2b2-8621-97a1389f17a7@gmail.com> <51221c6a-1adc-c32f-90d5-1d2d3d3852b4@nthpermutation.com> <15252DEB-290D-4F4B-90E2-B188FFFBBFB5@ietf.org> In-Reply-To: <15252DEB-290D-4F4B-90E2-B188FFFBBFB5@ietf.org> --40mo5B6LiTMJl0Eg4XEhXA5r6V7GsOdZv Content-Type: multipart/alternative; boundary="------------243F7A7E6A246E91C89C519D" Content-Language: en-US This is a multi-part message in MIME format. --------------243F7A7E6A246E91C89C519D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Thanks, Jay.=C2=A0 I'll add that I have no particular allegiance to the t= ext=20 that Brian called "Eliot's text." What I do think is important is that we level the text correctly.=C2=A0 T= hat=20 means addressing sufficient detail so that everyone is clear on roles=20 and general responsibilities, but stopping at the point where the detail = does not add normative value or overly constrains the role. There is, I think, some art to that; which is why we may be struggling a = bit on which wording we like.=C2=A0 On the call, it may be useful to star= t=20 with Jay's text below to see if the principles are agreeable, and then=20 see how we proceed on text.=C2=A0 We can live edit a bit, but only if we = can=20 reasonably agree on a starting point to see how we cover those principles= =2E Eliot On 26.08.21 02:13, IETF Executive Director wrote: > From my reading of all of this, we are trying to encode the following = separate things but each set of suggested text so far only identifies a s= ubset of these: > > # externalities that affect the RPC > > - the RPC is *instructed by* RFCs (not the RSAB/RSWG) > > - the RPC is *advised by* the RSAB and has a duty to ask for that advic= e under specific circumstances > > - the RPC is *contractually overseen by* the LLC to ensure that it deli= vers > > > # RPC behaviours > > - the RPC *participates* in the creation of new RFCs, at least in an ad= visory capacity > > - the RPC *reports* to the community on its performance and plans > > - the RPC *consults* with the community on its plans > > - the RPC *negotiates* its resources with the LLC > > > Perhaps if we could agree this list we could then turn it into text? > > Jay > > >> On 26/08/2021, at 11:21 AM, Brian E Carpenter wrote: >> >> Front posting to say that I could in fact live either with Mike's text= >> or with Eliot's as amended. I think that we are really trying to say >> the same thing and it's a question of which is clearest. >> >> Regards >> Brian >> >> On 26-Aug-21 11:10, Michael StJohns wrote: >>> On 8/25/2021 6:33 PM, Brian E Carpenter wrote: >>>> On 26-Aug-21 08:38, Michael StJohns wrote: >>>>> On 8/24/2021 11:15 PM, Brian E Carpenter wrote: >>>>>> Front posting for cause: >>>>>> >>>>>> I think Mike's concern about Eliot's text derives from the way it = starts. >>>>>> So I'd suggest: >>>>> Hi Brian - >>>>> >>>>> If I thought that was the problem I would have provided changes to = your >>>>> text rather than new text. I'm too lazy to write if I don't have t= o. >>>>> >>>>> WRT to your text, I really need it to not link the RPC with the >>>>> RSWG/RSAB and instead link it to the documents. While this group h= as >>>>> finally gotten the point that the RPC does not "report to" those gr= oups, >>>>> nor can those groups command the RPC, what I'm afraid of is 3-5 yea= rs >>>>> down the road where someone uses the text to justify the RSWG givin= g >>>>> operational directions to the RPC. >>>>> >>>>> I also want to get the point made that the RPC works with the RSWG = as >> it >>>>> tries to form strategic policy and that the RSWG is the primary pla= ce >>>>> for the RPC interaction rather than - as your text seems to imply -= the >>>>> RPC is responsible for interacting with all comer directly on matte= rs >> of >>>>> strategy. >>>>> >>>>> None of the above is meant to imply that the RPC doesn't work with >>>>> authors on their documents - but that's not the thrust of the text = you >>>>> and Mirja crafted and I think is handled elsewhere? If not, a simp= le >>>>> line that indicates that set of interactions would be useful. >>>>> >>>>> The RPC has both a role in the strategic process (e.g. sanity check= s on >>>>> whether things will work, or the costs of doing new things as speci= fied >>>>> by the Editorial series - e.g. with the RSWG), and the tactical pro= cess >>>>> (publishing documents while adhering to the aforesaid Editorial ser= ies >>>>> documents - with the RSCE and RSAB I would expect). Those need to >>>> be >>>>> teased apart and specified separately and the RPC interaction with = the >>>>> community on strategy ideally given a single specified place to hap= pen. >>>>> That will help both the LLC and RPC scope the tasking required to >>>>> support the strategic process. >>>>> >>>>> By the way - I'm not sure how you would have come to the conclusion= you >>>>> came given the text I wrote. Could you explain how you got there? >>>> Simply because the thrust of your text was to say that the line of >>>> command was policy --> IETF LLC --> RPC and Eliot's text seemed >>>> to dilute that. Whereas yours seemed to emphasise that and dilute >>>> the RPC's ability to interact widely with the community as well as >>>> with authors. (I don't dispute that RSWG is the *primary* place >>>> for such interaction.) >>> Actually, the line of authority is more generally: >>> >>> Community -> RSWG -> RSAB -> Editorial Series -> RPC and LLC -> RPC.= >>> Both of the "->" indicators pointing to the RPC are constrained by th= e >>> terms of the engagement agreement. There's also >> RSAB - advise when >>> requested -> RPC. >>> >>> I phrased it as I did because there's a large difference between an >>> ability and a requirement. The following has "They shall report ...= to >>> and consult with ... the broader community regarding...". Which >>> implies a requirement that RPC engages with the community on the >>> strategic stuff outside of the RSWG. Maybe I'm parsing this >> too >>> tightly, but the RSWG (and the RSWG mailing list for sure) is the pla= ce >>> where the community gets to engage this process and specifying them a= s >>> separate entities in this instance (not generally), muddies the water= >>> for this specific partner. >>> >>> I guess I don't understand what RPC ability you think I removed? Ma= ybe >>> you could describe a scenario which is prohibited by my text? >>> >>>> They shall report regularly to and >>>> consult with the RSAB, RSWG, and broader community regarding >>>> status of work undertaken and plans for work to be done, >>>> including timeline for implementation as well as any key >>>> risks they identify. >>> Then there is this clause: >>> >>>> The LLC is requested to negotiate a task with the RPC that permits a= nd >>>> requires the RPC to collaborate in at least an advisory capacity in >>>> the content creation of the Editorial series RFCs as they affect the= >>>> RPC and that collaboration is expected to be the main path for >>>> community input into the RPC processes. >>> Which enhances the *ability* of the RPC to participate in the RFC ser= ies >>> process discussions as a partner rather than as a supplicant or >>> afterthought. >>> >>> Thanks for the response! Mike >>> >>> >>>> Brian >>>> >>>>> Thanks, Mike >>>>> >>>>> >> --=20 >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future --------------243F7A7E6A246E91C89C519D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Thanks, Jay.=C2=A0 I'll add that I have no particular allegiance t= o the text that Brian called "Eliot's text."=C2=A0

What I do think is important is that we level the text correctly.=C2=A0 That means addressing sufficient detail so that everyone is clear on roles and general responsibilities, but stopping at the point where the detail does not add normative value or overly constrains the role.

There is, I think, some art to that; which is why we may be struggling a bit on which wording we like.=C2=A0 On the call, it ma= y be useful to start with Jay's text below to see if the principles are agreeable, and then see how we proceed on text.=C2=A0 We can live e= dit a bit, but only if we can reasonably agree on a starting point to see how we cover those principles.

Eliot

On 26.08.21 02:13, IETF Executive Director wrote:
From my reading of all of th=
is, we are trying to encode the following separate things but each set of=
 suggested text so far only identifies a subset of these:

# externalities that affect the RPC

- the RPC is *instructed by* RFCs (not the RSAB/RSWG)

- the RPC is *advised by* the RSAB and has a duty to ask for that advice =
under specific circumstances

- the RPC is *contractually overseen by* the LLC to ensure that it delive=
rs


# RPC behaviours

- the RPC *participates* in the creation of new RFCs, at least in an advi=
sory capacity

- the RPC *reports* to the community on its performance and plans

- the RPC *consults* with the community on its plans

- the RPC *negotiates* its resources with the LLC


Perhaps if we could agree this list we could then turn it into text?

Jay



On 26/08/2021, at 11:21 AM=
, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

Front posting to say that I could in fact live either with Mike's text
or with Eliot's as amended. I think that we are really trying to say
the same thing and it's a question of which is clearest.

Regards
  Brian

On 26-Aug-21 11:10, Michael StJohns wrote:

On 8/25/2021 6:33 PM, Br=
ian E Carpenter wrote:

On 26-Aug-21 08:38, Mi=
chael StJohns wrote:

On 8/24/2021 11:15 P=
M, Brian E Carpenter wrote:

Front posting for =
cause:

I think Mike's concern about Eliot's text derives from the way it starts.=

So I'd suggest:

Hi Brian -

If I thought that was the problem I would have provided changes to your
text rather than new text.  I'm too lazy to write if I don't have to.

WRT to your text, I really need it to not link the RPC with the
RSWG/RSAB and instead link it to the documents.  While this group has
finally gotten the point that the RPC does not "report to" those groups,
nor can those groups command the RPC, what I'm afraid of is 3-5 years
down the road where someone uses the text to justify the RSWG giving
operational directions to the RPC.

I also want to get the point made that the RPC works with the RSWG as=20

it

tries to form strate=
gic policy and that the RSWG is the primary place
for the RPC interaction rather than - as your text seems to imply - the
RPC is responsible for interacting with all comer directly on matters=20

of

strategy.

None of the above is meant to imply that the RPC doesn't work with
authors on their documents - but that's not the thrust of the text you
and Mirja crafted and I think is handled elsewhere?  If not, a simple
line that indicates that set of interactions would be useful.

The RPC has both a role in the strategic process (e.g. sanity checks on
whether things will work, or the costs of doing new things as specified
by the Editorial series - e.g. with the RSWG), and the tactical process
(publishing documents while adhering to the aforesaid Editorial series
documents - with the RSCE and RSAB I would expect).  Those need to

be

teased apart and spe=
cified separately and the RPC interaction with the
community on strategy ideally given a single specified place to happen.
That will help both the LLC and RPC scope the tasking required to
support the strategic process.

By the way - I'm not sure how you would have come to the conclusion you
came given the text I wrote.  Could you explain how you got there?

Simply because the thr=
ust of your text was to say that the line of
command was policy --> IETF LLC --> RPC and Eliot's text seemed
to dilute that. Whereas yours seemed to emphasise that and dilute
the RPC's ability to interact widely with the community as well as
with authors. (I don't dispute that RSWG is the *primary* place
for such interaction.)

Actually, the line of authority is more generally:

Community -> RSWG -> RSAB ->  Editorial Series -> RPC and LLC=
 -> RPC.  =20
Both of the "->" indicators pointing to the RPC are constrained by the=
=20
terms of the engagement agreement.   There's also  =20

RSAB - advise when=20

requested -> RPC.

I phrased it as I did because there's a large difference between an=20
ability and a requirement.   The following has "They shall report ... to =

and consult with ... the broader community regarding...".   Which=20
implies a requirement that RPC engages with the community on the=20
strategic stuff outside of the RSWG.   Maybe I'm parsing this=20

too=20

tightly, but the RSWG (a=
nd the RSWG mailing list for sure) is the place=20


        

          
where the community gets=
 to engage this process and specifying them as=20
separate entities in this instance (not generally), muddies the water=20
for this specific partner.

I guess I don't understand what RPC ability you think I removed?   Maybe =

you could describe a scenario which is prohibited by my text?



          

            
They shall report regu=
larly to and
consult with the RSAB, RSWG, and broader community regarding
status of  work undertaken and plans for work to be done,
including timeline for  implementation as well as any key
risks they identify.


          

          
Then there is this clause:



          

            
The LLC is requested t=
o negotiate a task with the RPC that permits and=20


          

        

        

        

          

            
requires the RPC to co=
llaborate in at least an advisory capacity in=20
the content creation of the Editorial series RFCs as they affect the=20
RPC and that collaboration is expected to be the main path for=20
community input into the RPC processes.


          

          
Which enhances the *ability* of the RPC to participate in the RFC series =

process discussions as a partner rather than as a supplicant or=20
afterthought.

Thanks for the response! Mike




          

            
   Brian



            

              
Thanks, Mike




            

          

          

        

        
--=20
Rfced-future mailing list
Rfced-future@iab.org
https://www.iab.org/mailman/listinfo/rfced-future


      

      

    

  


--------------243F7A7E6A246E91C89C519D--

--40mo5B6LiTMJl0Eg4XEhXA5r6V7GsOdZv--

--eOC9xpdyWIyZOfuZS7t7mikwCzhVatSDo
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmEnGcoFAwAAAAAACgkQh7ZrRtnSejOm
cQgAmQ6bB+KvZiqTPoB9zIyJOWd4iwRDRvTsZhMQrja3Iuhoq/j6qtWslsHRxCJ99vZsIlrxkWSZ
I6VN6TBFt5Q9CSLRcE4v0LelbyUB9rhxjkOxjUSqXZrkuKxO1a8cVW7sKwZPjaMK3T00VpKR5szC
M3vS3RzQlrN7Y64hErH4dfBGg44fg1YC2L+MrzTX8ontucJ0lJ1Ap4Unu9anc2YuxexUJ2OrPNwq
jUbc9xIlLkp3KeyoiSh3L57YO+kQFGXCA5840X3Ro+LprP4pYOuj8Cd5QT40/nYllx2WWFOzqDCV
bk2e9lciTnFBgsO1bgSBJo/Kz/eoXmaiM3ptLx/Udw==
=08Hp
-----END PGP SIGNATURE-----

--eOC9xpdyWIyZOfuZS7t7mikwCzhVatSDo--


From nobody Thu Aug 26 00:26:41 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 611B63A11C7 for ; Thu, 26 Aug 2021 00:26:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.891
X-Spam-Level: 
X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.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 qhgLwE4KHpfR for ; Thu, 26 Aug 2021 00:26:32 -0700 (PDT)
Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-eopbgr1400123.outbound.protection.outlook.com [40.107.140.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A0893A11CB for ; Thu, 26 Aug 2021 00:26:32 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gx7FdatyzPCl+mkj3zCidfquVUYt9KU8+gUMduZ7quXeOHnw6ITi23gQXu/Hr3+mpzQwJ78IjfdE/ieSE1WhS4tdF95bSydIgCgI1/kG8Qzysgl32Sa2stuIT4gTL3iXqlY6kaa/oz868WsImSNwM0g7h6kkzYv7rWGJAEIQvWgLLeLJXoWZYhyprSxGr80uuKoIIJ7imxKRK7muI4ZL7urGPOYWkx1vhHb/4o4HoSaqqqXBh2Vd0dkZqczcEAdKDsFcS1xL4i5ZP2QL5bMiM8ACt8mBpbAOcpJr0+9/4pQk/FxktbjMzcRWqfoYVpoitm0bt9ET1cJ9p7miLunW8A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=061ICf1aNX86NoYpdUwSph5PRWD7t0wJplo4XTFQ4wU=; b=SxQzobXbJAMF2p1wfFsk90AOQUwQEhJ/frGbn7Y2toJW8LWdhChACVjSAgYvK9c0NJXmPVYMsa1vHB0njySc8jVW0//vhHtStNcSxbcEplTMyd3QhRUbM05lvfrYYWn7KX/4+KfRt86i5fYxzZ6JSDQxkB/5tvtHdXCUAmhSySHcWkU14kPgiWRdO6AkLvQqU3JHZjR3kejERzmSf+0qaHKWgp/j1r55QKr8tLvEloRo55p5JIjfd58rMUzZhnc6bTLUyhfNdyjAlEm41ZTrwT2uUPwydgL3JwjEfmvkFaE/ItywCSwuqQSXDPDNoKHUILCJkH9On9mHuSR+CvVDPw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=it.aoyama.ac.jp; dmarc=pass action=none header.from=it.aoyama.ac.jp; dkim=pass header.d=it.aoyama.ac.jp; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector2-itaoyama-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=061ICf1aNX86NoYpdUwSph5PRWD7t0wJplo4XTFQ4wU=; b=wOaiQsz8htMMJcpxSHbxQK6SxQbUurY8+NpfR1NCTYS10cQo/BeuKx/oj7emRNiahsrmiPjA+UZ+/OGWEMU8zyOXn2svE4Fximp9p6FN+vnhFcUmIWWaAm4hU4S5G+8lqUArtTPLy3xtcuUxidRA2VojsYBTr1H1189P/u0Fku4=
Authentication-Results: lear.ch; dkim=none (message not signed) header.d=none;lear.ch; dmarc=none action=none header.from=it.aoyama.ac.jp;
Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) by TYYPR01MB6732.jpnprd01.prod.outlook.com (2603:1096:400:cb::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.22; Thu, 26 Aug 2021 07:26:26 +0000
Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::a944:554a:8cd3:e12a]) by TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::a944:554a:8cd3:e12a%9]) with mapi id 15.20.4436.025; Thu, 26 Aug 2021 07:26:26 +0000
To: Mirja Kuehlewind , rfced-future@iab.org
Cc: Jay Daley , Eliot Lear 
References:   <4ad09680-b067-4475-9232-e8f69101e7c0@lear.ch> <3295300e-d396-36fc-2137-6452de7f5296@nthpermutation.com>    <848d287a-d2e5-7e61-90c4-e3718c010906@gmail.com> <086c5844-ef49-4221-94f2-67408182c6a6@it.aoyama.ac.jp> <3b86de0d-6823-c740-7928-4258a420d990@gmail.com>       <173EC03C-E7C8-4965-AABB-49DAF4002F48@ietf.org> <5a47b37b-234e-a0d5-e529-6de68e0177c6@lear.ch> 
From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= 
Organization: Aoyama Gakuin University
Message-ID: <308a195b-3f7f-0ad5-4ccf-e1d3dc155dc2@it.aoyama.ac.jp>
Date: Thu, 26 Aug 2021 16:26:24 +0900
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: TYAPR01CA0002.jpnprd01.prod.outlook.com (2603:1096:404::14) To TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from [133.2.210.39] (133.2.210.39) by TYAPR01CA0002.jpnprd01.prod.outlook.com (2603:1096:404::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.17 via Frontend Transport; Thu, 26 Aug 2021 07:26:25 +0000
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: ac3b2c1a-94df-4373-e33c-08d96862d014
X-MS-TrafficTypeDiagnostic: TYYPR01MB6732:
X-Microsoft-Antispam-PRVS: 
X-MS-Oob-TLC-OOBClassifiers: OLM:10000;
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: T9j7fZy7mSAdspf437zVdVrx35wC3dRT3jp6SwXym/hCXizrwdsh/Log8c9DWf3NS+7PmbStDfHCzX2OEh4jF/x5dcmGdMQ2HIONUVKjZdtrQMd/Ay21zLNbePYuVV9IIKHzF8dIut4N0Auh/qTaguHhWJDRZXxSwB8k5UXce24z7pQ78J8848rXKMybZeuF2xJPq04Ls52ShxbEgeAtkEm6iQ7ESIYOLKtPjDHwbSW5ELpxeHBOIrt8tKBpmy4W7fZQPh/GO9Kp96P4CJK5h5zB7GqWd2s/YkxZ005BTf1ge7j4PyTCOsI1cjMc/67RXFgySs8dagkblL6snY1UyQy+lYivQKyA4JF8WnoMsSuWGd3R/S7k1ze5rNGqwmBzbnWeRkHpp0lAYc4s0AIndfDjcPLGF21dzDJT/1dfZLSkcHFBv6Cb/CFuDCppeFgv2/Tl2EmsGXMVyZaJqQ5AxXFCqyZ4gVRKvD5q6pBpGTDWlP8DMLe7O/OgTSIaVGE7wiyub+5NOlkVn+h675fR0EEu7vzKqCkLb/d9ZJndZb4ZU8zWwSkRxwmtz1XN/6F7MOlp+fjymgVIE6kM4+Q+IK+cQkwbp5esIci1XvnqEM6Env5F3asteodLpwAjkBuLPUpSgbFuNUBZxDoEcs4lm+ni8SpeD7o/gBD650XCuSx5Xkq5Ib1S4vugw5hyxESZ1fhoxl6Sl+AeB08Eb3xbwAo+ooJfX00MTc4W3sl+xR572fgPtcGZzPDsWttVooNiATzXNAjwyzDvWf2JfXi42cuY/bjNqZO1gfkc0QmnDCtG4xzwAnVQvofuJxDaINFGKTtPu+d6rcbBmYhilYrXL5SWXgL/kWyJFELBFedlW/24pHlUj11JmHb1jk3T078G
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:TYAPR01MB5689.jpnprd01.prod.outlook.com; PTR:; CAT:NONE;  SFS:(346002)(39840400004)(366004)(396003)(376002)(136003)(83380400001)(8936002)(4326008)(8676002)(38100700002)(316002)(66946007)(66476007)(38350700002)(786003)(31686004)(16576012)(86362001)(31696002)(52116002)(966005)(30864003)(36916002)(956004)(2616005)(6706004)(26005)(478600001)(5660300002)(54906003)(2906002)(66574015)(53546011)(66556008)(6486002)(186003)(3940600001)(45980500001)(43740500002); DIR:OUT; SFP:1102; 
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?WThYZ05JUU51Zzk2QnhJV2pncHF5eXpScXlPaWpGekZkZVpOM0hCMEJLMTdr?= =?utf-8?B?WlVSN1VaYm13RmdFUjg1MXZSc3NyRDgyaVZ5aWZHSjBJU2F1WVNXK1NVL2Qr?= =?utf-8?B?YkVObWp1emwzSG1EeTZMZUJWNnRPU2U5dmVFYnBrTmljcnk1aXRvSXlyS1hF?= =?utf-8?B?YzBYSDJtcm00YlpILzU3Wnp3ZDVqbmREaEZzVmI1U05nZnhERDY3amZ0WE10?= =?utf-8?B?SHIycWhqdkJCZXdwMXUxYWF2T0svclFVdkIxbEhFaGd3cEdmYllvbUo3SDdz?= =?utf-8?B?a1FIRDZUZmhRNFNxZTluSTg4ZzR4aENTWG5tYTBaeVM2TFRFaGdpZGZ6V1NW?= =?utf-8?B?Y2x6MmVoYnFiRUwvSWJZV0RQTUFCQlJoenc0bW9nWTQ3S1hIN0o3b3VxcWhn?= =?utf-8?B?ZDRXNGFkdFNDYjVKNDJzQmNCbnFNSE1JZkNIc2ZabjVlT0VBVk9VMEdOUDN5?= =?utf-8?B?VUUzb2lwUFl4RjRwMUY1RlBkaW5BbDBPQ3J5NFBrM2lDTzVUeHpzWnNZTFRs?= =?utf-8?B?K2ZYN2paZFd6Ly92RnZZSzNGRHIxUHgzK2xqOHNHWWFoaHRHZFkrNXZVS1U2?= =?utf-8?B?ZXZ4ckZQL1dVL0QzVkxBYmdUL0l3NWtHbGhocmRzaXVUbVE3VFNLdWZobFlm?= =?utf-8?B?bG40TXFNM0NIbkJ0VFhWVDYyVUQzaTdOWEFnbHpYSWVBalRXcjZUL2dFdERH?= =?utf-8?B?cFFNMmQwV3NaZ243TUVtdTRWOUp5ajBIeGlYd0tpVWJaTGRsL3BaY3JqTkxO?= =?utf-8?B?empaMGozQ2hYN2FrUnU2blJheTdEZ2FWRldDZXU1T0RPN2VZY2VubzhjWnd2?= =?utf-8?B?WGZZaldkN0NNbWtHME5ZVFNpVHI3eTk3WmcwUFBLc0ZVMW1Ma3VvNWhkWVJF?= =?utf-8?B?YWl6UXk4OXZrVGc3UDRYRE1waFRRQ3ZtNDJLanhPa3lGVE1RY0JSUmxadWJU?= =?utf-8?B?bEtlWHFGQmEyQ3lnQlliMTRNd2VqTTdkMDV6QmZTdVpkWlltaU1PcUNrRTZG?= =?utf-8?B?d2FOYlVUMENUZDNFaEh3OU1EVzVXOXVVQm14cVZoRjk0RWgyOVA1VklzLzhB?= =?utf-8?B?RTQ1ZUwyNTB0UTdNOWNRWkVkR0JNL0gva2pQNVNzQ200dXpXOTBVYzdhUnFD?= =?utf-8?B?dDJEZll0MmwwV21aQy9Ha1pFK0xielR0d3BtQ1VIZC9RaEs5STloQXR3cnhj?= =?utf-8?B?cGhXK1hSck5QcW16d3NsMk9DT1JSSGNwYm9GS0ppQmJoTXMvNWhJd3RSUEVH?= =?utf-8?B?eGhOeUo1eGJadE1wdE9UZVFoNDdFZ3l4UDVsSVd0ZjBFU09KdVlGUzhxVnlW?= =?utf-8?B?Z3NPWlkveFhZWXVnTTBIY0VEWG0ybTlZWmJtSGNJUlNIaEl6VzErUFhUK0Q0?= =?utf-8?B?TkZndkR5NHRyNXVsUGsyTWVMeGxON1VUUElZUldTTDFrZDE4VXdKNzdhTmtt?= =?utf-8?B?ZHExODRYdWpMek9jd05GQ3oweEh6Wlo3V1VpeERkRkNDVWdpTktrNkQwbjR2?= =?utf-8?B?Tmt4blJMTGNXVzhmZFhPTGgza29OZlhzUTByMTYwYjVtYUcwYVBtbHVYUWlk?= =?utf-8?B?VENKd25BZ0dPNDFCM28zMnI2ZElraVl0dGZUNEloMlhHU0h4Y3lkZmJLdDVs?= =?utf-8?B?amZKeUw1SEFkWi9lK1FwM3hRcnNMMUFnR2JISVk2NXNkbVRPZUFTc0ZFOGVr?= =?utf-8?B?bkxUUHBQMXJEU2pmbnBPcVQxdndKeG13c3p1UG5FekVsS2JrdC92K3N4clpD?= =?utf-8?Q?yWuujXCNVs5CSG28LLTMDtLm70zLHZESoiNe2Yk?=
X-OriginatorOrg: it.aoyama.ac.jp
X-MS-Exchange-CrossTenant-Network-Message-Id: ac3b2c1a-94df-4373-e33c-08d96862d014
X-MS-Exchange-CrossTenant-AuthSource: TYAPR01MB5689.jpnprd01.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Aug 2021 07:26:25.8919 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: e02030e7-4d45-463e-a968-0290e738c18e
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: sBHHLXgnQWo9xegPfQ2C9uZTuUFDPOKfbY21MiTxLMMqkdBgoPM0EJr3D6uvLrfcKPfMODW69NGf56TFjVQjjw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYYPR01MB6732
Archived-At: 
Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Aug 2021 07:26:39 -0000

Hello Mirja, others,

Sorry to be late with my comments. Some may already be obsolete in case 
we move to new text, but some text pieces have been kept in other 
proposals, so comments on these may still be relevant.

On 2021-08-24 18:20, Mirja Kuehlewind wrote:
> Brian and I have been working on some text proposal. This text is mainly based on the current text in the draft and Jay’s proposal for requirements but avoids the term work program. Here it is:

It's fine to avoid the term "work program". I can't complain now, 
because I was the one who complained about "work program".

But actually, I wasn't complaining about the term itself, but because it 
was unclear from the text what the relation ship between (strategy) RFCs 
and the "work program" was. The text below is fine in this regards, but 
would be fine with the word "work program", too. So if somebody is 
attached to that work, I'm not opposed to go back to it.

> --------
> # Roles and Processes
> 
> ## RFC Production Center (RPC)
> 
> Publication of RFCs shall continue to be handled by the RFC Production Center (RPC) function in accordance with high-level policies that have been
> specified through the RSWG/RSAB process as well as based on advice from direct discussions with the RSEA, stream managers, IETF LLC, authors and other community memberss in cases where the implementation of a policy is not clear or not sufficient.

"Publication of RFCs shall continue to be handled": This looks great for 
now, but remember that we are trying to create an RFC that reads good 
even in a few years. So I would change this to "Publication of RFCs is 
handled". That way, the text will be good as long as it's in force.

"RFC Production Center (RPC) function": The text below sometimes has 
"RPC", and sometimes "RPC function". Is there a distinction? If yes, 
what's the difference?

> The RPC shall proactively implement the policies specified by the RSWG/RSAB process reflecting the priorities of the community. The RPC shall report regularly to the RSAB, RSWG, and broader community regarding their plan and time line for implementation as well as any key risks or issues affecting it.

These two sentences make it very clear that the policies are at the top, 
and the 'plan' is for implementing these policies, i.e. subordinate.

Regards,   Martin.

> The RPC is expected to revise their plan based on community input if concern regarding the  implementation plan or priorities of work are raised. In case of conflicting requirements from the community, the RPC shall consult with the RSAB.
> 
> This document does not constrain how the RPC and the community communicate with each other. In the event that the RPC is required to make a decision without consultation that would normally deserve consultation, or makes a decision against the advice of the RSAB, then it must notify the RSAB.
> 
> All matters of budget, timetable and impact on its performance targets, are between the RPC and IETF LLC.
> 
> ### Relationship between the RPC and the IETF LLC
> 
> This document does not specify the exact relationship between the IETF LLC and the RPC function; for example, the RPC function could be provided by a separate corporate entity under contract to the IETF LLC, it could be
> performed by employees of the IETF LLC, or the IETF LLC could work with independent contractors for some or all aspects of the RPC function. The exact relationship is a matter for the IETF LLC and the IETF Executive Director to determine.
> 
> The IETF LLC has authority over negotiating performance targets for the RPC and also has responsibility for ensuring that those targets are adhered to.
> 
> If individuals or groups within the community have concerns about the performance of the RPC, they can request that the IETF LLC look into the matter. Even if the IETF LLC opts to delegate this activity, concerns should
> be raised with the IETF LLC. The IETF LLC is ultimately responsible to the community via the mechanisms outlined in its charter.
> --------
> 
> 
> 
>> On 19. Aug 2021, at 14:14, Eliot Lear  wrote:
>>
>> Ok.
>>
>> I think where we are on this issue is that some would like to see LESS detail about how the work programme is managed.  Jay has made the point below about stating the high level principles to be adhered.  Can I ask Mirja and Brian perhaps to work together to come up with whatever substitute text they think the right level should be?
>>
>> We can then discuss and perhaps wordsmith this at the interim next week.
>>
>> Eliot
>>
>> On 17.08.21 06:31, Jay Daley wrote:
>>>
>>> I think that’s inconsistent with the level of specification in the rest of this RFC but consistent with others that cover the LLC.  If the group chooses to go that way, then I would suggest that there are some general requirements set in this document to ensure that someone in the future doesn’t do away with things the community feels is important.
>>>
>>> Some examples:
>>>
>>> - the RPC/LLC is expected to implement any and all RFCs that come from the RSWG
>>> - the priorities of the RPC must reflect those of the community
>>> - the RPC priorities and plans are public and consulted on
>>> - no constraints on how the RPC communicates with the community or vice-versa
>>>
>>> Jay
>>
>>>> Regards
>>>>    Brian
>>>>
>>>> On 17-Aug-21 00:14, Mirja Kuehlewind wrote:
>>>>> Hi Jay, hi all,
>>>>>
>>>>> Replying to this original mail. The additional text is helpful to better explain what is meant by work program.
>>>>>
>>>>> I’m still slightly concerned that we are over-specifying this in the RFC. I think the process as described is fine, but writing it down in an RFC means we can't easily change anything in future if we see room or need for optimisation.
>>>>>
>>>>> However, if other people feel it’s important to have it in this
>>>> level of details in this RFC, the text looks fine for me.
>>>>> Three small comments/questions below.
>>>>>
>>>>>
>>>>>> On 28. Jul 2021, at 00:48, Jay Daley  wrote:
>>>>>>
>>>>>> Eliot asked me to propose some additional text to close off issues #56, #57, #61, #62 which I’ve done below.  It doesn’t have the elegance of Peter’s prose so may require some work to align with that.
>>>>>>
>>>>>> Much of this is already covered in the latest draft at:
>>>>>>
>>>>>> 	https://github.com/intarchboard/program-rfced-future/blob/master/draft-iab-rfcefdp-rfced-model.md#roles-and-processes
>>>>>>
>>>>>> My suggested additions are in red and my suggested text moves are in blue.
>>>>>>
>>>>>> Jay
>>>>>>
>>>>>> ——
>>>>>>
>>>>>> ## Role of the RPC
>>>>>>
>>>>>> Publication of RFCs shall be continue to be handled by the RFC Production Center (RPC) function in accordance with high-level policies currently in force or yet to be defined following the processes specified in the foregoing sections of this document.
>>>>>>
>>>>>> ### RPC work program
>>>>>>
>>>>>> The RPC follows a work program based on requirements it has gathered from a variety of sources, including policies that have been through the RSWG/RSAB process, and from direct discussions with the RSEA, stream managers, IETF LLC, authors and other IETF participants.  In developing this work program, the RPC makes some key decisions which impact the IETF community:
>>>>>>
>>>>>> 1.  For each requirement that is gathered, can it be directly incorporated into the work program or must it first be subject to community consultation.
>>>>>>
>>>>>> 2.  Setting the relative priorities for the various requirements within the work program.
>>>>>>
>>>>>> 3.  Determining if all the important requirements have been gathered.
>>>>>>
>>>>>> It is likely that the RPC will require advice during the drafting of its work program, which it should seek from at least the RSAB and if required, the chairs of the RSWG.
>>>>> Why are the chairs or the RSWG mentioned here? I guess the RPC is free to ask anybody for advise they want but the main contact point for me would be the RSAB (given it includes the stream managers).
>>>>>
>>>>>> In order to ensure community oversight of the RPC work program:
>>>>>>
>>>>>> * The RPC must present a draft work program for community feedback at least annually and then publish a final work program incorporating any agreed feedback.
>>>>> How and with whom is the feedback agreed?
>>>>>
>>>>>> * The RPC shall report regularly to the RSAB, RSWG, and broader community regarding the contents and progress of its work program and any key risks or issues affecting it.
>>>>> How does the RPC report to the broader community. Isn’t it enough to report to RSWG?
>>>>>
>>>>>> In the event that the RPC is required to make a decision without consultation that would normally deserve consultation, or makes a decision against the advice of the RSAB, then it must notify the RSAB.
>>>>>>
>>>>>> All matters of budget, timetable and impact on its performance targets, are between the RPC and IETF LLC.
>>>>>>
>>>>>> ### Relationship between the RPC and the IETF LLC
>>>>>>
>>>>>> This document does not specify the exact relationship between the IETF
>>>> LLC and the RPC function; for example, the RPC function could be provided
>>>> by a separate corporate entity under contract to the IETF LLC, it could be performed by employees of the IETF LLC, or the IETF LLC could work with
>>>> independent contractors for some or all aspects of the RPC function. The exact relationship is a matter for the IETF LLC and the IETF Executive Director to determine.
>>>>>> The IETF LLC has authority over negotiating performance targets for the RPC and also has responsibility for ensuring that those targets are adhered to. The IETF LLC is empowered to appoint a manager or to convene a committee to complete these activities.
>>>>>>
>>>>>> Community members who have concerns about the performance of the RPC can request that the IETF LLC look into the matter. Even if the IETF LLC opts to delegate this activity, concerns should be raised with the IETF LLC. The IETF LLC is ultimately responsible to the community via the mechanisms outlined in its charter.
>>>>>>
>>>>>> ——
>>>>>>
>>>>>> -- 
>>>>>> Jay Daley
>>>>>> IETF Executive Director
>>>>>> jay@ietf.org
>>>>>>
>>>>>> -- 
>>>>>> Rfced-future mailing list
>>>>>> Rfced-future@iab.org
>>>>>> https://www.iab.org/mailman/listinfo/rfced-future
>>
>> -- 
>> Rfced-future mailing list
>> Rfced-future@iab.org
>> https://www.iab.org/mailman/listinfo/rfced-future
> 

-- 
Prof. Dr.sc. Martin J. Dürst
Department of Intelligent Information Technology
College of Science and Engineering
Aoyama Gakuin University
Fuchinobe 5-1-10, Chuo-ku, Sagamihara
252-5258 Japan


From nobody Thu Aug 26 05:19:12 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6FC13A0B02 for ; Thu, 26 Aug 2021 05:19:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 u8KlgtxwhiII for ; Thu, 26 Aug 2021 05:19:04 -0700 (PDT)
Received: from mail-il1-x131.google.com (mail-il1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (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 E58F83A0AF9 for ; Thu, 26 Aug 2021 05:19:03 -0700 (PDT)
Received: by mail-il1-x131.google.com with SMTP id x5so3054003ill.3 for ; Thu, 26 Aug 2021 05:19:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=I1mINLXmc98cdi/enGDWGjr8c3tl8OvK7DHjux/Kr7k=; b=JMsS9cy5M2GupPfzYKyjOK81ajw3Y/KXL5Q8hgDpkTxIjqsjAYtbkAqLW/acfs0ICY 4M9Pxw4nY9Z8zR0zN+HztVgM7KHLkYVfDl8+NFkYy/p2S+1/ZEahx3t0c2DRh1vvemwv csfnUXNOPMsBmvFuJdOqY9ihKBWqNLMKr+b2I=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=I1mINLXmc98cdi/enGDWGjr8c3tl8OvK7DHjux/Kr7k=; b=pOsWfliGCKhFDTYfAmNCMe4qQx6G1RM2jxI0rFqjbrEP++fbxcXxZneKuiv/fxBJGp Cz4hniJHeySBFHJXTcPO2fIiPx7Bu9vAAEOKIxuR7/MMr/odbKOy9IyFwzArY1S+YGBa 4G14oF4Vp0GDRR64BfNUYGD5Q/Nm1hMcghh0+xCvJlIZVnQNfVgrwZjwwuf0ywQ/Ltrj oubHkYb9vDsnFXLmcvLKUIOJupDcg3BSinGKUE48YVR8Cu//zacRfFN/TFs+nsR5KLk5 k4YSZZLC/sLnksUFdEbxiOg95RpwLYL59p5jKJxl/skn9Yo3Q/EemHueRNkApRXpxTtJ zoSg==
X-Gm-Message-State: AOAM530kj/JOQFTW/7zXTjHsFmlYc2s2frzSgv6lPlwm/io0bmCiJqxg INXCPLTNbxcjKQ/d+aBFHZBbeg==
X-Google-Smtp-Source: ABdhPJxWx3+TVJJgllXW7hEm4Cq85v7qPv4mCDqZuOF85nAD4zMDwXiYRMmZqNfGrw0TUJbUCY4o/A==
X-Received: by 2002:a05:6e02:10c2:: with SMTP id s2mr2525653ilj.148.1629980341831;  Thu, 26 Aug 2021 05:19:01 -0700 (PDT)
Received: from dragon.local (c-73-78-113-156.hsd1.co.comcast.net. [73.78.113.156]) by smtp.gmail.com with ESMTPSA id l15sm1754255ilt.45.2021.08.26.05.19.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 26 Aug 2021 05:19:01 -0700 (PDT)
To: Eliot Lear 
Cc: "rfced-future@iab.org" 
References: <667f4a94-ab2a-b97d-f961-243e383d46a8@mozilla.com> <53d3839d-0a7d-df14-9050-d758ed867ead@lear.ch>
From: Peter Saint-Andre 
Message-ID: <0a8f147a-ecfa-14a8-8523-c10f1e99dc28@mozilla.com>
Date: Thu, 26 Aug 2021 06:18:58 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <53d3839d-0a7d-df14-9050-d758ed867ead@lear.ch>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Rfced-future] -01 draft
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Aug 2021 12:19:11 -0000

Sure thing! I might have missed some stuff because I got jammed. No
promises of perfection. :-)

On 8/25/21 10:10 PM, Eliot Lear wrote:
> Thanks for this, Peter!
> 
> On 26.08.21 03:31, Peter Saint-Andre wrote:
>> Hi all,
>>
>> My apologies for the late notice, but I've just uploaded version -01 of
>> the program draft:
>>
>> https://datatracker.ietf.org/doc/html/draft-iab-rfcefdp-rfced-model-01
>>
>> This should enable us to close some issues. I shall post -02 much
>> farther in advance of the next meeting.
>>
>> Peter
>>
> 


From nobody Thu Aug 26 14:34:00 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D14C3A0920 for ; Thu, 26 Aug 2021 14:33:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.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 tnbQ3auj5-SX for ; Thu, 26 Aug 2021 14:33:54 -0700 (PDT)
Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (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 969F83A0923 for ; Thu, 26 Aug 2021 14:33:54 -0700 (PDT)
Received: by mail-qt1-x82c.google.com with SMTP id t9so3731784qtp.2 for ; Thu, 26 Aug 2021 14:33:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=uYLmObniZ8tAcikXCKxSc6lRP32uK7+BAm8OYUO0RBI=; b=WE9ioS1aXzVcP0Q6w12S0aknZ0Qa0Ff64ZiP5W8nakh5DuIhRBbRimjRJG6lXFVHCf m1hxLMwlj/ZTXal7MeBmQth5lAaeZhrZVebKhmibUEilEHHJcn3KpIu1tCCGzliplgH/ d/0htWJF+vgIdJFjjG2NEB7UCwZnM3wUYTOcm/RIMHwULTfIkRy3BjFvKBKOQy6MR5v9 XODD/tdIvSMhZSomJIXZ5vBByrbIm8hN6CCNenII8usjDI8DiEW6WIvRTW/o/W+haC+a mqYwNPvVu+HbgS9o6LpqxSKDQI2Z43iD+x/PzEpTVRJl+e9RQOkSMR9RA8a4LwbZ/jDx GgeQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=uYLmObniZ8tAcikXCKxSc6lRP32uK7+BAm8OYUO0RBI=; b=UAWO3z4eOMgkG6CArUKHPNBUZfEgb64zUZSxh+UVEOmeQZVOof1bE4yRu9Urn1Q1Dn q4aQuwzvC30lMTtrKkJxrAwwym7zuH7/I/MbZWI9WlrH2vjVTUlh1MChEaoWkL85/E5X ZYF3h+lMvbVBfRL8dPGtvJoWIFRKB3M6pxmq3xYm2MDs/3nHJXRxUkptAMkhp5kJ9Q2b hKBhaikXXlsgQVIucmxucKIWt4WhLC5Askbh6JPirWHszNUFlNH6jzbM6mC7zORnYtod IHTKKdN1xfG90F3Xs8M2QaCEDRv73jz8acU7caLeAF+HC7JwGZKiNqXRDR74pXLsI06c NQwA==
X-Gm-Message-State: AOAM5320LXNMPw9+xlRWw+D94TKtS1e1SyzInMJqLcKkM98JZO3XffRR 8oZXNNaw5KMHpwt3nchpEmdMd/o2q7dyGoJ0
X-Google-Smtp-Source: ABdhPJxEMt7SnitQGv3Xc1ZAON+w7oBs8wzsQj/kfdI+x1HBvWbiDHgqRBMN6KwUSrcRvu5AF+p03A==
X-Received: by 2002:ac8:12c5:: with SMTP id b5mr5389961qtj.215.1630013631350;  Thu, 26 Aug 2021 14:33:51 -0700 (PDT)
Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id d78sm3199632qkg.92.2021.08.26.14.33.50 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 26 Aug 2021 14:33:50 -0700 (PDT)
To: "rfced-future@iab.org" 
From: Michael StJohns 
Message-ID: <2512c470-1721-08d9-b73f-f66248e585ce@nthpermutation.com>
Date: Thu, 26 Aug 2021 17:33:49 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: [Rfced-future] Creation/dissolution
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Aug 2021 21:33:59 -0000

Here's a cut.  Somewhat legalistic, but provides the basis for fixing a 
problem if it exists.  Note that this is an all or nothing - this 
doesn't give the IAB/IESG/LLC the ability to direct changes the RFC  
outside of the RSAB/RSWG process, but allows them to kill that process 
if necessary.

## Dissolution of the RSAB and RSWG

By mutual agreement of the IAB, the IETF and the IETF LLC Board, and 
with the consensus of the community, this document creates the RSAB, 
RSWG and the Editorial series within the IETF framework. To provide for 
the possibility that the needs of the community may change over time, or 
are not being satisfied by the system and organization described herein, 
the IAB, the IETF and the IETF LLC Board when acting collectively with 
the consensus of the community reserve the authority to disestablish 
either or both of the RSAB and RSWG and to redirect the authorities and 
responsibilities assigned to those groups as necessary.



From nobody Thu Aug 26 15:38:24 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B3F13A1171 for ; Thu, 26 Aug 2021 15:38:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=n5Ap7FQR; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=DHj3r0xg
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 wfNhZItMJDn0 for ; Thu, 26 Aug 2021 15:38:17 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0CEE3A1174 for ; Thu, 26 Aug 2021 15:38:16 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 9E24B5C01AA; Thu, 26 Aug 2021 18:38:15 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Thu, 26 Aug 2021 18:38:15 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=q ub90NFBRt3iXOmwYuFstF+qOe+h0fZhvRies+NVTfg=; b=n5Ap7FQRheDOvfwIh 5lrpYQtPIHxigQMfdzEGQGYXD6gKbfFbOwsbgLDYKaL5yJHNR4fyjULf4BJ5eWlI tnshFiN1Nmw8tFGZH/Q7WBU0i/LT71gICmwgH5j5iS+l1K0DZniiYkrNm1umazMU 0BJviXM6k01jkxCJUSHHhJb6EWtIeNBbnf0Nyc5H3nndtiD9NqUOg3mXbDa42sQw Vgwf1e2AmqRHS8wDy/+SK+okbw1iTAhjehBbGxKR3L3Bykn7R10oEnymSbUP40rg qRXVwJB6i9fRM0606jblAMtaO17LUUIoWzj4UQSu8W/R3u1nwJRkYbZiXMjQ8uQP Y2e9g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=qub90NFBRt3iXOmwYuFstF+qOe+h0fZhvRies+NVT fg=; b=DHj3r0xggV01G4ufi7C45KeI0xFSVF6lvZ3KW6VQGxaIENXWumCTpERB9 Nw8WmdXsqjqGVi6kjkn/N2lKXrmK5IWjFHIPHwkhcXyy7bgV8KVKQnoRR6HXrfB8 UvNUyICATu8qj7qoPIntDuDWQeLb/7qnOzkCMLlXKyHVUZ3dn4mHAqoup5wO6bK+ AwosTXTmU8OqxvjaBg3yF11a+sgbL4INZYQXLywXXBm9/NdGlLxt92jdNhW6h/5D KPZ6UvTw9oeqlcFl1HoiyzMStB1thyfjoml34xgAUqWdKm142Sp/4Pzv4Z4ERO6U gQxhYltND2awRzlAzfhZYCGm5KYfQ==
X-ME-Sender:  
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudduvddguddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfuhfgjfffgkfhfvffosehtqh hmtdhhtddvnecuhfhrohhmpeforghrkhcupfhothhtihhnghhhrghmuceomhhnohhtsehm nhhothdrnhgvtheqnecuggftrfgrthhtvghrnhepvefffffhudetveevhfeuffeigedtue dtheffleetffeftddtgeegjeehieeuteetnecuffhomhgrihhnpehmnhhothdrnhgvthen ucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhoth esmhhnohhtrdhnvght
X-ME-Proxy:    
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 26 Aug 2021 18:38:13 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Mark Nottingham 
In-Reply-To: <2512c470-1721-08d9-b73f-f66248e585ce@nthpermutation.com>
Date: Fri, 27 Aug 2021 08:38:10 +1000
Cc: "rfced-future@iab.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <6DD9248A-9E94-4CB9-A3E6-E79B66644545@mnot.net>
References: <2512c470-1721-08d9-b73f-f66248e585ce@nthpermutation.com>
To: Michael StJohns 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: 
Subject: Re: [Rfced-future] Creation/dissolution
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Aug 2021 22:38:24 -0000

> On 27 Aug 2021, at 7:33 am, Michael StJohns  =
wrote:
>=20
> Here's a cut.  Somewhat legalistic, but provides the basis for fixing =
a problem if it exists.  Note that this is an all or nothing - this =
doesn't give the IAB/IESG/LLC the ability to direct changes the RFC  =
outside of the RSAB/RSWG process, but allows them to kill that process =
if necessary.
>=20
> ## Dissolution of the RSAB and RSWG
>=20
> By mutual agreement of the IAB, the IETF and the IETF LLC Board, and =
with the consensus of the community, this document creates the RSAB, =
RSWG and the Editorial series within the IETF framework. To provide for =
the possibility that the needs of the community may change over time, or =
are not being satisfied by the system and organization described herein, =
the IAB, the IETF and the IETF LLC Board when acting collectively with =
the consensus of the community reserve the authority to disestablish =
either or both of the RSAB and RSWG and to redirect the authorities and =
responsibilities assigned to those groups as necessary.

I'm concerned that this might cause unnecessary strife if it ever =
actually needs to be used; saying that the IETF rather than the IESG is =
problematic because the only way to get an IETF position on something is =
to issue an RFC. Likewise, measuring the 'consensus of the community' =
has proven controversial, given the amorphous nature of the community in =
question.

I'd suggest something like:

This document creates the RSAB, RSWG and Editorial Series by mutual =
agreement of the IAB, the IESG and the IETF LLC Board, reflecting =
community consensus as established in the RFC Editor Future Development =
Program. Change to the Editorial Series are managed through the process =
defined here. Changes to the responsibilities and authorities of the =
RSAB and RSWG (including dissolution) require mutual agreement of the =
IAB, IESG and IETF LLC Board, well as a community consensus established =
in a manner defined by the IAB.

... where 'a manner defined by the IAB' is open to other suggestions -- =
we just need to define who holds the ball for scoping rfced-future2 if =
the need arises.

Cheers,


--
Mark Nottingham   https://www.mnot.net/


From nobody Thu Aug 26 15:49:15 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ADCE3A12B0 for ; Thu, 26 Aug 2021 15:49:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 eD7rvT9gPgAQ; Thu, 26 Aug 2021 15:49:08 -0700 (PDT)
Received: from smtpclient.apple (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id AB4873A12AD; Thu, 26 Aug 2021 15:49:07 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
From: IETF Executive Director 
In-Reply-To: <2512c470-1721-08d9-b73f-f66248e585ce@nthpermutation.com>
Date: Fri, 27 Aug 2021 10:49:03 +1200
Cc: "rfced-future@iab.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <801C9DE4-3788-4200-ABA7-520568CFCDE7@ietf.org>
References: <2512c470-1721-08d9-b73f-f66248e585ce@nthpermutation.com>
To: Michael StJohns 
X-Mailer: Apple Mail (2.3654.100.0.2.22)
Archived-At: 
Subject: Re: [Rfced-future] Creation/dissolution
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Aug 2021 22:49:15 -0000

> On 27/08/2021, at 9:33 AM, Michael StJohns  =
wrote:
>=20
> Here's a cut.  Somewhat legalistic, but provides the basis for fixing =
a problem if it exists.  Note that this is an all or nothing - this =
doesn't give the IAB/IESG/LLC the ability to direct changes the RFC  =
outside of the RSAB/RSWG process, but allows them to kill that process =
if necessary.
>=20
> ## Dissolution of the RSAB and RSWG
>=20
> By mutual agreement of the IAB, the IETF and the IETF LLC Board, and =
with the consensus of the community, this document creates the RSAB, =
RSWG and the Editorial series within the IETF framework. To provide for =
the possibility that the needs of the community may change over time, or =
are not being satisfied by the system and organization described herein, =
the IAB, the IETF and the IETF LLC Board when acting collectively with =
the consensus of the community reserve the authority to disestablish =
either or both of the RSAB and RSWG and to redirect the authorities and =
responsibilities assigned to those groups as necessary.

I would be cautious about giving the LLC a role here that is anything =
other than advising on the financial/operational feasibility of any such =
plan.


Jay

>=20
>=20
> --=20
> Rfced-future mailing list
> Rfced-future@iab.org
> https://www.iab.org/mailman/listinfo/rfced-future

--=20
Jay Daley
IETF Executive Director
exec-director@ietf.org




From nobody Thu Aug 26 16:02:08 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD1F3A1568 for ; Thu, 26 Aug 2021 16:01:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 tuN0qlviTcpL for ; Thu, 26 Aug 2021 16:01:52 -0700 (PDT)
Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (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 CD4E93A13FC for ; Thu, 26 Aug 2021 16:01:33 -0700 (PDT)
Received: by mail-pg1-x531.google.com with SMTP id 17so4372543pgp.4 for ; Thu, 26 Aug 2021 16:01:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=qeZCH71kyjpFN0Mhxjj6Sw0G93rD/zN3+E6ZYWMoEco=; b=CwA3SJc6hVFzP6WR0abz9rOaI7I0M8nI3khZpgTvbmLo16fHhE2TzibItKGLVa06aa I0j0Nk7SG8JdR0Qsd+KmyFLXrOGqHA3XTLBo6Bw+dlWxdO0funIFHwZqkDilpXa8kjcJ G6lyH9FU2ipdLSrjTWw81w8NhIi+c1WF91r4uWjw9finGTh8+ZjsKQ/Yp0EMBUXAZOJB THo3F2T6QsZYBL67zq5H2F3G/4zdGg/GFhFp0EfF7TL2d5pBmyyHAc4lpRxc+EGggQNM XELq7500ftXhCf2d7kI/stlHy9lL0NMiLtf+92xmHOMwGVPxYb63g2LvCKx4pdrhQpSG vhmQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=qeZCH71kyjpFN0Mhxjj6Sw0G93rD/zN3+E6ZYWMoEco=; b=ICWKBQKoKYgs9mSkRHT31OKh7sP5aZnAmEcnE9jW2Hg24EfuUdiIDIRYmiciMUOtsa sn6S9dGZZS1bQaHdmWRhfG0Uvc8XHhbn05ZcEsrJc487IbgMGbq/1BHhjgEvgkN7C5pt /0BtH39KQw2598VvZVi0zLpcyC+OF4rifGzhPxN2e9qvsHdk4NEE++J5KvMvqRhupBi6 GUH/Wz3h7ib86svfzFDCWJSPofqsfR7wrm1edsMhRP5SO8OULrqV+XtPHPp/lyOQO6xL e4yXpkd+on8oI33yagutZ//l36DwInLISyE1Y7IHFDWhREcH015hwXQ++krHAK5YEAyx VUAw==
X-Gm-Message-State: AOAM53026z4N705X4+FweMBw2bCfP7eY0mntA1D7KBIcoX2+ZClo5TTW KRuz+xOYNTgge1FZ3jyLooEG8Ll1lDQ9fg==
X-Google-Smtp-Source: ABdhPJw+07NVV0f2LImGVzVbTvm2sKlH1SwusBdqi/+WhfDZCSFSj4ZKJlepXfehFiAQn7RUJJavYA==
X-Received: by 2002:a62:4ece:0:b0:3ef:88d5:ba51 with SMTP id c197-20020a624ece000000b003ef88d5ba51mr6111424pfb.3.1630018891896;  Thu, 26 Aug 2021 16:01:31 -0700 (PDT)
Received: from ?IPv6:2406:e003:11d3:cf01:80b2:5c79:2266:e431? ([2406:e003:11d3:cf01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id x75sm5117423pgx.43.2021.08.26.16.01.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 26 Aug 2021 16:01:31 -0700 (PDT)
To: Mark Nottingham , Michael StJohns 
Cc: "rfced-future@iab.org" 
References: <2512c470-1721-08d9-b73f-f66248e585ce@nthpermutation.com> <6DD9248A-9E94-4CB9-A3E6-E79B66644545@mnot.net>
From: Brian E Carpenter 
Message-ID: 
Date: Fri, 27 Aug 2021 11:01:28 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <6DD9248A-9E94-4CB9-A3E6-E79B66644545@mnot.net>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Rfced-future] Creation/dissolution
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Aug 2021 23:02:06 -0000

On 27-Aug-21 10:38, Mark Nottingham wrote:
> 
>> On 27 Aug 2021, at 7:33 am, Michael StJohns  wrote:
>>
>> Here's a cut.  Somewhat legalistic, but provides the basis for fixing a problem if it exists.  Note that this is an all or nothing - this doesn't give the IAB/IESG/LLC the ability to direct changes the RFC  outside of the RSAB/RSWG process, but allows them to kill that process if necessary.
>>
>> ## Dissolution of the RSAB and RSWG
>>
>> By mutual agreement of the IAB, the IETF and the IETF LLC Board, and with the consensus of the community, this document creates the RSAB, RSWG and the Editorial series within the IETF framework. To provide for the possibility that the needs of the community may change over time, or are not being satisfied by the system and organization described herein, the IAB, the IETF and the IETF LLC Board when acting collectively with the consensus of the community reserve the authority to disestablish either or both of the RSAB and RSWG and to redirect the authorities and responsibilities assigned to those groups as necessary.
> 
> I'm concerned that this might cause unnecessary strife if it ever actually needs to be used; saying that the IETF rather than the IESG is problematic because the only way to get an IETF position on something is to issue an RFC. Likewise, measuring the 'consensus of the community' has proven controversial, given the amorphous nature of the community in question.
> 
> I'd suggest something like:
> 
> This document creates the RSAB, RSWG and Editorial Series by mutual agreement of the IAB, the IESG and the IETF LLC Board, reflecting community consensus as established in the RFC Editor Future Development Program. Change to the Editorial Series are managed through the process defined here. Changes to the responsibilities and authorities of the RSAB and RSWG (including dissolution) require mutual agreement of the IAB, IESG and IETF LLC Board, well as a community consensus established in a manner defined by the IAB.
> 
> ... where 'a manner defined by the IAB' is open to other suggestions -- we just need to define who holds the ball for scoping rfced-future2 if the need arises.

Agreed, but this omits the IRTF and the Independent Series and that isn't OK.

Also - I take your point about IESG v IETF, but I think the IESG must obtain IETF input for something this important. So "IESG after consulting the IETF" or something like that.

   Brian


From nobody Thu Aug 26 16:04:16 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 382F33A155B for ; Thu, 26 Aug 2021 16:04:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 uq8oaQBsBSOx for ; Thu, 26 Aug 2021 16:04:00 -0700 (PDT)
Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) (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 10D473A1418 for ; Thu, 26 Aug 2021 16:03:35 -0700 (PDT)
Received: by mail-pf1-x432.google.com with SMTP id v123so4017382pfb.11 for ; Thu, 26 Aug 2021 16:03:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=xo3ZEhPzNCZmQ3bAj/IAtzgysyXRt4Fqb1mm6n7qwX8=; b=kjMZFxRH+ZjeE4Vrf/0U0C8jaP04D4duLua5LDA7Px+dO6SNeobSlgA43K37I0dhkK 0nrfkZf7EBF6e0Lg6e19WBMnz5ZQI5tYjE9Wgr7nSYfLpIenkTlME496cA8fmNfxPyBy n6/+sjmLvn/JEhXdigcEJYX4C9v0Sihx3NUohuDkOaM2WfiXWthg6GHzXon7549niITy 2R3ahJiQUGYQuc5bl/0fBh/WIQLoQNjU6wIe6BkUbCuEmBSXccwfkWGCKSUiGU6puCdv LEUHQIAARCm5/LthxmSsY5ADxU1eBWZeBTIzcmxvFAqXmK4vbfEBabfwE7qNr/juMWZw VR2g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=xo3ZEhPzNCZmQ3bAj/IAtzgysyXRt4Fqb1mm6n7qwX8=; b=KQ7Hv3ZiliBill1/4fWUKrex4c+2kPqHT8Jf/XrdaONb5VBmW2+5UHmiTjqogc+qQ3 YFrcJUlMRullMRFcDaRTX2y/QuwnqhH2WNA7rB2uUDnmMf6rHXI+mf8PKZQ2jn3POPA2 DVdlYlVLjiD4S29h10Jiu2zI2GMjDprNJEWgMu+6zvXJL5ZqhjH2Tox1huPFVFmWdrKd frKpiQdkcbUNrXPB3Dt4uaKgGSrvy9sSvXlSa3MRFcLEvbu64DDEA/Dcj7vY3Q03DoL7 zUwi0YhtZjc2VhJ1hQp6S4qXsQmy6n1v1DHd0ibvPJyPYy3TMDccaluHvW4Bkyr1eT0m 5LdQ==
X-Gm-Message-State: AOAM533eJJmDHpMz4UitOJZJ2fsw6A50pwwEBRBZoD7P8FITwY1JjxLl Z0dQbfnBgicl8Oz6EVJYkGPEcVdbhGc3jQ==
X-Google-Smtp-Source: ABdhPJxAmehqGHNtTxjPYhI8eTlhJ/LJMAT20Nu0tsPo5rhfCj9RramT0N6QIy14cmGsoNpw9r1fmQ==
X-Received: by 2002:a65:6883:: with SMTP id e3mr5323464pgt.90.1630019013136; Thu, 26 Aug 2021 16:03:33 -0700 (PDT)
Received: from ?IPv6:2406:e003:11d3:cf01:80b2:5c79:2266:e431? ([2406:e003:11d3:cf01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id pj14sm3810370pjb.35.2021.08.26.16.03.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 26 Aug 2021 16:03:32 -0700 (PDT)
To: IETF Executive Director , Michael StJohns 
Cc: "rfced-future@iab.org" 
References: <2512c470-1721-08d9-b73f-f66248e585ce@nthpermutation.com> <801C9DE4-3788-4200-ABA7-520568CFCDE7@ietf.org>
From: Brian E Carpenter 
Message-ID: <6c1106c3-1063-0b50-165a-36e038b9e83a@gmail.com>
Date: Fri, 27 Aug 2021 11:03:29 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <801C9DE4-3788-4200-ABA7-520568CFCDE7@ietf.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Rfced-future] Creation/dissolution
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Aug 2021 23:04:15 -0000

On 27-Aug-21 10:49, IETF Executive Director wrote:
> 
> 
>> On 27/08/2021, at 9:33 AM, Michael StJohns  wrote:
>>
>> Here's a cut.  Somewhat legalistic, but provides the basis for fixing a problem if it exists.  Note that this is an all or nothing - this doesn't give the IAB/IESG/LLC the ability to direct changes the RFC  outside of the RSAB/RSWG process, but allows them to kill that process if necessary.
>>
>> ## Dissolution of the RSAB and RSWG
>>
>> By mutual agreement of the IAB, the IETF and the IETF LLC Board, and with the consensus of the community, this document creates the RSAB, RSWG and the Editorial series within the IETF framework. To provide for the possibility that the needs of the community may change over time, or are not being satisfied by the system and organization described herein, the IAB, the IETF and the IETF LLC Board when acting collectively with the consensus of the community reserve the authority to disestablish either or both of the RSAB and RSWG and to redirect the authorities and responsibilities assigned to those groups as necessary.
> 
> I would be cautious about giving the LLC a role here that is anything other than advising on the financial/operational feasibility of any such plan.

Good point. That may need an extra sentence.

   Brian
 


From nobody Thu Aug 26 16:34:27 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C25733A167B for ; Thu, 26 Aug 2021 16:34:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.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 gP6MwU49n3ed for ; Thu, 26 Aug 2021 16:34:20 -0700 (PDT)
Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 EA8EF3A167D for ; Thu, 26 Aug 2021 16:34:19 -0700 (PDT)
Received: by mail-qk1-x735.google.com with SMTP id e14so5409019qkg.3 for ; Thu, 26 Aug 2021 16:34:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=dQbKwxqDZqrISOaEqaHagzuTUqm08n3nW9aePi36Fz8=; b=M3LLhtqGXI8RR2AC14XTioUqEQgw8ki2OegRhtDAzm6kxECuf2SYOn7zmASfGFqgBT MmY49oYmIwj+193lrCytk4wWew4jqwMPu5oVxFP31bjXHtRgy5Lk7mqj6DJAL9TnXH7V 2MJ7jUzEzFKlj8TDIbB+AFZOAzjh3FwMIux4wizGPMWS+Rfn91WGhtKySuGNnp4CAVlD CHxAGzUJVadQH717+4l0S3b+FMm8LGXuns6xmZifDvk8YG4aMm1c8OhQVOiBhIBDuuoQ izmFISfb7d7Eq9HQdeSPbLBZidTSgzINYxXJ/KbSbHV7y2lymLCvtK1p15oVKLvfRExm JyOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=dQbKwxqDZqrISOaEqaHagzuTUqm08n3nW9aePi36Fz8=; b=okeK+exIP3LU3q8zMHjVGxoahpmSjCycsvWeS9RCFDhfDsIChToUyuyTpqBmMI3xlz R75CCIAKxMT5k/R7HIig2KfsUV3Bn6vd1iP8Gc7oq4mF9KcNAb7xHhXWkuVhOGH7eE7/ 3MTbnLaXIf//sK/Rcgvr8wya4cX0H9W+lRGUpdZM2gUkonSLfPL7DmCyvmuBGCvt37wV G9d6aRit99P2ISJYH3B0qb7Vsg6DVjTRyk7shdR9NPzgozxzLYiLVIffF/XOcnkUdxUG ab7FRI7XMucqG806H6Znet/PDBjGbsZJc6WC0NUNDpAUP6wX7mbr+rxZKCqfurx3WXwo 1Fgg==
X-Gm-Message-State: AOAM533bySbL47UzmiYBzqbUmc+3CisEA1xrNUT2i6z8cfZU9HVkbhii uI03lOvOiHQBKsj0bZAiwMDMGqxHPJk5Ph93
X-Google-Smtp-Source: ABdhPJzEsEGa/daPwSrkJkOK1DV/WYxS4KU+334LtvlyP/qcIX/zwB7L2E3NNa8QmOcLfSpzCJooCw==
X-Received: by 2002:a37:84c1:: with SMTP id g184mr6398749qkd.102.1630020856783;  Thu, 26 Aug 2021 16:34:16 -0700 (PDT)
Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id v5sm3617589qkh.39.2021.08.26.16.34.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 26 Aug 2021 16:34:16 -0700 (PDT)
To: Brian E Carpenter , IETF Executive Director 
Cc: "rfced-future@iab.org" 
References: <2512c470-1721-08d9-b73f-f66248e585ce@nthpermutation.com> <801C9DE4-3788-4200-ABA7-520568CFCDE7@ietf.org> <6c1106c3-1063-0b50-165a-36e038b9e83a@gmail.com>
From: Michael StJohns 
Message-ID: 
Date: Thu, 26 Aug 2021 19:34:15 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <6c1106c3-1063-0b50-165a-36e038b9e83a@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Rfced-future] Creation/dissolution
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Aug 2021 23:34:25 -0000

On 8/26/2021 7:03 PM, Brian E Carpenter wrote:
> On 27-Aug-21 10:49, IETF Executive Director wrote:
>>
>>> On 27/08/2021, at 9:33 AM, Michael StJohns  wrote:
>>>
>>> Here's a cut.  Somewhat legalistic, but provides the basis for fixing a problem if it exists.  Note that this is an all or nothing - this doesn't give the IAB/IESG/LLC the ability to direct changes the RFC  outside of the RSAB/RSWG process, but allows them to kill that process if necessary.
>>>
>>> ## Dissolution of the RSAB and RSWG
>>>
>>> By mutual agreement of the IAB, the IETF and the IETF LLC Board, and with the consensus of the community, this document creates the RSAB, RSWG and the Editorial series within the IETF framework. To provide for the possibility that the needs of the community may change over time, or are not being satisfied by the system and organization described herein, the IAB, the IETF and the IETF LLC Board when acting collectively with the consensus of the community reserve the authority to disestablish either or both of the RSAB and RSWG and to redirect the authorities and responsibilities assigned to those groups as necessary.
>> I would be cautious about giving the LLC a role here that is anything other than advising on the financial/operational feasibility of any such plan.
> Good point. That may need an extra sentence.
>
>     Brian
>   

Nope.   This is not about advising, its about agreeing.   In the 
creation phase, the LLC has to agree to pay related costs of this 
transition, and there probably will be some.  In the dissolution phase, 
there will be costs rehoming things and the LLC will have to agree with 
those costs.   Given that I think the LLC needs to be an approving body 
for both dissolution and creation.




From nobody Thu Aug 26 16:35:57 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C786A3A16A7 for ; Thu, 26 Aug 2021 16:35:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.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 Vy7UuNzec2vR for ; Thu, 26 Aug 2021 16:35:51 -0700 (PDT)
Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 A9DC73A16A2 for ; Thu, 26 Aug 2021 16:35:51 -0700 (PDT)
Received: by mail-qk1-x733.google.com with SMTP id t4so5350402qkb.9 for ; Thu, 26 Aug 2021 16:35:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=Kx+BaMKxd/vbpWTh1Z2IJgUGMVA92S9cywOQZL2pUGA=; b=OexpVNF8FdKlg2/5NL7DcxFb/MpHBZUvdZUqDsI6Hoegyqb1Ea7QXbIcQ2BQrWa1dL EN1Lxkqwt2KFo5OTGX8BABGusWpGezWUT94pvujNYGOIpZ/bkEs1MQgcEANslhdeUM4D h9Gev9zCu1ziwG4MWuXh99p+5aStC9+HTt6Q5/p1GoU+Orv2dA8pajRSw9BZ+13YRRsA rfjnJ8Z175npQnVVBBG7/EckO5pzToZppSmbMZYi2MROetqmPmZqCExqe8NBE6RPcl3m Fayb39zY8gz+oUE95Y1WGjjBi3fr+hhnqabxQtjd2fYTFE0ZdTQee4IraaaBbQK5DGPL Jizw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=Kx+BaMKxd/vbpWTh1Z2IJgUGMVA92S9cywOQZL2pUGA=; b=EYewolrd04vcUo3oO7esQo80WVMGdFzdCJY3P+Qe0giOyaflGQ2ya6bRU64G/TTerH NMG+JXIfBOuD5LMT76rPsas18ljuQidFEVwnALWqgtHTmt3WHmM5r+AKbl3lxGP+NlE6 i+I9z8yR2l52T3GcOgK/tK/tub+hQdIQl+sXoOdU+//QThhvu7GSOKc8a1Sli4Gi46aM 5Ymib+CMdg0bHEmT4xwHqHZDd6UT47UZpA/26ZgWm+v/Q31GSmTPAD9t9nPLxh7eB8RH zgIS+9N/7LgKwdGdIiuOKAC/ZfJqynnwb3rCBPfimExTpjent0QJFlUsu2KAMOLhY6G5 LyZw==
X-Gm-Message-State: AOAM53377m7BHHc2A7aLGJT9Cktc9CyhSTb4tCoWzj7qXBaZcSeFkNR1 VPduzaupnxfrToQy9S1dK6MsKXtps+zEcgn3
X-Google-Smtp-Source: ABdhPJxdeUaKtjWJGr6uWOBJYZI0yFw1mitnQBff7WpyMLjEcTRink1JpGQ12wV6C+pqcbYA5XcCfw==
X-Received: by 2002:a05:620a:1035:: with SMTP id a21mr6339248qkk.422.1630020949120;  Thu, 26 Aug 2021 16:35:49 -0700 (PDT)
Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id i18sm3721445qke.103.2021.08.26.16.35.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 26 Aug 2021 16:35:48 -0700 (PDT)
To: Brian E Carpenter , Mark Nottingham 
Cc: "rfced-future@iab.org" 
References: <2512c470-1721-08d9-b73f-f66248e585ce@nthpermutation.com> <6DD9248A-9E94-4CB9-A3E6-E79B66644545@mnot.net> 
From: Michael StJohns 
Message-ID: <13c56879-192f-5ca7-ca51-590fa75d8587@nthpermutation.com>
Date: Thu, 26 Aug 2021 19:35:47 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Rfced-future] Creation/dissolution
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Aug 2021 23:35:56 -0000

On 8/26/2021 7:01 PM, Brian E Carpenter wrote:
> Agreed, but this omits the IRTF and the Independent Series and that isn't OK.
>
> Also - I take your point about IESG v IETF, but I think the IESG must obtain IETF input for something this important. So "IESG after consulting the IETF" or something like that.

I actually meant IESG vice IETF.  And community stands in for what I 
think you mean by IETF above.

Mike



From nobody Thu Aug 26 16:50:12 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5C013A17AF for ; Thu, 26 Aug 2021 16:50:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.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 kqss498zadfW for ; Thu, 26 Aug 2021 16:50:09 -0700 (PDT)
Received: from mail-qv1-xf29.google.com (mail-qv1-xf29.google.com [IPv6:2607:f8b0:4864:20::f29]) (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 EE9273A17AD for ; Thu, 26 Aug 2021 16:50:08 -0700 (PDT)
Received: by mail-qv1-xf29.google.com with SMTP id g11so3087306qvd.2 for ; Thu, 26 Aug 2021 16:50:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:from:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=dmjEd1CZgvk1Y201UhqXLBy2yhe2mqYyRg90QDTHdDo=; b=MEvBfGGbL2Gx0Ch35/awctKnXTA/MrdyUZunCdNFPnj2ytCndBUQZFPyKiY7D+4C9S aUtS7UemQZSBTIWfow+si0JKCSRuepX8dVeJtWPMgapbVCd2c60UjhrTy7rZ0KgEI+Oj RxFydGf87mLV2bxo5XsK0fqE4FsWNQqItc7OPObcaf2UbwOrMABMa7aiHpehZicGVP08 AqpGw0cGH0+usknrR4qCP0+vdl9dBSFwjXFKXD8zpnvy3m4HlMRM5jg4R/UsBxdsuHqb yBp3voxvd8ROWFSdi1KRivn8cLBeg/tvUamqZjeDyw4mILnYTvG9zzezpRdi1yVjmgqj mUrA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=dmjEd1CZgvk1Y201UhqXLBy2yhe2mqYyRg90QDTHdDo=; b=LpvMLYH4B44G/GiW4RV6zxGr4focXZWfjDXMy2MvO2rpT0JUYFxJ9GnfwGEhHJsP9O nTjVSdiVbp6iAAx5ZhTfkhFGSgONBKafage+CKtJENO7TiSM3v/q+8Eqaxl64ZGF8VwW YsA6lIqG15QUaJg4vOF/R5PrkdOzioV7MmWl6kheCRXwpkcDlXegliiaLCiBOx2JWp9o WR4HnSPaahUc1pr8Yw5XUoNG8Zs4rQrbAQtFqnFDN9bkol5YJkMMfgTYNbM7GQAymizv 7V1Bd3ha9vQ2C82Klkn/djsfLfql0/d96jZNWRaB7oaJ2kpsKtmz40qEBClKNoCYzXH8 JCdA==
X-Gm-Message-State: AOAM5330ek3hABMmU2nuG+jjyqkTGTqL5ohCxU9un+LKjB8DoYTMkqda JtNKeUmaURczH84mCZjT/ekW+jZeLR6RqIwC
X-Google-Smtp-Source: ABdhPJzRmkobhg4vmvY0TNgw0urQ7EqXokYmL5aePvJP6nudA8MMlI7WmAx0Reld0gnsxaszJhN9VQ==
X-Received: by 2002:ad4:58ea:: with SMTP id di10mr7055595qvb.60.1630021806267;  Thu, 26 Aug 2021 16:50:06 -0700 (PDT)
Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id f20sm3378156qka.64.2021.08.26.16.50.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 26 Aug 2021 16:50:05 -0700 (PDT)
From: Michael StJohns 
To: Brian E Carpenter , Mark Nottingham 
Cc: "rfced-future@iab.org" 
References: <2512c470-1721-08d9-b73f-f66248e585ce@nthpermutation.com> <6DD9248A-9E94-4CB9-A3E6-E79B66644545@mnot.net>  <13c56879-192f-5ca7-ca51-590fa75d8587@nthpermutation.com>
Message-ID: 
Date: Thu, 26 Aug 2021 19:50:04 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <13c56879-192f-5ca7-ca51-590fa75d8587@nthpermutation.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Rfced-future] Creation/dissolution
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Aug 2021 23:50:11 -0000

On 8/26/2021 7:35 PM, Michael StJohns wrote:
> On 8/26/2021 7:01 PM, Brian E Carpenter wrote:
>> Agreed, but this omits the IRTF and the Independent Series and that 
>> isn't OK.
>>
>> Also - I take your point about IESG v IETF, but I think the IESG must 
>> obtain IETF input for something this important. So "IESG after 
>> consulting the IETF" or something like that.
>
> I actually meant IESG vice IETF.  And community stands in for what I 
> think you mean by IETF above.
>
> Mike
>
>
Drat -

Also, do you mean to give the ISE and Colin veto over the creation or 
dissolution of the process?  Mutual agreement means unanimous agreement 
in this case, not a vote of 2 to 1 or 3-2.

Neither the ISE nor the IRTF chair are selected by the community, but by 
the IAB.   While their needs and issues will be considered in the RSWG 
and RSAB, it's pretty clear that the IAB holds the reins for both of 
those positions and it's unclear why the IAB should get three votes here.

Later, Mike

ps - alternately, a 2/3 vote of every Nomcom selected participant (e.g. 
IETF chair, ADs, IAB members, LLC board, IETF Trust - am I forgetting 
one?) might be an alternative to the mutual agreement of the various boards.




From nobody Thu Aug 26 16:56:15 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 801523A1829 for ; Thu, 26 Aug 2021 16:56:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=jCVr4sVC; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=s17M3esw
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 uKpLix8fwt3X for ; Thu, 26 Aug 2021 16:56:07 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD6CF3A1827 for ; Thu, 26 Aug 2021 16:56:07 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 52BFA5C01B2; Thu, 26 Aug 2021 19:56:04 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 26 Aug 2021 19:56:04 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=y NwNhMoeqQtyGVKoQlyXbJolg3Fj/si96B1rzpCJTzI=; b=jCVr4sVCmv47u6kCa 5nLQL2jd/Z36gknEbvwCTu+zdGHgKUte2tw37lpvn9GFQy+UgZtyoiZCUIdp0OFY 4N2SpDPvnQOJQX+NA6RqczBvk7JyyCBwZ2lST1tn1JgRQ4NLMcIn7dKsi0YrPICs VZmLwX4Tq/LdkIxHENk4w+CK6Rm5h3xL+H4f/icovhZDIqDACXtr77y93cXNPqzv z3rI5GidJanG8WFsC9vAZvoqxnoonrubXhD/J6DCdoAIQFwrWC7q27TZntq4PV5r IAVDSjPRsYklgFFpNpqEOAV3ClNOFjN4hHkj2Vj3kP2dASIOVECbJjvR9e0zlYX2 PWrTA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=yNwNhMoeqQtyGVKoQlyXbJolg3Fj/si96B1rzpCJT zI=; b=s17M3esw342G+0Af0x9rPNOh7tceNEyKoeqCE8oIidNhsVCCYayLqoLLp 30Dytqyj+41WmJ9lDFAGt8FlmZAM7+l+OX1IlzxTeqKozj1RDnoDBILdLXqWt4EU MweKNQQK3uqt3pAkk9RQJm5Lzxi0de3ElFNLOtgLGDy4h8jj4OTywF0VfMUIgiXi ZcYXKty8Tih/ILfRsWLJZxfuMMG6mL4gIRkTCPj0RUM8fftYOlISAL/9cH4ijS18 vPXcy/+/01sI3q8B1RqDIVNUxFlZD/Zrwd/ELPGXsiwmy8FiA13hC1jxzAUQRkIT 41+oWI0/QHvr3yI5R8J4drtWS0xmw==
X-ME-Sender:  
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudduvddgvdekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeevffffhfduteevvefhueffieegtdeutdehffeltefffedttdeggeejheeiueet teenucffohhmrghinhepmhhnohhtrdhnvghtnecuvehluhhsthgvrhfuihiivgeptdenuc frrghrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvth
X-ME-Proxy:    
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 26 Aug 2021 19:56:00 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Mark Nottingham 
In-Reply-To: 
Date: Fri, 27 Aug 2021 09:55:56 +1000
Cc: Brian E Carpenter , "rfced-future@iab.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <5D7867A3-1687-4AAE-A621-01AFEC588B1C@mnot.net>
References: <2512c470-1721-08d9-b73f-f66248e585ce@nthpermutation.com> <6DD9248A-9E94-4CB9-A3E6-E79B66644545@mnot.net>  <13c56879-192f-5ca7-ca51-590fa75d8587@nthpermutation.com> 
To: Michael StJohns 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: 
Subject: Re: [Rfced-future] Creation/dissolution
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Aug 2021 23:56:14 -0000

Mike,

> On 27 Aug 2021, at 9:50 am, Michael StJohns  =
wrote:
>=20
> Neither the ISE nor the IRTF chair are selected by the community, but =
by the IAB.   While their needs and issues will be considered in the =
RSWG and RSAB, it's pretty clear that the IAB holds the reins for both =
of those positions and it's unclear why the IAB should get three votes =
here.

I'm having trouble interpreting this comment -- if the IAB were a single =
company, country or other interest, I could see where you're coming =
from, but they're selected from the community, by the community,  as a =
whole. They, in turn, select the IRTF Chair and ISE from the community, =
based upon community input; presumably, both of those people are =
respected by the community and act independently of the IAB. So I think =
it's a long stretch to see this as the IAB getting three votes -- and =
even if you view it that way, what kind of bias is being introduced?

Cheers,

--
Mark Nottingham   https://www.mnot.net/


From nobody Thu Aug 26 16:59:51 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA953A1857 for ; Thu, 26 Aug 2021 16:59:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 vVgxBIWe0tyj for ; Thu, 26 Aug 2021 16:59:43 -0700 (PDT)
Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (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 046EE3A185B for ; Thu, 26 Aug 2021 16:59:43 -0700 (PDT)
Received: by mail-il1-x12a.google.com with SMTP id r6so5122607ilt.13 for ; Thu, 26 Aug 2021 16:59:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dIs+4C5weAd3SMBSiZWbc1vqSzjmMV5MXBJlU0iFdZA=; b=yoA39l5qj8A6eGxtb+BVxDz9Zl15pOKyrdv7sZn8o7Z0ZxuMH4BvHG+OGimExhaMBI dl6Aml9PiJlDnRiKTIJYsY1RMu+bO9O4FXqsZ5qysHv/I4dqxmqjO6kHRplEwv5Ss3p9 BSUU6Hhc1W4GrUKoFhObozTTllSTa4YLUEVTnVdjuJcMIah1wxlmcvNOVKhzbyqehgAe r+NfVFw+l/XuE2RLTVoghtWLIis79ecA9hDc8RfK+tgYnQwus5eWVtcWHY9XTj8AIl6E ld07jocipEBDZrQgFO5iD/pPgXDnAYVTGucJxSYmCYR074P1Jcw2BGG1u7s35Le/gVfM /uag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dIs+4C5weAd3SMBSiZWbc1vqSzjmMV5MXBJlU0iFdZA=; b=TyWxwBYmjxMWwZRDY16UJ9EW2rnNeowpgr9o4ZeL5gS3tPaoqK+X58+vpTO9PQsihr 3fZ2Sj24oKXH9uhjcHZD+1dbpzLOd1/HosB6UCptWuHjpBAx5UfSf/BvsmFxr/U5BoKR CbIHnfAK40Ru7NsS4F0bz98v5HdJBWu2FojexjvhgA25wHc9378ShEN0HFVgksbjT/A8 tUyhP2O+pwdFI+YjMjr1Gg4TVn42PXuuS6rUdfW5oOlrnKakB2+qdIih8ZfyT9OAlsux 09oDEFNH0fpoX/g8ZjGJV6RNwN+sdiN84/3DfG39Gt2DH0+3kjyPay894rOxmocMLZMR QREw==
X-Gm-Message-State: AOAM532KB3w1SP6NoMtYKQJ93vFQH/i98mLIxXaTuDpGiLuBmHU9BPdv G5ZnjwU2FGDV29wW/Dw7DHzPnXTMMRYoPTDShPBUAw==
X-Google-Smtp-Source: ABdhPJz9hYjDY20kXseUpJNzPzAquaIam5Nyy2W6yiJy7iBmZKeyaaIzbH8yTlSeCFpwXvZATqu1NuruOddJsSXdI1c=
X-Received: by 2002:a05:6e02:5c8:: with SMTP id l8mr4646106ils.282.1630022381165;  Thu, 26 Aug 2021 16:59:41 -0700 (PDT)
MIME-Version: 1.0
References: <2512c470-1721-08d9-b73f-f66248e585ce@nthpermutation.com> <6DD9248A-9E94-4CB9-A3E6-E79B66644545@mnot.net>  <13c56879-192f-5ca7-ca51-590fa75d8587@nthpermutation.com> 
In-Reply-To: 
From: Eric Rescorla 
Date: Thu, 26 Aug 2021 16:59:05 -0700
Message-ID: 
To: Michael StJohns 
Cc: Brian E Carpenter , Mark Nottingham ,  "rfced-future@iab.org" 
Content-Type: multipart/alternative; boundary="00000000000001786805ca7f2931"
Archived-At: 
Subject: Re: [Rfced-future] Creation/dissolution
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Aug 2021 23:59:49 -0000

--00000000000001786805ca7f2931
Content-Type: text/plain; charset="UTF-8"

I'm a little unclear on what problem is being solved for here.

Taking a step back, suppose that the RSAWG and RSAB jointly agreed on some
restructuring of the
process (e.g., dissolving the RSAWG and reverting control to the IAB),
would they be able to do so
without this mechanism?

-Ekr


On Thu, Aug 26, 2021 at 4:50 PM Michael StJohns 
wrote:

> On 8/26/2021 7:35 PM, Michael StJohns wrote:
> > On 8/26/2021 7:01 PM, Brian E Carpenter wrote:
> >> Agreed, but this omits the IRTF and the Independent Series and that
> >> isn't OK.
> >>
> >> Also - I take your point about IESG v IETF, but I think the IESG must
> >> obtain IETF input for something this important. So "IESG after
> >> consulting the IETF" or something like that.
> >
> > I actually meant IESG vice IETF.  And community stands in for what I
> > think you mean by IETF above.
> >
> > Mike
> >
> >
> Drat -
>
> Also, do you mean to give the ISE and Colin veto over the creation or
> dissolution of the process?  Mutual agreement means unanimous agreement
> in this case, not a vote of 2 to 1 or 3-2.
>
> Neither the ISE nor the IRTF chair are selected by the community, but by
> the IAB.   While their needs and issues will be considered in the RSWG
> and RSAB, it's pretty clear that the IAB holds the reins for both of
> those positions and it's unclear why the IAB should get three votes here.
>
> Later, Mike
>
> ps - alternately, a 2/3 vote of every Nomcom selected participant (e.g.
> IETF chair, ADs, IAB members, LLC board, IETF Trust - am I forgetting
> one?) might be an alternative to the mutual agreement of the various
> boards.
>
>
>
> --
> Rfced-future mailing list
> Rfced-future@iab.org
> https://www.iab.org/mailman/listinfo/rfced-future
>

--00000000000001786805ca7f2931
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I'm a little unclear on what problem is being sol=
ved for here.

Taking a step back, suppose that the=
 RSAWG and RSAB jointly agreed on some restructuring of the
proce=
ss (e.g., dissolving the RSAWG and reverting control to the IAB), would the=
y be able to do so
 without this mechanism?

-Ekr


On Thu, Aug 26, 2021 at 4:50 PM Michael St=
Johns <msj@n=
thpermutation.com> wrote:
On 8/26/2021 7:35 PM, Michael StJohns wrote:

> On 8/26/2021 7:01 PM, Brian E Carpenter wrote:

>> Agreed, but this omits the IRTF and the Independent Series and tha=
t 

>> isn't OK.

>>

>> Also - I take your point about IESG v IETF, but I think the IESG m=
ust 

>> obtain IETF input for something this important. So "IESG afte=
r 

>> consulting the IETF" or something like that.

>

> I actually meant IESG vice IETF.=C2=A0 And community stands in for wha=
t I 

> think you mean by IETF above.

>

> Mike

>

>

Drat -



Also, do you mean to give the ISE and Colin veto over the creation or 

dissolution of the process?=C2=A0 Mutual agreement means unanimous agreemen=
t 

in this case, not a vote of 2 to 1 or 3-2.



Neither the ISE nor the IRTF chair are selected by the community, but by 
the IAB.=C2=A0=C2=A0 While their needs and issues will be considered in the=
 RSWG 

and RSAB, it's pretty clear that the IAB holds the reins for both of 
those positions and it's unclear why the IAB should get three votes her=
e.



Later, Mike



ps - alternately, a 2/3 vote of every Nomcom selected participant (e.g. 
IETF chair, ADs, IAB members, LLC board, IETF Trust - am I forgetting 

one?) might be an alternative to the mutual agreement of the various boards=
.







-- 

Rfced-future mailing list

Rfced-future@iab.=
org

https://www.iab.org/mailman/listinfo/rfced-future




--00000000000001786805ca7f2931--


From nobody Thu Aug 26 17:10:52 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 164333A1932 for ; Thu, 26 Aug 2021 17:10:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.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 M_CanX_04mKI for ; Thu, 26 Aug 2021 17:10:43 -0700 (PDT)
Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 39DC73A192F for ; Thu, 26 Aug 2021 17:10:38 -0700 (PDT)
Received: by mail-qt1-x82e.google.com with SMTP id s32so4019963qtc.12 for ; Thu, 26 Aug 2021 17:10:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=9B8mMKwp02hlAHK6pn42+sVkA3nFi/NynNQtRY+uxzk=; b=s9PVbjAMGDelGQywNIAxmOvib32lFlgSZ6FhlpiyHYmhnlgrvAwfD0AhCVLDnhhdQw GEoXo5bpXgtio9vGk2/RwyHX+w2NESsSSvqVWbh79cVXxT7FHOxYctBQHtM551Qf9xx5 XBmxTJRlLae5t9xjnBvfgz4KOq7foc9cjYB6VbMex1aHW303MIMij/m/PiZxE9CY1M+q NvPb2KGDuYyw3kk4RMlH4fmZmkSXyIS6J2VKZiedNz77L6I8yTQmAjgeTFOiS/i93DBM ESXTMyGDqiK+uIaJxWXx5HBKSXHIPRTSP9h8aU057fP4sZeXkGTCt/YpqaLkrk/QqRDV eLAQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=9B8mMKwp02hlAHK6pn42+sVkA3nFi/NynNQtRY+uxzk=; b=Mgi9vFlmdJ8obPEQ2589s9kXjI1IDNomCKzX6o4wm+wfpm/TRegwNJB+rzhlyz08wB a47iDGqAqDQJ3IUJ8q+OBQKWegWoMa9iEjyO9ehA23+QSHIGH+bDJLqeMPZDh9TAPf6g uxb95Ilv3kvLaKKIY+rPaCPq0yrQcDAYWfLCh2AZagB4RUyij9im0l5JNJIcXT2/mGbU 6X8XYHyTC9Pww04vsODF9FQW8fO6sSrdtapTS7vjMysNN0G/UGoAoZDpThgX+1kv6cUg f6+Cn0Hv+YjCFx0+1SLUgdcV3jZIRcYa9leOMSVobSJAFnRWV4cRtFl22RuBkwoaVoGP GA0g==
X-Gm-Message-State: AOAM533/TMFQa8/CXskgyx954cV2VLKlniRU1Kw9RxCwON7phsbDQvWa zMaRCPfm0EP3/hWe81FK+xZdNoPLWUT4B7kd
X-Google-Smtp-Source: ABdhPJwdXWMwevuQWOVuXKUcGJgoHz21/To5lSsclKB04u818fMzSlhu+7czAsAeHn4Tq43Kvp/rDg==
X-Received: by 2002:ac8:58d3:: with SMTP id u19mr6143904qta.306.1630023035431;  Thu, 26 Aug 2021 17:10:35 -0700 (PDT)
Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id j18sm3727481qkg.31.2021.08.26.17.10.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 26 Aug 2021 17:10:34 -0700 (PDT)
To: Eric Rescorla 
Cc: Brian E Carpenter , Mark Nottingham , "rfced-future@iab.org" 
References: <2512c470-1721-08d9-b73f-f66248e585ce@nthpermutation.com> <6DD9248A-9E94-4CB9-A3E6-E79B66644545@mnot.net>  <13c56879-192f-5ca7-ca51-590fa75d8587@nthpermutation.com>  
From: Michael StJohns 
Message-ID: 
Date: Thu, 26 Aug 2021 20:10:33 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------8A8B95E1713C132E6E6B31B8"
Content-Language: en-US
Archived-At: 
Subject: Re: [Rfced-future] Creation/dissolution
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Aug 2021 00:10:49 -0000

This is a multi-part message in MIME format.
--------------8A8B95E1713C132E6E6B31B8
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

On 8/26/2021 7:59 PM, Eric Rescorla wrote:
> I'm a little unclear on what problem is being solved for here.
>
> Taking a step back, suppose that the RSAWG and RSAB jointly agreed on 
> some restructuring of the
> process (e.g., dissolving the RSAWG and reverting control to the IAB), 
> would they be able to do so
> without this mechanism?

I don't see how.  The authority we're delegating is over the RFC series 
process, not the meta process that created them.

>
> -Ekr
>
>
> On Thu, Aug 26, 2021 at 4:50 PM Michael StJohns 
> > wrote:
>
>     On 8/26/2021 7:35 PM, Michael StJohns wrote:
>     > On 8/26/2021 7:01 PM, Brian E Carpenter wrote:
>     >> Agreed, but this omits the IRTF and the Independent Series and
>     that
>     >> isn't OK.
>     >>
>     >> Also - I take your point about IESG v IETF, but I think the
>     IESG must
>     >> obtain IETF input for something this important. So "IESG after
>     >> consulting the IETF" or something like that.
>     >
>     > I actually meant IESG vice IETF.  And community stands in for
>     what I
>     > think you mean by IETF above.
>     >
>     > Mike
>     >
>     >
>     Drat -
>
>     Also, do you mean to give the ISE and Colin veto over the creation or
>     dissolution of the process?  Mutual agreement means unanimous
>     agreement
>     in this case, not a vote of 2 to 1 or 3-2.
>
>     Neither the ISE nor the IRTF chair are selected by the community,
>     but by
>     the IAB.   While their needs and issues will be considered in the
>     RSWG
>     and RSAB, it's pretty clear that the IAB holds the reins for both of
>     those positions and it's unclear why the IAB should get three
>     votes here.
>
>     Later, Mike
>
>     ps - alternately, a 2/3 vote of every Nomcom selected participant
>     (e.g.
>     IETF chair, ADs, IAB members, LLC board, IETF Trust - am I forgetting
>     one?) might be an alternative to the mutual agreement of the
>     various boards.
>
>
>
>     -- 
>     Rfced-future mailing list
>     Rfced-future@iab.org 
>     https://www.iab.org/mailman/listinfo/rfced-future
>     
>


--------------8A8B95E1713C132E6E6B31B8
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 8/26/2021 7:59 PM, Eric Rescorla
      wrote:

    

    

      
      

        
I'm a little unclear on what problem is being solved for
          here.

        


        

        
Taking a step back, suppose that the RSAWG and RSAB jointly
          agreed on some restructuring of the

        
process (e.g., dissolving the RSAWG and reverting control
          to the IAB), would they be able to do so

        
 without this mechanism?

        

      

    

    
I don't see how.  The authority we're delegating is over the RFC
      series process, not the meta process that created them.

    

    

      

        


        

        
-Ekr

        


        

      

      

      

        
On Thu, Aug 26, 2021 at 4:50
          PM Michael StJohns <msj@nthpermutation.com>
          wrote:

        

        
On
          8/26/2021 7:35 PM, Michael StJohns wrote:

          > On 8/26/2021 7:01 PM, Brian E Carpenter wrote:

          >> Agreed, but this omits the IRTF and the Independent
          Series and that 

          >> isn't OK.

          >>

          >> Also - I take your point about IESG v IETF, but I
          think the IESG must 

          >> obtain IETF input for something this important. So
          "IESG after 

          >> consulting the IETF" or something like that.

          >

          > I actually meant IESG vice IETF.  And community stands in
          for what I 

          > think you mean by IETF above.

          >

          > Mike

          >

          >

          Drat -

          

          Also, do you mean to give the ISE and Colin veto over the
          creation or 

          dissolution of the process?  Mutual agreement means unanimous
          agreement 

          in this case, not a vote of 2 to 1 or 3-2.

          

          Neither the ISE nor the IRTF chair are selected by the
          community, but by 

          the IAB.   While their needs and issues will be considered in
          the RSWG 

          and RSAB, it's pretty clear that the IAB holds the reins for
          both of 

          those positions and it's unclear why the IAB should get three
          votes here.

          

          Later, Mike

          

          ps - alternately, a 2/3 vote of every Nomcom selected
          participant (e.g. 

          IETF chair, ADs, IAB members, LLC board, IETF Trust - am I
          forgetting 

          one?) might be an alternative to the mutual agreement of the
          various boards.

          

          

          

          -- 

          Rfced-future mailing list

          Rfced-future@iab.org

          https://www.iab.org/mailman/listinfo/rfced-future

        

      

    

    


    

  


--------------8A8B95E1713C132E6E6B31B8--


From nobody Thu Aug 26 17:16:26 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE8663A19E0 for ; Thu, 26 Aug 2021 17:16:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.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 RK4PrH7pTjSy for ; Thu, 26 Aug 2021 17:16:19 -0700 (PDT)
Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (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 A325B3A19E3 for ; Thu, 26 Aug 2021 17:16:19 -0700 (PDT)
Received: by mail-qk1-x732.google.com with SMTP id c10so5408707qko.11 for ; Thu, 26 Aug 2021 17:16:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=is+ZGD/ExS0nMJPdawfBLt9ndHpmaYnJNzGPNV45KMI=; b=Rf6lqRmDmof0+zAP2ixLkOOkewZzlH+7/VoYKZu/tJF7H/S1FAyf4JSbCIrIa7ALrt ELZlB9PJ6ED17BARjVmIBXSi0EargqxRe9Qvxrnrh12B4b4U70M26TpJKwzAJeGhU2J3 BFZVg0lhBQymRqIKsPNR478rZ7WQTVw3hwK1d9/rIHfxJa+TOHKX2YOR4AyIUZY7Zf3T qayrkZ+joEU0EyvvyOsGYLeHcYNAuRx0ws0PB6NvPj4UdVOfWa+0nGkJRl/nGxMbxkcg h5Hyaumo/gQS4EmrD/8ayZmpsgf7UKI6TJSg64LPAFQ1W7+5y0uFrQPZ3N8N7HuG9lRm qjWA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=is+ZGD/ExS0nMJPdawfBLt9ndHpmaYnJNzGPNV45KMI=; b=QwRcqQnDdc5BAwaM5i48G669FF2dqHoAx8CfEAG5mCkUudiw1xhBw75pgZ1sqEucXE YLvHLxkHDY7HvcGSG39JhQinHiM6IClE+udNaoncx5S2luVWUGCtMescQNwgs/fY93gs XbW6LBqtHG531uE5vKU8labDJVhx7jJo7ixAlLmpX0SXVQbYnqrXOPYXeWLGTy7LYXjH XA05Y0Mkyw3QormEdGNFD1O6FDABY2jbtxd7k2UZ+e7D1ftJs1CwBQKDAlzsicrd0thM cACsfJuLfDMAAuKpZnl8NnlJ0DJVwUIlhHGUJVOI96SMiRR8J+KRVupFITCB5LxjTIrl 2lOw==
X-Gm-Message-State: AOAM533D9rxqvFeWjYWD2JdKD8eR/yZCMJJBj+mrcUGk70YHUPmS2THD PeCDVEYYXR5de6l5aSPwSKdmRE3AeouwwKGC
X-Google-Smtp-Source: ABdhPJxIfmfW3nxpT65+ESjco2FXnSpKbHZyaz+lx/RdaUKNyJlWxT4LkcpZ0Pvv5K5eWin900ulVg==
X-Received: by 2002:a37:2f47:: with SMTP id v68mr6718144qkh.190.1630023376997;  Thu, 26 Aug 2021 17:16:16 -0700 (PDT)
Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id m188sm3802367qkc.99.2021.08.26.17.16.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 26 Aug 2021 17:16:16 -0700 (PDT)
To: Mark Nottingham 
Cc: Brian E Carpenter , "rfced-future@iab.org" 
References: <2512c470-1721-08d9-b73f-f66248e585ce@nthpermutation.com> <6DD9248A-9E94-4CB9-A3E6-E79B66644545@mnot.net>  <13c56879-192f-5ca7-ca51-590fa75d8587@nthpermutation.com>  <5D7867A3-1687-4AAE-A621-01AFEC588B1C@mnot.net>
From: Michael StJohns 
Message-ID: <0324d8dc-7be8-1b8b-ccaf-fc26a8d08b31@nthpermutation.com>
Date: Thu, 26 Aug 2021 20:16:15 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <5D7867A3-1687-4AAE-A621-01AFEC588B1C@mnot.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Rfced-future] Creation/dissolution
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Aug 2021 00:16:25 -0000

On 8/26/2021 7:55 PM, Mark Nottingham wrote:
> Mike,
>
>> On 27 Aug 2021, at 9:50 am, Michael StJohns  wrote:
>>
>> Neither the ISE nor the IRTF chair are selected by the community, but by the IAB.   While their needs and issues will be considered in the RSWG and RSAB, it's pretty clear that the IAB holds the reins for both of those positions and it's unclear why the IAB should get three votes here.
> I'm having trouble interpreting this comment -- if the IAB were a single company, country or other interest, I could see where you're coming from, but they're selected from the community, by the community,  as a whole. They, in turn, select the IRTF Chair and ISE from the community, based upon community input; presumably, both of those people are respected by the community and act independently of the IAB. So I think it's a long stretch to see this as the IAB getting three votes -- and even if you view it that way, what kind of bias is being introduced?

I don't doubt that either of these folk are respected by the community, 
nor that they effectively act independently of the IAB - currently.   
But in the final analysis, they are not appointed by the community 
regardless of how much input the IAB gets on them.

It's not a matter of bias in the current instance, but as both the ISE 
and the IRTF chair serve at the pleasure of the IAB, if both of them 
disagreed with the other three bodies, the IAB could simply replace them 
with more tractable members.  That's a capability of the way those two 
people are appointed, and needs to be considered in any fail safe 
dissolution mechanism we put in. So maybe not three votes, but certainly 
an ability to remove two votes that disagree with the IAB.

Later, Mike


>
> Cheers,
>
> --
> Mark Nottingham   https://www.mnot.net/
>


From nobody Thu Aug 26 17:20:00 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 689A33A1A26 for ; Thu, 26 Aug 2021 17:19:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.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 HC2Rc3y4jeNa for ; Thu, 26 Aug 2021 17:19:56 -0700 (PDT)
Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 D50643A1A1C for ; Thu, 26 Aug 2021 17:19:41 -0700 (PDT)
Received: by mail-qt1-x831.google.com with SMTP id s32so4034263qtc.12 for ; Thu, 26 Aug 2021 17:19:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:from:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=dLHdndl5GvzzF37ovUx9OrcTbSt5SBsQ2S1eF9s0oTw=; b=CzhlO01QXxXolHTsBS7HfZbdi+eOdk+n4TVZGsGGLtbtdvRTZJ4TXxU3Tl8oUEnk3q V8lY+ieIMRfQRSIQqqA9vA9ESu0/n7cuylhFT87DH/bmqwo56hTrg2PvxQiNCR67MzGG 5F5rW9XMM2Qi8KL1gFLs98k1GLh7+uotK2VtQrk/DIS1GjG/WVSQVMz19tIBGwnXHRNe xbWskXPtwpJjvfDnqbeVMZDmHFReAOwFEHsB4qHrk6utGeCoyIEhrpVnbhqV7fMdM9GB GSJFV/HSnipXXSSOZOfMwLTT1G3ZYFt3wYvpMXxcw51hL5tT38LfbIG7ExvfQ0+tX3j8 kYTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=dLHdndl5GvzzF37ovUx9OrcTbSt5SBsQ2S1eF9s0oTw=; b=Q+gBdlnaF2Z/8NSIJe0Dia2DRompGSU6C8bTPfpZMUU/k58rCml6e/elDzX56azmAb SnVVvCc3twC3xF8uE2clPs8I3lmBAzvZgyP8puuhNiUCv0nNiNjt5TLmsO7vMdaPfufn fup2q3WogrWJux4GwO0fGq+i3HxPmv5lLFPVUh9bCwKnEg68XFi61l7hxCQTmMm4FTro 7ttF4SGhbdFu1srDvcXcFrLlaLTAQ7inKj1qVyuLnzE3dmn0boL5CgFnSl5FlMRsfqYR ATNeMKFIQByrGeb3aFQET59yU73sh8DZ/EiHD5+K9KvJHSnK3yAq91Yt24wD6KHfApfJ WuIQ==
X-Gm-Message-State: AOAM532Cndwl9igtZmBOLh8n5Jxqy2wVftJCAZ8WNzRz7c83tKWcwd7r MZ+YWeI0Ks2EKn77nfCZNzOD+wuJKOGVHTRj
X-Google-Smtp-Source: ABdhPJwTNDltYp3/jlvVfBhOUZ7RnLnPHYJ/wryc1UMt5q0Aiz3ACVmPLyLmlmcIjD3w5QC7UDZyEg==
X-Received: by 2002:ac8:5848:: with SMTP id h8mr6172284qth.254.1630023579295;  Thu, 26 Aug 2021 17:19:39 -0700 (PDT)
Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id c20sm3574532qkk.121.2021.08.26.17.19.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 26 Aug 2021 17:19:38 -0700 (PDT)
From: Michael StJohns 
To: Eric Rescorla 
Cc: Brian E Carpenter , Mark Nottingham , "rfced-future@iab.org" 
References: <2512c470-1721-08d9-b73f-f66248e585ce@nthpermutation.com> <6DD9248A-9E94-4CB9-A3E6-E79B66644545@mnot.net>  <13c56879-192f-5ca7-ca51-590fa75d8587@nthpermutation.com>   
Message-ID: <2499c847-a6ef-2a06-a929-7538f8928aa9@nthpermutation.com>
Date: Thu, 26 Aug 2021 20:19:37 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Rfced-future] Creation/dissolution
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Aug 2021 00:19:59 -0000

On 8/26/2021 8:10 PM, Michael StJohns wrote:
> On 8/26/2021 7:59 PM, Eric Rescorla wrote:
>> I'm a little unclear on what problem is being solved for here.
>>
>> Taking a step back, suppose that the RSAWG and RSAB jointly agreed on 
>> some restructuring of the
>> process (e.g., dissolving the RSAWG and reverting control to the 
>> IAB), would they be able to do so
>> without this mechanism?
>
> I don't see how.  The authority we're delegating is over the RFC 
> series process, not the meta process that created them.
>
Sorry - I hit send too early.  The other consideration is to the IESG 
and the LLC who may not want the process to revert to the IAB for 
whatever reason, or at least don't want the RSAB or RSWG to be in 
control of where it lands.

The members of the RSAB and RSWG can certainly decide they don't want to 
play anymore, but the remedy for that is replacement of the RSWG chairs 
and the RSAB members, not allowing those who have given up on the 
process to kill the process.

Mike


>>
>> -Ekr
>>



From nobody Thu Aug 26 17:21:04 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0BD73A1A3B for ; Thu, 26 Aug 2021 17:21:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.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 ETyJwhNWuapf for ; Thu, 26 Aug 2021 17:20:57 -0700 (PDT)
Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 6C5823A1A38 for ; Thu, 26 Aug 2021 17:20:57 -0700 (PDT)
Received: by mail-qk1-x72d.google.com with SMTP id t190so5462859qke.7 for ; Thu, 26 Aug 2021 17:20:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=j7GNWp81qjsK0yX5XfO/K4uaUdBkt+Qd3FEjPlr36Hk=; b=JCd/HfB672TL3xDxbFBPXyXGKzpWeNXsd8eF1oRPbUIC90BKuThzo7J0+np5sZcv+E 28Jzz2eevTE0+j91YePQuZxuvL3cbpR/YQiGY7FH420T538vyRtFYpNcXaMg00ftkSXs 6jAiW9aYf09GGeJ6nyKOaWzc8+/CCes+Q0hoZwbGw1pRFXJeCEJV/CVzZ3msqzVTLq7g r0LlChXJOWZw9HZBDpiHTKRZSmJa4qI3vXRSzZSjfxz4dKYAhfaSx/bB8M6VxXGSFbLI 7aidob8H+LcOlmNxfmoAUtw5bvZG9S58GcVTOopg+iceczBOUPkIaTlhHCRyav4g8Qy0 jwhg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=j7GNWp81qjsK0yX5XfO/K4uaUdBkt+Qd3FEjPlr36Hk=; b=ai7pbaqZLPs7zEFtUbU/cheSqaJUB6YIbUT6TAbVzXQ3ruDCO6oAEchkugec1V3vVl A311ZdZpItR/uCup8D9ChSpCFWK8TSsPOhKxLmQkV7iL4PRWlexTA3JaB+ZhCTFNMpj0 EbXVGeL7vinig0gLFJ3sJDCwGiH6JAnkNbMkgYnMGY5c3lxEI6dGY7qvLwl85gBIfMl3 XFPCpxeqIz862TLQeEEymOHhx04Gv3/KsAozqW5ZFIMbWuA5TcaxFZtAs2sBLmOnqXJ5 8AAzpCGtHrF0+/WCBpZCjO4VPf0WEfW0KzstpKxq8TZ/Yc2WUiVjp+X8QWot7q414U+R DCSg==
X-Gm-Message-State: AOAM530klcEqMpUtJOGajLDtcnuY1R8yHAX974i1Dg/+FHq4OctU4O8l VufTGwh5ppKr3s+k4PJ96+1ZvXM3JOT9HKmF
X-Google-Smtp-Source: ABdhPJxbDANZGsLXxhlAuLxbZdVbxZA6rpzWHDdJ5jxIwpHXERazoO/xBrbbYKQIq2lqNkol1/r9SQ==
X-Received: by 2002:a05:620a:2849:: with SMTP id h9mr6674205qkp.69.1630023654064;  Thu, 26 Aug 2021 17:20:54 -0700 (PDT)
Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id o19sm35110qtv.85.2021.08.26.17.20.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 26 Aug 2021 17:20:53 -0700 (PDT)
To: Mark Nottingham 
Cc: "rfced-future@iab.org" 
References: <2512c470-1721-08d9-b73f-f66248e585ce@nthpermutation.com> <6DD9248A-9E94-4CB9-A3E6-E79B66644545@mnot.net>
From: Michael StJohns 
Message-ID: <090d5fbd-d0f4-1f39-6546-bc7ee7128657@nthpermutation.com>
Date: Thu, 26 Aug 2021 20:20:52 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <6DD9248A-9E94-4CB9-A3E6-E79B66644545@mnot.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Rfced-future] Creation/dissolution
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Aug 2021 00:21:03 -0000

On 8/26/2021 6:38 PM, Mark Nottingham wrote:
>> On 27 Aug 2021, at 7:33 am, Michael StJohns  wrote:
>>
>> Here's a cut.  Somewhat legalistic, but provides the basis for fixing a problem if it exists.  Note that this is an all or nothing - this doesn't give the IAB/IESG/LLC the ability to direct changes the RFC  outside of the RSAB/RSWG process, but allows them to kill that process if necessary.
>>
>> ## Dissolution of the RSAB and RSWG
>>
>> By mutual agreement of the IAB, the IETF and the IETF LLC Board, and with the consensus of the community, this document creates the RSAB, RSWG and the Editorial series within the IETF framework. To provide for the possibility that the needs of the community may change over time, or are not being satisfied by the system and organization described herein, the IAB, the IETF and the IETF LLC Board when acting collectively with the consensus of the community reserve the authority to disestablish either or both of the RSAB and RSWG and to redirect the authorities and responsibilities assigned to those groups as necessary.
> I'm concerned that this might cause unnecessary strife
Could you explain that?   These terms tend to exist in most formally 
created bodies and in fact there's 4 paragraphs in the IETF LLC document 
on dissolution and how it happens.
> if it ever actually needs to be used; saying that the IETF rather than the IESG is problematic
Yup - I actually mean IESG here - good catch.
> because the only way to get an IETF position on something is to issue an RFC. Likewise, measuring the 'consensus of the community' has proven controversial, given the amorphous nature of the community in question.

Not really.   We publish the intent as broadly as we can, we invite 
comments, we respond to comments, and resolve comments and then the IAB, 
IESG and LLC review that and make a decision.   In some ways this would 
have been easier when we were part of the ISOC and indeed we probably 
need to include the ISOC as the place where an appeal of this decision 
would be heard.


>
> I'd suggest something like:
>
> This document creates the RSAB, RSWG and Editorial Series by mutual agreement of the IAB, the IESG and the IETF LLC Board, reflecting community consensus as established in the RFC Editor Future Development Program.

Except that we've already agreed that this requires a community call for 
consensus outside this self-selected body.   So its not "as established 
in....".


>   Change to the Editorial Series are managed through the process defined here. Changes to the responsibilities and authorities of the RSAB and RSWG (including dissolution) require mutual agreement of the IAB, IESG and IETF LLC Board, well as a community consensus established in a manner defined by the IAB.

We're delegating all of the responsibility and authority for the RFC 
series to the RSAB/RSWG - I'm not sure what changes to those would make 
sense other than dragging them back and parceling them out again.

>
> ... where 'a manner defined by the IAB' is open to other suggestions -- we just need to define who holds the ball for scoping rfced-future2 if the need arises.
>
> Cheers,
>
>
> --
> Mark Nottingham   https://www.mnot.net/
>


From nobody Thu Aug 26 18:30:09 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9F83A005F for ; Thu, 26 Aug 2021 18:30:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level: 
X-Spam-Status: No, score=-2.101 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, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 7MAp3f098aIo for ; Thu, 26 Aug 2021 18:30:01 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 044003A003D for ; Thu, 26 Aug 2021 18:30:00 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4GwhwS2XLzz6G972; Thu, 26 Aug 2021 18:30:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1630027800; bh=c7CrVoDLZjGujqEm+2oPti8pTMhiXXMn1L96wVQLOp8=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=DUsuCQOODU0Y2qUBJJKGm0ZUm2Nj1DXgkO6zg45MXJHPcb1slQhbDZn94RWk2l2++ beLSryyKhaINzeeS2DlN+4792Un6JkGqsQxcGFFrIrOzgvFXLHBdKO7VRZcmwBhjXg TWNph9EKz92csfcN1CGXdNVdC3WZVFKflyV/ujsU=
X-Quarantine-ID: 
X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net
Received: from [192.168.23.64] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (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 maila2.tigertech.net (Postfix) with ESMTPSA id 4GwhwR18B3z6G932; Thu, 26 Aug 2021 18:29:59 -0700 (PDT)
To: Eric Rescorla , Michael StJohns 
Cc: "rfced-future@iab.org" , Mark Nottingham 
References: <2512c470-1721-08d9-b73f-f66248e585ce@nthpermutation.com> <6DD9248A-9E94-4CB9-A3E6-E79B66644545@mnot.net>  <13c56879-192f-5ca7-ca51-590fa75d8587@nthpermutation.com>  
From: "Joel M. Halpern" 
Message-ID: <1681f1e3-81e2-9cf2-6c24-14f3562ca54e@joelhalpern.com>
Date: Thu, 26 Aug 2021 21:29:57 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [Rfced-future] Creation/dissolution
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Aug 2021 01:30:08 -0000

I had assumed that the problem being solved was how to recover if the 
RSWG / RSAB became non-functional.  Expecting the RSWG / RSAB to fix 
itself in that case seems unlikely.

Yours,
Joel

On 8/26/2021 7:59 PM, Eric Rescorla wrote:
> I'm a little unclear on what problem is being solved for here.
> 
> Taking a step back, suppose that the RSAWG and RSAB jointly agreed on 
> some restructuring of the
> process (e.g., dissolving the RSAWG and reverting control to the IAB), 
> would they be able to do so
> without this mechanism?
> 
> -Ekr
> 
> 
> On Thu, Aug 26, 2021 at 4:50 PM Michael StJohns  > wrote:
> 
>     On 8/26/2021 7:35 PM, Michael StJohns wrote:
>      > On 8/26/2021 7:01 PM, Brian E Carpenter wrote:
>      >> Agreed, but this omits the IRTF and the Independent Series and that
>      >> isn't OK.
>      >>
>      >> Also - I take your point about IESG v IETF, but I think the IESG
>     must
>      >> obtain IETF input for something this important. So "IESG after
>      >> consulting the IETF" or something like that.
>      >
>      > I actually meant IESG vice IETF.  And community stands in for what I
>      > think you mean by IETF above.
>      >
>      > Mike
>      >
>      >
>     Drat -
> 
>     Also, do you mean to give the ISE and Colin veto over the creation or
>     dissolution of the process?  Mutual agreement means unanimous agreement
>     in this case, not a vote of 2 to 1 or 3-2.
> 
>     Neither the ISE nor the IRTF chair are selected by the community,
>     but by
>     the IAB.   While their needs and issues will be considered in the RSWG
>     and RSAB, it's pretty clear that the IAB holds the reins for both of
>     those positions and it's unclear why the IAB should get three votes
>     here.
> 
>     Later, Mike
> 
>     ps - alternately, a 2/3 vote of every Nomcom selected participant (e.g.
>     IETF chair, ADs, IAB members, LLC board, IETF Trust - am I forgetting
>     one?) might be an alternative to the mutual agreement of the various
>     boards.
> 
> 
> 
>     -- 
>     Rfced-future mailing list
>     Rfced-future@iab.org 
>     https://www.iab.org/mailman/listinfo/rfced-future
>     
> 
> 


From nobody Thu Aug 26 18:40:10 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60A633A0863 for ; Thu, 26 Aug 2021 18:40:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 vkYjDd1pjqTd for ; Thu, 26 Aug 2021 18:40:03 -0700 (PDT)
Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (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 5C2E83A085D for ; Thu, 26 Aug 2021 18:40:03 -0700 (PDT)
Received: by mail-pg1-x529.google.com with SMTP id q68so4633978pga.9 for ; Thu, 26 Aug 2021 18:40:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=/99QRYwGgN4sET9uXazxodm1AHcrQnNF7D5Y6uwxqAk=; b=jT+8Jz/bkGLsVKxjknbjCE2KuvHH2D779+0ehi31jo7qZhgGEqBIUr1N+YEE6PMEfd lWSlyV7BmLpoVTZGxgeba/IjErCMzDkU/Dii3rnqAziVqD76hdHAGOAGPfFgDHp1QFB+ ytSHNgfXeQe85wrtEdvFEHR2Q77+J3K3ZgtT/u7Dd3qDbikbfVX7DjujFFS5ZS+UXGjU 06EtB7adJtTZOJeo2nSQS0LaWxld8OvXWc3yLf5gEi7U+70OlEhBQwQfXBv60uVqceqp pRaYRbPz2ivUdEuQraruv0v0O4z04VjDd9ivjbRlpw/dvjb4rNBbbLV8ZgyZtgWbG4sU GBTw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=/99QRYwGgN4sET9uXazxodm1AHcrQnNF7D5Y6uwxqAk=; b=Mru20cWPq+yvxs/VPycQEB3TuED8/9KohgXGe+WivJfIyqnUOUKFO/A7Hg5mPIGxE/ /kOfEf5ms6R/38fiB7jIKLvp080563VK9GByhHjeig5i8YsdGmvflZtEmqhwtL9EX4ff Dh7EdCd8cRFQC8w1/5W0V+R3LB2ZyktGSf9hpYW7WFMpr7zOmZ3OGhrTY2IQt3tVhhyG LPUn2pdLg6BXo4Ck5gRT40ufR5QdRkPNLMRHLRTf9WVzQOgmU9hkg6y5ecrkB8+KO6hn +K61FdjJARTVTTCJWIvOWgiS7rbVOGjjUjtNKc+eZBwbeOXynYdp3zQEjl48YeHk5qV9 MHtg==
X-Gm-Message-State: AOAM531Sp+QrAdWFA3i09t75KaC5EfM/46yuMHqWvYolilbi74TdaOAq E0R1nMCkbpXUG6alLAGph1YFoL/x6qxVyg==
X-Google-Smtp-Source: ABdhPJxCcAuTjpfYFQG/HS2xi6rv51+al5/yC7ItbNoahrR3GXzLhpTiQV0uMo3DG4Gqk7Ei51+LJQ==
X-Received: by 2002:aa7:8151:0:b029:3e0:bba6:9754 with SMTP id d17-20020aa781510000b02903e0bba69754mr6688352pfn.19.1630028401819;  Thu, 26 Aug 2021 18:40:01 -0700 (PDT)
Received: from ?IPv6:2406:e003:11d3:cf01:80b2:5c79:2266:e431? ([2406:e003:11d3:cf01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id c12sm3921869pfl.56.2021.08.26.18.39.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 26 Aug 2021 18:40:01 -0700 (PDT)
To: Michael StJohns , Mark Nottingham 
Cc: "rfced-future@iab.org" 
References: <2512c470-1721-08d9-b73f-f66248e585ce@nthpermutation.com> <6DD9248A-9E94-4CB9-A3E6-E79B66644545@mnot.net>  <13c56879-192f-5ca7-ca51-590fa75d8587@nthpermutation.com>  <5D7867A3-1687-4AAE-A621-01AFEC588B1C@mnot.net> <0324d8dc-7be8-1b8b-ccaf-fc26a8d08b31@nthpermutation.com>
From: Brian E Carpenter 
Message-ID: <7d7c55fd-2cab-2874-1ec8-854690387fc1@gmail.com>
Date: Fri, 27 Aug 2021 13:39:58 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <0324d8dc-7be8-1b8b-ccaf-fc26a8d08b31@nthpermutation.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Rfced-future] Creation/dissolution
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Aug 2021 01:40:09 -0000

On 27-Aug-21 12:16, Michael StJohns wrote:
> On 8/26/2021 7:55 PM, Mark Nottingham wrote:
>> Mike,
>>
>>> On 27 Aug 2021, at 9:50 am, Michael StJohns  =
wrote:
>>>
>>> Neither the ISE nor the IRTF chair are selected by the community, but=20
by the IAB.   While their needs and issues will be considered in the RSWG=20
and RSAB, it's pretty clear that the IAB holds the reins for both of thos=
e positions and it's unclear why the IAB should get three votes here.
>> I'm having trouble interpreting this comment -- if the IAB were a sing=
le company, country or other interest, I could see where you're coming fr=
om, but they're selected from the community, by the community,  as a whol=
e. They, in turn, select the IRTF Chair and ISE from the community, based=20
upon community input; presumably, both of those people are respected by t=
he community and act independently of the IAB. So I think it's a long str=
etch to see this as the IAB getting three votes -- and even if you view i=
t that way, what kind of bias is being introduced?
>=20
> I don't doubt that either of these folk are respected by the community,=20

> nor that they effectively act independently of the IAB - currently.=C2=A0=
=C2=A0=20
> But in the final analysis, they are not appointed by the community=20
> regardless of how much input the IAB gets on them.

The IRTF Chair convenes the IRSG and is certainly perceived in a
leadership role by IRTF participants. I think that means that the
Chair has an independent voice.

The ISE is a bit different, because there is (by construction; the
word is Independent) no community to be identified. But I'm not
aware of any ISE having considered themself a tool of the IAB.

> It's not a matter of bias in the current instance, but as both the ISE =

> and the IRTF chair serve at the pleasure of the IAB, if both of them=20
> disagreed with the other three bodies, the IAB could simply replace the=
m=20
> with more tractable members.=C2=A0 That's a capability of the way those=20
two=20
> people are appointed, and needs to be considered in any fail safe=20
> dissolution mechanism we put in. So maybe not three votes, but certainl=
y=20
> an ability to remove two votes that disagree with the IAB.

Yes, but if it came to that we'd have a much, much worse problem
with the IAB.

    Brian


From nobody Thu Aug 26 23:50:49 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 336643A1E6F for ; Thu, 26 Aug 2021 23:50:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org
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 5MiuArejDDL2 for ; Thu, 26 Aug 2021 23:50:41 -0700 (PDT)
Received: from mail.eggert.org (mail.eggert.org [91.190.195.94]) (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 7C7333A1E6E for ; Thu, 26 Aug 2021 23:50:41 -0700 (PDT)
Received: from smtpclient.apple (unknown [IPv6:2a00:ac00:4000:400:7c71:e07f:3cf4:ff44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 41E2F600371; Fri, 27 Aug 2021 09:50:31 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1630047031; bh=CZG4GZF3n0y4aHLJ7YMy5FHh66R5DyBRyLE2OmRdsRU=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=QNZbP2QZN5Os9zYtDbeSUyEyIoOd7bTiMVCg4KqVnXFbtXJBpoqk5wsafow4kYM0s F8zudZPRHAbiJcSUf9dSHzHI1v2MCEWdx9ADMHRiwBRsfM6bQnMWZAAHHpV1zhW8Pk kQUG5zlsU8P9tTO9JiFZOUI3gKmqjTnXKMzEiyig=
From: Lars Eggert 
Message-Id: <6E9015E9-5EBE-4E4E-B75B-279518ACBCB2@eggert.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_0F63895B-96D7-43F9-A4D0-9E3F48FC8E84"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Date: Fri, 27 Aug 2021 09:50:30 +0300
In-Reply-To: 
Cc: Brian E Carpenter , Mark Nottingham , "rfced-future@iab.org" 
To: Michael StJohns 
References: <2512c470-1721-08d9-b73f-f66248e585ce@nthpermutation.com> <6DD9248A-9E94-4CB9-A3E6-E79B66644545@mnot.net>  <13c56879-192f-5ca7-ca51-590fa75d8587@nthpermutation.com> 
X-MailScanner-ID: 41E2F600371.AEE39
X-MailScanner: Found to be clean
X-MailScanner-From: lars@eggert.org
Archived-At: 
Subject: Re: [Rfced-future] Creation/dissolution
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Aug 2021 06:50:47 -0000

--Apple-Mail=_0F63895B-96D7-43F9-A4D0-9E3F48FC8E84
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi,

On 2021-8-27, at 2:50, Michael StJohns  wrote:
> On 8/26/2021 7:35 PM, Michael StJohns wrote:
>> On 8/26/2021 7:01 PM, Brian E Carpenter wrote:
>> I actually meant IESG vice IETF.  And community stands in for what I =
think you mean by IETF above.

Mike's text (with that correction) would work for me. Jay's point - =
whether the involvement of the LLC here would need to be clarified a bit =
more - is IMO orthogonal.

> Neither the ISE nor the IRTF chair are selected by the community, but =
by the IAB.   While their needs and issues will be considered in the =
RSWG and RSAB, it's pretty clear that the IAB holds the reins for both =
of those positions and it's unclear why the IAB should get three votes =
here.

I agree with this, too. I think I made a similar argument some time ago =
on some other issue.

One open question is what happens if at some point an RFC stream got =
created that was not directly or indirectly under the control of the =
IAB, IESG or RSWG - would the owner of that stream get a voice in this =
process. They probably should.

Thanks,
Lars

PS: Speaking as an individual, above and in general on this list. (It's =
been pointed out to me that I should clarify when I speak as chair and =
when I don't. Generally, I try to post from chair @ietf.org when I do.)

--Apple-Mail=_0F63895B-96D7-43F9-A4D0-9E3F48FC8E84
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmEoizYACgkQVLXDCb9w
wVdHEQ/+ODd/mR/8efKFxT7QPMMNM82NBPrYNejJb07Y5WPWmcpjSZpl8fmNfhTG
Uhk3QRE0kAX7h7srjNuJhpB6uwSynwr4NRPG6A7Vdirtkoldh4Is5RzTAFsTuSu/
1N/rt4s45QBpHnbmndq///kIlmielupy/tC7yxzqeGsCc1CigGq4fdZqbAwGKKEB
POqaRCr/1UbaxgBSZl/yXT1P4nS+/HdQya2NHmBn/r5Dj5qVdeV6VgCC+7Hxnr9k
ccbwNUJlBq4FLMc7BNQB2XPplvwVqPoUbs5x2Qak3N/Tp7lY+yyue+K95TYGNMwb
rnIWSrZ5Mmx+yYzhq9DqDuI/U3Jc3pwuaOkOY8ul94fCOeXl+SBb3WJ8souOKrVb
BpzoKfMRNH47LtWMuJjVWfKSFZuE4WPhL/Y0dPnGOV7v76fqoqAkGDzuJ/rVr46t
Kc9/VFGkQK1mHNdTJPGhW9DPKVP1tGE2ZV3A+ePQnbsRU46cj4WHC5gjy9+nx+bV
/slhR1XCV1Mbp0Are3eZ2jNB6xYcRWg7gRWL6zEhMV81uX06eVy+6IujwYalGnka
t6/I1LNwS4oHkn4pU7hspzW2SBSF8u5xcg5tKLDeqJk1WrZbWJXbF7ITA0XjLbXU
+CUf9Soh58u8uOAuJSC2uurpnBsjkIAywnib/FMJnIroMz1ZP88=
=gWnL
-----END PGP SIGNATURE-----

--Apple-Mail=_0F63895B-96D7-43F9-A4D0-9E3F48FC8E84--


From nobody Fri Aug 27 05:09:30 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C80C13A0DBF for ; Fri, 27 Aug 2021 05:09:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.09
X-Spam-Level: 
X-Spam-Status: No, score=-2.09 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, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch
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 qj1LHigXUk6M for ; Fri, 27 Aug 2021 05:09:22 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 791233A0DC0 for ; Fri, 27 Aug 2021 05:09:21 -0700 (PDT)
Received: from [IPv6:2001:420:c0c0:1011::7] ([IPv6:2001:420:c0c0:1011:0:0:0:7]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 17RC9IJt018575 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Fri, 27 Aug 2021 14:09:18 +0200
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1630066158; bh=rAIdMxbLVIHTPHBj2B6XW3/2tNdwdqaaXjAOaA5C72Y=; h=To:From:Subject:Date:From; b=HWHC4opBhGHrnlftmcuQ31R7OG/J5Cu2am/oYvQAmndEiUwvA0IE7qvOdt1Ci+pQa xt2FgDJssSFlDpWRO7E6C1SizcJ+dDmdVZZzzS+htU5NKRpzmil9+TQMUdj6vZUhi8 VTEtJpIIU9/aCD9rY0hF+Fs32O0el+BIx/ItLWh0=
To: "rfced-future@iab.org" 
From: Eliot Lear 
Message-ID: 
Date: Fri, 27 Aug 2021 14:09:17 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="axn2vW3i8WjkuDmnc4h7gD6UHsjZILwmw"
Archived-At: 
Subject: [Rfced-future] raw notes from yesterday
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Aug 2021 12:09:29 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--axn2vW3i8WjkuDmnc4h7gD6UHsjZILwmw
Content-Type: multipart/mixed; boundary="ESkYhVX6vLg3MTwnOq7ZHXXLWDIDZwAcU";
 protected-headers="v1"
From: Eliot Lear 
To: "rfced-future@iab.org" 
Message-ID: 
Subject: raw notes from yesterday

--ESkYhVX6vLg3MTwnOq7ZHXXLWDIDZwAcU
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US

Thanks to all of those who participated in the interim meeting. Raw=20
notes are now available at=20
https://notes.ietf.org/notes-ietf-interim-2021-rfcefdp-06-rfcefdp?view.

Minutes to follow early next week.

Eliot



--ESkYhVX6vLg3MTwnOq7ZHXXLWDIDZwAcU--

--axn2vW3i8WjkuDmnc4h7gD6UHsjZILwmw
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmEo1e0FAwAAAAAACgkQh7ZrRtnSejPQ
pQf+MxzS9WrJ2crpPatg0J7LW7QvihbliNQ5KYaW9Nfrzpcn1KEcG9UJG9vTU+zsOV4dUvxwrIwH
OiGsI30SU/VKGNMxK63FPjjCFuPgJbq9p6JRY2Ela6qqyBiWmnqj+78fs/PX+hNmvvGYN/FWElYl
zvqH+EaFKylfirFF/JCqcFvfXP4OVp1Gk02tQlX2yuSPGuBUsxuma3qfWoUt/8hmrM3TTP6dMuG6
oPsS7DLSnTr2l1NDHfAeojCjPYJlnKTAr1fvuL9/2XJ4CIdO8GPubVm9wAi0PJAfGkMLJstKBWDg
tflTwSHQr+s3s1ira1odz46Cf8INxnY89n46i0XpDg==
=6Xwg
-----END PGP SIGNATURE-----

--axn2vW3i8WjkuDmnc4h7gD6UHsjZILwmw--


From nobody Fri Aug 27 05:50:06 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D66A43A1376 for ; Fri, 27 Aug 2021 05:50:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=csperkins.org
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 rULAacS1X7Oq for ; Fri, 27 Aug 2021 05:49:58 -0700 (PDT)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 498A03A136A for ; Fri, 27 Aug 2021 05:49:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=csperkins.org; s=mythic-beasts-k1; h=To:Date:From:Subject; bh=tXaXn2F5pjntKLv6ZkZixc0RzjTn7Co1FHZldbvJJF0=; b=NIWQihV/Mc/a2f8BGAcCYMF1Y4 rugf5Il9n4H5eIMOxO9g+jVNvJ3nhgyz3z4tyvCRi65uxJYlUDE/34rOF6P8uGSLTjbUcZ9M2qpRx S/yfmTlcyvLgY5J3/wtyF0h222K5UbfK47K9Y4SbHzRlS/7dNA4iGvMhPHsuk/oTp4xFrIDyEzvOF 9Iz+S1Kf4Z7Oe43YAhA0JqmDG9Dfpmr23QIMIUNOcWvL3I3iKaLLad9PdhmGPAAeuWNk5ObebDRSs eh5wMJqQFfLxpV+TbIkZT65GmenzhwCJYT/+R1zgSnERcHeyqulO0LYlij/qH/O09lb4qQu7Q7VAq At30BD4w==;
Received: from [81.187.2.149] (port=33526 helo=[192.168.0.83]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1mJbIv-00043X-SX; Fri, 27 Aug 2021 13:49:54 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\))
From: Colin Perkins 
In-Reply-To: 
Date: Fri, 27 Aug 2021 13:49:48 +0100
Cc: Mark Nottingham , Michael StJohns ,  "rfced-future@iab.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <2512c470-1721-08d9-b73f-f66248e585ce@nthpermutation.com> <6DD9248A-9E94-4CB9-A3E6-E79B66644545@mnot.net> 
To: Brian E Carpenter 
X-Mailer: Apple Mail (2.3445.104.21)
X-BlackCat-Spam-Score: 4
Archived-At: 
Subject: Re: [Rfced-future] Creation/dissolution
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Aug 2021 12:50:05 -0000

> On 27 Aug 2021, at 00:01, Brian E Carpenter =
 wrote:
>=20
> On 27-Aug-21 10:38, Mark Nottingham wrote:
>>=20
>>> On 27 Aug 2021, at 7:33 am, Michael StJohns  =
wrote:
>>>=20
>>> Here's a cut.  Somewhat legalistic, but provides the basis for =
fixing a problem if it exists.  Note that this is an all or nothing - =
this doesn't give the IAB/IESG/LLC the ability to direct changes the RFC =
 outside of the RSAB/RSWG process, but allows them to kill that process =
if necessary.
>>>=20
>>> ## Dissolution of the RSAB and RSWG
>>>=20
>>> By mutual agreement of the IAB, the IETF and the IETF LLC Board, and =
with the consensus of the community, this document creates the RSAB, =
RSWG and the Editorial series within the IETF framework. To provide for =
the possibility that the needs of the community may change over time, or =
are not being satisfied by the system and organization described herein, =
the IAB, the IETF and the IETF LLC Board when acting collectively with =
the consensus of the community reserve the authority to disestablish =
either or both of the RSAB and RSWG and to redirect the authorities and =
responsibilities assigned to those groups as necessary.
>>=20
>> I'm concerned that this might cause unnecessary strife if it ever =
actually needs to be used; saying that the IETF rather than the IESG is =
problematic because the only way to get an IETF position on something is =
to issue an RFC. Likewise, measuring the 'consensus of the community' =
has proven controversial, given the amorphous nature of the community in =
question.
>>=20
>> I'd suggest something like:
>>=20
>> This document creates the RSAB, RSWG and Editorial Series by mutual =
agreement of the IAB, the IESG and the IETF LLC Board, reflecting =
community consensus as established in the RFC Editor Future Development =
Program. Change to the Editorial Series are managed through the process =
defined here. Changes to the responsibilities and authorities of the =
RSAB and RSWG (including dissolution) require mutual agreement of the =
IAB, IESG and IETF LLC Board, well as a community consensus established =
in a manner defined by the IAB.
>>=20
>> ... where 'a manner defined by the IAB' is open to other suggestions =
-- we just need to define who holds the ball for scoping rfced-future2 =
if the need arises.
>=20
> Agreed, but this omits the IRTF and the Independent Series and that =
isn't OK.

=E2=80=9C=E2=80=A6 by mutual agreement of the IAB, IESG, IRSG, ISE, and =
IETF LLC Board=E2=80=9D=20

> Also - I take your point about IESG v IETF, but I think the IESG must =
obtain IETF input for something this important. So "IESG after =
consulting the IETF" or something like that.


Is that not covered by the later mention of community consensus?

Or "by mutual agreement of =E2=80=A6 after consultation with their =
respective communities=E2=80=9D?


That said, while mutual agreement on changes is a desirable goal, if =
things have broken down so badly that the IETF believes it has to =
dissolve the RSWG and RSAB, then I have trouble believing the other =
streams could, in practice, veto that, whatever we write here.=20

Colin=20
(as individual)=


From nobody Fri Aug 27 09:52:37 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9639B3A17C7 for ; Fri, 27 Aug 2021 09:52:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.089
X-Spam-Level: 
X-Spam-Status: No, score=-2.089 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch
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 eSfZ_kLVVdCP for ; Fri, 27 Aug 2021 09:52:29 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 997FA3A17C1 for ; Fri, 27 Aug 2021 09:52:28 -0700 (PDT)
Received: from [IPv6:2001:420:c0c0:1011::7] ([IPv6:2001:420:c0c0:1011:0:0:0:7]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 17RGqPiD022340 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Fri, 27 Aug 2021 18:52:25 +0200
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1630083145; bh=7dFz+PQLb2IhrneGJxWX20pFuodz2LzTyiMpIAVBQqg=; h=To:From:Subject:Date:From; b=eW79fbwX6rrVaJGqa1RFF37eAufXmsLU3wrj8+B/YL08SufcR7SOgOJ9QWLqqu7K+ gk1LNFZjEriPFy6s80Nf0MNCsmbXRAR/L+jd9sP/362rEjM9qP3ocDfb8SFxt5+p9u zo0RRQkmgrTMqmX8qRBsUY3wuK7ocjJ6KshhteGM=
To: "rfced-future@iab.org" 
From: Eliot Lear 
Message-ID: 
Date: Fri, 27 Aug 2021 18:52:24 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="KfCLu8M9R0SwIWq0Eho7f6STZHy4io01b"
Archived-At: 
Subject: [Rfced-future] Call for Consensus: Issue 41 selection of RSWG chairs
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Aug 2021 16:52:36 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--KfCLu8M9R0SwIWq0Eho7f6STZHy4io01b
Content-Type: multipart/mixed; boundary="8MTqMUNVe3KUbVpNr42MWOk03pZBnqNIQ";
 protected-headers="v1"
From: Eliot Lear 
To: "rfced-future@iab.org" 
Message-ID: 
Subject: Call for Consensus: Issue 41 selection of RSWG chairs

--8MTqMUNVe3KUbVpNr42MWOk03pZBnqNIQ
Content-Type: multipart/alternative;
 boundary="------------5878345C37A18A60318D0CA4"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------5878345C37A18A60318D0CA4
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

As previously discussed Section 3.3.1 in the draft now reads as follows:

    The RSWG shall have two chairs, one appointed by the IESG and the
    other appointed by the IAB.  When the RSWG is formed, the chair
    appointed by the IESG shall serve for a term of one (1) year and the
    chair appointed by the IAB shall serve for a term of two (2) years;
    thereafter, chairs shall serve for a term of two (2) years, with no
    term limits on renewal.  The appointing bodies shall determine their
    own processes for making these appointments, such as provision for an=

    open nominations period.  Community members who have concerns about
    the performance of an RSWG chair should direct their feedback to the
    relevant appointing body.  Each appointing body shall have the power
    to replace its appointed chair at its discretion at any time, with
    the replacement serving the remainder of the original chair's origina=
l
    chair's term.

We have previously discussed this text, and we now propose to close this =

issue, barring objections.=C2=A0 Those having concerns should raise them =
by=20
the 10th of September.

Eliot


--------------5878345C37A18A60318D0CA4
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  

    
  
  
    
As previously discussed Section 3.3.1 in the draft now reads as
      follows:

    
   The RSWG shall have two chairs, one appoint=
ed by the IESG and the
   other appointed by the IAB.  When the RSWG is formed, the chair
   appointed by the IESG shall serve for a term of one (1) year and the
   chair appointed by the IAB shall serve for a term of two (2) years;
   thereafter, chairs shall serve for a term of two (2) years, with no
   term limits on renewal.  The appointing bodies shall determine their
   own processes for making these appointments, such as provision for an
   open nominations period.  Community members who have concerns about
   the performance of an RSWG chair should direct their feedback to the
   relevant appointing body.  Each appointing body shall have the power
   to replace its appointed chair at its discretion at any time, with
   the replacement serving the remainder of the original chair's original=

   chair's term.



    
We have previously discussed this text, and we now propose to
      close this issue, barring objections.=C2=A0 Those having concerns
      should raise them by the 10th of September.

    
Eliot

    

  


--------------5878345C37A18A60318D0CA4--

--8MTqMUNVe3KUbVpNr42MWOk03pZBnqNIQ--

--KfCLu8M9R0SwIWq0Eho7f6STZHy4io01b
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmEpGEgFAwAAAAAACgkQh7ZrRtnSejMr
nQgArzqOzBWAGE7zTZzQemX+Qy3BobgxilmrmMn/W1u+ezvv9wgOn+WlGL0BLgAjARjpshD/j9np
VZc4vyB20yXV+70d1mtja1pxG5JchzqPy8Nh1GvbcQbgbSZbkmizz6zC5GeDVFTPp8oN0wU6UTif
Q8cR7uxFP5MHlFf82da3Zbxie+YmP6OgO5EW58EF4q9sL8NZcrTJb2D70ME5g5vNnqFW6UYKtRMz
JkWXmZO877g9y0zC11Awh1cz231GrzIh7kjABwIGgC9nOZLOE6y4HMAIRAPUDqmb5p30/Lzx4qEk
QDyIPEb+LgJz3/iFIU9XeCdq4FL+QaH7ujYJa3TD5g==
=5Acr
-----END PGP SIGNATURE-----

--KfCLu8M9R0SwIWq0Eho7f6STZHy4io01b--


From nobody Fri Aug 27 10:05:10 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55A4C3A1921 for ; Fri, 27 Aug 2021 10:05:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.09
X-Spam-Level: 
X-Spam-Status: No, score=-2.09 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, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch
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 nwT7hW6ZUgL8 for ; Fri, 27 Aug 2021 10:05:02 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51F5F3A1922 for ; Fri, 27 Aug 2021 10:05:02 -0700 (PDT)
Received: from [IPv6:2001:420:c0c0:1011::7] ([IPv6:2001:420:c0c0:1011:0:0:0:7]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 17RH4wd4022565 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Fri, 27 Aug 2021 19:04:58 +0200
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1630083899; bh=t2wzwOTb87UzRSzhZVjbcHCXel8O6naZw3PaZkMRJ0U=; h=To:From:Subject:Date:From; b=tTEd8gNu00tf94jufuYhBhXVu9PxJ87G8HxcaEXrZsEDXJQp/8PCquxi7TEHUDWHR OByxJaVM43A/mLdZzJG5WBC9rBQYlg0Ss89YSJe2h80VSFyh4k4YpiKbwUN06Fb8D1 RMLsgZ+8QNzwqOGE49+sX5M5RHNKbj4bJJXj0xQE=
To: "rfced-future@iab.org" 
From: Eliot Lear 
Message-ID: <58be8fca-c011-7976-586e-4e686004d300@lear.ch>
Date: Fri, 27 Aug 2021 19:04:57 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="YjAfNG3hquY0dgziJAHiKhJugzHS3ibkR"
Archived-At: 
Subject: [Rfced-future] Propose to close: Issue 50: RSAB responsibilities
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Aug 2021 17:05:09 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--YjAfNG3hquY0dgziJAHiKhJugzHS3ibkR
Content-Type: multipart/mixed; boundary="bQouiZ98c0w2i1qT4HTWdAYRLQNvMQrc7";
 protected-headers="v1"
From: Eliot Lear 
To: "rfced-future@iab.org" 
Message-ID: <58be8fca-c011-7976-586e-4e686004d300@lear.ch>
Subject: Propose to close: Issue 50: RSAB responsibilities

--bQouiZ98c0w2i1qT4HTWdAYRLQNvMQrc7
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US

As discussed, since this issue has opened the text has matured=20
significantly about the RSAB responsibilities.=C2=A0 If people have speci=
fic=20
concerns, new issues can still be opened.=C2=A0 Otherwise we propose to c=
lose=20
this if we hear nothing by 10 September.

Eliot



--bQouiZ98c0w2i1qT4HTWdAYRLQNvMQrc7--

--YjAfNG3hquY0dgziJAHiKhJugzHS3ibkR
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmEpGzkFAwAAAAAACgkQh7ZrRtnSejNJ
Awf8Cz0OBRde95MQoIwmltatn3vy5eGduiD7Vs4XWWufOd8kZextmF3IsAbHa+3jUBMbbLMZBkgi
MlByMOzqXYAj/jZpOJKXpZ7sZ+p5+dfKCgItoIdrMcbli4r392IqFN2STEtLXT1VyeVno83YKfgk
P0rkBJ95NYScucl1pOyiYTMYDmNBf/wi7v+937gOCPOn9EOfzjYQDgKZ6DE3/rU3e3xPE7DRxYfL
TCEdFdJGfu+I+HkhnZaymUYNCWKsJEjakkAAXcebKGy1U/acfy58aWjJJhsgoKNpI5hmtUOvmKe4
sD6SsrlaOs52djZ04vHGr1uUUpSI3g4gsKzjZkDUzg==
=mL7+
-----END PGP SIGNATURE-----

--YjAfNG3hquY0dgziJAHiKhJugzHS3ibkR--


From nobody Fri Aug 27 10:08:02 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 780C53A198F for ; Fri, 27 Aug 2021 10:07:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.09
X-Spam-Level: 
X-Spam-Status: No, score=-2.09 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, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch
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 o5rK_dog0YvN for ; Fri, 27 Aug 2021 10:07:53 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF2383A1988 for ; Fri, 27 Aug 2021 10:07:52 -0700 (PDT)
Received: from [IPv6:2001:420:c0c0:1011::7] ([IPv6:2001:420:c0c0:1011:0:0:0:7]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 17RH7nNX022598 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Fri, 27 Aug 2021 19:07:49 +0200
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1630084070; bh=4cdy9EzHKctup0KTE2bEMjwrHf9DOZHqjHUwWlOxPFI=; h=To:From:Subject:Date:From; b=GE5mtuMUDiIGvaXqkAFZq86Ar3ClSDy6SXgAm1t4/LZf7DopEbkb4781Fv/MVM+Lv 9CO2C0gv5k0R4KGssdqL+fO3HGeTBhD4FLAIva+f+p6a3kbkEosi7ksTh3vjWddONT XpvFCCHa79Fev6fTsVJwv6MIq8IaSSLOIe3hexWY=
To: "rfced-future@iab.org" 
From: Eliot Lear 
Message-ID: 
Date: Fri, 27 Aug 2021 19:07:49 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="nTNXNXFXjN11P9S4Y0oUTNFAFCmjvWc9R"
Archived-At: 
Subject: [Rfced-future] Propose to close: Issue #49 on RSEA feedback
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Aug 2021 17:08:00 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--nTNXNXFXjN11P9S4Y0oUTNFAFCmjvWc9R
Content-Type: multipart/mixed; boundary="nVwn0yNGEkYMg2jk1Jzm058bKIRVPJDiw";
 protected-headers="v1"
From: Eliot Lear 
To: "rfced-future@iab.org" 
Message-ID: 
Subject: Propose to close: Issue #49 on RSEA feedback

--nVwn0yNGEkYMg2jk1Jzm058bKIRVPJDiw
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US

As discussed in the interim, we'd like to close this issue.=C2=A0 I note =
that=20
there is one outstanding matter with this and another issue, which is=20
how anonymous feedback is handled.=C2=A0 I'd ask people to review that te=
xt=20
and comment before the 10th of September.=C2=A0 See Section 4.2.

Eliot



--nVwn0yNGEkYMg2jk1Jzm058bKIRVPJDiw--

--nTNXNXFXjN11P9S4Y0oUTNFAFCmjvWc9R
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmEpG+UFAwAAAAAACgkQh7ZrRtnSejMf
Pwf9GQ0QB//Cxv9F9EdGYvda8d3v5ICyCc/mBrNuLxOLwUNqO3/ua5m954YzL59szUlJq88/9TjX
dEFc9+wuFKZAlI5QiVuQ0jE/uaZ8iYsRWtrhSPkoBqd0PjSrwG08DlhQNYsHSw/+abd/t0dvXT61
BlR6Dd2pXLyXCOAAB3ZAyXzXwhbeMr4Cqag7JMlYUy115GHVb4eFcPzzxf+KoqXIPkjgqyyUu7Fl
fSMT6pA1m9ZidwovKGOiJID+RRtJ/sBqrcs5RDVlgXtXl69oqGP4+wmYVdAZT/ZSw6Ai1rkAqja1
crrBqnFm8mORMz8S4PIC7uGoRT273tLzpEz070uoeA==
=ruwt
-----END PGP SIGNATURE-----

--nTNXNXFXjN11P9S4Y0oUTNFAFCmjvWc9R--


From nobody Fri Aug 27 10:21:30 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A606D3A1A68 for ; Fri, 27 Aug 2021 10:21:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.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 CSMBz8ffFUeF for ; Fri, 27 Aug 2021 10:21:24 -0700 (PDT)
Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 709083A1A78 for ; Fri, 27 Aug 2021 10:21:24 -0700 (PDT)
Received: by mail-qk1-x736.google.com with SMTP id 22so7979199qkg.2 for ; Fri, 27 Aug 2021 10:21:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=yxFrHDJSszTWf3mIsnodU/zRqhGhqSXVeO0njp8gdbc=; b=zJJ/cZdcvFNlhfjkYYKfuV2usBhyqg7IffI6VcX/HBTlluogRNMqM2srba+W/PeJZh j1Bn4LcEfSCRjSzKxgVKwSV6Z7LT1J/cpo1D2hK9jRGKetpxnSMSSfWR+9xNmYkj/3vP dHs2QzvNBEEbu0+WxMsLfdJPmwdYSXOPIreRxR3OM5Qnpje1dm9ixdeJ1i3dTwH5lEEL ogFsJp6WO55deMpjp2kHNGcivy6OZRAVCKMbpyHIK2LAYfXaINco/wfwh5MP/RqBV7lg 6z5Lv82TOEWP0F4QNjFRo8X1OHtefh0c7DK0sGozjL4FWI/r2L2AKKT+ViM/BOjG0MOy 60Dg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=yxFrHDJSszTWf3mIsnodU/zRqhGhqSXVeO0njp8gdbc=; b=EbIAEN1YyH0CGXiR+3aXgiY4psEdzqVDMIJgEXwt2YJifapl7gSqinUtup7mq/N/NC fwe+ZTh0aC84xhMKzQnrhlpu+1675ALlO3GJwQ7Nh4ATwq++9ugFhQfuTdOxJkhLUrIY O+M1x2i68gQP0rXlB8CZt1z3fLzBQXiGWKFWJ7wES2hIwwChb+Jh21OBAs3yynOJzDEh oXyD/putCZRMNGkpfFVYYcpCeKl2+7vqXifrnCACtR0TrW0380kt9AI2pwl//MW1Xi4i V/KJAeW+JqAIVtpMRO9y+Z6a0EYjnexx0M6+s3SAeABmGOqYOyGXpSpWoqAFJbZhghuT 8Qjg==
X-Gm-Message-State: AOAM532hXuzN9E6JMUGAxOmNU+SJFvEEF07xda+r61EYlYcFwbM4MGH/ Wav2xi65GM1d3Fg7lJ+5YMaKrhZ2W9Hrqqg8
X-Google-Smtp-Source: ABdhPJx42IBI2m3y04ZPSYKmjyz4YxJFD+RtmhQC/BTZDtO5uU61aFgY6fER+we5Dao/egAe1MG05A==
X-Received: by 2002:a37:6447:: with SMTP id y68mr10010806qkb.296.1630084882173;  Fri, 27 Aug 2021 10:21:22 -0700 (PDT)
Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id h68sm5366883qkf.126.2021.08.27.10.21.21 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 27 Aug 2021 10:21:21 -0700 (PDT)
To: rfced-future@iab.org
References: 
From: Michael StJohns 
Message-ID: <56ba2516-ef0f-df22-aaec-5f4e9bd44009@nthpermutation.com>
Date: Fri, 27 Aug 2021 13:21:19 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------70F1B54824F2E35CCAECE39D"
Content-Language: en-US
Archived-At: 
Subject: Re: [Rfced-future] Call for Consensus: Issue 41 selection of RSWG chairs
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Aug 2021 17:21:29 -0000

This is a multi-part message in MIME format.
--------------70F1B54824F2E35CCAECE39D
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

On 8/27/2021 12:52 PM, Eliot Lear wrote:
>
> As previously discussed Section 3.3.1 in the draft now reads as follows:
>
>     The RSWG shall have two chairs, one appointed by the IESG and the
>     other appointed by the IAB.  When the RSWG is formed, the chair
>     appointed by the IESG shall serve for a term of one (1) year and the
>     chair appointed by the IAB shall serve for a term of two (2) years;
>     thereafter, chairs shall serve for a term of two (2) years, with no
>     term limits on renewal.  The appointing bodies shall determine their
>     own processes for making these appointments, such as provision for an
>     open nominations period.  Community members who have concerns about
>     the performance of an RSWG chair should direct their feedback to the
>     relevant appointing body.  Each appointing body shall have the power
>     to replace its appointed chair at its discretion at any time, with
>     the replacement serving the remainder of the original chair's original
>     chair's term.
>
> We have previously discussed this text, and we now propose to close 
> this issue, barring objections.  Those having concerns should raise 
> them by the 10th of September.
>
> Eliot
>
>
s/original chair's original chair's/original chair's/


--------------70F1B54824F2E35CCAECE39D
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 8/27/2021 12:52 PM, Eliot Lear
      wrote:

    

    

      
      
As previously discussed Section 3.3.1 in the draft now reads as
        follows:

      
   The RSWG shall have two chairs, one appointed by the IESG and the
   other appointed by the IAB.  When the RSWG is formed, the chair
   appointed by the IESG shall serve for a term of one (1) year and the
   chair appointed by the IAB shall serve for a term of two (2) years;
   thereafter, chairs shall serve for a term of two (2) years, with no
   term limits on renewal.  The appointing bodies shall determine their
   own processes for making these appointments, such as provision for an
   open nominations period.  Community members who have concerns about
   the performance of an RSWG chair should direct their feedback to the
   relevant appointing body.  Each appointing body shall have the power
   to replace its appointed chair at its discretion at any time, with
   the replacement serving the remainder of the original chair's original
   chair's term.



      
We have previously discussed this text, and we now propose to
        close this issue, barring objections.  Those having concerns
        should raise them by the 10th of September.

      
Eliot

      

      

      

    

    
s/original chair's original chair's/original chair's/

    

  


--------------70F1B54824F2E35CCAECE39D--


From nobody Sat Aug 28 01:33:07 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C28073A14DB for ; Sat, 28 Aug 2021 01:33:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.09
X-Spam-Level: 
X-Spam-Status: No, score=-2.09 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, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch
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 R3I6KR0Tscjy for ; Sat, 28 Aug 2021 01:32:59 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A39F3A14D9 for ; Sat, 28 Aug 2021 01:32:57 -0700 (PDT)
Received: from [IPv6:2a02:aa15:4101:2a80:e934:cdee:5039:69d1] ([IPv6:2a02:aa15:4101:2a80:e934:cdee:5039:69d1]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 17S8Wn1D035590 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Sat, 28 Aug 2021 10:32:54 +0200
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1630139574; bh=mRSWCqxka0fe4dHvNGOzA50hlDlusnz3psvplFychQI=; h=To:From:Subject:Date:From; b=NTh4Y5B0+jguc3SIyWG5h1C5QgveicjtgZjVebgxIoFBt/RKWWT8Cz7/vKGDEms0e bh0/oMhF52ao3fjZYiSr7kPZGnPx9MQRTL4jPOoCZOFvKONY4G0lelRcAWUH9D4P/R GPRo5a0XLgYc1NGwdPiDqNNSijYYQGJuYHIksg2o=
To: "rfced-future@iab.org" 
From: Eliot Lear 
Message-ID: <04bddec4-dfe3-0da6-f5e2-2fa71e573e5d@lear.ch>
Date: Sat, 28 Aug 2021 10:32:38 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="736jNt9SMQhLUEsBqOPwpSSChALLUtA1Y"
Archived-At: 
Subject: [Rfced-future] Propose to close: Issues 56, 58, and 79
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 28 Aug 2021 08:33:05 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--736jNt9SMQhLUEsBqOPwpSSChALLUtA1Y
Content-Type: multipart/mixed; boundary="Czm4qAGCqdvQzNnc0a9PxZbGiHIHYNXgy";
 protected-headers="v1"
From: Eliot Lear 
To: "rfced-future@iab.org" 
Message-ID: <04bddec4-dfe3-0da6-f5e2-2fa71e573e5d@lear.ch>
Subject: Propose to close: Issues 56, 58, and 79

--Czm4qAGCqdvQzNnc0a9PxZbGiHIHYNXgy
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US

Text is now in the draft.=C2=A0 See Sections 5.2 and 5.3.=C2=A0 Please re=
view by=20
11 September.



--Czm4qAGCqdvQzNnc0a9PxZbGiHIHYNXgy--

--736jNt9SMQhLUEsBqOPwpSSChALLUtA1Y
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmEp9KYFAwAAAAAACgkQh7ZrRtnSejPD
uggAzMLHAJdjcZynjoejgOGniYludEq7xWxyoP0E0MHt75rdPv9PUGO0uplrrrkFIeJBWaBmLMpX
ULNZDBL/nFzQY0piSfXqFafu4UNU4SONvZCCWa+zPBFLeSApGY0xr6L2drD87TYHang4hb83Oiko
9Ms8vwCLKo5iRVaurdaPJHscQpaxAhrskJBlk63XXWCqb6dunfx4vbKkejLpAoeaTiNMzoX33p5c
Ymnss0Bc3ePlNC4P7qStojzqAFUXIVZfAImLAuTOoOdkGLq+cS7jf0VI6jheSS04cZ7SgJzbDVgZ
PqFPzxj48pLoJMxsCkU1Qz7Zf+pNwjOrdB/H3DFuxQ==
=qpCe
-----END PGP SIGNATURE-----

--736jNt9SMQhLUEsBqOPwpSSChALLUtA1Y--


From nobody Sat Aug 28 01:37:39 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28EDA3A1521 for ; Sat, 28 Aug 2021 01:37:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.09
X-Spam-Level: 
X-Spam-Status: No, score=-2.09 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, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch
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 gpNfCoEAkkjj for ; Sat, 28 Aug 2021 01:37:32 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15E103A1510 for ; Sat, 28 Aug 2021 01:37:30 -0700 (PDT)
Received: from [IPv6:2a02:aa15:4101:2a80:e934:cdee:5039:69d1] ([IPv6:2a02:aa15:4101:2a80:e934:cdee:5039:69d1]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 17S8bNOa035620 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Sat, 28 Aug 2021 10:37:23 +0200
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1630139843; bh=kKyxFRjbRVwFR4KZ1bfJXmRkIsD2ren1phtsvARXKnc=; h=To:From:Subject:Date:From; b=EtRmG5RJxjJpzdK4LttmyHu2aNrsT+7Uv9X+6wz5yRg0JwaCuXiKRyMYepSlLQBW+ rQWs2TIZnjpyJdh4yMLH1gbsLDIOrxucjxcJyMeTR6+cDAGdRa/lVH4m6R0b9ZqFTP ShCTDeuDBoCEMEYq8vhmmgp7p/EbKsMyF7L64T/Y=
To: "rfced-future@iab.org" 
From: Eliot Lear 
Message-ID: <6ba3bd40-8754-3d3d-66cf-2bcd72469b6a@lear.ch>
Date: Sat, 28 Aug 2021 10:37:22 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="C4RmAoIJ0EA3knol8yH1cfZCltclP2IzI"
Archived-At: 
Subject: [Rfced-future] Issue 36: Propose to close
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 28 Aug 2021 08:37:38 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--C4RmAoIJ0EA3knol8yH1cfZCltclP2IzI
Content-Type: multipart/mixed; boundary="WqWTfKvVY8g4H3SMHw64XmRTh3LpcONP0";
 protected-headers="v1"
From: Eliot Lear 
To: "rfced-future@iab.org" 
Message-ID: <6ba3bd40-8754-3d3d-66cf-2bcd72469b6a@lear.ch>
Subject: Issue 36: Propose to close

--WqWTfKvVY8g4H3SMHw64XmRTh3LpcONP0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US

What is in the draft today:

 =C2=A0=C2=A0 Appeals of RSAB decisions shall be made to the IAB and shou=
ld be made
 =C2=A0=C2=A0 within thirty (30) days of public notice of the relevant RS=
AB
 =C2=A0=C2=A0 decision (typically, when minutes are posted).=C2=A0 The ap=
peals body
 =C2=A0=C2=A0 shall decide whether a process failure occurred and what if=
 any
 =C2=A0=C2=A0 corrective action should take place.

I believe "appeals body" should be replaced with IAB as an editorial.=C2=A0=
=20
However, if anyone would like to continue discussing appeals roles,=20
please comment before 11 September.



--WqWTfKvVY8g4H3SMHw64XmRTh3LpcONP0--

--C4RmAoIJ0EA3knol8yH1cfZCltclP2IzI
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmEp9cIFAwAAAAAACgkQh7ZrRtnSejMZ
vQgArNhhK+C3HA5b9bGJWmtFAeiRxLCCDCk6e3UquA5gh3fxdmSM1UvlSVlnKM9sg1L1UuMjYtQk
/upnrrJLxO8cTcfzRsWt19cg8NjzMfYGnjZ+57wdEjFHzK//wm443R2jaU4E0tPJNbEu7WO+33HN
fJ1gCOAY/Yl3bbjbC3Hn5eqsmefeKkkw1bA8Js2/ucmXRUzxiN43u7h1maaUq1ied2x7/uWpXLdr
7c6Fhg/wc2h/uINzDVPfeNhXRpYtebAWscKrqlM/TVtuNzpY2yN2DlYJpGIW0SejkE/3LqhieyNt
RsKWR4h1BllSVlxoHQ8hcmdf/Mwh3JAxwwwV9Qrwcg==
=Gg9s
-----END PGP SIGNATURE-----

--C4RmAoIJ0EA3knol8yH1cfZCltclP2IzI--


From nobody Sat Aug 28 01:56:31 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C50093A15BD for ; Sat, 28 Aug 2021 01:56:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.089
X-Spam-Level: 
X-Spam-Status: No, score=-2.089 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch
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 Rtaty082JfhJ for ; Sat, 28 Aug 2021 01:56:24 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A0C73A15BE for ; Sat, 28 Aug 2021 01:56:23 -0700 (PDT)
Received: from [IPv6:2a02:aa15:4101:2a80:e934:cdee:5039:69d1] ([IPv6:2a02:aa15:4101:2a80:e934:cdee:5039:69d1]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 17S8uKg8035876 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Sat, 28 Aug 2021 10:56:20 +0200
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1630140980; bh=yBRoOPyyne/A/IaB6FTbahWvvOmiOuvWatoqtSvjmRY=; h=To:From:Subject:Date:From; b=nd+0i+a4oeGuYGFm+EKVBPZZ71ML8+7jYQHkYByduLoFd9RL1P/TrDpTxsVqvZOfR fjhFReidrSGFgxykSngxwTBweK9yHtHkJ9CGw5k8fsqr09WzwvmiDL8JXbX4sZIYg8 W/RUKiv6/B0TqWwg39ZKl48pM3q8S9OYw4CUV+9I=
To: "rfced-future@iab.org" 
From: Eliot Lear 
Message-ID: 
Date: Sat, 28 Aug 2021 10:56:20 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="mS6WsCg8SQcUqp8ftBvcROUPOZ5jGdbjF"
Archived-At: 
Subject: [Rfced-future] Issue 31: Updates RFC 8729?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 28 Aug 2021 08:56:30 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--mS6WsCg8SQcUqp8ftBvcROUPOZ5jGdbjF
Content-Type: multipart/mixed; boundary="IYh2PjiCrUNmGpo0D6NOp35FT1lNKTN67";
 protected-headers="v1"
From: Eliot Lear 
To: "rfced-future@iab.org" 
Message-ID: 
Subject: Issue 31: Updates RFC 8729?

--IYh2PjiCrUNmGpo0D6NOp35FT1lNKTN67
Content-Type: multipart/alternative;
 boundary="------------0A35491756DD14317FE28275"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------0A35491756DD14317FE28275
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

In re-reading RFC 8729, it's pretty clear that we need to make clear=20
that we are updating this document.=C2=A0 For one, it is referencing RFC =

8728, which I believe we are obsoleting.=C2=A0 For another, it mentions t=
he=20
RSOC, and describes the oversight role of the LLC for these functions,=20
which we have now redone.

Regarding Section 4.1.3, the text reads as follows:

 > 4.1.3.=C2=A0 Process Change

> =C2=A0=C2=A0 From time to time, it may be necessary to change the appro=
val
> =C2=A0=C2=A0 processes for any given stream, or even add or remove stre=
ams.=C2=A0 This
> =C2=A0=C2=A0 may occur when the RFC Editor, the IAB, the body responsib=
le for a
> =C2=A0=C2=A0 given stream of documents, or the community determines tha=
t there are
> =C2=A0=C2=A0 issues to be resolved in general for RFC approval or for p=
er-stream
> =C2=A0=C2=A0 approval processes.
>
> =C2=A0=C2=A0 In this framework, the general approach is that the IAB wi=
ll work
> =C2=A0=C2=A0 with the RFC Editor and other parties to get community inp=
ut, and it
> =C2=A0=C2=A0 will verify that any changes appropriately account for com=
munity
> =C2=A0=C2=A0 requirements.

Does this group believe that the IAB has a role to approve changes in=20
approval process flows of other streams, and in particular, the new=20
stream we have created?

Also, once we resolve the name of the role of the RSE, we have to decide =

whether we need to indicate that as an Update to this and other documents=
=2E

Note that there are many parts of RFC 8729 we probably *don't* want to=20
change, such as Section 4.3 and 4.4, and Section 5.

Eliot


--------------0A35491756DD14317FE28275
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  

    
  
  
    
In re-reading RFC 8729, it's pretty clear that we need to make
      clear that we are updating this document.=C2=A0 For one, it is
      referencing RFC 8728, which I believe we are obsoleting.=C2=A0 For
      another, it mentions the RSOC, and describes the oversight role of
      the LLC for these functions, which we have now redone.

    
Regarding Section 4.1.3, the text reads as follows:

    
> 4.1.3.=C2=A0 Process Change

    

    

      
=C2=A0=C2=A0 From time to time, it may be=
 necessary
        to change the approval

        =C2=A0=C2=A0 processes for any given stream, or even add or remov=
e
        streams.=C2=A0 This

        =C2=A0=C2=A0 may occur when the RFC Editor, the IAB, the body res=
ponsible
        for a

        =C2=A0=C2=A0 given stream of documents, or the community determin=
es that
        there are

        =C2=A0=C2=A0 issues to be resolved in general for RFC approval or=
 for
        per-stream

        =C2=A0=C2=A0 approval processes.

        

        =C2=A0=C2=A0 In this framework, the general approach is that the =
IAB will
        work

        =C2=A0=C2=A0 with the RFC Editor and other parties to get communi=
ty input,
        and it

        =C2=A0=C2=A0 will verify that any changes appropriately account f=
or
        community

        =C2=A0=C2=A0 requirements.

      

    

    
Does this group believe that the IAB has a role to approve
      changes in approval process flows of other streams, and in
      particular, the new stream we have created?

    
Also, once we resolve the name of the role of the RSE, we have to
      decide whether we need to indicate that as an Update to this and
      other documents.

    
Note that there are many parts of RFC 8729 we probably don't
      want to change, such as Section 4.3 and 4.4, and Section 5.

    
Eliot

    

  


--------------0A35491756DD14317FE28275--

--IYh2PjiCrUNmGpo0D6NOp35FT1lNKTN67--

--mS6WsCg8SQcUqp8ftBvcROUPOZ5jGdbjF
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmEp+jQFAwAAAAAACgkQh7ZrRtnSejOa
xQf+OzLbzrzyV2+x7p2g7YGxoPEwFtLS6orfNmyfKIu7TP+TYkd8i7Rx9/JzhiWJv5h2sQLqxvpS
v51yISuzeC9Ik9qfBj2+47BI05MVAaL/d96q8Nmdfp4VULJjqyLgPhI5Ec+Siz7jzOCVvslTZvrK
oEZSB4QRm9XE4bPU5Rb0nfuV7xTjiCCy0XI1W0tKDqLJtyT1xjpLYS5MqpgLsU9MfG2+NGHO3r99
BptO1OPQ574OGT248vK5Pi9/7cGE3N4Ykih4XJvRBX5lOOr2m0rwGI+sHYujp0BVf1nJhwsmp1Ba
CIeVLB4MkXFAQaBkc023bLWPno/AVGCf9mkPsy9YnA==
=54H5
-----END PGP SIGNATURE-----

--mS6WsCg8SQcUqp8ftBvcROUPOZ5jGdbjF--


From nobody Sat Aug 28 02:02:05 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D61E3A15FC for ; Sat, 28 Aug 2021 02:02:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.09
X-Spam-Level: 
X-Spam-Status: No, score=-2.09 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, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch
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 6lnsnIcqfYKB for ; Sat, 28 Aug 2021 02:01:57 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 807993A1600 for ; Sat, 28 Aug 2021 02:01:57 -0700 (PDT)
Received: from [IPv6:2a02:aa15:4101:2a80:e934:cdee:5039:69d1] ([IPv6:2a02:aa15:4101:2a80:e934:cdee:5039:69d1]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 17S91oQ7035921 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Sat, 28 Aug 2021 11:01:50 +0200
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1630141310; bh=yCsRdSSvutcARp3BWXuMclbtW9HBmM/JUFw5EsY8FHU=; h=To:From:Subject:Date:From; b=Q70donF14vgvnHNwzS3y5F4WKQqrugkV9BV6xPoRXYirWpzN0UcX0cPgZYMXHAbpj bWx4zAqVAhNX7GdWyR6r2/ZGTdPZdno+OqTlhMqiJTwN3ydWr3RyxbjE+gnoeEDfqf DRg9B/wcUJtb5HQPdlPRfWNTK3y/aOZmpKped8z8=
To: "rfced-future@iab.org" 
From: Eliot Lear 
Message-ID: <9231e538-0a08-6edf-37d2-bcacfece6ca9@lear.ch>
Date: Sat, 28 Aug 2021 11:01:49 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="49IcDkDXWfhDrBkYipRUkaJvR1hMgxOU9"
Archived-At: 
Subject: [Rfced-future] Propose to close: Issue 26: updates RFC 2028?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 28 Aug 2021 09:02:04 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--49IcDkDXWfhDrBkYipRUkaJvR1hMgxOU9
Content-Type: multipart/mixed; boundary="InGn5Lwz7QuhRftUGQ7NYXiOg8D4u8C4y";
 protected-headers="v1"
From: Eliot Lear 
To: "rfced-future@iab.org" 
Message-ID: <9231e538-0a08-6edf-37d2-bcacfece6ca9@lear.ch>
Subject: Propose to close: Issue 26: updates RFC 2028?

--InGn5Lwz7QuhRftUGQ7NYXiOg8D4u8C4y
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US

Some time ago, Peter wrote:

> Based on John's comments and a review of RFC 2028, I suggest that the=20
> RFC Editor Model Version 3 does not need to specify that it updates=20
> RFC 2028 (whether RFC 2028 itself needs to be updated is outside the=20
> scope of the RFC Editor Future Development Program). Therefore I=20
> suggest that we close this issue.

I would go further.=C2=A0 RFC 2028 is decrepit.=C2=A0 It should either be=
 marked=20
Historic or someone should take up the job and really update it.=C2=A0 Bu=
t=20
the question is whether this group needs to take that on?=C2=A0 We have a=
=20
pretty free hand in terms of our charter, but let me suggest that this=20
is a stretch.

One thing we could do is make a recommendation to the community that=20
SOMEONE take that on, in, say, a chairs' report or some such, if this=20
group wants.

In any case, if you feel strongly that there needs to be an action taken =

regarding RFC 2028, please say something before the 11th of September.

Eliot



--InGn5Lwz7QuhRftUGQ7NYXiOg8D4u8C4y--

--49IcDkDXWfhDrBkYipRUkaJvR1hMgxOU9
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmEp+30FAwAAAAAACgkQh7ZrRtnSejOv
ogf/eQV+Z2vHk+Eau1ONijJ1nOZNkmphvY3qAIG6nHobRLDidYgBFi8Y6nPrauRuY70qqTnTOL/p
YJsF7Mev0h9Xdz0lnQckNxvAUStu7EMTj4bgUjAVnrw2fyf/6hwB4KYClROoSOKO1uSwKlxHs8Hw
lBXMVAns1NYifKLINqnwgpzbvgDoOzQo9HfrgelIEF61lWdI+q1lNd4JKtukhqkA1hRxbDJ4kxEQ
BFHyfV8pwg/T9K3Skt9FsJSmltOzA/oBGt8qd2ulDlKSVKydNztHSLCWc1OSGMuhalIUeVNRq3If
yk6jyQ3xvHWv7NZVE+nA+wNzteB/OY/ckMBx+XqneA==
=YtJC
-----END PGP SIGNATURE-----

--49IcDkDXWfhDrBkYipRUkaJvR1hMgxOU9--


From nobody Sat Aug 28 10:12:57 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA383A0D4D for ; Sat, 28 Aug 2021 10:12:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
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 XTd0hQtCHEEl for ; Sat, 28 Aug 2021 10:12:50 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B64063A0D41 for ; Sat, 28 Aug 2021 10:12:50 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1mK1su-0001VS-J7; Sat, 28 Aug 2021 13:12:48 -0400
Date: Sat, 28 Aug 2021 13:12:42 -0400
From: John C Klensin 
To: Michael StJohns 
cc: rfced-future@iab.org
Message-ID: 
In-Reply-To: <090d5fbd-d0f4-1f39-6546-bc7ee7128657@nthpermutation.com>
References: <2512c470-1721-08d9-b73f-f66248e585ce@nthpermutation.com> <6DD9248A-9E94-4CB9-A3E6-E79B66644545@mnot.net> <090d5fbd-d0f4-1f39-6546-bc7ee7128657@nthpermutation.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: 
Subject: Re: [Rfced-future] Creation/dissolution
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 28 Aug 2021 17:12:54 -0000

Mike and others,

(comment from the fringe)

I've tried to follow this thread (without complete success for
other reasons) and wonder if we are asking the wrong question
and, perhaps as a result, not only overengineering things but
applying our efforts in the wrong place.  Should sufficiently
bad conditions arise, I think it is extremely important that
"we" (for some value of "we") be able to look at the structure
this effort is producing and say "not working; unable to fix
itself; time to discard these ideas and start over".  However,
it is unclear to me that the mechanisms being described (and any
of the variations) are necessary and sufficient to the job.

Consider:

* When we completed the POISED work, we did not include
procedures for dissolving and discarding either the IAB or IESG.
I don't recall it even being discussed, but I think that we
assumed that, if there were serious problems, they were more
likely to lie in people than in institutional structures and
that, if the structures became a significant part of the
problem, we could return to the type of insurrection that led to
the major POISED changes (I think that hypothesis may now be
incorrect, but that is another issue).  These arrangements are
different because the interplay among three to five entitles
(RSAB, RSWG, RSEA*, and maybe RPC and LLC) is more complex than,
IMO, anything we have seen before.  But maybe not that different.

* The analogies to legal entities are interesting and important,
but perhaps mostly because such an entity is one thing that is
not being created here.

* This arrangement might be different, but history suggests that
it is as, and likely more, likely that the IAB or IESG will go
off the rails than the new structure will.  If one or both did
(perhaps by seriously disagreeing with some decision of the RFC
process), requiring those bodies to agree among themselves that
there was a serious enough problem with the RFC Editor Function
to justify dissolving anything would be likely to turn into an
opportunity to entangle the RFC Editor Function in far more
complicated disputes and power games.  In theory, the
community's remedy for that sort of problem --one than cannot
wait out a few Nomcom cycles-- is the recall procedure, but we
know that does not work.

So, two very tentative suggestions instead:

(1) Rather than working on dissolution mechanisms, let's think
of a periodic (or at least one-time) review model.  Perhaps we
could make this effort dormant rather than shutting it down but
reconvene it in a few years to do a review of what is working
and what isn't and whether more or less significant changes are
needed.  That review would focus exclusively on the structural
arrangements and not on people ... unless the structures were
preventing the people from functioning.  If particular people
were preventing the structures from functioning well, that is,
and would be, a different sort of problem.

(2) While it is far outside the scope of this effort, perhaps it
is time to take a serious look at the recall mechanism, the
reasons why it has become impossible to use it as a useful part
of an accountability model, and how it might be chanced or
replaced to be a meaningful accountability mechanism.  It is
possible that what we would learn from that discussion would be
helpful for the RFC Editor Function (or perhaps not).  I note
that the IESG has (at least apparently) been very resistant to
any changes to the recall mechanism that would make it easier
and faster to remove their members from office.  However, at
least part if the reason was that the problem didn't need
fixing.  If there were strong community consensus that it,
indeed, did need fixing, then maybe it would be possible to move
forward.

best,
   john






From nobody Sat Aug 28 14:09:28 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BBE53A1F24 for ; Sat, 28 Aug 2021 14:09:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 ozChXrk4wJ0z for ; Sat, 28 Aug 2021 14:09:22 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4180C3A1F20 for ; Sat, 28 Aug 2021 14:09:21 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1mK5Zm-0001op-Mm; Sat, 28 Aug 2021 17:09:18 -0400
Date: Sat, 28 Aug 2021 17:09:12 -0400
From: John C Klensin 
To: Eliot Lear 
cc: rfced-future@iab.org
Message-ID: 
In-Reply-To: <9231e538-0a08-6edf-37d2-bcacfece6ca9@lear.ch>
References: <9231e538-0a08-6edf-37d2-bcacfece6ca9@lear.ch>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: 
Subject: Re: [Rfced-future] Propose to close: Issue 26: updates RFC 2028?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 28 Aug 2021 21:09:27 -0000

Assuming I'm the "John" in question, I have not changed my
mind... and agree with Eliot about "decrepit".  But it cannot be
this group's problem.  I hope the IESG would agree that it is in
serious need of work and do something about that without this
group having to waste time taking some sort of formal action.

In addition, if someone does believe this group should take 2028
on, I note a procedural problem that would make it more than
just a stretch: since we are not an IETF WG, we'd either need to
undertake the work as a design team then go for AD sponsorship
or seek a charter as an IETF WG in addition to our current
charter.  I see both options as in "don't go there" territory.=20

--On Saturday, August 28, 2021 11:01 +0200 Eliot Lear
 wrote:

> Some time ago, Peter wrote:
>=20
>> Based on John's comments and a review of RFC 2028, I suggest
>> that the  RFC Editor Model Version 3 does not need to specify
>> that it updates  RFC 2028 (whether RFC 2028 itself needs to
>> be updated is outside the  scope of the RFC Editor Future
>> Development Program). Therefore I  suggest that we close this
>> issue.
>=20
> I would go further.=C2=A0 RFC 2028 is decrepit.=C2=A0 It =
should either
> be marked Historic or someone should take up the job and
> really update it.=C2=A0 But the question is whether this group
> needs to take that on?=C2=A0 We have a pretty free hand in =
terms
> of our charter, but let me suggest that this is a stretch.
>=20
> One thing we could do is make a recommendation to the
> community that SOMEONE take that on, in, say, a chairs' report
> or some such, if this group wants.
>=20
> In any case, if you feel strongly that there needs to be an
> action taken regarding RFC 2028, please say something before
> the 11th of September.
>=20
> Eliot
>=20
>=20



From nobody Sat Aug 28 15:26:04 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5309C3A240B for ; Sat, 28 Aug 2021 15:26:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, 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 OvEtPh5VKyvc for ; Sat, 28 Aug 2021 15:26:00 -0700 (PDT)
Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (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 D12D23A2409 for ; Sat, 28 Aug 2021 15:26:00 -0700 (PDT)
Received: by mail-pg1-x534.google.com with SMTP id g184so9490346pgc.6 for ; Sat, 28 Aug 2021 15:26:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=AcIxa5n1wFNLsP1HmN774XXAK4Taur8ZqkZjFl7e8xQ=; b=hu/rkcpUfDyIOfCheKUz4gIRavBahBaV6UFLMs9qXq9mEXd0Lm/OkcgIjYwg3t5QMu KgmF+vye0Elkx0x5vh6e9Lv6L9oxuVCdlbtlY0sl+0QydSrc1HsEiKRB/NYC8amfvGU9 0UsGkr//9Q1941OuaU8ddAXSlLkCA4VOpe1Y+ov45hknaEE/zdS4jf38bXCdE+6B8X97 AlLU3Klvq/DrLzlYbojDY32u1IS5fKVcLBVOX8jdheWPMnFv9g1vhhTPFHdlLt6UMFAR VtiK5kkSe/gO1F1U0v9ftDyalXuR2RRI677XO4dZJiYFLgYLC3qI8iYU07GqzhdnAc0h iVYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=AcIxa5n1wFNLsP1HmN774XXAK4Taur8ZqkZjFl7e8xQ=; b=Das2KI7Z6bwufDnH7KjB9U05bhhAcoG1V0DTygmymts56S1ZYZwnReoG1ELl1lA294 TzHnMPjGDJLj6Q2+SJkV3f4CCk3ouyaAY8bfDJNyc9/Sg+U15Y/v+kuuvY90OpgG9BfI uxzhRlKynN4UM0XAwXh7CUQH6qLmpQP7LGM+Ymkri9Bz5UwP3deNtuQZQC20VSDJD+eB gGsAO+OJV4FK+mvI0tv/PBI47VWJTIap5IsQukllHCsuukp/dOBu6WxVpw3xBwh34W+5 ISqdNSp6l45GzBNnk9FJgRXLwGp1kgL+EWc6qdK5gvqhBY7cZeJITQqftiE85sCnvWIx 5eJQ==
X-Gm-Message-State: AOAM533rmDvFrdvrUWuE8JOE5c1en9hXgXasKAnj6IZeLSpRKHK+1aEj U9SwGTUimImngVwu7x7cLkSLGfeqzbCGBw==
X-Google-Smtp-Source: ABdhPJzZ8GqjNaGlaL5kOnoBCboG9qGJVIwK/1LiLopnj8wSvnTJf+uWVVKWeEbrSVvkvAx2OoADXg==
X-Received: by 2002:a05:6a00:70d:b0:3f6:7f2:1ea9 with SMTP id 13-20020a056a00070d00b003f607f21ea9mr7994919pfl.26.1630189559148;  Sat, 28 Aug 2021 15:25:59 -0700 (PDT)
Received: from ?IPv6:2406:e003:11d3:cf01:80b2:5c79:2266:e431? ([2406:e003:11d3:cf01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id x73sm11060253pfc.98.2021.08.28.15.25.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 28 Aug 2021 15:25:58 -0700 (PDT)
To: John C Klensin , Michael StJohns 
Cc: rfced-future@iab.org
References: <2512c470-1721-08d9-b73f-f66248e585ce@nthpermutation.com> <6DD9248A-9E94-4CB9-A3E6-E79B66644545@mnot.net> <090d5fbd-d0f4-1f39-6546-bc7ee7128657@nthpermutation.com> 
From: Brian E Carpenter 
Message-ID: <202b7346-7841-a7fc-2a28-f46dd6e2b2b5@gmail.com>
Date: Sun, 29 Aug 2021 10:25:56 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Rfced-future] Creation/dissolution
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 28 Aug 2021 22:26:03 -0000

> (1) Rather than working on dissolution mechanisms, let's think
> of a periodic (or at least one-time) review model.

Or do both, but certainly a review mechanism after N years seems
very useful.

(I agree about the recall mechanism needing review, but that should
probably be kicked over the fence to the IETF.)

Regards
   Brian

On 29-Aug-21 05:12, John C Klensin wrote:
> Mike and others,
> 
> (comment from the fringe)
> 
> I've tried to follow this thread (without complete success for
> other reasons) and wonder if we are asking the wrong question
> and, perhaps as a result, not only overengineering things but
> applying our efforts in the wrong place.  Should sufficiently
> bad conditions arise, I think it is extremely important that
> "we" (for some value of "we") be able to look at the structure
> this effort is producing and say "not working; unable to fix
> itself; time to discard these ideas and start over".  However,
> it is unclear to me that the mechanisms being described (and any
> of the variations) are necessary and sufficient to the job.
> 
> Consider:
> 
> * When we completed the POISED work, we did not include
> procedures for dissolving and discarding either the IAB or IESG.
> I don't recall it even being discussed, but I think that we
> assumed that, if there were serious problems, they were more
> likely to lie in people than in institutional structures and
> that, if the structures became a significant part of the
> problem, we could return to the type of insurrection that led to
> the major POISED changes (I think that hypothesis may now be
> incorrect, but that is another issue).  These arrangements are
> different because the interplay among three to five entitles
> (RSAB, RSWG, RSEA*, and maybe RPC and LLC) is more complex than,
> IMO, anything we have seen before.  But maybe not that different.
> 
> * The analogies to legal entities are interesting and important,
> but perhaps mostly because such an entity is one thing that is
> not being created here.
> 
> * This arrangement might be different, but history suggests that
> it is as, and likely more, likely that the IAB or IESG will go
> off the rails than the new structure will.  If one or both did
> (perhaps by seriously disagreeing with some decision of the RFC
> process), requiring those bodies to agree among themselves that
> there was a serious enough problem with the RFC Editor Function
> to justify dissolving anything would be likely to turn into an
> opportunity to entangle the RFC Editor Function in far more
> complicated disputes and power games.  In theory, the
> community's remedy for that sort of problem --one than cannot
> wait out a few Nomcom cycles-- is the recall procedure, but we
> know that does not work.
> 
> So, two very tentative suggestions instead:
> 
> (1) Rather than working on dissolution mechanisms, let's think
> of a periodic (or at least one-time) review model.  Perhaps we
> could make this effort dormant rather than shutting it down but
> reconvene it in a few years to do a review of what is working
> and what isn't and whether more or less significant changes are
> needed.  That review would focus exclusively on the structural
> arrangements and not on people ... unless the structures were
> preventing the people from functioning.  If particular people
> were preventing the structures from functioning well, that is,
> and would be, a different sort of problem.
> 
> (2) While it is far outside the scope of this effort, perhaps it
> is time to take a serious look at the recall mechanism, the
> reasons why it has become impossible to use it as a useful part
> of an accountability model, and how it might be chanced or
> replaced to be a meaningful accountability mechanism.  It is
> possible that what we would learn from that discussion would be
> helpful for the RFC Editor Function (or perhaps not).  I note
> that the IESG has (at least apparently) been very resistant to
> any changes to the recall mechanism that would make it easier
> and faster to remove their members from office.  However, at
> least part if the reason was that the problem didn't need
> fixing.  If there were strong community consensus that it,
> indeed, did need fixing, then maybe it would be possible to move
> forward.
> 
> best,
>    john
> 
> 
> 
> 
> 


From nobody Sat Aug 28 15:37:05 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D5B63A24B8 for ; Sat, 28 Aug 2021 15:37:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, 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 I9QRoiBBiEiJ for ; Sat, 28 Aug 2021 15:37:02 -0700 (PDT)
Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (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 EAA4A3A24B6 for ; Sat, 28 Aug 2021 15:37:01 -0700 (PDT)
Received: by mail-pf1-x429.google.com with SMTP id r13so8605354pff.7 for ; Sat, 28 Aug 2021 15:37:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=pisskpMWbHGCaURUYFCaE04BzRohXTROSmLqR4z73b8=; b=GcLm1JPrFDGqaBdeqPnCgiCL7mLnT34+7h1fM4W/xvnuGNWN/DWFFD/sRJBjDbUMDy 9V6C+pISj/6fEUpbuo8Bf3fPXklgy/zjvwD+uyC3XrX6dEDoxdB/K8SCUvEVjBdTUk9w pNcHGOmH1PQO2mRJE8ZRDkAckEfqdVFzX8RNmqOsG9Sj1VpIkttLY/inr7qtcvGZVEgk MKhGRoAAI3E5wDPqfgi6VqGaosWrRVPiH5f0o4c8aMYJkS6PYOJ24kAHySildY4BivCA 0vqPxIF7Ke1Zg0R25ULrsskVR7X1ogVEvgD+ZjVT7rFwPaTVPhRIbDypn7bTkVOhuLPE 7Mag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=pisskpMWbHGCaURUYFCaE04BzRohXTROSmLqR4z73b8=; b=OWXMXL5Xxi/7yttr9c7BsrQz7o6XW0aPMrpobtDYAYV3Y58E/6j6MOcKJ7KxXE3uR9 A84ToJVXUxyz/EGz+nE1tY1Gi0oTCc/YxyTYJZGj4mMJmHRujNXfZceuefMuMAxPywLW Pg5NVi7dSkpFisGPESbMkSInFrrl41Hj+s4r6S8SxlA36V0iTQhmikECm4Btg+yEnUh4 9Z+QSOCTuRa4VBVoCLRRPlpJM5A1S5fy7AmDVZXTEbhzI8BrU07MNM5KrTeCJRYX78vs TGG/gs08G/3nJpZeXOoQOZj07I6DCpBoZ+r4fzzXlySmbdTSGWuIXqQGj3huGbZ+B56q WN1Q==
X-Gm-Message-State: AOAM533wYc1IvZ/qEoRGVpuEyu1zWHnC3m4z3RzyMJXK1ReE2/0n+CAp Qu548zJj1lnoKaE0PFY4hJbvswps8X8iIQ==
X-Google-Smtp-Source: ABdhPJxfVwukIq6IZ6eEY9nQ4vGsyNMEKraDHZRMJNfhCNqdBVWMAdsfm7x+MyPfqDxqbvdmG1ZOSA==
X-Received: by 2002:a62:6453:0:b0:3fa:69ac:6c88 with SMTP id y80-20020a626453000000b003fa69ac6c88mr4157692pfb.24.1630190220454;  Sat, 28 Aug 2021 15:37:00 -0700 (PDT)
Received: from ?IPv6:2406:e003:11d3:cf01:80b2:5c79:2266:e431? ([2406:e003:11d3:cf01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id t15sm11119145pgk.13.2021.08.28.15.36.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 28 Aug 2021 15:36:59 -0700 (PDT)
To: Eliot Lear , "rfced-future@iab.org" 
References: 
From: Brian E Carpenter 
Message-ID: <8926ef7f-adfa-4b21-9298-f412cf74f2f8@gmail.com>
Date: Sun, 29 Aug 2021 10:36:57 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Rfced-future] Issue 31: Updates RFC 8729?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 28 Aug 2021 22:37:04 -0000

On 28-Aug-21 20:56, Eliot Lear wrote:
> In re-reading RFC 8729, it's pretty clear that we need to make clear th=
at we are updating this document.=C2=A0 For one, it is referencing RFC 87=
28, which I believe we are obsoleting.=C2=A0 For another, it mentions the=20
RSOC, and describes the oversight role of the LLC for these functions, wh=
ich we have now redone.
>=20
> Regarding Section 4.1.3, the text reads as follows:
>=20
>> 4.1.3.=C2=A0 Process Change
>=20
>> =C2=A0=C2=A0 From time to time, it may be necessary to change the appr=
oval
>> =C2=A0=C2=A0 processes for any given stream, or even add or remove str=
eams.=C2=A0 This
>> =C2=A0=C2=A0 may occur when the RFC Editor, the IAB, the body responsi=
ble for a
>> =C2=A0=C2=A0 given stream of documents, or the community determines th=
at there are
>> =C2=A0=C2=A0 issues to be resolved in general for RFC approval or for =
per-stream
>> =C2=A0=C2=A0 approval processes.
>>
>> =C2=A0=C2=A0 In this framework, the general approach is that the IAB w=
ill work
>> =C2=A0=C2=A0 with the RFC Editor and other parties to get community in=
put, and it
>> =C2=A0=C2=A0 will verify that any changes appropriately account for co=
mmunity
>> =C2=A0=C2=A0 requirements.
>=20
> Does this group believe that the IAB has a role to approve changes in a=
pproval process flows of other streams, and in particular, the new stream=20
we have created?

I'm happy with the current text as quoted above, so I want to simply duck=20
your question, except to say that not having the IAB as part of the conse=
nsus to approve this document (including the new stream) would be a blund=
er.

> Also, once we resolve the name of the role of the RSE, we have to decid=
e whether we need to indicate that as an Update to this and other documen=
ts.

Yes, but won't that just be part of a monster review of the other related=20
documents?

> Note that there are many parts of RFC 8729 we probably *don't* want to =
change, such as Section 4.3 and 4.4, and Section 5.

Agreed. But there seem to be three choices:
1) Incorporate them here by reference. In other words, we do Updates: 872=
9 and have a section that details which sections are kept and which secti=
ons are obsoleted.
2) Incorporate them here by value, and do Obsoletes: 8729.
3) Do RFC8729bis.
These are equivalent operations but we need to pick one.

    Brian


From nobody Sat Aug 28 15:39:34 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7326C3A24D2 for ; Sat, 28 Aug 2021 15:39:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 BaWlBnXxCq0o for ; Sat, 28 Aug 2021 15:39:27 -0700 (PDT)
Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (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 193523A24D1 for ; Sat, 28 Aug 2021 15:39:27 -0700 (PDT)
Received: by mail-pg1-x52a.google.com with SMTP id w8so9512224pgf.5 for ; Sat, 28 Aug 2021 15:39:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=+tVFhEEhE6O/l+hK2x/E8fvc2lFfvFvtqOcc7Vrtp8Q=; b=bvqMRMOy8Coi0/SoYANOQtx2BYcelMYanDrIH9VFyj5bJ+bcp26B6c+GX/JHXF+CVH +/rJ/ep5f1eDGzAKMJ2Z4pFgBHPIaeYCDZ627piUoUbrWb11tTG4K7/M0EV0DlDAjD1n 9H9F0IOF1L+egZBxwKpZtYUQV23OV+EK8Gbp1eeYYHqUlOOMDOVBcHZE2E+I118FtPSd d21RmudnnVUrO9gv8M7Jhl0vuvTGvCNmLasSn8DMQ8bacNKmtAe/PMzkgIsSngMgggoP sdSrShlQj6Q0apIih1jtymw94sQGCGR4n19DvzQXoNw9rNTiIN6RlGOAZaPMpxtHy4Nx BDcg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=+tVFhEEhE6O/l+hK2x/E8fvc2lFfvFvtqOcc7Vrtp8Q=; b=OtDRPa84iMoSbTbj3B0+QxI/9cpSRr/TIqo43SQNQ59+Vc3672tPvNMqCKvneu6k6W XnaxwgJLLcrDO8xdtw+88H37FsDEEoFQRRBCt3SwrzH53sBbGHBLQ6xK3akAMXEJLE4J p7Hg+zgZ1DEnyacVP30iIP9/6WhUbrkiPB7l80R2WVWYJLBCTE2rDHEv58tVD6Egcvt8 SMsEvmEZZJh/2de5tza9acyN/zr6VrqBQip/GI74ouqMd+E4ZajKrWwuWynKXG7RyVsh 0EZz43U2XoOM0Y/PQv8gGUyT+TXRNCwuZQL4HainNegmE0JZ841iyPpuvotp6s5zNbVX 0O4A==
X-Gm-Message-State: AOAM530bfq4m3JiO1VGoGUYPJnyXkNICAHzfQO5fTFDiRYxA2dDa0E4G LqLoUuOQ8nIr9EHl1j0gndkfC3YS4ldYSw==
X-Google-Smtp-Source: ABdhPJzLKeu1nkKL9lTR/nY4g3wQoYLdL+FU0e7IiaK3ZBZgzpO4NatZybZFPrvxj48o2bTMI8Op8Q==
X-Received: by 2002:a63:ea58:: with SMTP id l24mr14301809pgk.334.1630190365645;  Sat, 28 Aug 2021 15:39:25 -0700 (PDT)
Received: from ?IPv6:2406:e003:11d3:cf01:80b2:5c79:2266:e431? ([2406:e003:11d3:cf01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id o14sm11134783pgl.85.2021.08.28.15.39.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 28 Aug 2021 15:39:25 -0700 (PDT)
To: John C Klensin , Eliot Lear 
Cc: rfced-future@iab.org
References: <9231e538-0a08-6edf-37d2-bcacfece6ca9@lear.ch> 
From: Brian E Carpenter 
Message-ID: <936f681f-bcec-4144-31bd-fec836956255@gmail.com>
Date: Sun, 29 Aug 2021 10:39:23 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Rfced-future] Propose to close: Issue 26: updates RFC 2028?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 28 Aug 2021 22:39:33 -0000

+1. Over the fence it goes to the IETF, along with updating the Recall pr=
ocess.

Regards
   Brian

On 29-Aug-21 09:09, John C Klensin wrote:
> Assuming I'm the "John" in question, I have not changed my
> mind... and agree with Eliot about "decrepit".  But it cannot be
> this group's problem.  I hope the IESG would agree that it is in
> serious need of work and do something about that without this
> group having to waste time taking some sort of formal action.
>=20
> In addition, if someone does believe this group should take 2028
> on, I note a procedural problem that would make it more than
> just a stretch: since we are not an IETF WG, we'd either need to
> undertake the work as a design team then go for AD sponsorship
> or seek a charter as an IETF WG in addition to our current
> charter.  I see both options as in "don't go there" territory.=20
>=20
> --On Saturday, August 28, 2021 11:01 +0200 Eliot Lear
>  wrote:
>=20
>> Some time ago, Peter wrote:
>>
>>> Based on John's comments and a review of RFC 2028, I suggest
>>> that the  RFC Editor Model Version 3 does not need to specify
>>> that it updates  RFC 2028 (whether RFC 2028 itself needs to
>>> be updated is outside the  scope of the RFC Editor Future
>>> Development Program). Therefore I  suggest that we close this
>>> issue.
>>
>> I would go further.=C2=A0 RFC 2028 is decrepit.=C2=A0 It should either=

>> be marked Historic or someone should take up the job and
>> really update it.=C2=A0 But the question is whether this group
>> needs to take that on?=C2=A0 We have a pretty free hand in terms
>> of our charter, but let me suggest that this is a stretch.
>>
>> One thing we could do is make a recommendation to the
>> community that SOMEONE take that on, in, say, a chairs' report
>> or some such, if this group wants.
>>
>> In any case, if you feel strongly that there needs to be an
>> action taken regarding RFC 2028, please say something before
>> the 11th of September.
>>
>> Eliot
>>
>>
>=20
>=20


From nobody Sat Aug 28 16:03:11 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB6DD3A25A0 for ; Sat, 28 Aug 2021 16:03:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
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 zY_brw9Pq49e for ; Sat, 28 Aug 2021 16:03:05 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8FF23A25A5 for ; Sat, 28 Aug 2021 16:03:03 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1mK7Ln-0001x0-2U; Sat, 28 Aug 2021 19:02:59 -0400
Date: Sat, 28 Aug 2021 19:02:53 -0400
From: John C Klensin 
To: Brian E Carpenter , Michael StJohns 
cc: rfced-future@iab.org
Message-ID: <814CBBD15B87EEEE8B2C2A26@PSB>
In-Reply-To: <202b7346-7841-a7fc-2a28-f46dd6e2b2b5@gmail.com>
References: <2512c470-1721-08d9-b73f-f66248e585ce@nthpermutation.com> <6DD9248A-9E94-4CB9-A3E6-E79B66644545@mnot.net> <090d5fbd-d0f4-1f39-6546-bc7ee7128657@nthpermutation.com>  <202b7346-7841-a7fc-2a28-f46dd6e2b2b5@gmail.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: 
Subject: Re: [Rfced-future] Creation/dissolution
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 28 Aug 2021 23:03:09 -0000

--On Sunday, August 29, 2021 10:25 +1200 Brian E Carpenter
 wrote:

>> (1) Rather than working on dissolution mechanisms, let's think
>> of a periodic (or at least one-time) review model.
> 
> Or do both, but certainly a review mechanism after N years
> seems very useful.

Ack.  But, in case it was not clear from the longer note, my
concern about dissolution mechanisms is that the long discussion
leaves me with the strong feeling that we will take a lot of
time getting the details pinned down and then, if we ever
discover the mechanism is needed, that it won't work.  The most
obvious case is that, if N bodies have to agree that something
should be dissolved, and one of those bodies was part of the
problem...
 
> (I agree about the recall mechanism needing review, but that
> should probably be kicked over the fence to the IETF.)

Indeed.  Relevant to this group only insofar as, if we had a
working one of those, it might provide a useful model for
dealing with a seriously disfunctional collection of RFC Editor
function bodies.  For example, if there were a problem for which
the right solution was to fire the membership of some particular
body and reconstitute the membership from scratch, dissolving
the body may be unnecessarily complex and destructive overkill.

    john


From nobody Sun Aug 29 22:11:52 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A61B3A0CEA for ; Sun, 29 Aug 2021 22:11:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.09
X-Spam-Level: 
X-Spam-Status: No, score=-2.09 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, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch
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 l-3c8IAjyl58 for ; Sun, 29 Aug 2021 22:11:43 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 854143A0CE5 for ; Sun, 29 Aug 2021 22:11:41 -0700 (PDT)
Received: from [IPv6:2001:420:c0c0:1011::1] ([IPv6:2001:420:c0c0:1011:0:0:0:1]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 17U5BcTX071118 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Mon, 30 Aug 2021 07:11:38 +0200
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1630300298; bh=6fcjCfH9FKjNX3bI+10wnPEoT77AVE7rdhEf0L0Bibw=; h=To:From:Subject:Date:From; b=M9eizWtmGWkibtOqhCNByC7+WVH0uwFcXBVOoLB3jTkaWvNd10xmfVWTCTSNiPp2+ 99Kujd+T3K1B6BBFy+qr5qFN5pbYiesVHOFel3QVPoQrdAlRApn6f1s+TsSrwH1POY GfcPCoizq+GL1Sy5pwjzWmgZlXterEuxoEIKhODM=
To: "rfced-future@iab.org" 
From: Eliot Lear 
Message-ID: <25c441eb-f892-90a6-b386-bd872c186117@lear.ch>
Date: Mon, 30 Aug 2021 07:11:34 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5nEiYD1RGMovJIxyjKuyATT1av1WgfKha"
Archived-At: 
Subject: [Rfced-future] minutes posted
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Aug 2021 05:11:51 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--5nEiYD1RGMovJIxyjKuyATT1av1WgfKha
Content-Type: multipart/mixed; boundary="X6MdB087EOnG7mkGIm0qUI24s6mAuCF9a";
 protected-headers="v1"
From: Eliot Lear 
To: "rfced-future@iab.org" 
Message-ID: <25c441eb-f892-90a6-b386-bd872c186117@lear.ch>
Subject: minutes posted

--X6MdB087EOnG7mkGIm0qUI24s6mAuCF9a
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US

The minutes of last week's interim can be found at the following URL:

https://datatracker.ietf.org/doc/minutes-interim-2021-rfcefdp-06-20210826=
2000/

Corrections to the chairs, please.

Eliot



--X6MdB087EOnG7mkGIm0qUI24s6mAuCF9a--

--5nEiYD1RGMovJIxyjKuyATT1av1WgfKha
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmEsaIYFAwAAAAAACgkQh7ZrRtnSejNd
JAgApMJogv525ohXcZkf/3Cs9pNr92rFuVZ3BvaR97s0rWt4cDL0uR1VXB0XCf6RtmCXBxW9zwQh
Z2G+s6pkemIwFaj7hjy3/Lzq/XJUtrWlpVBjmigwF7Nq/rEY1JFIZGtWG3A+yR22DcSnbFKt3au3
SpcKZ1HXD1tV8bHvYYoe7t0qIIwU+QlgXfeVAhvVtCy/GziPE798rf68v6RMF/3ljGIjI0lZnv+W
ba5BwBfI5keuGd6nCFGrwC0iLodeI2gkywLQapbdxurAc1ibRvUrijKH7XSU7ruunkUJwYIkMDvU
2+wMeDJ9AAFWc23ipM6WaGBJMkYdAC9AEvTCPwf2Ww==
=a3wr
-----END PGP SIGNATURE-----

--5nEiYD1RGMovJIxyjKuyATT1av1WgfKha--


From nobody Sun Aug 29 22:23:03 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B62213A0DFA for ; Sun, 29 Aug 2021 22:23:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.09
X-Spam-Level: 
X-Spam-Status: No, score=-2.09 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, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch
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 EYM7WI9r8wl9 for ; Sun, 29 Aug 2021 22:22:56 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F32143A0DFB for ; Sun, 29 Aug 2021 22:22:55 -0700 (PDT)
Received: from [IPv6:2001:420:c0c0:1011::1] ([IPv6:2001:420:c0c0:1011:0:0:0:1]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 17U5MqDP071221 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Mon, 30 Aug 2021 07:22:52 +0200
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1630300972; bh=wi26ZDleXE/SDc79QB75VDMtXnQqZCfTXxtopUuKMJw=; h=To:From:Subject:Date:From; b=R9xGQoD4zlcTlvMdnratXIeGcZhmRnZqv8rSpyIgjNurocFAJPTAsgNiobuoADRbw 4se8dzMNCfUzCxN82pIkN9IVukg96AYjc9D2i3sfdeYZgFFncNwNRaA51xJxt/Qjym 3f8lhSpvV8y/eiEzOpetrCY700va1K+91FYrz/CY=
To: "rfced-future@iab.org" 
From: Eliot Lear 
Message-ID: <05601649-a4f8-eef5-aa87-f9be5208b84b@lear.ch>
Date: Mon, 30 Aug 2021 07:22:51 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="MDMEs6plT1ImC8JTo5NTjM6h5zA4JuTpv"
Archived-At: 
Subject: [Rfced-future] Doodle for the September meeting
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Aug 2021 05:23:02 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--MDMEs6plT1ImC8JTo5NTjM6h5zA4JuTpv
Content-Type: multipart/mixed; boundary="sxIocuZTkC9KQEe3aa6TEUXRSpacbZRpn";
 protected-headers="v1"
From: Eliot Lear 
To: "rfced-future@iab.org" 
Message-ID: <05601649-a4f8-eef5-aa87-f9be5208b84b@lear.ch>
Subject: Doodle for the September meeting

--sxIocuZTkC9KQEe3aa6TEUXRSpacbZRpn
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US

Hi everyone,

Here is a doodle for the next interim meeting:

https://doodle.com/poll/mdnhyfsmp6kyrax9

Would you mind entering your preferences by Friday, September 3rd?

Thanks,

Eliot



--sxIocuZTkC9KQEe3aa6TEUXRSpacbZRpn--

--MDMEs6plT1ImC8JTo5NTjM6h5zA4JuTpv
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmEsaysFAwAAAAAACgkQh7ZrRtnSejPk
BQf/dgoNLq5k/pM/1hoo1zpDFU73zOxRAEnGTa/BLtROnlxAVA8c/zaOJ6q3J66xUKEyKHUW6wQx
T+HCR2oDjORBMCdeY29porodGsbQqPtrYzMznzym8FBXoO2JstPW52ERY3XnpPrUgM4T0GlX9OMf
NSbrKhzohALCeVJ59Th05fUT+Fuw+L5pCAZ3J1jeBwdeuV86R6KYN4fK5TrSGOzQrmSWQeqL8qpd
mVdA0zJ3PYtHjYNxLJP09UcdZzAdY0SuzHw3kHwLkUMj+HYV4O4fJ2rRR7GiBUQ6dWkX5B+CT96M
iq8m8L0w3WTDBO7+QDyvQZuIM92rLJ9MWSL3+wpWtQ==
=oaO1
-----END PGP SIGNATURE-----

--MDMEs6plT1ImC8JTo5NTjM6h5zA4JuTpv--


From nobody Sun Aug 29 22:56:16 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F06CC3A1413 for ; Sun, 29 Aug 2021 22:56:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.891
X-Spam-Level: 
X-Spam-Status: No, score=-0.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=lear.ch
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 8ZAmbokqcXSj for ; Sun, 29 Aug 2021 22:56:09 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D9363A1417 for ; Sun, 29 Aug 2021 22:56:08 -0700 (PDT)
Received: from [IPv6:2001:420:c0c0:1011::1] ([IPv6:2001:420:c0c0:1011:0:0:0:1]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 17U5u1QL071894 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Mon, 30 Aug 2021 07:56:02 +0200
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1630302962; bh=WI+YhKoNui0q5WIJgXHJif8p0qMzF+fCenda38I0LsE=; h=To:References:From:Subject:Date:In-Reply-To:From; b=J+NUuXyon76sOLLYIILkxVbzG8WsCCqFMgI94yvtt33EhPHEl0Ucaa8r24OcjdFHL U7qJP3QSN1XIGqjUNe6rG1GpqxdAxDeGH3EOYuHmfKhxGKJ3ur7nA3S9ohzBMDMcxL EqVF/6A14V24kewxs9DsRWUB0V05akwITzrFujHE=
To: Brian E Carpenter , "rfced-future@iab.org" 
References:  <8926ef7f-adfa-4b21-9298-f412cf74f2f8@gmail.com>
From: Eliot Lear 
Message-ID: <9209021a-e58a-2e5e-624b-c35723b71272@lear.ch>
Date: Mon, 30 Aug 2021 07:56:00 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <8926ef7f-adfa-4b21-9298-f412cf74f2f8@gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="w6sEBmqquiy9SzK3FeuEkavF4Y5D8nfuN"
Archived-At: 
Subject: Re: [Rfced-future] Issue 31: Updates RFC 8729?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Aug 2021 05:56:15 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--w6sEBmqquiy9SzK3FeuEkavF4Y5D8nfuN
Content-Type: multipart/mixed; boundary="Z36zRtLn8jBXUIkJF7m0gfSC9Hzh1vQ4w";
 protected-headers="v1"
From: Eliot Lear 
To: Brian E Carpenter ,
 "rfced-future@iab.org" 
Message-ID: <9209021a-e58a-2e5e-624b-c35723b71272@lear.ch>
Subject: Re: [Rfced-future] Issue 31: Updates RFC 8729?
References: 
 <8926ef7f-adfa-4b21-9298-f412cf74f2f8@gmail.com>
In-Reply-To: <8926ef7f-adfa-4b21-9298-f412cf74f2f8@gmail.com>

--Z36zRtLn8jBXUIkJF7m0gfSC9Hzh1vQ4w
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US

Hi Brian,

On 29.08.21 00:36, Brian E Carpenter wrote:

>> Also, once we resolve the name of the role of the RSE, we have to deci=
de whether we need to indicate that as an Update to this and other docume=
nts.
> Yes, but won't that just be part of a monster review of the other relat=
ed
> documents?

That is what I am attempting to get started.=C2=A0 Feel free to join in!

>
>> Note that there are many parts of RFC 8729 we probably *don't* want to=
 change, such as Section 4.3 and 4.4, and Section 5.
> Agreed. But there seem to be three choices:
> 1) Incorporate them here by reference. In other words, we do Updates: 8=
729 and have a section that details which sections are kept and which sec=
tions are obsoleted.
> 2) Incorporate them here by value, and do Obsoletes: 8729.
> 3) Do RFC8729bis.
> These are equivalent operations but we need to pick one.


That sums it up nicely.=C2=A0 If we Update RFC 8729, we need to describe =
what=20
has changed.=C2=A0 The introduction of the document itself is going to be=
=20
obsolete.

Eliot



--Z36zRtLn8jBXUIkJF7m0gfSC9Hzh1vQ4w--

--w6sEBmqquiy9SzK3FeuEkavF4Y5D8nfuN
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmEscvAFAwAAAAAACgkQh7ZrRtnSejMx
MAgAmjA6VA4BrW+66UKqU9avDB67bn2GnAlL4liLzWhSvZ+F0ECr9wSWXcfjzLU8kl2trxN5B9IF
4wGBpmigiUbuFMxcRy816S1xugliH6j1cb+J4Rk9nebFXoW2mpmb3VD6haNPzp2SrVko6uQ+4+69
HHbirObllugsuKdBfC64TiAUtFtJ+zK6cqtTjFAd1z+Go0sToroyj4E0zMIaOU8UKLJKa3EaUhwJ
5l0qgtiTscaIVxXnHcAyYY3MJhOqQYOksLw9gnZ/hEozoM41EXAC5c9kLnQl0rG1M03B7R7L9VcH
3q57If9EEAeavD2HWxr/IVMpRK70xfKom0t+g6IU4A==
=WSb4
-----END PGP SIGNATURE-----

--w6sEBmqquiy9SzK3FeuEkavF4Y5D8nfuN--