WG Work Items require WG engagement.
What is “WG engagement”? The WG should be interested in the content and involved in developing the document. WG engagement implies at least two reviews or a robust technical discussion.
The Chairs will determine whether WG engagement exists.
Reviews
A review is a set of comments about the overall state of the document or its contents. It is more than "I read the draft and support it", and certainly more than "support" or "+1".
A lack of reviews or volunteers to do them can be interpreted as a lack of interest in the work.
Technical Discussions
A robust technical discussion is related to the contents of a draft, its options, or other related topics. The expectation is that at least one non-author represents other perspectives from what is written in the draft or points out missing considerations. IOW, there should be a conversation or debate -- to reach a decision or exchange ideas.
Ideally, the authors can start a discussion on the list by pointing out items they want feedback on or the main enhancements proposed. An active on-list discussion will help prioritize meeting time.
WG Adoption Calls
Authors are encouraged to request adoption once they believe WG engagement has been achieved.
When authors request adoption and if the Chairs determine that WG Engagement exists, the document is placed in the "Candidate for WG Adoption" state. When the call for adoption starts, the document will move to the “Call For Adoption By WG Issued" state.
WGLCs
For WG documents, continued WG engagement is required. The authors must engage the WG by starting discussions on the list or giving presentations (of significant updates).
When authors request WGLC, the Chairs appoint a Document Shepherd, who may be a WG Chair or participant, with a preference for participants serving as shepherds, if they consider the WG engagement bar met. The Document Shepherd must provide a technical review of the document and ensure that any open issues have been closed. At that point, the Document Shepherd advises the Chairs to start the WGLC.
Authors must provide a progress report for their WG documents before each plenary IETF meeting. Progress is not expected for every draft at every cycle, but it would be nice.
For this working group, when an I-Ds is ready for WG last call it MUST have an implementation section based on, but somewhat more than, that mandated by RFC 7942 (BCP 205, Improving Awareness of Running Code: The Implementation Status Section). We are asking that all items identified in section 2 of RFC 7942 be included. When information is not available, it is acceptable to say "not known". It is desirable if this section can be added earlier and maintained by the document editor for the benefit of the WG process.
Authors are asked to collect information about implementations and include what they can find out when that information is available for public disclosure. Documents will not be blocked from publication if the authors fill in the section as "none report" or "does not apply" when they have made an effort to get information and not been able to.
There are a couple of important additions to what is called for in RFC 7942. We have confirmed with leadership that these changes are acceptable in terms of IETF process:
1) Each implementation description SHOULD include either a statement that all MUST & SHOULD clauses in the draft are implemented, or a statement as to which ones are not implemented. If it does not include that, it MUST say that has been omitted.
2) each implementation description may include reports of what optional elements of the draft are implemented.
Reports of interoperability testing are strongly encouraged. Including the reports in the document is preferred or alternatively in the SPRING wiki. This may include a reference to longer and more detailed testing reports available elsewhere. If there are no reports of interoperability tests, then the section MUST state that no such reports were received.
1) Information which is generally applicable to IPv6 nodes should go
into IPv6 destination options, including the use of destination options
before routing headers for the case of IPv6 nodes that are destinations
of routing header paths.
2) Information that is specific to SRH processing should go in SRH TLVs.
3) We should not define the same information in both places.