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

[Ballot comment]
I appreciate the work that has gone into this document.  And the discussions about the impact (or lack thereof) on the 3GPP architecture.

However, I believe this document shouldn't be published in the IETF stream, regardless of its status.  I mainly considered the proposed applicability (for example, "GTP-U protocol [TS.29281] is replaced by SRv6") and the fact that it "is not related to any current technical work" in 3GPP [1].

I am then ABSTAINing and not standing in the way of publication.

[1] https://mailarchive.ietf.org/arch/msg/3gpp-ietf-coord/XV5GRtdJLLyqpuJr1unw03sf1-A/

[Ballot 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)

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).

[Ballot 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.

### 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.

### Section 2.1

Please explain what a 'DN' is.

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" ?

### 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.

`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.

`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".

### Section 5

Suggest s/In order to simplify the adoption of SRv6, we present/This document presents/

The rest of the section also uses "we", which is not the usual way to write an IETF document.

### Section 5.1

Please expand "TEID".

What is "QFI" ?

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.

`to push an SRH` unsure what is the exact meaning of this wording ? Is it a reference to 'reduced SRH' ?

### Section 5.2

What are `stationary residential meters` ? Is it about electrical meters ? or any similar meters ?

```
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.

### Section 5.2.1

I am afraid that I fail to understand what the address B is ?

What is "PSP" ? (i.e., add it to the terminology section or point to the right reference).

### 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).

### 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 ?

### 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.

## NITS

### Section 3
s/architetural/architectural/

### e.g.
s/e.g./e.g.,/

## 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

[Ballot comment]
#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.

[Ballot comment]
#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". 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.

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-dmm-srv6-mobile-uplane-23. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the SRv6 Endpoint Behaviors registry on the Segment Routing web page located at:

https://www.iana.org/assignments/segment-routing/

the following early registrations will be made permanent and their references changed to [ RFC-to-be ]:

Value Hex Endpoint behavior
40 0x0028 End.MAP
41 0x0029 End.Limit
69 0x0045 End.M.GTP6.D
70 0x0046 End.M.GTP6.Di
71 0x0047 End.M.GTP6.E
72 0x0048 End.M.GTP4.E

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Specialist

The following Last Call announcement was sent out (ends 2022-12-28):

From: The IESG
To: IETF-Announce
CC: dmm-chairs@ietf.org, dmm@ietf.org, draft-ietf-dmm-srv6-mobile-uplane@ietf.org, ek.ietf@gmail.com, sgundave@cisco.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Segment Routing IPv6 for Mobile User Plane) to Proposed Standard


The IESG has received a request from the Distributed Mobility Management WG
(dmm) to consider the following document: - 'Segment Routing IPv6 for Mobile
User Plane'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2022-12-28. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document specifies the applicability of SRv6 (Segment Routing
  IPv6) to the user-plane of mobile networks.  The network programming
  nature of SRv6 accomplishes mobile user-plane functions in a simple
  manner.  The statelessness of SRv6 and its ability to control both
  service layer path and underlying transport can be beneficial to the
  mobile user-plane, providing flexibility, end-to-end network slicing,
  and SLA control for various applications.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dmm-srv6-mobile-uplane/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/3891/
  https://datatracker.ietf.org/ipr/3979/
  https://datatracker.ietf.org/ipr/3950/

--
Date: 8th Dec, 2022

Based on the feedback resulting from IETF Last Call, feedback from 3GPP-IETF Coordination team, 3GPP CT Chair and few others, we have decided to move this document (SRv6 for Mobile User Plane - draft-ietf-dmm-srv6-mobile-uplane) on informational track. This document is currently on track to become a Proposed Standard. Meaning, with this change, this document upon IESG approval will be published as an Informational RFC.

The Int Area Director (Erik Kline), ex-Int Area director (Suresh Krishnan) and the lead document authors (Satoru, Miya, Pablo, & Daniel) and WG chair (myself) have met few times and have agreed to implement this change.


Sri Gundavelli
---

Document Shepherd writeup for:

  Title:    Segment Routing IPv6 for Mobile User Plane
  Author:  Satoru Matsushima (editor), Clarence Filsfils, Miya Kohno, Pablo Camarillo Garvia (editor), Daniel Voyer, Charles E. Perkins
  Filename: draft-ietf-dmm-srv6-mobile-uplane

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this the
proper type of RFC? Is this type of RFC indicated in the title page
header?

Standards Track, Proposed Standard
 
The use of SRv6 for enabling mobile user plane requires support from multiple network elements and with a very prescriptive behavior. This is essential for realizing a multi-vendor eco-system and interoperability. Publishing this behavior in a standards-track document will help realize that larger goal.  We therefore believe “Standards Track” is the correct status for this document.

 

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

Relevant content can frequently be found in the abstract and/or
introduction of the document. If not, this may be an indication that
there are deficiencies in the abstract or introduction.

  This document specifies the applicability of SRv6 (Segment Routing
  IPv6) to the user-plane of mobile networks.  The network programming
  nature of SRv6 accomplishes mobile user-plane functions in a simple
  manner.  The statelessness of SRv6 and its ability to control both
  service layer path and underlying transport can be beneficial to the
  mobile user-plane, providing flexibility, end-to-end network slicing,
  and SLA control for various applications.
 

Working Group Summary:

Was there anything in WG process that is worth noting? For example, was
there controversy about particular points or were there decisions where
the consensus was particularly rough?


There have been two WGLCs on this document. The first WGLC was issued in April of 2021. The working group feedback from the first WGLC has identified few technical issues which the authors have addressed over the next 11 months. Subsequently, there was a second WGLC which was issued in April of 2022.

There have been few objections raised during the first WGLC, primarily the concern that the document attempts to redefine 3GPP standard in an IETF document and which is not acceptable. The authors have worked with the reviewers and additionally based on the WG chair feedback have updated the document. Most of the sections are now marked as informative sections. The feedback from the second WGLC did not reflect any such major concerns, except from one WG member who still has concerns on the scope. Other than this one opposing view, there is considerable support from the WG for this work. Based on the feedback received from the first and second last calls, we believe there is rough consensus to move the document forward. 

With regards to the scope of the efforts, we the chairs believe the document does not redefine any particular SDO standard. It is not updating what is specified in 3GPP TS 23.501 or for that matter any other specifications. The focus of the document is about the use of IETF protocols for realizing a specific behavior without modifying the SDO standards. It is about application and the use of an open IETF standard protocol in a forwarding environment. No part of this specification redefines any of the SDO interfaces. 3GPP specified N3 and N9 interfaces or all other interfaces continue to remain the same. An implementation is not required to implement any part of this specification for it to be compliant to the SDO defined standards.





Document Quality:

Are there existing implementations of the protocol? Have a significant
number of vendors indicated their plan to implement the specification?
Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If there was a
MIB Doctor, YANG Doctor, Media Type or other expert review, what was its
course (briefly)? In the case of a Media Type review, on what date was
the request posted?

This document had high visibility and it went through a thorough review process. The quality of the document is very good. It is technically accurate and a well written document.


Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?


  Sri Gundavelli is Document Shepherd.
  Erik Kline is Responsible Area Director.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the
IESG.


I as a Document Shepard and WG co-chair, have reviewed this document.

I believe this document is ready for publication and therefore we are moving this for IESG reviews.



(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that took
place.

No.


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the IESG
should be aware of? For example, perhaps he or she is uncomfortable with
certain parts of the document, or has concerns whether there really is a
need for it. In any event, if the WG has discussed those issues and has
indicated that it still wishes to advance the document, detail those
concerns here.


This document went through a thorough review process. I have no concerns moving this document forward.



(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why?

Yes. 


(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.


https://datatracker.ietf.org/ipr/search/?draft=draft-ietf-dmm-srv6-mobile-uplane&submit=draft&rfc=&doctitle=&group=&holder=&iprtitle=&patent=

WG was made aware of the IPR declarations. There were no discussions or objections.



(9) How solid is the WG consensus behind this document? Does it represent
the strong concurrence of a few individuals, with others being silent, or
does the WG as a whole understand and agree with it?

There is strong consensus for advancing this work. The fact that the document went through multiple WGLC is a good indication on the level of working group engagement. People have been quite vocal on this topic.



(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

There is one reviewer who has concerns moving this document forward. The person did not state if he is going to go for an appeal. He did say that he will raise his concerns during IETF LC.
 


(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.


No ID nits errors are seen. Following is the Id nits summary:

Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--).


(12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Not Applicable


(13) Have all references within this document been identified as either
normative or informative?

Yes.


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

All normative references are published RFC and external documents.


(15) Are there downward normative references references (see RFC 3967)? If so,
list these downward references to support the Area Director in the Last Call
procedure.

No.

(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs is
discussed. If this information is not in the document, explain why the WG
considers it unnecessary.


No

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA
registries. Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a detailed
specification of the initial contents for the registry, that allocations
procedures for future registrations are defined, and a reasonable name
for the new registry has been suggested (see RFC 8126).

Yes.



(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.

None.


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, YANG modules,
etc.

Not applicable



(20) If the document contains a YANG module, has the module been checked
with any of the recommended validation tools
(https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and
formatting validation? If there are any resulting errors or warnings,
what is the justification for not fixing them at this time? Does the YANG
module comply with the Network Management Datastore Architecture (NMDA)
as specified in RFC8342?

Not Applicable

--
Date: 8th Dec, 2022

Based on the feedback resulting from IETF Last Call, 3GPP-IETF Coordination team, 3GPP CT Chair and few others, we have decided to move this document (SRv6 for Mobile User Plane - draft-ietf-dmm-srv6-mobile-uplane) on informational track. This document is currently on track to become a Proposed Standard. Meaning, with this change, this document upon IESG approval will be published as an Informational RFC.

The Int Area Director (Erik Kline), ex-Int Area director (Suresh Krishnan) and the lead document authors (Satoru, Miya, Pablo, & Daniel) and WG chair (myself) have met few times and have agreed to implement this change.


Sri Gundavelli
---

Document Shepherd writeup for:

  Title:    Segment Routing IPv6 for Mobile User Plane
  Author:  Satoru Matsushima (editor), Clarence Filsfils, Miya Kohno, Pablo Camarillo Garvia (editor), Daniel Voyer, Charles E. Perkins
  Filename: draft-ietf-dmm-srv6-mobile-uplane

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this the
proper type of RFC? Is this type of RFC indicated in the title page
header?

Standards Track, Proposed Standard
 
The use of SRv6 for enabling mobile user plane requires support from multiple network elements and with a very prescriptive behavior. This is essential for realizing a multi-vendor eco-system and interoperability. Publishing this behavior in a standards-track document will help realize that larger goal.  We therefore believe “Standards Track” is the correct status for this document.

 

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

Relevant content can frequently be found in the abstract and/or
introduction of the document. If not, this may be an indication that
there are deficiencies in the abstract or introduction.

  This document specifies the applicability of SRv6 (Segment Routing
  IPv6) to the user-plane of mobile networks.  The network programming
  nature of SRv6 accomplishes mobile user-plane functions in a simple
  manner.  The statelessness of SRv6 and its ability to control both
  service layer path and underlying transport can be beneficial to the
  mobile user-plane, providing flexibility, end-to-end network slicing,
  and SLA control for various applications.
 

Working Group Summary:

Was there anything in WG process that is worth noting? For example, was
there controversy about particular points or were there decisions where
the consensus was particularly rough?


There have been two WGLCs on this document. The first WGLC was issued in April of 2021. The working group feedback from the first WGLC has identified few technical issues which the authors have addressed over the next 11 months. Subsequently, there was a second WGLC which was issued in April of 2022.

There have been few objections raised during the first WGLC, primarily the concern that the document attempts to redefine 3GPP standard in an IETF document and which is not acceptable. The authors have worked with the reviewers and additionally based on the WG chair feedback have updated the document. Most of the sections are now marked as informative sections. The feedback from the second WGLC did not reflect any such major concerns, except from one WG member who still has concerns on the scope. Other than this one opposing view, there is considerable support from the WG for this work. Based on the feedback received from the first and second last calls, we believe there is rough consensus to move the document forward. 

With regards to the scope of the efforts, we the chairs believe the document does not redefine any particular SDO standard. It is not updating what is specified in 3GPP TS 23.501 or for that matter any other specifications. The focus of the document is about the use of IETF protocols for realizing a specific behavior without modifying the SDO standards. It is about application and the use of an open IETF standard protocol in a forwarding environment. No part of this specification redefines any of the SDO interfaces. 3GPP specified N3 and N9 interfaces or all other interfaces continue to remain the same. An implementation is not required to implement any part of this specification for it to be compliant to the SDO defined standards.





Document Quality:

Are there existing implementations of the protocol? Have a significant
number of vendors indicated their plan to implement the specification?
Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If there was a
MIB Doctor, YANG Doctor, Media Type or other expert review, what was its
course (briefly)? In the case of a Media Type review, on what date was
the request posted?

This document had high visibility and it went through a thorough review process. The quality of the document is very good. It is technically accurate and a well written document.


Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?


  Sri Gundavelli is Document Shepherd.
  Erik Kline is Responsible Area Director.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the
IESG.


I as a Document Shepard and WG co-chair, have reviewed this document.

I believe this document is ready for publication and therefore we are moving this for IESG reviews.



(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that took
place.

No.


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the IESG
should be aware of? For example, perhaps he or she is uncomfortable with
certain parts of the document, or has concerns whether there really is a
need for it. In any event, if the WG has discussed those issues and has
indicated that it still wishes to advance the document, detail those
concerns here.


This document went through a thorough review process. I have no concerns moving this document forward.



(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why?

Yes. 


(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.


https://datatracker.ietf.org/ipr/search/?draft=draft-ietf-dmm-srv6-mobile-uplane&submit=draft&rfc=&doctitle=&group=&holder=&iprtitle=&patent=

WG was made aware of the IPR declarations. There were no discussions or objections.



(9) How solid is the WG consensus behind this document? Does it represent
the strong concurrence of a few individuals, with others being silent, or
does the WG as a whole understand and agree with it?

There is strong consensus for advancing this work. The fact that the document went through multiple WGLC is a good indication on the level of working group engagement. People have been quite vocal on this topic.



(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

There is one reviewer who has concerns moving this document forward. The person did not state if he is going to go for an appeal. He did say that he will raise his concerns during IETF LC.
 


(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.


No ID nits errors are seen. Following is the Id nits summary:

Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--).


(12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Not Applicable


(13) Have all references within this document been identified as either
normative or informative?

Yes.


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

All normative references are published RFC and external documents.


(15) Are there downward normative references references (see RFC 3967)? If so,
list these downward references to support the Area Director in the Last Call
procedure.

No.

(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs is
discussed. If this information is not in the document, explain why the WG
considers it unnecessary.


No

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA
registries. Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a detailed
specification of the initial contents for the registry, that allocations
procedures for future registrations are defined, and a reasonable name
for the new registry has been suggested (see RFC 8126).

Yes.



(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.

None.


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, YANG modules,
etc.

Not applicable



(20) If the document contains a YANG module, has the module been checked
with any of the recommended validation tools
(https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and
formatting validation? If there are any resulting errors or warnings,
what is the justification for not fixing them at this time? Does the YANG
module comply with the Network Management Datastore Architecture (NMDA)
as specified in RFC8342?

Not Applicable

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-dmm-srv6-mobile-uplane-22. If any part of this review is inaccurate, please let us know.

We understand that, upon approval of this document, there is a single action which we must complete.

In the SRv6 Endpoint Behaviors registry under the Segment Routing registry group located at:

https://www.iana.org/assignments/segment-routing

the existing registrations for:

40 0x0028 End.MAP
41 0x0029 End.Limit
69 0x0045 End.M.GTP6.D
70 0x0046 End.M.GTP6.Di
71 0x0047 End.M.GTP6.E
72 0x0048 End.M.GTP4.E

will have their references changed to [ RFC-to-be ].

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Specialist

The following Last Call announcement was sent out (ends 2022-11-23):

From: The IESG
To: IETF-Announce
CC: dmm-chairs@ietf.org, dmm@ietf.org, draft-ietf-dmm-srv6-mobile-uplane@ietf.org, ek.ietf@gmail.com, sgundave@cisco.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Segment Routing IPv6 for Mobile User Plane) to Proposed Standard


The IESG has received a request from the Distributed Mobility Management WG
(dmm) to consider the following document: - 'Segment Routing IPv6 for Mobile
User Plane'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2022-11-23. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document specifies the applicability of SRv6 (Segment Routing
  IPv6) to the user-plane of mobile networks.  The network programming
  nature of SRv6 accomplishes mobile user-plane functions in a simple
  manner.  The statelessness of SRv6 and its ability to control both
  service layer path and underlying transport can be beneficial to the
  mobile user-plane, providing flexibility, end-to-end network slicing,
  and SLA control for various applications.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dmm-srv6-mobile-uplane/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/3891/
  https://datatracker.ietf.org/ipr/3979/
  https://datatracker.ietf.org/ipr/3950/

# Internet AD comments for draft-ietf-dmm-srv6-mobile-uplane-21
CC @ekline

* Thank you for the shepherd write-up; I was glad to see the rounds of
  discussion and issues summarized.

* Owing to my considerable slowness I-D nits reports that some of the drafts
  referenced have either newer version numbers or have been published.

  (my fault for the delay)

* I'll observe that I think I saw an implementation be advertised by a vendor
  at the FYUZ event in Madrid (2022.10.25-27).

## Comments

### S2

* This should be updated to use the RFC 8174 language (don't forget to update
  the normative dependencies).

### S2.2

* "SRH[SL] can be different from the DA of the IPv6 header."

  If this can only happen when a Reduced SRH is used, perhaps just note
  that parenthetically.  If there are other cases where this can happen
  what are they?

### S5.2

* This mention of "Args.Mob.Session" should probably have a forward reference
  to S6.1, since I can't recall it having been mentioned prior to this (like
  what's done in 5.2.2).

### S5.2.2

* Should this End.DT2 actually be End.DT2U (as used in S5.2.1)?

### S5.3.1.2

* This trick where the SRGW is end of the SR domain but there are still
  remaining segments feels like it might abuse some SRH text somewhere, but
  I can't find it.  Perhaps someone during Last Call will find -- or not --
  anything relevant.

  I guess it's just a kind of PSP.

### S6.2

* It is noted that the SIDs in the SRH are not modified.  I assume that the
  SL value is also not modified?  I.e. this is just some form of "SID NAT".

### S6.3

* "S3 in the example"

  Could possibly append "and S08 in the steps above" or something, if I
  understand correctly.

### S6.7

* This appears to be first use of "IW-IPv4-Prefix"?  Perhaps add it to a
  table up at the top of draft or explain "IW" here.

* In S05, "Ref1" wants to be ... Figure 11, I guess?

### S10

* I think this could be worded a bit better to say why no more needs to be
  said.  My poor attempt to get at this follows:

  OLD

  This document introduces new SRv6 Endpoint Behaviors.  Those
  behaviors do not need any special security consideration given that
  it is deployed within that SR Domain

  NEW

  This document introduces new SRv6 Endpoint Behaviors.  Those
  behaviors operate on control plane information, including information
  within the received SRH payload on which the behaviors operate.  Altering
  the behaviors requires that an attacker alter the SR domain control plane,
  including possibly altering SRv6 packets in flight through the SR domain.
  At this point, the entire trust model of the domain (8402 S8.2) will have
  been violated.

  ... or something?

## Nits

### S2.1

* "Context of a UE connects to a mobile network" ->
  "Context of a UE connected to a mobile network", perhaps

* I'm sure it's well-known to 3GPP folks, but I can never keep track of
  which direction is "up" and which is "down" in every other networking
  context.

  Perhaps mention that "uplink" is from the UE and "downlink" it towards it.

### S4

* "also work in such case" ->

  "also work in this case" or "also work in such a case", perhaps

### S5

* "defines his own operational model" ->
  "defines their own operational model", is probably better

### S5.2.3

* "The Enhanced Mode improves since" ->
  "The Enhanced Mode improves scalability since", or if not "scalability"
  then substitute another noun for a thing that is improved.

### S5.3.1.2

* "looks for ... and forward it on the bearer" ->
  "looks for ... and forwards it on the bearer"

### S6.4

* "IPv6 DA of GTP packet" ->
  "IPv6 DA of the GTP packet", perhaps

* "Preprend" -> "Prepend"

* "instantiated at the SR gateway" ->
  "instantiated at the final SR gateway", or
  "instantiated at the ultimate SR gateway", or
  "instantiated at the egres SR gateway",

  or something maybe (there are multiple SR gateways in the example
  architecture, but I assume this refers to SRGW-B).

Document Shepherd writeup for:

  Title:    Segment Routing IPv6 for Mobile User Plane
  Author:  Satoru Matsushima (editor), Clarence Filsfils, Miya Kohno, Pablo Camarillo Garvia (editor), Daniel Voyer, Charles E. Perkins
  Filename: draft-ietf-dmm-srv6-mobile-uplane

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this the
proper type of RFC? Is this type of RFC indicated in the title page
header?

Standards Track, Proposed Standard
 
The use of SRv6 for enabling mobile user plane requires support from multiple network elements and with a very prescriptive behavior. This is essential for realizing a multi-vendor eco-system and interoperability. Publishing this behavior in a standards-track document will help realize that larger goal.  We therefore believe “Standards Track” is the correct status for this document.

 

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

Relevant content can frequently be found in the abstract and/or
introduction of the document. If not, this may be an indication that
there are deficiencies in the abstract or introduction.

  This document specifies the applicability of SRv6 (Segment Routing
  IPv6) to the user-plane of mobile networks.  The network programming
  nature of SRv6 accomplishes mobile user-plane functions in a simple
  manner.  The statelessness of SRv6 and its ability to control both
  service layer path and underlying transport can be beneficial to the
  mobile user-plane, providing flexibility, end-to-end network slicing,
  and SLA control for various applications.
 

Working Group Summary:

Was there anything in WG process that is worth noting? For example, was
there controversy about particular points or were there decisions where
the consensus was particularly rough?


There have been two WGLCs on this document. The first WGLC was issued in April of 2021. The working group feedback from the first WGLC has identified few technical issues which the authors have addressed over the next 11 months. Subsequently, there was a second WGLC which was issued in April of 2022.

There have been few objections raised during the first WGLC, primarily the concern that the document attempts to redefine 3GPP standard in an IETF document and which is not acceptable. The authors have worked with the reviewers and additionally based on the WG chair feedback have updated the document. Most of the sections are now marked as informative sections. The feedback from the second WGLC did not reflect any such major concerns, except from one WG member who still has concerns on the scope. Other than this one opposing view, there is considerable support from the WG for this work. Based on the feedback received from the first and second last calls, we believe there is rough consensus to move the document forward. 

With regards to the scope of the efforts, we the chairs believe the document does not redefine any particular SDO standard. It is not updating what is specified in 3GPP TS 23.501 or for that matter any other specifications. The focus of the document is about the use of IETF protocols for realizing a specific behavior without modifying the SDO standards. It is about application and the use of an open IETF standard protocol in a forwarding environment. No part of this specification redefines any of the SDO interfaces. 3GPP specified N3 and N9 interfaces or all other interfaces continue to remain the same. An implementation is not required to implement any part of this specification for it to be compliant to the SDO defined standards.





Document Quality:

Are there existing implementations of the protocol? Have a significant
number of vendors indicated their plan to implement the specification?
Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If there was a
MIB Doctor, YANG Doctor, Media Type or other expert review, what was its
course (briefly)? In the case of a Media Type review, on what date was
the request posted?

This document had high visibility and it went through a thorough review process. The quality of the document is very good. It is technically accurate and a well written document.


Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?


  Sri Gundavelli is Document Shepherd.
  Erik Kline is Responsible Area Director.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the
IESG.


I as a Document Shepard and WG co-chair, have reviewed this document.

I believe this document is ready for publication and therefore we are moving this for IESG reviews.



(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that took
place.

No.


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the IESG
should be aware of? For example, perhaps he or she is uncomfortable with
certain parts of the document, or has concerns whether there really is a
need for it. In any event, if the WG has discussed those issues and has
indicated that it still wishes to advance the document, detail those
concerns here.


This document went through a thorough review process. I have no concerns moving this document forward.



(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why?

Yes. 


(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.


https://datatracker.ietf.org/ipr/search/?draft=draft-ietf-dmm-srv6-mobile-uplane&submit=draft&rfc=&doctitle=&group=&holder=&iprtitle=&patent=

WG was made aware of the IPR declarations. There were no discussions or objections.



(9) How solid is the WG consensus behind this document? Does it represent
the strong concurrence of a few individuals, with others being silent, or
does the WG as a whole understand and agree with it?

There is strong consensus for advancing this work. The fact that the document went through multiple WGLC is a good indication on the level of working group engagement. People have been quite vocal on this topic.



(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

There is one reviewer who has concerns moving this document forward. The person did not state if he is going to go for an appeal. He did say that he will raise his concerns during IETF LC.
 


(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.


No ID nits errors are seen. Following is the Id nits summary:

Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--).


(12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Not Applicable


(13) Have all references within this document been identified as either
normative or informative?

Yes.


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

All normative references are published RFC and external documents.


(15) Are there downward normative references references (see RFC 3967)? If so,
list these downward references to support the Area Director in the Last Call
procedure.

No.

(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs is
discussed. If this information is not in the document, explain why the WG
considers it unnecessary.


No

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA
registries. Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a detailed
specification of the initial contents for the registry, that allocations
procedures for future registrations are defined, and a reasonable name
for the new registry has been suggested (see RFC 8126).

Yes.



(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.

None.


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, YANG modules,
etc.

Not applicable



(20) If the document contains a YANG module, has the module been checked
with any of the recommended validation tools
(https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and
formatting validation? If there are any resulting errors or warnings,
what is the justification for not fixing them at this time? Does the YANG
module comply with the Network Management Datastore Architecture (NMDA)
as specified in RFC8342?

Not Applicable

Document Shepherd writeup for:

  Title:    Segment Routing IPv6 for Mobile User Plane
  Author:  Satoru Matsushima (editor), Clarence Filsfils, Miya Kohno, Pablo Camarillo Garvia (editor), Daniel Voyer, Charles E. Perkins
  Filename: draft-ietf-dmm-srv6-mobile-uplane

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this the
proper type of RFC? Is this type of RFC indicated in the title page
header?

Standards Track, Proposed Standard
 
The use of SRv6 for enabling mobile user plane requires support from multiple network elements and with a very prescriptive behavior. This is essential for realizing a multi-vendor eco-system and interoperability. Publishing this behavior in a standards-track document will help realize that larger goal.  We therefore believe “Standards Track” is the correct status for this document.

 

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

Relevant content can frequently be found in the abstract and/or
introduction of the document. If not, this may be an indication that
there are deficiencies in the abstract or introduction.

  This document specifies the applicability of SRv6 (Segment Routing
  IPv6) to the user-plane of mobile networks.  The network programming
  nature of SRv6 accomplishes mobile user-plane functions in a simple
  manner.  The statelessness of SRv6 and its ability to control both
  service layer path and underlying transport can be beneficial to the
  mobile user-plane, providing flexibility, end-to-end network slicing,
  and SLA control for various applications.
 

Working Group Summary:

Was there anything in WG process that is worth noting? For example, was
there controversy about particular points or were there decisions where
the consensus was particularly rough?


There have been two WGLCs on this document. The first WGLC was issued in April of 2021. The working group feedback from the first WGLC has identified few technical issues which the authors have addressed over the next 11 months. Subsequently, there was a second WGLC which was issued in April of 2022.

There have been few objections raised during the first WGLC, primarily the concern that the document attempts to redefine 3GPP standard in an IETF document and which is not acceptable. The authors have worked with the reviewers and additionally based on the WG chair feedback have updated the document. Most of the sections are now marked as informative sections. The feedback from the second WGLC did not reflect any such major concerns, except from one WG member who still has concerns on the scope. Other than this one opposing view, there is considerable support from the WG for this work. Based on the feedback received from the first and second last calls, we believe there is rough consensus to move the document forward. 

With regards to the scope of the efforts, we the chairs believe the document does not redefine any particular SDO standard. It is not updating what is specified in 3GPP TS 23.501 or for that matter any other specifications. The focus of the document is about the use of IETF protocols for realizing a specific behavior without modifying the SDO standards. It is about application and the use of an open IETF standard protocol in a forwarding environment. No part of this specification redefines any of the SDO interfaces. 3GPP specified N3 and N9 interfaces or all other interfaces continue to remain the same. An implementation is not required to implement any part of this specification for it to be compliant to the SDO defined standards.





Document Quality:

Are there existing implementations of the protocol? Have a significant
number of vendors indicated their plan to implement the specification?
Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If there was a
MIB Doctor, YANG Doctor, Media Type or other expert review, what was its
course (briefly)? In the case of a Media Type review, on what date was
the request posted?

This document had high visibility and it went through a thorough review process. The quality of the document is very good. It is technically accurate and a well written document.


Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?


  Sri Gundavelli is Document Shepherd.
  Erik Kline is Responsible Area Director.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the
IESG.


I as a Document Shepard and WG co-chair, have reviewed this document.

I believe this document is ready for publication and therefore we are moving this for IESG reviews.



(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that took
place.

No.


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the IESG
should be aware of? For example, perhaps he or she is uncomfortable with
certain parts of the document, or has concerns whether there really is a
need for it. In any event, if the WG has discussed those issues and has
indicated that it still wishes to advance the document, detail those
concerns here.


This document went through a thorough review process. I have no concerns moving this document forward.



(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why?

Yes. 


(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.


https://datatracker.ietf.org/ipr/search/?draft=draft-ietf-dmm-srv6-mobile-uplane&submit=draft&rfc=&doctitle=&group=&holder=&iprtitle=&patent=

WG was made aware of the IPR declarations. There were no discussions or objections.



(9) How solid is the WG consensus behind this document? Does it represent
the strong concurrence of a few individuals, with others being silent, or
does the WG as a whole understand and agree with it?

There is strong consensus for advancing this work. The fact that the document went through multiple WGLC is a good indication on the level of working group engagement. People have been quite vocal on this topic.



(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

There is one reviewer who has concerns moving this document forward. The person did not state if he is going to go for an appeal. He did say that he will raise his concerns during IETF LC.
 


(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.


No ID nits errors are seen. Following is the Id nits summary:

Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--).


(12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Not Applicable


(13) Have all references within this document been identified as either
normative or informative?

Yes.


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

All normative references are published RFC and external documents.


(15) Are there downward normative references references (see RFC 3967)? If so,
list these downward references to support the Area Director in the Last Call
procedure.

No.

(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs is
discussed. If this information is not in the document, explain why the WG
considers it unnecessary.


No

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA
registries. Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a detailed
specification of the initial contents for the registry, that allocations
procedures for future registrations are defined, and a reasonable name
for the new registry has been suggested (see RFC 8126).

Yes.



(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.

None.


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, YANG modules,
etc.

Not applicable



(20) If the document contains a YANG module, has the module been checked
with any of the recommended validation tools
(https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and
formatting validation? If there are any resulting errors or warnings,
what is the justification for not fixing them at this time? Does the YANG
module comply with the Network Management Datastore Architecture (NMDA)
as specified in RFC8342?

Not Applicable

Request for posting confirmation emailed to previous authors: Satoru Matsushima , Charles Perkins , Miya Kohno , " daniel.voyer@bell.ca" , Pablo Camarillo , Clarence Filsfils

Request for posting confirmation emailed to previous authors: Satoru Matsushima , Charles Perkins , Miya Kohno , " daniel.voyer@bell.ca" , Pablo Camarillo , Clarence Filsfils

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

1) The type of RFC being requested is Experimental.
2) This document describes experimental solution of proxy mobile IP extensions to support distributed mobility management.
3) The type of RFC is indicated in the title page header.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

    This document defines proxy mobile IP extension to support distributed mobility management.

Working Group Summary

This document has been reviewed and agreed by the working group.


Document Quality

The solution describes in this document has been implemented by DEMOs.


Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Shepherd: Dapeng(Max) Liu
Responsible Area Director: Suresh Krishnan

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

This document specifies proxy mobile IP extension to support distributed mobility management. This version of the document is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

This document has been reviewed by experts that active in DMM working group.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

N/A.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

There is 3 IPR disclosure references to this document:
https://datatracker.ietf.org/ipr/3030/

Working group discussion and conclusion:

[TBD]

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

This document has reached consensus in the working group and there is no objection to move forward.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

Idnits has been checked, issues found has been solved.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No.


(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

This document defines new mobility options for proxy mobile IP that require IANA to have new registry and those request have been described in the document.


(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

N/A

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

This document does not use formal language.

Request for posting confirmation emailed to previous authors: Satoru Matsushima , Charles Perkins , Miya Kohno , " daniel.voyer@bell.ca" , Pablo Camarillo , Clarence Filsfils

Request for posting confirmation emailed to previous authors: Satoru Matsushima , Charles Perkins , Miya Kohno , " daniel.voyer@bell.ca" , Pablo Camarillo , Clarence Filsfils

Request for posting confirmation emailed to previous authors: Satoru Matsushima , Charles Perkins , Miya Kohno , " daniel.voyer@bell.ca" , Pablo Camarillo , Clarence Filsfils