On 9/30/2007 11:44 PM, Danny McPherson said the following: > On Jul 25, 2007, at 11:51 AM, Mark Townsley wrote: > >> Please also give us feedback on whether or not this document should >> be published, and on what track. I am considering the Standards >> Track, shepherded directly by either me or Jari. > > > I also believe Standards Track is appropriate. > > I do have a couple of comments rather random comments > for the Alia and the rest of the authors. > > -danny > > ------- > Section 4.1: Interface Role Value 2-3 : "Undefined by this memo and > to be assigned by IANA" I think you mean "Reserved"? > > Bits 4 & 5 of the Interface Information Object you say they MUST > be set to zero. Why not SHOULD be, this will provide more flexibility > with deployment of new functions that might employ those bits? > > In section 4 item "4." you say an interface name string of no more > than 31 bytes may be included. In section 4.2 you say the interface > name Sub-Object must have a length that is a multiple of 4 bytes and > MUST NOT exceed 32 bytes. Clarifying that a one octet "charset > type" is required, and that the entire field be aligned on 32-bit > boundaries, with trailing zero padding if necessary, would perhaps > remove any confusion. > > Also, your use of "An interface name string" may introduce > confusion, you might consider rewording section 4 bullet > 4. to something like this: > > 4. An Interface Name Sub-Object, a string of no more than > 31 bytes, MAY be included > > "Figure 3" is the only diagram you seem to have labeled and > referenced. Consistency with the others would be useful. > > In the Security Considerations section tightening up the use > of "destination IP address" is important. You should be very > clear about the ICMP message destination IP address versus > the triggering packets destination IP address. Also, I think the > example should be that interface names and ifIndex values > should NOT be available outside of the local administrative > domain, while the IPv4 addresses may be. > > Also, the fact that this could be used to identify egress > interfaces that may have drop by policy on ingress > (e.g., Dest Unreah, Admin Prohibit) should be strongly > considered, both from a descriptive and IP address > perspective. I could see this information being exploit > for reconnaissance and other activities. > > Providing a few tables for each object in the IANA > considerations section might make things more clear. > I'd tighten up the wording around the Interface Name > Sub-Object bits 4 & 5 as well, as mentioned above. > Same for values 2 & 3 if Interface role. > > Given that this is Standards Track, perhaps something > besides FCFS for charset type allocation worthwhile? > > I also have some concerns about there only being two > RSVD bits for included information, I suspect we could > very quickly exhaust that. Any thoughts there? I realize > we're bounded by C-Type Object subtype bit some other > encoding might be useful here?
My 2ยข, I think that this bitmask encoding fits this application fine, and one more RSVD bit could be reclaimed by using a single bitfield for IPv4|IPv6 (as defined a given extension does not have include IPv4 and IPv6 addresses, so a single "IP" bitfield could suffice, freeing one more bit). That would yield 3 used and 3 unused bits for included information. Worst case, if needed in the future, the last RSVD to be allocated could be a TLV-encoded "Included information" field. One additional note though is that the Interface Name field has a variable length but does not have an associated length field. This is OK since it's the last sub-object in the extension, and there is an extension length, but could complicate using those RSVD fields. Thanks, --Carlos. > > I'm not sure why you have a reference to RFC 2328 in > the references section? > > A general application of this as well may be to identify which > egress interface triggered a given function for the original > datagram. For example, if an ACL drops the packet and > Dest Unreac/Admin Pro denies the packet, being able to > identify that might be useful.. Another example there would > be that of P MTU, to identify which egress interface can't > support a given MTU size - or to obtain a bit of intelligence > data from a given router on that front. If you thought of > such an implementation on a firewall, for example, you > might drop and even provide corresponding policy numbers > on a trusted side, and nothing on an untrusted side, etc.. > > Your text here: > > Included Information: This 6-bit field [0:5] indicates what > information is included in the object. The > information must be included in the same order > as the bits (from highest to lowest). > > Might be better clarified by either using highest-order or > "leftmost", as opposed to "from highest to lowest". Also, > why do you have this constraint? > > Why is the interface name Sub-Object limited to 32 octets > total length? > > > > > > _______________________________________________ > Int-area mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/int-area > -- --Carlos Pignataro. Escalation RTP - cisco Systems _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
