Re: TSVDIR Review for draft-ohba-pana-relay-03
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
TSVDIR Review for draft-ohba-pana-relay-03
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? 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? 3) Is it possible to place a PRE behind NAT? Is there any concern for this? 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? Regards, -- Yoshifumi Nishida nish...@sfc.wide.ad.jp ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSVDIR Review for draft-ohba-pana-relay-03
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
