Re: 'monotonic increasing'

Joe Touch <touch@ISI.EDU> Sat, 18 February 2006 18:56 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAXFt-00006Z-Eq; Sat, 18 Feb 2006 13:56:29 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAXFr-00006P-Rc for ietf@ietf.org; Sat, 18 Feb 2006 13:56:27 -0500
Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAXFr-0005YU-DT for ietf@ietf.org; Sat, 18 Feb 2006 13:56:27 -0500
Received: from [128.9.176.73] ([128.9.176.73]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k1IItLq25543; Sat, 18 Feb 2006 10:55:21 -0800 (PST)
Message-ID: <43F76D94.1010404@isi.edu>
Date: Sat, 18 Feb 2006 10:55:16 -0800
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: "Tom.Petch" <sisyphus@dial.pipex.com>
References: <200601301716.JAA16888@gra.isi.edu> <002501c628af$62188600$0601a8c0@pc6> <014601c633dd$82948bc0$0601a8c0@pc6>
In-Reply-To: <014601c633dd$82948bc0$0601a8c0@pc6>
X-Enigmail-Version: 0.94.0.0
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b
Cc: ietf <ietf@ietf.org>
Subject: Re: 'monotonic increasing'
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2142339255=="
Errors-To: ietf-bounces@ietf.org


Tom.Petch wrote:
> The phrase 'monotonic increasing' seems to be a Humpty-Dumpty one, used with a
> different sense within RFC to that which I see defined elsewhere; and this
> could lead to a reduction in security.
> 
> Elsewhere - dictionaries, encyclopaedia, text books -  I see it
> defined so that when applied to a sequence of numbers, then each number is not
> less than its predecessor, so that
> 1 1 1 1 1 1 1 1 1 1
> 1 1 2 3 5 8 13
> 1 2.71828 3.14159 4.18 42
> are all monotonic increasing sequences whereas
> 1 2 3 4 5 6 7 9 8 10
> is not.

There are two variants:

	monotonic increasing
		sequence where (i+1)>=(i)
		which applies to all of the above

		in math, monotonic always includes equality

	strictly monotonic increasing
		sequence where (i+1)>(i)
		which applies to all except the first two examples

		this is also known as "non decreasing", as Ken noted

a constant sequence is one which is both monotonic increasing and
monotonic decreasing.

> Within RFC, mostly those related to security or network management, the context
> of its use implies, in addition, one or more of
> a) each number in the sequence is different (as in number used once)
> b) each number is an integer
> c) each number is one greater than its predecessor (as in message sequencing) .

RFCs tend to describe integer sequences (vs. real or other kinds of
numbers). Most of the uses I'm familiar with for sequence numbers in
RFCs don't care if numbers are skipped, so I'm not sure this definition
is typical. (can you give an example if not?)

The above is an arithmetic integer sequence (constant delta between
terms) that is strictly monotonic increasing and maximally compact.
Informally, this might be referred to as a "sequential", but
mathematically a sequence is just an ordered list of numbers.

If (c) is changed to omit "one", this defines is monotonic increasing
integer sequence.

If (c) is changed to "at least one", this defines a strictly monotonic
integer sequence.

> Most likely, an implementation that conforms to the rest of the world definition
> would interwork with one that conforms to the RFC one, but with some loss of
> security, since numbers that are intended to be used only once could be reused.
> 
> Q1) Can anyone point me to an authoritative source that endorses the RFC usage?
> 
> Q2) Even so, since the  rest of the world usage seems to be so widely defined,
> should we change our terminology, eg specifying seqences to be strictly
> increasing when that is what is needed?

I would agree with Q2.

Joe

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf