Distributed Mobility Anchoring
RFC 8818
Yes
No Objection
Abstain
Note: This ballot was opened for revision 14 and is now closed.
Alvaro Retana No Objection
Roman Danyliw No Objection
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
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
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, Regards, -éric == COMMENTS == -- 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
(Adam Roach; former steering group member) No Objection
(Alissa Cooper; former steering group member) No Objection
(Barry Leiba; former steering group member) No Objection
(Benjamin Kaduk; former steering group member) (was Discuss) No Objection
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.
(Deborah Brungard; former steering group member) No Objection
(Mirja Kühlewind; former steering group member) Abstain
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!)!