Re: AD evaluation: draft-ietf-6man-rfc1981bis-03

Bob Hinden <> Thu, 26 January 2017 20:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B2F71129B06; Thu, 26 Jan 2017 12:33:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id REK75iHPTrAz; Thu, 26 Jan 2017 12:33:18 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A43F5129AF9; Thu, 26 Jan 2017 12:33:18 -0800 (PST)
Received: by with SMTP id j13so46056979iod.3; Thu, 26 Jan 2017 12:33:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=NS2pOGdVxvLkB2EmXb2KEwt2Yk4YJnxOpoTD9Sxnzls=; b=gGN1IRsbI/N9bqhElDeLPNf1kJPAKuPPUJA5LBOcSovO43a5AT00wOrkHSjEulM7mp sMU4Hbh6wETwnEwFX+3Gjz9kgnGCM9EBIiPYS8g9xPF+2ox1ensFyFc6596E81J72LFP RabVdeVSWmAKC1QAEH1uNDtprPTQsoUqXN/HepbcaTs8EDAi59TWgeE/+0mDuxShAtp4 IvwdBNnL3CpjGxeMl0+KP9xS9TuXrcCtlX3lyWDZc5meLB2cjK9SeFMC4zmr35cSa5fu cQsDlEiXfeM2s5frMUiqtmFPtNmCeDvVemLCRQazMeFVblH4ucfjboFqob/lmq3pWIS5 ZBiQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=NS2pOGdVxvLkB2EmXb2KEwt2Yk4YJnxOpoTD9Sxnzls=; b=AP8ouLEw05TxUTLO2IblN7Me2TOnV57699ye9NUD6TF8ujN5DT1rT05aV/uyD+Zauh 9TNjj5sjviLU2QMtXmRdQuGizSiCtYCMhiS2/NNsOFiiAlbHWgpmsXxX9fwi6ziEI9pV dtLH8+KmWeik9DqQii9u4UPhH+7JUxNuMuZs9dIJiRXwQ9dhaoSzrXckQzXAhbdNo1YK 5ts0Dd7mL1dd+8noNEY6shno9dlwxG31Lb9Piv121hWD2M7rkwkvMEZTZv6UaWza1DO2 n/RsU4DXjTYsfwnDbTurNhEBPlPL3qmswj9kBO+xemRCyWWm01ndJ+lDw0/tU3d+PgSd PN+g==
X-Gm-Message-State: AIkVDXKUwayWInfscI68noCJioR4Ou3lEOx6DQOFPbbaAVt+H8Gn87RCQ9uFWa64qGHRBw==
X-Received: by with SMTP id u24mr4607581ioi.94.1485462797892; Thu, 26 Jan 2017 12:33:17 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id y126sm100199itf.14.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Jan 2017 12:33:16 -0800 (PST)
From: Bob Hinden <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_622A2676-33A2-4BAD-815E-B963E7FCC28C"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: AD evaluation: draft-ietf-6man-rfc1981bis-03
Date: Thu, 26 Jan 2017 12:33:14 -0800
In-Reply-To: <>
To: Suresh Krishnan <>
References: <>
X-Mailer: Apple Mail (2.3259)
Archived-At: <>
Cc: IPv6 List <>, Bob Hinden <>, "" <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 26 Jan 2017 20:33:21 -0000


Thanks for your evaluation.

> On Jan 25, 2017, at 7:59 PM, Suresh Krishnan <> wrote:
> Hi all,
>  I have gone through draft-ietf-6man-rfc1981bis-03 and I found it to be in good shape to progress. I just saw two minor issues that need to be addressed
> * Section 1
> I don’t think that his text that is copied over from RFC4821 is helpful. I think the earlier part of the paragraph is well written, useful and conveys exactly the right amount of context.
> “          In this algorithm, the
> 	   proper MTU is determined by starting with small packets and probing
> 	   with successively larger packets.  The bulk of the algorithm is
> 	   implemented above IP, in the transport layer (e.g., TCP) or other
> 	   "Packetization Protocol" that is responsible for determining packet
> 	   boundaries.”

I tend to agree and am happy to remove it.  I will note that there as a lot of debate on what this paragraph should say.  Unless someone objects, I will plan to remove it from the next version.

> * Section 3
> I am not sure why the following text is required. What are these nodes? I thought we discussed this and decided to not put in such text.
> "(regardless of whether it decrements the Hop Limit)"
> I would suggest removing the text or adding an example of such a node.

I went back and read the email thread:

The discussion does go back and forth, but ends with Ole closing the issue in the tracker:

   #13: Regardless of whether it decrements the Hop Limit

   Changes (by

     * status:  new => closed
     * resolution:   => wontfix

I interpert it to leave it in.  I don’t have a strong view on this, happy to remove it.  Any objections?

> Thanks
> Suresh
> P.S.: I agree with Donald’s comment in his INT Dir review that the “security classifications” paragraph seems dated but I would prefer for it to be removed rather than rewritten.

OK, I will remove it.