Skip to main content

A Presence-based GEOPRIV Location Object Format
draft-ietf-geopriv-pidf-lo-03

Yes

(Allison Mankin)
(Ted Hardie)

No Objection

(Bill Fenner)
(David Kessens)
(Jon Peterson)
(Margaret Cullen)
(Thomas Narten)

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

Allison Mankin Former IESG member
Yes
Yes () Unknown

                            
Ted Hardie Former IESG member
Yes
Yes () Unknown

                            
Bert Wijnen Former IESG member
No Objection
No Objection (2004-08-19) Unknown
Quite a set of lines occur which are (much) longer than 72 characters

Oterhwise no further objections
Bill Fenner Former IESG member
No Objection
No Objection () Unknown

                            
David Kessens Former IESG member
No Objection
No Objection () Unknown

                            
Harald Alvestrand Former IESG member
No Objection
No Objection (2004-08-19) Unknown
Reviewed by John Loughney, Gen-ART
IANA considerations section for "method" token should say FCFS explicitly.
Password-based encryption is a MUST, so reference should be normative.
(No opinion stated on whether the WG is right in making passwords MUST and certificates SHOULD - this is a WG decision that I won't second-guess.)
Jon Peterson Former IESG member
(was Recuse) No Objection
No Objection () Unknown

                            
Margaret Cullen Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
(was Discuss) No Objection
No Objection (2004-08-17) Unknown
  It would be nice if the Abstract said what new features are provided
  in the enhanced PDIF.  In short, what was it extended.  I think the
  Introduction tells us, and I think the Abstract should say something
  like: "This document extends the XML-based Presence Information Data
  Format (PIDF) to allow the encapsulation of location information
  within a presence document."

  The document uses "GEOPRIV requirements" and "geopriv requirements."
  Please pick one.

  Does civilLoc A5 also include subdivisions?  Perhaps this is a synonym
  for neighborhood.

  In section 2.2.2, some white space between each field description would
  help the reader.

  In section 4, it should read: "... EnvelopedData and SignedData content
  types, ..."

  Reference [5] should point to RFC 3851.

  Reference [6] should point to RFC 3852.

  Reference [17] should point to RFC 3850, which includes S/MIME-specific
  certificate conventions.  If you also want a more general reference, I
  strongly prefer RFC 3280.

  Appendix seems to be truncated.  It stops in the middle of a sentence.
Scott Hollenbeck Former IESG member
(was No Record, Discuss) No Objection
No Objection (2004-08-12) Unknown
For what it's worth, it's not necessary to specify minOccurs="1" and maxOccurs="1" in the element definitions listed in the schemas.  Those are the default values.
Steven Bellovin Former IESG member
No Objection
No Objection (2004-08-15) Unknown
Certificates are a SHOULD; shared secret is a MUST.  Is that compatible with likely deployment patterns?  What about obtaining the other party's certificate?  Is that likely to be an issue here?
Thomas Narten Former IESG member
No Objection
No Objection () Unknown