Re: [Rfced-future] [IAB] I18ndir last call review of draft-iab-rfcefdp-rfced-model-11

[Jay Daley <[e-mail]>]

> On 2/03/2022, at 8:15 AM, Peter Saint-Andre <[e-mail]> wrote:
> 
> On 2/28/22 2:45 AM, Eliot Lear wrote:
>> Hi Martin,
>> Thanks. Just to close the loop:
>> On 28.02.22 09:06, Martin J. Dürst wrote:
>>> "In short:": What follows isn't really any much shorter than what preceded it,
>>>>>> so the "in short" seems a bit misplaced.
>>>>>> 
>>>>>> "*  If approved, such proposals are published as RFCs in the Editorial
>>>>>>      Stream and thus define the policies to be followed by the RSWG,
>>>>>>      RSAB, RSCE, and RPC."
>>>>>> Shouldn't the IETF LLC also be mentioned here? My understanding is that the LLC
>>>>>> can say that something won't work because there's no money for it, but that
>>>>>> once it has accepted that a policy is implementable with reasonable means, it
>>>>>> also has to follow this policy.
>>>>>> 
>>>> The LLC role is described in detail below.  I don't think mention is necessary here.
>>> 
>>> Well, things will probably work out either way. But in my view, it would be better if it were clear here that the LLC has to follow accepted policies, too.
>> We are very careful in the draft *not* to be prescriptive to the LLC as a whole.  The board in particular cannot be bound to this document, though they can be guided.
> 
> I'm curious if Jay has any concerns about adding the IETF LLC to this sentence.

My view remains as previously expressed - RFC 8711 is unequivocal on the requirement for the LLC to "follow accepted policies":

     "Responsiveness to the community.  The IETF LLC is expected to act
      consistently with the documented consensus of the IETF community,
      to be responsive to the community's needs, and to adapt its
      decisions in response to consensus-based community feedback."

I’m opposed to any need to restate this in any RFC that does not update/replace 8711 because a) It is unnecessary - RFC 8711 says it all;  b) we then have make sure to add that language everywhere to ensure that we never imply by omission that there are circumstances under which the LLC can not follow accepted policies; c) we then have to start considering "should we also add the IESG, the IAB, the Trust?" etc.

The RSWG, RSAB, RSCE and RPC are the key subjects of this RFC and so this is the appropriate place for setting out how they are bound by policy, and we don’t need to go any further than them.

cheers
Jay

> 
>>>>>> " The RSWG may decide by rough consensus to use additional tooling
>>>>>>   (e.g., GitHub as specified in [RFC8874]), forms of communication, and
>>>>>>   working methods (e.g., design teams) as long as they are consistent
>>>>>>   with [RFC2418]."
>>>>>> Should this read "as long as they are consistent with [RFC 2418] and this
>>>>>> document?"
>>>> 
>>>> Do we say anything else in that document?
>>> 
>>> By "this document", I mean draft-iab-rfcefdp-rfced-model and the RFC that it will (hopefully soon) become. Which document do you mean by "that document"?
>> draft-iab-rfcefdp-rfced-model.  Yes.
> 
> Martin's suggestion seems fine.
> 
>>>>>> 3.1.2.4.  Vacancies
>>>>>> This is the part that I'm really still not sure about. First, there's a problem
>>>>>> with what the text means. Imagine a first 3-month period, during which a second
>>>>>> 3-month period starts. So far, the text is clear. But let's say then there's a
>>>>>> third 3-month period, which overlaps with the second one. Does that extend the
>>>>>> delay again? Or is there only one delay, because the text mentions only one
>>>>>> delay? This should be clarified. On a higher level, I think the probability of
>>>>>> these things happening are very low, but in the whole new process, this is one
>>>>>> of the weakest points.
>>>> 
>>>> As you are aware, this was painfully negotiated text, and as you point out, this is a corner case.
>>> 
>>> I'm definitely aware of all the background, but in my role as a reviewer, I wanted to make sure others are, too.
>> Ok.
> 
> Well, we could tweak it as follows:
> 
> OLD
> 
>   *  Voting on approval of policy documents produced by the RSWG shall
>      be delayed until the vacancy or vacancies have been filled, up to
>      a maximum of 3 months.  If during this 3-month period a further
>      vacancy arises, the delay should be extended by up to another 3
>      months.  After the delay period expires, the RSAB should continue
>      to process documents as described below.
> 
> NEW
> 
>   *  Voting on approval of policy documents produced by the RSWG shall
>      be delayed until the vacancy or vacancies have been filled, up to
>      a maximum of 3 months.  If during this or any subsequent delay
>      period a further vacancy arises, the delay period should be
>      extended by up to another 3 months.  After the delay period
>      expires, the RSAB should continue to process documents as
>      described below.
> 
> But this would introduce the possibility of an infinite delay period, which seems suboptimal even if highly unlikely.
> 
>>>>>> 4.3.  RPC Responsibilities
>>>>>> point 17: "depositing copies on the RFC Editor site both individually and in
>>>>>> collections": As far as I understand, maintaining the RFC Editor website will
>>>>>> also be the responsibility of the RPC, but this isn't listed in these points.
>>>>>> This should be added. The word "depositing" then makes even less sense than it
>>>>>> does currently, I'd replace it with "publishing".
>>>> Adding the website responsibility seems reasonable.  The word "depositing" matters in as much as other repositories are involved, such as the U.S. Library of Congress or the like.
>>> 
>>> Yes, but that's covered by the *second* bullet of point 17, reading
>>> *  depositing copies with external archives
>>> There, as you say, "depositing" is a very good choice.
>>> 
>>> My comment was that for the *first* bullet of point 17, "depositing" doesn't make much sense.
>> Ah ok.  Then I leave this to Peter as well, editorially.
> 
> I'd change "depositing" to "posting".
> 
> Peter
> 
> -- 
> Rfced-future mailing list
> [e-mail]
> https://www.iab.org/mailman/listinfo/rfced-future

-- 
Jay Daley
IETF Executive Director
[e-mail]