PIM Join Attributes for Locator/ID Separation Protocol (LISP) Environments
draft-ietf-pim-join-attributes-for-lisp-06

For the values for the "transport" (and I do agree with Mirja that it isn't entirely clear what should be there - I
was expecting different encapsulations), I'd recommend having 0 as being unallocatable & having 255 be reserved for
future use as was suggested in https://datatracker.ietf.org/doc/draft-haas-code-point-reservation-bcp.

I think it would be helpful to have a paragraph on the goal of the "experiment", even if the goal is to gather implementation/deployment/operational experience.

There are a number of abbreviations that should be expanded on first mention.

Discussion inspired by Lucy's Gen-ART review might result in some clarifications in the document. Please make sure any clarifications, if you decide to have them, are done before the document is finally approved.

One minor but I think important comment (I don't think this justifies a discuss but I would really like to see that changed or at least discussed):

For me as a 'transport person' using the plain term '(underlaying) transport' is really confusing because it's very unspecific. In section 4.1. you actually call it the 'type of transport' and later on you talk about the mode of transport, but in general you just talk about the transport which is also reflected in the name of the attribute. In draft-ietf-taps-transports we classify this transport feature as part of addressing. I guess that might not be completely appropriate for your case. However, I would like to see the terminology here cleaned up to not only talk about '(underlaying) transport' but choose a more specific term. Given that you only have a 0 or 1 as choices in the attribute, I would even recommend to call this attribute 'Unicast Replication' or something like this instead of just 'Transport'.

One other minor comment: 
There are many abbreviations that are not spelled out once and make the reading slightly harder, e.g. ITR and ETR and so on