IETF Logo Mail Archive

Re: [dhcwg] AD Evaluation: draft-ietf-dhc-dhcpv6-unknown-msg

Ted Lemon <ted.lemon@nominum.com> Sun, 02 February 2014 15:12 UTC

Return-Path: <Ted.Lemon@nominum.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C22DD1A00EB for <dhcwg@ietfa.amsl.com>; Sun, 2 Feb 2014 07:12:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KKRYM53jyh9a for <dhcwg@ietfa.amsl.com>; Sun, 2 Feb 2014 07:12:30 -0800 (PST)
Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 48F2C1A00D9 for <dhcwg@ietf.org>; Sun, 2 Feb 2014 07:12:30 -0800 (PST)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKUu5gWtbOCJKac67brW/ux1ENrwoFgjMC@postini.com; Sun, 02 Feb 2014 07:12:26 PST
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 044671B82FD for <dhcwg@ietf.org>; Sun, 2 Feb 2014 07:12:26 -0800 (PST)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id F0F96190052; Sun, 2 Feb 2014 07:12:25 -0800 (PST)
Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 2 Feb 2014 07:12:25 -0800
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ted Lemon <ted.lemon@nominum.com>
In-Reply-To: <52EE6D56.4090908@gmail.com>
Date: Sun, 02 Feb 2014 10:12:22 -0500
Content-Transfer-Encoding: quoted-printable
Message-ID: <094F910C-AEC2-48CF-8BDA-4A337978BE9A@nominum.com>
References: <52EBC3EA.1020104@innovationslab.net> <CFA19E62-0F9A-4358-AB7C-E4A910BF4874@nominum.com> <52EE6D56.4090908@gmail.com>
To: Tomek Mrugalski <tomasz.mrugalski@gmail.com>
X-Mailer: Apple Mail (2.1827)
X-Originating-IP: [192.168.1.10]
Cc: "dhcwg@ietf.org WG" <dhcwg@ietf.org>, Brian Haberman <brian@innovationslab.net>, draft-ietf-dhc-dhcpv6-unknown-msg@tools.ietf.org
Subject: Re: [dhcwg] AD Evaluation: draft-ietf-dhc-dhcpv6-unknown-msg
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 02 Feb 2014 15:12:31 -0000

On Feb 2, 2014, at 11:07 AM, Tomek Mrugalski <tomasz.mrugalski@gmail.com> wrote:
> I would extend the text a bit with "The server or client MAY log the
> fact.". Silently dropping a message that is typically network setup
> problem may hide problems and make their debugging harder.

The "silent" in "silently drop" conventionally means "drop without sending any response," not "drop without making any record that you dropped it."   Silently dropped messages are often either logged or recorded in statistics counters, and I'm pretty sure RFC 3315 recommends this practice and explains that that's what "silently drop" means.   Hm, actually no, neither 3315 nor 2131 explains, but they do use the term in this way.   I know I've seen it documented somewhere... :}

Anyway, it certainly could be clarified, but I don't think it's strictly necessary, given that it's not clarified in 3315.   Maybe you could just add it to the terminology section in 3315-bis?

v2.23.0 | Report a Bug | By Email