Subject: [apps-discuss] APPSDIR review of draft-ietf-netext-access-network-option-10

From: Yoshiro YONEYA <[email-masked]>
Date: Fri, 11 May 2012 19:17:14 +0900

I have been selected as the Applications Area Directorate reviewer for
this draft (for background on appsdir, please see
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).

Please resolve these comments along with any other Last Call comments
you may receive.  Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-netext-access-network-option-10
Title: Access Network Identifier (ANI) Option for Proxy Mobile IPv6
Reviewer: Yoshiro Yoneya
Review Date: 11 May 2012
IETF Last Call Date: (unknown)
IESG Telechat Date: (unknown)
Summary: This draft is almost ready for publication as an Standards Track
         RFC but has a few issues that should be fixed before publication.

Major Issues:

  [NONE]

Minor Issues:

  Section 3.1.1 [Page 7]
    "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]."
    => 8-bit octets is ambiguous. UTF-8 is also 8-bit octets. Clear 
       distinction between 8-bit octets and UTF-8 is recommended.

  Section 3.1.2 [Page 8]
    "Longitude Degrees:  MUST be a value between 0 to 90;"
    => MUST be a value between 0 to 180?

  Section 3.1.3 [Page 10]
    "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."
    => What is the intention of UTF-8? To accommodate IDN? If so, using 
       the term U-label defined in RFC 5891 is much preferrable.

Nits:

  [NONE]

-- 
Yoshiro YONEYA <[email-masked]>

---

From: jouni korhonen <[email-masked]>
Date: Fri, 11 May 2012 14:01:44 +0300

Hi Yoshiro,

Thank you for the review. See my comments inline:

>       distinction between 8-bit octets and UTF-8 is recommended.

8-bit octets is supposed to be just an opaque blob, where as UTF-8
itself contain rules how to interpret the sequence of octets. We could
say:

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

>    => MUST be a value between 0 to 180?

Ack.

>       the term U-label defined in RFC 5891 is much preferrable.

Although the typical use of the operator name is a realm or a domain name,
I think we should leave that kind of conversion to the final consumers of the
operator identifier value, since PMIP6 protocol itself has nothing to do with
the content of this option value. Since we do not even have any uniqueness
requirements on the identifier, we have not even proposed normalizations
for the value.

- Jouni

---

From: John C Klensin <[email-masked]>
Date: Sat, 12 May 2012 06:17:32 -0400

--On Friday, May 11, 2012 14:01 +0300 jouni korhonen
<[email-masked]> wrote:

>> Minor Issues:
>> 
>>  Section 3.1.1 [Page 7]
>>    "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]."
>>    => 8-bit octets is ambiguous. UTF-8 is also 8-bit octets.
>>    Clear  distinction between 8-bit octets and UTF-8 is
>>       recommended.
> 
> 8-bit octets is supposed to be just an opaque blob, where as
> UTF-8 itself contain rules how to interpret the sequence of
> octets. We could say:
> 
>    "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]."

Let me take this one step further.  From a quick look at the
draft, that field appears to be something that is likely to be
compared with others, not just printed out of otherwise used in
a strictly informative way.  Because of matching/comparison
issues, the authors should carefully examine the discussion in
RFC 5198 and/or draft-iab-identifier-comparison and then adjust
this requirement so it doesn't assume that "encoding using UTF-8
[RFC3629]" is a sufficient statement from which one can them
move on.

I also wonder whether the has examined the question of whether
an ANI is actually an element requiring internationalization or
whether it is actually a protocol element with the provision for
UTF-8 included only because it is the "new ASCII" / "new ISO 646
BV".

IESG: We have supposedly had a policy requiring an
"Internationalization Considerations" requirement since early
1998 and Section 6 of RFC 2277.  I generally don't like such
requirements and am glad it hasn't turned into another cause of
RFC bloat.  I am coming to believe that a number of illustrative
bad experiences in recent years, the RFC 5198 effort, the need
to revise IDNA to the 2008 version, developments in PRECIS, and
the IAB comparison work suggest that any document that
references "UTF-8 [RFC3629]" should be flagged as probably
requiring such a section (or an explanation in a Shepherd's
report or equivalent) unless it is specifically i18n-related.
IMO, we will do ourselves and the community a disservice by
simply letting people insert "UTF-8" where they used to insert
"ASCII" and by letting such documents go through without
addressing the "protocol identifier or i18n element" and "do
Unicode strings need to be restricted and in what ways"
questions.

   john

---

From: John C Klensin <[email-masked]>
Date: Mon, 14 May 2012 18:31:36 -0400

Jouni,

Entirely reasonable explanation, thanks.  One observation inline
below.

--On Tuesday, May 15, 2012 01:16 +0300 jouni korhonen
<[email-masked]> wrote:

>...
> We are/were aware of the comparison issues regarding UTF-8
> strings.

>> an ANI is actually an element requiring internationalization
>> or whether it is actually a protocol element with the
>> provision for UTF-8 included only because it is the "new
>> ASCII" / "new ISO 646 BV".
> 
> In past we have defined the normalization forms to be used with
> specific PMIPv6 options that carry UTF-8 and needed to be aware
> of internationalized names.
> 
> For this case regarding ANI, we came to conclusion (so far)
> that it is not for this specification to say anything about
> internationalization or comparisons of the network name(s).
> The sole reason why UTF-8 possibility was added here is the
> compliancy to the latest IEEE 802.11-2012 definition of SSID,
> which added a flag to indicate the SSID is actually an UTF-8
> string. And that is all what 802.11-2012 says about it. So I
> would hesitate to go further than IEEE did. In practice the
> network name is just copied verbatim from the access technology
> and conveyed to the backend system using ANI as a container.
> The configuration of the network name has to match literally
> in the access network and the LMA regardless the name is an
> octet blob or UTF-8. The PMIPv6 system does not care, just
> does an octet wise comparison. Network names in two different
> core network elements under the same management are supposed
> to be something that can be configured correctly.

At least superficially, this appears to be a reasonable answer.
Not second-guessing IEEE 802.11-2012 seems wise too.   I do
wonder about one possible problem, noting that we might possibly
know more that IEEE 802 (or a least have a head start on
accumulating nasty scars).  If someone sets up a network with an
SSID that equals a wildly unnormalized string in UTF-8 (or maybe
one that is normalized to NFD) a potential user of that system
is running on a system that normalizes everything to NFC at the
time strings are keyed in or in the interfaces to all of the
API, then "copied verbatim" could easily turn out to be a big
problem.  I would think that issue should at least be mentioned,
e.g., as a Security Consideration, even though most of the
failure scenarios I can imagine are safe ones (rather than,
e.g., someone getting access to an undesired network).

Just a thought though, not anything I'd try to insist on if you
conclude it is unnecessary.

> We would not need the UTF-8 knowledge at all but there is a
> chance that we need to convey the network name further to
> other management functions like AAA where it would be
> desirable to be able to tell the configuration of the access
> network (the coding of the SSID, for example). The issues
> really show up when an user enters the network name (e.g.
> SSID) manually instead of using the normal mobile side
> dialer/network manager. However, in this case the mobile would
> not even be able to associate/attach to the network and cause
> PMIPv6 signaling.

Yes, exactly.  See above and remember that all that is required
for a user to have to type in the SSID is that the network
operator decides to hide the thing... which some folks still
think is a good idea from a security standpoint even though we
pretty much know better.

best,
   john

---

From: jouni korhonen <[email-masked]>
Date: Tue, 15 May 2012 01:16:13 +0300

John,

> [RFC3629]" is a sufficient statement from which one can them

We are/were aware of the comparison issues regarding UTF-8 strings.

For this case regarding ANI, we came to conclusion (so far) that it
is not for this specification to say anything about internationalization
or comparisons of the network name(s). The sole reason why UTF-8
possibility was added here is the compliancy to the latest IEEE 802.11-2012
definition of SSID, which added a flag to indicate the SSID is
actually an UTF-8 string. And that is all what 802.11-2012 says
about it. So I would hesitate to go further than IEEE did. In practice
the network name is just copied verbatim from the access technology
and conveyed to the backend system using ANI as a container. The
configuration of the network name has to match literally in the access
network and the LMA regardless the name is an octet blob or UTF-8.
The PMIPv6 system does not care, just does an octet wise comparison.
Network names in two different core network elements under the same
management are supposed to be something that can be configured
correctly.

We would not need the UTF-8 knowledge at all but there is a chance
that we need to convey the network name further to other management
functions like AAA where it would be desirable to be able to tell the
configuration of the access network (the coding of the SSID, for
example). The issues really show up when an user enters the network
name (e.g. SSID) manually instead of using the normal mobile side
dialer/network manager. However, in this case the mobile would not
even be able to associate/attach to the network and cause PMIPv6
signaling.

- Jouni