Hi, 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.
Generally, the document is well written and the following are suggestions to improve the document. There is no show stopper in the document itself but I feel it is sometimes a bit unbalanced regarding detail, explanation and recommendation of the various protocols presented. I hope these comments are helpful. General observations: You lack a definition of what the Smart Grid is. You clearly write the document for Smart Grid folks (they should know what Smart Grid is) but is there a generally accepted definition of what the Smart Grid consists of, what the requirements are, what the technological assumptions are etc? If there is such a document then you should reference it, otherwise you should state in the document what you think the Smart Grid is and why these Smart Grid folks need this document. This would also explain why you have included certain things and left other things out (which is something I couldn't tell from the document). As an example, in Section 2.3 you write "While the following protocols are not critical to the design of a specific system, they are important to running a network, and as such are surveyed here." What is the relevance to Smart Grid? Why is only DNS and Network Management mentioned? Having text that explains what the Smart Grid is makes it much easier to understand why you included these specific things in the document. Section 2.2.: I am not a security expert but I find either the title of the section wrong or the list not quite right. So the section is about authentication and a requirement is the "protection of the channel against DoS". I believe that is not part of authentication. The same applies to integrity. Maybe you just want to refer to some of the RFC 4949 definitions here? Generally, I find the security section less coherent than the preceding sections. Section 2.3: I think you conflate confidentiality and privacy here (but again, please check with a sec person). I am also not sure what you want to express with the last sentence. (Or how it would work in practice). Section 4: I don't see much value in this section. At least, it is not well titled as is mainly talks about firewalls and NATs. Also, if you decide to keep the section, you might want to change the examples to something less real by using RFC 5737 IP addresses. Other technologies: could delay tolerant networking be of interest. After all, the Core charter says that devices may be off at any time. Nits: Section 2.1: s/While Internet architecture/While the Internet architecture/ Section 2.1: move "(ISO-OSI)" to come right after "Interconnect" Section 2.1: s/"host /"host"/ Section 2.1: s/"internet gateway"/"Internet gateway"/ Caption figure 1: s/ISO OSI/ISO-OSI/ (at least the rest of the text uses that spelling) Figure 2: You use slighlty different terminology from RFC 1122 and RFC 1812. Is that intentional? Section 2.1.2: s/to large extent/to a large extent/ Section 2.1.2: The session identification in an IP datagram is often called the "five-tuple" (I personally would use flow instead of session) Section 2.1.3: s/is the network that/is the network protocol that/ Section 2.1.3.1: s/network abstraction network/network abstraction/ Section 2.1.3.1: s/those protocol/those protocols/ Section 2.1.4: s/IPv4 and IPv6 various media types/IPv4 and IPv6 over various media types/ Section 3.1.2: s/Header (AH) [RFC4302]/Header (AH) [RFC4302],/ Section 3.2: s/since IPv4 free pool/since the IPv4 free pool/ Section 3.2.1.3: s/some networks site networks/some site networks/ Section 3.2.2: s/dropped../dropped./ Section 3.2.2.1: s/using Address Resolution Protocol/using the Address Resolution Protocol/ Section 2.2.2.2: You write: "Active research exists in mobile ad hoc routing and other routing paradigms; these result in new protocols and modified forwarding paradigms." This (or a similar) statement applies to all other protocols that you mention in the document but you do not mention ongoing research. Why is this statement more relevant to routing v4? Section 3.2.4.3: expand CLNS Section 3.2.4.6: s/between device/between devices/ Section 3.2.5.1: s/A the highest/At the highest/ Section 3.2.5.1: s/SSM has inherent/SSM has an inherent/ Section 3.3: s/that built for/that were built for/ Section 3.3.1: s/properly not/probably not/ Section 3.4.3: s/The current versions of the time protocol are/The current version of the time protocol is/ Section 3.7.2: s/Representation [I-D.daboo-et-al-icalendar-in-xml]/Representation [I-D.daboo-et-al-icalendar-in-xml]./ Section 4: s/address/aport tuples/address/port tuples/ Section 4: s/the internet backbone/the Internet backbone/ NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
