Subject: [Gen-art] Gen-ART LC review of draft-atlas-icmp-unnumbered-06

From: Ben Campbell <[email-masked]>
Date: Thu, 8 Jan 2009 16:39:49 -0600

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

_______________________________________________
Gen-art mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/gen-art

---

From: <[email-masked]>
Date: Fri, 9 Jan 2009 01:05:17 -0000

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

Alia 

> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]] 
> Sent: Thursday, January 08, 2009 5:40 PM
> To: General Area Review Team; [email-masked]; 
> [email-masked]; [email-masked]; Atlas,AK,Alia,DMF R
> Cc: [email-masked]; [email-masked]
> 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.
> 
> 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?
> 
> 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:
> 
> 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.
> 
> 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.
> 
> 
>    ** It looks like you're using RFC 3978 boilerplate.  You 
> should update this
>       to the boilerplate described in the IETF Trust License 
> Policy document
>       documents with boilerplate according to the mentioned 
> Trust License
>       Policy document.
> 
> ... and ...
>

---

From: Naiming Shen <[email-masked]>
Date: Thu, 8 Jan 2009 20:27:52 -0800

Hi Ben,

Thanks for the review.
Just to comment on the "Security Considerations" you referred to below.

Most of those information probably is not sensitive, if a router  
allows a traceroute packet
to go through; Also this draft references to [I-D.shen-udp-traceroute- 
ext],
which gives the responder an option to authenticate the source of
the request, that if used correctly, also implies the intermediate  
devices
between the source and this responder. Or a local policy on the  
responder
can be defined to verify the domain/subnet of a set of addresses which  
are
allowed to receive those sensitive add-on information.

thanks.
- Naiming

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

> NAT section)? (I'm not saying they are concerns--just checking to  
> see if they have been thought about.)
>
>
> Editorial Comments:
>
> -- Abstract:
>
> stand alone; even though they may be expanded in the body, they  
> should be expanded here.
>
> -- Section 2:
>
> 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.
>

---

From: Ben Campbell <[email-masked]>
Date: Thu, 8 Jan 2009 23:25:40 -0600

On Jan 8, 2009, at 10:27 PM, Naiming Shen wrote:

> to go through; Also this draft references to [I-D.shen-udp- 
> traceroute-ext],
> can be defined to verify the domain/subnet of a set of addresses  
> which are

Okay, good enough for me--a sentence or two to that effect might be  
helpful, particularly about intermediate devices.

Thanks!

Ben.