Skip to main content

Traffic Engineering Extensions to OSPF for GMPLS Control of Evolving G.709 Optical Transport Networks
RFC 7138

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 steering group member) Yes

Yes (for -11)

                            

(Barry Leiba; former steering group member) No Objection

No Objection (2013-11-15 for -11)
-- 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 steering group member) No Objection

No Objection (for -11)

                            

(Brian Haberman; former steering group member) No Objection

No Objection (for -11)

                            

(Gonzalo Camarillo; former steering group member) No Objection

No Objection (for -11)

                            

(Jari Arkko; former steering group member) No Objection

No Objection (2013-11-20 for -11)
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 steering group member) No Objection

No Objection (2013-11-20 for -11)
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 steering group member) No Objection

No Objection (for -11)

                            

(Pete Resnick; former steering group member) No Objection

No Objection (for -11)

                            

(Sean Turner; former steering group member) No Objection

No Objection (for -11)

                            

(Spencer Dawkins; former steering group member) No Objection

No Objection (for -11)

                            

(Stephen Farrell; former steering group member) No Objection

No Objection (2013-11-20 for -11)
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 steering group member) No Objection

No Objection (for -11)