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

Re: [STDS-802-21] Comments on 21-12-0067-01-srho-tgc-proposal



Hello Pete,

In general, I am O.K. with removing .confirm, but I reckon the .response message
would often be useful.

Your point about generalizing the link-layer frame message to enable signaling unrelated to authentication is also valid I think. However, unless there is a particular case within the jurisdiction of 802.21 for doing so, I'm not sure if
there is any process that we could charter for that purpose.

If you mean to say that we only need a single message for any generic
cross-domain link-layer communication, I'm intrigued but haven't spent
enough time thinking about it to decide.  Do you think we should have
a discussion about it?

Regards,
Charlie P.

On 7/3/2012 11:13 AM, Peter McCann wrote:
Hi, Charles,

What do you think about eliminating the .response and .confirm primitives
from the link layer transfer?

I read 802.21a which contains Auth Request/Response messages and I guess
Yoshi is saying that was the inspiration for making separate link layer
frame request/responses.  However, I don't see why we have to do this.

There may be reasons other than authentication to send a link-layer frame
to a remote PoA.  The setup of the link may involve several messages
prior to or after authentication.  It would seem appropriate to have a
generic way to carry these messages.

-Pete

Charles E. Perkins wrote:
Hello Pete,

I am in agreement with Yoshi on all of these points.  They should be
reflected in the next revision of the proposal.

Would you be willing to review the diagrams and make suggestions about
how they might be clearer?  It seems to me that the differences
between the various scenarios could be highlighted somehow, or
irrelevant detail omitted, so that the main points are easier to grasp.

Regards,
Charlie P.


On 7/2/2012 4:39 PM, Yoshihiro Ohba wrote:


	Hi Pete,

	Thank you very much for reviewing the document.

	Please see my comments below.

	(2012/07/03 4:55), Peter McCann wrote:

		Hi,

		I had promised to send some review comments on this document.


		In Section 3, the acronym "MN" is expanded to mean "Mobile Network."
I think
		you meant, "Mobile Node?"

	I think it should be "Mobile Node".


		After reviewing the base 802.21 specification, I think the use of
the primitives
		is mostly correct; however, some of the description in the text is a
bit wrong.

		For example, you say in Section 7.4.29.1.1 that the function of the
		MIH_LL_Transfer.request primitive is to carry link-layer frames
between the 		MN and the serving PoS.  This is incorrect.  It only
carries the link-layer 		frames between the MIH user and the MIHF.  It
is the corresponding message 		in Section 8.6.3.24 that actually carries
the frames to the new PoS via the 		existing network.  This message is
generated by the MIHF after receiving 		an invocation of the
MIH_LL_Transfer.request primitive from the MIH user.


	You are right.  I think Section 7.4.29.1.1 has to be revised as you
	pointed out.


		In Section 7.4.29.1.3: you say that the primitive is generated by an
MIH user
		to start an authentication and association process based on
link-layer frames.
		Do you really need to be so specific?  This is a general- purpose
primitive for
		sending link-layer frames for any purpose whatsoever, isn't it?

	AFAIK, the discussed use of the primitive is pre-registration, and
	sending link-layer frames for any purpose using this primitive has not
	been discussed.  If we expand the usage to allow sending any LL frame
	then the text should be revised.  But we need to agree on expanding
	the usage first.


		Section 7.4.29.1.4: you say the MIH_LL_Transfer.indication is used
by a remote
		MIHF.  I don't think you need to specify that it is a "remote" MIHF.
You just
		need to say that it is used by an MIHF to notify the local MIH user
about the
		receipt of an MIH_LL_Transfer request message.

	I agree.  The text needs to be revised as you suggested.


		I do not think you need to specify the corresponding .response and
.confirm 		messages.  The transfer of a link-layer frame is a one-way,
unreliable operation 		that does not always generate a response.
Specifying a .response just seems 		redundant; the MIH user that
receives an .indication can always generate a 		brand new .request
primitive to transfer a link layer frame in the other 		direction.

	The reason for having .response and .confirm primitives in
	MIH_LL_Transfer is basically inherited from 802.21a MIH_LL_Auth.

	I would say the design depends on whether the use of MIH_LL_Transfer
	is for pre-registration only or for carrying any link-layer frame.


		Similarly, I think you can do away with the
MIH_N2N_LL_Transfer.response and
		.confirm primitives.

	Again the design depends on whether the use of MIH_LL_Transfer
	is for pre-registration only or for carrying any link-layer frame.

	Best Regards,
	Yoshihiro Ohba




--
Regards,
Charlie P.