Hierarchical IPv4 Framework
RFC 6306

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

(Ralph Droms) Yes

(Jari Arkko) (was Discuss) No Objection

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Wesley Eddy) No Objection

Comment (2011-04-12 for -)
No email
send info
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?

(Adrian Farrel) No Objection

Comment (2011-04-14 for -)
No email
send info
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.

(Stephen Farrell) No Objection

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

(Russ Housley) No Objection

(Pete Resnick) (was Discuss, No Objection) No Objection

Comment (2011-04-13)
No email
send info
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.

(Dan Romascanu) (was Discuss) No Objection