Subject: [Gen-art] Gen-ART review of draft-ietf-netlmm-pmipv6-heartbeat-04.txt

From: "Miguel A. Garcia" <[email-masked]>
Date: Thu, 26 Feb 2009 15:41:44 +0100

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-netlmm-pmipv6-heartbeat-04.txt
Reviewer: Miguel Garcia <[email-masked]>
Review Date: 2009-02-26
IETF LC End Date: 2009-03-03
IEST Telechat date: 2009-03-12

Summary: The document is ready for publication as a Standards track RFC.

There are no issues in the document, however, a few editorial comments.

- Figures: it would be nice to include a Figure number and a caption in 
each figure. This makes life easier if another document needs to refer to 
such figure, so that document could say "According to Figure 2 in RFC 
xxxx..."

- The first figure in Section 3.3 lacks the numbers that represent the 
order of bits in the figure.

- idnits reports that RFC 4887 (an informational document) is referred to 
as a normative document. I think RFC 4887 should be an informational 
reference.

- I noticed that IANA has correctly understood the intended actions. 
However, I think the text in the draft is a bit cryptographically 
encrypted. I would have removed references to the registry created by RFC 
3775 and instead I would have mentioned the registry by name: "Mobile 
IPv6 parameters registry, Mobility Header types for the MH Type field in 
the mobility header subregistry". Long, but precise.

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 26 Feb 2009 13:45:18 -0800

Hi Miguel,

Miguel A. Garcia wrote:
> each figure. This makes life easier if another document needs to refer 
> to such figure, so that document could say "According to Figure 2 in RFC 
> xxxx..."
> 

Fixed both.

> - idnits reports that RFC 4887 (an informational document) is referred 
> to as a normative document. I think RFC 4887 should be an informational 
> reference.

I made a mistake here. I wanted to refer to RFC 4877, not 4887. RFC 4877 
is the right one that describes how to use IKEv2/IPsec to secure 
mobility header messages. 4877 is a Standards Track document. Thanks!

> encrypted. I would have removed references to the registry created by 
> RFC 3775 and instead I would have mentioned the registry by name: 
> "Mobile IPv6 parameters registry, Mobility Header types for the MH Type 
> field in the mobility header subregistry". Long, but precise.

Does it matter? I have used the same style in the past in other 
documents that have defined new mobility header messages types and new 
mobility options. IANA seems to be fine with this....

Vijay