Skip to main content

Hierarchical IPv4 Framework
RFC 6306

Yes

(Ralph Droms)

No Objection

(Dan Romascanu)
(Gonzalo Camarillo)
(Jari Arkko)
(Ron Bonica)
(Russ Housley)
(Stewart Bryant)

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

(Ralph Droms; former steering group member) Yes

Yes ()

                            

(Adrian Farrel; former steering group member) No Objection

No Objection (2011-04-14)
I have no objection to the publication of this document as Experimental.

I note that RFC 3032 is given as the eference for [MPLS]. I think that RFC 3031 is a more central anchor for the MPLS architecture.

(Dan Romascanu; former steering group member) (was Discuss) No Objection

No Objection ()

                            

(Gonzalo Camarillo; former steering group member) No Objection

No Objection ()

                            

(Jari Arkko; former steering group member) (was Discuss) No Objection

No Objection ()

                            

(Pete Resnick; former steering group member) (was Discuss, No Objection) No Objection

No Objection (2011-04-13)
As an IRTF submission, I'm only evaluating on the basis of conflict with IETF stuff. To that end, though it could be argued that using "hIPv4" as an abbreviation of the protocol name "could potentially disrupt the IETF work done in" HIP, I don't feel strongly enough to say that we should file an objection with the RFC Editor just because of that.

This work is certainly related to work going on in LISP, but I don't think it's conflicting.

(Ron Bonica; former steering group member) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) No Objection

No Objection ()

                            

(Stephen Farrell; former steering group member) No Objection

No Objection (2011-04-14)
I thought the IRTF process called for something about document status to be in the abstract as well?

(Stewart Bryant; former steering group member) No Objection

No Objection ()

                            

(Wesley Eddy; former steering group member) No Objection

No Objection (2011-04-12)
The Security Considerations section appears to be a bit light, and I would suggest improving this section.

I have no objections to publishing this, but here are some editorial nits:

page 5, 3rd to last paragraph: should "three areas: area" be "three types of areas: stub area"?

should note during first occurrence of "LSR" that this does *not* refer to an MPLS Label Switching Router, since this is overloading an already well-known acronym

page 10 - "in Internet" -> "in the Internet"

page 11 - how can the ALOC prefix (which is a prefix, not an address) be assigned as the locator for the LSRs or announced as an anycast *address* as it says on this page?  The wording choices might be clarified here.

page 12 - "since the destination address is the remote ALOC prefix" this text seems to have the same address/prefix confusion as above; should this really say "is within the remote ALOC prefix?"  If the bare prefix itself is used as an address, doesn't this severely limit the number of ALOCs available?