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

[Peter Saint-Andre <[e-mail]>]

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.

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