RE: [STDS-802-21] Inconsistency in 802.21(c) parameters -- please take a look
Pete,
If you can make mandatory all information that an MIHF layer must have in order to support this case and all future cases, then it would be okay.
I understand your suggestion, but without this extra requirement, it will not work every time.
Here's another point that you would need to consider if you continued in your path.
You would also have to forbid the inclusion of any primitive parameter that is to be supplied by the MIHF layer itself.
Otherwise what would be the result if a primitive parameter did not match the one being supplied by the MIHF?
Where does the MN NAI information come from?
Can it be changed/modified?
Can it be overwritten?
David Cypher
> -----Original Message-----
> From: Peter McCann [mailto:Peter.McCann@xxxxxxxxxx]
> Sent: Tuesday, August 07, 2012 8:37 PM
> To: Cypher, David E.; STDS-802-21@xxxxxxxxxxxxxxxxx
> Subject: RE: [STDS-802-21] Inconsistency in 802.21(c) parameters -- please
> take a look
>
> Is it possible that some of the message parameters could be supplied by the
> MIHF layer, after it receives the primitive from the upper layers, based on
> information that is endemic to the MIHF layer itself?
> In those cases, the information element might not appear in the primitive
> but would appear on the wire in the message between peer MIHF layers.
> I was guessing that this might be the case for some of the information
> elements such as the MN's NAI.
>
> -Pete
>
> 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.
> >
> > 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.1 Semantics 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?
>
>