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

["Carlos Pignataro (cpignata)" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] 
Sent: Monday, December 28, 2009 3:59 PM
To: Carlos Pignataro (cpignata)
Cc: [e-mail]; [e-mail]; [e-mail];
Naiming Shen (naiming); [e-mail]; [e-mail];
[e-mail]
Subject: RE: Gen-ART review of draft-atlas-icmp-unnumbered-08

Carlos,

Summarizing ...

-- ifIndex --

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

That was never my intent.  I believe my current request is to explain
something along the lines of the following in Section 3:

>>> 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
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


> -----Original Message-----
> From: Carlos Pignataro [mailto:[e-mail]]
> Sent: Monday, December 28, 2009 2:50 PM
> To: Black, David
> Cc: [e-mail]; [e-mail];
[e-mail]; [e-mail]; gen-
> [e-mail]; [e-mail]
> Subject: Re: Gen-ART review of draft-atlas-icmp-unnumbered-08
> 
> 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.
> 
> On 12/28/2009 1:59 PM, [e-mail] wrote:
> > 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 ...
> >
> >> 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.
> >
> > 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).
> 
> I agree adding a MUST NOT requirement is not the solution.
> 
> >
> >> 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.
> >
> > 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
> > significant improvement to include a use case in Section 3 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:
> >
> >>> 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
> > 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).
> 
> 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.
> 
> >
> > On to the nits ...
> >
> >>> - Section 4.1: Explain what a C-Type is.  A few words and a
reference
> >>> 	to Section 8 of RFC 4884 should suffice.
> >> Again we could add it but... RFC4884 is a _normative reference_,
> > meaning
> >> 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.
> 
> 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.
> 
> >
> >>> - 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.
> >
> > Yes, I did, sorry.
> >
> >>>    A single instance of IP Address information MAY be included
only
> > in
> >>>    the following circumstances:
> >>>
> >>>    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.
> >>
> >>   A single instance of IP Address information MAY be included only
in
> >>   the following circumstances:
> >
> > IMHO, the paragraph break makes it not self-evident.
> >
> >> We can s/be included/be included in an Interface Information
Object/
> > at
> >> expense of being repetitive.
> >
> > I would do that, as it's clearer.  As an alternative, remove the
> > paragraph
> > break.
> 
> OK, I agree, and I think that the addition of "in an Interface
> Information Object" is the most clear modification.
> 
> >
> >>> 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,
> >
> > 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:
> >>
> >>   5. MAY This word, or the adjective "OPTIONAL", mean that an item
is
> >>      truly optional...
> >>
> >> So how is the usage poor?
> >
> > 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.,
> 
> 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.
> 
> >
> >>>    When an Interface Information Object contains an IP Address,
one
> > of
> >>>    the following two conditions MUST be true:
> >
> > Thanks,
> > --David
> >
> >> -----Original Message-----
> >> From: Carlos Pignataro [mailto:[e-mail]]
> >> Sent: Monday, December 28, 2009 11:58 AM
> >> To: Black, David
> >> Cc: [e-mail]; [e-mail]; JR Rivers;
> > [e-mail]; [e-mail];
> >> [e-mail]
> >> Subject: Re: Gen-ART review of draft-atlas-icmp-unnumbered-08
> >>
> >> [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.
> >>
> >> On 12/28/2009 11:48 AM, Carlos Pignataro wrote:
> >>> David,
> >>>
> >>> Please find one additional comment response to your suggestion.
> >>>
> >>> Excerpts from [e-mail] on 12/27/2009:
> >>>> 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)
> >>> 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.
> >>>
> >
> >