Hi Dave, Thanks very much for the in depth review! You've caught a number of things. Where I don't respond, it is for the minor typos/grammer details - but that's because I agree and will take care of them.
In ref to Sec 3.2, you asked: "Also why does PMTU care about identifying the outgoing interface? As far as I know it doesn't, it just cares about determining the PMTU. Elaborate or delete." The idea here is to learn what interface has the lowest MTU. For instance, think of this as an ops tool, which helps discover incorrectly configured interfaces. In ref to Sec 4, bullet 4, you asked: "Comment [DT9]: Is this the ifName as specified by the Interfaces Group MIB [RFC2863]? If it's not the same as ifName, why not? Section 4.2 partly answers this but the reader is looking for the answer here due to the wording of the previous bullet." I can copy/move the text from 4.2 to here. There is the option for the text to be something other than the ifName, if that is desired by the operators. I see that you are concerned about this by the comment: "Comment [DT15]: BUG: This can cause problems if the human meaningful name is the same as the ifName of some other interface. How can you tell whether it's an ifName or not? Suggest requiring it to be the ifName. If you want something else, then use a different subobject." It is a SHOULD; I don't think it needs to be a MUST. I agree that it would be possible to configure a different interface's ifName as the string, but that supposes that there is malicious access to the router for deliberate confusion. Do you see this as a likely problem? I think it is far better to allow flexibility over the ifName so that operators can get more relevant data, based on what is desired for their tools. In ref to Sec 4, bullet 4, you said: "Comment [DT10]: In general, including this would appear to be a bad thing, since you'd get less of the original IP packet that triggered the ICMP error." The reason there is a limit to 62 bytes is to trade-off between this concern and getting additional useful information. In ref to Sec 4.1 and the description of "included information", you said: "Comment [DT11]: This label doesn't match the diagram above." It matches the text that breaks the C-type into 2 fields - the "interface role" and the "included info". The diagram shows the included info field broken down further to show the meaning of the bits in the included info field. I'll add a level to the diagram explicitly labeling those 6 bits as "included information". In ref to Sec 4.1, bit 2 description, you said: "Comment [DT12]: RFC 2463 states: " (c) If the message is a response to a message sent to an address that does not belong to the node, the Source Address should be that unicast address belonging to the node that will be most helpful in diagnosing the error. For example, if the message is a response to a packet forwarding action that cannot complete successfully, the Source Address should be a unicast address belonging to the interface on which the packet forwarding failed." Given this, why would an IPv6 address appear in this extension? Is this so you can put a link-local address in the extension where you have to pick a global address in the source address? Or what?" Well, the node can't use both the IPv6 address of the incoming interface and that of the outgoing interface as the packet's source address. Thus, the ability to expressly include the outgoing interface's IPv6 address is useful. As you say, it also lets one put the link-local addresses into the extension, if that's desirable. In ref to Sec 4.1 description of the bits in the Included Information field, you said: "Comment [DT13]: What's the point in having reserved bits that aren't contiguous? This limits the ability to (say) use a 3-bit field in the future. Can bit 3 be moved to this position?" In the original draft, we had a flag for IPv4 address and a different flag for IPv6 address. When we consolidated them, rather than moving the flags around, we just made it reserved. If there aren't implementations yet that care and can't easily be changed, then I agree that having the reserved bits together would be better. Without express agreement, I'm reluctant to change. In ref to Sec 4.1 discussion of the ordering of the information and sub-objects, you said: "Comment [DT14]: BUG: Because you "MUST ignore" the reserved bits on receipt, then in the future if one is used then you will parse the rest incorrectly. You need to constrain the first sentence of this paragraph to be just the 3 types of information in this document, and it can be followed by arbitrary data that MUST be ignored." Yes - this is a very good point. The issue is how future additions that use the reserved bits should be added in. I think we need to address that here as well. Do you have any suggestions? We could require them to be sub-objects that indicate their length in the first byte... and place them after the 3 defined here and in the order of bits? In ref to sec 4.2, you said: "Comment [DT16]: The ifIndex is sufficient for cross-correlation and takes up far less packet space. And since the UTF-8 might not be displayed correctly or in a language the human reader understands, it can't be relied upon for human reader familiarity. Hence one could argue that the name is harmful by comparison to just using ifIndex. Just like traceroute can do reverse DNS to get the full name based on IP address, it could do SNMP to get the ifName based on the ifIndex, for routers it has permission to access." The interface indicated by an ifIndex can change with rebooting of a router; there are also dynamic interfaces that come and go. Having the associated name is useful there. Similarly, with traceroute, reverse DNS is usually done to provide the name for the IP addresses because that gives more meaning. As for your concern about UTF-8, the program receiving packets with this extension will need to be updated to understand and display the information anyway; I'm sure that UTF-8 compatibility would be included or the name wouldn't be displayed if that wasn't possible. I'm not sure I understand your argument about human reader familiarity. Even if the name is in a different language, it can give some useful information. Some of that depends on who is expected to get this extra info; I can certainly see the name being something that is limited to those IP addresses associated with that network's operators. As for your suggestion that every traceroute should also do SNMP to every hop on the path, well, I would just like you to think about the scaling concerns if one is probing many paths. That also assumes that the box doing the traceroute has access/authority to SNMP to all those routers; it's entirely likely that would not be the case. In ref to sec 4.4, "If the interface in question is unnumbered, then the Interface Information Object SHOULD include the ifIndex and SHOULD NOT include an IP address." you said: "Comment [DT17]: Huh? Section 4 implies this has to be MUST NOT. To avoid violating section 4, what IP address could this legally contain?" I don't have a good suggestion for what address it could legally contain. I'm willing to make this a MUST NOT, unless I hear disagreement. Thanks again for the detailed review, Alia On Wed, Sep 10, 2008 at 4:02 PM, <[EMAIL PROTECTED]> wrote: > > > > -----Original Message----- > > From: Dave Thaler [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, September 09, 2008 6:36 PM > > To: Jari Arkko; Internet Area > > Cc: [EMAIL PROTECTED]; Ron Bonica; > > [EMAIL PROTECTED]; [EMAIL PROTECTED] > > Subject: RE: [Int-area] WGLC for draft-atlas-icmp-unnumbered > > > > My comments are in the PDF attached (yeah this makes it hard > > to respond to in email, but it's the fastest way for me to > > review in detail and I figure you'd rather have comments now > > than maybe get them later or maybe not :) > > > > I also read draft-watkins-icmptype11code0 and believe it > > should be merged (i.e., next hop IP address information) into > > the same document. > > > > Because of the technical issues I point out in my review, and > > the possible combination with the watkins doc, I would > > suggest another WGLC after the next version of the doc comes out. > > > > -Dave > > > > ________________________________________ > > From: [EMAIL PROTECTED] [EMAIL PROTECTED] > > On Behalf Of Jari Arkko [EMAIL PROTECTED] > > Sent: Saturday, September 06, 2008 2:48 AM > > To: Internet Area > > Cc: [EMAIL PROTECTED]; Ron Bonica; > > [EMAIL PROTECTED]; [EMAIL PROTECTED] > > Subject: [Int-area] WGLC for draft-atlas-icmp-unnumbered > > > > This is the start of the two week WG last call period for > > draft-atlas-icmp-unnumered. Please send comments by September > > 20th, 2008. The intended status of the draft is Proposed Standard. > > > > Given that there has been other proposals in this space too > > and some discussion about what the drafts should contain: > > please take the intended scope of the document as ICMP > > extensions useful for retrieving more interface and next-hop > > related information in a traceroute/error situation. That is, > > please consider whether functionality defined in > > draft-watkins-icmptype11code0 is also something that should > > be defined. > > I only want to progress one document on this, however (or at > > least coordinate the formats). > > > > Jari > > > > _______________________________________________ > > Int-area mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/int-area > > >
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
