Pseudowire Preferential Forwarding Status Bit
Note: This ballot was opened for revision 07 and is now closed.
(Stewart Bryant) Yes
(Ron Bonica) No Objection
(Gonzalo Camarillo) No Objection
(Benoit Claise) (was Discuss) No Objection
Comment (2012-09-25 for -08)
- <MY INITIAL COMMENT> Section 5.1 1. For FEC128 PW, the PW with the lowest pw-id value is selected. 2. For FEC129 PW, each PW in a redundant set is uniquely identified No idea what FEC128 and FEC129 were. I had to search and found http://tools.ietf.org/html/rfc4379#section-3.2.8, where by the way, they're spelled "FEC 128" and "FEC 129". So please add a reference. </MY INITIAL COMMENT> You solve the issue in section 5.1 by removing FEC128 and FEC129, but FEC 128 and FEC 129 still appear in different places of the document
(Ralph Droms) No Objection
(Wesley Eddy) No Objection
(Adrian Farrel) (was Discuss) No Objection
Thank you with your patient work to address my Discuss. --- I continue to be disappointed by the piecemeal invention of bolt-on signaling features for PW management. It really seems that the working group needs to work on a functional architecture for pseudowires to work out all of the bits and pieces that are needed for redundancy, bandwidth, multi-segment routing, etc., etc. I wish this would happen before we incrementally munge the protocol too much, but I understand that this is not directly actionable for the authors of this document.
(Stephen Farrell) No Objection
Comment (2012-05-21 for -07)
The security considerations say that this is the same as for 4447, which is arguably correct, but 4447 really defers to 3036, which a) doesn't consider switching over to a "less good" PW as a potential DoS (is it?) and b) only has TCP-MD5 based security which even in 2001 attracted an IESG note, repeated in 3036 from rfc 2385 (from 1998!). Any chance of getting some 21st century security stuff done in PW-land? (Sorry, but that's hard to resist:-) This is probably not the place to fix that, but it'd be good to know if there's a plan. Is there? Nits: - PE-rs is used without expansion (on p2) - FEC128 and FEC129 are used without definition on p11 (As as AGI::SAII:TAII) - What is the "system IP address"? (on p11) Could be fairly obvious, but then again if a node has many addresses, maybe not.
(Brian Haberman) No Objection
(Russ Housley) No Objection
Comment (2012-05-23 for -07)
Please consider the issues raised in the Gen-ART Review by Miguel Garcia on 23-May-2012. I tend to agree with his points on RFC 2119 language in Sections 5 and 15. Please find the review at: http://www.ietf.org/mail-archive/web/gen-art/current/msg07447.html.
(Barry Leiba) No Objection
(Pete Resnick) No Objection
Comment (2012-05-21 for -07)
Section 2: MANDATORY OPTIONAL OPTIONALLY Neither MANDATORY nor OPTIONALLY are 2119 terms. I suspect that the capitalized words in this section are a new magical usage of which I am unaware. Perhaps you might like to define terms? 5.1 The PW endpoints MAY also implement the following optional active PW selection mechanism. 1. If the PW endpoint is configured with the precedence parameter on each PW in the redundant set, it MUST select the PW with the lowest configured precedence value. So you MAY do something that you MUST do? I am confused. a management indication SHOULD be generated I may not understand what is meant by a "management indication" here, but it sounds like an implementation choice, not something that is required for interoperation. Did I get that wrong?
(Robert Sparks) No Objection
(Martin Stiemerling) No Objection
Comment (2012-05-21 for -07)
Please check the idnits: Checking nits according to http://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 19 instances of too long lines in the document, the longest one being 4 characters in excess of 72. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC5542, but the abstract doesn't seem to directly say this. It does mention RFC5542 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack a disclaimer for pre-RFC5378 work, but was first submitted before 10 November 2008. Should you add the disclaimer? (See the Legal Provisions document at http://trustee.ietf.org/license-info for more information.) -- however, there's a paragraph with a matching beginning. Boilerplate error? IETF Trust Legal Provisions of 28-dec-2009, Section 6.c(iii): "This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English." ... text found in draft: "Code Components extracted from this document must include Simplified BSD ......^ License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License." -- The document date (May 1, 2012) is 20 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-08) exists of draft-ietf-pwe3-redundancy-07
(Sean Turner) No Objection
Comment (2012-05-22 for -07)
Note these comments are the same for both draft-ietf-pwe3-redundancy and draft-ietf-pwe3-redundancy-bit. Much of the Terminology is repeated in draft-ietf-pwe3-redundancy and draft-ietf-pwe3-redundancy-bit. Can't you just point from on to the other? This uses the TCP MD5 "signature" option [RFC5036]. KARP's hopefully going to get this fixed sooner rather than later. So there's nothing for the authors to do about this otherwise recurring gripe. I'd like to suggest some tweaks to the security considerations section, assuming of course that I've not totally missed the mark: 1st - I think the "LDP extensions" are referred to as options in both RFC 4447 and 5036? 2nd - I think there's only one of them? 3rd - I think you mean control plane not control protocol? How about the following tweaks to the security considerations section: This document uses the TCP MD5 Signature option, as specified in , to protect pseudowires. This document has the same security considerations as in the PWE3 control-plane . If you want to future proof the text more maybe: LDP extensions/options that protect pseudowires must be implemented because the security considerations for the bits defined in this document have the same security considerations as the PWE3 control-plane .