Re: [apps-discuss] Publication request:draft-faltstrom-5892bis-04

[Patrik Fältström <[e-mail]>]

Thank you for your work!

   Patrik

On 17 maj 2011, at 05:11, "Jiankang YAO" <[e-mail]> wrote:

> Dear ADs,
> 
> This message is a request to publish
> draft-faltstrom-5892bis-04 on the Standards Track.
> The draft represents the rough consensus of the APPSAWG Working
> Group.
> 
> As required by RFC 4858, below is the completed current template for
> the Document Shepherd Write-Up.
> 
> 
> Best regards,
> Jiankang Yao(as a co-chair of APPSAWG)
> 
> 
> --------------------------------------------
> 
> DRAFT FILENAME: 
>    draft-faltstrom-5892bis-04
> TITLE: 
>   The Unicode code points and IDNA - Unicode 6.0
> 
> 
> 
>  (1.a) Who is the Document Shepherd for this document? Has the
>        Document Shepherd personally reviewed this version of the 
>        document and, in particular, does he or she believe this 
>        version is ready for forwarding to the IESG for publication? 
> 
> Jiankang Yao.  Yes, I believe it is ready.
> 
>  (1.b) Has the document had adequate review both from key WG members 
>        and from key non-WG members? Does the Document Shepherd have 
>        any concerns about the depth or breadth of the reviews that 
>        have been performed?
> 
> There has a lot of discussions and an informal last call for comments about
> this draft in the IDNAbis list [e-mail].  
> The APPSAWG has been talking about this draft for some time.  I believe it
> has had adequate review.  
> 
>  (1.c) Does the Document Shepherd have concerns that the document 
>        needs more review from a particular or broader perspective, 
>        e.g., security, operational complexity, someone familiar with 
>        AAA, internationalization or XML? 
> 
> No.
> 
>  (1.d) Does the Document Shepherd have any specific concerns or 
>        issues 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. Has an IPR disclosure related to this document 
>        been filed? If so, please include a reference to the 
>        disclosure and summarize the WG discussion and conclusion on 
>        this issue. 
> 
> This draft is a document that updates RFC 5892 by
> stating nothing is to be changed with respect to Unicode
> version 6. The IESG needs to decide whether this document
> should be marked as "updating" RFC 5892 or not.
> 
> 
> 
>  (1.e) 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?   
> 
> Many WG participants from IDNAbis and APPSAWG have reviewed this document and
> had reasonably strong WG consensus.
> 
>  (1.f) 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 
>        entered into the ID Tracker.) 
> 
> No.
> 
>  (1.g) Has the Document Shepherd personally verified that the 
>        document satisfies all ID nits? (See the Internet-Drafts Checklist 
>        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are 
>        not enough; this check needs to be thorough. Has the document 
>        met all formal review criteria it needs to, such as the MIB 
>        Doctor, media type and URI type reviews? 
> 
> Yes, I have checked it. There is one unused reference; see 1.h.
> 
> 
>  (1.h) Has the document split its references into normative and 
>        informative? 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 
>        strategy for their completion? Are there normative references 
>        that are downward references, as described in [RFC3967]? If 
>        so, list these downward references to support the Area 
>        Director in the Last Call procedure for them [RFC3967]. 
> 
> The references are correct.  There are two references to non-IETF
> documents (Unicode 5.2 and Unicode 6.0), and those are necessary and
> correct.
> 
> "Unicode6" is listed as a normative reference, but
> it is never referenced in the main text although "Unicode 6.0" is
> used everywhere.  Please add the following RFC Editor note:
> ---
> Introduction, first paragraph:
> OLD
>   it defines a derived property value.  Unicode 6.0 has changed
>   GeneralCategory of three code points that where allocated in Unicode
> NEW
>   it defines a derived property value.  Unicode 6.0 [Unicode6] has changed
>   GeneralCategory of three code points that where allocated in Unicode
> ---
> 
>  (1.i) Has the Document Shepherd verified that the document IANA 
>        consideration section exists and is consistent with the body 
>        of the document? 
> 
> Yes.
> 
> 
>        If the document specifies protocol 
>        extensions, are reservations requested in appropriate IANA 
>        registries? Are the IANA registries clearly identified? If 
>        the document creates a new registry, does it define the 
>        proposed initial contents of the registry and an allocation 
>        procedure for future registrations? Does it suggest a 
>        reasonable name for the new registry? See [RFC5226]. If the 
>        document describes an Expert Review process has Shepherd 
>        conferred with the Responsible Area Director so that the IESG 
>        can appoint the needed Expert during the IESG Evaluation? 
> 
> N/A.
> 
> 
>  (1.j) Has the Document Shepherd verified that sections of the 
>        document that are written in a formal language, such as XML 
>        code, BNF rules, MIB definitions, etc., validate correctly in 
>        an automated checker? 
> 
> There is no formal language in this document.
> 
> 
>  (1.k) 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 
> 
> This document specifies IETF consensus for IDNA derived character
> properties related to the three code points, existing in Unicode 5.2,
> that changed property values when version 6.0 was released. 
> 
> 
>     Working Group Summary 
> 
> This document has been discussed both in the old IDNAbis WG list and APPSAWG list. 
> The WG came to consensus on this document.
> 
> 
> 
>     Document Quality 
> 
> This document is concise and clear,
> and is ready for publication
> 
> (end)
> ---------------------------------------------
> _______________________________________________
> apps-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>