Hello Ohba-san,
Thank you so much for your quick response.
I agree with your comments and won't have further comments as long as
the doc is updated based on your response.
Regards,
--
Yoshifumi Nishida
nishida(_at_)sfc(_dot_)wide(_dot_)ad(_dot_)jp
2011年6月6日5:59 Yoshihiro Ohba
<yoshihiro(_dot_)ohba(_at_)toshiba(_dot_)co(_dot_)jp>:
Nishida-san,
Thank you very much for reviewing the draft.
Please see my comments below.
(2011/06/06 17:39), Yoshifumi Nishida wrote:
Hello,
I've reviewed this document as part of the transport area
directorate's ongoing effort to review key IETF documents. These
comments were written primarily for the transport area directors, but
are copied to the document's authors for their information and to
allow them to address any issues raised. The authors should consider
this review together with any other last-call comments they
receive. Please always CC tsv-dir(_at_)ietf(_dot_)org if you reply to or
forward
this review.
Summary:
This draft specifies protocol for PANA Relay Element that can relay
messages between a PaC and a PAA where they cannot reach each other.
The proposed function is simple and straightforward and useful.
I couldn't find any transport related issues in the draft.
Minor comments:
Please consider clarifying the following points.
1) I think clarifying communication model of this proposal will be
helpful for readers.
It seems to me that a PRE should communicate only one PAA. But, can a
PAA
communicate multiple PREs?
PANA allows multiple PAAs in an access network. For example, RFC 5192
defines a DHCP option to carry a list of PAA addresses and a PaC will
choose one PAA to communicate with. Similarly, there can be multiple
PAAs in an access network with PREs. In this case, a PRE will choose
one PAA to communicate with for a given PaC. Next, a PAA can
communicate with multiple PREs. We can clarify these in the draft.
2) The draft seems to presume PRE to be a multi-homed node. But, is
this mandatory
requirement? Is it possible to use single-homed node as a PRE?
You are right, PRE can be either single-homed or multi-homed. In
fact, in ZigBee IP, each mesh router is a PRE having a single 802.15.4
radio interface. We can clarify this in the draft as well.
3) Is it possible to place a PRE behind NAT? Is there any concern for this?
There are two cases, (i) a NAT between a PaC and a PRE, and (ii) a
NAT between a PRE and a PAA. I don't see a NAT issue specific to PANA
relay for both cases.
4) How p2 (PRE-assigned UDP port number) is determined? Is it possible to
use
ephemeral port? If so, the protocol will need to be robust
against PRE rebooting.
Similarly, can we use dhcp-ed address for IP2b?
Yes, p2 can be ephemeral. Since a PAA just uses the UDP and IP
headers received from the relay to generate UDP and IP headers of its
response PRY to the relay, I think the protocol is robust against PRE
rebooting. For the same reason, use of DHCP-ed address for IP2b
works. Even when IPsec is used between a PRE and a PAA, I think
DHCP-ed address for IP2b works as long as IKEv2 identity for the PRE
is not based on IP address.
Kind Regards,
Yoshihiro Ohba
Regards,
--
Yoshifumi Nishida
nishida(_at_)sfc(_dot_)wide(_dot_)ad(_dot_)jp
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf