Subject: [Gen-art] gen-ART LC review of draft-ietf-mpls-mldp-hsmp-04

From: "Roni Even" <[email-masked]>
Date: Sun, 8 Dec 2013 20:14:46 +0200

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

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.

---

From: "Lizhong Jin" <[email-masked]>
Date: Tue, 10 Dec 2013 11:21:16 +0800

Hi Roni,

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

Lizhong

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

Reviewer: Roni Even

Review Date:2013–12-8

IETF LC End Date: 2013-12–10

IESG Telechat date: 

 

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.

Nits/editorial comments:

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

---

From: "Roni Even" <[email-masked]>
Date: Tue, 10 Dec 2013 07:10:24 +0200

Hi Lizhong,

See inline

Roni

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

Hi Roni,

Lizhong

Reviewer: Roni Even

Review Date:2013-12-8

IESG Telechat date:

Major issues:

Minor issues:

[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:

---

From: Jari Arkko <[email-masked]>
Date: Thu, 19 Dec 2013 16:39:31 +0200

Roni, Lizhong,

Thank you very much Roni for your review. And Lizhong for the updates.

(By the way, I saw no change regarding 3.1; I do agree with Roni that adding some explanation might be useful. This is just a comment, however - I will let you decide how to deal with it.)

Jari

---

From: "Lizhong Jin" <[email-masked]>
Date: Sun, 22 Dec 2013 01:01:26 +0800

Hi Jari, Roni,
Thank you very much for the comments. Is it OK for you to change as below:
Section 3.1, "If the peer has not advertised the corresponding capability, then label messages using the HSMP FEC Element SHOULD NOT (as described in [RFC6388] section 2.1) be sent to the peer."
It is better to have the same description with RFC6388 here, so as to avoid any confusion.

Regards
Lizhong

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]]
> Sent: Thursday, December 19, 2013 10:40 PM
> To: Roni Even
> Cc: 'Lizhong Jin'; [email-masked];
> Subject: Re: [Gen-art] gen-ART LC review of draft-ietf-mpls-mldp-hsmp-
> 04
> 
> Roni, Lizhong,
> 
> (By the way, I saw no change regarding 3.1; I do agree with Roni that
> adding some explanation might be useful. This is just a comment,
> however - I will let you decide how to deal with it.)
> 
> Jari