Please see my comments in the attachment.
Bill Atwood
The IESG wrote:
The IESG has received a request from the Protocol Independent Multicast
WG (pim) to consider the following document:
- 'Format for using TLVs in PIM messages '
<draft-ietf-pim-join-attributes-03.txt> as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@xxxxxxxx mailing lists by 2008-03-26. Exceptionally,
comments may be sent to iesg@xxxxxxxx instead. In either case, please
retain the beginning of the Subject line to allow automated sorting.
The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-pim-join-attributes-03.txt
IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=13904&rfc_flag=0
_______________________________________________
IETF-Announce mailing list
IETF-Announce@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf-announce
--
Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046
Professor Emeritus fax: +1 (514) 848-2830
Department of Computer Science
and Software Engineering
Concordia University EV 3.185 email: bill@xxxxxxxxxxxxxxxx
1455 de Maisonneuve Blvd. West http: //users.encs.concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8
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.
_______________________________________________
IETF mailing list
IETF@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf