[Robustness] Minutes of the 7/20 call

Terry L Anderson tla at LUCENT.COM
Mon Jul 24 17:42:48 EDT 2000


Hi, Mark and Jaakko:

I think that MD-102a is good one. It consists of 3 parts:

1. Use mobility
2. Terminal mobility
3. Service mobility

The interesting thing is that services also overlap for items 1 and 2
indirectly. However, let me relate above items from the
H.323 standard perspective.

Item 3 as described in the contribution, it may fall into the category of
H.323 supplementary services mobility, while items 1 and 2 will be H.323
(basic) call services.

With respect to the "scope" of our present standardization effort of Annex
H, the basic question is: How far do we want to go?

The reason that I am saying so is that AT&T contribution D.353 provides
another view of the services mobility. MD-102a (Siemens and Intel) also
describes how many more items need to be addressed for the services
mobility.

You can easily imagine that the services mobility is one of the most
important items that the service providers like to see happen in standard
arena.

So, my proposal for the interest of the rapid standardization effort is as
follows:
a. Phase 1: Items 1 and 2
b. Phase 2: Item 3

I like to see other members also provide comments on this.

Best regards,
Radhika R. Roy
AT&T

-----Original Message-----
From: Jaakko Sundquist [mailto:jaakko.sundquist at nokia.com]
Sent: Monday, July 24, 2000 4:14 AM
To: ITU-SG16 at MAILBAG.INTEL.COM
Subject: Re: [H.323 Mobility:] Update to Service Definitions for Annex H
- > a question


Hi Marc et al,

I just finished reading MD-102a and I have a couple of questions. First of
all, though, I want to thank you guys for the excelent contribution, I
really liked it.

Actually I have just one thing that I don't quite understand. In section
5.1.2 you talk about the Authentication of a H.323 Mobile Terminal and say
that it enables the verification of the authenticity of the terminal is
context of the association it has with the Mobile User. You also explain
this a bit further by adding that this is used to verify that the terminal
can act on behalf of the authenticated User using it but you still state
that the identity of the terminal is only relevant for the purposes of
denying the usage of stolen terminals, etc. (black lists). So my question is
that are you talking here about authenticating the terminal or are you
referring to authenticating some sort of identifier that is used for the
association between the terminal and the user? Your statement in item 3.
about not needing to authenticate the user in subsequent terminal
re-registrations would also seem to indicate the latter. Thus are you
thinking of implementing a way to avoid the User authentication at least in
Intra-zone location changes by introducing some sort of temporary local
identifier for the terminal/user pair? I know that these are just
requirements, but these statements seem to lead to that direction, if I have
understood them correctly.
The idea seems to be worth while to consider and we should discuss this
further, but I don't quite see, how the terminal/user pair could really be
authenticated, i.e. you can authenticate the User (by contacting the AuF)
and you can authenticate the terminal (if proper cryptographic methods are
specified also for the terminal), but how can you authenticate their
association?

Or am I just reading too much into this?

Otherwise the contribution seems fine and I would suggest the addition of
its contents to the draft Annex H. Let's have a bit of discussion before
that, however.

------------------------------------------------
Jaakko Sundquist           *
+358 50 3598281            * Audere est Facere!
jaakko.sundquist at nokia.com *
------------------------------------------------

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com



More information about the sg16-avd mailing list