RE: gen-ART LC review of draft-ietf-mpls-mldp-hsmp-04

["Roni Even" <[e-mail]>]

Hi Lizhong,

See inline

Roni



From: Lizhong Jin [mailto:[e-mail]]
Sent: 10 December, 2013 5:21 AM
To: 'Roni Even'; [e-mail];
[e-mail]; [e-mail]
Subject: RE: gen-ART LC review of draft-ietf-mpls-mldp-hsmp-04



Hi Roni,

Thank you for the review. Please see reply in line.

Lizhong



From: Roni Even [mailto:[e-mail]]
Sent: 2013年12月9日 2:15
To: [e-mail]; [e-mail];
[e-mail]
Subject: gen-ART LC review of draft-ietf-mpls-mldp-hsmp-04



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:

1.	In section 2 for PTP IEEE1588 need a reference. There is a reference
in the reference section but it is not used. Also the tictoc reference is
not used.

[Lizhong] thank you. Will fix in next version.