**Session Date/Time:** 25 Jul 2022 17:30

# RSWG Meeting Minutes

## Summary

The RSWG session focused on establishing initial ground rules, discussing its scope, and reviewing a list of potential policy issues for the RFC Series. Key discussions revolved around defining "policy," managing workflow logistics (including GitHub for issue tracking), and understanding the group's role in format evolution. A significant portion of the meeting was dedicated to the status and publication process of RFC 7991bis, which describes the current RFC XML format implementation, with strong calls to publish it promptly as a descriptive artifact while continuing policy discussions on its content.

## Key Discussion Points

*   **Scope and Acceptance Criteria**:
    *   Chairs proposed criteria for new work: must be about policy, have enthusiasm, show rough consensus on a plausible starting point.
    *   Community feedback highlighted the blurriness of "policy" and the potential for issues arising from the RPC/RSAB that might require work regardless of initial enthusiasm.
    *   Distinction was made between policy work and expert review/implementation details, suggesting not everything is in RSWG scope.
    *   A mechanism for handling non-policy issues (e.g., an issues list) was suggested to avoid arguments about scope and allow the RPC to be aware of community concerns transparently.

*   **Logistics and Workflow**:
    *   Chairs proposed using GitHub as an issue tracker for proposals and general issues, with mailing lists for discussions. No strong objections were raised, though concerns about GitHub's usability for intermittent tracking were noted.
    *   Discussion topics brought to the group would remain "loose issues" until a draft is authored and proposed for adoption as a working group item.
    *   Meeting cadence: Face-to-face during IETF meetings, primarily remote/asynchronous discussions for most work, with synchronous meetings reserved for critical resolutions.

*   **Review of Potential Policy Issues/Proposals**:
    *   **Documenting Relationships**: Interest in clarifying RFC relationships and process was noted.
    *   **Updating and Versioning**: Perennial question of referential integrity and RFC versioning.
    *   **RSWG List vs. RFC Interest List**: Clarifying the role and boundaries of each.
    *   **Unknown/Legacy RFC Statuses**: Addressing RFCS in unclear statuses or legacy streams.
    *   **IAB Stream BCPs**: Managing instances where the IAB stream produced BCPs outside its charter.
    *   **RFCs on Multiple Streams**: Policy regarding RFCs belonging to more than one stream.
    *   **RFC Email Announcements/Boilerplate**: Questions about content and standardization.
    *   **Author Ethics**: Responsibilities of authors regarding acknowledging previous work/authorship, especially when reusing content.
    *   **Format Evolution**:
        *   Discussion on who is empowered to evolve the RFC format.
        *   Robert H. argued that RSWG is the appropriate venue for grammar and presentation (CSS) evolution, proposing to allow UTF-8 throughout RFCs.
        *   Elliot acknowledged intentional vagueness in RFC 9280, suggesting RSWG can judge what it wants but should proceed cautiously.
        *   Mike S. suggested defining initial scope carefully to avoid fragmentation.
        *   Consensus on whether RSWG should micromanage tag names vs. providing direction.
    *   **Internet Drafts Policy Creep**: Concern that RFC policy decisions could inadvertently impact Internet Drafts, which are governed by the IESG. Lars stressed the ISG's responsibility for ID policy.
    *   **Errata Trolls**: Whether more gateways are needed to prevent problematic errata.
    *   **Note Well Text**: Reviewing the Note Well text for proper alignment with RSWG's context, specifically regarding anti-harassment, IPR sections, and general IETF meeting consents.

*   **RFC 7991bis Discussion (Format of RFCs)**:
    *   This document describes the current XML format for RFCs as implemented by tooling.
    *   **Mirja**: Advocates for publishing 7991bis quickly on the IAB stream as it reflects current implementation, allowing RSWG to then start new work.
    *   **Mark N.**: Argued that the document is not "done," as it describes one implementation, and the IETF should document an interoperable format. Changes need community review, not just direct publication based on tooling.
    *   **Julian**: Noted 7991bis was intended to be a snapshot quickly revised but has been delayed for years. Highlighted ambiguities and flaws (especially metadata) that, if fixed, would affect published canonical XML, urging caution before publishing as an RFC.
    *   **Robert H.**: Supported publishing the current state (7991bis) as a descriptive artifact, even with known flaws, to provide a baseline for currently published RFCs, before embarking on a potentially long process of revising policy or republishing.
    *   **Paul H.**: Emphasized 7991bis is an *implementation description*, not a `bis` document that sets a standard. He suggested publishing a document that clearly describes what *has been done* to date, separate from future policy work.
    *   **Lars**: Agreed with documenting the current tools' behavior to align description with action, even if imperfect, to provide a starting point for future consensus-based changes.
    *   **John C.**: Agreed to publish a snapshot quickly, making it clear it's descriptive of an implementation, not normative, to facilitate identifying areas of contention.

## Decisions and Action Items

*   **Agenda Approval**: The proposed agenda was approved without objection.
*   **Issue Tracking**: The Chairs will set up an issue tracker (likely using GitHub as a starting point) to manage proposals and open issues.
*   **Discussion Venue**: All substantive discussions will primarily take place on the working group mailing list.
*   **7991bis Discussion**: The discussion regarding RFC 7991bis (its status, publication, and the process for future format evolution) will continue on the mailing list. The Chairs will monitor the discussion and provide a summary or call for consensus.

## Next Steps

*   **Chairs**:
    *   Set up and populate the GitHub issue tracker with the proposals and issues discussed.
    *   Monitor the mailing list for further discussion on RFC 7991bis and related format evolution.
    *   Invite John Levine to discuss operational issues he's facing to inform policy work.
*   **Working Group**:
    *   Engage in asynchronous discussions on the mailing list for proposed issues.
    *   Authors are encouraged to develop drafts for adoption as working group items once momentum builds on a topic.
    *   Consider the proposal for UTF-8 throughout RFCs.
    *   Engage with the RSAB to clarify the line between policy and implementation details.