WGLC comments for draft-ietf-geopriv-radius-lo-07

[<Pasi.Eronen@nokia.com>]

This document has been around for a long time, and we really should
get it out. I think there are some parts of the document that are
unnecessarily complex and/or inelegant, but I understand that they're
a result of a long process of making the document acceptable to
various constituencies. Since my objections would be of the "it could
be nicer" type rather than "it doesn't work", I won't complain them
now. Let's get this out; it's good enough.

I do have a couple of minor and mostly editorial comments, though:

1) Section 5.1 says:

   "GSM (0):

   This namespace can be used to indicate operator names based on
   GSMA TADIG codes.  The TADIG Working Group within the GSM
   Association is the authority responsible for issuing unique
   Operator-Name values of this type."

The GSM system uses many different codes to identify operators in
different contexts; thus, this probably should be called "GSM_TADIG"
or just "TADIG". Also, we need a reference (any kind of reference is
better than none), expand the acronym, and specify how the value is
encoded.

Suggested text:

   TADIG (0):
   
   This namespace can be used to indicate operator names based on
   Transferred Account Data Interchange Group (TADIG) codes defined in
   [NNN]. TADIG codes are assigned by the TADIG Working Group within
   the GSM Association. The TADIG code consists of five uppercase
   ASCII characters.

   [NNN] GSM Association, "TADIG Naming Conventions, Version 4.1", 
   GSM Association Official Document TD.13, June 2006.

(The document is not currently on the GSMA web site, but it is
classified "Unrestricted". I talked with Jouni Korhonen about this and
he promised to find out if it could be made more easily available.)


2) Another comment about Section 5.1:

   "CDMA (1):

   The CDMA operator namespace can be used to indicate operator names
   based on the Home Network Identifier (HNI).  The HNI is the
   concatenation of the 3-digit Mobile Country Code (MCC) and 3-digit
   Mobile Network Code (MNC).  The IMSI Oversight Council (IOC) is the
   authority responsible for issuing unique Operator-Name values for
   operators of this type."

No no no... the Mobile Country Code (MCC) and Mobile Network Code
(MNC) are defined in E.212, and ITU-T is the authority for MCCs.  IMSI
Oversight Council is the national authority for assigning MNCs within
the US country codes; other countries have their own authorities.  The
E.212 numbering and MCC/MNC are not specific to CDMA; GSM, UMTS and
other systems use them as well. And the text needs to say how they're
encoded in the field (as many protocols use something weird such as
BCD for MCC/MNC).

Suggested rephrasing:

   E212 (1):
 
   The E212 namespace can be used to indicate operator names based on
   the Mobile Country Code (MCC) and Mobile Network Code (MNC) defined
   in [NNN]. The MCC/MCC values are assigned by the Telecommunications
   Standardization Bureau (TSB) within the ITU-T and designated
   administrators in different countries. The E212 value consists of
   three ASCII digits containing the MCC, followed by two or three
   ASCII digits containing the MNC.

   [NNN] ITU-T, "The international identification plan for mobile
   terminals and mobile users", ITU-T Recommendation E.212 (05/2004),
   May 2004.


3) Yet another comment about Section 5.1:

   "ITU (3):

   The ITU operator namespace can be used to indicate operator names
   based on ITU Carrier codes.  The Telecommunication Standardization
   Bureau (TSB) within the ITU-T is the authority responsible for the
   repository.  Each national regulatory authority is responsible for
   issuing unique Operator-Name values for operators of this type."

This is really badly named, because ITU is the authority for so many
different namespaces. There's no reference (M.1400). And because ICC
is unique only within a country, M.1400 uses them together with a
country code (the three-letter alphanumeric code from ISO 3166).

Suggested rephrasing:

   ICC (3):

   The ICC namespace can be used to indicate operator names based on
   ITU Carrier Codes (ICC) defined in [NNN]. ICC values are assigned
   by national regulatory authorities and are coordinated by the
   Telecommunication Standardization Bureau (TSB) within the ITU-T.
   When using the ICC namespace, the attribute consists of three
   uppercase ASCII characters containing a three-letter alphabetic
   country code as defined in [MMM], followed by one to six uppercase
   alphanumeric ASCII characters containing the ICC itself.
 
   [NNN] ITU-T, "Designations for interconnections among operators'
   networks", ITU-T Recommendation M.1400 (01/2004), 2004.
 
   [MMM] ISO, "Codes for the representation of names of countries and
   their subdivisions - Part 1: Country codes", ISO 3166-1:1997.


4) Section 5.3: "The format of the data is described in Section 3.1 of
[4] whereby the first 8 bits (i.e., the code for this DHCP option) are
not included." Hmm... shouldn't we also skip the length and "what"
fields?


5) Section 5.4: "The RFC 3825 Location Configuration Information (LCI)
format defined in Section 2 of RFC 3825 starting with bit 17 (i.e.,
the code for the DHCP option and the length field is not included.)."

RFC 3825 Section 2 numbers bits from 0, so it's really "starting with
bit 16". But "starting with the third octet (i.e. [...])" would be
less ambiguous.


6) Section 5.5 says that

   "The Basic-Policy-Rules attribute MUST be sent in an Access-Accept,
   an Access-Challenge, an Access-Request, an Access-Reject and an
   Accounting-Request message if location information is transmitted
   with this exchange.  If authorization policy rules are available to
   the RADIUS client then the Access-Request MUST carry the Basic-
   Policy-Rules attribute to to the RADIUS server."

This paragraph is very difficult to understand; I'd suggest some
rephrasing (almost the same text appears also in Section 5.6, and
equally unclear).


7) Section 5.6 says "The full ruleset SHOULD be fetched using
Transport Layer Security (TLS)."  Is this trying to say that "The 
URI SHOULD use the "https" scheme?" or something else?


8) Section 5.7: "The Value field is four octets.  Every bit of the two
octets MUST be set to 0." What about the other two of the four octets?
:)


9) Section 5.8: "The Value field is at least 8 octets in length"
Not "at least", since the total attribute length is exactly 10, 
not at least 10.


10) Section 6, the second table suggests that "Location-Info-Required"
is an attribute; isn't it an Error-Cause value?


11) Section 7: Hmm... I wonder if the AVP Flag rules are really
right. For example, is it really necessary to set the "M" bit for
Challenge-Capable? If the NAS is upgraded before the AAA server, the M
bit would cause the AAA server to reject the request (and the NAS has
to re-send the request without this AVP); but in this case, perhaps
just ignoring the AVP might be a better idea? Other attributes
are less clear; at least Operator-Name looks reasonably safe to 
ignore (suggesting that maybe the "M" bit should be in MAY column);
the location information/policies are less clear.

(Although I'm not sure if the word "clear" can really apply to any 
text about Diameter mandatory AVPs :-)


12) Section 8.3, req 1: "The same civic location information format is
used in PIDF-LO [16] and this document." It looks similar, but it's
not exactly the same format, right?


13) Section 11.1: "new values to the Operator-Namespaces will be
assigned after Expert Review by the Geopriv working group or its
designated successor." According to RFC 2434, "Expert Review" means
review by a designated expert, and that's a person (appointed by the
AD), not a working group. But maybe the intent was to say that the
designated expert should consult the Geopriv WG?  Same applies to
Section 11.2 as well.


Best regards,
Pasi

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>