RE: [802.21] AW: [802.21] Telecon on source/destination Ids within different primitives
Kalyan,
I forgot to mention that I had reponses to your comments embedded in the email.
Thanks,
Srini
>-----Original Message-----
>From: ext Srinivas Sreemanthula
>[mailto:Srinivas.Sreemanthula@nokia.com]
>Sent: Tuesday, January 24, 2006 3:03 PM
>To: STDS-802-21@listserv.ieee.org
>Subject: Re: [802.21] AW: [802.21] Telecon on
>source/destination Ids within different primitives
>
>HI Kalyan,
>I completely agree with the inconsistencies in the sections
>you pointed out. This must be fixed by the end of internal
>ballot process. The current dialogue to arrive at some common solution.
>
>Regards,
>Srini
>
>>-----Original Message-----
>>From: ext Kalyan Koora [mailto:kalyan.koora@BENQ.COM]
>>Sent: Tuesday, January 24, 2006 2:48 AM
>>To: STDS-802-21@LISTSERV.IEEE.ORG
>>Subject: [802.21] AW: [802.21] Telecon on source/destination
>Ids within
>>different primitives
>>
>>Hi Srini,
>>
>>it is nice to see that we agree on the things quickly. I also
>wanted to
>>raise some questions, which you already put into your email :-)
>>
>>Here my comments:
>>
>>>The issue must be narrowed down to either i) MIH packet or
>>ii) SAP definitions.
>>
>>I too agree with this and fell that we have already clarified src/dst
>>info in MIH variable header part. So the consideration is only
>>regarding SAP definition.
>>
>>Within the present draft 4, in section 6.2.2 we have a command
>>primitive definition which has only one ID other than info
>set. In the
>>section 6.2.6.1 we have set of commands defined in table 4, eg. MIH
>>Poll. Further, in section 7.4.6.1.2 we have a description of the MIH
>>poll request primitive, where we have src and dst ID.
>>Thus, I am not able to correlate the general primitive with the
>>specific primitive description.
>>
>>>1. MIH discovery mechanisms are performed by the MIH function
>>layer and hence
>>> part of MIH layer.
>>
>>Yes, I agree to it. But who will initiate this, that is, the
>"decision"
>>to perfrom discovery? MIH itself or MIH user?
>>
>Srini> minor correction here. We agreed the MIH discovery for
>L3 is done by the xport itself while for L2 it is the MIHF. My
>contention is that it cannot be mIH user since it would be
>counter-intuitive for each MIH user to create their own MIH
>peers. Both the decision and the origination is at MIH.
>
>>>2. MIH peer information is not made available(as per current
>>mechanisms) to the
>>> upper or lower layers of MIH.
>>
>>Do you mean here the information embedded in remote communication
>>between MIHF peers?
>
>Srini> I meant the MIH header information, we provide all the
>payload information that is supported by the primitive.
>
>>
>>>5. In this regard, the upper and lower layers only need to
>>mention local or
>>> remote scope in the SAP definition and the MIH will make
>>routing decisions
>>> about the destination for remote communication.
>>
>>Same as point 1, will upper or lower layer need to know whether the
>>info is local or remote? Or the decision will be taken place at MIHF?
>Srini> this is the tricky part and I have to correct my
>statement with "MAY". Knowing that MIH event registrations
>terminate at MIH layer and there are no remote link events.
>Clearly when a link event is generated you cannot tell that it
>is remote in scope. Only the MIH knows who has registered for
>it and where the peer is. For commands, OTH, there are no
>registrations so the MIH user MAY tell if it is local or
>remote and the implementation at MIH could validate it and act
>accordingly.
>
>>>6. I take the same position with regards to the transport
>>option (l2 or
>>>l3) as well. The decision is upto MIH (this change was
>>approved in Kona meeting).
>>
>>Sorry, I didn't get your point here. Could you please elaborate this?
>
>Srini> In v4 there was a transport parameter in the primitives
>starting from 7.4.10. I requested to remove it in the F2F meeting.
>
>>
>>By the way one IMPORTANT question to be clarified with this
>aspect, who
>>will decide over which interface or using which protocol
>local MIHF has
>>to communicate with peer MIHF? Is it the local MIHF or the MIHF user?
>>This point clarifies most of the doubts coming up.
>
>Srini> my proposal is keep MIH-users/l2 out of it. MIHF knows
>all the available transports and will choose.
>>
>>Regards,
>>Kalyan
>>
>>-----Ursprüngliche Nachricht-----
>>Von: Srinivas Sreemanthula [mailto:Srinivas.Sreemanthula@NOKIA.COM]
>>Gesendet: Dienstag, 24. Januar 2006 00:18
>>An: STDS-802-21@listserv.ieee.org
>>Betreff: Re: [802.21] Telecon on source/destination Ids within
>>different primitives
>>
>>
>>Hi Wolfgang,
>>Sorry I would not be able to make it for the conference next week.
>>But, please consider my opinions below as part of your
>discussion. The
>>issue must be narrowed down to either i) MIH packet or ii) SAP
>>definitions. My opinions are related to SAP defitions, for MIH packet
>>we already have those fields defined.
>>
>>1. MIH discovery mechanisms are performed by the MIH function
>layer and
>>hence part of MIH layer.
>>2. MIH peer information is not made available(as per current
>>mechanisms) to the upper or lower layers of MIH.
>>3. MIH registration (in the future) will also be part of MIH function
>>which provided MIH pairing information (not provided to other layers)
>>4. The most suitable layer/part of the stack having the knowledge of
>>the MIH peer is the MIH layer itself.
>>5. In this regard, the upper and lower layers only need to mention
>>local or remote scope in the SAP definition and the MIH will make
>>routing decisions about the destination for remote communication.
>>6. I take the same position with regards to the transport
>option (l2 or
>>l3) as well. The decision is upto MIH (this change was
>approved in Kona
>>meeting).
>>
>>Regards,
>>Srini
>>
>>
>>>-----Original Message-----
>>>From: ext Wolfgang Gröting [mailto:wolfgang.groeting@BENQ.COM]
>>>Sent: Wednesday, January 18, 2006 6:39 PM
>>>To: STDS-802-21@listserv.ieee.org
>>>Subject: [802.21] Telecon on source/destination Ids within different
>>>primitives
>>>
>>>Dear all,
>>>
>>> as agreed within the meeting, I suggest to have a telecon on the
>>>above mentioned issue next week. I will provide telecon
>details later
>>>on.
>>>
>>>Aim is to clarify the value of having source / destination
>Ids within
>>>particular commands and events.
>>>
>>>Cheers,
>>>Wolfgang.
>>>
>>
>