Re: [DMM] Alexey Melnikov's No Objection on draft-ietf-dmm-lma-controlled-mag-params-04: (with COMMENT)

["Dhananjay Patki (dhpatki)" <[e-mail]>]

[Resending with some formatting changes]


Hi Mirja/Alexey/Ben,

Thanks for your respective reviews. Please find below responses to your comments. The comments are addressed in the new version 05 that is attached to this email (not uploaded yet). Please review the rework and let me know if you have any further comments.


----------------------------------------------------------------------
Mirja Kühlewind
----------------------------------------------------------------------
 
Minor comments:
 
1) Please add a reference to rfc5213 right at the beginning of the
intro:
s/A large Proxy Mobile IPv6 (PMIPv6) deployment/A large Proxy Mobile IPv6
(PMIPv6) [RFC5213] deployment/

[Dhananjay] Added


2) Section 3.1 says: "The alignment of the sub-option MUST be 4n."
Is that actually (still) important? Is this also the reason for the
reserved field in the option or is there an expectation that any flags
will be needed in future? Could you remove the reserved field and require
6n then (given you anyway at least need the LCMP Type and Length fields)?
No strong need to change anything, just asking...

[Dhananjay] The alignment of the top-level LCMP is changed to 4n+2 and that of the sub-options is changed to 4n. The alignment is used for consistency with other PMIPv6 RFCs.


3) Given that section 4 only has one subsection, I guess the subsection
heading for 4.1 can simply be removed.

[Dhananjay] Done

 
4)  Are sections 4 and 5 updates to RFC5213? I find the use of normative
language at the beginning of each section a little weird, e.g.:
"The LMA MUST allow the following variables to be configured by the
system management."
Isn't it implicit that these things have to be configurable to implement
this option? I would just not use normative language here...

[Dhananjay] Rephrased


5) Also section 4: I would recommend to use normative language rather to
define the used values itself than what they should be configured to,
e.g.
OLD
"It SHOULD NOT be set to less than 30 seconds or more than 3600
seconds."
NEW
"The delay time SHOULD NOT be less than 30 seconds or more than 3600
seconds."
Maybe even use a MUST here?

[Dhananjay] Changed as suggested. I have retained SHOULD NOT to follows the same language as in RFC  5847.


6) Security consideration: Aren't there security implications if an
external node can influence the number of message and therefore the
network load?

[Dhananjay] Authentication option defined in RFC 4285 will protect against influence from external nodes. In general this extension inherits the security considerations from RFC 5213 and does not require any additional security considerations. The section is updated to reflect this.


----------------------------------------------------------------------
Alexey Melnikov
----------------------------------------------------------------------
 
In 3.1.1 and 3.1.2: I assume all 16-bit values are in Network byte order,
but it would be good if the document said so.

[Dhananjay] Network byte order is an implicit requirement. RFC 2360 talks about this.


In response to Mirja's point 4: I think specifying requirements on
management interfaces is appropriate using RFC 2119 language. And yes, if
an option is sent on the wire, it should be configurable. But I think
drawing implementor's attention to this is important.

[Dhananjay] I believe this is no AI on this.


----------------------------------------------------------------------
Ben Campbell
----------------------------------------------------------------------
 
Substantive:
 
Security Considerations: Seems like more is needed here. Do you mean to
say that none of these parameters add any security considerations that
were not there for existing headers? If that's the case, please say so,
and why people believe that to be the case.

[Dhananjay] Rephrased


Editorial:
- Abstract: Can you mention what sort of parameters this contemplates?
(At a very high level.)

[Dhananjay] Rephrased


- 5, 2nd paragraph: "MUST be extended " seens like a statement of fact.
-- "parameters MUST be defined" Doesn't this document define them?
 
[Dhananjay] Rephrased


--
Regards,
Dhananjay


-----Original Message-----
From: Alexey Melnikov <[e-mail]>
Date: Wednesday, 12 April 2017 at 4:08 PM
To: The IESG <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, Dapeng Liu <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Alexey Melnikov's No Objection on draft-ietf-dmm-lma-controlled-mag-params-04: (with COMMENT)
Resent-From: <[e-mail]>
Resent-To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Resent-Date: Wednesday, 12 April 2017 at 4:08 PM

Alexey Melnikov has entered the following ballot position for
draft-ietf-dmm-lma-controlled-mag-params-04: No Objection

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-lma-controlled-mag-params/



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

In 3.1.1 and 3.1.2: I assume all 16-bit values are in Network byte order,
but it would be good if the document said so.

In response to Mirja's point 4: I think specifying requirements on
management interfaces is appropriate using RFC 2119 language. And yes, if
an option is sent on the wire, it should be configurable. But I think
drawing implementor's attention to this is important.