Thanks, If you don't see an AD review by the middle of next week please hassle me,
Cheers, S. On 04/07/2013 03:45 PM, Hannes Tschofenig wrote: > Dear Stephen, Dear IESG Secretary, > > here is my shepherd writeup for <draft-ietf-oauth-revocation-06>. Please > proceed with the publication of this document. > > ------------------------------- > > (1) What type of RFC is being requested (BCP, Proposed Standard, Internet > Standard, Informational, Experimental, or Historic)? Why is this the proper > type of RFC? Is this type of RFC indicated in the title page header? > > The RFC type being requested in Standards Track. The type is appropriate for > this type of OAuth protocol extension. > > (2) The IESG approval announcement includes a Document Announcement Write-Up. > Please provide such a Document Announcement Write-Up. Recent examples can be > found in the "Action" announcements for approved documents. The approval > announcement contains the following sections: > > Technical Summary: > > Relevant content can frequently be found in the abstract and/or introduction > of the document. If not, this may be an indication that there are > deficiencies in the abstract or introduction. > > > The OAuth Token Revocation specification proposes an additional endpoint > for OAuth authorization > servers, which allows clients to notify the authorization server that > a previously obtained refresh or access token is no longer needed. > This allows the authorization server to cleanup security credentials. > A revocation request will invalidate the actual token and, if > applicable, other tokens based on the same authorization grant. > > > Working Group Summary: > > The document experienced no particular problems in the working group. > > Document Quality: > > The document has been deployed by four companies, namely by Salesforce, > Google, Deutsche Telekom, and MITRE. > The working group reviewed and discussed the document extensively. > > Personnel: > > Hannes Tschofenig is the document shepherd. The responsible area director is > Stephen Farrell. > > (3) Briefly describe the review of this document that was performed by the > Document Shepherd. > > I have reviewed this version of the document and provided feedback to earlier > versions of the draft. > The document is ready for publication. > > (4) Does the document Shepherd have any concerns about the depth or breadth > of the reviews that have been performed? > > I have no concerns about the level of reviews. > > (5) Do portions of the document need review from a particular or from broader > perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or > internationalization? If so, describe the review that took place. > > No, there is no need for further reviews. > > (6) Describe any specific concerns or issues that the Document Shepherd has > with this document that the Responsible Area Director and/or the IESG should > be aware of? For example, perhaps he or she is uncomfortable with certain > parts of the document, or has concerns whether there really is a need for it. > In any event, if the WG has discussed those issues and has indicated that it > still wishes to advance the document, detail those concerns here. > > I have no concerns regarding the document. > > (7) Has each author confirmed that any and all appropriate IPR disclosures > required for full conformance with the provisions of BCP 78 and BCP 79 have > already been filed. If not, explain why? > > Two of the three authors have confirmed that they are not aware of any IPRs. > Marius Scurtescu so far has not responded to my mails. > > (8) Has an IPR disclosure been filed that references this document? If so, > summarize any WG discussion and conclusion regarding the IPR disclosures. > > There are no IPR disclosures available for this document. > > (9) How solid is the WG consensus behind this document? Does it represent the > strong concurrence of a few individuals, with others being silent, or does > the WG as a whole understand and agree with it? > > The working group is in support of this document. > > (10) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarise the areas of conflict in separate email > messages to the Responsible Area Director. (It should be in a separate email > because this questionnaire is publicly available.) > > There has been no extreme discontent. > > (11) Identify any ID nits the Document Shepherd has found in this document. > (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). > Boilerplate checks are not enough; this check needs to be thorough. > > ID nits have been verified. There is one reference ([portable-contacts]) that > is not used in the document that has to be removed with the next draft update > or by the RFC Editor. > > (12) Describe how the document meets any required formal review criteria, > such as the MIB Doctor, media type, and URI type reviews. > > The document does not contain content that requires formal reviews. > > (13) Have all references within this document been identified as either > normative or informative? > > Yes. > > (14) Are there normative references to documents that are not ready for > advancement or are otherwise in an unclear state? If such normative > references exist, what is the plan for their completion? > > All normative references are published RFCs already. > > (15) Are there downward normative references references (see RFC 3967)? If > so, list these downward references to support the Area Director in the Last > Call procedure. > > There are no downward references. > > (16) Will publication of this document change the status of any existing > RFCs? Are those RFCs listed on the title page header, listed in the abstract, > and discussed in the introduction? If the RFCs are not listed in the Abstract > and Introduction, explain why, and point to the part of the document where > the relationship of this document to the other RFCs is discussed. If this > information is not in the document, explain why the WG considers it > unnecessary. > > This document will not change the status of existing RFCs. > > (17) Describe the Document Shepherd's review of the IANA considerations > section, especially with regard to its consistency with the body of the > document. Confirm that all protocol extensions that the document makes are > associated with the appropriate reservations in IANA registries. Confirm that > any referenced IANA registries have been clearly identified. Confirm that > newly created IANA registries include a detailed specification of the initial > contents for the registry, that allocations procedures for future > registrations are defined, and a reasonable name for the new registry has > been suggested (see RFC 5226). > > This document defines a new error code and follows the requirements in RFC > 6749. > > (18) List any new IANA registries that require Expert Review for future > allocations. Provide any public guidance that the IESG would find useful in > selecting the IANA Experts for these new registries. > > The shepherd is currently the expert for RFC 6749 IANA registry allocations. > > (19) Describe reviews and automated checks performed by the Document Shepherd > to validate sections of the document written in a formal language, such as > XML code, BNF rules, MIB definitions, etc. > > No text written in a formal language is contained in the document. > > ------------------------------- > > Ciao > Hannes > > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
