Skip to main content

Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)
RFC 4023

Yes

(Alex Zinin)

No Objection

(Bill Fenner)
(David Kessens)
(Jon Peterson)
(Russ Housley)
(Scott Hollenbeck)
(Steven Bellovin)
(Thomas Narten)

Abstain


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

(Alex Zinin; former steering group member) Yes

Yes ()

                            

(Allison Mankin; former steering group member) (was Discuss) No Objection

No Objection (2004-02-19)
I gave my assent to the author on wording to clear my Discuss on this 6 weeks
ago.  It would have been helpful to be given back my email when asked to
re-check the i-d, rather than having me find it.

(Bert Wijnen; former steering group member) (was Discuss) No Objection

No Objection (2003-12-18)
Comments from Bert:

- I do not understand why RFC791 is normative while RFC2460 is
  Informative 

Comments/Nits from OPS directorate (by Pekka).

We know that some are REAL NITs. just to record them in case
a new rev is done anyway.

Network Working Group                                        Tom Worster
Internet Draft
Expiration Date: March 2004
                                                           Yakov Rekhter
                                                  Juniper Networks, Inc.
                                                                                                                                       
                                                   Eric C. Rosen, editor
                                                     Cisco Systems, Inc.

==> s/Tom/T./, s/Yakov/Y./, s/Eric C./E./

7. IANA Considerations
                                                                                                                                       
   The MPLS-in-IP encapsulation requires that IANA allocate two IP
   Protocol Numbers, as described in section 3.  No future IANA actions
   will be required.  The MPLS-in-GRE encapsulation does not require any
   IANA action.

==> the last sentence should be removed, as it conflicts with the 
rest of the section.

   [RFC2460]"Internet Protocol, Version 6 (IPv6) Specification," S.
 
==> s/]"/] "/

9. Intellectual Property Notice
                                                                                                                                       
10. Copyright Notice

==> I'd recommend moving these after Authors Information section (14.)

14. Author Information
                                                                                                                                       
==> s/Author Information/Authors' Addresses/

(Bill Fenner; former steering group member) No Objection

No Objection ()

                            

(David Kessens; former steering group member) No Objection

No Objection ()

                            

(Harald Alvestrand; former steering group member) No Objection

No Objection (2004-05-26)
Reviewed by Brian Carpenter, Gen-ART

(Jon Peterson; former steering group member) No Objection

No Objection ()

                            

(Margaret Cullen; former steering group member) No Objection

No Objection (2003-12-17)
I share Thomas' concerns, but did not choose to enter a separate discuss.

(Ned Freed; former steering group member) No Objection

No Objection (2003-12-12)
Copyright section has (date) rather than actual date

(Russ Housley; former steering group member) (was Discuss) No Objection

No Objection ()

                            

(Scott Hollenbeck; former steering group member) No Objection

No Objection ()

                            

(Steven Bellovin; former steering group member) (was Discuss) No Objection

No Objection ()

                            

(Thomas Narten; former steering group member) (was Discuss) No Objection

No Objection ()

                            

(Ted Hardie; former steering group member) Abstain

Abstain (2003-12-16)
As a general comment, I agree with all of Thomas's operational concerns, and I think there are probably more waiting in the weeds.  This seems to create a very generalized pair of mechanisms
that can probably actually only be used successfully in very tightly pre-configured situations.  

Melinda Shore has several times raised a flag that we're turning our end-to-end network into an all
tunnel network.  When we start tunnelling tunnelling protocols and protecting their security with tunnels, we're in trouble.