Skip to main content

Mobile Access Gateway Configuration Parameters Controlled by the Local Mobility Anchor
draft-ietf-dmm-lma-controlled-mag-params-05

Yes

(Suresh Krishnan)

No Objection

(Alia Atlas)
(Alissa Cooper)
(Alvaro Retana)
(Benoît Claise)
(Deborah Brungard)
(Spencer Dawkins)

Note: This ballot was opened for revision 03 and is now closed.

Warren Kumari
No Objection
Comment (2017-04-11 for -04) Unknown
I had a few minor editorial comments:

"LCMPReregistrationStartTime
  This variable is used to set the minimum time interval **in number of seconds** before the expiry... The default
   value is 10 units, where each unit is 4 seconds."
I understand what it is trying to say, but the "in number of seconds" and "units of 4 seconds" seemed confusing to me (and I immediately wanted to try set it to e.g 43 seconds, just because :-))

"LCMPHeartbeatInterval"
  SHOULD NOT be less than 30 seconds or more than 3600 -- why not? If I choose to DoS myself (or limit my ability to change), isn't that my choice? (No need to change this, just checking to make sure the numbers had discussion behind them).
Suresh Krishnan Former IESG member
Yes
Yes (for -03) Unknown

                            
Alexey Melnikov Former IESG member
No Objection
No Objection (2017-04-12 for -04) Unknown
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.
Alia Atlas Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Alissa Cooper Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Alvaro Retana Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Ben Campbell Former IESG member
No Objection
No Objection (2017-04-12 for -04) Unknown
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.

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

- 5, 2nd paragraph: "MUST be extended " seens like a statement of fact.
-- "parameters MUST be defined" Doesn't this document define them?
Benoît Claise Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Deborah Brungard Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Kathleen Moriarty Former IESG member
No Objection
No Objection (2017-04-11 for -04) Unknown
If text is expanded on the security considerations section from Mirja's comment (thanks for asking that), benefits of the extensions to reduce traffic should also be included.
Mirja Kühlewind Former IESG member
No Objection
No Objection (2017-04-11 for -04) Unknown
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/

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

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

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

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?

6) Security consideration: Aren't there security implications if an external node can influence the number of message and therefore the network load?
Spencer Dawkins Former IESG member
No Objection
No Objection (for -04) Unknown