Re: [Gen-art] Hi, Gen-art Telechat review of draft-ietf-mpls-mldp-node-protection-06 - follow up

Thanks Elwyn! Ice. > On 16 Sep 2015, at 15:32, Elwyn Davies wrote: > > Hi Ice. > > I had a quick look through the updates in -07 and that has addressed all the > points below. Definitely good to go now. > > Cheers, > Elwyn > >> I am the assigned Gen-ART reviewer for

Re: [Gen-art] Gen-art LC review of draft-ietf-mpls-mldp-node-protection-05

Hi Elwyn, First of all, thanks for the great comments. See a few responses inline below. I’ll submit the new version now, hope it addresses all your comments. > In particular, there doesn't seem to be any explanation of why the PLRs and > MPTs have to be directly connected to the protected

Re: [Gen-art] Gen-art LC review of draft-ietf-mpls-mldp-in-band-wildcard-encoding-02

be useful to know whether there will be a new version to check out for the IESG review report. Cheers, Elwyn On 04/11/14 22:03, IJsbrand Wijnands wrote: Hi Elwyn, Summary: Almost ready. There are a couple of clarifications around how IPv4 and IPv6 trees can or cannot be merged

Re: [Gen-art] Gen-art LC review of draft-ietf-mpls-mldp-in-band-wildcard-encoding-02

Hi Elwyn, Summary: Almost ready. There are a couple of clarifications around how IPv4 and IPv6 trees can or cannot be merged on a single MP-LSP that would be advantageous. Also the error handling in the parent RFCs (6388, 6826) is a bit sketchy resulting in messy handling if an LSR that

Re: [Gen-art] review of draft-ietf-l3vpn-mldp-vrf-in-band-signaling-03.txt

Hi Francis, I'll resolve the editorial nits. Regarding the co-author list, you say (soft) limit, what does (soft) mean here? Does one co-author need to drop of, or will it pass? Thx, Ice. On 17 Feb 2014, at 16:12, Francis Dupont francis.dup...@fdupont.fr wrote: I am the assigned Gen-ART

Re: [Gen-art] Review: draft-ietf-mpls-ldp-p2mp-14

Hi Joel, Thanks for the comments. Major issues: As I read the document, status codes (and stauts TLVs) are for reporting on the status of LSPs. They are not for negotiating behaviors. Thus, I find it very strange that make-before-break behavior (section 8) is requested (by a

Re: [Gen-art] Gen-ART Last Call Review of draft-ietf-pim-rpf-vector-06

Hi Ben, Sorry for the delay.. Substantive Comments: -- It is not clear to me why this is to be an informational RFC. It seems to be defining protocol. If that protocol is not intended to be a standard, then it would help to have an applicability statement to that effect. Good point,