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

From: <[email-masked]>
Date: Sun, 27 Dec 2009 17:52:38 -0500

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-08
Reviewer: David L. Black
Review Date: December 27, 2009
IETF LC End Date: January 1, 2010

Summary:
This draft is on the right track, but has open issues, described
in the review.

Comments:
The draft defines an extension to ICMP messages that allows additional
network interface information to be provided with some ICMP messages.
The information may be an ifIndex, an IP address, an Interface Name
and/or an MTU.

The one open issue in this review involves the use of ifIndex to
identify an interface.  The motivating use cases in section 3
involve traceroute, ACL-caused-blockage, and the need to determine the
MTU - those use cases are "public" in the sense that they clearly
encompass use of the ICMP messages by other than the network operator
whose device generated those messages.

In this context, IP address, Interface Name and MTU are all clearly
useful, but I am concerned about ifIndex.  An ifIndex is effectively
private to the SNMP management infrastructure of the network operator.
Determining what interface an ifIndex designates generally involves
SNMP access that a network operator may be reluctant to grant to
outsiders due to the level of detail that such access may expose.

I suspect that the ifIndex could be *very* useful to an ifIndex-
enhanced traceroute issued from a network operator's management station
as alluded to in paragraphs 3-5 of Section 6 (Security Considerations).
My open issue is that I should have to go all the way down to the latter
part of the Security Considerations section in order to find the
motivations for and intended usage of one of the major features of this
extension.

I suggest adding a Section 3.3 to discuss use of ifIndex with ICMP and
network management tools (e.g., enhanced traceroute plus an SNMP
manager)
by a network operator to debug his/her own network.  This new section
should also contain some sort of warning that ifIndex information may
not be available to other than the network operator's management
applications (with a pointer to the Security Considerations section).

Nits:
- Section 2: "o  that interface is numbered"  Please add a definition
	of "numbered" for an interface.
- Section 4.1: Explain what a C-Type is.  A few words and a reference
	to Section 8 of RFC 4884 should suffice.
- Section 5.4: This appears to be poorly stated:
   A single instance of IP Address information MAY be included only in
   the following circumstances:

   Included in what?  I presume an Interface Information Object.  Also,
   MAY ... only is poor usage of RFC 2119 terminology.  Here's an
attempt
   at better phrasing:  

   When an Interface Information Object contains an IP Address, one of
   the following two conditions MUST be true:

idnits 2.11.15 did not find any nits.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: <[email-masked]>
Date: Sun, 27 Dec 2009 18:02:49 -0500

And the draft needs a new email address for JR:

Your message did not reach some or all of the intended recipients.

      Subject:	Gen-ART review of draft-atlas-icmp-unnumbered-08
      Sent:	12/27/2009 5:53 PM

The following recipient(s) cannot be reached:

      [email-masked] on 12/27/2009 5:54 PM
            The e-mail system was unable to deliver the message, but did
not report a specific reason.  Check the address and try again.  If it
still fails, contact your system administrator.
            < sj-inbound-d.cisco.com #5.0.0 smtp; 5.1.0 - Unknown
address error 550-'5.1.1 <[email-masked]>... User unknown' (delivery
attempts: 0)>

Thanks,
--David

> -----Original Message-----
> From: Black, David
> Sent: Sunday, December 27, 2009 5:53 PM
> To: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked];
> [email-masked]'
> Cc: Jari Arkko; Black, David
> Subject: Gen-ART review of draft-atlas-icmp-unnumbered-08
> 
manager)
attempt

---

From: Carlos Pignataro <[email-masked]>
Date: Sun, 27 Dec 2009 20:22:53 -0500

David,

Thank you for your time to review, please see inline.

> whose device generated those messages.

I disagree with the intrinsic '"public"' nature and the 'clearly' use
you mention; and so does the I-D, as the Security Considerations section
explicitly negates what you are saying here.

Moreover, the motivation is not (as you say) in the use cases in Section
3. The motivation is spelled out in the Introduction (ifIndex identifies
an unnumbered interface within the router). Section 3 provides exemplary
(and not all inclusive) use cases.

> motivations for and intended usage of one of the major features of this

OK, so your open issue is that the security concern is addressed in the
Security Considerations? Existing text addresses your concern. We expect
implementors to read the complete spec, including the Security
Considerations. And folks will not implement a spec without
understanding its use.

The details: The motivation is in Section 1, Introduction:

   If all of the following conditions are true, the source address of
   the ICMPv4 message identifies the interface upon which the original
   datagram arrived:

   o  the device sends an ICMPv4 message through the same interface upon
      which the original datagram was received
   o  that interface is numbered

   However, the incoming and outgoing interfaces may be different due to
   an asymmetric return path, which can occur due to asymmetric link
   costs, parallel links or Equal Cost Multipath (ECMP).

and the concern you raise is explicitly addressed in the spec:

   It may be desirable to provide this information to a particular
   network's operators and not to others.

> network management tools (e.g., enhanced traceroute plus an SNMP

Thank you for the suggestion.
I strongly disagree with this suggestion.

I highly suspect that doing so would be harmful to the spec, as it would
(implicitly) limit the scope of applicability and use of the extension.
We do not what to spell out potential uses in so much detail, as they
would become obsolete before the spec is. And we do not want to pretend
we cover all use cases.

> applications (with a pointer to the Security Considerations section).

This is understood from the definition (and _Normative_ citation
pointer) of ifIndex in the spec. It would be, IMHO, redundant and
therefore be another distraction to the reader.

> 	of "numbered" for an interface.

We could add a pointer to [RFC1812], although I really do not think it
is needed. There is ample precedence that this is not needed, e.g., OSPF
RFCs like RFC2328, RFC5185, etc, etc.

> 	to Section 8 of RFC 4884 should suffice.

Again we could add it but... RFC4884 is a _normative reference_, meaning
that (from RFC3967]:

   normative reference specifies a document that must be read to fully
   understand or implement the subject matter in the new RFC, or whose
   ...

Therefore, not needed, as it is defined in the Normative reference.
Another data point, IANA understood waht was meant.

> - Section 5.4: This appears to be poorly stated:

There is no Section 5.4 in the document... I suspect you meant Section 4.5.

>    Included in what? 

It is, I think, self-evident when read in context (including previous
sentence):

   more than one instance of each of these three information
   elements MUST NOT be included per Interface Information Object.

We can s/be included/be included in an Interface Information Object/ at
expense of being repetitive.

> I presume an Interface Information Object.  Also,
>    MAY ... only is poor usage of RFC 2119 terminology.

Why? We are saying that the item (an IP Address information element) is
truly optional, and the definition of MAY says:

   5. MAY This word, or the adjective "OPTIONAL", mean that an item is
      truly optional...

So how is the usage poor?

>  Here's an

Thank you for the suggestion, we will consider it as a nit.

> idnits 2.11.15 did not find any nits.

Ack.

Again, thank you for the time and review !

-- Carlos.

---

From: Carlos Pignataro <[email-masked]>
Date: Sun, 27 Dec 2009 20:24:00 -0500

[adding JR to Cc:]

> And the draft needs a new email address for JR:

Yes, we will fix this before publication.

Thanks again,

-- Carlos.

---

From: Carlos Pignataro <[email-masked]>
Date: Mon, 28 Dec 2009 11:48:56 -0500

David,

Please find one additional comment response to your suggestion.

> network management tools (e.g., enhanced traceroute plus an SNMP

I still feel that discussing this use would be a strong distraction and
divertion, and not add substativeness to the spec, ultimatelly causing
confusion.

My traceroute app at home does IP address-to-name mapping, querying DNS
and reporting hostnames; ICMP timexceeded was not spec'ed that way, but
a 'traceroute + hostname manager querier' was useful. It also does:
      -A: Report AS# at each hop (from GRR)
      -O: Report owner at each hop (from DNS)

because it was useful, and reports TOS change, none of which was
including on the ICMP timeexceeded or unreachable definitions.

A public use of the ifIndex can be to see different interfaces in a
router, seeing ECMPs with unnumbered, and not mapping them to an
interface name with an SNMP manager. That is a degree of idenfication,
to know they are different.

Describing an app like you suggest would implicitly limit, I think. We
are not spec'ing an application, only the extensions of ICMP, and it
seems to me that there is enough contextual applicability and motivation
(without falling into over-framing and under-scoping).

Thanks,

-- Carlos.

---

From: Carlos Pignataro <[email-masked]>
Date: Mon, 28 Dec 2009 11:58:20 -0500

[apologize, hit send too quickly, wanted to add:]

public traceroute reports:

10  namehidden1 (ipaddress1)  20 ms  55 ms  36 ms
    MPLS Label=698653 Exp=0 TTL=1 S=0
    MPLS Label=301856 Exp=0 TTL=1 S=1
11  namehidden2 (ipaddress2)  45 ms  52 ms  50 ms
    MPLS Label=323717 Exp=0 TTL=1 S=0
    MPLS Label=301856 Exp=0 TTL=2 S=1

But RFC4950 does not prescribe a traceroute + LIB/LFIB manager, which I
think would be analogous.

Thanks,

-- Carlos.

---

From: <[email-masked]>
Date: Mon, 28 Dec 2009 13:59:45 -0500

Carlos,

I think you're getting carried away.  I would like to see some text
explaining why the ifIndex is useful in Section 3 rather than having
to go all the way down to the Security Considerations section to
figure out what it's useful for.  It doesn't need to involve SNMP,
more below ...

> explicitly negates what you are saying here.

I don't think so.  In order to restrict use of this extension to within
an operator's network in all cases, the Security Considerations section
would have to contain a MUST or MUST NOT requirement that is not
present.

I suppose adding such a requirement could be an alternative to
explaining
why ifIndex is useful in Section 3, but I don't think such a requirement
would be a good idea (and I'm not asking for one to be added).

> (and not all inclusive) use cases.

I'm sorry, but use cases are part of "motivation".  It would be a
significant improvement to include a use case in Section that involves
ifIndex.  It would be even better if that use case did not involve SNMP,
for example the following text from one of your replies would be a
good starting point:

> > interface name with an SNMP manager. That is a degree of
identification,
> > to know they are different.

That would help any other readers who make the same incorrect inference
that I made, namely that ifIndex is only useful as input to an
SNMP-based
tool (IMHO, not an unreasonable inference, as ifIndex is referenced from
a MIB RFC).

On to the nits ...

> that

This is a *readability* improvement comment, not a suggestion that a
reference is missing.  If you have RFC 4884 completely memorized,
congratulations, but I suspect that will not be the case for many
readers of this document, hence a sentence explaining what a C-Type
is and pointing to Section 8 of RFC 4884 (already cited as a normative
reference) would be an improvement.

> There is no Section 5.4 in the document... I suspect you meant Section
4.5.

Yes, I did, sorry.

>   the following circumstances:

IMHO, the paragraph break makes it not self-evident.  

> expense of being repetitive.

I would do that, as it's clearer.  As an alternative, remove the
paragraph
break.

> truly optional,

If that's what was truly meant, then "only in the following
circumstances:"
and the two bullet items following it need to be removed because they
place significant restrictions on when the item can be included, making
it
not truly optional.

> and the definition of MAY says:
>

Read the *rest* of RFC 2119 (!).  The keywords MUST, MUST NOT, SHOULD,
SHOULD NOT and MAY are defined there, but MAY NOT is omitted.  The
latter
is a deliberate omission, as MAY NOT is ambiguous and bad standards
language
(e.g., MAY is equivalent to "may or may not").  The draft's text uses a
"MAY ... only in the following circumstances" construction, which is an
ambiguous variant of MAY NOT.  I understand what was meant, but in order
to use RFC 2119 keywords to correctly impose the two "only in the
following
circumstances" requirements, a MUST (or a MUST NOT) is appropriate,
e.g.,

Thanks,
--David

> From: Carlos Pignataro [mailto:[email-masked]]
> Sent: Monday, December 28, 2009 11:58 AM
> To: Black, David
> Cc: [email-masked]; [email-masked]; JR Rivers;
[email-masked]; [email-masked];
> [email-masked]
> Subject: Re: Gen-ART review of draft-atlas-icmp-unnumbered-08
>

---

From: Carlos Pignataro <[email-masked]>
Date: Mon, 28 Dec 2009 14:49:34 -0500

David,

I tried to convey as clearly as I could the reasons why I feel strongly
that what you suggested was not a good idea for the document. Sorry for
the carried away, it was an attempt at extra clarity. I think the new
twist can be of help, and the counter-suggestion won't hurt.

Please see inline my additional $0.005, then I will let others chime in
with their thoughts.

> would be a good idea (and I'm not asking for one to be added).

I agree adding a MUST NOT requirement is not the solution.

> I'm sorry, but use cases are part of "motivation".

The motivation is to allow identifying the incoming interface for a
packet that elicited an ICMP error; there are scenarios in this
motivation, like the use of asymmetric return paths or unnumbered
interfaces, and there are further applications.

>  It would be a

OK, with this clarification my objection is certainly not so strong. I
think adding something along these lines won't hurt (but I do not
believe it will be of great value either).

For the record, my main objection was to designing an traceroute + SNMP
Manager application querying an SNMP agent, etc, etc.

> reference) would be an improvement.

Thank you for the suggestion, I think that any implementor would
understand C-Type (memorized or not), so I do not see a huge readability
improvement. And that a simplified C-Type explanation can deter someone
from actually reading RFC 4884 when they should.

> I would do that, as it's clearer.  As an alternative, remove the

OK, I agree, and I think that the addition of "in an Interface
Information Object" is the most clear modification.

> circumstances" requirements, a MUST (or a MUST NOT) is appropriate,

I still read that: "in the following circumstances, it is truly optional
to include the IP Address". As in, given this initial conditions, you
MAY do it. But rephrases that won't alter the semantics are welcome.

Thanks,

-- Carlos.

> idenfication,

---

From: <[email-masked]>
Date: Mon, 28 Dec 2009 15:58:46 -0500

Carlos,

Summarizing ...

-- ifIndex --

> Manager application querying an SNMP agent, etc, etc.

That was never my intent.  I believe my current request is to explain

identification,
>>> to know they are different.

In other words, the ifIndex can be effectively used as an opaque token
to identify whether two ICMP messages involve the same interface
(ifIndex
values match) or not (ifIndex values are different).  I remain of the
opinion that this ability to use ifIndex outside of SNMP is both
somewhat
unexpected and important enough to mention, especially as the definition
of ifIndex is via reference to a MIB RFC.

-- C-Type --

This was a readability nit, no change is necessary.  I noted it because
when I reached the start of Section 4.1 in reviewing the draft, it was
not clear to me where C-Type was defined.  That sent me scurrying off
to go find its definition in order to understand the contents of
Section 4.1.  Unlike you, I did not know which RFC to check first.

-- Section 4.5 --

Trying to limit edits to the current text, try this ...

OLD
   A single instance of IP Address information MAY be included only in
   the following circumstances:
NEW (remove "only", add object)
   A single instance of IP Address information MAY be included in
   an Interface Information Object under the following circumstances:

After the two bullet items, add the following sentence to impose the
restriction to those circumstances.

NEW
   In all other circumstances, IP address information MUST NOT be
   included.

Thanks,
--David

> Sent: Monday, December 28, 2009 2:50 PM
> To: Black, David
> Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]; gen-
> [email-masked]; [email-masked]
> > significant improvement to include a use case in Section 3 that
involves
> >> There is no Section 5.4 in the document... I suspect you meant
Section
> > 4.5.
> >
> > Yes, I did, sorry.
> >
> >>>    A single instance of IP Address information MAY be included
only
> > in
> >> We can s/be included/be included in an Interface Information
Object/
> > at
> >> Why? We are saying that the item (an IP Address information
element)
> > is
> >>>    When an Interface Information Object contains an IP Address,
one
> > of
> >> But RFC4950 does not prescribe a traceroute + LIB/LFIB manager,
which
> > I
> >>>> I suggest adding a Section 3.3 to discuss use of ifIndex with
ICMP
> > and
> >>> I still feel that discussing this use would be a strong
distraction
> > and
> >>> My traceroute app at home does IP address-to-name mapping,
querying
> > DNS
> >>> and reporting hostnames; ICMP timexceeded was not spec'ed that
way,
> > but
> >>> Describing an app like you suggest would implicitly limit, I
think.
> > We

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 28 Dec 2009 15:17:36 -0600

David,

I think we are converging. To re-state, from my perspective:

1. ifIndex -- I think that adding a sentence describing different
potential uses of ifIndex inside and outside a management domain (esp.
its use outside) should be fine. I do not think it adds great value, but
it might not be as evident as it appeared.

2. C-Type -- No change needed. The only Normative reference outside the
very-well-known ones is RFC 4884, so it would be an easy choice on which
normative RFC to follow. Still, I do not mind a citation in the 1st line
of S4.1, like "For this object, the c-type _[RFC4884]_ is used", or a
parenthetical "see S8 of [RFC4884]", but I do not want a definition of
C-Type in this doc.

3. Section 4.5 -- Sure, that editorial seems sensible to me.

Thank you again for your review,

-- Carlos.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, December 28, 2009 3:59 PM
To: Carlos Pignataro (cpignata)
Cc: [email-masked]; [email-masked]; [email-masked];
Naiming Shen (naiming); [email-masked]; [email-masked];
[email-masked]
Subject: RE: Gen-ART review of draft-atlas-icmp-unnumbered-08

Carlos,

Summarizing ...

-- ifIndex --

identification,

-- C-Type --

-- Section 4.5 --

OLD

NEW

Thanks,
--David

involves
Section
only
Object/
element)
one
which
ICMP
distraction
querying
way,
think.

---

From: <[email-masked]>
Date: Mon, 28 Dec 2009 16:29:09 -0500

Carlos,

Adding (somewhere early in draft, doesn't need to be in Section 3),
plus your first suggestion for C-Type text would be fine with me.

Thanks,
--David

> From: Carlos Pignataro (cpignata) [mailto:[email-masked]]
> Sent: Monday, December 28, 2009 4:18 PM
> To: Black, David
[email-masked]; Naiming Shen (naiming); gen-
> Cc: [email-masked]; [email-masked];
[email-masked];
> > >>> A public use of the ifIndex can be to see different interfaces
in
> a
> > > tool (IMHO, not an unreasonable inference, as ifIndex is
referenced
> from
only
> > >>   5. MAY This word, or the adjective "OPTIONAL", mean that an
item
> > > "MAY ... only in the following circumstances" construction, which
is
> an
> > >>> A public use of the ifIndex can be to see different interfaces
in
> a
> > >>> are not spec'ing an application, only the extensions of ICMP,
and

---

From: <[email-masked]>
Date: Mon, 28 Dec 2009 16:53:25 -0500

Something ate a line of text - that should be:

Adding (somewhere early in draft, doesn't need to be in Section 3),
a sentence on potential uses of ifIndex inside and outside a management
domain plus your first suggestion for C-Type text would be fine with me.

Thanks,
--David

> From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
> Sent: Monday, December 28, 2009 4:29 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [Gen-art] Gen-ART review of
draft-atlas-icmp-unnumbered-08
in
> > > that what you suggested was not a good idea for the document.
Sorry
> > for
> > > Please see inline my additional $0.005, then I will let others
chime
> > > >> I disagree with the intrinsic '"public"' nature and the
'clearly'
> > use
> > > >> you mention; and so does the I-D, as the Security
Considerations
> > > > section
> > > >> Moreover, the motivation is not (as you say) in the use cases
in
> > > > ifIndex.  It would be even better if that use case did not
involve
> > SNMP,
> > > OK, with this clarification my objection is certainly not so
strong.
> > > >> Again we could add it but... RFC4884 is a _normative
reference_,
> > > > meaning
> > > >> that
> > > >
> > > > This is a *readability* improvement comment, not a suggestion
that
> > > > ambiguous variant of MAY NOT.  I understand what was meant, but
in
> > order
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art