Re: [rsab] Preparing for RSAB's first document

[Robert Sparks <[e-mail]>]

On 4/17/24 11:33 AM, Mirja Kuehlewind (IETF) wrote:
> Hi Robert,
>
> To catch up on this. I now see that the “request publication” button 
> is the final request to send it to the RPC. This should of course only 
> be visible to the RSAB chair and secretariat. However, I think it 
> would nice to have a button for the RSWG chairs to request RSAB 
> approval similar as IETF WG chair have a button “Submit to IESG for 
> publication”.
>
> Also while IETF documents haven WG state (under the stream section) 
> and IESG state (under the IESG section), for RSWG and RSAB all states 
> are now mixed into one Editorial State. This means the RSWG chair can 
> actually change this state and set the document into RSAB specific 
> states. I know this is the same for how the IRTF document process 
> works but I would actually recommend to eventually fix that as well. I 
> don’t know how much work that will be but can we add that separation 
> for RSAB to the tool team roadmap?
I'll track this.
>
> Mirja
>
> P.S.: Is it actually bug that IRTF docs also have the IESG section?
No - Remember that the IETF IRTF interaction is managed with a 
_separate_ document (conflict-review) not with states on the IRTF document.
>
>
>
>> On 13. Mar 2024, at 14:38, Robert Sparks <[e-mail]> wrote:
>>
>>
>> On 3/13/24 7:14 AM, Mirja Kuehlewind (IETF) wrote:
>>> Quick update on the datatracker: As far as I tested it now in the 
>>> dev instance, Cindy and I can open and close the ballots but I don’t 
>>> think we have any RSAB state handling yet. Thus for now we would 
>>> need to do that “manually” and send the respective mails directly. 
>>> Also I can see a publication request button my view but I don’t 
>>> think it works correctly yet. I’m checking with Robert on all this.
>>
>> This is like all the other streams than the IETF stream. Chairs of 
>> RG, for instance, don't have a button asking that the IRSG consider a 
>> document. Instead, that's currently handled out-of-band, and Colin 
>> creates the IRSG ballot. When that ballot is created, mail does get 
>> sent (and mail gets sent when an editorial stream ballot gets created 
>> too).
>>
>> The "request publication" button is again similar to the IRTFs. 
>> You're hitting a problem with a missing state (yes, the states were 
>> created, but that particular one is missing - it will be in 
>> production later today and on the dev instance tomorrow when the 
>> databases sync). With the state in place the workflow succeeds.
>>
>> RjS
>>
>>>
>>> @Alexis if you log in with my email address in the dev instance you 
>>> can test that as well!
>>>
>>>
>>>
>>>> On 13. Mar 2024, at 11:35, Mirja Kuehlewind (IETF) 
>>>> <[e-mail]> wrote:
>>>>
>>>> Hi Alexis, hi all,
>>>>
>>>> Thanks for starting this! I wanted to sent something earlier but 
>>>> was busy with other things. However, this was finally on my todo 
>>>> list for today.
>>>>
>>>> I will send a separate mail soon and propose a more detailed 
>>>> process but please see some answers below.
>>>>
>>>>> On 13. Mar 2024, at 02:02, Alexis Rossi <[e-mail]> wrote:
>>>>>
>>>>> In anticipation of getting our first document from RSWG [1], it 
>>>>> seems like we should start contemplating how the RSAB portion of 
>>>>> the process will play out.
>>>>>
>>>>>
>>>>>
>>>>> ** Notice & Comments - where do they live long term? **
>>>>>
>>>>> RFC 9280 defines some things about how notices and comments should 
>>>>> be presented/archived:
>>>>>
>>>>> - "The RSAB shall announce plans and agendas for their meetings on 
>>>>> the RFC Editor website and by email to the RSWG at least a week 
>>>>> before such meetings." (Section  3.1.2.6)
>>>>> - "Notices are also to be made available and archived on the RFC 
>>>>> Editor website.” (Section  3.2.3)
>>>>> - "Comments will be publicly archived on the RFC Editor website." 
>>>>>  (Section  3.2.3)
>>>>>
>>>>> Since this was written, it seems like a lot of functionality moved 
>>>>> to Datatracker, so the requirement that things be on 
>>>>> rfc-editor.org may now be out of date (obviously we’re already not 
>>>>> doing the first one for agendas). The spirit here seems to be “all 
>>>>> records are publicly available where the community can easily find 
>>>>> them.” I’m hoping the solution is to have a page about RSAB on 
>>>>> rfc-editor.org that points to Datatracker, or something or similar 
>>>>> (rather than needing to update 9280 to be correct/less specific 
>>>>> about implementation details).
>>>>>
>>>>> As a specific answer to “where” notice and comments live long 
>>>>> term, I think they live in the mail archive?
>>>>>
>>>> Yes, I would interpret this the same way that we keep the record in 
>>>> the datatracker and comments in the RSAB mail archive. I think it 
>>>> would be good to put some information on the RFC editor webpage 
>>>> that links to the ressources! I don’t think we need to update 
>>>> RFC9280 for that as long as it is clear where to find the 
>>>> information and there is a public record.
>>>>
>>>>>
>>>>> ** Notice & Comments - which lists? **
>>>>>
>>>>> Question #1 - does this document have "the potential to 
>>>>> significantly modify long-standing policies or historical 
>>>>> characteristics of the RFC Series” (section 3.2.3), thus requiring 
>>>>> “extra care”? If so, what “extra care” is required?
>>>>
>>>> I would say by default there is usually no extra care required. I 
>>>> think that this part is in the doc for the case of a drastic change 
>>>> where we want to do more than the “usual” thing. As I said I will 
>>>> send an extra to make a proposal for the “usual” thing, however, I 
>>>> guess for every document before we send the call we should make a 
>>>> quick review if any additional outreach would make sense.
>>>>
>>>>>
>>>>> Question #2 - To which email lists (or other places) should we 
>>>>> provide notice? Rfc-interest is specified in 9280, as well as 
>>>>> saying "RSAB members should also send a notice to the communities 
>>>>> they directly represent (e.g., the IETF and IRTF)” (section 
>>>>> 3.2.3). Are there other lists we should post notice to?
>>>>
>>>> I will make a concrete proposal in my next mail.
>>>>
>>>>>
>>>>> Question #3 - Should we require that Comments only be sent to one 
>>>>> particular list for the sake of record keeping? Should that be 
>>>>> [e-mail]?
>>>>
>>>> Yes, I would propose to send the reply-to to 
>>>> [e-mail] for all calls. [e-mail] has a public 
>>>> archive, so I think that is fine.
>>>>>
>>>>>
>>>>>
>>>>> ** Balloting **
>>>>>
>>>>> Jean pointed out that balloting should be implemented on 
>>>>> Datatracker (per 
>>>>> https://github.com/ietf-tools/datatracker/issues/4332). Having 
>>>>> never used the balloting system before, I guess I’m assuming that 
>>>>> this will work as desired (I don’t know where it is or how to test 
>>>>> it). Do we need to do any testing to make sure it functions as needed?
>>>>
>>>> There is the dev instance of the datatracker (there was also the 
>>>> sandbox but that is currently not in use and redirects to the dev 
>>>> instance). So got to dt-main.dev.ietf.org 
>>>> <http://dt-main.dev.ietf.org/> (or sandbox.ietf.org 
>>>> <http://sandbox.ietf.org/>). There you can log in with anybody’s 
>>>> email address to get their view and simply use “password” as 
>>>> password. E.g. you can log in as RSWG chair by using Pete’s or 
>>>> Russ’ email address. All changes you do there will be reset after a 
>>>> while, so the instance is back in sync with the real datatracker 
>>>> and also no emails will be send (but there is a notice that tells 
>>>> you which emails would have been sent in the real instance).
>>>>
>>>> I just tested this by logging in as Pete and going to the page of 
>>>> the 7997bis draft. There is already a tap for the RSAB evaluation 
>>>> but I don’t see a button to request RSAB review and also no RSAB 
>>>> state. I’m in touch with Robert now. For anything where we don’t 
>>>> have datatracker support we have to send emails manually. We can 
>>>> also look at this together in Brisbane if you want!
>>>>
>>>> Mirja
>>>>
>>>>
>>>>
>>>>>
>>>>> Alexis
>>>>>
>>>>> [1] https://github.com/paulehoffman/draft-rswg-rfc7990-updates
>>>>> -- 
>>>>> RSAB mailing list
>>>>> [e-mail]
>>>>> https://mailman.rfc-editor.org/mailman/listinfo/rsab
>>>>
>>>> -- 
>>>> RSAB mailing list
>>>> [e-mail]
>>>> https://mailman.rfc-editor.org/mailman/listinfo/rsab
>>>
>> -- 
>> RSAB mailing list
>> [e-mail]
>> https://mailman.rfc-editor.org/mailman/listinfo/rsab
>