Skip to main content

Hierarchical IPv4 Framework
draft-frejborg-hipv4-14

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 IESG member
Yes
Yes () Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection (2011-04-14) Unknown
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 IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Gonzalo Camarillo Former IESG member
No Objection
No Objection () Unknown

                            
Jari Arkko Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Pete Resnick Former IESG member
(was Discuss, No Objection) No Objection
No Objection (2011-04-13) Unknown
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 IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection () Unknown

                            
Stephen Farrell Former IESG member
No Objection
No Objection (2011-04-14) Unknown
I thought the IRTF process called for something about document status to be in the abstract as well?
Stewart Bryant Former IESG member
No Objection
No Objection () Unknown

                            
Wesley Eddy Former IESG member
No Objection
No Objection (2011-04-12) Unknown
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?