Subject: [MIPSHOP-MIH-DT] Discovery discussion

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Thu, 22 Mar 2007 09:40:12 -0400

Hello all,

These are the notes that I took during our discussion about discovery.

Please feel free to comment.

Regards,

Jc

MIPSHOP DT

Discovery discussion

We can think of three scenarios for discovery:

1) Absolute knowledge of node location, address, etc.

2) No knowledge at all of where things are when roaming to a new network

3) A partial knowledge where the user has "some" knowledge (e.g. NAI)
and the discovery function needs to convert that into something more
meaningful (e.g. IP address) E.g. Diameter defines an NAI procedure for
AAA discovery

Consensus that MSTP would address cases 2 and 3, since case 1 could be
solved with already existing solutions, perhaps at application (http,
sip, etc.).

We agree that the MIHF must provide some information to the MSTP for it
to discover the peer MIHF. What we need to evaluate is whether this
information should include a set of criteria (e.g. type of service) for
the MSTP to find one (or many) peers, or not. 

We have to consider whether these criteria should be explicit and
visible to the MSTP (e.g. find IS service for me), or implicit and
hidden (find [email-masked] for me, which is the partial knowledge case
mentioned above).

Similarly, for defining the interface between the MIHF and the MSTP, we
have to consider whether there is variability in the criteria (e.g. find
IS, ES, CS), or not (e.g. find NAI)

_______________________________________________
MIPSHOP-MIH-DT mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt

---

From: "Robert Hancock" <[email-masked]>
Date: Thu, 22 Mar 2007 16:43:45 +0100

it seems that the presentation was good enough for the audience ;-)
 
thanks everyone for all the time and effort that's been put in this week. i
think we got to know each other a lot better and also made real progress on
the technical work. now we just need to keep going.
 
i think dinner this evening has collapsed, partly through exhaustion and
partly more exciting offers - how people can think that a trip to the Prague
opera is more exciting than a mipshop discussion I do not know, but ... ;-)
 
but we will have another opportunity for a DT meal, at least in Chicago. see
you there!
 
cheers,
 
robert h.

---

From: <[email-masked]>
Date: Thu, 22 Mar 2007 11:02:40 -0500

I am too late to comment on the slides but they are mighty good. Great
work. 
 
Regards,
Srini

________________________________

From: ext Robert Hancock [mailto:[email-masked]] 
Sent: Thursday, March 22, 2007 10:44 AM
To: [email-masked]
Subject: [MIPSHOP-MIH-DT] hi everyone

thanks everyone for all the time and effort that's been put in this
week. i think we got to know each other a lot better and also made real
progress on the technical work. now we just need to keep going.
 
i think dinner this evening has collapsed, partly through exhaustion and
partly more exciting offers - how people can think that a trip to the
Prague opera is more exciting than a mipshop discussion I do not know,
but ... ;-)
 
but we will have another opportunity for a DT meal, at least in Chicago.
see you there!
 
cheers,
 
robert h.

---

From: <[email-masked]>
Date: Thu, 22 Mar 2007 17:06:35 -0500

Hi Juan Carlos,
 
I've been swamped by several things, quite a bit having to do with my
relocation to the US (hence not making the the IETF), but I am starting
to catch-up on some threads. Some points on discovery

	Discovery discussion

	2) No knowledge at all of where things are when roaming to a new
network

	3) A partial knowledge where the user has "some" knowledge (e.g.
NAI) and the discovery function needs to convert that into something
more meaningful (e.g. IP address) E.g. Diameter defines an NAI procedure
for AAA discovery

	Consensus that MSTP would address cases 2 and 3, since case 1
could be solved with already existing solutions, perhaps at application
(http, sip, etc.).

	We agree that the MIHF must provide some information to the MSTP
for it to discover the peer MIHF. What we need to evaluate is whether
this information should include a set of criteria (e.g. type of service)
for the MSTP to find one (or many) peers, or not. 

	We have to consider whether these criteria should be explicit
and visible to the MSTP (e.g. find IS service for me), or implicit and
hidden (find [email-masked] for me, which is the partial knowledge case
mentioned above).

	Similarly, for defining the interface between the MIHF and the
MSTP, we have to consider whether there is variability in the criteria
(e.g. find IS, ES, CS), or not (e.g. find NAI)

	I strongly dislike 1), as we expect that endhosts running 802.21
will be running in a variety of networks (home, office, public,
operator, etc) and in a number of scenarios (home network, roaming
network, intranets, Internet access, VPN access).  Absolute knowledge
will require provisioning and assumes that there will be a definitive
location for all use cases, which I do not believe the case.

	I think that, looking at this in a different way, we have a
couple of mechanisms

	1) Above mentioned preconfigured discovery

	2) External protocol mechanism (SLP, DNS, Diameter, etc.)

	3) transport protocol mechansims (path-based discovery, for
eample).

	Question to everyone: can we assume a NAI solution?  Will there
always be some way to assign a MIHF provider, so that we can handle a
NAI solution? This implies to me, at least, that there is a service
provider providing MIHF.  Or, could we assume that MIHF would be a bit
more ubiquitous and could be provided via the network attachment point. 

	thanks,

	John

---

From: <[email-masked]>
Date: Thu, 22 Mar 2007 17:14:10 -0500

What were the main comments on the material?  
 
Good presentation, btw.
 
John

	From: ext Robert Hancock [mailto:[email-masked]] 
	Sent: 22 March, 2007 08:44
	To: [email-masked]
	Subject: [MIPSHOP-MIH-DT] hi everyone

	it seems that the presentation was good enough for the audience
;-)
	 
	thanks everyone for all the time and effort that's been put in
this week. i think we got to know each other a lot better and also made
real progress on the technical work. now we just need to keep going.
	 
	i think dinner this evening has collapsed, partly through
exhaustion and partly more exciting offers - how people can think that a
trip to the Prague opera is more exciting than a mipshop discussion I do
not know, but ... ;-)
	 
	but we will have another opportunity for a DT meal, at least in
Chicago. see you there!
	 
	cheers,
	 
	robert h.

---

From: Subir Das <[email-masked]>
Date: Fri, 23 Mar 2007 04:45:07 -0400

John,
Thanks for your comments.
Response to your following question:
"Question to everyone: can we assume a NAI solution? Will there always 
be some way to assign a MIHF provider, so that we can handle a NAI 
solution? This implies to me, at least, that there is a service provider 
providing MIHF. Or, could we assume that MIHF would be a bit more 
ubiquitous and could be provided via the network attachment point."

802.21 spec provides example MIHF-ID as NAI or FQDN. That does not mean 
a provider can not assign something else if it is used within that 
provider's network and is unique within that provider's domain. But to 
support global roaming and interoperability, it has to be globally 
unique, IMO. Although 802.21 does not define how this ID will be 
assigned, but couple of us believe that this ID will be assigned by the 
provider not via the network attachment point.

Thanks,
-Subir

[email-masked] wrote:
> relocation to the US (hence not making the the IETF), but I am 
> starting to catch-up on some threads. Some points on discovery
>
>     Discovery discussion
>
>     3) A partial knowledge where the user has “some” knowledge (e.g.
>     NAI) and the discovery function needs to convert that into
>     something more meaningful (e.g. IP address) E.g. Diameter defines
>     an NAI procedure for AAA discovery
>
>     could be solved with already existing solutions, perhaps at
>     application (http, sip, etc.).
>
>     for it to discover the peer MIHF. What we need to evaluate is
>     whether this information should include a set of criteria (e.g.
>     type of service) for the MSTP to find one (or many) peers, or not.
>
>     hidden (find [email-masked] <mailto:[email-masked]> for me,
>     which is the partial knowledge case mentioned above).
>
>     MSTP, we have to consider whether there is variability in the
>     criteria (e.g. find IS, ES, CS), or not (e.g. find NAI)
>
>     network, intranets, Internet access, VPN access). Absolute
>     knowledge will require provisioning and assumes that there will be
>     a definitive location for all use cases, which I do not believe
>     the case.
>
>     I think that, looking at this in a different way, we have a couple
>     of mechanisms
>
>     3) transport protocol mechansims (path-based discovery, for eample).
>
>     always be some way to assign a MIHF provider, so that we can
>     handle a NAI solution? This implies to me, at least, that there is
>     a service provider providing MIHF. Or, could we assume that MIHF
>     would be a bit more ubiquitous and could be provided via the
>     network attachment point.
>
>     thanks,
>
>     John
>
> ------------------------------------------------------------------------
>