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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thanks for the review - I'll fix it up.

Alia 

> -----Original Message-----
> From: Ben Campbell [mailto:ben@xxxxxxxxxxxx] 
> Sent: Thursday, January 08, 2009 5:40 PM
> To: General Area Review Team; enkechen@xxxxxxxxx; 
> naiming@xxxxxxxxx; rbonica@xxxxxxxxxxx; Atlas,AK,Alia,DMF R
> Cc: jari.arkko@xxxxxxxxxxxx; ietf@xxxxxxxx
> Subject: Gen-ART LC review of draft-atlas-icmp-unnumbered-06
> 
> 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
> 
> 
> 
_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]