From: julien.meu...@orange.com <julien.meu...@orange.com> Sent: 08 September 2022 16:13
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; <tp2> That I-D is an import and so a Normative Reference and one without which the pcep I-D cannot work; this is not just a question of nice to have information but will it work at all which is why, having slept on it, I decided to oppose so that others can see where we are heading! Tom Petch - 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 > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > > _______________________________________________ > Pce mailing list > Pce@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. _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
