[DMM] Mirja Kühlewind's Discuss on draft-ietf-dmm-pmipv6-dlif-05: (with DISCUSS and COMMENT)

[Mirja Kühlewind via Datatracker <[e-mail]>]

Mirja Kühlewind has entered the following ballot position for
draft-ietf-dmm-pmipv6-dlif-05: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dmm-pmipv6-dlif/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Sec 3.2:
"The INITIAL_BINDACK_TIMEOUT [RFC6275] SHOULD
   be used for configuring the retransmission timer."
Use of this timeout from RFC6275 is fine. However, you should also indicate
that the rest of the specified retransmission mechanism should be used as well.
That means exponential backoff as well as a max number of retries. Further I
think it would also be important to overall rate-limit the traffic e.g. as
specified in RFC6275: "The mobile node MUST NOT send Mobility Header messages
   of a particular type to a particular correspondent node more than
   MAX_UPDATE_RATE times within a second."

In addition the same mechanisms should probably be also required for any (new)
message sent by the P/S-MAAR in other modes.

Finally in the security consideration section I see this:
"The CMD SHOULD use a pacing approach to limit
   this amplification risk."
Which is good! But why is that a SHOULD and not a MUST?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Editorial comments/nits:

1)Sec 1: "Following this idea, in our proposal, the central anchor is..."
Maybe remove "in our proposal" as this is not a proposal only anymore when
published.

2) Sec 2:
"The following terms used in this document are defined in the DMM
   Deployment Models and Architectural Considerations document
   [I-D.ietf-dmm-deployment-models]:"
As there doesn't seem to be any plan to actually publish
draft-ietf-dmm-deployment-models anymore, maybe move the respective definitions
into this document.

3) Sec 3: "Note that a MN MAY move across different MAARs"
This should be lower case "may".

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

5) In the appendix you always talk about "our solution". This is rather
uncommon for an RFC. I recommend to chance to e.g. "the solution specified in
this document".

6) Are both appendices A and B are still needed?

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.