Re: [v6ops] Document Action: 'Recommended Simple SecurityCapabilities in Customer Premises Equipment for ProvidingResidential IPv6 Internet Service' to Informational RFC

Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org> Sat, 23 October 2010 15:24 UTC

Return-Path: <ipng@69706e6720323030352d30312d31340a.nosense.org>
X-Original-To: v6ops@core3.amsl.com
Delivered-To: v6ops@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9B8E3A682F for <v6ops@core3.amsl.com>; Sat, 23 Oct 2010 08:24:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.155
X-Spam-Level:
X-Spam-Status: No, score=-1.155 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_13=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EOHAQL8Hcezv for <v6ops@core3.amsl.com>; Sat, 23 Oct 2010 08:24:20 -0700 (PDT)
Received: from smtp1.adam.net.au (smtp1.adam.net.au [202.136.110.253]) by core3.amsl.com (Postfix) with ESMTP id DBD993A67DF for <v6ops@ietf.org>; Sat, 23 Oct 2010 08:24:19 -0700 (PDT)
Received: from 182-239-171-173.ip.adam.com.au ([182.239.171.173] helo=opy.nosense.org) by smtp1.adam.net.au with esmtp (Exim 4.63) (envelope-from <ipng@69706e6720323030352d30312d31340a.nosense.org>) id 1P9fyj-0002bA-9g; Sun, 24 Oct 2010 01:55:53 +1030
Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 743E13B32F; Sun, 24 Oct 2010 01:55:52 +1030 (CST)
Date: Sun, 24 Oct 2010 01:55:52 +1030
From: Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org>
To: "Bernie Volz (volz)" <volz@cisco.com>
Message-ID: <20101024015552.5b831c55@opy.nosense.org>
In-Reply-To: <D9B5773329187548A0189ED65036678904932107@XMB-RCD-101.cisco.com>
References: <20101022135409.11E1328C0E8@core3.amsl.com> <20101023034107.2e049007@opy.nosense.org> <804E93BB-B90E-427B-8A83-98E1D36DDC3F@cisco.com> <D9B5773329187548A0189ED65036678904932107@XMB-RCD-101.cisco.com>
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; x86_64-unknown-linux-gnu)
X-Location: Lower Mitcham, South Australia, 5062
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Cc: v6ops mailing list <v6ops@ietf.org>
Subject: Re: [v6ops] Document Action: 'Recommended Simple SecurityCapabilities in Customer Premises Equipment for ProvidingResidential IPv6 Internet Service' to Informational RFC
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 23 Oct 2010 15:24:22 -0000

On Fri, 22 Oct 2010 14:38:23 -0500
"Bernie Volz (volz)" <volz@cisco.com> wrote:

> Just so the record is correct, technically they only got to 76:
> 
> http://www.ietf.org/id/draft-hixie-thewebsocketprotocol-77.txt:
> 
> ---
> This Internet-Draft, draft-hixie-thewebsocketprotocol-76.txt, has been
> replaced by another
> document, draft-ietf-hybi-thewebsocketprotocol-01.txt, and has been
> deleted from the 
> Internet-Drafts directory.
> 
> Internet-Drafts are not archival documents, and copies of
> Internet-Drafts
> that have been deleted from the directory are not available.  The
> Secretariat does not have any information regarding the future plans of
> the author(s) or working group, if applicable, with respect to this
> deleted Internet-Draft.  For more information, or to request a copy of
> the document, please contact the author(s) directly. 
> 
> Draft Author(s):
> 
>  I. Hickson <ian@hixie.ch>
> ---
> 
> Kind of sad they didn't keep going, but 76 is a going to be a tough
> record to beat -- I would have long given up?
> 

I've read in Radia Perlman's book that one of the ATM AAL standards was
published unimplementable, just so that they could cross off the
"published standard" check box. The IETF is obviously far more
pragmatic than that, however it'd be possibly useful to have a status
of "unRFC", to capture a historical representation of the effort people
put into it even if it didn't eventuate as an RFC :-) I think there is
quite commonly just as much value in knowing about what doesn't
work as there is in knowing what does.

Regards,
Mark.


> - Bernie
> 
> -----Original Message-----
> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
> Of Ralph Droms (rdroms)
> Sent: Friday, October 22, 2010 3:28 PM
> To: Mark Smith
> Cc: v6ops mailing list
> Subject: Re: [v6ops] Document Action: 'Recommended Simple
> SecurityCapabilities in Customer Premises Equipment for
> ProvidingResidential IPv6 Internet Service' to Informational RFC
> 
> With a little research - regrettably, we didn't record the actual rev
> number in RFC 3315 - the highest numbered rev of the DHCPv6 spec I could
> find was draft-ietf-dhc-dhcpv6-28.
> 
> From the Acknowledgments in RFC 3315:
> 
>    And, thanks to Steve Deering for pointing out at IETF 51 in London
>    that the DHCPv6 specification has the highest revision number of any
>    Internet Draft.
> 
> In any event, that record has been significantly exceeded by more recent
> drafts: draft-hixie-thewebsocketprotocol-77.txt 
> 
> - Ralph
> 
> On Oct 22, 2010, at 1:11 PM 10/22/10, Mark Smith wrote:
> 
> > On Fri, 22 Oct 2010 06:54:09 -0700 (PDT)
> > The IESG <iesg-secretary@ietf.org> wrote:
> > 
> >> The IESG has approved the following document:
> >> 
> >> - 'Recommended Simple Security Capabilities in Customer Premises 
> >>   Equipment for Providing Residential IPv6 Internet Service '
> >>   <draft-ietf-v6ops-cpe-simple-security-16.txt> as an Informational
> RFC
> >> 
> > 
> > Well done everybody, especially James. I think I've read somewhere
> that
> > the DHCPv6 spec had set a record at 15 revisions ... it's just been
> > beaten :-)
> > 
> >> 
> >> This document is the product of the IPv6 Operations Working Group. 
> >> 
> >> The IESG contact persons are Ron Bonica and Dan Romascanu.
> >> 
> >> A URL of this Internet-Draft is:
> >>
> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-cpe-simple-security
> -16.txt
> >> 
> >> Technical Summary
> >> 
> >> This document identifies a set of recommendations for the makers of
> >> devices describing how to provide for "simple security" capabilities
> >> at the perimeter of local-area IPv6 networks in Internet-enabled
> >> homes and small offices.
> >> 
> >> Working Group Summary
> >> 
> >> The working group was divided on the concept of defining or
> recommending
> >> the use of firewalls; as a result, this document is very explicitly a
> set
> >> of recommendations for those that would choose to build or deploy a
> >> firewall without making any recommendation on whether anyone should
> do
> >> either. It describes a simple stateful firewall, permeable to traffic
> that
> >> is secured using IPsec.
> >> 
> >> Document Quality
> >> 
> >> There is at least one deployed implementation of this firewall, and
> >> expected to be others. The document clearly specifies a consensus set
> of
> >> recommendations for such firewalls.
> >> 
> >> Personel
> >> 
> >> Fred Baker is shepherd.
> >> 
> >> RFC Editor Note
> >> 
> >> OLD TEXT:
> >> 
> >> REC-13: 
> >> 
> >> By DEFAULT, Internet gateways SHOULD, automatically download
> >> and install software updates for extending IPv6 simple security for
> >> support of future standard upper layer transports and extension
> >> headers.
> >> 
> >> NEW TEXT:
> >> 
> >> REC-13:
> >> Residential Internet Gateways SHOULD provide a convenient means to 
> >> securely update their firmware, for the installation of security 
> >> patches and other manufacturer-recommended changes.
> >> 
> >> Vendors can expect users and operators to have differing viewpoints 
> >> on the maintenance of patches, with some preferring automated update 
> >> and some preferring manual initiation, and those preferring automated
> 
> >> update wanting to download from a vendor site or one managed by the 
> >> network operator. To handle the disparity, vendors are well advised 
> >> if they provide manual and automated options. In the automated case, 
> >> they would do well to facilitate pre-configuration of the download 
> >> URL and a means of validating the software image such as a
> certificate.
> >> 
> >> _______________________________________________
> >> v6ops mailing list
> >> v6ops@ietf.org
> >> https://www.ietf.org/mailman/listinfo/v6ops
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://www.ietf.org/mailman/listinfo/v6ops
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops