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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf