(also posted at https://datatracker.ietf.org/group/iesg/appeals/artifact/127)
Hi Aijun! # Summary On November 6, 2024, Aijun Wang appealed the conclusion of the Working Group Last Call (WGLC) of draft-ietf-lsr-multi-tlv, a document of the Link State Routing (LSR) working group. The appeal claims “technical issues unresolved” and furthermore claims consensus to advance the document has not been developed. The full text of this appeal can be found at \[1\]. The responsible Area Director (AD) for the LSR working group is Gunter van de Velde. He did not take part in the processing of this appeal. The IESG has reviewed the working group’s processing of the document and its mailing list archive, and finds that the record does not support the claimed defects in process or content. The appeal is denied. # Procedural History According to the IETF datatracker \[DT\] and the LSR mailing list archive \[ML\]: * 2022-01-21: \-00 version of individual draft (draft-pkaneria-lsr-multi-tlv) published \[DT\] * 2023-12-09: \-00 first version of adopted working group draft published \[DT\] * 2024-07-02: \-01 version placed in WGLC state \[DT\] * 2024-10-14: Chairs declare WGLC complete with consensus to proceed \[ML\] * 2024-11-02: “request formally that AD to step in to resolve the issues” posted \[ML\] * 2024-11-06: reply from the responsible AD posted \[ML\]\[2\] * 2024-11-06: appeal of WGLC received by IESG \[DT\] IETF process and other documents relevant to this appeal are: * BCP 9 (RFC 2026): “The Internet Standards Process \-- Revision 3” * BCP 25 (RFC 2418): “IETF Working Group Guidelines and Procedures” * RFC 7282: “On Consensus and Humming in the IETF” # Discussion This appeal comes under Section 3.4 of RFC 2418, which for working group specific appeals refers to the process of Section 6.5.1 of RFC 2026\. The appeal appears to be invoking both the (a) and (b) clauses of this section, i.e., respectively, that the appellant’s concerns have not been addressed by the working group, and that the working group has made a choice that places the quality of its output in jeopardy. The record confirms that the appellant has first appealed to the working group as a whole over the general course of the document’s life cycle, then to the Chairs when WGLC completed, and then to the responsible AD. Dissatisfied with the outcome at each phase, the appellant now accordingly seeks resolution from the IESG. The appeal also meets the time and presentation constraints of Section 6.5.4 of RFC 2026\. While not a BCP, RFC 7282 is a consensus document of the IETF, capturing the essence of the IETF’s operating philosophy with respect to how community decisions are made. Importantly, it points out, as a section heading, that “Rough consensus is achieved when all issues are addressed, but not necessarily accommodated.” The record of the LSR working group, i.e., its mailing list archive, contains numerous examples of the appellant expressing the viewpoint that the current document’s content is either confusing, or is not technically sound even if it were to be clarified. Taking these together or even separately, it’s also abundantly clear from the record that, though the working group does not concur with the appellant’s position, it has considered and responded in good faith to that position on several occasions (e.g., threads beginning at \[3\], \[4\], \[5\]). We contend therefore that the issues have been *addressed* in the sense that they were discussed and the working group as a whole decided that neither clarification nor a change in direction was warranted. That the appellant’s preferred remedies to these claimed defects were considered but not adopted by the working group is not sufficient to sustain a claim of the absence of consensus; it is, in fact, plain evidence of the opposite. The appellant also at one point asked why the document is being hurried through the working group, but seven months from adoption to WGLC and then a three month WGLC is hardly evidence of an accelerated process. We note that there is no evidence in the record that the Chairs explicitly measured and declared working group consensus on the issue raised. Rather, they appear to have done this implicitly by completing the WGLC. The appellant claims in his appeal that “only two non-author-experts expressed” support for advancing the document from WGLC. On review, we found three \[6\]\[7\]\[8\]. Though at \[9\] the appellant refers to some of these as “friendship support”, we see no basis upon which to devalue them in determining consensus to proceed. We also note that as a result of this appeal, additional reviews have been conducted (e.g., at \[10\], and a Routing Directorate review at \[11\] resulting in \[12\]) which discuss the raised issue, provide feedback, and do not object to document progress. Discussion was relatively broad. However, these are moot in the context of this appeal as the validity of the WGLC is at issue while these appeared after the WGLC ended. While it is certainly preferable to develop significant explicit support on the list during a WGLC that a document is ready to and should proceed toward publication, RFC 2418, and in particular Sections 3.3 and 6.1, gives working group chairs broad discretion with respect to conducting working group business and determining consensus. We defer to this discretion. In this case, the Chairs have determined that WGLC completed with consensus to proceed, and we believe the record presents a satisfactory basis for this conclusion. Upon receiving the earlier direct appeal, the responsible AD conducted a thorough review of the WGLC, addressed each of the points raised by the appellant, and finally presented a summary of what the WGLC had concluded \[2\]. This review included in-person discussion with some participants about potentially open issues regarding this document. The only disagreement with the AD’s report was from the appellant. In response to this appeal, the IESG conducted its own independent review of the record and there was no deviation between the AD’s summary and its own findings. That review also revealed ample evidence of detailed, substantive, responsive discussion and debate about issues that include those raised by the appellant. # Conclusion The IESG concurs with the analysis presented by the responsible AD posted to the LSR working group’s mailing list on November 6, 2024 \[2\], and thus finds no basis upon which to disturb the current path of the document. There is no evidence of an “unresolved” technical issue and finds that ample grounds exist to support the assertion that working group consensus was properly reached. The IESG notes, however, that the path to publication is not complete and there remain gates through which the document must pass prior to publication, such as IETF Last Call and IESG Evaluation, and these are points at which this and any other post-WGLC feedback will need to be addressed. The appeal is therefore denied. # References RFCs: * RFC 2026: [https://datatracker.ietf.org/doc/html/rfc2026](https://datatracker.ietf.org/doc/html/rfc2026) * RFC 2418: [https://datatracker.ietf.org/doc/html/rfc2418](https://datatracker.ietf.org/doc/html/rfc2418) * RFC 7282: [https://datatracker.ietf.org/doc/html/rfc7282](https://datatracker.ietf.org/doc/html/rfc7282) Other Links: * \[1\] [https://datatracker.ietf.org/group/iesg/appeals/artifact/124](https://datatracker.ietf.org/group/iesg/appeals/artifact/124) * \[2\] [https://mailarchive.ietf.org/arch/msg/lsr/Km0Sre4gyrkEubTndBnzt5NqqqU/](https://mailarchive.ietf.org/arch/msg/lsr/Km0Sre4gyrkEubTndBnzt5NqqqU/) * \[3\] [https://mailarchive.ietf.org/arch/msg/lsr/H1pav2lCwtv8AqTm6b8qIJ-piGY/](https://mailarchive.ietf.org/arch/msg/lsr/H1pav2lCwtv8AqTm6b8qIJ-piGY/) * \[4\] [https://mailarchive.ietf.org/arch/msg/lsr/dgvlgNDei9-kCfawrnQm1JDXUWU/](https://mailarchive.ietf.org/arch/msg/lsr/dgvlgNDei9-kCfawrnQm1JDXUWU/) * \[5\] [https://mailarchive.ietf.org/arch/msg/lsr/5e3-DFVNYPynDLR\_EPEi7FY3T7g/](https://mailarchive.ietf.org/arch/msg/lsr/5e3-DFVNYPynDLR_EPEi7FY3T7g/) * \[6\] [https://mailarchive.ietf.org/arch/msg/lsr/yIlJCemz3TL1ARXL08b0H2N7LLc/](https://mailarchive.ietf.org/arch/msg/lsr/yIlJCemz3TL1ARXL08b0H2N7LLc/) * \[7\] [https://mailarchive.ietf.org/arch/msg/lsr/XkScyjZGPR2cdGhOfMcPul\_z7U8/](https://mailarchive.ietf.org/arch/msg/lsr/XkScyjZGPR2cdGhOfMcPul_z7U8/) * \[8\] [https://mailarchive.ietf.org/arch/msg/lsr/9ixBHgPZ61wTazFU2CoSSBhyu\_I/](https://mailarchive.ietf.org/arch/msg/lsr/9ixBHgPZ61wTazFU2CoSSBhyu_I/) * \[9\] [https://mailarchive.ietf.org/arch/msg/lsr/XLPwjKUUdwny2WhZ7epmBus-mU4/](https://mailarchive.ietf.org/arch/msg/lsr/XLPwjKUUdwny2WhZ7epmBus-mU4/) * \[10\] [https://mailarchive.ietf.org/arch/msg/lsr/t5pcyCnQcshJcKZAMq1Y-Lsaf84/](https://mailarchive.ietf.org/arch/msg/lsr/t5pcyCnQcshJcKZAMq1Y-Lsaf84/) * \[11\] [https://datatracker.ietf.org/doc/review-ietf-lsr-multi-tlv-06-rtgdir-lc-chen-2025-01-13/](https://datatracker.ietf.org/doc/review-ietf-lsr-multi-tlv-06-rtgdir-lc-chen-2025-01-13/) * \[12\] [https://mailarchive.ietf.org/arch/msg/lsr/7tX9eVKlpgv4jIN3qJE44R5b1Ts/](https://mailarchive.ietf.org/arch/msg/lsr/7tX9eVKlpgv4jIN3qJE44R5b1Ts/) Regards, Roman (as IETF Chair, for the IESG) From: Roman Danyliw Sent: Thursday, November 7, 2024 6:21 PM To: Aijun Wang <[email protected]>; [email protected] Cc: [email protected] Subject: RE: Appeal to the IESG re WGLC of draft-ietf-lsr-multi-tlv)(Aijun Wang) Hi Aijun! Acknowledging receipt on behalf of the IESG. Regards, Roman (As IETF Chair for the IESG) From: Aijun Wang <mailto:[email protected]> Sent: Wednesday, November 6, 2024 11:31 AM To: mailto:[email protected] Cc: mailto:[email protected] Subject: Appeal to the IESG re WGLC of draft-ietf-lsr-multi-tlv)(Aijun Wang) Warning: External Sender - do not click links or open attachments unless you recognize the sender and know the content is safe. IESG, As I had promised to the LSR WG, I am contacting you to formally appeal the declaration of WG consensus to progress https://datatracker.ietf.org/doc/draft-ietf-lsr-multi-tlv/ (I am cc'ing the LSR WG for the sake of transparency and openness). • Appellants: Aijun Wang mailto:[email protected] • Description of the Dispute Draft https://datatracker.ietf.org/doc/draft-ietf-lsr-multi-tlv/ is passing its WGLC, although there are obvious technical issues unsolved. I had summarized the still existing issues within the LSR WG list[https://mailarchive.ietf.org/arch/msg/lsr/ZBf0hBj-oeCWxsztAEXzjIxAaMU/]and expected the authors or the WG chairs could response them from technical viewpoints, but there was none, the Chairs just declared that there was already WG consensus. Actually, during the WGLC process, only two non-author-experts expressed explicitly to forward this document. This certainly can’t be called WG consensus. I asked our AD to step in to solve the existing technical issues (https://mailarchive.ietf.org/arch/msg/lsr/PbYIOaF_Jo3lWaOKEn8x8ILxhrA/) and list clearly again the existing issues as the following: ================================= 1) It defines only “what constitutes a key” for two IS-IS TLVs(TLV 22 and TLV 135), there is no such information for other IS-IS TLVs, and also their respective sub-TLVs. 2) The information about “what constitutes a key” is important for any method that segments the packet and concatenate them together. It’s even impossible to assure the interoperability from the implementation of different vendors when the standard is lack of such information. 3) Current MP-TLV proposal illustrates also in its section 8.2 (https://datatracker.ietf.org/doc/html/draft-ietf-lsr-multi-tlv-06#section-8.2) that there are other IS-IS TLVs and their respective sub-TLVs may have value length that exceeds 255 bytes, but the authors of this draft admitted publicly that it is impossible to illustrate all the information about “what constitutes a key” for all these TLVs and sub-TLVs. Based on the above information, we can conclude that MP-TLV proposal is one error prone, full of pitfalls solution. ================================= Our AD responded my request after his laborious review of the overall discussions (https://mailarchive.ietf.org/arch/msg/lsr/Km0Sre4gyrkEubTndBnzt5NqqqU/), quoted some past discussions, but failed to answer the key issues that I raised. I summarized two simple questions regarding to our AD’s responses, and expected he could give some reasonable explanations, but there is no such technical responses. I can only ask the IESG to step in to solve the existing technical issues before forwarding this document, or abandon it if these issues can’t be solved. • Requested Action The WGLC draft(MP-TLV https://datatracker.ietf.org/doc/draft-ietf-lsr-multi-tlv/)is one simple document, here I want the experts within IESG to review it independently, regardless of the past amounts of discussions, and give us some answers for the following questions: 1) Assuming every vendor has their understanding of “what constitutes a key” for the specific IS-IS code point(because current MP-TLV draft doesn’t provide such information), how can we assure that different vendors have exact the same context for “what constitutes a key”? Lack of such explicit information for “what constitutes a key”, how can we concatenate together correctly the segmented packets that may sent by different vendors? 2) If “what constitutes a key” should be defined in the relevant specific RFCs, or revised RFCs(As the author argued, but both are impossible), what’s the value of this draft then?——the general segmentation/concatenate procedures for one large packet is the well known knob, why bother the IETF to describe (not) new one? 3) If there is no reasonable explanation for the above questions, and there are no other way from MP-TLV proposal to bypass these questions, we should stop to approach such direction to solve the problem. We should instead find other general approaches to solve the problems. If the experts in IESG have any questions need me further clarification, please contact me directly. As the person from the operator, we are worrying extremely the chaos that may be arose in the network if MP-TLV proposal can’t provide “what constitutes a key” information explicitly in their document. Wish to get your professional explanations for the above questions. Aijun Wang _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
