[ippm] Re: Joint BMWG/IPPM chartering - implementation polic y
Libin Liu <[email protected]> Sat, 9 May 2026 03:08:01 +0000
| Newsgroups | gmane.ietf.ippm,gmane.ietf.bmwg |
|---|---|
| Message-ID | <TY4PR01MB12668DD1D92FB4E128C3E2937E23A2@TY4PR01MB12668.jpnprd01.prod.outlook.com> |
--===============8065221936851039366== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_TY4PR01MB12668DD1D92FB4E128C3E2937E23A2TY4PR01MB12668jp_" --_000_TY4PR01MB12668DD1D92FB4E128C3E2937E23A2TY4PR01MB12668jp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All, Thank you for raising this question and for summarizing the possible choice= s. I support adding an implementation policy to the charter. I agree that impl= ementation experience is valuable for improving document quality and increa= sing confidence that the specifications can be applied in practice. Among the three proposed choices, I would prefer Option 1: "The WG prioriti= zes documents with implementations." I think this provides the right balanc= e between encouraging running code and avoiding unnecessary barriers to pro= gressing useful work. For BMWG/IPPM documents, especially benchmarking methodologies, metrics, an= d measurement frameworks, implementation experience can take different form= s, such as prototype tools, lab testbeds, measurement scripts, or early dep= loyment experience. These are very useful, but requiring one or two impleme= ntations as a strict condition for every Standards Track document may be to= o restrictive in some cases. As mentioned, it may also slow down documents = that are relatively small updates or address operational/security issues. I think the WG should encourage authors to include an Implementation Status= section, when implementation experience exists. The WG can also consider i= mplementation maturity when deciding whether a document is ready for WGLC. Therefore, I would support charter text along the following lines: "The WG prioritizes documents with implementations. Authors are encouraged = to document implementation status, prototype experience, test results, or d= eployment feedback where applicable, for example using an Implementation St= atus section as described in RFC 7942. The WG will consider such experience= when evaluating document maturity, while allowing exceptions when appropri= ate." Thank you. Best, Libin ________________________________ From: Thomas.Graf-Zc0CTiu5wcBWk0Htik3J/[email protected] <Thomas.Graf-Zc0CTiu5wcBWk0Htik3J/[email protected]> Sent: Thursday, May 7, 2026 4:13 PM To: [email protected] <[email protected]>; [email protected] <[email protected]> Cc: [email protected] <[email protected]>; [email protected] <ippm= [email protected]> Subject: [bmwg] Joint BMWG/IPPM chartering - implementation policy Dear BMWG and IPPM, We have with https://github.com/ietf-ippm/wg-charter/issues/4 a suggestion = from Med to consider adding an implementation policy in the join charter pr= oposal. We chairs have been thinking how this could be addressed best in the charte= r and came up with the 3 proposals: 1. The WG prioritizes documents with implementations. 2. The WG requires an implementation for standard track documents. In so= me cases exceptions can be applied. Whenever such an exception applies, the= exception justification must be included in the specification document or = its write-up. 3. The WG requires two implementations for standard track documents. In = some cases exceptions can be applied. Whenever such an exception applies, t= he exception justification must be included in the specification document o= r its write-up. The main differences between the choices are underlined. We would like to have feedback from both working groups on * wherever an implementation policy should be added or not * wherever those choices make sense or not * which would be the preferred choice and why https://datatracker.ietf.org/doc/html/rfc7942 is a good quick read in regar= ds to implementations and implementation status section. Rough consensus an= d running code is part of the IETF DNA. Personally we think it is helpful f= or the authors if the working group states what is expected in terms of imp= lementations. There are good reasons for having implementations such as rai= sing quality of the document and ensure interoperability. But there are als= o reasons to progress quickly. For instance in case where there is only a s= mall document update or a security fix. Best wishes Marcus, Giuseppe, Sarah and Thomas --_000_TY4PR01MB12668DD1D92FB4E128C3E2937E23A2TY4PR01MB12668jp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <style type=3D"text/css" style=3D"display:none;"> P {margin-top:0;margin-bo= ttom:0;} </style> </head> <body dir=3D"ltr"> <div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo= nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= olor: rgb(0, 0, 0);"> Dear All,</div> <div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo= nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= olor: rgb(0, 0, 0);"> <br> </div> <div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo= nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= olor: rgb(0, 0, 0);"> Thank you for raising this question and for summarizing the possible choice= s. </div> <div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo= nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= olor: rgb(0, 0, 0);"> <br> </div> <div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo= nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= olor: rgb(0, 0, 0);"> I support adding an implementation policy to the charter. I agree that impl= ementation experience is valuable for improving document quality and increa= sing confidence that the specifications can be applied in practice.</div> <div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo= nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= olor: rgb(0, 0, 0);"> <br> </div> <div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo= nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= olor: rgb(0, 0, 0);"> Among the three proposed choices, I would prefer Option 1: "The WG pri= oritizes documents with implementations." I think this provides the ri= ght balance between encouraging running code and avoiding unnecessary barri= ers to progressing useful work.</div> <div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo= nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= olor: rgb(0, 0, 0);"> <br> </div> <div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo= nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= olor: rgb(0, 0, 0);"> For BMWG/IPPM documents, especially benchmarking methodologies, metrics, an= d measurement frameworks, implementation experience can take different form= s, such as prototype tools, lab testbeds, measurement scripts, or early dep= loyment experience. These are very useful, but requiring one or two implementations as a strict condition for= every Standards Track document may be too restrictive in some cases. As me= ntioned, it may also slow down documents that are relatively small updates = or address operational/security issues.</div> <div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo= nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= olor: rgb(0, 0, 0);"> <br> </div> <div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo= nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= olor: rgb(0, 0, 0);"> I think the WG should encourage authors to include an Implementation Status= section, when implementation experience exists. The WG can also consider i= mplementation maturity when deciding whether a document is ready for WGLC.<= /div> <div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo= nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= olor: rgb(0, 0, 0);"> <br> </div> <div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo= nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= olor: rgb(0, 0, 0);"> Therefore, I would support charter text along the following lines:</div> <div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo= nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= olor: rgb(0, 0, 0);"> "The WG prioritizes documents with implementations. Authors are encour= aged to document implementation status, prototype experience, test results,= or deployment feedback where applicable, for example using an Implementati= on Status section as described in RFC 7942. The WG will consider such experience when evaluating document maturi= ty, while allowing exceptions when appropriate."</div> <div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo= nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= olor: rgb(0, 0, 0);"> <br> </div> <div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo= nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= olor: rgb(0, 0, 0);"> Thank you.</div> <div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo= nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= olor: rgb(0, 0, 0);"> <br> </div> <div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo= nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= olor: rgb(0, 0, 0);"> <br> </div> <div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo= nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= olor: rgb(0, 0, 0);"> Best,</div> <div style=3D"font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, = Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> Libin</div> <div id=3D"appendonsend"></div> <hr style=3D"display:inline-block;width:98%" tabindex=3D"-1"> <div id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" st= yle=3D"font-size:11pt" color=3D"#000000"><b>From:</b> Thomas.Graf@swisscom.= com <Thomas.Graf-Zc0CTiu5wcBWk0Htik3J/[email protected]><br> <b>Sent:</b> Thursday, May 7, 2026 4:13 PM<br> <b>To:</b> [email protected] <[email protected]>; [email protected] <bmwg@ietf= .org><br> <b>Cc:</b> [email protected] <[email protected]>; ippm-chairs@i= etf.org <[email protected]><br> <b>Subject:</b> [bmwg] Joint BMWG/IPPM chartering - implementation policy</= font> <div> </div> </div> <style> <!-- @font-face {font-family:Wingdings} @font-face {font-family:"Cambria Math"} @font-face {font-family:Aptos} @font-face {font-family:"Trebuchet MS"} p.x_MsoNormal, li.x_MsoNormal, div.x_MsoNormal {margin:0in; font-size:12.0pt; font-family:"Aptos",sans-serif} a:link, span.x_MsoHyperlink {color:#467886; text-decoration:underline} p.x_MsoListParagraph, li.x_MsoListParagraph, div.x_MsoListParagraph {margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:.5in; font-size:12.0pt; font-family:"Aptos",sans-serif} span.x_EmailStyle17 {font-family:"Trebuchet MS",sans-serif; color:windowtext; font-weight:normal; font-style:normal} .x_MsoChpDefault {} @page WordSection1 {margin:70.85pt 70.85pt 56.7pt 70.85pt} div.x_WordSection1 {} ol {margin-bottom:0in} ul {margin-bottom:0in} --> </style> <div lang=3D"DE-CH" link=3D"#467886" vlink=3D"#96607D" style=3D"word-wrap:b= reak-word"> <div class=3D"x_WordSection1"> <p class=3D"x_MsoNormal"><span style=3D"font-size:10.0pt; font-family:"= ;Trebuchet MS",sans-serif">Dear BMWG and IPPM,</span></p> <p class=3D"x_MsoNormal"><span style=3D"font-size:10.0pt; font-family:"= ;Trebuchet MS",sans-serif"> </span></p> <p class=3D"x_MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt; fo= nt-family:"Trebuchet MS",sans-serif">We have with </span><span style=3D"font-size:10.0pt; font-family:"Trebuchet MS"= ;,sans-serif"><a href=3D"https://github.com/ietf-ippm/wg-charter/issues/4">= <span lang=3D"EN-US">https://github.com/ietf-ippm/wg-charter/issues/4</span= ></a></span><span style=3D"font-size:10.0pt; font-family:"Trebuchet MS= ",sans-serif"> <span lang=3D"EN-US">a suggestion from Med to consider adding an implementa= tion policy in the join charter proposal.</span></span></p> <p class=3D"x_MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt; fo= nt-family:"Trebuchet MS",sans-serif"> </span></p> <p class=3D"x_MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt; fo= nt-family:"Trebuchet MS",sans-serif">We chairs have been thinking= how this could be addressed best in the charter and came up with the 3 pro= posals:</span></p> <p class=3D"x_MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt; fo= nt-family:"Trebuchet MS",sans-serif"> </span></p> <ol start=3D"1" type=3D"1" style=3D"margin-top:0in"> <li class=3D"x_MsoListParagraph" style=3D"margin-left:0in"><span lang=3D"EN= -US" style=3D"font-size:10.0pt; font-family:"Trebuchet MS",sans-s= erif">The WG <u>prioritizes</u> documents with implementations.</span></li><li class=3D"= x_MsoListParagraph" style=3D"margin-left:0in"><span lang=3D"EN-US" style=3D= "font-size:10.0pt; font-family:"Trebuchet MS",sans-serif">The WG <u>requires an</u> implementation for standard track documents. In some cas= es exceptions can be applied. Whenever such an exception applies, the excep= tion justification must be included in the specification document or its wr= ite-up.</span></li><li class=3D"x_MsoListParagraph" style=3D"margin-left:0i= n"><span lang=3D"EN-US" style=3D"font-size:10.0pt; font-family:"Trebuc= het MS",sans-serif">The WG <u>requires two</u> implementations for standard track documents. In some c= ases exceptions can be applied. Whenever such an exception applies, the exc= eption justification must be included in the specification document or its = write-up.</span></li></ol> <p class=3D"x_MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt; fo= nt-family:"Trebuchet MS",sans-serif"> </span></p> <p class=3D"x_MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt; fo= nt-family:"Trebuchet MS",sans-serif">The main differences between= the choices are underlined.</span></p> <p class=3D"x_MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt; fo= nt-family:"Trebuchet MS",sans-serif"> </span></p> <p class=3D"x_MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt; fo= nt-family:"Trebuchet MS",sans-serif">We would like to have feedba= ck from both working groups on</span></p> <p class=3D"x_MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt; fo= nt-family:"Trebuchet MS",sans-serif"> </span></p> <ul type=3D"disc" style=3D"margin-top:0in"> <li class=3D"x_MsoListParagraph" style=3D"margin-left:0in"><span lang=3D"EN= -US" style=3D"font-size:10.0pt; font-family:"Trebuchet MS",sans-s= erif">wherever an implementation policy should be added or not</span></li><= li class=3D"x_MsoListParagraph" style=3D"margin-left:0in"><span lang=3D"EN-= US" style=3D"font-size:10.0pt; font-family:"Trebuchet MS",sans-se= rif">wherever those choices make sense or not</span></li><li class=3D"x_Mso= ListParagraph" style=3D"margin-left:0in"><span lang=3D"EN-US" style=3D"font= -size:10.0pt; font-family:"Trebuchet MS",sans-serif">which would = be the preferred choice and why</span></li></ul> <p class=3D"x_MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt; fo= nt-family:"Trebuchet MS",sans-serif"> </span></p> <p class=3D"x_MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt; fo= nt-family:"Trebuchet MS",sans-serif"><a href=3D"https://datatrack= er.ietf.org/doc/html/rfc7942">https://datatracker.ietf.org/doc/html/rfc7942= </a> is a good quick read in regards to implementations and implementation status section. Rough consensus and running code is par= t of the IETF DNA. Personally we think it is helpful for the authors if the= working group states what is expected in terms of implementations. There a= re good reasons for having implementations such as raising quality of the document and ensure interoperability. But t= here are also reasons to progress quickly. For instance in case where there= is only a small document update or a security fix.</span></p> <p class=3D"x_MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt; fo= nt-family:"Trebuchet MS",sans-serif"> </span></p> <p class=3D"x_MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt; fo= nt-family:"Trebuchet MS",sans-serif">Best wishes</span></p> <p class=3D"x_MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt; fo= nt-family:"Trebuchet MS",sans-serif">Marcus, Giuseppe, Sarah and = Thomas</span><span lang=3D"EN-US" style=3D"font-size:10.0pt; font-family:&q= uot;Trebuchet MS",sans-serif; color:gray"></span></p> <p class=3D"x_MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt; fo= nt-family:"Trebuchet MS",sans-serif"> </span></p> <p class=3D"x_MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt; fo= nt-family:"Trebuchet MS",sans-serif"> </span></p> <p class=3D"x_MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt; fo= nt-family:"Trebuchet MS",sans-serif"> </span></p> <p class=3D"x_MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt; fo= nt-family:"Trebuchet MS",sans-serif"> </span></p> <p class=3D"x_MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt; fo= nt-family:"Trebuchet MS",sans-serif"> </span></p> <p class=3D"x_MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt; fo= nt-family:"Trebuchet MS",sans-serif"> </span></p> <p class=3D"x_MsoNormal"><span lang=3D"EN-US"> </span></p> </div> </div> </body> </html> --_000_TY4PR01MB12668DD1D92FB4E128C3E2937E23A2TY4PR01MB12668jp_-- --===============8065221936851039366== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KaXBwbSBtYWls aW5nIGxpc3QgLS0gaXBwbUBpZXRmLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5kIGFuIGVtYWlsIHRv IGlwcG0tbGVhdmVAaWV0Zi5vcmcK --===============8065221936851039366==--