[secdir] Secdir review of draft-ietf-geopriv-uncertainty-03

"Takeshi Takahashi" <takeshi_takahashi@nict.go.jp> Tue, 07 October 2014 09:21 UTC

Return-Path: <takeshi_takahashi@nict.go.jp>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 762BD1A9248; Tue, 7 Oct 2014 02:21:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.721
X-Spam-Level: *
X-Spam-Status: No, score=1.721 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id YuAyl3p4B35e; Tue, 7 Oct 2014 02:21:24 -0700 (PDT)
Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:df0:232:300::1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62E701A924C; Tue, 7 Oct 2014 02:21:24 -0700 (PDT)
Received: from gw1.nict.go.jp (gw1 []) by ns1.nict.go.jp with ESMTP id s979LM2R029079; Tue, 7 Oct 2014 18:21:22 +0900 (JST)
Received: from mail2.nict.go.jp (mail.nict.go.jp []) by gw1.nict.go.jp with ESMTP id s979LMKs026118; Tue, 7 Oct 2014 18:21:22 +0900 (JST)
Received: from mail2.nict.go.jp (localhost []) by mail2.nict.go.jp (NICT Mail) with ESMTP id 14C722C711; Tue, 7 Oct 2014 18:21:22 +0900 (JST)
Received: from VAIO (unknown []) by mail2.nict.go.jp (NICT Mail) with ESMTP id 0EDCF2C5BC; Tue, 7 Oct 2014 18:21:22 +0900 (JST)
From: Takeshi Takahashi <takeshi_takahashi@nict.go.jp>
To: "'draft-ietf-geopriv-uncertainty.all@tools.ietf.org.'"@mail2.nict.go.jp
Date: Tue, 07 Oct 2014 18:21:22 +0900
Message-ID: <0e2501cfe210$0f819b60$2e84d220$@nict.go.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac/iD+W9l87FhA1UR4mY7+AHxiqI6A==
Content-Language: ja
X-Virus-Scanned: clamav-milter 0.97.8 at zenith1
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/hPncrX1OfYtOhvOwyoFZyAVRVps
Cc: geopriv-chairs@tools.ietf.org, iesg@ietf.org, secdir@ietf.org
Subject: [secdir] Secdir review of draft-ietf-geopriv-uncertainty-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Oct 2014 09:21:26 -0000


I have reviewed current version of this document as part of the security
directorate's ongoing effort to review all IETF documents being processed by
the IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat these
comments just like any other last call comments.

This draft provides lots of information on how to handle uncertainty and
It also defines a schema for describing confidence information.

I believe this document is very helpful for readers.
It outlines assorted techniques in a very clear way.

I think this draft is almost ready, but I have clarification questions as

1. standards track (std), or informational?

I am not sure what would be the criteria for being a std RFC, but I feel
like that this draft talks as if it is an informational draft.
I do not mean that I object to make it as a std rfc, but clarification is

A std RFC specifies the interfaces that communication parties need to
follow, IMHO.
The RFC 3863 and 5139 is std RFCs since they define data format/schema each
communication party needs to follow.
The RFC 3693, which this draft is updating, is an informational RFC and
provides lots of useful knowledge, but it does not force anything to
communication parties.
How is the case of this draft?

I know that the draft specifies a schema for the confidence information, but
I feel like this is rather smaller part of the issues discussed in this
It talks about schemes to handle uncertainty, but it does not define a
single scheme to handle uncertainty. (It outlines several techniques, but
implementers need to consider which techniques to use, and they can
implement different techniques, IMHO.)

To sum up, I would appreciate if you could clarify why the draft is in the
std rfc.

2. why this document is not split into two documents?

This is related to the issue 1.

Here are my understanding of the sections.
Section 7 defines the confidence schema.
I understood that this document normatively defines this schema and
implementers need to follow this schema.
On the other hand, sections 2 - 5 provides helpful information, but the
draft does not mandate implementers to do anything.
I have understood that implementers can use arbitrary techniques (including
the techniques introduced in this document) to handle uncertainty.

I wonder whether it would have been easier to have separate drafts for the
issues; i.e., the content described in section 7 goes to std RFC while the
rest goes to another informational rfc.

3. content in sections 2-5

Thank you for your elaboration.
This is very helpful to get knowledge on the uncertainty manipulation.

If this document goes to a std RFC, I would expect to see sentences such as
"SHOULD/MUST/is recommended to use the techniques to handle uncertainty", in
these sections.

4. security considerations

If the confidence information is maliciously altered, does it cause trouble
to the information receiver?
(I think the RFC 4119 (and RFC 3694) does not address the need to protect
confidence information.)

Information sender sents a location information with high confidence value,
but the information receiver received the information with falsified low
confidence value.
I guess this could hinder some decision making of the information receiver
in some case.

So, I think it would be safer to say something like that we should implement
schemes to protect the values that is defined outside the scope of this
draft, etc.

Kind regards,

Takeshi Takahashi, Ph.D.,
Senior Researcher at the National Institute of Information and
Communications Technology, Japan