Distributed Mobility Anchoring
draft-ietf-dmm-distributed-mobility-anchoring-15
Yes
(Suresh Krishnan)
No Objection
(Adam Roach)
(Alissa Cooper)
(Alvaro Retana)
(Deborah Brungard)
Abstain
Note: This ballot was opened for revision 14 and is now closed.
Roman Danyliw
No Objection
Comment
(2020-03-04 for -14)
Sent
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)
Sent
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)
Sent
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 IESG member
Yes
Yes
(for -14)
Unknown
Adam Roach Former IESG member
No Objection
No Objection
(for -14)
Not sent
Alissa Cooper Former IESG member
No Objection
No Objection
(for -14)
Not sent
Alvaro Retana Former IESG member
No Objection
No Objection
(for -14)
Not sent
Barry Leiba Former IESG member
No Objection
No Objection
(2020-03-04 for -14)
Sent
Benjamin Kaduk Former IESG member
(was Discuss)
No Objection
No Objection
(2020-03-17)
Sent
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 IESG member
No Objection
No Objection
(for -14)
Not sent
Mirja Kühlewind Former IESG member
Abstain
Abstain
(2020-02-27 for -14)
Sent
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!)!