Re: Mirja Kühlewind's Discuss on draft-ietf-d mm-pmipv6-dlif-05: (with DISCUSS and COMMENT)

Hi Mirja,

Thanks a lot for your review. Please see below my comments.

On Fri, Feb 28, 2020 at 6:06 PM Mirja Kühlewind via Datatracker <
[email protected]> wrote:

> 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."
>
> [CB] This is a good point. I've added some text along the lines you
proposed in a new section "3.6.  Retransmissions and Rate Limiting"


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

[CB] The new section 3.6 referred to in my previous comment applies to all
the nodes (CMD or MAAR) sending a message.


>
> 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?
>

[CB] I was not sure whether to go for a SHOULD or a MUST. I agree with you
it's better to use a MUST there. I've replaced it.


>
>
> ----------------------------------------------------------------------
> 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.
>

[CB] Fixed.


>
> 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.
>

[CB] Done.


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

[CB] Done.


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

[CB] While it's true that it's mainly about implementation details, I
prefer to keep it in the main body, as it explains a mechanism that enables
hiding the change of
 anchors from the mobile node.

>
> 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".
>
> [CB] Right, fixed.


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

[CB] Here I'm neutral. I think they offered value when the document was
discussed at the WG. But I agree now they can be perfectly removed. I'm
removing them in version -06 (to be submitted soon), but if the IESG
believes it is better to put them back, I can easily do it.


>
> 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.
>

[CB] I prefer to keep the document as is. I think it is a matter of
personal preferences, and now it would involve lots of changes.

Thanks again for all your good cooments.

Carlos

_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm