RE: Last Call: <draft-ietf-6man-lineid-05.txt> (The Line Identification Destination Option) to Experimental RFC

RJ Atkinson <rja.lists@gmail.com> Wed, 13 June 2012 14:23 UTC

Return-Path: <rja.lists@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5E9121F85DA for <ipv6@ietfa.amsl.com>; Wed, 13 Jun 2012 07:23:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.599
X-Spam-Level:
X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_INVITATION=-2, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7mnYBKHBV7Q7 for <ipv6@ietfa.amsl.com>; Wed, 13 Jun 2012 07:23:12 -0700 (PDT)
Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) by ietfa.amsl.com (Postfix) with ESMTP id 1350721F853E for <ipv6@ietf.org>; Wed, 13 Jun 2012 07:23:09 -0700 (PDT)
Received: by qabj40 with SMTP id j40so1368705qab.15 for <ipv6@ietf.org>; Wed, 13 Jun 2012 07:23:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=eUwBeiccrAIgfNC8WPZvPrKWGeuTVtO9XhSUEhwCKfY=; b=fLmRmjTdCr1LL4/SMNTh9by/iXAeIP0df2Kh0Svtn7X3vjfMje0Lk0GDEbkBq4Bw2i gThYZZ0ltr7ZtY/m72Ck+84ZUotggYPrep3H/WOSrCkKptcdZ8hJIip4R8FuLBQ5qudK wIcxHEutpKt+9YSCmU0WaeBjxKLgS84VsWw8xZ4d5nFTgzOjaWF501W4fvym/wvnyrCk tY3v8GS9wtKfWTyMqh7G4WhrAt/+2MMeLu5VtK3Lwy+rL+rUv0cbMpfEBBzaXdSSQKNr 6rj+KxK54Ur6Pz7S/nvaYHkKEslMfLadllxb57pdeN/+4jVUNpeM1x6cko8BPwKqb3iX 3B8w==
Received: by 10.224.72.210 with SMTP id n18mr27166240qaj.10.1339597389526; Wed, 13 Jun 2012 07:23:09 -0700 (PDT)
Received: from [10.30.20.11] (pool-96-225-134-175.nrflva.fios.verizon.net. [96.225.134.175]) by mx.google.com with ESMTPS id e2sm9827875qap.15.2012.06.13.07.23.08 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 13 Jun 2012 07:23:08 -0700 (PDT)
From: RJ Atkinson <rja.lists@gmail.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Subject: RE: Last Call: <draft-ietf-6man-lineid-05.txt> (The Line Identification Destination Option) to Experimental RFC
Date: Wed, 13 Jun 2012 10:23:09 -0400
Message-Id: <22B5C3E9-47B8-46DD-8C14-0089DCC785C2@gmail.com>
To: ipv6@ietf.org
Mime-Version: 1.0 (Apple Message framework v1278)
X-Mailer: Apple Mail (2.1278)
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Jun 2012 14:23:15 -0000

On 13th June 2012, Mohamed Boucadair wrote, in part:
> 
> Having the warnings in the draft is good but having a pointer 
> to a document including a fair and detailed risk analysis is also 
> valuable and worth to be acknowledged.
> 
> Having that pointer is an "invitation" to people who will deploy 
> this mechanism (I know some of them who are planning to) to assess 
> the validity of the claimed threats (and also to consider the
> alternatives listed in Section 3 of draft-dec-*).  This is
> even encouraged given the intended track:  "experimental". 

(Aside:  s/intended track/intended status/ just above)

Agreed.  The requested addition of the informative reference
is not burdensome and seems entirely justified on technical
grounds.  Please add the informative reference as requested.

The IETF tries to provide full information in RFCs so that
network users/operators can make fully informed decisions
about whether to deploy or enable a particular IETF technology
in a particular network.  Adding this citation helps enable
such network users/operators to locate that additional
document which contains a more detailed discussion of the
operational risks.  In turn, this enables a more fully
informed decision about whether to deploy/enable the LineID
option -- and where/when it might not be appropriate for
a network to deploy/enable the LineID option.

I don't see any valid technical or procedural grounds 
to refuse to add an informative reference.  Please add it.

Yours,

Ran