Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: [802.21] Ad hoc telecon for Nov 29th


> >I believe that nothing in the draft is cast in stone until the 
> >draft is released as approved. That is normal IEEE process. If 
> >there are parties that believe something in the draft may not 
> >be 100% ok, I do not see why we should not keep the discussion open.
> >
>=> Sure, I am definitely not trying to close the discussion.  
>:-)   However,
>excluding the consideration of what is defined in D3 is not a 
>good way. I believe that the baseline of our discussion should 
>be originated from the currently defined spec., D3. Until this 
>time, I did not hear any good rational and explanation what is 
>missing and needs to be amended regarding this discussion from 
>the current defined MIH Capability Discovery from D3.
>Thus, it would be helpful if I can hear your pin-pointing out 
>what needs to be amended. Maybe, you can try to amend the 
>current spec., D3 in the future meeting by submitting comments 
>if you would like to make any amendments regarding MIH 
>Capability Discovery. This is the first step to be more 
>productive, I believe.
[Stefano] Indeed. Let's keep in mind that in this specific discussion we are talking about higher layer requirements. Based on this, we need to consider not only whether the mechanisms in the draft work or not, but also the feasibility to have them supported by the other for a we need to liaise and interwork with. We should strive to define the best solution possible,  but at the same time we need to keep in mind that we need to work with other fora. Not doing so would be definitely a waste of time and energies. 
Considering this, the shortcoming I'm highlighting is described below in my previous text and new comments.  

> > >Could anyone kindly let me know where this gab in 
> > >understanding the MIH 
> > >Capability Discovery stuff comes from? Am I miss-understanding or 
> > >missing something here?
> >I believe the misunderstanding is not so much on what is or 
> >not in the draft, but what is the of the draft content on 
> >higher layer requirements. 
> >
> >I **do not believe** it is realistic for any form of L3 
> >transport to have the discovery of MIH functions (e.g. even 
> >just their IP addressed) built in the MIH protocol. 
>=> Do you believe or not? I am confused. I thought you believe.

[Stefano] Perhaps the sentence should be read in his entirety. Sorry for not being clear, let me rephrase it: I was referring to 802.21 @ L3 and having the discovery of MIH functions built into the MIH protocol wrt having the MIH protocol separate from the use of an IP mechanism to discover MIH. I do not believe that from an IETF point of view it makes sense to have the discovery of MIH functions built into the MIH protocol. The reason is that:
> >That is the equivalent of telling IETF that for the MIH 
> >specific purposes we are not using any of the proven existing 
> >discovery solutions designed in IETF and we're introducing a new one. 
>=> Is there any discovery protocol defined in IETF which fits 
>the purpose of MIH capability discovery? Absolutely not! 
[Stefano] I guess there is a study somewhere proving that? It would be good to see the results to support this statement.
>did not introduce and do not introduce and will not introduce 
>any protocol which needs be standardized in IETF regarding MIH 
>protocol itself. We are here in IEEE 802.21. :-) 
[Stefano] Let me try to put it in a different way: for 802.21 @ L3, are we relying on the expertise of IETF in discovery of an IP function (the MIH), or have we defined our own solution? My understanding is that by building the discovery into the protocol we have decided not to rely on the surely larger expertise of IETF in this field. As for existing protocols, I can easily see either DNS or SLP used for the discovery, without any particular modifications by just a smart adoption.
>As a side 
>note: There is no work item for capability discovery in the 
>current IETF MIPSHOP charter.
[Stefano] that is correct. However, this does not stop IETF from working on the discovery aspects in other WGs. E.g. MIPSHOP could ask another IETF WG to help with the discovery aspects since MIPSHOP has decided to not cover that aspect.
> Aside from the on-going 
>discussions, what do you expect by including a requirement 
>about MIP capability discovery in the requirement documents of 
>MIH info/command/event services? Are you intending to re-try 
>including this MIH capability discovery to the **future** 
>MIPSHOP charter?
[Stefano] definitely not. 
> Or do you believe that the work of MIH 
>Capability Discovery is already included in MIH event, command 
>and information support items of MIPSHOP? 
[Stefano] it is not, but that does not mean it cannot be done somewhere else in IETF as needed.
>Please let me hear 
>what you have in your mind.
> I believe the work about MIH 
>protocol which includes the MIP Capability Discovery is 
>accurately the job of IEEE 802.21 group.
[Stefano] I guess we must agree to disagree. I still believe that for 802.21 @ L3 we should try to reuse existing solutions for the discovery.

> >I doubt that would fly in IETF. As for capabilities discovery, 
> >that can definitely be built in the protocol.
>=> So we just need to sharpen the existing MIH Discovery 
>Protocol which is defined in D3, Whether the MIH protocol use 
>layer 2 transport or layer 3, we only need one firmly defined 
>MIP protocol which includes MIH Capability Discovery, right?
>>So, maybe we should separate the requirements in two categories as 
>>1/ The actual MIH Protocol requirements: Transport, Security, 
>>Reliabilty, Time Constraint/QoS Requirements..
>>2/ The "other" MIH ES/CS Function requirements: Discovery, 
>>-----Message d'origine-----
>>De : Srinivas Sreemanthula [mailto:Srinivas.Sreemanthula@NOKIA.COM]
>>Envoyé : mardi 29 novembre 2005 16:43
>>À :
>>Objet : Re: [802.21] Ad hoc telecon for Nov 29th
>>The timely delivery of ES/CS messages have been noted. This 
>>to the delay aspect.  Do you have other any others on your mind?
>>>-----Original Message-----
>>>From: ext Reijo Salminen []
>>>Sent: Tuesday, November 29, 2005 3:33 AM
>>>To: Sreemanthula Srinivas (Nokia-NRC/Dallas)
>>>Cc: Sreemanthula Srinivas (Nokia-NRC/Dallas); 
>>>Subject: RE: [802.21] Ad hoc telecon for Nov 29th
>>>Hello, 802.21
>>>Any ideas how the QoS issues will be addressed in this
>>context? It was
>>>not mentioned in the slides. Is it out of scope?
>>>Best Regards, Reijo Salminen
>>>> Hello all,
>>>> Here is the related slideset we can start off with.
>>>> Regards,
>>>> Srini
>>>>>-----Original Message-----
>>>>>From: ext Srinivas Sreemanthula
>>>>>Sent: Monday, November 28, 2005 12:26 PM
>>>>>Subject: Re: [802.21] Ad hoc telecon for Nov 29th
>>>>>Here is telecon bridge info for Nov 29th about L3 ES/CS
>>>>>US Phone Number: 972-894-6500
>>>>>EU Phone Number: +358 7180 71870
>>>>>Conference ID: 37162, PIN: 598518
>>>>>One-time agreement: 29.11.2005 at 08:00 - 10:00
>>>>>(GMT-06:00) Central Time (US & Canada)
>>>>>Number of participants: 20
>>>>>Instructions language: English
>>>>>	From: ext Ajay Rajkumar []
>>>>>	Sent: Friday, November 25, 2005 7:22 AM
>>>>>	To:
>>>>>	Subject: [802.21] Ad hoc telecons for the next two months
>>>>>	*
>>>>>	Hi everyone,
>>>>>	The external meeting documents server has been updated
>>>and synced. At
>>>>>the end of the just concluded Vancouver session the working group 
>>>>>approved a set of telecon for the next two months.
>>>>>	Here is the schedule of these telecons again. Please
>>>note that all
>>>>>times are from 9-11 am EST, which was acceptable to all and
>>seems to
>>>>>be most suitable time for all time zones concerned.
>>>>>	*
>>>>>	*IS Higher Layer Transport Requirements
>>>>>	   December 8, 2005
>>>>>	-    January 10, 2006
>>>>>	*ES/CS Higher Layer Transport Discussion
>>>>>	-    November 29, 2005
>>>>>	-    December 13, 2005
>>>>>	-    January 12, 2006
>>>>>	*802.11 Requirements
>>>>>	-    January 5, 2006
>>>>>	*
>>>>>	802.16 Requirements
>>>>>	   -December 15, 2005
>>>>>	The telecon bridge number and codes would be announced
>>>closer to the
>>>>>respective telecon dates.
>>>>>	Best Regards,
>>>>>	-ajay
>>>>>	Ajay Rajkumar
>>>>>	Chair, IEEE 802.21 WG