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

[<[e-mail]>]

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


> -----Original Message-----
> From: Carlos Pignataro (cpignata) [mailto:[e-mail]]
> Sent: Monday, December 28, 2009 4:18 PM
> To: Black, David
> Cc: [e-mail]; [e-mail];
[e-mail]; Naiming Shen (naiming); gen-
> [e-mail]; [e-mail]
> Subject: RE: Gen-ART review of draft-atlas-icmp-unnumbered-08
> 
> 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.
> > >>>
> > >
> > >
> 
>