Hi Aijun, If you have a need for an early allocation, please send an email to [email protected] and we will follow https://datatracker.ietf.org/doc/html/rfc7120#section-3
But note that as per your Implementation Status [ https://www.ietf.org/archive/id/draft-ietf-pce-pcep-extension-native-ip-21.html#section-12], there are no known implementations though! Thanks! Dhruv On Wed, May 24, 2023 at 9:19 PM Adrian Farrel <[email protected]> wrote: > In the past, I would have agreed with Tom on this. > > But we are routinely seeing a pause of more than 200 days between a WG > issuing a Publication Request and the AD starting their review (which leads > to updates and discussion before IETF last call). IANA don't do their > provisional assignments until IETF last call. > > If there are implementations of what is presumably a stable draft, I think > early assignment is reasonable. It shouldn't take more than 10 minutes of > the chairs' and AD'S time. > > Cheers, > Adrian > > On 24/05/2023 16:33 BST tom petch <[email protected]> wrote: > > > From: Aijun Wang <[email protected]> > Sent: 24 May 2023 16:02 > > As I remember, it is the IANA first allocate the necessary values, then go > to the RFCEditor. > > Can we ask the IANA to (early) allocate the value now? > > <tp> > At this stage in the process, I doubt if it is worth the extra work. Such > a request goes via chairs and AD. I see it more when users want to > implement and it may be some time before the I-D gets to the stage that > this one is now at. And later reviews - Last Call, IESG - may come up with > changes to the TBDnnn that then confuse the picture. I prefer the 'normal' > process but with perhaps a bit more of a nudge to the RFC Editor to make > sure that they pick up all the usages e.g. pointing out to the RFC Editor > up front or in the IANA Considerations that there are many TBDnn in the > body of the I-D. > > Thinking about it, I am a bit hazy on the normal process between IANA and > RFC Editor. The e-mails that I see are when things go wrong and either the > RFC Editor or IANA (or both) are unclear as to what is intended and need > guidance from the WG > > Tom Petch > > Aijun Wang > China Telecom > > > On May 24, 2023, at 17:12, tom petch <[email protected]> wrote: > > From: Aijun Wang <[email protected]> > Sent: 23 May 2023 07:59 > > Hi, Tom: > > Thanks for your review. > > I have uploaded the new version to address your comments. > > I am trying to find some more convenient methods to describe the > un-allocated "TBDnnn" from the IANA. Do you have any suggestions that can't > be "too easy to miss"? > > My purpose is that once the IANA allocates the value to each of these > values according to our requests ( > https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-native-ip-21#section-14) > > > , I can replace them easily in the updated version. > > <tp> > > Mmm I did look at other I-D for another way but think that this is unusual > in the number of TBDnnn in the body of the I-D, not in the IANA > Considerations. I did not see a request for early allocation so the values > will not be assigned until the I-D is about to leave the RFC Editor Queue > so it is the RFC Editor, not you, who has to find all the instances of > TBDnnn and replace them. Common practice is to add a > -- Note to the RFC Editor > in each and every place where such action is needed outside the IANA > Considerations. There are a lot of them; 44 I think. I think that at least > there should be a Note to the RFC Editor in IANA Considerations to the > effect that these values appear in many places and need editing. > > I will post separately a concern about BGP session setup. > > Tom Petch > > > For the interaction between BGP and PCEP, we think the paces or procedures > described in this document can be controlled by the PCE------Once the PCE > sends the command to PCC, it will collect the status of such command. Only > when the previous command is executed successfully, then the next command > can be issued. Section 6 cover the descriptions of main procedures. > > For your other comments, please see replies inline. > > > > Huaimo also gives us more valuable suggestions to refine the document > offline. I have also incorporated them together in the updated version. > > > > Thanks all you together! > > > > Future reviews from other experts can be based on the updated version. > > > > > > Best Regards > > > > Aijun Wang > > China Telecom > > > > -----Original Message----- > From: [email protected] <[email protected]> On Behalf Of tom petch > Sent: Monday, May 22, 2023 7:35 PM > To: Dhruv Dhody <[email protected]>; [email protected] > Cc: pce-chairs <[email protected]>; > [email protected] > Subject: Re: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20 > > > > From: Pce <[email protected]<mailto:[email protected]>> on behalf > of Dhruv Dhody <[email protected]<mailto:[email protected]>> > > Sent: 16 May 2023 23:15 > > > > This email starts a 2-weeks working group last call for > draft-ietf-pce-pcep-extension-native-ip-20 [1]. > > > > <tp> > > I had a look and decided that it is mostly beyond me - I am not up to > speed with all the 15 Normative References, in particular with RFC8821. I > would prefer that this I-D provided a better bridge to the material in > RFC8821. > > > > I note that RFC8821 is an as yet unapproved downref which reinforces that > view. > > > > I note too that the Abstract references this and 8735 as anchors which > Abstracts must not do. > > [WAJ] Remove the anchors in the abstract. > > > > The I-D uses the word 'draft' in many places. These must be changed. > > [WAJ] Changed the "draft" to "document" within the entire document. > > > > The I-D has a large number of TBDnnn with no note requesting that they are > replaced; I find these easy to miss. > > [WAJ] Do you have any suggestions that can't be "easy to miss"? > > > > p.9 2) > > seems to end mid-sentence. > > [WAJ] Updated > > > > The English is not quite in several places and could be confusing. Thus > p.5 "Further only one > > of BPI, EPR, or PPA object MUST be present. " > > I can interpret in two ways although subsequent text makes one the > preferred one. > > [WAJ] Change the phrase to "Further only one and one kind of BPI,EPR, or > PPA object MUST be present", is it better? > > > > I suspect that there are many potential interactions with BGP, especially > when things are not going quite right, and that the I-D does not cover them > all. The language used is not that of BGP (e.g. Established, speaker). The > timing too of BGP can be quite slow, in setup and in shutdown and I wonder > how a PCC copes with that. > > [WAJ] Once the PCC receives the PCInitiate message that include BPI (BGP > Peer Info) object, it will try to build the BGP session between the peers > that indicates in the BPI object. Only when it establishes the BGP session > successfully, it will report the PCE via the PCRpt message(as that > described in section > https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-native-ip-21#section-6.1). > Then the PCE can send other instruction to the PCCs. Actually, the > procedures described in this document is asynchronous. > > > > > > As I say, largely beyond me but the English needs some attention; using > the terminology of BGP would help. > > > > Tom Petch > > > > > > Please indicate your support or concern for this draft. If you are opposed > to the progression of the draft to RFC, please articulate your concern. If > you support it, please indicate that you have read the latest version and > it is ready for publication in your opinion. As always, review comments and > nits are most welcome. > > > > The WG LC will end on Wednesday 31st May 2023. We will also notify the IDR > WG about this WGLC. > > > > A general reminder to the WG to be more vocal during the > last-call/adoption and help us unclog our queues :) > > > > Thanks, > > Dhruv & Julien > > > > [1] > https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/ > > > > _______________________________________________ > > Pce mailing list > > [email protected]<mailto:[email protected]> > > https://www.ietf.org/mailman/listinfo/pce > > > _______________________________________________ > Pce mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/pce > >
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
