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

From: "MORAND Lionel RD-CORE-ISS" <[email-masked]>
Date: Wed, 11 Oct 2006 20:29:50 +0200

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:[email-masked]] 
> Envoyé : mercredi 11 octobre 2006 15:10
> À : [email-masked]
> 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pana
> 

_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 11 Oct 2006 14:46:09 -0400

Hi Lionel,

> 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

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 12 Oct 2006 00:49:30 +0300

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:[email-masked]]
> Sent: Wednesday, October 11, 2006 9:46 PM
> To: MORAND Lionel RD-CORE-ISS
> Cc: Yoshihiro Ohba; [email-masked]
> Subject: Re: [Pana] ISP-Information and NAP-Information AVPs
> 
> Hi Lionel,
> 
> > 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 ;)
> >
> > 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".
> 
> > > Envoy醇P : mercredi 11 octobre 2006 15:10
> > > 遵 : [email-masked]

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 17 Oct 2006 08:24:40 -0400

> Replicating the formatting and than maintaining it in the pana spec is not that good either.

Can we replicate the formatting, values and semantics in PANA
specification and using the IANA space to be assigned for the RADIUS
operator identifier attribute, with referring geopriv-radius-lo as
Informative reference?

Regards,
Yoshihiro Ohba

> > > > 遵??? : [email-masked]

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 18 Oct 2006 18:00:20 +0300

How about if we remove the network selection part? Not only because of the
concern about dealing with it (see my note below), but also the base spec
can live without it. We can produce a separate I-D on that later.

Comments?

Alper

> > > > But is it possible to say that a PANA AVP contains a RADIUS
> attribute
> > > value?
> > > > >       0                   1                   2
> 3

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 18 Oct 2006 13:22:10 -0400

> can live without it. We can produce a separate I-D on that later.

I can live without network selection in the base specification as long
as we have a separate I-D on it.

If we go that direction, then we may further want to make PSR/PSA
exchange optional in the base specification.  I mean, PSR/PSA is used
only for stateless handshake in the base specification, and is also
used for network selection in the separate I-D.

Yoshihiro Ohba

> > > > > > Envoy碯P : mercredi 11 octobre 2006 15:10
> > > > > > 驟??? : [email-masked]

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 19 Oct 2006 03:32:13 +0300

> used for network selection in the separate I-D.

I'm wondering the benefit of making it optional.

Introducing more optionality adds to complexity. Also, I like PSR/PSA as it indicates an explicit "start" of a PANA session.

Alper

> > > > 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.
> > >
> > > > > 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
> > > > > > If not, another way to do it could be to define our own PANA
> AVPs
> > > based
> > > > > > > I believe use of this RADIUS attribute format is more
> appropriate
> > > for
> > > > > > >       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
> > > > > > >      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +-+-
> > > +-+-+
> > > > > > >      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +-+-
> > > +-+-+
> > > > > > >      | Operator-Name
> > > > > > >       ...
> > > > > > >      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +-+-
> > > +-+-+
> > > > > > >
> > > > > > >      Namespace ID:
> > > > > > >
> > > > > > >       This namespace can be used to indicate operator names
> based
> > > on
> > > > > > >       Telecommunications Standardization Bureau (TSB) within
> the
> > > ITU-T
> > > > > > >       and designated administrators in different countries.
> The
> > > E212
> > > > > > >       by national regulatory authorities and are coordinated
> by
> > > the
> > > > > > >       Telecommunication Standardization Bureau (TSB) within
> the
> > > ITU-T.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 18 Oct 2006 23:34:56 -0400

I agree that making PSR/PSA would not simply the protocol.  I also
agree that using a separate message for the fist exchange and
subsequent exchanges would make sence since the first exchange
provides functionalities (including the indication of "start") that
are not provided by the subsequent exchanges.

Yoshihiro Ohba