[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
WGLC comments for draft-ietf-geopriv-radius-lo-07
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:
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
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
[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:
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).
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),
3) Yet another comment about Section 5.1:
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).
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
 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"
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
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
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  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.
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.