Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX)
draft-turner-additional-new-asn-08

[Ballot comment]
1. I support Stewart's DISCUSS

2. I think that the title of the document is too general and should be more specific - e.g. 'Additional New ASN.1 Modules Using the Cryptographic Message Syntax (CMS) format.

[Ballot discuss]
This is a DISCUSS-DISCUSS. Should we not make a recommendation about using the 2008 version for documents including CMS format expressions in the future?

[Ballot comment]
IMO, this should be PS *and* formally "Update" these other RFCs. See Stuart's discuss.

Section 6., paragraph 13:
>    --  Define each of the MAC-ALGOIRTHM objects to describe the

  Nit: s/MAC-ALGOIRTHM/MAC-ALGORITHM/


Section 2., paragraph 1:
>    Protocol designers can make use of the '08 ASN.1 contraints to define

  Nit: s/contraints/constraints/

[Ballot comment]
Please consider the comments from the Gen-ART Review by Kathleen
  Moriarty on 5-JAN-2011.  You can found the review at:
 
    http://www.softarmor.com/rai/temp-gen-art/
    draft-turner-additional-new-asn-06-moriarty.txt

[Ballot comment]
I support Stewart's Discuss.
Although the resultant long list of "updates" may be a nuisance to some, it is important for the person who plans to update one of the other RFCs to know that this update exists.

---

I am a bit confused why the document talks about RFCs using the old (1988) syntax, but only describes the updates from 2002 to 2008.

[Ballot comment]
I support Stewart's DISCUSS in regards to updating other RFCs, in particular RFC 5911, which defined earlier versions of new style ASN.1 modules.

I don't have much opinion regarding Informational versa PS, but I think PS would have been just fine.

Which tool was used to verify the new ASN.1?

[Ballot comment]
For Stuart and Alexey: I raised very similar questions during the processing of
. This document is
following the same pattern that document did.

[Ballot comment]
I support Stewart's DISCUSS in regards to updating other RFCs.

I have not much opinion regarding Informational versa PS, but I think PS would have been just fine.

[Ballot discuss]
This is a discuss discuss which I hope to clear on the call.

This document provided updated ASN.1 syntax for a number of standards track documents. I would like to discuss:

1) Should itself be a standards track document.
2) Whether this document should formally indicate that it updates those documents.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (Additional New ASN.1 Modules) to Proposed Standard


The IESG has received a request from an individual submitter to consider
the following document:
- 'Additional New ASN.1 Modules'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-01-18. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-turner-additional-new-asn/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-turner-additional-new-asn/

  (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? Tim Polk, sponsoring AD, is the document Shepherd for this document.  He has reviewed this version of the document and believes it is ready for forwarding to the IESG for publication.   (1.b) Has the document had adequate review both from key members of
        the interested community and others? Does the Document Shepherd
        have any concerns about the depth or breadth of the reviews that
        have been performed? The document has had adequate review by the authors and others.  The Document Shephard has no concerns about the depth or breadth of the reviews.   (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? The document has been reviewed by ASN.1 experts.  No other reviews seem to be called for.   (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 interested community has discussed those issues and has
        indicated that it still wishes to advance the document, detail
        those concerns here. No.   (1.e) How solid is the consensus of the interested community behind
        this document? Does it represent the strong concurrence of a few
        individuals, with others being silent, or does the interested
        community as a whole understand and agree with it? The document represents a simple update on documents that had various levels of 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 Ie D 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   (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]. No.   (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body of
        the document? 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 suggested a reasonable name for the new registry? See
        [I-D.narten-iana-considerations-rfc2434bis]. 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? Yes.   (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? Yes.   (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Writeup? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:      Technical Summary         The document updates existing ASN.1 modules from the 1988
        specification to the 2008 specification.  This involves the
        use of previously defined classes as well as defining some
        new classes.  Some modules are revised from RFC 5911 to deal
        with addition separation that has been found to be required
        through use of these modules.     Working Group Summary         This document is not a product of any IETF Working Group.
        The document was presented to the PKIX Working Group and
        no opposition to publication was registered.      Document Quality         Portions of the document have been used by one of the
        authors in an implementation for CMS.

[Note]: '  (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?

Tim Polk, sponsoring AD, is the document Shepherd for this document.  He has
reviewed this version of the document and believes it is ready for
forwarding to the IESG for publication.

  (1.b) Has the document had adequate review both from key members of
        the interested community and others? Does the Document Shepherd
        have any concerns about the depth or breadth of the reviews that
        have been performed?

The document has had adequate review by the authors and others.  The
Document Shephard has no concerns about the depth or breadth of the reviews.

  (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?

The document has been reviewed by ASN.1 experts.  No other reviews seem to
be called for.


  (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 interested community has discussed those issues and has
        indicated that it still wishes to advance the document, detail
        those concerns here.

No.


  (1.e) How solid is the consensus of the interested community behind
        this document? Does it represent the strong concurrence of a few
        individuals, with others being silent, or does the interested
        community as a whole understand and agree with it?

The document represents a simple update on documents that had various levels
of 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 Ie D 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

  (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].

No.


  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body of
        the document? 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 suggested a reasonable name for the new registry? See
        [I-D.narten-iana-considerations-rfc2434bis]. 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?

Yes.

  (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?

Yes.


  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Writeup? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

     Technical Summary

        The document updates existing ASN.1 modules from the 1988
        specification to the 2008 specification.  This involves the
        use of previously defined classes as well as defining some
        new classes.  Some modules are revised from RFC 5911 to deal
        with addition separation that has been found to be required
        through use of these modules.

    Working Group Summary

        This document is not a product of any IETF Working Group.
        The document was presented to the PKIX Working Group and
        no opposition to publication was registered.

     Document Quality

        Portions of the document have been used by one of the
        authors in an implementation for CMS. ' added by Tim Polk