Distributed Mobility Anchoring
RFC 8818

Note: This ballot was opened for revision 14 and is now closed.

Alvaro Retana No Objection

Benjamin Kaduk (was Discuss) No Objection

Comment (2020-03-17)
Thanks for addressing my Discuss and Comment points!

I think the current placement of the references to RFCs 8221 and 8247 make it sound          
like they are references for IPsec and IKEv2 respectively, and not "just"           
the best-practices for configuring them.  Moving the references later          
in the sentences would probably help, though I'd recommend adding another           
sentence "The current guidance for IPsec and IKEv2 usage is given in                
[RFC8221] and [RFC8247], respectively" to be fully clear about why they are         
being referenced.

Roman Danyliw No Objection

Comment (2020-03-04 for -14)
I support Ben Kaduk’s DISCUSS point.

Section 5.  To provide symmetry with the IPSec recommendation, s/IKEv2 should/IKEv2 SHOULD/

Warren Kumari No Objection

Comment (2020-03-03 for -14)
I am balloting NoObj, but I had a hard time deciding between this and DISCUSS (I went with NoObj because I'm submitting this late) - Qin Wu submitted an OpsDir review with a number of open questions, as well as some very easy to address comments / suggestions.
It looks like this were either ignored, or missed (or, perhaps I missed the discussion)

I strongly encourage the authors and AD to review and address these comments.

Éric Vyncke No Objection

Comment (2020-03-02 for -14)
Thank you for the work put into this document. 

Nevertheless, please find below some non-blocking COMMENTs (and I would appreciate a response from the authors) and NITS.

Please also address the review done by Carlos for the Internet Directorate (see: https://datatracker.ietf.org/doc/review-ietf-dmm-distributed-mobility-anchoring-14-intdir-telechat-pignataro-2020-02-28/ ) Thank you Carlos for this review.

I hope that this helps to improve the document,




-- Section 4 --
Can you better define what is a "dynamic IP address" ?

In the last paragraph, is there any reason why draft-ietf-intarea-provisioning-domains is not mentioned as yet another means to select an IP address for new connections ?

-- Section 4.1 --
Please expand AR at first use

-- Section 4.3 --
To be honest, relocating the DP anchor is sending a bad feeling under my skin... Scalability will be a major concerned as mentioned in your document: "such a solution may present some scalability concerns"

(Suresh Krishnan; former steering group member) Yes

Yes ( for -14)
No email
send info

(Adam Roach; former steering group member) No Objection

No Objection ( for -14)

(Alissa Cooper; former steering group member) No Objection

No Objection ( for -14)

(Barry Leiba; former steering group member) No Objection

No Objection (2020-03-04 for -14)
You include the BCP 14 boilerplate and references, but there are no BCP 14 key words in the document (except in a quotation from another document).  I suggest removing the boilerplate and the references.

(Deborah Brungard; former steering group member) No Objection

No Objection ( for -14)

(Mirja Kühlewind; former steering group member) Abstain

Abstain (2020-02-27 for -14)
While I think the content of this document is fine and I'm sure it was valuable to has this written down as basis for potentially on-going working group discussion, I don't see a value in publishing this document in a (separate) RFC.

Further I don't see a milestone covering this document in the dmm charter. There is a bullet point on "Distributed mobility management deployment models and scenarios" however that does not mean that this has to be documented in potentially multiple RFCs. There is also draft-ietf-dmm-deployment-models with a quite central reference in the document, however, this draft is expired for more than a year. What's the plan here?

In any case, thanks for quickly addressing the TSV-ART review (and Yoshi thanks for the review!)!