Access Network Identifier (ANI) Option for Proxy Mobile IPv6
draft-ietf-netext-access-network-option-13

[Ballot comment]
I assume the conclusion of the discussion you were having at IETF about the encoding of SSIDs fell out to UTF-8 instead of raw bits?

[Ballot discuss]
(1) Why doesn't this use geopriv?  I think Robert put this better than
I in asking why don't RFC 6280 considerations apply. I think they
ought. The text that's new since -11 however, might provide a way
forward. In -12 you clarified that this information is only for infrastructure
nodes to use to provide better network service. And in -13 you changed
the lat/lon structure. So I'm wondering if there's a way to do a -14
that adds the rule information to the lat/lon as 6280 implies is
needed? That could be as simple as a hardcoded value, not sure
if that'd work, but since you've changed that structure in -13, adding
some hardcoded value meaning "this rule applies" might be a way
to fix this.

(2) cleared

(3) Rolled into point 1 above.

(4) cleared

[Ballot discuss]
(1) Why doesn't this use geopriv?  I think Robert put this better than
I in asking why don't RFC 6280 considerations apply. I think they
ought. The text that's new since -11 however, might provide a way
forward. In -12 you clarified that this information is only for infrastructure
nodes to use to provide better network service. And in -13 you changed
the lat/lon structure. So I'm wondering if there's a way to do a -14
that adds the rule information to the lat/lon as 6280 implies is
needed? That could be as simple as a hardcoded value, not sure
if that'd work, but since you've changed that structure in -13, adding
some hardcoded value meaning "this rule applies" might be a way
to fix this.

(2) cleared

(3) Rolled into point 1 above.

(4) I looked at 6275 and 5213 and its not clear to me that
these sensitive values, if sent, MUST be protected using IPsec
with strong confidentiality and mutual authentication. The
authentication part may be ok according to the documents, but
I'm not sure if that's the deployed reality. Is it? But even if
so, there's nothing much that I can see to ensure
confidentiality for this information. Where's all that
(clearly) specified? I still do not see this clearly specified
anywhere in -13. Just using AH is arguably not enough
here.

[Ballot discuss]
Thanks for solving some of my DISCUSSes
Here is the updated DISCUSS.

- I was proposing:

  Operator PEN ID

      SMI Network Management Private Enterprise
      Code of the IANA-maintained Private Enterprise Numbers registry
      [SMI] for the operator running ... [actually running what, that's another
      required clarification in the draft] ... the respective interface on mobile access gateway?

You chose to remove "running ..":
  Operator ID

      The Operator ID is the SMI Network Management Private Enterprise
      Code of the IANA-maintained Private Enterprise Numbers registry
      [SMI].

This is fine but you have to add that "running ..." part in

Operator Identifier (Op-ID) Type:  8-bit unsigned integer indicating
    the type of the Operator Identifier.

By for example, re-using a previous sentence: "This sub-option carries the operator identifier of the access network to which the mobile node is attached."


- Regarding "And also add a few sentences about whether all operators should or must now register new PENs for this spec.  I checked for a couple of my local ISPs, and not all of them had a PEN.", you added: "If a given access network operator has not obtained an identifier from the Private Enterprise Number registry,..." this is fine, but I'm still unclear if the operator MAY/SHOULD/MUST request a PEN?

[Ballot discuss]
Thanks for solving some of my DISCUSSes
Here is the updated DISCUSS.

- I was proposing:

  Operator PEN ID

      SMI Network Management Private Enterprise
      Code of the IANA-maintained Private Enterprise Numbers registry
      [SMI] for the operator running ... [actually running what, that's another
      required clarification in the draft] ... the respective interface on mobile access gateway?

You chose to remove "running ..":
  Operator ID

      The Operator ID is the SMI Network Management Private Enterprise
      Code of the IANA-maintained Private Enterprise Numbers registry
      [SMI].

This is fine but you have to add that "running ..." part in

Operator Identifier (Op-ID) Type:  8-bit unsigned integer indicating
    the type of the Operator Identifier.

By for example, re-using a previous sentence: "This sub-option carries the operator identifier of the access network to which the mobile node is attached."


- And also add a few sentences about whether all operators should or must now register new PENs for this spec.
  I checked for a couple of my local ISPs, and not all of them had a PEN.
You added: "If a given access network operator has not obtained an identifier from the Private Enterprise Number registry,..." this is fine, but I'm still unclear if the operator MAY/SHOULD/MUST request a PEN?

[Ballot discuss]
[Updating per email discussion]

3.1.1

  'E'-bit:  1-bit flag for representing the encoding of the following
      name field.  MUST be set to zero (0) if the network name is
      encoded using a string of opaque 8-bit octets or to one (1) if the
      network name is encoded using UTF-8 [RFC3629].

"Encoded using a string of opaque 8-bit octets" is problematic, particularly the word "encoded". Really, zero (0) means "undefined". That is, if the 'E'-bit is 0, then the encoding is only discoverable via out-of-band mechanisms. I think you need to use those words:

"'E'-bit: 1-bit flag indicating whether the network name is encoded in UTF-8. If this flag is set to one (1), then the network name is encoded using UTF-8 [RFC 3629]. If the flag is set to zero (0), this indicates that the encoding is undefined and is determined by out-of-band mechanisms."

I'd even prefer adding a sentence saying, "Implementations SHOULD use UTF-8 encoding."

  Net-Name Length:  8-bit field for representing the length of the
      network name to be followed.

I think you want to specifically say "in octets", since if it's UTF-8, characters is probably *not* what you mean. Also for AP-Name Length and ANI Length. Check throughout the document please.

3.1.3

      2 -  Realm of the operator.  Realm names are required to be
        unique, and are piggybacked on the administration of the DNS
        namespace.  Realms are encoded using a domain name encoding
        defined in [RFC1035].

  Operator Identifier:  Up to 253 octets of the operator identifier.
      The encoding of the identifier depends on the used Operator-ID
      Type.  Numeric values are encoded in network byte order and
      strings are in UTF-8 representation and have no terminating '\0'
      mark.

So the first part above says that the domain names are encoded to RFC 1035. Are you talking there about the letter-digit-hyphen rules of 2.3.1 of 1035? If so, you should say that. However, if that's what you mean, then clearly those are all US-ASCII. The second part says that "strings are in UTF-8 representation". Now I'm confused. Are you intending to allow things outside of US-ASCII, e.g. unencoded UTF-8 U-labels for IDNs? Something is not right about the above. If you changed the last sentence of the Realm definition to be, "Realms are encoded using a US-ASCII domain name encoding as defined in [RFC1035]" (and explain the bit about the terminating '\0' here), then I think you could get away with just striking the last sentence of the Operator definition and you'd be fine. I just want to make sure you are not allowing IDN U-labels, or if you are allowing them, you need to be explicit (and would need to add a bunch more text and more explanation about comparisons).

[Ballot discuss]
(1) Why doesn't this use geopriv?

(2) cleared

(3) Why is it ok to send SSID and AP name  without asking the
user?  Many of those are pretty revealing as to MN location.

(4) I looked at 6275 and 5213 and its not clear to me that
these sensitive values, if sent, MUST be protected using IPsec
with strong confidentiality and mutual authentication. The
authentication part may be ok according to the documents, but
I'm not sure if that's the deployed reality. Is it? But even if
so, there's nothing much that I can see to ensure
confidentiality for this information. Where's all that
(clearly) specified?

[Ballot discuss]
-The term "vendor" is confusing

  Vendor ID

      The Vendor ID is the SMI Network Management Private Enterprise
      Code of the IANA-maintained Private Enterprise Numbers registry
      [SMI].

The example in figure 1 speaks about: "Operator-Id: provider2.example.com"
Vendor Id, in the network management world is the manufacturer id, while you're after the Operator-Id
I see what you want to do, but this is confusing. Also, do we expect that all operators will have Private Enterprise Number?

Maybe you want to redefine this with something such as (I trust you on the right wording)

  Operator PEN ID

      SMI Network Management Private Enterprise
      Code of the IANA-maintained Private Enterprise Numbers registry
      [SMI] for the operator running ... [actually running what, that's another
      required clarification in the draft] ... the respective interface on mobile access gateway?

In section 3.1.3 (and some other places such as IANA), change "Vendor ID" by "Operator PEN ID"

And also add a few sentences about
- whether all operators should or must now register new PENs for this spec.
  I checked for a couple of my local ISPs, and not all of them had a PEN.
- if there is no PEN Operator ID, then ANI type= 3, Op-ID=2 MUST NOT/SHOULD NOT be used
    if "SHOULD NOT", what should be default?
    Operator PEN ID=8653? (not even sure if this is the right thing to do) or 0?
    You want to discuss with the authors of draft-liang-iana-pen-00, be in synch with them.

- Part of the OPS-DIR review, this one was reported by Juergen Quittek:
Section 3.1.1, description of ANI Length:
ANI Length: The description states
  "The value can be in the range of 2 to 32 octets."
I think this is wrong. A value of 2 would only include
the E-bit, the reserved field and a (zero valued) Net-Name-Len
field.  The description implies that a (zero-valued) AP-Name Length
Field is also mandatory. Then you need at least 3 octets, not just 2.

[Ballot comment]
- I was wondering about the relationship between the Access Technology Type option and this new Access Network Identifier option. Both of the required at the same time? I finally discovered the answer in RFC5213: the Access Technology Type is mandatory. That would help to stress this in the document, just in case the readers are not that familiar with RFC5213 (like myself)

-OLD:
  The
  Access Network Identifier mobility option MUST contains one or more
  Access Network Identifier Sub-options.

NEW:
  The
  Access Network Identifier mobility option MUST contain one or more
  Access Network Identifier Sub-options.


- Part of the OPS-DIR review, the following editorial comments were reported by Juergen Quittek:

Section 3.1.1, description of Net-Name length:
Following up on the technical issue above: It is not clear,
if the Network Name may be of length zero.  The description
of the AP-Name Length explicitly states
  "If the access point name is not included, then this length
  MUST be set to a value of zero."
There is no such statement for the Net-Name Length. Please add
A statement, that the Network name MUST NOT be of length zero,
Or add a statement like the cited one from AP-Name length.


Section 3, description of field "Type" under Figure 2:
"(IANA-1)" is highly ambiguous.  Please replace
OLD
  Type:  (IANA-1)
NEW
  It MUST be set to value of (to be defined by IANA),
  indicating that its a Network-Identifier option.


Section 3.1.2, description of N and E flag:
OLD
  N: When the flag (N) is set to a value of (1), it means North, else
      its South
NEW
  N: When the flag (N) is set to a value of (1), it means North, else
      it means South


The same applies accordingly to the E flag.

[Ballot discuss]
( no change - just reformatting to make this easier to read in the tracker )

Can the document provide more clarity on what kinds of things the LMA is expecting to use the information carried by this extension for? Specifically, how is geolocation going to be used? Is there normative text in some other document that constrains what the LMA can do with this information? Could it be used, for instance, for dispatching emergency services?

The document is inconsistent in describing what the location represents. Some sections say it is the location of the MAG. Other sections say it is the location of the network (which is very unclear). The security considerations section says it is the location of the mobile node. What this location represents needs to be very clearly stated.

If the security consideration text is correct, and this location is intended to represent (even as coarsely as which AP a user is attached to) the location of the MN, and thus the MN's user,  then the considerations in RFC6280 do come into play, and the document needs to account for them.

What is the expected relationship/trust model between the APs and the MAGs in Figure 1? Are they required to be part of the same administrative domain? What are the consequences if incorrect data is provided when the information is "dynamically obtained through some of out-of-band means".

The geolocation format proposed in this document doesn't allow specifying details like the coordinate reference system. Was reusing an existing format (such as the geo-uri in RFC5870) considered? Is there a need to express precision or uncertainty?

[Ballot discuss]
Can the document provide more clarity on what kinds of things the LMA is expecting to use
the information carried by this extension for? Specifically, how is geolocation going to
be used? Is there normative text in some other document that constrains what the LMA can
do with this information? Could it be used, for instance, for dispatching emergency services?

The document is inconsistent in describing what the location represents. Some sections say
it is the location of the MAG. Other sections say it is the location of the network (which is very unclear).
The security considerations section says it is the location of the mobile node.
What this location represents needs to be very clearly stated.

If the security consideration text is correct, and this location is intended to represent
(even as coarsely as which AP a user is attached to) the location of the MN, and thus the MN's user,
then the considerations in RFC6280 do come into play, and the document needs to account for them.

What is the expected relationship/trust model between the APs and the MAGs in Figure 1? Are they
required to be part of the same administrative domain? What are the consequences if incorrect
data is provided when the information is "dynamically obtained through some of out-of-band means".

The geolocation format proposed in this document doesn't allow specifying details like the coordinate
reference system. Was reusing an existing format (such as the geo-uri in RFC5870) considered?
Is there a need to express precision or uncertainty?

[Ballot comment]
This is a not-quite-Discuss Comment

I think a number of references listed as Informative need to be moved
to Normative. Specifically:

SMI
RFC 3629
RFC 1035
RFC 6275

I am in two mindsabout RFC2460.

Happy to discuss why/whether this would be appropriate, but it looks
like the uses are explicit "do encode this thing you need to read this
reference" type of statements.

[Ballot discuss]
I have a concern about tying the interpretation of the "Network Name"
field in the Network-Identifier Sub-option to the Access Technology
type in the Access Technology Type option.  Why not put a "Network
Name Type" field - there's a handy set of Reserved bits available -
that explicitly identifies the type of the Network Name?

Without a "Network Name Type" field, the definition of a new Access
Technology type will have to include the definition of the
interpretation of the "Network Name" field.

[Ballot discuss]
3.1.1

  'E'-bit:  1-bit flag for representing the encoding of the following
      name field.  MUST be set to zero (0) if the network name is
      encoded using 8-bit octets or to one (1) if the network name is
      encoded using UTF-8 [RFC3629].

So, I want to understand the semantics of the below network name field if the 'E'-bit is 0. What does it mean to be 8-bit octets that are not UTF-8? What is it then? And I'm not sure this is even correct, since further down in the definition of Network Name you say, "Encoding MUST be UTF-8." Something is funky here. Please explain.

(BTW: RFC3629 is a normative reference, not informative. Please correct that in section 9. I think there are probably several things you've got in the wrong place.)

  Net-Name Length:  8-bit field for representing the length of the
      network name to be followed.

I think you want to specifically say "in octets", since if it's UTF-8, characters is probably *not* what you mean.

3.1.3

      2 -  Realm of the operator.  Realm names are required to be
        unique, and are piggybacked on the administration of the DNS
        namespace.  Realms are encoded using a domain name encoding
        defined in [RFC1035].

  Operator Identifier:  Up to 253 octets of the operator identifier.
      The encoding of the identifier depends on the used Operator-ID
      Type.  Numeric values are encoded in network byte order and
      strings are in UTF-8 representation and have no terminating '\0'
      mark.

So the first part above says that the domain names are encoded to RFC 1035. Are you talking there about the letter-digit-hyphen rules of 2.3.1 of 1035? If so, you should say that. However, if that's what you mean, then clearly those are all US-ASCII. The second part says that "strings are in UTF-8 representation". Now I'm confused. Are you intending to allow things outside of US-ASCII, e.g. unencoded UTF-8 U-labels for IDNs? Something is not right about the above. I also have no idea why you have the note about the terminating '\0'. Please explain.

Now, all that said, I'm a bit worried about the lack of information on how to compare these things that appears in section 4. Comparing network names you seem to leave to DHCP, but others you don't talk about. If you have to compare these things, are you going to (and do you have to) deal with comparing UTF-8 strings which have different normalizations? Perhaps the answer is "no" and these are not things that need to compare if one contains "latin small 'o' followed by combining diaeresis" and the other contains "latin small 'o' with diaeresis". But if these two *do* have to compare as identical, you're going to need to say more about how those comparisons (and normalizations) happen.

[Ballot discuss]
-The term "vendor" is confusing

  Vendor ID

      The Vendor ID is the SMI Network Management Private Enterprise
      Code of the IANA-maintained Private Enterprise Numbers registry
      [SMI].

The example in figure 1 speaks about: "Operator-Id: provider2.example.com"
Vendor Id, in the network management world is the manufacturer id, while you're after the Operator-Id
I see what you want to do, but this is confusing. Also, do we expect that all operators will have Private Enterprise Number?

Maybe you want to redefine this with something such as (I trust you on the right wording)

  Operator PEN ID

      SMI Network Management Private Enterprise
      Code of the IANA-maintained Private Enterprise Numbers registry
      [SMI] for the operator running ... [actually running what, that's another
      required clarification in the draft] ... the respective interface on mobile access gateway?

In section 3.1.3 (and some other places such as IANA), change "Vendor ID" by "Operator PEN ID"

And also add a few sentences about
- whether all operators should or must now register new PENs for this spec.
  I checked for a couple of my local ISPs, and not all of them had a PEN.
- if there is no PEN Operator ID, then ANI type= 3, Op-ID=2 MUST NOT/SHOULD NOT be used
    if "SHOULD NOT", what should be default?
    Operator PEN ID=8653? (not even sure if this is the right thing to do) or 0?
    You want to discuss with the authors of draft-liang-iana-pen-00, be in synch with them.

[Ballot comment]
- I was wondering about the relationship between the Access Technology Type option and this new Access Network Identifier option. Both of the required at the same time? I finally discovered the answer in RFC5213: the Access Technology Type is mandatory. That would help to stress this in the document, just in case the readers are not that familiar with RFC5213 (like myself)

-OLD:
  The
  Access Network Identifier mobility option MUST contains one or more
  Access Network Identifier Sub-options.

NEW:
  The
  Access Network Identifier mobility option MUST contain one or more
  Access Network Identifier Sub-options.

[Ballot discuss]

(1) Why doesn't this use geopriv?

(2) Why is it ok to send the MN location (3.1.2) without asking
the user?

(3) Why is it ok to send SSID and AP name  without asking the
user?  Many of those are pretty revealing as to MN location.

(4) I looked at 6275 and 5213 and its not clear to me that
these sensitive values, if sent, MUST be protected using IPsec
with strong confidentiality and mutual authentication. The
authentication part may be ok according to the documents, but
I'm not sure if that's the deployed reality. Is it? But even if
so, there's nothing much that I can see to ensure
confidentiality for this information. Where's all that
(clearly) specified?

[Ballot comment]
IANA Considerations rant:

  o  Action-1: This specification defines a new Mobility Header option,
      the Access Network Identifier.  This mobility option is described
      in Section 3.  The Type value for this option needs to be assigned
      from the same numbering space as allocated for the other mobility
      options, as defined in [RFC6275].

I noticed the same problem that confused IANA, and was going to kick in a DISCUSS to get it fixed: the registry is called "Mobility Options", and referring to it as a "Mobility Header option" confused it with the "Mobility Header Types" registry.  No need for the DISCUSS, though, because the author noticed the error in Pearl's proposed IANA actions, and sorted it out by email.

So this comment will just serve to beat people up about this, and to rant a bit.  You can otherwise ignore it:
Folks, it's just not that hard to go to http://www.iana.org/protocols/ and actually *look up* the correct name of the registry you aim to use... and then to use the *exact* name.  Please be specific and accurate; it's important.

IESG:

IANA has reviewed draft-ietf-netext-access-network-option-10 and has
the following comments:

IANA understands that, upon approval of this document, there are
three actions which IANA must complete.

First, a new Mobility Header Type - for the MH Type field in the Mobility Header
will be registered. The new registration will take place in the Mobility Header
Type subregistry of the Mobile IPv6 parameters registry located at:

http://www.iana.org/assignments/mobility-parameters/mobility-parameters.xml

as follows:

Value: [ tbd ]
Description: Access Network Identifier
Reference: [ RFC-to-be ]

Second, IANA is to create a new subregistry of the Mobile IPv6 parameters
registry located at:

http://www.iana.org/assignments/mobility-parameters/mobility-parameters.xml

The new registry will be called the "Access Network Information (ANI)
sub-option" registry. Management of the new subregistry will be through
Expert Review. The reference for the new sub-registry is [ RFC-to-be ].
There are initial values for the registry as follows:

ANI
Sub-option Description Reference
-----------+------------------------------------------+--------------
0 Reserved [ RFC-to-be ]
1 Network-Identifier Sub-option [ RFC-to-be ]
2 Geo-Location Sub-option [ RFC-to-be ]
3 Operator-Identifier Sub-option [ RFC-to-be ]

Third, IANA is to create a new subregistry of the Mobile IPv6 parameters
registry located at:

http://www.iana.org/assignments/mobility-parameters/mobility-parameters.xml

This new registry will be called the "Operator-Identifier Sub-Option of the
Access Network Identifier"

Management of the new subregistry will be through Expert Review.
The reference for the new sub-registry is [ RFC-to-be ]. There are
initial values for the registry as follows:

Operator
Identifier
Sub-Option Description Reference
------------+--------------------------------------------+--------------
0 Reserved [ RFC-to-be ]
1 Vendor ID as four octet Private Enterprise [ RFC-to-be ]
Number
2 Realm of the Operator [ RFC-to-be ]

IANA understands that these are the only actions required upon approval
of the document.

Note: The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.

State changed to In Last Call from Last Call Requested

The following Last Call Announcement was sent out:

From: The IESG

To: IETF-Announce

CC:

Reply-To: ietf@ietf.org

Subject: Last Call:  (Access Network Identifier (ANI) Option for Proxy Mobile IPv6) to Proposed Standard





The IESG has received a request from the Network-Based Mobility

Extensions WG (netext) to consider the following document:

- 'Access Network Identifier (ANI) Option for Proxy Mobile IPv6'

  as a Proposed Standard



The IESG plans to make a decision in the next few weeks, and solicits

final comments on this action. Please send substantive comments to the

ietf@ietf.org mailing lists by 2012-05-09. Exceptionally, comments may be

sent to iesg@ietf.org instead. In either case, please retain the

beginning of the Subject line to allow automated sorting.



Abstract





  The local mobility anchor in a Proxy Mobile IPv6 domain is able to

  provide access network and access operator specific handling or

  policing of the mobile node traffic using information about the

  access network to which the mobile node is attached.  This

  specification defines a mechanism and a related mobility option for

  carrying the access network identifier and the access operator

  identification information from the mobile access gateway to the

  local mobility anchor over Proxy Mobile IPv6.









The file can be obtained via

http://datatracker.ietf.org/doc/draft-ietf-netext-access-network-option/



IESG discussion can be tracked via

http://datatracker.ietf.org/doc/draft-ietf-netext-access-network-option/ballot/





No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why
is this the proper type of RFC? Is this type of RFC indicated in the
title page header?

Proposed Standard

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

The local mobility anchor in a Proxy Mobile IPv6 domain is able to
provide access network and access operator specific handling or
policing of the mobile node traffic using information about the
access network to which the mobile node is attached. This
specification defines a mechanism and a related mobility option for
carrying the access network identifier and the access operator
identification information from the mobile access gateway to the
local mobility anchor using proxy mobile IPv6 signaling messages.

Working Group Summary

The I-D has followed normal IETF WG process and has consensus
regarding the proposed extension to Proxy Mobile IPv6. There have
been no controversies or opposition to this proposal.

Document Quality

No known or announced implementations of the protocol exist. However
there may be unannounced implementations in progress. Multiple
vendors have indicated interest in implementing these extensions in
their products.
The I-D has undergone multiple reviews and they have been
acknowledged in the document itself.

Personnel

Who is the Document Shepherd? Who is the Responsible Area
Director?

Document shepherd: Basavaraj Patil
Responsible AD: Brian Haberman

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

I have reviewed multiple versions of the I-D and have suggested
changes to the text which have been incorporated. Questions about
security (specifically provady) also have been addressed
satisfactorily. Hence I believe the I-D is ready to be forwarded to
the IESG.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No concerns. I am satisfied with the number as well as depth and
breadth of the reviews.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

I do not believe there is a need for a broader review or review by
specific experts from the area of security or internationalization
etc.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

I have no concerns with this document and additionally do not believe
that WG members have any concerns either.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Each of the author has confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR disclosure that references this I-D has been filed.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

There is sufficient WG consensus behind this document. As has been the
norm a few core contributors in the WG are supportive of the I-D and
approve of it while the majority are silent. However I do believe that
the WG as a whole understands this I-D and the proposed extensions.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No threats of an appeal have been raised or for that matter extreme
discontent with this I-D.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

The idnits tool does not raise any flags or problems with this I-D.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

This I-D does not specify a MIB, media type or URI type.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

All normative references are published RFCs.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

Publication of this document does not affect any existing RFCs. This
I-D specifies an extension to Proxy MIP6 signaling and does not change
the status of any other published RFC.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC
5226).

I have reviewed the IANA section and believe that sufficient
and appropriate information w.r.t the proposed extensions, and the
actions needed by IANA have been specified.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No new registry is proposed by this I-D.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

This I-D does not include any XML code, BNF rules or MIB definitions
which would require an automated check and review.

Hello,

This is the working group last call for the I-D:
Access Network Identifier (ANI) Option for Proxy Mobile IPv6


The I-D has been updated by the authors following multiple reviews
that have been posted on the mailing list.

Abstract:

  This specification defines a mechanism and a related mobility option
  for carrying the access network identifier and the access operator
  identification information from the mobile access gateway to the
  local mobility anchor over Proxy Mobile IPv6.  Based on the received
  information, the local mobility anchor is able to provide access
  network and access operator specific handling or policing for the
  mobile node traffic.

The I-D is intended for publication as a proposed standard.
The deadline for receiving comments (i.e end of WG LC) is March 2nd,
2012.
Please send your review comments to the mailing list or authors.

-Chairs