I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-mpls-mldp-in-band-wildcard-encoding-02.txt Reviewer: Elwyn Davies Review Date: 2014-10-31 IETF LC End Date: 2014-10-27 IESG Telechat date: (if known) - Summary: Almost ready. There are a couple of clarifications around how IPv4 and IPv6 trees can or cannot be merged on a single MP-LSP that would be advantageous. Also the error handling in the parent RFCs (6388, 6826) is a bit sketchy resulting in messy handling if an LSR that does not support the wildcard encoding is accidentally sent the TLVs from this draft. I am not sure if this can be cleaned up (and maybe there is no thought to be a problem - I am not sufficiently expert in LDP signalling). PS Apologies for the late review - Overtaken by holidays. Major issues: None. Minor issues: IPv4 and IPv6 Multicast: I think it would be useful to add a short discussion of the fact that there are both IPv4 and IPv6 multicast trees. Presumably an MP-LSP can only carry one or the other at a time, but I am unclear about whether this is the case. Also a note in s3.1 that it is either the IPv4 or IPv6 address fields that are relevant and they are all zeroes in either case would clarify the usage further. RFC 5918 Typed Wildcard: Is there anything special that has to be done if the Typed Wildcard is used? s3.3: Is it possible to specify the error behaviour more concretely (i.e., what might happen) in case an unadapted Ingress LSR gets a wildcard TLV? It appears that RFC 6826 is rather underspecified as regards error handling - but I am not an expert on this area - it appears that the MP-LSP would get set up but to no good purpose which seems inappropriate. Could an error status not be returned? Nits/editorial comments: s2, Definition of 'in-band signalling': Should also allow for (S,*) - and possibly (*,*), I believe. s3.4: s/PIM ASM/PIM-ASM/