Subject: BCP 111, RFC 4841 on RFC 4181 Update to Recognize the IETF Trust

From: [email-masked]
Date: Tue, 27 Mar 2007 13:21:57 -0700

A new Request for Comments is now available in online RFC libraries.

        BCP 111        
        RFC 4841

        Title:      RFC 4181 Update to Recognize 
                    the IETF Trust 
        Author:     C. Heard, Ed.
        Status:     Best Current Practice
        Date:       March 2007
        Mailbox:    [email-masked]
        Pages:      3
        Characters: 4414
        Updates:    4841
        SeeAlso:    BCP 111 

        I-D Tag:    draft-heard-rfc4181-update-00.txt

        URL:        http://www.rfc-editor.org/rfc/rfc4841.txt

This document updates RFC 4181, "Guidelines for Authors and Reviewers
of MIB Documents", to recognize the creation of the IETF Trust.  This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements.

This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements.  Distribution of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
ddress in either the outermost or
   innermost IP header and MAY provide a configuration option
   for specifying which is to be checked.  If there is no
   configuration option provided, an implementation SHOULD
   check the peer source address contained in the outermost
   header (as is the practice of most of today's implementations).

  In section 5.1.3.12, please make the following change:

  OLD:

   A summary of the logic flow for peer certificate validation regarding
   the EKU extension follows:

  NEW:

   Conforming IKE implementations are not required to support EKU.
   If a critical EKU extension appears in a certificate and EKU is
   not supported by the implementation, then RFC 3280 requires that
   the certificate be rejected.  Implementations that do support EKU
   MUST support the following logic for certificate validation:

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf-announce