Return-Path: X-Original-To: spring@mail2.ietf.org Delivered-To: spring@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 5FF099B99A7D; Tue, 16 Dec 2025 19:13:51 -0800 (PST) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -1.697 X-Spam-Level: X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=chinamobile.com Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id toe3C3PxPB3S; Tue, 16 Dec 2025 19:13:49 -0800 (PST) Received: from cmccmta1.chinamobile.com (cmccmta2.chinamobile.com [111.22.67.135]) by mail2.ietf.org (Postfix) with ESMTP id 1B7D69B99A64; Tue, 16 Dec 2025 19:13:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chinamobile.com; s=default; l=0; h=from:subject:message-id:to:mime-version; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; b=Wx2FPZ5sgBSbfle3+Xs7Knofyt+pUlN83aTjf46TRANWuLtdHI27MvsWkIuaBDgTpbU8NldylxfQf RJ7mCARNQZAZo/xEqyPTh6zw4zzs+aLbshEtZ8Pw7PtANFoDl1a98Ua7AwnonRQkqzZIH7mcm8HQ30 jUWDXaEHuvpKMiyU= X-RM-TagInfo: emlType=0 X-RM-SPAM-FLAG: 00000000 Received: from spf.mail.chinamobile.com (unknown[10.188.0.87]) by rmmx-syy-dmz-app03-12003 (RichMail) with SMTP id 2ee369421fe4e21-ef73a; Wed, 17 Dec 2025 11:13:41 +0800 (CST) X-RM-TRANSID: 2ee369421fe4e21-ef73a X-RM-SPAM-FLAG: 00000000 Received: from gongliyan@chinamobile.com ( [10.2.146.60] ) by ajax-webmail-syy-spmd05-11015 (Richmail) with HTTP; Wed, 17 Dec 2025 11:13:39 +0800 (CST) Date: Wed, 17 Dec 2025 11:13:39 +0800 (CST) From: Liyan Gong To: spring , draft-liu-spring-sr- Message-ID: <2b0769420b91a1d-0013a.Richmail.00002012556930008067@chinamobile.com> References: <2b07691d0db1434-00050.Richmail.00005082154910795526@chinamobile.com>, , <2b03691e7ae6193-00001.Richmail.00006062457910195596@chinamobile.com>, <2b03693fc3b42e7-00005.Richmail.00005072955980095576@chinamobile.com>, <2b076941fc82b36-00021.Richmail.00001062055930891546@chinamobile.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_489593_2130674121.1765941219890" X-Priority: 3 X-RM-TRANSID: 2b0769420b91a1d-0013a Encrypt-Channel: web X-RM-OA-ENC-TYPE: 0 X-RM-FontColor: 0 X-CLIENT-INFO: X-TIMING=0&X-MASSSENT=0&X-SENSITIVE=0 X-Mailer: Richmail_Webapp(V2.5.01) Message-ID-Hash: B4WCRA2NRBOTWW25MU5EXJTVZW4UMCMF X-Message-ID-Hash: B4WCRA2NRBOTWW25MU5EXJTVZW4UMCMF X-MailFrom: gongliyan@chinamobile.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-spring.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5Bspring=5D_Re=3A_Follow-up_on_IETF_124Presentationofdraft-liu-sp?= =?utf-8?q?ring-sr-policy-flexible-path-selectionand_draftclarification?= List-Id: "Source Packet Routing in NetworkinG (SPRING)" Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: ------=_Part_489593_2130674121.1765941219890 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi WG and Authors=EF=BC=8C >From my perspective as a network operator utilizing SR for service delivery= , I see the quality-aware path selection framework proposed in this draft a= s a meaningful step forward in operational capabilities. Moving from static= preferences to dynamic, performance-based steering appears to align well w= ith the need for more reliable service-level assurance and efficient bandwi= dth utilization in practice. I would therefore be supportive of advancing t= his work. Best Regards, Liyan ----=E9=82=AE=E4=BB=B6=E5=8E=9F=E6=96=87---- =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9AYisong Liu = =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9AAlvaroRetana = ,spring-chairs ,spring =E6=8A= =84=E3=80=80=E9=80=81: draft-liu-spring-sr-policy-flexible-path-selection = =E5=8F=91=E9= =80=81=E6=97=B6=E9=97=B4=EF=BC=9A2025-12-15 17:10:14 =E4=B8=BB=E9=A2=98=EF= =BC=9ARe:Re:Re: Follow-up on IETF 124 Presentationofdraft-liu-spring-sr-pol= icy-flexible-path-selectionand draft clarification=20 Hi Alvaro and WG, Thank you for your valuable feedback on the previous version of our draft. = We have carefully considered the comments and have just submitted an update= d version (draft-liu-spring-sr-policy-flexible-path-selection-12) to addres= s them. The key technical updates in this revision are as follows: Clarified Reference to Eligibility Concept (section 1): The document now ex= plicitly references and builds upon the eligibility attribute introduced in= the related eligibility draft and also clarifies not simply an expansion o= f the eligibility draft39s use cases.=20 Updated Information Model for Performance Thresholds (section 4.2): We have= defined a structured information model that specifies performance threshol= d parameters (e.g., latency, jitter, bandwidth) for each SR Policy candidat= e path. Detailed Forwarding Quality Measurement (section 4.4): Added specifics on p= erformance measurement methods, including the use of STAMP for metrics like= delay and formulas for calculating available bandwidth. Refined Selection Rules (section 4.5): The rules for the path selection hav= e been refined to mandate its use in excluding paths that fail to meet qual= ity thresholds from active selection. Wait-to-Restore (WTR) Timer Mechanism (section 4.6): Introduced a WTR timer= to prevent flapping by delaying a path39s return to service until its qual= ity stabilizes. With these updates, the document is now more comprehensive and detailed. We= kindly request your continued review and guidance on this version. Your fe= edback is invaluable to us, and we look forward to hearing from you at your= earliest convenience. The updated draft is available at:URL: https://www.ietf.org/archive/id/draf= t-liu-spring-sr-policy-flexible-path-selection-12.txtStatus: https://datatr= acker.ietf.org/doc/draft-liu-spring-sr-policy-flexible-path-selection/HTMLi= zed: https://datatracker.ietf.org/doc/html/draft-liu-spring-sr-policy-flexi= ble-path-selectionDiff: https://author-tools.ietf.org/iddiff?url2=3Ddraft-l= iu-spring-sr-policy-flexible-path-selection-12 Thank you for your time and support. Best Regards,Yisong ----=E9=82=AE=E4=BB=B6=E5=8E=9F=E6=96=87---- =E5=8F=91=E4=BB=B6=E4=BA=BA= =EF=BC=9AYisong Liu =E6=94=B6=E4=BB=B6=E4=BA= =BA=EF=BC=9AAlvaroRetana ,spring-chairs ,spring =E6=8A=84=E3=80=80=E9=80=81: draf= t-liu-spring-sr-policy-flexible-path-selection =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4=EF= =BC=9A2025-11-20 10:20:22 =E4=B8=BB=E9=A2=98=EF=BC=9ARe:Re: Follow-up on IE= TF 124 Presentation ofdraft-liu-spring-sr-policy-flexible-path-selectionand= draft clarification=20 Hi Alvaro, Thank you for your detailed feedback and guidance. This is highly valuable = for improving our draft. I woud like to provide some additional clarificati= on. Our draft, draft-liu-spring-sr-policy-flexible-path-selection, was initiall= y presented at IETF 117 in 2023, predating the eligibility draft. Our work = is not simply an expansion of the eligibility draft39s use cases. From the = beginning, we proposed a mechanism for Candidate Path switching based on fo= rwarding quality thresholds and monitoring results. While this approach ori= ginally modified the active candidate path status, we later incorporated th= e eligibility concept following AD feedback to better align with the SR Pol= icy architecture defined in RFC 9256, as we believe this concept better ref= lects path state definitions. Our focus remains on the CP switching mechanism based on forwarding quality= . We have already submitted related drafts covering BGP and PCEP extensions= for forwarding quality notification, though our current priority is advanc= ing the main spring draft: draft-liu-idr-bgp-sr-policy-cp-threshold draft-liu-pce-sr-policy-cp-threshold draft-liu-idr-bgp-ls-srp-flexible-path-selection Per your suggestions, we will promptly enhance Section 4.3 with detailed ex= planations of path quality measurement methodologies and the revertive proc= edures. Thank you for your suggestions and guidance. Best regards,Yisong ----=E9=82=AE=E4=BB=B6=E5=8E=9F=E6=96=87---- =E5=8F=91=E4=BB=B6=E4=BA=BA=EF= =BC=9AAlvaro Retana =E6=94=B6=E4=BB=B6=E4=BA=BA= =EF=BC=9AYisong Liu ,spring-chairs ,spring =E6=8A=84=E3=80=80=E9=80=81: draft-= liu-spring-sr-policy-flexible-path-selection =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4=EF=BC= =9A2025-11-19 21:36:32 =E4=B8=BB=E9=A2=98=EF=BC=9ARe: Follow-up on IETF 124= Presentation of draft-liu-spring-sr-policy-flexible-path-selectionand draf= t clarification =20 On November 18, 2025 at 8:26:51PM, Yisong Liu wrote: Yisong: Hi! How are you? > Thank you for the valuable feedback following our presentation at=20 > IETF 124. We would like to offer some clarification to ensure our > draft39s purpose is properly understood. > > In our latest revision, we have referenced > draft-karboubi-spring-sr-policy-eligibility, though we wish to > emphasize that the two drafts serve distinctly different purposes.=20 > The eligibility draft introduces new concepts for path qualification, > while our draft focuses specifically on defining a mechanism for path > selection and switching based on forwarding performance metrics such > as latency, jitter, and bandwidth. Our approach predefines quality > requirements for SR policies and enables rapid path selection or > switching when real-time monitoring indicates these requirements are > no longer met. The reference to eligibility is included to maintain > compatibility with the SR Policy architecture defined in RFC 9256. > > We believe there is no significant overlap between our draft and > eligibility draft and see value in advancing them independently.=20 I understand what you39re saying, but I am having a hard time seeing that r= eflected in the document. (1) From =C2=A74: When a candidate path fails to meet forwarding quality requirements, its Eligibility attribute SHOULD be set to false, thereby excluding it from active candidate path selection. This text is effectively the same as what draft-karboubi-spring-sr-policy-eligibility says in =C2=A73.2 (Example 2= : Delay sensitive paths): ...the policy could have a constraint to not use a path when its end-end delay exceeds a given value D1. ... In this case, a system could set the eligibility as false when it detects that path delay exceeds D1 (e.g. using STAMP) rendering path ineligible for selection... The main difference I see is that draft-karboubi-spring-sr-policy-eligibility focuses the example on delay, while your document mentions other possible "threshold parameters" (=C2=A74.1). Your document also includes examples in =C2=A74= .1 and =C2=A75. If I may go further, the document is a more detailed version of the example in =C2=A73.2/draft-karboubi-spring-sr-policy-eligibility. The comments at the meeting in Montreal also mentioned a "high amount of overlap" (even from one of the authors of this document). (2) From above: "our draft focuses specifically on defining a mechanism for= path selection and switching based on forwarding performance metrics". A mechanism is described in =C2=A74.3 (Flexible Candidate Path Selection= =20 Process): 1) The document mentions that a "headend may be informed about the=20 forwarding quality requirements...through various means", and=20 points at BGP and PCEP drafts (=C2=A74). 2) Examples of how the path can be monitored are listed in =C2=A74.3,= =20 but I see no specification...only examples. 3) The Rules for Setting the Eligibility Attribute (=C2=A74.2) are basically the same as what is defined in draft-karboubi-spring-sr-policy-eligibility: if the constraints are met, set the Eligibility to True otherwise, it can be set to False. 4) Finally, "whether to revert to the previous active candidate=20 path can be specified by the configuration" is mentioned as a=20 possibility, but no explicit specification. In summary, if the intent is to define/specify a mechanism, there39s=20 significant work to be done, given that the document only mentions=20 examples at this point. The current content does not justify the=20 Intended Status of putting this document in the Standards Track. =20 > We would appreciate if the chairs can give the guidance on how to > proceed with our draft. Additionally, we have formally requested an > adoption call during our presentation and would be grateful if the > chairs can help to schedule this. In addition to the comments above, the main action item at this time is to = build WG engagement and interest. I only found comments from one other non-= author in the archive (Joel) [1]. We need to see explicit engagement and in= terest [2] before moving forward. Thanks! Alvaro. [1] https://mailarchive.ietf.org/arch/search/?q=3D%22draft-liu-spring-sr-po= licy-flexible-path-selection%22&f_list=3Dspring=20 [2] https://wiki.ietf.org/en/group/spring/WG_Policies=20 =20 =20 ------=_Part_489593_2130674121.1765941219890 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi WG and Authors=EF=BC=8C

From my perspective as a network operat= or utilizing SR for service delivery, I see the quality-aware path selectio= n framework proposed in this draft as a meaningful step forward in operatio= nal capabilities. Moving from static preferences to dynamic, performance-ba= sed steering appears to align well with the need for more reliable service-= level assurance and efficient bandwidth utilization in practice. I would th= erefore be supportive of advancing this work.

Best Regards,

Liy= an


----=E9=82=AE=E4=BB=B6=E5=8E=9F=E6=96=87----

= =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9AYisong Liu  <= ;liuyisong@chinamobile.com>
=E6=94=B6=E4=BB=B6=E4=BA=BA=EF= =BC=9AAlvaroRetana  <aretana.ietf@gmail.com>,sprin= g-chairs  <spring-chairs@ietf.org>,spring  <sp= ring@ietf.org>
=E6=8A=84=E3=80=80=E9=80=81: draft-= liu-spring-sr-policy-flexible-path-selection  <draft-liu-sprin= g-sr-policy-flexible-path-selection@ietf.org>
=E5=8F=91=E9= =80=81=E6=97=B6=E9=97=B4=EF=BC=9A2025-12-15 17:10:14
= =E4=B8=BB=E9=A2=98=EF=BC=9ARe:Re:Re: Follow-up on I= ETF 124 Presentationofdraft-liu-spring-sr-policy-flexible-path-se= lectionand draft clarification

Hi Alvaro and WG,


Thank you for your valuable feedback = on the previous version of our draft. We have carefully considered the comm= ents and have just submitted an updated version (draft-liu-spring-sr-policy= -flexible-path-selection-12) to address them. The key technical updates in = this revision are as follows:

  1. Clarified Reference to El= igibility Concept (section 1): The document now explicitly references and b= uilds upon the eligibility attribute introduced in the related eligibility = draft and also clarifies not simply an expansion of the eligibility dr= aft's use cases. 

  2. Updated Information Model for P= erformance Thresholds (section 4.2): We have defined a structured informati= on model that specifies performance threshold parameters (e.g., latency, ji= tter, bandwidth) for each SR Policy candidate path.

  3. Detail= ed Forwarding Quality Measurement (section 4.4): Added specifics on perform= ance measurement methods, including the use of STAMP for metrics like delay= and formulas for calculating available bandwidth.

  4. Refine= d Selection Rules (section 4.5): The rules for the path selection have been= refined to mandate its use in excluding paths that fail to meet quality th= resholds from active selection.

  5. Wait-to-Restore (WTR) Tim= er Mechanism (section 4.6): Introduced a WTR timer to prevent flapping by d= elaying a path's return to service until its quality stabilizes.=

With t= hese updates, the document is now more comprehensive and detailed. We kindl= y request your continued review and guidance on this version. Your feedback= is invaluable to us, and we look forward to hearing from you at your earli= est convenience.

= The updated draft is available at:
URL: https://www.ietf.org/archive/id/draft-liu-spring-sr-policy-flexible-p= ath-selection-12.txt
Status: https://datatracker.ietf.org/doc/draft-liu-spring= -sr-policy-flexible-path-selection/
HTMLized: https://datatracker.ietf.org/doc= /html/draft-liu-spring-sr-policy-flexible-path-selection
Diff: https://author-= tools.ietf.org/iddiff?url2=3Ddraft-liu-spring-sr-policy-flexible-path-selec= tion-12

Thank you for your time and support.


Best Regards,
Yisong



=
----= =E9=82=AE=E4=BB=B6=E5=8E=9F=E6=96=87----
=E5=8F=91=E4=BB=B6=E4= =BA=BA=EF=BC=9AYisong Liu  <liuyisong@chinamobil= e.com>
=E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9AAlvaroR= etana  <aretana.ietf@gmail.com>,spring-chairs  &l= t;spring-chairs@ietf.org>,spring  <spring@ietf.org>
= =E6=8A=84=E3=80=80=E9=80=81: draft-liu-spring-sr-policy-f= lexible-path-selection  <draft-liu-spring-sr-policy-flexible-p= ath-selection@ietf.org>
=E5=8F=91=E9=80=81=E6=97=B6=E9=97= =B4=EF=BC=9A2025-11-20 10:20:22
=E4=B8=BB=E9=A2=98=EF= =BC=9ARe:Re: Follow-up on IETF 124 Presen= tation ofdraft-liu-spring-sr-policy-flexible-path-selectionand dr= aft clarification

Hi Alvaro,


Thank you for your detailed feedback and guidance. This= is highly valuable for improving our draft. I woud like to provide some ad= ditional clarification.

Our draft, draft-liu-spring-sr-policy-flexible-path-selec= tion, was initially presented at IETF 117 in 2023, predating the eligibilit= y draft. Our work is not simply an expansion of the eligibility draft's= use cases. From the beginning, we proposed a mechanism for Candidate Path = switching based on forwarding quality thresholds and monitoring results. Wh= ile this approach originally modified the active candidate path status, we = later incorporated the eligibility concept following AD feedback to better = align with the SR Policy architecture defined in RFC 9256, as we believe th= is concept better reflects path state definitions.

Our focus remains on the CP sw= itching mechanism based on forwarding quality. We have already submitted re= lated drafts covering BGP and PCEP extensions for forwarding quality notifi= cation, though our current priority is advancing the main spring draft:

=

  • draft-liu-idr-bgp-sr-policy-cp-threshold

  • draft-l= iu-pce-sr-policy-cp-threshold

  • draft-liu-idr-bgp-ls-srp-flexible-path-s= election

Per your suggestions, we will promptly enhance Section 4.3 wit= h detailed explanations of path quality measurement methodologies and the r= evertive procedures.

Thank you for your suggestions and guidance.


Best regards,
Yisong


----=E9=82= =AE=E4=BB=B6=E5=8E=9F=E6=96=87----
=E5=8F=91=E4=BB=B6=E4=BA=BA= =EF=BC=9AAlvaro Retana  <aretana.ietf@gmail.com&= gt;
=E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9AYisong L= iu  <liuyisong@chinamobile.com>,spring-chairs  &l= t;spring-chairs@ietf.org>,spring  <spring@ietf.org>
= =E6=8A=84=E3=80=80=E9=80=81: draft-liu-spring-sr-policy-f= lexible-path-selection  <draft-liu-spring-sr-policy-flexible-p= ath-selection@ietf.org>
=E5=8F=91=E9=80=81=E6=97=B6=E9=97= =B4=EF=BC=9A2025-11-19 21:36:32
=E4=B8=BB=E9=A2=98=EF= =BC=9ARe: Follow-up on IETF 124 Presentat= ion of draft-liu-spring-sr-policy-flexible-path-selectionand = ;draft clarification

     
On November 18, 2025 at 8:26:51PM, Yisong Liu wrote:

Yisong:

<= div id=3D"bloop_customfont" style=3D"margin: 0.0px;">Hi!  How are you?=

> Thank= you for the valuable feedback following our presentation at 
> IETF 124. We would = like to offer some clarification to ensure our
> draft's purpose is properly underst= ood.
>
<= div id=3D"bloop_customfont" style=3D"margin: 0.0px;">> In our latest rev= ision, we have referenced
> draft-karboubi-spring-sr-policy-eligibility, though we wish = to
> emphasiz= e that the two drafts serve distinctly different purposes. 
> The eligibility draft= introduces new concepts for path qualification,
> while our draft focuses specifically = on defining a mechanism for path
> selection and switching based on forwarding performan= ce metrics such
= > as latency, jitter, and bandwidth. Our approach predefines quality
> requirements f= or SR policies and enables rapid path selection or
> switching when real-time monitoring= indicates these requirements are
> no longer met. The reference to eligibility is inc= luded to maintain
>
> We believe there is no = significant overlap between our draft and
> eligibility draft and see value in advancing= them independently. 

I understand what you're saying, but I am having a hard= time seeing that reflected in the document.

(1) From =C2=A74:

      When a candid= ate path fails to meet forwarding quality
      requirements, its Eligibilit= y attribute SHOULD be set to false,
      thereby excluding it from active c= andidate path selection.

   This text is effectively the same as what
<= div id=3D"bloop_customfont" style=3D"margin: 0.0px;">   draft-kar= boubi-spring-sr-policy-eligibility says in =C2=A73.2 (Example 2:
   Delay sensiti= ve paths):

=        ...the policy could have a constraint to not use= a path when its
       end-end delay exceeds a given value D1. ... In = this case, a
&nb= sp;      system could set the eligibility as false when it d= etects that
&nbs= p;      path delay exceeds D1 (e.g. using STAMP) rendering p= ath
   = ;    ineligible for selection...

   The main difference I see is t= hat
   = ;draft-karboubi-spring-sr-policy-eligibility focuses the example on
   delay, whi= le your document mentions other possible "threshold
   parameters" (=C2= =A74.1). Your document also includes examples in =C2=A74.1 and
   =C2=A75. If I m= ay go further, the document is a more detailed version of
   the example in =C2= =A73.2/draft-karboubi-spring-sr-policy-eligibility.

   The comments at the m= eeting in Montreal also mentioned a "high
   amount of overlap" (even f= rom one of the authors of this document).


(2) From above: "our draft focuses= specifically on defining a mechanism for path selection and switching base= d on forwarding performance metrics".

   A mechanism is described in = =C2=A74.3 (Flexible Candidate Path Selection 
   Process):

    1) The documen= t mentions that a "headend may be informed about the 
    forwarding qu= ality requirements...through various means", and 
    points at BGP and= PCEP drafts (=C2=A74).

    2) Examples of how the path can be monitored are= listed in =C2=A74.3, 
    but I see no specification...only examples.
=
    3)= The Rules for Setting the Eligibility Attribute (=C2=A74.2) are
    basically th= e same as what is defined in
    draft-karboubi-spring-sr-policy-eligibility: if = the constraints are
    met, set the Eligibility to True; otherwise, it can be se= t to False.

    4) Finally, "whether to revert to the previous active c= andidate 
&= nbsp;   path can be specified by the configuration" is mentioned = as a 
 = ;   possibility, but no explicit specification.


   In summary, if = the intent is to define/specify a mechanism, there's 
   significant wor= k to be done, given that the document only mentions 
   examples at this poi= nt. The current content does not justify the 
   Intended Status of putting = this document in the Standards Track.

      <= div id=3D"bloop_customfont" style=3D"margin: 0.0px;">> We would apprecia= te if the chairs can give the guidance on how to
> proceed with our draft. Additionally,= we have formally requested an
> adoption call during our presentation and would be grat= eful if the
>= chairs can help to schedule this.

In addition to the comments above, the main action = item at this time is to build WG engagement and interest. I only found comm= ents from one other non-author in the archive (Joel) [1]. We need to see ex= plicit engagement and interest [2] before moving forward.

Thanks!

Alvaro.









 



 




 


------=_Part_489593_2130674121.1765941219890--