Skip to main content

Extension to Sockets API for Mobile IPv6
RFC 4584

Yes

(Margaret Cullen)

No Objection

(Bill Fenner)
(David Kessens)
(Mark Townsley)
(Sam Hartman)

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

Margaret Cullen Former IESG member
Yes
Yes () Unknown

                            
Bert Wijnen Former IESG member
No Objection
No Objection (2005-08-18) Unknown
citation/reference problems:
  !! Missing citation for Informative reference:
  P020 L028: [3]    Deering, S., Hinden, R., "Internet Protocol, Version 6

  !! Missing Reference for citation: [RFC-3493]
  P004 L038:    body, such as has been done with the Basic API [RFC-3493]. 

  !! Missing Reference for citation: [RFC3245]
  P004 L040:    [RFC3245], such standardization would make sense only if
Bill Fenner Former IESG member
(was Discuss) No Objection
No Objection (2006-01-12) Unknown

                            
Brian Carpenter Former IESG member
No Objection
No Objection (2005-08-18) Unknown
From Gen-ART review by Mark Allman:

  + Section 1: "mainly target user-level" --> "mainly targets
    user-level"

  + Section 1: While the document is fine without specifying error
    handling it might be nice to add a note that this is not good
    practice.

  + Section 1: "deployed among implementations, it" --> "deployed, it"
David Kessens Former IESG member
No Objection
No Objection () Unknown

                            
Mark Townsley Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection (2005-08-17) Unknown
  In section 7: s/man in the middle/man-in-the-middle/

  Reference [1] contains two dates.  I believe the second one should
  be deleted.

  Section 11 should be deleted prior to publication.
Sam Hartman Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Ted Hardie Former IESG member
No Objection
No Objection (2005-08-17) Unknown
The document says:

Behavior of legacy IPv6 socket applications:

   Applications, whether or not they implement this specification, that 
   use the Advanced API mechanisms to receive Destination options or 
   Routing headers, need to ignore or otherwise properly handle the Home
   Address destination option and the type 2 routing headers according
   to this API specifications.


I found this pretty hard to parse.  I would suggest re-phrasing it.  Does "Legacy applications using
the Advanced API mechanisms to receive Destination options or Routing headers will ignore
the Home Address destination option and the type 2 routing headers specified here." capture
the intent?