Skip to main content

Applicability of MPLS Transport Profile for Ring Topologies
draft-ietf-mpls-tp-ring-protection-06

Yes

(Adrian Farrel)

No Objection

(Brian Haberman)
(Gonzalo Camarillo)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Pete Resnick)
(Richard Barnes)
(Sean Turner)
(Spencer Dawkins)

Recuse

(Stewart Bryant)

Note: This ballot was opened for revision 06 and is now closed.

Adrian Farrel Former IESG member
Yes
Yes () Unknown

                            
Barry Leiba Former IESG member
No Objection
No Objection (2013-05-10) Unknown
I don't object to the Informational status of this document, but I have to ask, in a non-blocking and non-confrontational way:

From the shepherd writeup:
   This document does not specify a protocol but describes how to
   use the MPLS-TP linear protection as specified in RFC 6378 for 
   ring topologies, the document is thus intended to be published as
   an informational RFC.

This really *is* what applicability statements are for, the title even calls itself an applicability statement, and it does make recommendations (not just give information).  I wonder, then, why it's Informational, rather than Standards Track (see RFC 2026, Section 3.2).
Benoît Claise Former IESG member
No Objection
No Objection (2013-05-15) Unknown
Probably the RFC editors would correct this. Anyway, here it is

"Contributing Authors" section title -> "Contributors"

https://www.rfc-editor.org/rfc-editor/instructions2authors.txt :

      1.  First-page header           [Required]
      2.  Status of this Memo         [Required*]
      3.  Copyright Notice            [Required*]
      4.  IESG Note                   [As requested by IESG*]
      5.  Abstract                    [Required]
      6.  Table of Contents           [Required for large documents]
      7.  Body of the Memo            [Required]
       7a.  Contributors
       7b.  Acknowledgments
       7c.  Security Considerations   [Required]
       7d.  IANA Considerations
       7e.  Appendixes
       7f.  References
      8. Author's Address             [Required]
      9. IPR Boilerplate              [Required*]
Brian Haberman Former IESG member
No Objection
No Objection () Unknown

                            
Gonzalo Camarillo Former IESG member
No Objection
No Objection () Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection () Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection () Unknown

                            
Martin Stiemerling Former IESG member
No Objection
No Objection () Unknown

                            
Pete Resnick Former IESG member
No Objection
No Objection () Unknown

                            
Richard Barnes Former IESG member
No Objection
No Objection () Unknown

                            
Sean Turner Former IESG member
No Objection
No Objection () Unknown

                            
Spencer Dawkins Former IESG member
No Objection
No Objection () Unknown

                            
Stephen Farrell Former IESG member
No Objection
No Objection (2013-05-14) Unknown
- So colour me puzzled - the write up says "nothing new here,
just a way to use 6378" but there are two RAND+fee IPR
declarations. Sigh. (But no more than a sigh since the WG are
ok with it.)

- Is the syntax on p6 for describing label stacks not more
generic than this? I assume its too late (or not worth the
bother) to take this out into its own informational RFC as it
might be more broadly useful. If that text is replicated from
elsewhere then I'd suggest you reference the elsewehere and
not include it here again.

- The tables/figures/whatever between figures 7 and 9 have no
captions.
Stewart Bryant Former IESG member
Recuse
Recuse () Unknown