tsv-dir review of draft-ietf-karp-threats-reqs-03
Hello folks, 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. Transport Issues: I had some difficulties to grasp the objective of the document, however, I believe it's This document does not contain protocol specifications. Instead, it defines the areas where protocol specification work is needed and sets a direction, a set of requirements, and a relative priority for addressing that specification work. as it is stated in Section 1.3. Along with this context, I can understand section 2 and 3 are written for this purpose. Also, I think there is no specific transport layer concern in this document since there's no detailed discussion for protocol specs. However, if my presumption on the objective of the document is right, I think the title of this draft might not be appropriate. It would be something like The Goal and Requirements for Cryptographic Authentication of Routing Protocols' Transports or The Requirements for Cryptographic Authentication of Routing Protocols' Transports. Because there is not threat analysis in the document. Also, abstract will need to be updated. Other minor comments: As stated above, I have some difficulties to read this document. I think this is likely because I'm not an expected audience for the document. However, if you think some of the following points are also reasonable for some expected audience, please consider updating. 1: I prefer that the objective of the draft is articulated at the beginning of the document. It will be very helpful to read the rest of the document. 2: I think it would be better to separate the introduction of this draft and KARP project. For example, it is a bit confusing for me to understand the focus of this draft since it is mixed with the focus of the KARP in Section 1.3. I think Section 1.1, 1.2 and 1.7 can be put in the introduction of this draft and 1.3, 1.4, 1.5, 1.6 can be put in another section which describes the overview of KARP. 3: I think it depends on the objective of the draft, but I feel some texts in Section 1 is not necessary for this draft. For example, I'm not very sure the audience of this doc need to read Section 1.4. Also, Section 1.5 seems to be too long. There are also many mentions about roadmap in this draft, but I'm not very sure these are necessary since this is not a roadmap document. (Hence, I don't understand the meaning of this roadmap document. ) 4: Section 3 only describes the requirement for Phase 1. Will be there another document for Phase 2 or we don't need it? 5: 24 requirements seems to be too many to check easily. I think it would be better to categorize them in some ways. (priority? protocols? approach?) Thanks, -- 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
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-ietf-netext-pmip6-lr-ps
Dear Marco, Thanks for your response. 2011/5/2 Marco Liebsch marco.lieb...@neclab.eu: Dear Yoshifumi, thanks a lot for your review. Please find 2 comments inline. 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 describes the problem space for localized routing in PMIPv6, which supports direct communication between MAGs for MN and CN. This draft is basically ready for publication and I couldn't find any transport related issues in the draft. Minor comments: Would it be better to mention error detection and fallback function in Functional Requirements? It would be useful and helpful to fall back to normal routing when something happens. I agree that the solution must provide means to handle such error cases and to step back to non-optimized routing in case there is need. I see these as non-functional requirements, whereas section 4 is about functional requirements only. We could add a functional requirement to 'terminate' localized routing. Example for reasons doing this could be the error case you mention. Does this sound ok? Yes. That works for me. I believe localize routing is very useful in most cases. However, I think there will be the cases where we had better avoid localized routing, such as a case where there are some restrictions (policy, network quality or configuration, etc) in communications between MAGs. It might be better to address having some kind of control to enable localized routing in Functional Requirements in addition to checking source and destination addresses. Section 4, which covers the functional requirements, has a new item listed about enforcement of operator policies to control localized routing. I think that covers your comment. I've checked the new item and I think it covers the comments. Thanks, -- Yoshifumi Nishida nish...@sfc.wide.ad.jp ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
TSVDIR Review for draft-ietf-netext-pmip6-lr-ps
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 describes the problem space for localized routing in PMIPv6, which supports direct communication between MAGs for MN and CN. This draft is basically ready for publication and I couldn't find any transport related issues in the draft. Minor comments: Would it be better to mention error detection and fallback function in Functional Requirements? It would be useful and helpful to fall back to normal routing when something happens. I believe localize routing is very useful in most cases. However, I think there will be the cases where we had better avoid localized routing, such as a case where there are some restrictions (policy, network quality or configuration, etc) in communications between MAGs. It might be better to address having some kind of control to enable localized routing in Functional Requirements in addition to checking source and destination addresses. Thanks, -- Yoshifumi Nishida nish...@sfc.wide.ad.jp ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
