Traffic Engineering Extensions to OSPF for GMPLS Control of Evolving G.709 Optical Transport Networks
draft-ietf-ccamp-gmpls-ospf-g709v3-13
Yes
(Adrian Farrel)
No Objection
(Benoît Claise)
(Brian Haberman)
(Gonzalo Camarillo)
(Martin Stiemerling)
(Pete Resnick)
(Sean Turner)
(Spencer Dawkins)
(Stewart Bryant)
Note: This ballot was opened for revision 11 and is now closed.
Adrian Farrel Former IESG member
Yes
Yes
(for -11)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(2013-11-15 for -11)
Unknown
-- Section 1 -- Routing information for Optical Channel Layer (OCh) (i.e., wavelength) is beyond the scope of this document. Is "i.e." correct here? Is wavelength the only factor? -- Section 2 -- For example, if a multiplexing or example a multiplexing hierarchy like the following one is considered: This doesn't make sense. Is there a copy/paste error in there? -- Section 4 -- In contrast with most usage, we don't usually expand "IEEE". I actually found it quite odd to see it done. "IEEE floating point format" should be fine. -- Section 4.1.1 -- The values of the fields shown in figure 4 are explained in section 4.1.3. That should be "figure 3". -- Section 9.1 -- You should have a note to the RFC Editor to replace the "TBA by IANA" in Section 4. -- Section 9.2 -- You should have a note to the RFC Editor to replace the "TBA by IANA" in Section 4.1.
Benoît Claise Former IESG member
No Objection
No Objection
(for -11)
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
(for -11)
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
(for -11)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(2013-11-20 for -11)
Unknown
There is continued discussion of the modifications from the Gen-ART review. I'm not sure if the IANA change has been implemented. Please check the mail thread!
Joel Jaeggli Former IESG member
No Objection
No Objection
(2013-11-20 for -11)
Unknown
with resecept to stephens comment, it seems unlikely that noodling with the security considerations text will have any effect at all on the outcome. I can live with it as written
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -11)
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
(for -11)
Unknown
Sean Turner Former IESG member
No Objection
No Objection
(for -11)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -11)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2013-11-20 for -11)
Unknown
The security considerations section here seems like a cut and paste from rfc 3630, which is referred to from here. But 3630 does not actually seem to "suggest mechanisms" so the reference seems wrong and when in any case did "suggestion" become a useful form of specification? This reads as if the minimum cursory amount of text that might satisfy was added. Having said that, I don't have time to analyse this sufficient to turn this into a discuss-worthy point, so I'm committing the same sin with this cursory comment.
Stewart Bryant Former IESG member
No Objection
No Objection
(for -11)
Unknown