Segment Routing over IPv6 for the Mobile User Plane
draft-ietf-dmm-srv6-mobile-uplane-24

The shepherd writeup avoids the question about current or planned implementations, and the simple answer "Yes" to #17 seems to be not as informative as we'd like.

Section 11 is missing the "Change controller" column for all values.  I can't tell why that column is present in the registry, actually, since it wasn't present in RFC 8986 which created it, so it seems like there's something to be cleaned up here with IANA.

#1 I would change the order of the Contributions and Acknowledgements sections - it is sort of customary to say more important things earlier and "contributions" seem of higher importance than "acknowledgements"

#2 Appendix A is really an "Implementation Status" section. Those sections are removed before publication as an RFC, but I see no note to the RFC editor that this section is to be removed. It should be removed for the same reasons the "Implementation Status" section is always removed.

Thank you to Stephen Farrell for the SECDIR review.

** I am puzzled by the characterization of this document in the abstract text and in the Introduction (Section 1) as “specif[ying] the applicability of SRv6 (Segment Routing IPv6) to mobile networks.”  This seems inaccurate. If this document was focused on applicability, I would have expected it to describe _existing_ protocol behavior being applied to the mobile network use case.  However, Section 6 is defining new SR behavior in support of a mobility solution.  

** I also don’t understand the 3GPP coordination described in the shepherd report resulting in this document being moved from PS to Informational status.  Is this new behavior requested by 3GPP?

** Section 3.  Editorial.
   ... on the other-hand, there are new use-cases like distributed
   NFVi that are also challenging network operations.

Is it “NFVi” or NFVI”?  The RFC Editor acronym list (https://www.rfc-editor.org/materials/abbrev.expansion.txt) uses all caps.

** Section 3.
   In the meantime, applications have shifted to use IPv6, and network
   operators have started adopting IPv6 as their IP transport.  

Is there citations that can be provided to substantiate these motivating trends?

** Section 3.
   SRv6 has been
   deployed in dozens of networks
   [I-D.matsushima-spring-srv6-deployment-status].

Is there a non-expired draft that can be referenced?

** Section 3.  Typo. s/architetural/architectural/

** Section 5.2

   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.

Please rephrase this text so that that normative “MAY” does not suggest a list of protocol that are immediately said to be out of scope in the next sentence.

** Section 5.3.  What is a “SR Gateway”?  I can’t find a reference to it in other SPRING documents.  The only text I can find here is that it “maps the GTP-U traffic to SRv6.”  
-- What does that mapping activity entail?  
-- Is the gateway the boundary of the SR domain? Yes?

** Section 8.  If I was an implementer, I would have trouble understanding the purpose of this section.  It appears to be a list of annotated references.  Is their implementation suggested for this mobility use case?

** Section 8
   A mobile network may be required to implement "network slices", which
   logically separate network resources.  User-plane behaviors
   represented as SRv6 segments would be part of a slice.

Are different “network slices” also different SR domains?

Thanks for working on this specification. Thanks also for attending useful discussion throughout the progress of the document, I think informational status probably the right thing to do.

I have some comments, those I think when addressed with improve the document more -

1. Section 4: I see no need to change UE = User equipment to UE = User endpoint.

2. I didn't find scalability as a motivating point in the section 3 in clear text, however, found the enhanced mode to solve the scalability issue later. This happens without educating us about the scalability issue that the mobile network has. I think it would be great if this informational specification also inform about the existing issues regarding scalability the current network architecture has.

3. hmm, how any modes we are really defining here ? we are defining traditional and enhanced mode, and then section 5.4 is also defining another one.. this is confusing. We should clearly say there are three modes in the beginning if we have 3 modes. However, I actually don't think 5.4 defines another mode, rather it is a combined arrangement of traditional and enhanced mode, so it should be call it that way or another mechanism of enhanced inter-working.

Thanks to the authors and to the shepherd for addressing / replying to my previous DISCUSS ballot, https://mailarchive.ietf.org/arch/msg/dmm/X0EQotIqMjVxl3WZRxZomiK6SBY/