RE: [STDS-802-21] Inconsistency in 802.21(c) parameters -- please take a look
As Yoshihiro points out there are inconsistencies (or at least an unclear understanding of the relationships with the primitive parameters and the messages).
Therefore I think that now is a great chance to make absolutely clear what the relationship is, rather than use mistakes in the already published standards as a reason to continue making mistakes or continuing to be unclear.
It is a good thing that a revision PAR was requested.
David Cypher
> -----Original Message-----
> From: Yoshihiro Ohba [mailto:yoshihiro.ohba@xxxxxxxxxxxxx]
> Sent: Wednesday, August 08, 2012 7:00 PM
> To: Cypher, David E.
> Cc: STDS-802-21@xxxxxxxxxxxxxxxxx
> Subject: Re: [STDS-802-21] Inconsistency in 802.21(c) parameters -- please
> take a look
>
> (2012/08/08 5:01), Cypher, David E. wrote:
> > Charles,
> >
> > I do not have 802.21c in front of me, but ...
> >
> > The original formatting for 802.21 was that the parameters list of a
> > primitive contains all of the parameters that could be included, as
> > well as in the tables following the parameter list explains when and
> > or if the parameter is included.
> >
> > When it came to the actual message format it had to include also all
> > of the fields that could be part of the message and within that field
> > (mark as optional)
> >
> > There should be no inconsistency between the primitive parameters list
> > and the message fields (as you appear to be pointing out). That is
> > there shall be a one for one match between the primitive list,
> > primitive table, and message format.
>
> There are two exceptions in 802.21-2008 on this. Source Identifier TLV will
> be automatically inserted by the MIHF of the source of a message, but a
> SourceIdentifier parameter is not included in the primitive (such as .request
> and .response) invoked by an MIH user when sending the message.
[dc] Is this an exception? Or are you stating what I already said?
Does the 802.21-2008 clearly state that the Source Identifier TVL is automatically inserted by the MIHF (as opposed to provide in the primitive's parameter list?
> Similarly, Destination Identifier TLV will not be included in the primitive
> (such as .indication and .confirm) that will be invoked by an MIHF when it
> receives a message.
[dc] This is not an exception and does not apply to the discussion at hand.
The .indication and .confirm come from the MIHF, not the user of the MIHF.
THe Destination ID TLV is present in the message (YES).
Would the MIHF ever accept a message that does not match its address with the destination in the message that it received?
I think not, and therefore the question next becomes does the USER need to know the destination address received in the message?
>
> Having said that, in 802.21c case, I see no consistency between
> MIH_LL_Transfer.request primitive and MIH_LL_Transfer request message.
>
> BTW, there is another exception in 802.21a-2012. MIH_Auth messages used
> for MIH service access authentication are exchanged between peer MIHFs
> without invoking any primitive.
[dc] How is this an exception? If there is no primitive, and the message is created entirely by the MIHF, then it is clearly obvious that the information has to come from the MIHF and is required by the MIHF to provide. Apparently those actively involved in 802.21a thought that the MIHF is entirely in control and there were no primitives need or permitted to invoke this message(s).
>
[dc] Summary:
For the .request and .response primitives that originate from the MIHF User , what parameters are required?
Is there a field for each of these parameters in the resulting message?
If there is a field in a message that is not contained as a parameter in the primitive, then it absolutely stated that that field is filled by the MIHF.
Yoshihiro made two other points, that are not related to the original question or my response, but worth commenting on, since at least one did not understand my repsonse.
The .indication and .confirm primitives are generated entirely by the MIHF.
Case 1 (local MIHF) some .confirm primitives can be sent by the MIHF without reception of any message, therefore the one to one correspondence that I stated for the .request and .response, obviously cannot apply.
Case 2 (remote MIHF) some .confirm primitives are generated by the MIHF after receiving a message. In this case the question becomes what information from the received message needs to be forwarded to the MIHF User? All? Some? None?
For the MIH_Auth messages.802.21a
If there are no primitives to generate these message, then the MIHF must provide all of the necessary information to be placed in the fields of the message.
Where's the inconsistency? I see none.
> Yoshihiro Ohba
>
> >
> > I am not commenting on whether source address is required or not in
> > order to remover the inconsistency.
> >
> > David Cypher
> >
> > *From:*Charles E. Perkins [mailto:charles.perkins@xxxxxxxxxxxxx]
> > *Sent:* Tuesday, August 07, 2012 3:30 PM
> > *To:* STDS-802-21@xxxxxxxxxxxxxxxxx
> > *Subject:* [STDS-802-21] Inconsistency in 802.21(c) parameters --
> > please take a look
> >
> >
> > Hello folks,
> >
> > I am noticing various inconsistencies, which mostly I can fix. But
> > here is an example where I am not so sure.
> >
> > For instance in section 7.4.29.1.2:
> >
> >
> > 1.1.1.1.1Semantics of service primitive
> >
> > MIH_LL_Transfer.request
> >
> > includes:
> >
> > DestinationIdentifier,
> >
> > TargetLinkIdentifier,
> >
> > LLInformation,
> >
> > TMGWIdentifier,
> >
> > CandidateLinkList
> >
> >
> > But section 8.6.3.24 calls also for
> > a "Source Identifier". I think this can be argued both ways, but the
> > Source Identifier is unlikely to be absolutely required and so I could
> > omit it.
> >
> > Comments, please?
> >