RE: [Pana] ISP-Information and NAP-Information AVPs

["MORAND Lionel RD-CORE-ISS" <lionel.morand at orange-ft.com>]

Hi Yoshi,

Being involved in the definition of this attribute, i would be of course in favor to re-use le format defined in the geopriv-radius-lo draft ;)

But is it possible to say that a PANA AVP contains a RADIUS attribute value?
If not, another way to do it could be to define our own PANA AVPs based on the same RADIUS attribute format and to refer to the IANA registry defined for "Operator type".

Lionel

> -----Message d'origine-----
> De : Yoshihiro Ohba [mailto:yohba at tari.toshiba.com] 
> Envoyé : mercredi 11 octobre 2006 15:10
> À : pana at ietf.org
> Objet : [Pana] ISP-Information and NAP-Information AVPs
> 
> Hi,
> 
> In the current PANA specification, ISP-Information and 
> NAP-Information AVPs are defined as follows:
> 
>    ISP-Information ::= < AVP Header: 7 >
>                     0*1 { Provider-Identifier }
>                         { Provider-Name }
>                      *  [ AVP ]
> 
>    NAP-Information ::= < AVP Header: 9 >
>                     0*1 { Provider-Identifier }
>                         { Provider-Name }
>                      *  [ AVP ]
> 
>    where:
> 
>    The Provider-Identifier AVP (AVP Code 14) is of type 
> Unsigned32, and
>    contains an IANA assigned "SMI Network Management Private 
> Enterprise
>    Codes" [ianaweb] value, encoded in network byte order.
> 
>    The Provider-Name AVP (AVP Code 15) is of type UTF8String, and
>    contains the UTF8-encoded name of the provider.
> 
> The above format was developed before geopriv WG started the 
> work of draft-ietf-geopriv-radius-lo which defines RADIUS 
> attribute named Operator-Name to serve as operator identifier.
> 
> I believe use of this RADIUS attribute format is more appropriate for
> NAP- and ISP-Information AVPs in PANA than what is defined in
> pana-pana-12 because the attribute supports multiple operator 
> namespaces.  Note that IEEE 802.21 WG also adopted this 
> RADIUS attribute format for operator identifier in their 
> speficication.
> 
> A RADIUS Operator-Name attribute value consists of 1-octet 
> operator Namespace ID and variable-length Operator-Name:
> 
>       0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      | Namespace ID  | Operator-Name                          
>       ...
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      | Operator-Name                                          
>       ...
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>      Namespace ID:
> 
>        The value within this field contains the
>        operator namespace identifier. The Namespace ID value
>        is encoded as an 8-bit unsigned integer value.
> 
>        Example: 1 for REALM
> 
>      Operator-Name:
> 
>        The text field of variable length contains an
>        Access Network Operator Name.
>        This field is a RADIUS base data type of Text.
> 
>        Example: anyisp.example.com
> 
> The following is the list of Namespace ID values currently in
> draft-ietf-geopriv-radius-lo:
> 
>    TADIG (0):
> 
>       This namespace can be used to indicate operator names based on
>       Transferred Account Data Interchange Group (TADIG) codes defined
>       in [13].  TADIG codes are assigned by the TADIG Working Group
>       within the GSM Association.  The TADIG Code consists of two
>       fields, with a total length of five ASCII characters 
> consisting of
>       a three-character country code and a two-character aplhanumeric
>       operator (or company) ID.
> 
> 
>    REALM (1):
> 
>       The REALM operator namespace can be used to indicate operator
>       names based on any registered domain name.  Such names are
>       required to be unique and the rights to use a given 
> realm name are
>       obtained coincident with acquiring the rights to use a 
> particular
>       Fully Qualified Domain Name (FQDN).
> 
> 
>    E212 (2):
> 
>       The E212 namespace can be used to indicate operator 
> names based on
>       the Mobile Country Code (MCC) and Mobile Network Code (MNC)
>       defined in [14].  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.
> 
> 
>    ICC (3):
> 
>       The ICC namespace can be used to indicate operator 
> names based on
>       ITU Carrier Codes (ICC) defined in [15].  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 [16], followed by one to six 
> uppercase
>       alphanumeric ASCII characters containing the ICC itself.
> 
> (I think Namespace ID for IEEE 802.16 Operator ID should also 
> be added, but this is not a PANA issue.)
> 
> 
> Suggested changes for PANA specification:
> 
> - Define ISP-Information AVP and NAP-Information AVP as type 
> OctetString where the octetstring data contains a RADIUS 
> Operator-Name attribute value defined in draft-ietf-geopriv-radius-lo.
> 
> - Remove Provider-Identifier AVP and Provider-Name AVP from 
> the speficication.
> 
> 
> Best regards,
> Yoshihiro Ohba
> 
> _______________________________________________
> Pana mailing list
> Pana at ietf.org
> https://www1.ietf.org/mailman/listinfo/pana
> 

_______________________________________________
Pana mailing list
Pana at ietf.org
https://www1.ietf.org/mailman/listinfo/pana