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

[Carlos Pignataro <[e-mail]>]

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