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 nish...@sfc.wide.ad.jp 2011年6月6日5:59 Yoshihiro Ohba <yoshihiro.o...@toshiba.co.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-...@ietf.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 >> nish...@sfc.wide.ad.jp >> > > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
