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

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Fri, 06 Jan 2012 20:01:09 +0100

Dear all,

I've read draft-ietf-netext-access-network-option-03. It is well written
and most of my comments (for -00 version) have been addressed.

Some additional comments below:

- I think the names of the new defined mobility header and the options
may lead to a bit of confusion. Section 3 deals with the new mobility
header, but it is called "Access Network Identifier Option". I'm not
sure if it'd be better to call it "Access Network Identifier Mobility
Header"/"Access Network Identifier Mobility Option"/"Access Network
Identifier". The (minor) problem I have is that there is also an option
which has a very similar name ("Access Network Identifier Sub-option").

- Related to the former, I think Sections 3.2 to 3.4 should be moved to
a lower hierarchy level (like 3.1.1 to 3.1.3), because they deal with
sub-options of the Access Network Identifier Sub-Option (which is
defined in Section 3.1).

- The Network-Identifier Sub-option (Section 3.2) seems 802.11 specific.
If that is the case, I think it'd be better to rename it so the name
reflects that.

- Section 4.1. I think the text may be a bit reworded, so it does not
say that "Specifically, the following parameters must be defined."
referring to the currently defined 3 Access Network Identifier
sub-options. I think it should leave room for sub-options defined in the
future. Additionally, the "must" normative term is used in lower case.
The same comment applies to Section 4.2.

- When the EnableANISubOptetworkIdentifier config variable is discussed,
I think the per-interface example does not consider all possible cases.
Maybe some text about VLAN configurations may be useful.

- Section 5. I don't know if I'm missing something here (most likely),
but I don't see why there is no text about the "Network-Identifier" and
"Geo-Location" sub-options (Sections 3.2 and 3.3). Shouldn't be there
also text for them?

Nits:

- "The specific details on how the local mobility anchor uses this
information is out-of-scope..." --> "are out-of-scope"?
- "is used to exchanged access network related information" --> "is used
to exchange..."
- "If the mobile access gateway is configured to support to Access..."
--> I think the last "to" should be removed.

Hope this helps.

Kind Regards,

Carlos

-- 
Carlos Jesús Bernardos Cano  http://www.netcom.it.uc3m.es/
GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 06 Jan 2012 12:06:01 -0800

Hi Carlos,

Thanks a lot for the second review. We will address these comments and
hopefully the WGLC can be initiated on this draft now.

Regards
Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Sat, 07 Jan 2012 10:00:57 -0800

Hi Carlos:

Thanks for the review and good comments. Appreciated it. Posted the updated
version. 

Idnit Errors/Warnings/Spell check: Zero

Comments inline.

> which has a very similar name ("Access Network Identifier Sub-option").

We looked at it, appears Ok. The names are not ambiguous. There is one
mobility option and rest sub-options in that option. But, I will wait for
more inputs. Any cases, reworded where ever possible.

> sub-options of the Access Network Identifier Sub-Option (which is

Good point. Done

> If that is the case, I think it'd be better to rename it so the name

We did not want to restrict the name to SSID, it could be used beyond WLAN
access networks. I thought of defining a sub-type for qualifying this, but
given the ATT option, I rather not define a new registry for this. I've
added text to indicate SSID as an example. Does this sound reasonable ?

> The same comment applies to Section 4.2.

I slightly reworded this. The spec is only identifying three ATT related
parameters and that's what is defined in BUL/BCE entries. If a new draft
defines new sub-options, that spec has to extend the BCE/BUL entries.

> Maybe some text about VLAN configurations may be useful.

All of the IE's can be configured on the MAG, on a per-interface basis. Each
interface can be part of specific VLAN, identified by a .1q tag. I've
updated the text to state, this can be these static params, or obtained
through other means such as DHCP option 82, or in access specific means.

> "Geo-Location" sub-options (Sections 3.2 and 3.3). Shouldn't be there

Yes. You are missing some thing, that the authors get lazy and start taking
short cuts, when they hit the last sections of the document :)
Fixed

> --> I think the last "to" should be removed.

Fixed. Thanks !!!

> Hope this helps.

Absolutely.

Best Regards
Sri

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Sat, 07 Jan 2012 22:09:30 +0100

Hi Sri,

Thanks for taking into account my comments. Some minor comments inline
below.

> more inputs. Any cases, reworded where ever possible.

Well, there are no duplicated names, that's true. What I meant is that
there is one mobility option/header, which has one sub-option (called
very similarly), which then has sub-options.

> added text to indicate SSID as an example. Does this sound reasonable ?

Yes, thanks.

> defines new sub-options, that spec has to extend the BCE/BUL entries.

OK.

> through other means such as DHCP option 82, or in access specific means.

OK.

> short cuts, when they hit the last sections of the document :)

:)

> > --> I think the last "to" should be removed.

Thanks.

Kind Regards,

Carlos

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 10 Jan 2012 23:03:28 -0800

Hi Carlos:

Thanks. Will keep that one comment open on the sub-option name.

Thanks again for the review.

Regards
Sri