Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address
RFC 3956

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

(David Kessens) Yes

Comment (2004-06-25 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Comments received from gen-art (by Mark Allman <mallman@icir.org>):

I'd say this draft is not quite ready.  A few points ....
                                                                                  
 * I'd **really** like to see an introduction that says what problem is
   being solved in very high-level terms.  By the end of the document I
   sort of have an understanding, but I was immediately lost because
   the document seems to assume context that just isn't there for some
   of us.  I understand that this is really only going to be used by
   folks implementing, but still --- I don't think it too much to ask
   to craft a statement on the problem the document solves that
   everyone else can understand.
                                                                                  
 * Please define all acronymns.  There are plenty of cases when an
   acronymn is just used without being defined or even spelled out.
   Please check them all.  (A concrete example is the use of "DR"
   starting in section 6.)
                                                                                  
 * Likewise, this (S,G) notation is weird to an outsider.  A word or
   two about it's meaning would be useful (not an entire tutorial -- I
   understand the document is not for "outsiders", but a little help
   would be appreciated).
                                                                                  
 * The text does not refer to appendix A, but should.
                                                                                  
 * Section 3:
                                                                                  
   The first half of the section seems un-needed to me (before the
   diagram).  This text says things like if the flags are set to "01".
   But, that is not really what is meant.  Rather, the document is
   keying on the second bit being one.  At the moment, the first bit is
   unassigned and should be zero.  But, the document even notes that
   this may change in the future.  So, why does the document specify
   the first bit when it doesn't need to?

   Also, what happens when R=1 and either P or T (or both) are not 1?
   It seems that the failure cases should be considered more.
                                                                                  
 * In the diagram on page 6, I assume "ID" is really "RIID"?  I'd
   suggest changing the diagram for consistency.

(Harald Alvestrand) No Objection

(Steven Bellovin) No Objection

(Margaret Cullen) No Objection

(Bill Fenner) (was Discuss) No Objection

(Ted Hardie) (was Discuss) No Objection

(Scott Hollenbeck) No Objection

Comment (2004-06-18 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Missing IANA Considerations (I-D checklist), though I assume it's not there because there aren't any.

(Russ Housley) No Objection

Comment (2004-06-23 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
  Please delete Appendix B before publication as an RFC.

(Allison Mankin) No Objection

(Thomas Narten) (was Discuss) No Objection

(Jon Peterson) No Objection

(Alex Zinin) (was Discuss) No Objection