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? Aijun Wang China Telecom > On May 24, 2023, at 17:12, tom petch <ie...@btconnect.com> wrote: > > From: Aijun Wang <wangai...@tsinghua.org.cn> > 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: pce-boun...@ietf.org <pce-boun...@ietf.org> On Behalf Of tom petch > Sent: Monday, May 22, 2023 7:35 PM > To: Dhruv Dhody <d...@dhruvdhody.com>; pce@ietf.org > Cc: pce-chairs <pce-cha...@ietf.org>; > draft-ietf-pce-pcep-extension-native...@ietf.org > Subject: Re: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20 > > > > From: Pce <pce-boun...@ietf.org<mailto:pce-boun...@ietf.org>> on behalf of > Dhruv Dhody <d...@dhruvdhody.com<mailto:d...@dhruvdhody.com>> > > 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 > > Pce@ietf.org<mailto:Pce@ietf.org> > > https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
