Subject: [Dime] Application-id reuse

From: "Jacob Martin" <[email-masked]>
Date: Tue, 9 Sep 2008 13:44:56 +0530

Hi,

    I am a bit confused about the feasibility of one specific configuration
in Diameter.

    Please look at the diagram below:

                                |
                                |
                                |
                                |
   Local Node                   |
                                |        +----+       +-------+
                                |        |NAS |       |  Wm   |
    +--------+   +--------+     |        +----+       +-------+
    |        |   |        |     |            |            ---
    |NASREQ  |   |  Wm    |     |             |        ---
    +----\---+   +---/----+     |             +----- --
          \        //           |         ////      \\\\\
          \      //             |       |/               |
           \   //               |      |        PEER     |
        +---\-/------+          |      |                  |
        |            |          |       |\               |
        |Diameter    |          |         \\\\      /////
        |Base process|          |             ------
        +----+-------+          |             |
             |                  |             |
             |                  |             |
             +------------------+-------------+

   I wish to provide support for two applications on my local node i.e
NASREQ and Wm. As per Wm specifications, Wm should reuse the application
identifier of EAP/NASREQ. So, in CEA, I have advertised '1' and '5' as the
applications supported.

   Assume that peer node also has the same configuration as of mine i.e it
also support Wm and NAS applications.

  Now, peer Wm application issues an AAR. After receiving this AAR, how
could my Diameter base process determine that this AAR is for local Wm
application, but not for local NASREQ application?

  Thanks in anticipation,
  Martin
_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: Sebastien Decugis <[email-masked]>
Date: Tue, 09 Sep 2008 20:02:19 +0900

Hello,

I think the Application Id in the command header will contain the 
appropriate identifier to route the message to the correct handler...

Best regards,
Sebastien.

Jacob Martin a écrit :
>
> Hi,
>  
>     I am a bit confused about the feasibility of one specific 
> configuration in Diameter.
>  
> NASREQ and Wm. As per Wm specifications, Wm should reuse the 
> application identifier of EAP/NASREQ. So, in CEA, I have advertised 
> '1' and '5' as the applications supported.
>  
>    Assume that peer node also has the same configuration as of mine 
> i.e it also support Wm and NAS applications.
>  
>   Now, peer Wm application issues an AAR. After receiving this AAR, 
> how could my Diameter base process determine that this AAR is for 
> local Wm application, but not for local NASREQ application?
>  
>
>   Thanks in anticipation,
>   Martin                             
>                                
>                                
>
> ------------------------------------------------------------------------
>

-- 
Sebastien Decugis
Research fellow
Network Architecture Group
NICT (nict.go.jp)

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 9 Sep 2008 19:02:55 +0300

Hi Jacob,

I assume by Wm you mean the 3GPP TS 29.234 specified Wm interface?
Btw, Wm is not an "application", rather a name of a specific
reference point between two nodes. You can also see it as a
"profile" compliant with NASREQ or EAP.

Anyway, you NAS device, i.e. the PDG knows that it wants to
authorize a certain user to a specific APN and adds required AVPs
to the AAR to accomplish this. The AAA server receiving the AAR
needs to do "further checking" against the message it received. So
it falls back to dictionary type of matching of AVPs. There are
Wm specific AVPs such as 3GPP-WLAN-APN-ID. Once the server finds
one in the AAR it can be sure this is about WM and authorizing the
user to a specific APN. For other possible uses of Wm you need to
do similar checking of AVPs in the received message.

Hope this helps.

Cheers,
	Jouni

On Sep 9, 2008, at 11:14 AM, Jacob Martin wrote:

>    I wish to provide support for two applications on my local node  
> i.e NASREQ and Wm. As per Wm specifications, Wm should reuse the

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 9 Sep 2008 10:02:52 -0700

> appropriate identifier to route the message to the correct handler...

The Application Identifiers are specified to be identical.  What are you
talking about?

> i.e

---

From: Sebastien Decugis <[email-masked]>
Date: Wed, 10 Sep 2008 10:24:40 +0900

> The Application Identifiers are specified to be identical.  What are you
I didn't know what 'Wm' refers to, and since in the original post it was 
specified as " two applications i.e NASREQ and Wm" I assumed the 
application-id would be different...

I guess I was mistaken, sorry!

Sebastien. (still learning about Diameter...)

---

From: "Jacob Martin" <[email-masked]>
Date: Wed, 10 Sep 2008 10:33:02 +0530

Jouni,

> I assume by Wm you mean the 3GPP TS 29.234 specified Wm interface?
Yes, I meant the same
> "profile" compliant with NASREQ or EAP.
Ok.
> do similar checking of AVPs in the received message.
hmm...It makes sense to follow this approach. I would look at the AVPs
which could clearly distinguish Wm/NAS/EAP requests/responses.
Cheers,
Martin

---

From: "Jacob Martin" <[email-masked]>
Date: Fri, 12 Sep 2008 13:03:11 +0530

Jouni,
> do similar checking of AVPs in the received message.

I could identify AAR for Wm by looking at W-APN-ID or Routing Policy
AVPs, but I am not able to find any such AVPs in DER command.

In DER for Wm, "Visited Network Identifier" AVP is a new one, but its
a conditional AVP. If PDG is in WLAN-UE's home network then this AVP
would be absent.

Cheers,
Martin

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 12 Sep 2008 10:36:39 +0300

Hi Jacob, 

Your question addresses different aspects, namely

* How does Diameter routing work in general?  

This is described in Section 6.1 and Section 6.2 of 
http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-12.txt

This should give you an idea how the right node is found and how messages travel back and forth. 

* How does Diameter routing work with a Diameter application like Wm?

This very much depends on how the protocol designers of Wm want it to work. I have to read Wm again to recall the details but based on what you describe it seems that the protocol designers of Wm did not want to create a new Diameter application and hence the additionally specified AVPs are just optional extensions to Diameter EAP and Diameter NASREQ. As such, they should be routed to the respective EAP/NASREQ code and the optional AVPs are interpreted in case that they are understood. 

Ciao
Hannes

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of ext Sebastien Decugis
>Sent: 09 September, 2008 14:02
>To: Jacob Martin
>Cc: [email-masked]
>Subject: Re: [Dime] Application-id reuse
>
>Hello,
>
>I think the Application Id in the command header will contain 
>the appropriate identifier to route the message to the correct 
>handler...
>
>Best regards,
>Sebastien.
>
>Jacob Martin a écrit :
>>
>> Hi,
>>

---

From: <[email-masked]>
Date: Fri, 12 Sep 2008 09:39:39 +0200

Hi Jacob,

> Behalf Of Jacob Martin
> Sent: 12. syyskuuta 2008 10:33
> To: Jouni Korhonen
> Cc: [email-masked]

The Wm uses "two phase" approach. First the EAP is used to authenticate
the WLAN-UE. This is standard EAP application use, except the optional
Visited-Network-Identifier AVP. Here, you just follow what EAP
application
is supposed to do.

During the second phase the NASREQ is used to authorize the WLAN-UE.
And for that case, the earlier dictionary stuff applies.

Cheers,
	Jouni

---

From: "Jacob Martin" <[email-masked]>
Date: Fri, 12 Sep 2008 15:09:09 +0530

Hi Hannes,

   My problem relates to the second question which you have raised i.e
"How does Diameter routing work with a Diameter application like Wm?"

   From the implementor's point of view, it is difficult to keep one
process(Wm) for WLAN activities, and other for traditional EAP/NASREQ
requests(Please look at the diagram in my initial post).

   This problem could be avoided if we have a seperate app-id for Wm.

As per section 1.2.3 of RFC 3588,
=====
  "
    .........it may be desirable to create a new Diameter
   application.  Major changes to an application include:

   -  Adding new AVPs to the command, which have the "M" bit set.
 "
=====

In Wm, protocol designers have added AVPs which have M bit 'on' ex:
3GPP-WLAN-APN-Id, Routing-Policy etc.

Cheers,
Jacob

On 9/12/08, Tschofenig, Hannes (NSN - FI/Espoo)
<[email-masked]> wrote:
> This very much depends on how the protocol designers of Wm want it to work.
> I have to read Wm again to recall the details but based on what you describe
> it seems that the protocol designers of Wm did not want to create a new
> Diameter application and hence the additionally specified AVPs are just
> optional extensions to Diameter EAP and Diameter NASREQ. As such, they
> should be routed to the respective EAP/NASREQ code and the optional AVPs are
> interpreted in case that they are understood.
>
> Ciao
> Hannes
>

---

From: <[email-masked]>
Date: Fri, 12 Sep 2008 11:58:36 +0200

Hi Jacob,

> requests(Please look at the diagram in my initial post).

Dictionaries..

> 3GPP-WLAN-APN-Id, Routing-Policy etc.

These are known deficiencies in TS29.234 and will stay there until
someone makes a CR to fix them. Anyway, the Information Element with
a category 'M' means that the said AVP must be present in the Diameter
message.. thus defining the exact "profile". It does not say anything
about the M-bit setting. See section 10.2 of TS 29.234. You can send
3GPP-WLAN-APN-Id with M-bit unset and still assume the other end
understands the AVP. (you are now entering into a gray area in 3GPP,
which has recently been tried to fix with clear guidelines..)

Cheers,
	Jouni

> > This should give you an idea how the right node is found 
> and how messages
> > travel back and forth.
> >
> >>------------------------------------------------------------
> ----------
> >>> --
> >>>

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 12 Sep 2008 13:27:07 +0300

Hi Jacob,

>> requests(Please look at the diagram in my initial post).
There are many ways todo so from an implementation point of view. 
Typically, you are going to have some business logic at the AAA server. 
Could you be more specific about the problems you see?

> which has recently been tried to fix with clear guidelines..)
I would like to reinforce what Jouni said. If the application designer 
does not want to create new application then all the functionality they 
define has to be optional. If there is mandatory and required 
functionality in the extension then a Diameter application should have 
been defined. This wasn't done in the 3GPP and I hope that someone is 
going to fix it.

Ciao
Hannes

>>> * How does Diameter routing work with a Diameter 
>>>       
>> application like Wm?
>>     
>>> This very much depends on how the protocol designers of Wm 
>>>       
>> want it to work.
>>     
>>> I have to read Wm again to recall the details but based on 
>>>       
>> what you describe
>>     
>>> it seems that the protocol designers of Wm did not want to 
>>>       
>> create a new
>>     
>>> Diameter application and hence the additionally specified 
>>>       
>> AVPs are just
>>     
>>> optional extensions to Diameter EAP and Diameter NASREQ. As 
>>>       
>> such, they
>>     
>>> should be routed to the respective EAP/NASREQ code and the 
>>>       
>> optional AVPs are
>>     
>>>>>    I wish to provide support for two applications on my
>>>>>           
>>>> local node i.e
>>>>         
>>>>> application identifier of EAP/NASREQ. So, in CEA, I have 
>>>>>           
>> advertised
>>     
>>>>>    Assume that peer node also has the same configuration 
>>>>>           
>> as of mine
>>     
>>>>>   Now, peer Wm application issues an AAR. After receiving 
>>>>>           
>> this AAR,
>>

---

From: "Jacob Martin" <[email-masked]>
Date: Fri, 12 Sep 2008 15:59:05 +0530

Jouni,
On 9/12/08, [email-masked]
>> requests(Please look at the diagram in my initial post).
How? If my base Diameter process has received a DER request from peer
for WLAN application, then how could it be routed to Wm application.
Please refer the diagram in my initial post.

> which has recently been tried to fix with clear guidelines..)

I think table 10.1.1 in TS29.234 has the AVP flag details for all the AVPs.

---

From: "Jacob Martin" <[email-masked]>
Date: Fri, 12 Sep 2008 16:08:24 +0530

Hi Hannes,
> Could you be more specific about the problems you see?
I have explained it in my previous post. Please have a look.
> been defined. This wasn't done in the 3GPP and I hope that someone is
This problem has been captured in 3GPP TR 29.909. In section 5.5, it
has few proposals to avoid such problem.

Cheers,
Jacob

---

From: <[email-masked]>
Date: Fri, 12 Sep 2008 12:38:52 +0200

Hi Jacob,

> I think table 10.1.1 in TS29.234 has the AVP flag details for 

Oh yes, correct ;) Anyway, as I said, it is a known deficiency (well
that does not help you though) that no one has bothered to fix.

Cheers,
	Jouni

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 12 Sep 2008 13:52:24 +0300

Hi Jacob,

> Please refer the diagram in my initial post.

I believe the terminology would be rather "... how could it be handed 
over to the Wm application within ."

This is largely an implementation specific issue. You need to enhance 
your existing application logical to handle the additional AVPs that are 
defined on top of EAP/NASREQ.

Does this help?

> I think table 10.1.1 in TS29.234 has the AVP flag details for all the AVPs.
Someone should fix this.

Ciao
Hannes

---

From: "Jacob Martin" <[email-masked]>
Date: Fri, 12 Sep 2008 16:41:05 +0530

Hannes,
> defined on top of EAP/NASREQ.
Anything could be done in software :), but I was just trying to get
the answer for "Why Wm protocol designers did not opt for new app-id
for Wm?"

Cheers,
Jacob

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 12 Sep 2008 14:24:31 +0300

> the answer for "Why Wm protocol designers did not opt for new app-id

Because of the RFC3588 section 1.2.3 statement:

   "Creation of a new application should be viewed as a last resort.  An
    ...
   "

Now that M-bit settings are wrong is just n error in TS29.234

Cheers,
	Jouni

---

From: "Glen Zorn" <[email-masked]>
Date: Sat, 13 Sep 2008 10:57:42 -0700

Jacob Martin [mailto://[email-masked]] writes:

...

> the answer for "Why Wm protocol designers did not opt for new app-id

If that's the question, then pretty obviously asking the wrong people:  Wm
isn't a product of the IETF, let alone this WG.  Take your complainin' to
3GPP ;-)...

...

---

From: "Jacob Martin" <[email-masked]>
Date: Mon, 15 Sep 2008 09:39:29 +0530

Jouni,
>    "Creation of a new application should be viewed as a last resort.  An
Thanks for the pointer. I think Wm designers should have applied for a
new application-id to tackle the kind of scenarios which I had
mentioned in my initial post.
Anyways, I would raise it to the 3gpp people.
> Now that M-bit settings are wrong is just n error in TS29.234
I did not get you on this. could you please explain this again?
>> Jacob
TFYT!
Jacob

---

From: "Jacob Martin" <[email-masked]>
Date: Mon, 15 Sep 2008 09:44:12 +0530

Glen,
> isn't a product of the IETF, let alone this WG.  Take your complainin' to
My initial post had some IETF products in my scenario, so I opted for
this mailing list. I would raise this issue to the 3GPP as well.
Cheers,
Jacob

---

From: Jouni <[email-masked]>
Date: Mon, 15 Sep 2008 07:44:20 +0300

> I did not get you on this. could you please explain this again?
Wm has some new AVPs with M-bit set, as you also pointed out. This goes
against the rule for "when to create a new application" as no new 
application is
created. These are just errors in the current TS 29.234.

Jouni

---

From: "Jacob Martin" <[email-masked]>
Date: Mon, 15 Sep 2008 10:17:52 +0530

> created. These are just errors in the current TS 29.234.
ok... Thanks for the clarification.

---

From: "Sarkar, Biplab" <[email-masked]>
Date: Mon, 15 Sep 2008 10:27:05 +0530

Hi all,

I was thinking of the consequences of allowing AVP's to have the liberty to either set or un-set the M-bit.
The sender may decide to set it depending upon its judgement about the version of the peer. 
- Will this give added help for extendability? 
- Is it really required to mandate the presence of M-bit for AVPs? Won't it be better to allow the sender to decide?

Some comments on this please.

Thanks & Regards,
Biplab

---

From: Ankit Kumar Sharma <[email-masked]>
Date: Mon, 15 Sep 2008 10:50:15 +0530

Hi Biplab,
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sarkar, Biplab
Sent: Monday, September 15, 2008 10:27 AM
To: Jacob Martin; [email-masked]
Cc: [email-masked]
Subject: Re: [Dime] Application-id reuse

Hi all,

< I hope you are referring to section 4.1 of RFC 3588.
" A configuration option may be provided on a system wide, per
         peer, or per realm basis that would allow/prevent particular
         Mandatory AVPs to be sent.  Thus an administrator could change
         the configuration to avoid interoperability problem ">

- Will this give added help for extendability?
<Yes it would add to the extendibility/flexibility>
- Is it really required to mandate the presence of M-bit for AVPs? Won't it be better to allow the sender to decide?

< To define any specification, there should be mandate on some of the basic AVPs which helps in core functioning. For proprietary extensions, vendors are allowed to define custom AVPs to meet their requirements>

Thanks & Regards,
Biplab

-----Original Message-----
From: [email-masked] on behalf of Jacob Martin
Sent: Mon 9/15/2008 10:17 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Dime] Application-id reuse

Thanks,
Ankit

"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error,please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."
_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: srinivas <[email-masked]>
Date: Tue, 16 Sep 2008 15:40:51 +0530

Hi,
Silly doubt.Suppose a Diameter node has received the CER with
inband-security value as 2 then does the node has to respond with
DIAMETER_NO_COMMON_SECURITY (5017) or DIAMETER_INVALID_AVP_VALUE (5004) or
any one is fine.
>From my understanding if the node sends DIAMETER_INVALID_AVP_VALUE (5004)
then the receiver will easily come to know that AVP value is wrong.
Please give your thoughts/comments on the same.

Thanks & Regards, 
Srinivas CH,
Huawei Technologis India Pvt Ltd, 
1st Floor DIamond District, 
Airport Road, Bangalore-8, 
Contact: (Off) 080-41117676 ext: 3008               (Mob) +919731316362.
 
This e-mail and attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed
above. Any use of the information contained herein in any way (including,
but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ankit Kumar Sharma
Sent: Monday, September 15, 2008 10:50 AM
To: Sarkar, Biplab; Jacob Martin; [email-masked]
Cc: [email-masked]
Subject: Re: [Dime] Application-id reuse

Hi Biplab,
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Sarkar, Biplab
Sent: Monday, September 15, 2008 10:27 AM
To: Jacob Martin; [email-masked]
Cc: [email-masked]
Subject: Re: [Dime] Application-id reuse

Hi all,

I was thinking of the consequences of allowing AVP's to have the liberty to
either set or un-set the M-bit.
The sender may decide to set it depending upon its judgement about the
version of the peer.

- Will this give added help for extendability?
<Yes it would add to the extendibility/flexibility>
- Is it really required to mandate the presence of M-bit for AVPs? Won't it
be better to allow the sender to decide?

< To define any specification, there should be mandate on some of the basic
AVPs which helps in core functioning. For proprietary extensions, vendors
are allowed to define custom AVPs to meet their requirements>

Thanks & Regards,
Biplab

-----Original Message-----
From: [email-masked] on behalf of Jacob Martin
Sent: Mon 9/15/2008 10:17 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Dime] Application-id reuse

Thanks,
Ankit

"DISCLAIMER: This message is proprietary to Aricent and is intended solely
for the use of the individual to whom it is addressed. It may contain
privileged or confidential information and should not be circulated or used
for any purpose other than for what it is intended. If you have received
this message in error,please notify the originator immediately. If you are
not the intended recipient, you are notified that you are strictly
prohibited from using, copying, altering, or disclosing the contents of this
message. Aricent accepts no responsibility for loss or damage arising from
the use of the information transmitted by this email including damage from
virus."
_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: "Nilanjan Sarkar" <[email-masked]>
Date: Tue, 16 Sep 2008 15:55:17 +0530

Hi Srinivas,

According to RFC3588, Inband-Security-Id may support other security Ids
apart from 0 and 1 (ref page 80), and thus value 2 may not be invalid
AVP value for  Inband-Security-Id AVP, so  DIAMETER_INVALID_AVP_VALUE
may not be appropriate.

Kind Regards,
Nilanjan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
srinivas
Sent: Tuesday, September 16, 2008 3:41 PM
To: [email-masked]; [email-masked]
Subject: [Dime] Silly doubt on InbandSecurity handling in CER

Hi,
Silly doubt.Suppose a Diameter node has received the CER with
inband-security value as 2 then does the node has to respond with
DIAMETER_NO_COMMON_SECURITY (5017) or DIAMETER_INVALID_AVP_VALUE (5004)
or
any one is fine.

Thanks & Regards, 
Srinivas CH,
 
This e-mail and attachments contain confidential information from
HUAWEI,
which is intended only for the person or entity whose address is listed
above. Any use of the information contained herein in any way
(including,
but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please notify the
sender by
phone or email immediately and delete it!

-----Original Message-----

Hi Biplab,
-----Original Message-----

Hi all,

I was thinking of the consequences of allowing AVP's to have the liberty
to
either set or un-set the M-bit.
The sender may decide to set it depending upon its judgement about the
version of the peer.

- Will this give added help for extendability?
<Yes it would add to the extendibility/flexibility>
- Is it really required to mandate the presence of M-bit for AVPs? Won't
it
be better to allow the sender to decide?

< To define any specification, there should be mandate on some of the
basic
AVPs which helps in core functioning. For proprietary extensions,
vendors
are allowed to define custom AVPs to meet their requirements>

Thanks & Regards,
Biplab

-----Original Message-----
From: [email-masked] on behalf of Jacob Martin
Sent: Mon 9/15/2008 10:17 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Dime] Application-id reuse

Thanks,
Ankit

"DISCLAIMER: This message is proprietary to Aricent and is intended
solely
for the use of the individual to whom it is addressed. It may contain
privileged or confidential information and should not be circulated or
used
for any purpose other than for what it is intended. If you have received
this message in error,please notify the originator immediately. If you
are
not the intended recipient, you are notified that you are strictly
prohibited from using, copying, altering, or disclosing the contents of
this
message. Aricent accepts no responsibility for loss or damage arising
from
the use of the information transmitted by this email including damage
from
virus."
_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime
No virus found in this incoming message.
Checked by AVG - http://www.avg.com 
Version: 8.0.169 / Virus Database: 270.6.21/1673 - Release Date:
9/15/2008 6:49 PM

---

From: Ankit Kumar Sharma <[email-masked]>
Date: Tue, 16 Sep 2008 17:08:03 +0530

Hi Sri,

 It should return DIAMETER_NO_COMMON_SECURITY.

Cheers,
Ankit
-----Original Message-----
From: srinivas [mailto:[email-masked]]
Sent: Tuesday, September 16, 2008 3:41 PM
To: [email-masked]; [email-masked]
Cc: Ankit Kumar Sharma; 'Sarkar, Biplab'; 'Jacob Martin'; [email-masked]
Subject: [Dime] Silly doubt on InbandSecurity handling in CER

Hi,

Thanks & Regards,
Srinivas CH,

-----Original Message-----

Hi Biplab,
-----Original Message-----

Hi all,

Thanks & Regards,
Biplab

-----Original Message-----
From: [email-masked] on behalf of Jacob Martin
Sent: Mon 9/15/2008 10:17 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Dime] Application-id reuse

Thanks,
Ankit