Re: [OSPF] OSPF WG Minutes from IETF 95

Paul Jakma <> Wed, 13 April 2016 20:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 67A1312D88D for <>; Wed, 13 Apr 2016 13:14:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 xaFN0M86GCgq for <>; Wed, 13 Apr 2016 13:14:26 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6F87012D787 for <>; Wed, 13 Apr 2016 13:14:26 -0700 (PDT)
Received: by with SMTP id u206so96322795wme.1 for <>; Wed, 13 Apr 2016 13:14:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=nszOLKTtz0pQgSAa/mWwW52c2W4xGTz1QelBKz19oWo=; b=s2bXJnCK/TjIvD/tV/7StumdbUa8CU05PDSwnDQXvBh3q2LL3kUj7miaQ+81Nm2Rb0 GA/+UxsPl2F5amxS4OmXkt/pOxUdWT0b0wKGh+HJkhJrN7jSzIlPPDJFZTLKiK9KUx+y iXR/jcj35NjbG7mafWRxntueomefm/CwgSPD5GZ9ZrP4cqsLlm1ANyBEVZ7x26OsuOmz mrfEViOYSUEP8IUAiETJNfdK0j7DUgPqwOtMK3z8/eVXoopggYPEguVt7DIAZ1V3B8fN M7YsBuMTlIe4y2gJdoAXTXDaS0NpUWHeNCe4PH0fKTO/vn3noCP5lDFGxv2pIVxTRb24 6cbQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=nszOLKTtz0pQgSAa/mWwW52c2W4xGTz1QelBKz19oWo=; b=d7yq1jZMunlLLG3s+HrRE6sM1fnR4VM5ByYdAzesZYeR3to+bVIdYuk4MqYgkRDWJu bCOYMGO6rJObMtIFJh2+y53ZwlMAuM0Y7wE31dLmTVtfmuFKoVKlzBE/K7yzfSgrb2WV XrkmbD2OOziGtQ9ey2jqi0LTEUtrreuWnUG8badWNEj02orDnsksb7SiVGMSLtkkxoVa 5xwQoNkuhtGP1qTIZRi0tolMXHjMigLJ5u1DGMkYodXaoFtFgPVftmxsb13bONAv2zHY 9DKT2pevsEsJTntVwiPbkaypqAb9qyms/eLoV0xAYHq+1S7pygeXimCnCsIxgm9y9lUD g4ow==
X-Gm-Message-State: AOPr4FXZDTi/A67ZMyqPye/diLYKvB+LFE5b+kiwk4sfkna1rQ4Mel0FuD9ImfDtoA5zdQ==
X-Received: by with SMTP id y20mr12353649wmh.68.1460578464777; Wed, 13 Apr 2016 13:14:24 -0700 (PDT)
Received: from ( []) by with ESMTPSA id g78sm29829301wme.21.2016. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Apr 2016 13:14:23 -0700 (PDT)
Date: Wed, 13 Apr 2016 21:14:21 +0100 (BST)
From: Paul Jakma <>
To: "Acee Lindem (acee)" <>
In-Reply-To: <>
Message-ID: <>
References: <> <> <> <> <>
User-Agent: Alpine 2.20 (LFD 67 2015-01-07)
X-Snooper: A life spent reading others private email is a sad and wasted one
X-NSA: nitrate toxic DNDO hostage al aqsar fluffy jihad DHS cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt mustard gas x-ray british airways hydrogen washington peroxide cool FEMA emergency four lions encryption ricin table pandemic scanner power sleet catalyst injection acetone
X-KEYSCORE: The greatest long-term threats to freedom and democracy are based in Langley and Fort Meade and Cheltenham
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="-1471075816-367225847-1460578463=:13056"
Archived-At: <>
Cc: OSPF WG List <>
Subject: Re: [OSPF] OSPF WG Minutes from IETF 95
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 13 Apr 2016 20:14:28 -0000

On Wed, 13 Apr 2016, Acee Lindem (acee) wrote:

> Are you familiar with the requirements language? While the use of 
> “should not” is unfortunate, it is not normative. To be normative it 
> would need to be “SHOULD NOT”.

Capitals are not required. If one is used to RFC2328, one would not 
expect normative language to be shouty.

> Furthermore, RFC 6987 is informational as opposed to standards track.
> Finally, the document goes on to precisely state the behavior (refer 
> to the last paragraph of section 4).

> I believe the above is clear.

Sure, 4 reads the other way but "deployment considerations" . I'm not 
saying how it must be read, just saying it is possible to read the 
stronger language of 3 another way.

I'm not trying to argue, I'm trying to explain why we are here.

>> For the RFC6987 desired behaviour, any high metric other than 0xffff
>> will universally work.
> You have misinterpreted it.

I may have misinterpreted RFC6987, sure.

However, it is a fact that the behaviour desired by RFC6987 can be 
universally achieved with metrics of 0xfffe or lower. That was true 
before any misinterpretation, and is still true now.

0xffff today will not universally be recognised as meaning "you can 
still calculate transit paths out of a router using that link". 0xfffe 
or below will.

That is the reality today.

Paul Jakma	@pjakma	Key ID: 64A2FF6A
Even a blind pig stumbles upon a few acorns.