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: [email protected] [mailto:[email protected]] On Behalf Of [email protected] > Sent: Monday, December 28, 2009 4:29 PM > To: [email protected] > Cc: [email protected]; [email protected]; [email protected]; [email protected]; > [email protected]; [email protected] > 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:[email protected]] > > Sent: Monday, December 28, 2009 4:18 PM > > To: Black, David > > Cc: [email protected]; [email protected]; > [email protected]; Naiming Shen (naiming); gen- > > [email protected]; [email protected] > > 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: [email protected] [mailto:[email protected]] > > Sent: Monday, December 28, 2009 3:59 PM > > To: Carlos Pignataro (cpignata) > > Cc: [email protected]; [email protected]; > [email protected]; > > Naiming Shen (naiming); [email protected]; [email protected]; > > [email protected] > > 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:[email protected]] > > > Sent: Monday, December 28, 2009 2:50 PM > > > To: Black, David > > > Cc: [email protected]; [email protected]; > > [email protected]; [email protected]; gen- > > > [email protected]; [email protected] > > > 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, [email protected] 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:[email protected]] > > > >> Sent: Monday, December 28, 2009 11:58 AM > > > >> To: Black, David > > > >> Cc: [email protected]; [email protected]; JR Rivers; > > > > [email protected]; [email protected]; > > > >> [email protected] > > > >> 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 [email protected] 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 > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
