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-dir(_at_)ietf(_dot_)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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf