Subject: RE: [Mipshop] GIST for 802.21

From: "Hepworth, Eleanor" <[email-masked]>
Date: Thu, 10 Aug 2006 14:33:02 +0100

Hi Akbar, Alper,

> I agree with your point below that the current MIH problem 
> statement is "too high level. It does not answer many 
> questions, and now we need to take it from there......."

It wasn't clear from Alper's original e-mail as to whether he was
referring to the mih-ps I-D or the actual IEEE 802.21 requirements
draft.  If it is the former that is felt to be too high level, could you
give some indication as to the sort of level of detail you would prefer
to see?  We do need to take care that we don't wander into the solution
space too much whilst trying to pin down the problem.
 
> As I said during the IETF meeting in Montreal, we should try 
> to avoid solving other problems beyond the current need for 
> discovery/transport/security of MIH messages.  It is true 
> that other requirements and issues may arise in the future 
> but first let's get focused on solving the MIH issue and not 
> try to come up with a "meta solution" that solves everything.

It's not clear to me that anyone is suggesting solving any problems
other than the discovery/transport/security of mobility service
information.  Other applications have been identified within MIPSHOP
that can make use of this common functionality, but I don't believe they
change the scope of the problem.  In any case, taking a high level view
of the problem space usually leads to cleaner protocol designs which is
a good thing for everybody in the long term.

Thanks

Ele
> 
> 
> Akbar
> 
> 
> -----Original Message-----
> From: Alper Yegin [mailto:[email-masked]] 
> Sent: Monday, August 07, 2006 8:34 AM
> To: 'Hancock, Robert'
> Cc: [email-masked]
> Subject: RE: [Mipshop] GIST for 802.21
> 
> Hi Robert,
> 
> > - i had always understood that ES/CS/IS were fundamentally 
> > differentiated from each other by their different roles in the .21 
> > architecture,
> 
> I think so too.
> 
> > rather than their message transport requirements. so it
> 
> I think the transport requirements (whatever they end up to 
> be) would be affected by your former point.
> 
> > might be dangerous at this stage to hard-code assumptions 
> about those 
> > requirements into the protocol design. for example, suppose in the 
> > future that there is a value in sending a large message 
> (e.g. with a 
> > couple of certificates or something) from the CS node in 
> the network;
> it
> > would be bad if the protocol architecture forced that such messages 
> > could only come from the IS node.
> 
> I'm hoping we can clearly separate configuration and 
> information delivery
> (IS) from ES and CS. Maybe we should look at some scenarios.
> 
> 
> > - if you want to use different transports for different 
> services, then 
> > you quite likely end up with parallel discovery mechanisms.
> 
> I'm not sure if different transports imply different 
> discovery mechanisms. I think this has to do more with the 
> location of the end-points, irrespective of the protocols 
> used to reach them. For example, depending on the discovery 
> mechanism, even if the transports and the server nodes are 
> different, same discovery mechanism may be able to help.
> 
> 
> > conversely,
> > as was discussed in the last meeting, the model of MIH 
> services being 
> > used by .21 is that that server capabilities are negotiated in-band 
> > after initial discovery - but then one has another question 
> about what 
> > are the tranport requirements for those negotiation messages
> themselves,
> > which are not ES/IS/CS at all.
> > 
> > i'm hoping that the problem statement will cover the 
> overall transport 
> > requirements for all the MIH services, and also the 
> meta-requirement 
> > that different services may have different needs which have to be 
> > accommodated efficiently.
> 
> I agree. I've looked at the .21 requirements document and 
> found it to be "too high level." It does not answer many 
> questions, and now we need to take it from there.......
> 
> > however, i'm not sure that it is a good idea
> > to split the problem up too rigidly at this point.
> 
> I agree. But in fact I was not asking for that. I was just 
> asking, now that people are also proposing GIST for 802.21, I 
> was wondering what parts of the .21 problem space they think 
> GIST should be used.
> 
> Regards,
> 
> Alper
> 
> 
> 
> 
> > 
> > cheers,
> > 
> > robert h.
> > 
> > > -----Original Message-----
> > > From: Alper Yegin [mailto:[email-masked]]
> > > Sent: 03 August 2006 21:11
> > > To: [email-masked]; [email-masked]; 
> > > [email-masked]; [email-masked]; 
> > > [email-masked]
> > > Cc: [email-masked]
> > > Subject: RE: [Mipshop] GIST for 802.21
> > >
> > >
> > >
> > > Question: which one(s) of the MIH protocols are we 
> considering GIST 
> > > for? (ES, CS, IS)?
> > >
> > > Alper
> > >
> > >
> > > > -----Original Message-----
> > > > From: [email-masked] [mailto:[email-masked]]
> > > > Sent: Thursday, August 03, 2006 8:44 AM
> > > > To: [email-masked]; [email-masked]; 
> > > > [email-masked]; [email-masked]
> > > > Cc: [email-masked]
> > > > Subject: RE: [Mipshop] GIST for 802.21
> > > >
> > > > Junghoon,
> > > >
> > > > >From the explanation about the GIST by John, I can not 
> find any 
> > > > >clear issue/obstacle about the possibility in 
> utilizing the GIST 
> > > > >for the transporting the MIH protocol under 
> considering the MIH 
> > > > >communication model. I might give more detailed feedback about 
> > > > >the considerable points in adopting GIST for MIH 
> transport after 
> > > > >further exploring the GIST world.
> > > >
> > > > Great - let us know.  Also, as an FYI - GIST is in IETF 
> last call, 
> > > > if anyone wants to send comments, please do so. Either 
> post them 
> > > > to the NSIS list or send them to Robert / myself.
> > > >
> > > > thanks,
> > > > John
> > > >
> > > > _______________________________________________
> > > > Mipshop mailing list
> > > > [email-masked] https://www1.ietf.org/mailman/listinfo/mipshop
> > >
> > >
> > > _______________________________________________
> > > Mipshop mailing list
> > > [email-masked] https://www1.ietf.org/mailman/listinfo/mipshop
> > >
> 
> 
> _______________________________________________
> Mipshop mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mipshop
>  
>  
>  
> Akbar Rahman  
> Principal Engineer, Systems
> InterDigital Canada Ltee
> 1000 Sherbrooke Street West
> 10th Floor
> Montreal, Quebec H3A 3G4
> Tel.: +1 514.904.6270
> Fax: +1 514.904.6344
> Email: [email-masked] http://www.InterDigital.com
> 
>  
>  
>  This e-mail is intended only for the use of the individual 
> or entity to which it is addressed, and may contain 
> information that is privileged, confidential and/or otherwise 
> protected from disclosure to anyone other than its intended 
> recipient.  Unintended transmission shall not constitute 
> waiver of any privilege or confidentiality obligation. If you 
> received this communication in error, please do not review, 
> copy or distribute it, notify me immediately by email, and 
> delete the original message and any attachments. Unless 
> expressly stated in this e-mail, nothing in this message or 
> any attachment should be construed as a digital or electronic 
> signature.
> 
> _______________________________________________
> Mipshop mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mipshop
> 

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

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 11 Aug 2006 02:01:45 +0300

Hi Eleanor,

> space too much whilst trying to pin down the problem.

I was referring to the latter document.
It is still in my to-do list to do a detailed reading of the former
document.

Alper