MPLS Transport Profile (MPLS-TP) Applicability: Use Cases and Design
draft-ietf-mpls-tp-use-cases-and-design-08
Yes
(Adrian Farrel)
No Objection
(Gonzalo Camarillo)
(Richard Barnes)
(Ted Lemon)
Abstain
(Joel Jaeggli)
Note: This ballot was opened for revision 07 and is now closed.
Adrian Farrel Former IESG member
Yes
Yes
(for -07)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(2013-03-26 for -07)
Unknown
I have to agree with Stephen that this really comes off more as a glossy brochure than as an IETF document. But given the shepherd's contention that there's strong consensus in the working group to publish this, I'll say, "Mostly harmless."
Benoît Claise Former IESG member
No Objection
No Objection
(2013-03-26 for -07)
Unknown
I tend to agree with Stephen's general sentiment regarding some marketing in the document. However, as the write-up mentions "This document has a strong support in the working group and has been well reviewed.", I will record "no objection"
Brian Haberman Former IESG member
No Objection
No Objection
(2013-03-27 for -07)
Unknown
I agree with Stephen's point that there doesn't seem to be any benefit in publishing this draft as an RFC.
Gonzalo Camarillo Former IESG member
No Objection
No Objection
(for -07)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(2013-03-27 for -07)
Unknown
I did not think Section 1.2 was very informative. A rewrite in a different style would have made it better. These last call comments from Russ Housley were also on Section 1.2: ---- I wonder if the direction of Section 1.2 can be revised to make it more of an engineering document. It currently says: In recent years, the urgency for moving from traditional transport technologies, such as SONET/SDH, TDM, and ATM, to new packet technologies has been rising. This is largely due to the fast growing demand for bandwidth, which has been fueled by the following factors: ... Please consider an approach that describes the the reasons behind the transition from the network operator and network user perspectives: Traditional transport technologies include SONET/SDH, TDM, and ATM. There is a transition away from these transport technologies to new packet technologies. In addition to the ever increasing demand for bandwidth, the packet technologies offer these advantages: ... The fact that IP networks are being used for new applications and that the legacy devices are getting old does not motivate the transition to packet technologies. The advantages that packet technologies offer for these new applications is the thing that needs to be highlighted here, even if it is just a list of bullets. It seems like the only sentence that addresses this point in Section 1.2 is: "It streamlines the operation, reduces the overall complexity, and improves end-to-end convergence."
Martin Stiemerling Former IESG member
No Objection
No Objection
(2013-03-26 for -07)
Unknown
I'm fine with the current text wrt to "transport" (packet transport) vs. "transport" (TCP), as at least in my understanding the difference is clear in the text context of this particular draft.
Richard Barnes Former IESG member
No Objection
No Objection
(for -07)
Unknown
Sean Turner Former IESG member
No Objection
No Objection
(2013-03-27 for -07)
Unknown
I think this is harmless but it definitely felt like a glossy brochure. When do I get an MPLS-TP t-shirt?
Stephen Farrell Former IESG member
No Objection
No Objection
(2013-03-22 for -07)
Unknown
- The "transport" (packet transport) vs. "transport" (TCP) terminology divergence screams out here, even from the moment one starts reading the ballot writeup. The routing and transport ADs might want to do something about that sometime. (The transport ADs get 2x votes as to what to do of course:-) - Once I did start reading, my marketing-BS detectors started firing big time. (See the specific comments below.) To be honest, I think this kind of post-facto justification marketing-spiel is mildly damaging to the RFC series. Not enough to object, but enough to be objectionable. - 1.1, I dare you to invent expansions of 5G, 6G, 7G etc.:-) And looking at this section, I don't believe all the acronyms expanded are actually used, e.g. "AIS" seems to occur exactly once in the document. There are also seem to be acronyms that are expanded here that are used exactly once which seems like a waste of space. And lastly, expanding an acronym is not really the same as defining a term, and this section does the former and not the latter mostly. So overall, this section seems not so useful and more for forms sake or to make the document look "more serious" both of which seem undesirable to this reader. - 1.2, "many legacy transport devices are approaching end of life" - I'd love to see some references there, (since I think that's an interesting fact, if its a fact) but the phrase is also vague - do you mean the devices are reaching end of life or the product lines are? - 1.2, "MPLS family," "complements existing," "closes the gap," "efficient, reliable" and "emerged as the next generation transport technology of choice" all seem to me to be purely marketing terms and are all are used within one paragraph here. Phrases in subsequent paragraphs outdo this one. IMO the best IETF marketing materials involve code and/or technical detail of existing deployment details and we're really not the best place from which to launch this kind of text. (It turned me off the rest of the document anyway fwiw, I'd never have read the whole thing if I didn't have to ballot on it.) - 2.1, "becoming inadequate," "too expensive to maintain," without references those are merely truth by blatent assertion. "a natural choice" also grates. - 2.1, "most Service Provider's core networks are MPLS enabled" seems to scream for a reference - 2.1, "it reduces OPEX" seems similarly without factual backing, "improves network efficiency" begs for a metric and "reduces end-to-end convergence time" is talking about something I'm sure, but its not clear what. (At this point, I'm gonna stop calling out marketing text. There's too much and it'd take too long. And it turns out the only comments I would have had were negative "we don't do marketing" things anyway;-)
Stewart Bryant Former IESG member
(was Discuss)
No Objection
No Objection
(2013-05-02)
Unknown
Many thanks for addressing my concerns.
Ted Lemon Former IESG member
No Objection
No Objection
(for -07)
Unknown
Joel Jaeggli Former IESG member
Abstain
Abstain
(for -07)
Unknown
Pete Resnick Former IESG member
(was Discuss)
Abstain
Abstain
(2013-03-28 for -07)
Unknown
This does sound like a lot of marketing fluff. *Why* did the WG think this was important to publish? Why was there "strong support in the WG"? Why is this "a reasonable contribution to the area of Internet engineering which it covers?"