While I completely agree with Matthew's edits, do informative RFCs normally have normative references? None of the text is normative ....
Cheers, Andy On Tue, Jun 16, 2009 at 10:40 AM, BOCCI Matthew<[email protected]> wrote: > Scott, > > Many thanks for your review. > >> -----Original Message----- > > [snip] > >> >> Summary: This draft is ready for publication as an informational RFC. >> >> Major issues: >> >> Minor issues: >> >> Nits/editorial comments: >> >> - In this one paragraph: >> >> Note that although Figure 4 only shows a single S-PE, a PW may >> transit more one S-PE along its path. This architecture is >> applicable when the S-PEs are statically chosen, or when they are >> chosen using a dynamic path selection mechanism. Both directions >> of an MS-PW must traverse the same set of S-PEs on a reciprocal >> path. Note that although the S-PE path is therefore reciprocal, >> the path taken by the PSN tunnels between the T-PEs and S-PEs may >> not be reciprocal due to choices made by the PSN routing protocol. >> >> ... "reciprocal" is used, but nowhere else in the document. Should >> it be "bi-directional" (used elsewhere)? > > We mean 'reciprocal' here rather than bidirectional. This section uses > the term reciprocal to refer to the corresponding, but opposite > directions of a PW. Thus we are using the navigational definition of the > term. > >> >> >> - 15.1 "References" should be "Normative References" > > Actually I think we need to split the references properly into normative > and informative references. Since this is also an informational draft, > it is also inappropriate to cite RFC2119. The editors therefore propose > rearranging the references as follows: > > 15. References > 15.1. Normative References > [1] Bryant, S. and Pate, P. (Editors), "Pseudo Wire Emulation > Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005 > [2] Andersson, L. and Madsen, T., "Provider Provisioned Virtual > Private Network (VPN) Terminology", RFC 4026, March 2005 > [3] Rosen, E. Viswanathan, A. and Callon, R., "Multiprotocol Label > Switching Architecture", RFC 3031, January 2001 > [4] Malis, A. and Townsley, M., "Pseudowire Emulation Edge-to-Edge > (PWE3) Fragmentation and Reassembly", RFC 4623, August 2006 > > 15.2. Informative References > > [5] Martini, L. Bitar, N. and Bocci, M (Editors), "Requirements for > Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)", RFC 5254, > October 2008 > [6] Bryant, S. & Andersson, L. "JWT Report on MPLS Architectural > Considerations for a Transport profile", RFC 5317, February 2009 > > > Also, in removing the RFC2119 citation we spotted one MUST that is > inappropriate for this informational draft, and removed the 'conventions > used in this document' section. The inappropriate MUST is in section 1.3 > bullet 3, where we propose the following change: > > OLD: > o Multi-Segment Pseudowire (MS-PW). A static or dynamically > configured set of two or more contiguous PW segments that behave and > function as a single point-to-point PW. Each end of a MS-PW by > definition MUST terminate on a T-PE. > > NEW: > o Multi-Segment Pseudowire (MS-PW). A static or dynamically > configured set of two or more contiguous PW segments that behave and > function as a single point-to-point PW. Each end of a MS-PW by > definition terminates on a T-PE. > > > Best regards > > Matthew > >> >> >> Scott >> _______________________________________________ >> pwe3 mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/pwe3 > _______________________________________________ > pwe3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/pwe3 > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
