Comments on draft-ietf-pim-join-attributes-03

The need for this addition to the Join functionality is clear.  In addition to the justification to be found in draft-ietf-pim-rpf-vector-06, the TLVs provide a convenient vehicle for establishing a relationship between edge routers and the router closest to the source, when necessary to support secure multicast.


I have one comment on the "intended status".

If additional semantics are to be added to an approved standard, then the status of the additional semantics should also be "standards track", and not "informational".


I have three technical comments:

1. The semantics of the F bit need to be more clearly stated.

a. In section 3.2, it says:
      "It may be desired to have routers that understand the generic
      attribute format, forward the attributes regardless of whether they
      understand the TLV's encoded in the attribute not."

   Leaving aside the fact that the word "not" should be "or not", this
   sentence implies that the forwarding is completely determined by the bit,
   and not by the router that is processing the TLV.

b. One sentence later, it says:
      "If this bit is set then the router MUST forward the TLV upstream in
      case the router does not understand that type.  If this bit is not
      set, the router MUST NOT forward the TLV upstream in the case the
      router does not understand that type."

   This seems to say that, when the router _does_ understand the type, it
   is free not to forward the bit.  This is in direct contradiction to the
   sentence in "a."

c. In section 3.8.1, it says:
      "If this bit is set the TLV is forwarded regardless if the router
      understands the type."

   This phrase is ambiguous; in my estimation it would most likely be taken
   to mean, "the TLV is forwarded whether or not the router understands the
   type."  This re-enforces the intention in "a.", and directly contradicts
   the implied meaning in "b.".

   It is my opinion that the forwarding action should be determined by the
   "F" bit, without regard to the ability of the local router to understand
   the specific TLV.  If this is what was intended, then all three places
   noted above need to be altered so that the meaning is unambiguous.

   Alternatively, if both semantics are desirable (in different situations),
   then two bits need to be allocated, one with "always forward" semantics,
   and the other with "forward only if you do not understand this TLV"
   semantics.

2. The packet format for Join is ambiguous.

The first four bytes are Addr Family, Encoding Type, Rsrvd+Flags, Mask Len.  This is followed by Source Address (Encoded-Source format).  However, Encoded-Source format is defined in RFC 4601 as Addr Family, Encoding Type, Rsrvd+Flags, Mask Len, Source Address.  This will result in a duplication of the first four bytes.  I believe that what is intended here is that the label "Source Address (Encoded-Source format)" should be simply "Source Address".

3. The label "S" is used twice in the packet format.  The first time is for the "Sparse" bit (in the Flags field, at position 21), and the second time is for the "Bottom of Stack" bit in position 0 of a TLV.  My suggestion is to rename the "Bottom of Stack" bit and call it "B".


I have the following comments on grammar:

Page 4, line 1.  "which" ->"that"

Line 2.  "which" ->"that"

Line 3.  "parse to the" -> "parse the"


I have the following comments on style:

In general, the use of contractions in formal writing should be avoided.  Therefore, all instances of "there's" should be replaced with "there is" and all instances of "it's" should be replaced by "it is".  Of course, if you do not consider an RFC to be a "formal writing", then you are free to use contractions wherever you wish.


NOTE on use of "which" and "that".

"that" is used when the following phrase is _required_ to be able to completely identify what is being talked about, while "which" is used to introduce supplementary information.  Some examples:
1) If there are three houses on the street, and only one of them is at the corner, then you say:
"The house that is on the corner needs paint."
2) If there are three houses on the street, and only one of them is yellow, then you say:
"The yellow house, which needs paint, is for sale."
In the first case, the observer cannot identify the exact house until its position is given.  In the second case, the house is completely identified by its colour, and the information about the need for paint is supplementary information, which is set off with commas, and introduced with "which".

In the examples cited above on page 4 of the Internet Draft, the kind of PIM Join being discussed is only fully specified when we know that it includes an attribute.  Therefore, "that" is necessary.