Explicit Path Routing for Dynamic Multi-Segment Pseudowires
RFC 7392

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

(Adrian Farrel; former steering group member) Yes

Yes (2014-08-25 for -05)
No email
send info
Need to pick up the nits from Meral's GenArt review

> [Page 6], Section 4.1, typo: "A noted in Section 1"---->"As noted in Section 1"
>
> [Page 6],"but each node MUST attempt to determine a loop-free path",
> if the only method to detect a loop is http://tools.ietf.org/html/rfc6073#section-7.6, 
> then perhaps a reference to this RFC would be useful.
> [Page 8], Section 5, typo :"consesus"---->"consensus"

(Alia Atlas; former steering group member) (was Discuss) No Objection

No Objection (2014-09-02 for -05)
No email
send info
Ok - sorry for the confusion.

(Alissa Cooper; former steering group member) No Objection

No Objection (2014-09-01 for -05)
No email
send info
Wondering if any of the mays and musts in Section 4.2 should be MAYs or MUSTs. I noted that in 4.1, the text says "Processing continues as per Section 4.2, where a new explicit route TLV MAY be added to the Label Mapping Message," but the behavior specified in 4.2 is not described normatively.

(Barry Leiba; former steering group member) No Objection

No Objection ( for -05)
No email
send info

(Benoît Claise; former steering group member) No Objection

No Objection ( for -05)
No email
send info

(Brian Haberman; former steering group member) No Objection

No Objection ( for -05)
No email
send info

(Jari Arkko; former steering group member) No Objection

No Objection ( for -05)
No email
send info

(Joel Jaeggli; former steering group member) No Objection

No Objection ( for -05)
No email
send info

(Kathleen Moriarty; former steering group member) No Objection

No Objection (2014-08-29 for -05)
No email
send info
Looks ok from a security standpoint, interested to see the clearer language from Alia's review.

(Richard Barnes; former steering group member) No Objection

No Objection ( for -05)
No email
send info

(Spencer Dawkins; former steering group member) No Objection

No Objection ( for -05)
No email
send info

(Stephen Farrell; former steering group member) No Objection

No Objection (2014-09-03 for -05)
No email
send info
- I'm not sure to what extent this may be a significant
threat, but want to check. This new mechanism seems to create
a new way to attempt to DoS or probe a MS-PW if one is allowed
to send any traffic on that MS-PW as an S-PE (or a zombied
S-PE) - any such sender can nominate the path for traffic. Why
is that not a new security consideration? If it is, (and I
think it is), then at least noting that in the security
considerations section would seem right. And how might one
detect or otherwise mitigate such a nasty S-PE? 

- To be honest, I found 4.1 and 4.2 very hard to take in. I'd
suggest maybe a re-write but IFF others have had similar
difficulty. (If its just me, then ignore me.) Some examples
below.

- 2nd sentence of 4.1 - who is selecting when? (Passive
voice?)

- "MUST attempt" is very odd, is that the same as "MAY not
bother"? :-)

- "If a loop free path cannot be found..." by whom?

- "If the L bit is not set in the first ER Hop and if the node
is not part of the abstract node described by the first ER Hop
(i.e it does not lie within the prefix as determined by the
prefix length specified in the ER-Hop TLV), it has received
the message in error, and MUST reply with a Label Release
Message with a "Bad Initial ER Hop Error" (0x04000004) status
code." Does that *all* really have to be one and only one
sentence?

(Ted Lemon; former steering group member) No Objection

No Objection (2014-09-04 for -05)
No email
send info
In 3.2:
   The ER-TLV specifies the path to be taken by the MS-PW being
   established.  Each hop along the path is represented by an abstract
   node, which is a group of one or more S-PEs, identified by an IPv4,
   and IPv6 or an S-PE address.  The ER-TLV format is as per Section 4.1
  ^^^^^
   of [RFC3212].

I think the "and" that I indicated should be an "an".   I mention this because although it's a fairly obvious typo, it _could_ actually be intentional, and hence doesn't qualify as strictly editorial.   If it is intentional, you should remove the preceding comma.

In 4.1:
   3.  If a second ER Hop TV does exist, and the node is also a part of

Again kind of nit-picky, but I think you mean TLV here, not TV.

FWIW (referring to Stephen's comment), I did not find section 4 difficult to follow.