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

[Naiming Shen <naiming@xxxxxxxxx>]

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:

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