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

["Alper Yegin" <alper.yegin at yegin.org>]

Moving away from defining our own service provider identification is a good thing.
But, relying on another spec (dependency) for the formatting is not a good thing.
Replicating the formatting and than maintaining it in the pana spec is not that good either.

Any suggestions?

Alper


> -----Original Message-----
> From: Yoshihiro Ohba [mailto:yohba at tari.toshiba.com]
> Sent: Wednesday, October 11, 2006 9:46 PM
> To: MORAND Lionel RD-CORE-ISS
> Cc: Yoshihiro Ohba; pana at ietf.org
> Subject: Re: [Pana] ISP-Information and NAP-Information AVPs
> 
> Hi Lionel,
> 
> On Wed, Oct 11, 2006 at 08:29:50PM +0200, MORAND Lionel RD-CORE-ISS wrote:
> > 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".
> 
> Yes, your suggested way would work better, probably with additinal
> text stating that the format, value and semantics of the field is the
> same as that is defined for the RADIUS Operator-Name attribute value.
> 
> Yoshihiro Ohba
> 
> 
> >
> > Lionel
> >
> > > -----Message d'origine-----
> > > De : Yoshihiro Ohba [mailto:yohba at tari.toshiba.com]
> > > EnvoyéP : 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


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