I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see _http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html_).
Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-pim-join-attributes-03.txt Reviewer: Elwyn Davies Review Date: 15 March 2008 IETF LC End Date: 26 March 2008 IESG Telechat date: (if known) - Summary: This document appears to be seriously unready, although, as ever, some of the apparent problems may be due to my misunderstandings. From the introductory description that totally fails to give a concise summary of how address encodings with additional attributes are distinguished and what is actually done to the format, through statements in s3.3 that would appear to preclude any sort of incremental deployment and an ambiguous packet format section, to a seriously incomplete IANA considerations, I believe that a good deal of work is needed to fix up this document. Indeed the problems with s3.3 may actually be a show stopper. I am unclear whether there is actually a technical solution to the requirement for 'ALL' routers to be able to support the new options even if this isn't the entire Internet. See below for further discussion. Comments: s3.1: The terminology is inconsistent with RFC 4601 which uses Encode-Source Address rather than source encoded (I assume that is the right association). I found this section totally unenlightening about the general principles of the new Join attributes. I spent a good 20 minutes trying to understand what was going on. The indication that a different Encoding Type is what distinguishes this form from the 'legacy' Encoded-Source format is not made clear - it is ultimately buried in the packet format. Is the WG clear whether this is really a different encoding and/or happy that this is an adaptation of the meaning of the field? There is not actually any difference in the way the address itself is encoded. s3.2: Should clarify whether it is expected that the address should be forwarded upstream without the TLV or the whole address discarded. s3.3: > > We can only send a PIM Join which includes an attribute if ALL > routers on the network support the new option. > If this really means what it says, then there seems little chance of effective (incremental) deployment. Even if what is actually meant is that all routers on the relevant multicast tree have to support the extra capability, I am unclear how the originator of such a message gets to know how this condition is fulfilled. This needs some explanation I think. What happens if the original tree that is 'attribute capable' is broken due to a failure and the paths reconverge to pass through one or more routers that don't support Join attributes? s3.4: The upshot of the potential need for conflict resolution is AFAICS that the definition of any attribute MUST include instructions for conflict resolution (even if they state that the attribute is either present or not, and if it is received from any source then it is propagated to all next hops - or maybe conversely, if not received from all sources then should not be propagated). I think this requirement has to be specified. s3.8.1: The format specifies (on the second line of the picture) 'Source Address (Encoded-Source format)'. Does this mean the *whole* of the Encoded-Source format from section 4.9.1 of RFC 4601? or just the source address? If the former this results in duplicating the first row of information. I understand that a different Encoding Type is needed to distinguish this format from the basic 'native encoding'. RFC4601 fails to define an IANA registry for Encoding Type. What happens if there are no attributes on some address? Should a 'null' attribute be defined to carry the 'bottom of stack' bit if there aren't any attributes? If not then probably worth making it explicit that the 'legacy' encoding should be used if there are no attributes. How is the length field encoded (number of octets, 32 bit words, twists in a piece of string, etc.) and represented. s4: The definition and review type for the attribute type registry are not defined. This document effectively updates RFC 4601 by requiring a registry for Encoding Types - although it doesn't define this registry. One problem with this is that doing this from an informational document may not be allowed (I am not sure about this, because it is an effective update of RFC 4601 which is standards track). Editorial: Abstract: Expand PIM and TLV acronyms. s1: Expand PIM-SM acronyms. RFC 2119 needs to have a reference. s3.x/s3.x.x: Capitalization of section titles needs attention. s3.3, para 2: 'must be able to parse to the packet'? s/parse to/parse/? s3.8.1: Prefer octet to byte. s3.8.1/2: The bit number labels are not aligned over the bit fields on the pictures (and in s3.8.2 the decade digits are missing). _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
