Re: [tcpm] Last Call: draft-ietf-tcpm-tcpsecure (Improving TCP'sRobustness to Blind In-Window Attacks) to Proposed Standard

"Tom Petch" <nwnetworks@dial.pipex.com> Mon, 18 May 2009 06:08 UTC

Return-Path: <nwnetworks@dial.pipex.com>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C97743A6F5F for <tcpm@core3.amsl.com>; Sun, 17 May 2009 23:08:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.96
X-Spam-Level:
X-Spam-Status: No, score=0.96 tagged_above=-999 required=5 tests=[AWL=1.145, BAYES_40=-0.185]
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 19vLD-oZ0mv1 for <tcpm@core3.amsl.com>; Sun, 17 May 2009 23:08:20 -0700 (PDT)
Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by core3.amsl.com (Postfix) with ESMTP id BE04F3A6F6B for <tcpm@ietf.org>; Sun, 17 May 2009 23:08:19 -0700 (PDT)
X-Trace: 104039141/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.17.136/None/nwnetworks@dial.pipex.com
X-SBRS: None
X-RemoteIP: 62.188.17.136
X-IP-MAIL-FROM: nwnetworks@dial.pipex.com
X-SMTP-AUTH:
X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106
X-IP-BHB: Once
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApwEANOYEEo+vBGI/2dsb2JhbACDKItGwAIHg3oF
X-IronPort-AV: E=Sophos;i="4.41,208,1241391600"; d="scan'208";a="104039141"
X-IP-Direction: IN
Received: from 1cust136.tnt1.lnd3.gbr.da.uu.net (HELO allison) ([62.188.17.136]) by smtp.pipex.tiscali.co.uk with SMTP; 18 May 2009 07:09:51 +0100
Message-ID: <005201c9d776$c88bfce0$0601a8c0@allison>
From: Tom Petch <nwnetworks@dial.pipex.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
References: <20090402150706.EC83D28C222@core3.amsl.com> <49E3ADA4.1090402@gont.com.ar> <0C53DCFB700D144284A584F54711EC58070763E3@xmb-sjc-21c.amer.cisco.com><be6497400904162214lbc16cf1oda737cb91ae88bf7@mail.gmail.com> <49E8EE86.3010600@gmail.com>
Date: Mon, 18 May 2009 07:02:39 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Cc: tcpm@ietf.org
Subject: Re: [tcpm] Last Call: draft-ietf-tcpm-tcpsecure (Improving TCP'sRobustness to Blind In-Window Attacks) to Proposed Standard
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Tom Petch <nwnetworks@dial.pipex.com>
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 May 2009 06:08:21 -0000

----- Original Message -----
From: "Brian E Carpenter" <brian.e.carpenter@gmail.com>
To: "Fernando Gont" <fernando@gont.com.ar>
Cc: <tcpm@ietf.org>; "Anantha Ramaiah (ananth)" <ananth@cisco.com>;
<ietf@ietf.org>
Sent: Friday, April 17, 2009 11:03 PM
Subject: Re: [tcpm] Last Call: draft-ietf-tcpm-tcpsecure (Improving
TCP'sRobustness to Blind In-Window Attacks) to Proposed Standard


> On 2009-04-17 17:14, Fernando Gont wrote:
> > On Mon, Apr 13, 2009 at 10:23 PM, Anantha Ramaiah (ananth)
> > <ananth@cisco.com> wrote:
> >
> >>> * The document never mentions the fact that this document is
> >>> IPR-encumbered.
> ...
> > I personally believe this should be noted in all RFCs on which there's
> > a known IPR. However, Joel Halpern mentioned this is not current
> > practice. If that's the case, I'd have no problem with leaving it "as
> > is". (FWIW, if you look at our tcp-security document, we do recommend
> > the implementation of the counter-measures you propose, but just note
> > that there's an IPR, and that implementers should research how this
> > would affect them).
>
> Personal belief doesn't come into it. It's strictly defined in a BCP.
> RFC3979 tells us the rules about this. Basically, the RFC Editor will
> do what is required:
>
> "4.  Actions for Documents for which IPR Disclosure(s) Have Been Received
>
>    (A) When any Intellectual Property Right is disclosed before
>        publication as an  RFC, with respect to any technology or
>        specification, described in a Contribution in the manner set
>        forth in Section 6 of this document, the RFC Editor shall ensure
>        that the document include a note indicating the existence of such
>        claimed Intellectual Property Rights in any RFC published from
>        the Contribution.  (See Section 5 below.)"
>
> [Section 5 defines the exact text to be included in such RFCs.
> I believe you can use <?rfc iprnotified="yes"?> in xml2rfc.]

This is what I thought but ....

RFC5425 has recently been published and I can find no mention of IPR claims in
it.  The IESG Protocol Action
Message-Id: <20081008150846.3A3B03A6BDE@core3.amsl.com>
calls out the fact that claims were made, in fact repeatedly so, against each
successive version of the I-D.  So why nothing in the RFC?  What am I missing?

Tom Petch


> "11.  No IPR Disclosures in IETF Documents
>
>    IETF and RFC Editor Documents must not contain any mention of
>    specific IPR.  All specific IPR disclosures must be submitted as
>    described in Section 6.  Specific IPR disclosures must not be in the
>    affected IETF and RFC Editor Documents because the reader could be
>    misled.  The inclusion of a particular IPR disclosure in a document
>    could be interpreted to mean that the IETF, IESG, or RFC Editor has
>    formed an opinion on the validity, enforceability, or applicability
>    of the IPR.  The reader could also be misled to think that the
>    included IPR disclosures are the only IPR disclosures the IETF has
>    received concerning the IETF document.  Readers should always refer
>    to the on-line web page to get a full list of IPR disclosures
>    received by the IETF concerning any Contribution.
>    (http://www.ietf.org/ipr/)"
>
>       Brian
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf