Hi Paul, Thanks for your feedback and the set of questions below. It helps us understand where clarification in the processing instructions are needed.
> https://www.rfc-editor.org/rpc/wiki/doku.php?id=rpc-github-phase-0-pilot-test > says: > > Authors will provide feedback on the RFC-to-be using GitHub's review and > issue-tracking tools. Once the authors approve changes, the PR will be > merged. If the document source is kramdown-rfc, there will be an additional > step of approving the RFCXML and output formats. > > - How are we meant to use the review tools? I assume that we are not expected > to leave a comment for every red-green pair in > https://github.com/rfc-editor/AUTH48-rfc9920/pull/1/files > Do we just put in comments for the ones where we have questions? If so, how > do you know when we are finished? How do we know when the RPC has agreed or > disagreed with every comment that we do make? We do not expect you to leave a comment for every instance of change. We imagined authors would include comments for any additional changes needed (e.g., if you disagree with a change or want to make additional changes) or submit additional PRs as needed, ideally against the RPC-edits branch. The RPC would use comments to discuss any issues, as needed. You can send us an email when you have finished your review, and we will then respond to any comments. > - Some but not all of the issues are duplicates of what is in the pull > request. How do you want us to deal with the issues that are duplicated in > the pull request? If the update in the pull request is acceptable, please reply using the comments for the related Issue. If any changes are needed, please either note the update in the comments or commit a suggested update against the PR. > For the ones not in the pull request that require changes to the document, do > we create a new pul request or use the "review" feature to add a comment that > would add text? Or do we add commits to the current pull request? Yes, we would accept either of these. > - Do we authors close issues where there is no action needed, or does the RPC? The RPC will close the issues as they are resolved. Please let us know if you have any further questions. Best regards, Rebecca VanRheenen RFC Production Center > On Jan 11, 2026, at 5:36 PM, Paul Hoffman <[email protected]> wrote: > > [[ Removed RSAB because these are procedural questions. ]] > > Greetings. Based on what I read in the guidelines. I'm now deeply confused > about how to do AUTH48 on this document. > > https://www.rfc-editor.org/rpc/wiki/doku.php?id=rpc-github-phase-0-pilot-test > says: > > Authors will provide feedback on the RFC-to-be using GitHub's review and > issue-tracking tools. Once the authors approve changes, the PR will be > merged. If the document source is kramdown-rfc, there will be an additional > step of approving the RFCXML and output formats. > > - How are we meant to use the review tools? I assume that we are not expected > to leave a comment for every red-green pair in > https://github.com/rfc-editor/AUTH48-rfc9920/pull/1/files > Do we just put in comments for the ones where we have questions? If so, how > do you know when we are finished? How do we know when the RPC has agreed or > disagreed with every comment that we do make? > > - Some but not all of the issues are duplicates of what is in the pull > request. How do you want us to deal with the issues that are duplicated in > the pull request? For the ones not in the pull request that require changes > to the document, do we create a new pul request or use the "review" feature > to add a comment that would add text? Or do we add commits to the current > pull request? > > - Do we authors close issues where there is no action needed, or does the RPC? > > Specific answers would be greatly appreciated. > > --Paul Hoffman > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
