Hi Bernie, Thank you for the review.
Please see inline. Cheers, Med > -----Message d'origine----- > De : Bernie Volz (volz) [mailto:[email protected]] > Envoyé : jeudi 12 janvier 2017 14:49 > À : [email protected] > Cc : [email protected]; [email protected]; Terry Manderson > Objet : Review of draft-ietf-softwire-multicast-prefix-option-11 > > Hi: > > A few comments on this draft. > > Section 2: > > The dslite-multicast draft uses uPrefix64 instead of U_PREFIX64? > Consistency between the various softwire documents might be useful? [Med] Works for me. > > Nit: SSM_PREFIX64 has an extra closing parenthesis (after the RFC4607 > reference). [Med] Fixed. > > Section 3: > > I am not sure that the *-length fields are correctly documented? Can they > really be 0-128. I understand 0 if there is none, and I can see 1-96 > potentially, but does more than 96 make sense? It seems that the other > documents referenced typically say to use the prefix (96 bits – perhaps > zero extended if needed to make 96 bits) and then add 32-bits IPv4 for > multicast (unicast is a bit more complex when prefix is not 96). But none > of this other text seems to imply that the prefix length can be > 96? [Med] As mentioned in Section 5, only 96 is allowed. I already fixed Section 3 accordingly. > > Also, while 2001::/96 could be sent as 2001::/16 in terms of the option > encoding (as bits 17 to 96 are 0), the two are vastly different in terms > of what they might mean (if the prefix is always mapped to /96 it may not > matter). I just wonder if this needs to be clarified some? I believe the > first encoding (2001::/96 is always intended as that communicate the true > prefix length). > > Is the reference to “Section 6 of RFC7051” correct? Was this intended to > be RFC 7227 (Section 6 there is titled “Avoid Conditional Formatting”). [Med] Section 6 of RFC7051 is correct. It documents the use of Well-known DNS name for the unicast-only case. I updated the text to make this explicit. NEW: Such side effect conflicts with the recommendation to support the Well-Known DNS Name heuristic discovery-based method for unicast-only environments (Section 6 of [RFC7051]). > > I think it would be useful to clearly state that multiple instances of > this option are allowed. Yes, if you carefully read the text (in Section 4 > & 5) this is evident, but it is useful to state this explicitly when > defining the option! [Med] Happily. I added to NEW text to section 3: "Multiple instances of OPTION_V6_PREFIX64 may be returned to a DHCPv6 client." > > Section 5: > > Nit: There are two “Pv4 mulitcast” instances; are these supposed to be > “IPv4 multicast”? [Med] Fixed. > > Note here that the text for ASM and SSM says to insert last 32-bits. This > would imply that a prefix length > 96 does not work. (See comments above > for section 3.) [Med] Yes, only 96 is allowed. See above. > > And, there is talk here about scope selection and adding the same > reference as in Section 4 (to RFC7346) might be useful? Client > implementers may not read the server section, so duplicating the reference > here would be useful. [Med] Works for me. Done! > > - Bernie > > > _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
