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

[<[e-mail]>]

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


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
Behalf Of [e-mail]
> Sent: Monday, December 28, 2009 4:29 PM
> To: [e-mail]
> Cc: [e-mail]; [e-mail];
[e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: Re: [Gen-art] Gen-ART review of
draft-atlas-icmp-unnumbered-08
> 
> 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.
> > > >>>
> > > >
> > > >
> >
> >
> 
> _______________________________________________
> Gen-art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art