Ballot for draft-ietf-mpls-rfc4379bis
Yes
No Objection
Note: This ballot was opened for revision 07 and is now closed.
The document authors will increase by one (to a total of six) as due to a mix up of communications, George Swallow was omitted. We had planned to fix with the next update when addressing the Gen-Art comments last week but got delayed.
There are comments in the gen-art review that I think need to be considered: https://mailarchive.ietf.org/arch/msg/gen-art/NCnpeM8V5bWmrw_eLEuiT0FPP_E
Please work with the Gen-ART reviewer on the remaining issues as well.
Sheng Jiang <jiangsheng@huawei.com> performed the opsdir review
A few not very important comments: 1) To me it seems a bit unfortunate that this draft points to rfc6425 and rfc6426 for the definition of the T and R flags, given the goal was to have all specifications in one doc. Not sure if that can or should be fixed. Just wanted to mention it. 2) I would expect that the security section recommends border filtering of MPLS ping message, given that these are usually used within one domain, no? 3) I know this is a bis doc but I'm still wondering why this TTL trick is used here. For ICMP that was a way that utilizes the existing specification and implementation to get further information. However here, you could just have used a flag in the header either saying 'only forward to the end' or 'reply and still forward', or something like this, to cover the two modes. This would also allow to just send one packet to the end instead of sending one for each hop. Is there a rational for copying this ICMP hack?