Internet Protocols for the Smart Grid
draft-baker-ietf-core-15

None of the comments below taken alone is discuss-worthy, but I do think at least several of them should really be addressed.

Section 2.1.2., paragraph 3:
>    For example, TCP will
>    reduce rate to avoid loss, while DCCP accepts some level of loss if
>    necessary to maintain timeliness.

  TCP doesn't really reduce its rate to avoid loss - it uses loss as an
  indication for congestion, and basic congestion control principles
  mandate a rate reduction. DCCP does the same - the difference is that
  DCCP will not bother to retransmit lost data while TCP will.


Section 3.2.2.3., paragraph 3:
>    In that research, the IETF imposed guidelines [RFC2357] on the
>    research community regarding what was desirable.  Important results
>    from that research include a number of papers and several proprietary
>    protocols including some that have been used in support of business
>    operations.  RFCs in the area include The Use of Forward Error
>    Correction (FEC) in Reliable Multicast [RFC3453], the Negative-
>    acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol
>    [RFC5740], and the Selectively Reliable Multicast Protocol (SRMP)
>    [RFC4410].  These are considered experimental.

  This section has outdated information. NORM is now PS (RFC 5401), and
  FLUTE is almost there (IETF LC of draft-ietf-rmt-flute-revised is
  imminent). Reliable multicast is not experimental anymore.


Section 3.3.2., paragraph 2:
>    it delivers data to its peer and provides acknowledgement to the
>    sender, or it dies trying.  It has extensions for Congestion Control
>    [RFC5681] and Explicit Congestion Notification [RFC3168].

  As well as many other extensions - it may be useful to cite RFC 4614
  here.


Section 3.3.2., paragraph 3:
>    For message-stream interfaces, we generally use the ISO
>    Transport Service on TCP [RFC1006][RFC2126] in the application.

  Who is "we"? Is anyone really using RFC1006 and RFC2126?


Section 3.3.2., paragraph 5:
>    Finally, note that TCP has been the subject of ongoing research and
>    development since it was written.  The End to End research group has
>    published a Roadmap for TCP Specification Documents [RFC4614] to
>    capture this history, to guide TCP implementors, and provide context
>    for TCP researchers.

  RFC 4614 did not come out of end-to-end, it was a WG document in TCPM.
  And while it does capture some of the history and research aspects,
  the motivation was very much to be a "start reading here" document for
  implementors, similar in spirit to this I-D.


Section 3.6.2., paragraph 8:
>    The Constrained Application Protocol (CoAP) [I-D.ietf-core-coap] is
>    being developed in IETF with these goals in mind.

  I'm surprised to see that COAP is only mentioned under resource
  discovery. While that's one aspect of it, the broader aspect is as an
  application/transport protocol for constraint environments. IMO it
  would make more sense to discuss COAP under Section 3.3 or 3.3.1.


Section 4., paragraph 0:
> 4.  A simplified view of the business architecture

  At least to my mind, it would be a bit more logical to see this
  section merged into Section 2 or following it. (Also, it'd be nice to
  replace domain names and IP addresses in this section with ones from
  the "example" spaces.)


Section 5., paragraph 1:
>    This memo asks the IANA for no new parameters.

  Although this document makes no requests from IANA, I wonder if the
  smartgrid guys know about the role that IANA plays in the
  standardization and administration of the IPS. Is there an IANA
  overview document that you could cite here for them to read?


Section 8., paragraph 0:
> 8.  References

  Is there a logic to the split between normative and informative
  references?


Appendix A., paragraph 1:
>    This appendix provides a worked example of the use of the Internet
>    Protocol Suite in a network such as the Smart Grid's Advanced
>    Metering Infrastructure (AMI).  There are several possible models.

  I don't think this example is worked out enough to illustrate how the
  IPS can be applied here. There's a little bit of text about layer 3,
  and nothing at all about higher layers. I wonder if this material
  would be better split off into a standalone document for further
  development.

---

Section 2.2., paragraph 1:
>    solutions to many Internet security problems have already exist.

  Nit: s/have//


Section 2.2.1., paragraph 3:
>    For wirless transmission technologies eavesdropping on the

  Nit: s/wirless/wireless/


Section 3.2.3.1., paragraph 1:
>    Autoconfiguation enables various different models of network

  Nit: s/Autoconfiguation/Autoconfiguration/


Section 802.11, paragraph 0:
>    networks between various sensors in the home (e.g., betweeen the

  Nit: s/betweeen/between/

#1) Politics layer is missing from Figure 1 ;)

#2) <nit alert>r/"host./"host."</nit alert>

#3) Could we point to SNMPv3 instead of v1? (i.e., something that's not historic)

#4) Is it worth mention HIP at all or the concept of splitting the identifier and locator?  It's experimental so maybe not.

#5) Is it worth adding an informative reference to https://datatracker.ietf.org/doc/draft-ietf-tcpm-tcp-security/ in 2.2.2 where it talks about TCP attacks/counter measures?  Also maybe pointing to https://datatracker.ietf.org/doc/draft-ietf-opsec-ip-security/ for IP attacks/counter measures would be helpful.

#6) Section 3.1.1: can we also add EAP-TLS:

   For access to remote
   networks, such as enterprise networks, the ability to utilize EAP
   within IKEv2 [RFC5996] and within TLS [RFC5216] have also
   been developed.

#7) While the Suite B IPsec profiles are near and dear to my heart, I'm not sure they need to be included in Sec 3.1.2.

#8) Sec 3.1.3: It's probably worth noting that TLS supports hop-by-hop security and depending on the architecture this might not be end-to-end (i.e., TLS isn't one size fits all).

#9) Sec 3.1.4: for truth in advertising:

  The CMS can support a variety of
   architectures for key management included: certificate-based key
   management, such as the one
   defined by the PKIX (Public Key Infrastructure using X.509) working
   group [RFC5280], or symmetric key management.

#10) Sec 3.1.4: Should also add that a variety of algorithms are supported:

  CMS supports a number of algorithms: RSA, DSA, DH, ECDSA,
   and ECDH as well as the SHA family of algorithms.


#11) Sections 3.1.2-3.1.4: When renaming 3.1.4 to "Application Security" makes me think that 3.1.2 should be called "Network Security" and 3.1.3 should be called "Transport Security".  Then put SSH in 3.1.3 (maybe no need for a new 3.1.6 as Tim suggests).  Could have two subsections.

#12) I think this needs to be updated:

  Note that since IPv4 free pool (the pool of available, unallocated
   IPv4 addresses) is almost exhausted,