This is a re-review of this document. The document incorporates some of my suggestions from the previous round. Tom Yu writes: > The Security Considerations section states: > > The security considerations of the Diameter Base protocol [RFC3588], > Diameter EAP application [RFC4072], Diameter NASREQ application > [RFC4005] and Diameter Mobile IPv6 integrated scenario bootstrapping > [RFC5447] are applicable to this document. > > Should a reference to RFC 4832 (Security Threats to NETLMM) be > included here? There appear to be no obvious additional security > considerations beyond those mentioned in the above documents. (if > including the suggested additional citation) There has been no change in this area. Do the authors feel that the additional reference to "Security Threats to NETLMM" is not necessary? > In general, the Diameter messages may be transported between the HA > and the Diameter server via one or more AAA brokers or Diameter > agents. In this case the HA to the Diameter server AAA communication > rely on the security properties of the intermediate AAA brokers and > Diameter agents (such as proxies). > > "HA" as used above is not defined in the document, and is used nowhere > else in the document. Is it a Home Agent? (which is not really > otherwise mentioned in this document) This is also unchanged. It would be useful to clarify if the HA is a Home Agent, Home AAA Server, etc. > Editorial: > > "DER" and "DEA" are not defined. I am fairly sure that "DER" does not > mean "Distinguished Encoding Rules" in this document. This has not been fixed. After further investigation, it seems that these mean "Diameter EAP Request" and "Diameter EAP Answer" as defined in RFC 4072. Although the acronyms are defined in a normative reference, and may be obvious to readers already knowledgeable about the subject, please consider expanding them in this document at least once. > The caption for Figure 4 crosses a page break, making it appear > truncated. This appears to have been fixed. > draft-ietf-netlmm-pmip6-ipv4-support is now on revision #14, but is > cited as "-11". This appears to have been fixed.