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

[<[e-mail]>]

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

> 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".  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:

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

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.

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

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

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