Subject: [netext] AD Review: draft-ietf-netext-access-network-option

From: Brian Haberman <[email-masked]>
Date: Tue, 24 Apr 2012 17:14:31 -0400

All,
      I have completed my AD review of this draft.  For the most part, 
it is a well-written document.  I have some comments, suggestions, and 
questions that should be relatively easy to deal with.

1. In the Introduction, the first paragraph talks about requiring the 
LMA to provide differentiated service and policing.  Should this be an 
Informative reference to the DiffServ architecture (RFC 2475)?

2. It would be good to expand the PCC and ANDSF acronyms in the Intro 
for the uneducated reader.

3. The term "Web Page" does not need to be capitalized.

4. Introduction (2nd paragraph):
- s/allows for carrying the/allows for the carrying of/
- the LMA acronym was already expanded
- s/is a need for an additional/is a need for additional/
- s/an local mobility anchor/a local mobility anchor/
- insert "optionally" prior to "...carrying such information..."

5. Introduction (3rd paragraph):
- add "the" before first instance of "Access Network Identifier"
- s/used by mobile access gateway/used by the mobile access gateway/
- s/for carrying the access network/to signal the access network/

6. Section 3:
- The text for the ANI option says "...there can only be a single 
instance...".  I would like to see this strengthened with the use of 
2119 keywords.  Would "...there MUST NOT be more than a single 
instance.." convey the point?
- Similarly, would "The Access Network Identifier mobility option MUST 
contain one or more..." work?
- The alignment requirement is useful, but I would also like a reference 
to how I interpret "4n".

7. Section 3.1.1
- s/that can be carried in Access/carried in the Access/
- s/There can only be a single instance/There MUST be no more than a 
single instance/
- The ANI Type MUST be set to a value of (1)
- In the Network Name, MUST the SSID be used if it is 802.11?
- s/digists/digits/
- Where do the MNC and MCC codes come from?
- You will need a reference for UTF-8.
- In AP-Name Length definition, it MUST be set to zero if the name is 
not carried?

8. Section 3.1.2
- s/that can be carried in Access/carried in the Access/
- "This sub-option carries the Geo-location..."
- s/There can only be a single instance/There MUST be no more than a 
single instance/
- ANI Type: It MUST be set to a value of (2), ...
- In ANI Length, I think it is better to say "MUST be set to a value of 8".
- I would use MUSTs to define the acceptable ranges of the fields and 
specify what a receiver does when those ranges are violated.  I would 
also capitalize the "must" in statements on rounding values.

9. Section 3.1.3:
- The Operator-Identifier sub-option carries the operator...
- s/There can only be a single instance/There MUST be no more than a 
single instance/
- The ANI Type MUST be set to a value of (3)
- Should the reference to "Vendor ID" in Operator ID value 1 really be 
"Operator ID"?
- What string encoding is supported for the Operator Identifier?

10. Section 4.1
- s/the following parameters must be/the following parameters MUST be/
- Are there recommended datatypes for the new parameters?
- The 2nd bullet says the ANI option SHOULD be constructed as specified 
in Section 3.  Why is this a SHOULD and not a MUST?
- s/It should include the relevant/It SHOULD include the relevant/ and 
in what conditions would it not include the relevant sub-options?
- s/through some of out of means/through some out-of-band means/
- The references to Section 6 when discussing the configuration 
variables need to be put in parenthesis. I would also like to see a 
discussion of when it is OK to violate the SHOULDs.
- I am not sure I understand the following: "...the Proxy Binding 
Acknowledgement received from the local mobility anchor is also expected 
to contain...".  SHOULD it contain the option?  MUST it contain the option?

11. Section 4.2
- Same comment on whether there are recommended datatypes for the new 
parameters.  And those parameters "MUST" be defined.
- 3rd bullet: What does it mean to "agree with" the sub-option?
- 3rd bullet: Is the last sentence necessary?
- The 4th bullet seems clunky and is hard to parse.  Can it be re-worded 
to state that if there is a matching session the old information MUST be 
removed.
- I would suggest adding an "outside the scope of this document" clause 
to the 5th bullet.

12. Section 5
- I would suggest adding an example table structure for IANA actions 2 & 3.
- Is there a potential recommendation for the Expert Reviewer that can 
be added to this section?

13. Section 6
- I would suggest re-wording the introductory sentence of each variable 
to something like: "This flag indicates the operational state of the ..."
- Can you document rationale for why the SHOULDs are not MUSTs?

Regards,
Brian

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 25 Apr 2012 00:05:44 -0700

Hi Brian,

Thanks a lot for your detailed review. Please see inline. I've posted the
updated spec.

> Informative reference to the DiffServ architecture (RFC 2475)?

DiffServ based service treatment is probably just one example.

> for the uneducated reader.

OK

> 3. The term "Web Page" does not need to be capitalized.
OK

> - s/allows for carrying the/allows for the carrying of/
Ok
> - the LMA acronym was already expanded
Ok
> - s/is a need for an additional/is a need for additional/
Ok
> - s/an local mobility anchor/a local mobility anchor/
Ok
> - insert "optionally" prior to "...carrying such information..."
OK

> - add "the" before first instance of "Access Network Identifier"

Ok

> - s/used by mobile access gateway/used by the mobile access gateway/

Ok

> - s/for carrying the access network/to signal the access network/
OK

> instance.." convey the point?

Agree

> contain one or more..." work?

Agree

> - The alignment requirement is useful, but I would also like a reference

Wondering, which spec provides a good reference for this. 2460 Appendix ?

> - s/that can be carried in Access/carried in the Access/

Ok

> - s/There can only be a single instance/There MUST be no more than a

Ok

> - The ANI Type MUST be set to a value of (1)

Ok

> - In the Network Name, MUST the SSID be used if it is 802.11?

Yes

> - s/digists/digits/
Ok

> - Where do the MNC and MCC codes come from?

3GPP Specification 3GPP TS 23.003

> - You will need a reference for UTF-8.

Ok. RFC 3629

> - In AP-Name Length definition, it MUST be set to zero if the name is

Reworded

> - s/that can be carried in Access/carried in the Access/

ok

> - "This sub-option carries the Geo-location..."

Ok

> - s/There can only be a single instance/There MUST be no more than a

Ok

> - ANI Type: It MUST be set to a value of (2), ...

ok

> - In ANI Length, I think it is better to say "MUST be set to a value of 8".

Ok

> also capitalize the "must" in statements on rounding values.

Ok

> - The Operator-Identifier sub-option carries the operator...

Ok

> - s/There can only be a single instance/There MUST be no more than a

ok

> - The ANI Type MUST be set to a value of (3)

Ok

> - Should the reference to "Vendor ID" in Operator ID value 1 really be

No. Vendor Id is the term used for referring to the enterprise number.

> - What string encoding is supported for the Operator Identifier?

UTF-8. 

> - s/the following parameters must be/the following parameters MUST be/
Ok
> - Are there recommended datatypes for the new parameters?

We have not defined data types for conceptual data structure fields in most
PMIP specs, so not sure, if we should do this now. We might be imposing a
specific implementation, unless we are sure the suggested data types are the
correct types

> in Section 3.  Why is this a SHOULD and not a MUST?

MUST might be too strong. The feature may be enabled, but what if the MAG is
unable to get all the needed parameters.

> - s/It should include the relevant/It SHOULD include the relevant/ and
Ok

> in what conditions would it not include the relevant sub-options?

Removed "relevant"

> - s/through some of out of means/through some out-of-band means/

Ok

> discussion of when it is OK to violate the SHOULDs.

Ok.
 
"However, if the mobile access gateway is unable to obtain the operator
identity, then it MUST NOT include this sub-option."

> to contain...".  SHOULD it contain the option?  MUST it contain the option?

SHOULD is probably ok

> parameters.  And those parameters "MUST" be defined.

We have not defined data types for conceptual data structure fields in most
PMIP specs, so not sure, if we should do this now. We might be imposing a
specific implementation, unless we are sure the suggested data types are the
correct types

> - 3rd bullet: What does it mean to "agree with" the sub-option?

If the LMA is enabled to support that sub-option

> - 3rd bullet: Is the last sentence necessary?

Removed

> to state that if there is a matching session the old information MUST be

Ok

> - I would suggest adding an "outside the scope of this document" clause

I'm not sure I understood this comment

> - I would suggest adding an example table structure for IANA actions 2 & 3.
Ok

> be added to this section?

OK

> to something like: "This flag indicates the operational state of the ..."
Ok

> - Can you document rationale for why the SHOULDs are not MUSTs?

MUST is too strong, IMO. The config variables may be turned on, but there
are many other reasons where the MAG may be unable to construct the option.

I've also added a reference to DHCP Geo Location spec, RFC 6225.

> 
> Regards,
> Brian
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext

---

From: Brian Haberman <[email-masked]>
Date: Wed, 25 Apr 2012 08:53:57 -0400

Sri,
      Thanks for the quick turnaround.  I have trimmed the changes we 
agree on and the remaining follow-ups are in-line...

> Wondering, which spec provides a good reference for this. 2460 Appendix ?

A reference to 2460 is sufficient.

> No. Vendor Id is the term used for referring to the enterprise number.

Ok.  I parsed that sentence incorrectly.

> specific implementation, unless we are sure the suggested data types are the

No need to if there is not precedence to do it.

> unable to get all the needed parameters.

The inability to get the needed parameters falls under the first SHOULD 
about including the option, in my opinion.  So, if the MAG cannot get 
those parameters, it doesn't send the option.  When the MAG decides to 
include the option I would think it MUST construct the option based on 
Section 3.  Which sub-options to include are driven by what information 
the MAG has available.  If you don't construct the options in the 
formats defined in Section 3, how do you ensure correct handling?

Ok.

> I'm not sure I understood this comment

Sorry for the terseness.  I am thinking that the decision to use the ANI 
options are driven by policies/issues that are outside the scope of this 
specification.  In other words, there is nothing in this document that 
controls how/when the operator applies the information contained in 
these options.
>
>
>> 12. Section 5
>> - I would suggest adding an example table structure for IANA actions 2&  3.
> Ok
>

Then I would suggest adding a sentence that explains that situation.

> I've also added a reference to DHCP Geo Location spec, RFC 6225.

Good.

Regards,
Brian

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 25 Apr 2012 06:48:37 -0700

Hi Brian,

Thanks for the quick response. Please see inline.

Ok

Ok

Ok

> formats defined in Section 3, how do you ensure correct handling?

I agree for the use of MUST for the "construct" clause; I did not read my
text carefully. How about this:

"If the mobile access gateway is configured to support Access Network
Information option, it SHOULD include this option with the specific
sub-options in all Proxy Binding Update messages (including in Proxy Binding
Updates for lifetime extension and for deregistration) that it sends to the
local mobility anchor. The Access Network Information option MUST be
constructed as specified in Section 3. It SHOULD include the ANI
sub-option(s) that the mobile access gateway is configured to carry them in
the Proxy Mobile IPv6 messages."

> controls how/when the operator applies the information contained in

I got it now. How about this.

Section 4.2 (Last bullet point):

"The local mobility anchor MAY choose to use the access network information
sub-options for applying any access operator specific handling or policing
of the mobile node traffic. The specific details on how these sub-options
are used is outside the scope of this document."

>>> - I would suggest adding an example table structure for IANA actions 2&  3.

I've added to the tables IANA actions 2 and 3.

   +=========================================================+
   | 0 | Reserved                                            |
   +=========================================================+
   | 1 | Network-Identifier Sub-option                       |
   +=========================================================+
   | 2 | Geo-Location Sub-option                             |
   +=========================================================+
   | 3 | Operator-Identifier Sub-option                      |
   +=========================================================+

   +=========================================================+
   | 0 | Reserved                                            |
   +===+=====================================================+
   | 1 | Vendor ID as a four octet Private Enterprise Number |
   +===+=====================================================+
   | 2 | Realm of the Operator                               |
   +===+=====================================================+

>>> be added to this section?

One of the Authors ?

>>> to something like: "This flag indicates the operational state of the ..."

This is what I've:

This flag indicates the operational state of the Network-Identifier
sub-option support.
..
This flag indicates the operational state of the Geo-Location sub-option
support.
..
This flag indicates the operational state of the Operator-Identifier
sub-option support.

> Then I would suggest adding a sentence that explains that situation.

How about some thing like this for each of the variables ?

"There can be situations where the MAG is unable to obtain the network name
and be able to construct the option."

Regards
Sri

---

From: Brian Haberman <[email-masked]>
Date: Wed, 25 Apr 2012 10:43:40 -0400

> the Proxy Mobile IPv6 messages."

Drop the "them" from the last sentence and that works for me.

> are used is outside the scope of this document."

Sounds good.

Good.

>>>> be added to this section?

That is fine.  There is no need to include that in the draft.  I will 
pass that information along to IANA when they review the document.

Ok.

> and be able to construct the option."

Works for me.

Regards,
Brian

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 25 Apr 2012 08:33:08 -0700

Thanks Brian. Revised version posted.

Sri