|
Hi Lizhong, See inline Roni From: Lizhong Jin [mailto:lizho.jin@xxxxxxxxx] Hi Roni, Thank you for the review. Please see reply in line. Lizhong From: Roni Even [mailto:ron.even.tlv@xxxxxxxxx] 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-hsmp-04 Reviewer: Roni Even Review Date:2013–12-8 IETF LC End Date: 2013-12–10 IESG Telechat date: Summary: This draft is ready for publication as an standard track RFC. Major issues: Minor issues: 1. In section 3.1 last paragraph “If the peer has not advertised the corresponding capability, then label messages using the HSMP FEC Element SHOULD NOT be sent to the peer. “. Why use a SHOULD NOT and not MUSR NOT [Lizhong] I follow the description in RFC6388 section 2.1. But let me try to explain. There may exist some rare cases that the peer does not have the capability negotiation function, but still support HSMP. This could only happen if the node has pre-knowledge of the peer’s HSMP capability. In that case, label message could be sent to the peer. To Ice, if you have any opinion, please comment. [Roni Even] Thanks for explaining. Maybe you can add such text to the document in order to explain why it is a should but it is up to you. I am OK with any decision you make Nits/editorial comments:
[Lizhong] thank you. Will fix in next version. |