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
