Subject: Re: Gen-ART LC review of draft-atlas-icmp-unnumbered-06

From: Ben Campbell <[email-masked]>
Date: Tue, 17 Mar 2009 14:05:02 -0500

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-atlas-icmp-unnumbered-06
Reviewer: Ben Campbell
Review Date: 2009-03-07
IETF LC End Date: 2009-04-06
IESG Telechat date: (unknown)

Summary:

I previously reviewed this draft in it's first IETF LC. Further  
correspondences with the authors addressed all of my comments, however  
as far as I know the draft has not been updated. I pasted in my  
previous review below for reference.

Thanks!

Ben.

On Jan 8, 2009, at 4:39 PM, Ben Campbell wrote:

> 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-atlas-icmp-unnumbered-06
> Reviewer: Ben Campbell
> Review Date: 2009-01-08
> IETF LC End Date: 2009-01-27
> IESG Telechat date: (unknown)
>
>
>
> Summary: This draft is very close to ready for publication as a  
> proposed standard. I have a couple of minor comments and questions  
> that should be considered prior to publication, and some editorial  
> nits.
>
> Substantive Comments:
>
> -- Section 4.1, definition of Next-Hop flag: "This MUST be clear  
> unless the Interface Role is 3, indicating an outgoing interface."
>
> The interface role definition listed the value for outgoing  
> interface to be "1". Am I misreading something?
>
> -- Security Considerations:
>
> Are there any concerns about the extension data being available to  
> intermediary devices? Is there any concern about unauthorized  
> modification of the extension data (beyond what is mentioned in the  
> NAT section)? (I'm not saying they are concerns--just checking to  
> see if they have been thought about.)
>
>
> Editorial Comments:
>
> -- Abstract:
>
> Please expand acronyms on first use for MIB and OSPF. ( ICMP is  
> probably well known enough to skip expanding.) The Abstract should  
> stand alone; even though they may be expanded in the body, they  
> should be expanded here.
>
> -- Section 2:
>
> Please expand ECMP on first use.
>
> -- 6th paragraph from end of section:
>
> s/permit/permits
>
> -- Section 4.3, between figure 3 an figure 4:
>
> It's not clear from the formatting if the line "Class-Num = 2" is  
> part of figure 4, part of the caption for figure 3, or just orphaned.
>
> -- Section 4.3, Figure 4:
>
> I find it confusing to have all the examples in a single figure. I  
> think it would be easier to read if you split them up.
>
>
> -- idnits reports the following:
>
>  ** It looks like you're using RFC 3978 boilerplate.  You should  
> update this
>     to the boilerplate described in the IETF Trust License Policy  
> document
>     (see http://trustee.ietf.org/license-info), which is required from
>     December 16, 2008.  Version 1.34 of xml2rfc can be used to produce
>     documents with boilerplate according to the mentioned Trust  
> License
>     Policy document.
>
> ... and ...
>
>  == Outdated reference: A later version (-11) exists of
>     draft-ietf-behave-nat-icmp-10
>
>