Hi, Roman: Thanks for your responses. But, it is only repeat of previous procedures analysis from our AD, not my expected independent technical analysis/responses, even I illustrated my technical arguments for your references:
> 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. As you said, there will be IESG evaluation to gate its publish, then I will wait for their technical analysis and participate in the discussions if possible. Aijun Wang China Telecom > On Jan 25, 2025, at 01:20, Roman Danyliw <[email protected]> wrote: > > (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] _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
