On Sun, 18 Mar 2007, Alia Atlas wrote:
For a slightly different approach at the problem, take a look at
draft-atlas-icmp-unnumbered-02.txt. It has the ability to report on
what would have been the outgoing interface, as well as the incoming
interface. The information can include an ifIndex, an IP address,
and a brief string description.
I'd be very interested in your feedback.
The draft is unclear wrt 'description'. It says that it SHOULD report
'ifName' but other info can be reported as well. This is very
confusing as 'description' has established meaning in the ops
community and that meaning is NOT ifName. The object should be named
'Interface name' (ifName) because that's distinct from description
(ifAlias).
I'd very strongly object to reporting 'description' (ifAlias). In
deployments I've seen this often includes confidential information
(e.g., customer numbers, link identification numbers, etc.). I
suggest rephrasing this so that the name of the object is 'Interface
name' (ifName). If description (ifAlias) would be retained, the spec
should require that by default it MUST NOT be reported.
In general, I find the specification having features that I don't see
necessary. Reporting ifIndex is not necessary (and the index is not
very useful as is to a human) if ifName is reported. Addresses are
already known from the source address though somewhat less reliably so
those need not be reported for outgoing interface use, and could also
result in reporting IPv6 link-local addresses (or IPv4 private
addresses) which wouldn't necessarily be useful or desired.
There also seems to be some specification about incoming/outgoing
interface (which is probably why addresses are supported). This is
distinct from what draft-watkins-icmptype11code0 is about because that
draft reports next-hops which this doesn't do.
Personally, I'd prefer seeing either one big document or two
documents, one describing 'ifName' reporting and one describing IP
address reporting (nexthop, possibly input/output interface).
Currently input/output address reporting seems to be out of scope of
this draft though: the title, draft name, abstract, etc. don't reflect
these address extensions (meant to identify the incoming interface) so
some rewording at the very least is needed there.
As a more editorial issue, the first two paragraphs could maybe use
slight modification to better account for IPv6 (e.g., ref to ICMPv6
spec). As a detail, source address selection for ICMPv6 is specified
slightly differently, but it's spec-compliant to do it the same way as
for IPv4. It's not guaranteed though.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
