Skip to main content

PIM Join Attributes for Locator/ID Separation Protocol (LISP) Environments
RFC 8059

Yes

Alvaro Retana

No Objection

(Alexey Melnikov)
(Alissa Cooper)
(Deborah Brungard)
(Kathleen Moriarty)
(Stephen Farrell)
(Suresh Krishnan)
(Terry Manderson)

Note: This ballot was opened for revision 05 and is now closed.

Alvaro Retana Yes

(Alexey Melnikov; former steering group member) No Objection

No Objection (for -05)

                            

(Alia Atlas; former steering group member) No Objection

No Objection (2016-11-29 for -05)
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.

(Alissa Cooper; former steering group member) No Objection

No Objection (for -05)

                            

(Ben Campbell; former steering group member) No Objection

No Objection (2016-11-30 for -05)
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.

(Deborah Brungard; former steering group member) No Objection

No Objection (for -05)

                            

(Jari Arkko; former steering group member) No Objection

No Objection (2016-12-01 for -05)
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.

(Kathleen Moriarty; former steering group member) No Objection

No Objection (for -05)

                            

(Mirja Kühlewind; former steering group member) No Objection

No Objection (2016-11-22 for -05)
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

(Stephen Farrell; former steering group member) No Objection

No Objection (for -05)

                            

(Suresh Krishnan; former steering group member) No Objection

No Objection (for -05)

                            

(Terry Manderson; former steering group member) No Objection

No Objection (for -05)