Note: This ballot was opened for revision 05 and is now closed.
Summary: Has enough positions to pass.
Comment (2011-09-05) 
I have not done a detailed review of this document and will trust that the
Security ADs have done.
I am somewhat puzzled by...
This document contains a new IANA considerations section to be added
to [RFC5273] as part of this update.
Section 3.2 says...
Reference: [ RFC-to-be ]
...and I assume that means *this* document.
So the new IANA section is as a result of 5273, but not part of it.
Comment (2011-09-06)
Doesn't the new change subject name thing require a new security
consideration? E.g. if an RA says it'd like a new cert renaming
stephen.farrell to *.google.com? I think just a sentence saying
that the RA and CA need to ensure that both the new and old names
adhere to any relevant policies/practices would do fine.
There may be a case for also making the general point as well
that CAs MUST check names are according to policy/practice
as well, but even if so, the new name change thing should
also get a mention I reckon.
But that can all be done in one sentence so it should be easy.
Comment (2011-09-08)
1. I believe that this format of defining in one RFC updates for other 3 RFCs
is quite difficult to read and follow.
2. - In section 2.5. New Section 6.20 RA Identity Proof Witness control:
"Identity Proof Version 2" should be "Identity Proof Version 2 control" if I'm
correct.
Comment (2011-09-06)
I concur with Wesley Eddy's comment, especially given the scope of changes to
RFC 5272.
Comment (2011-09-06)
Please consider the editorial comments from the Gen-ART Review by
Elwyn Davies on 5 September 2011.
Comment (2011-09-01)
I don't have any problem with this if the WG and people implementing from it
are happy with it, but it does seem that the format as just a collection of the
changes rather than a stand-alone document to be possibly confusing and
error-prone to work from. However, if the real stakeholders are happy with it,
then that's all that matters, I guess.
datatracker.ietf.org