Ping authors Thanks, --Bruno
Orange Restricted -----Original Message----- From: spring <spring-boun...@ietf.org> On Behalf Of julien.meu...@orange.com Sent: Friday, September 9, 2022 2:10 PM To: spring@ietf.org Cc: p...@ietf.org Subject: [spring] Fwd: Re: [Pce] WG Adoption of draft-li-pce-pcep-srv6-yang-07 Hi Spring WG, An adoption poll is currently running in the PCE WG for an I-D related to SRv6. Some concern has been raised about the status of two Spring documents included as references because they're expired. Could you please share with the PCE WG your plans to progress both spring-sr-policy-yang and spring-srv6-yang? Thank you, Dhruv and Julien, PCE co-chairs -------- Forwarded Message -------- Date: Thu, 8 Sep 2022 17:13:30 +0200 From: julien.meu...@orange.com Hi Tom, Thank you for sharing your views. I agree with your generic point about dependency. This question is very legitimate when requesting publication, especially if there are concerns about the maturity of some references (note however there's no universal rule to address that kind of situation). After a quick scan, here's the situation we're facing for the considered I-D: - SRv6 YANG expired this summer (with a typo in its expiration date) and is referenced for 2 attributes; - SR Policy YANG expired 1 year ago and is referenced for one attribute. Please keep in mind that we aren't running a WG LC, just an adoption poll. In other word, I don't see your point on references as a blocking issue that would really prevent the WG from adopting this topic as a work item and using this I-D as a document base. Cheers, Julien On 08/09/2022 10:14, tom petch wrote: > Thinking some more ... > ________________________________________ > From: Pce <pce-boun...@ietf.org> on behalf of tom petch > <ie...@btconnect.com> > Sent: 07 September 2022 12:32 > > Hi WG, > > This email begins the WG adoption poll for draft-li-pce-pcep-srv6-yang-07. > > https://datatracker.ietf.org/doc/draft-li-pce-pcep-srv6-yang/ > > Should this draft be adopted by the PCE WG? Please state your reasons > - Why / Why not? What needs to be fixed before or after adoption? Are > you willing to work on this draft? Review comments should be posted to > the list. > > <tp2> > Oppose. > It is those expired references. We have I-D that have been sitting in > the RFC Editor queue waiting for their references to catch up for 1108 > days - yes, three years - and in one case, the referenced I-D has > changed so that the first document is no longer valid and will have to > be taken back into the WG to be revised, if anyone is still around who > is familiar with it and willing to work on it. > > With hindsight, such I-D should have been held and not forwarded to > the IESG, or not adopted in the first place. > > Here, I am not familiar with the state of the spring WG and do not > know if and when those expired I-D will progress. A last revision of > April 2021 with an I-D that has plenty that needs fixing does not look > promising. > > Tom Petch > > <tp> > The challenge I see is the SR references, one is RFC9256, the others, > spring-sr-policy-yang and spring-srv6-yang, are expired; not a good > starting point.. > > The 'when' clauses use absolute form of the path which means that the > when is satisfied if there is anything meeting this anywhere in the > tree, not just in this path of the tree; if the latter is wanted, then > the relative form is required > > MSD type could do with a better reference - pce-segment-routing-ipv6 > points to RFC8491 but that only sets up an IANA registry which > contains many more entries so I think the reference has to be to the > IANA registry. > > 'Add NAI' looks like an unresolved issue > > Tom Petch > > Please respond by Monday 19th Sept 2022. > > Please be more vocal during WG polls! > > Thanks! > Dhruv & Julien > > _______________________________________________ > Pce mailing list > p...@ietf.org > https://www.ietf.org/mailman/listinfo/pce _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
