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