Subject: Re: [Gen-art] 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
>
>

---

From: Jari Arkko <[email-masked]>
Date: Tue, 17 Mar 2009 13:41:17 -0700

Thanks for your review. Alia et al -- can you make the below changes. I 
think you can actually submit a new document version early next week, or 
at least it would be good to get it in before the draft hits the IESG 
two weeks after the IETF.

Jari

Ben Campbell wrote:
>> that should be considered prior to publication, and some editorial nits.
>>
>> Substantive Comments:
>>
>> The interface role definition listed the value for outgoing interface 
>> to be "1". Am I misreading something?
>>
>> NAT section)? (I'm not saying they are concerns--just checking to see 
>> if they have been thought about.)
>>
>>
>> Editorial Comments:
>>
>> -- Abstract:
>>
>>     documents with boilerplate according to the mentioned Trust License
>>     Policy document.
>>
>> ... and ...
>>