A Property Types Registry for the Authentication-Results Header Field
draft-ietf-appsawg-authres-ptypes-registry-04
Yes
(Barry Leiba)
(Pete Resnick)
No Objection
(Adrian Farrel)
(Alia Atlas)
(Benoît Claise)
(Brian Haberman)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Richard Barnes)
(Ted Lemon)
Note: This ballot was opened for revision 04 and is now closed.
Barry Leiba Former IESG member
Yes
Yes
()
Unknown
Pete Resnick Former IESG member
Yes
Yes
()
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
()
Unknown
Alia Atlas Former IESG member
No Objection
No Objection
()
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
()
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
()
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
()
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
(2014-10-15)
Unknown
I'm curious to see the response to Stephen's question, if that's possible, it may be a good way to handle security issues that may arise with new ptypes.
Martin Stiemerling Former IESG member
No Objection
No Objection
()
Unknown
Richard Barnes Former IESG member
No Objection
No Objection
()
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2014-10-13)
Unknown
I wondered if it'd be worthwhile asking that the designated expert try ensure that the security and privacy consequences of new entries also be documented? That's assuming there are cases where the header field is likely to transit between ADMDs. I'm not sure if that's really needed though, but 7001 does have a fairly significant set of security considerations, so presumably new entries might also deserve a similar level of documentation. OTOH, I could buy that experience with 7001 means that this isn't really needed or that demanding that level of documentation might be counterproductive.
Ted Lemon Former IESG member
No Objection
No Objection
()
Unknown