Hi Eric, Many thanks for the review. Please see inline with [PC]. I've posted revision -24 of the draft.
Cheers, Pablo. -----Original Message----- From: Éric Vyncke via Datatracker <[email protected]> Sent: jueves, 5 de enero de 2023 12:44 To: The IESG <[email protected]> Cc: [email protected]; [email protected]; [email protected]; Sri Gundavelli (sgundave) <[email protected]>; Sri Gundavelli (sgundave) <[email protected]> Subject: Éric Vyncke's Discuss on draft-ietf-dmm-srv6-mobile-uplane-23: (with DISCUSS and COMMENT) Éric Vyncke has entered the following ballot position for draft-ietf-dmm-srv6-mobile-uplane-23: Discuss 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-dmm-srv6-mobile-uplane/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- # Éric Vyncke, INT AD, comments for draft-ietf-dmm-srv6-mobile-uplane-23 CC @evyncke Thank you for the work put into this document. I always like the use of innovative technologies. Please find below two blocking DISCUSS points (easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Sri Gundavelli for the shepherd's detailed write-up including the very descriptive WG consensus ***but*** the justification of the intended status is plain wrong as it is about the original intended status. I hope that this review helps to improve the document, Regards, -éric ## DISCUSS As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics: ### Intended status The shepherd's write-up is about a standard track intended status, but this document text & meta-data say informal. I know the sad history of the intended status as well as that the IETF Last Call was done a 2nd time for 'informational', but I am afraid that the shepherd's write-up must be updated. ### Section 2.2 What is "gNB" ? (I know the term, but a reference and definition should be given) [PC] Added to terminology list. Unsure how to parse the bullet list as `SRH[n]: A shorter ` appears in the middle of apparently a single list. Or is it two lists ? Then what is the relationship with the 2nd list ? (possibly just a formatting issue). [PC] Clarified sentence, added proper formatting. Thanks. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ## COMMENTS ### Abstract The tone of the abstract looks more like a promotional rather than a factual description. Please consider rewriting it in a more factual way. Also add text about the non-normative nature of this I-D. [PC] done some slight rewording and added extra sentence. Feel free to let me know if this is better. ### Section 1 This section contains the 'instruction' term, which is seems to me more related to network programming (RFC 8986). The following sections are also about network programming. So, let's be clear and refer to both SRH and network programming. [PC] added both references. ### Section 2.1 Please explain what a 'DN' is. [PC] Added DN to the acronym list. Also, usually the terminology section is not only about acronym expansion but also about *explanations* or *descriptions* of the terms. ### Section 3 What is "NFVi" ? [PC] Expand text to NFV infrastructure as it is the only appearance in the document. ### Section 4 About the "a reference architecture" is it the 3GPP architecture (per figure 1) or the architecture defined in this I-D ? I suspect the former, but then let's be clear in the text and in the section title. [PC] Clarified in the text. `The 5G packet core architecture as shown is based on the latest 3GPP standards at the time of writing this draft` I could be wrong and will be happy to stand corrected, but it seems to me that 5G is already deployed, hence the `at the time of writing this draft` is not really relevant. [PC] I removed the text. `A UE gets its IP address from the DHCP block of its UPF.` is this sentence also applicable for IPv6 ? I had in mind (again happy to stand corrected) that for IPv6 a /64 was assigned per UE, i.e., not an "IP address". [PC] You are right. Corrected. :-) ### Section 5 Suggest s/In order to simplify the adoption of SRv6, we present/This document presents/ [PC] Thanks. Suggestion taken. The rest of the section also uses "we", which is not the usual way to write an IETF document. [PC] And not only this section, but several places throughout the document. I've tried to remove all of them. Let me know if I missed any. ### Section 5.1 Please expand "TEID". [PC] Added. What is "QFI" ? [PC] Expanded to QoS Flow Identifier. Explaining how this mechanism is different from plain IPv[4/6] in IPv6 would benefit the reader. ### Section 5.1.1 It seems that `(U2::, U1::2) (Z,A)` describes an encapsulation (IP in IP), but this representation was not explained in section 2.2. [PC] Added to 2.2 `to push an SRH` unsure what is the exact meaning of this wording ? Is it a reference to 'reduced SRH' ? [PC] Added reduced SRH. Nonetheless, the behavior is mentioned in the sentence before, H.Encaps.Red, defined in RFC8986. ### Section 5.2 What are `stationary residential meters` ? Is it about electrical meters ? or any similar meters ? [PC] added "water/energy" to clarify. I don’t know if there's any better word. ``` The gNB MAY resolve the IP address received via the control plane into a SID list using a mechanism like PCEP, DNS-lookup, LISP control-plane or others. The resolution mechanism is out of the scope of this document. ``` Suggest to only use the last sentence and not enumerate the possible mechanisms. [PC] Removed the specific mechanisms. ### Section 5.2.1 I am afraid that I fail to understand what the address B is ? [PC] The gNB uses this address to resolve it into a SID list. Modified wording in draft. What is "PSP" ? (i.e., add it to the terminology section or point to the right reference). [PC] Added reference to 8986. ### Section 5.4 As this is not really about interworking (at least to my definition), I would suggest to use "GTP-U Transport over SRv6" (mainly cosmetic). [PC] I disagree on this one, as the SRv6 packet does not have a GTP-U header. "GTP-U transport over SRv6" implies that GTP-U is carried in SRv6, but this is not the case. ### Section 10 AFAIK about 3GPP, the 3GPP 'packet core' is also a very limited/closed domain. Does it change/help the boundaries of the SRv6 limited domain ? [PC] Indeed, its an interesting note. I added it to the security considerations. ### Appendix A Like Paul Wouters, this section is really about an implementation status section: useful but should probably be removed before publication by the RFC editor. [PC] Added note to RFC Editor to remove it. ## NITS ### Section 3 s/architetural/architectural/ [PC] fixed. ### e.g. s/e.g./e.g.,/ [PC] fixed. ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments [PC] A pity that I just saw this note after finishing answering the email. Many thanks for the review! _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
