RE: [802.21] MIH Protocol message naming
> -----Original Message-----
> From: Junghoon Jee [mailto:jhjee@etri.re.kr]
> Sent: Sunday, January 08, 2006 4:42 PM
> To: Gupta, Vivek G; 'zze-Seamless PERESSE M ext RD-RESA-REN';
STDS-802-
> 21@listserv.ieee.org
> Subject: RE: [802.21] MIH Protocol message naming
>
<clip>
> > > >
> > > Hi Junghoon,
> > >
> > > I agree with your statement. I guess MIH Function Message should
> > > simply not have a "primitive like" naming scheme, since it
> > is confusing.
> > >
> > > However, these messages will be transmitted using other
> > media specific
> > > primitives: for example, in 16g (if I understood correctly), 4
> > > primitives (section 6.3.2.3 in the 16g draft) are used to
> > transmit and
> > > receive MIH messages (1 Request and 1 Response in both
> > directions). Another example:
> > > for 11 and 3 we can use LLC primitives to send MIH message over
> the
> > > data plane. For L3 transport, I guess MIH messages can be
> > transported
> > > using an implementation specific access point (e.g. socket), since
>
> > > their is no such thing as a SAP within IETF.
> > >
> > > I think we should separate interactions that deal with the
> > local MIH
> > > message passing (i.e. MIH_X primitives that MIH users will use and
>
> > > Link_X primitives the MIH Function will use) from the interactions
>
> > > that deal with the MIH message transport (i.e. Media (or
> Transport)
> > > Specific facilities the MIH Function will use to transport
> > MIH messages).
> > [Vivek G Gupta]
> > MIH protocol shall only use MIH messages and not Link layers
> > messages (since link layer messages shall be local only).
>
> > There is a lot of similarity in naming between Table-8 and
> > Table-13 in the draft (SAP primitives and actual MIH
> > messages) which may not be a bad thing.
>
> The issue is not whether this is bad or good.
> Clearly representing the MIH protocol messages not to be confused with
> local primitives needs to be done.
>
> --Junghoon
>
[Vivek G Gupta]
Absolutely.
Initially link layer messages could also be remote and that was adding
to confusion. Things should get better with clear separation of
primitives and clarity in what is local and what can be remote. I agree
that it is the representation and definition of protocol messages that
has to be updated as opposed to just the naming.
Best Regards
-Vivek