Hello Aijun, Thanks for your reply and the changes that I hope will be in -35.
About section 12: up to you whether the authors/WG want to keep simulation and ‘on roadmap’ implementations, for me this does not really fit ‘implementations’. About section 13: adding the URL for IANA registry (as a reference or in-line) makes it super clear, but again, up to the authors/WG Regards -éric From: Aijun Wang <[email protected]> Date: Thursday, 22 August 2024 at 11:43 To: Eric Vyncke (evyncke) <[email protected]>, 'The IESG' <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]> Subject: 答复: Éric Vyncke's No Objection on draft-ietf-pce-pcep-extension-native-ip-34: (with COMMENT) Hi, Eric: Thanks for your careful review and suggestions! I have updated the document according to your suggestions and will upload the document soon to reflect the change. Some detail replies are inline below. Best Regards Aijun Wang China Telecom -----邮件原件----- 发件人: [email protected] [mailto:[email protected]] 代表 【外部账号】éric Vyncke via Datatracker 发送时间: 2024年8月20日 17:05 收件人: The IESG <[email protected]> 抄送: [email protected]; [email protected]; [email protected]; [email protected]; [email protected] 主题: Éric Vyncke's No Objection on draft-ietf-pce-pcep-extension-native-ip-34: (with COMMENT) Éric Vyncke has entered the following ballot position for draft-ietf-pce-pcep-extension-native-ip-34: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Éric Vyncke, INT AD, comments for draft-ietf-pce-pcep-extension-native-ip-34 Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Dhruv Dhody for the shepherd's detailed write-up including the WG consensus and the justification of the intended status. I hope that this review helps to improve the document, Regards, -éric # COMMENTS (non-blocking) ## Abstract s/This document describes/This document defines/ as this is an experimental document ? 【WAJ】Although it is an experimental, we want also keep the definitions and descriptions as normative as possible, because it is the base for the future interoperability. The reason we select it as experimental is just to want to get more experiences from its deployment and toward to the Standard track. To achieve this, the procedures, code points etc. should be first defined and stabilized. ## Section 1 `native IP` could be defined in a couple of words for readers not familiar to RFC 8735. 【WAJ】‘native IP network’ should be one general description that describes the network within which traffic forwarding based solely on IP address, not depend on other field, for example MPLS Label etc. RFC8735 describes mainly the scenarios and simulation results that RFC8821 and this document try to solve. I have add the explanation for "native IP" within the section 3 "Terminology", which is stated as: Native IP network: Refer to the network that forwards traffic based solely on the IP address, instead of other indicator, for example MPLS etc. Should PCE & PCC be expanded on first use even if they are listed in https://www.rfc-editor.org/rpc/wiki/doku.php?id=abbrev_list ? E.g., PCEP is expanded while it is on the list. 【WAJ】PCE has been expanded already when it appeared first within the document, which is in the "Abstract" part. I add the term PCC also within the abstract part, expand it also when its first appeared. Thanks for your suggestions. ## Section 6.4 Please add a reference to `IPinIP tunnel` as there are various encapsulations defined by the IETF. 【WAJ】And reference to RFC 2003 ## Section 7.2 Should the local/peer addresses be qualified as unicast (as opposed to multicast) ? Can those addresses be link-local ? (possibly applicable to other sections) 【WAJ】Thanks for the recommended. Have added the restriction description before the local/peer address. They should not be the link-local, because the BGP peers are usually mult-hop away. ## Section 7.4 Suggest making a specific "For IPv4" similar to the current "For IPv6" as opposed to common fields such as No of Prefixes, ... 【WAJ】Thanks for the suggestions. Have divided the descriptions into three parts: Common Fields/For IPv4/For IPv6. It will be more clearer. ## Section 12 I wonder whether an implementation section referring to implementation in preparation or simulations is really useful. See also RFC 7492. 【WAJ】Section 12.1 and 12.2 describes one simulation implementation, and another preparing implementation. Or we omitted this part totally? ## Section 14 Suggest adding the URI of the various registries to be super clear, e.g., https://www.iana.org/assignments/pcep/pcep.xhtml#pcep-path-setup-types 【WAJ】The normal procedure is just describing the name of code point, will it be onerous to point out every URI of the related registries? The name of the each code point are the exact same as that within the IANA allocation table. # NITS (non-blocking / cosmetic) Sometimes "bytes" is written capitalized as "Bytes" without any reason. 【WAJ】：Have replaced all the "Bytes" with "bytes" within the document. Thanks.
_______________________________________________ Pce mailing list -- [email protected] To unsubscribe send an email to [email protected]
