Proxy Mobile IPv6 Extensions for Distributed Mobility Management
draft-ietf-dmm-pmipv6-dlif-06

I support Mirja Kühlewind's and Ben Kaduk's DISCUSS position.

** Section 6. Per “The CMD SHOULD use a pacing approach to limit this amplification risk”, could you address Vincent Roca’s SECDIR Review (thank you!) question “should that pacing be on the In the incoming queue (i.e., by delaying some PBU/PBA messages) or in the outgoing queue (i.e., to limit output traffic), or both?”

** Section 6.  To provide normative language: 
s/This requires security associations to exist between the involved MAARs/
Hence, security associations are REQUIRED to exist between the involved MAARs/

Editorial Nit:
** Section 6. s/there may exist multiple previous (e.g., k) MAARs exist/ there may exist multiple previous (e.g., k) MAARs/

Thank you for the work put into this document. And congratulations for the many advanced ASCII art ! Except for section 3.6, the text is really easy to read.

Thank you also for fixing my previous DISCUSS as well as replying by email to my comments. I have kept the original DISCUSS & COMMENT below.

Please also address the points raised by Carlos during the INT directorate review. Thank you again Carlos !
https://datatracker.ietf.org/doc/review-ietf-dmm-pmipv6-dlif-05-intdir-telechat-pignataro-2020-02-28/

Happy that my comments have helped to improve the document

Regards,

-éric

== OLD DISCUSS ==

-- Section 4.3 & 4.4 & 4.5 --
Probably trivial to fix but is "Prefix Length" expressed in bits (/64) or in bytes (8 bytes). If the latter, then how can we have a prefix of /57 ? The definition of the "Prefix length" field should be specific about the unit (bits/bytes) and be aligned with the definition of "Anchored prefix" (as this one seems to assert that the prefix length must be a multiple of 8).

== COMMENTS ==

A generic question, can a MN be attached to multiple MAAR at the same time? I.e., once over WiFi and once of 3GPP ? There seems to be only one S-MAAR at any time.

-- Section 3.1 --
Should the length of the prefix assigned to the MN be specified? Adding a /64 would make things clearer without using too much of text.

For my own curiosity, the text is about "IPv6 global prefix", but, would ULA also work ? 

-- Section 3.6 --
This section is so different than the previous ones in section 3, that I would have created a section on its own.

This section also uses EUI-64 for the link-local address; and, this is no more advised for privacy reason. Not really important in the DMM context though.

Important thing to fix, s/fe80:211:22ff:fe33:101/fe80::211:22ff:fe33:101/ ;-)

The text of this section is really difficult to parse. After 2 readings I am not even sure that I got it... I was about to open a DISCUSS for the point 2) but I am unsure whether I am reading the text correctly. 

1) If the MAC and LLA for the 'virtual router' mn1mar2 are different than the one for mn1mar2, why is there a need for different interface? Multiple routers can exist on the same link.

2) For packets sourced by MN1 with prefix1 how can we ensure that they are sent to mn1mar1 and not to mn1mar? PvD could help there and should be mentionned draft-ietf-intarea-provisioning-domains.

-- Section 4.2 --
Bit 31 is not described, it is probably reserved but you should really described it.

With this PBA packet format, all flags / bits are used and assigned for an experimental document. Isn't it a waste of bits? I will really appreciate an answer on this question.


== NITS ==

-- Section 3 (and possibly others) --
The CMD and MAAR acronyms are expanded multiple times. This makes the reading easier for newcomers of course.

Thanks for the work on this document. I have only one editorial suggestion.

Section 3.6:

>   to-point link) with MN1, exposing itself as a (logical) router with a
>   specific MAC (e.g., 00:11:22:33:01:01) and IPv6 addresses (e.g.,

Please use a MAC address from the range reserved for documentation purposes by section 2.1.1 of RFC 7042.

Thanks for addressing my discuss and adding section 3.6. I know that the text there is inline with RFC6275 and therefore I'm clearing my discuss. However I just notice that its says

" The node MAY continue to send these	
 	   messages at this slower rate indefinitely."

I think allowing to send something indefinitely is always a bad idea. This is a MAY but given there is no alternative provided, I guess it's not unlikely that people will implement it this way. It's always better to have a defined termination condition. This could be something like "SHOULD stop sending after X <timeunit> and log an error" where X <timeunit> is a super high value in e.g. days. This would implicitly also allow to send indefinitely because it's a SHOULD but would make it less likely people implement that. I personal would however even recommend a MUST.

In any case, as RFC6275 has exactly the same sentence, so I'm not blocking on this, but maybe still worth reconsidering...


---------
Old comments: I fully understand why the authors decided to not make changes but keeping these as for the record:


4) As section 3.6 talks mainly about implementation details, I suggest to move this section into the appendix.

7) One overall editorial comment which might be too late to address: I would have found it more easy to read if you would have first introduced the new messages and then used the concrete message names in the description in section 3.