Mobile Access Gateway Configuration Parameters Controlled by the Local Mobility Anchor
RFC 8127

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

(Suresh Krishnan) Yes

(Alia Atlas) No Objection

(Deborah Brungard) No Objection

(Ben Campbell) No Objection

Comment (2017-04-12 for -04)
No email
send info

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.

- 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) No Objection

(Alissa Cooper) No Objection

(Spencer Dawkins) No Objection

Warren Kumari No Objection

Comment (2017-04-11 for -04)
No email
send info
I had a few minor editorial comments:

  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 :-))

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

(Mirja Kühlewind) No Objection

Comment (2017-04-11 for -04)
No email
send info
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.
"It SHOULD NOT be set to less than 30 seconds or more than 3600 seconds."
"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?

(Alexey Melnikov) No Objection

Comment (2017-04-12 for -04)
No email
send info
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.

(Kathleen Moriarty) No Objection

Comment (2017-04-11 for -04)
No email
send info
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.

Alvaro Retana No Objection