Re: [Int-area] Review of draft-ietf-intarea-provisioning-domains

"Eric Vyncke (evyncke)" <> Thu, 29 March 2018 06:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5C21012D7F9 for <>; Wed, 28 Mar 2018 23:59:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.799
X-Spam-Status: No, score=-6.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=neutral reason="invalid (public key: DNS error: SERVFAIL)"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id C4ZK9Xj-hrCe for <>; Wed, 28 Mar 2018 23:59:09 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 96770126D45 for <>; Wed, 28 Mar 2018 23:59:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=9320; q=dns/txt; s=iport; t=1522306749; x=1523516349; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=4qgZksCrMEdRPnPveJ+095VwiaeGBBtVzupOi6OH8u0=; b=Zt0XF3IAl0WHYnt6whVs8R2qguXDHhAOvJd9wvI/VfzgEQ6MEck9Yb2c FyZr3pnitw2tPxErtRvxRm46Tt5/VKOgCIdYN20Hm7Yj9UfecjU+0RyUJ RWWUO4mljayqtzUKpr618ceBBBGhNkpsSxO7fNGAB8DIWp7nor2S6EILy Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A/BAAujrxa/5JdJa1dGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYJNbwVhbygKg1KVAIFTIYEPjW2GXguFBAIag3ghOBQBAgE?= =?us-ascii?q?BAQEBAQJrKIUlAQEBBCNWEAIBCA4DAwECKAMCAgIwFAkIAgQOBRuED2SrRYI?= =?us-ascii?q?cH4Q2g22CKYdfgVQ/gQwiDIJWhQ8WgkowgiQClzMIAogZhg8CjC+PUQIREwG?= =?us-ascii?q?BJAEzIYFScBU6KgGCGJBNb40mgRcBAQ?=
X-IronPort-AV: E=Sophos; i="5.48,375,1517875200"; d="scan'208,217"; a="90998743"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Mar 2018 06:59:08 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id w2T6x80f025665 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 29 Mar 2018 06:59:08 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 29 Mar 2018 02:59:07 -0400
Received: from ([]) by ([]) with mapi id 15.00.1320.000; Thu, 29 Mar 2018 02:59:07 -0400
From: "Eric Vyncke (evyncke)" <>
To: Ted Lemon <>
CC: int-area <>
Thread-Topic: [Int-area] Review of draft-ietf-intarea-provisioning-domains
Thread-Index: AQHTw8ldBAmiLLRouk+9HHmG0XVohaPmIGEA///0XACAAR8gAA==
Date: Thu, 29 Mar 2018 06:59:07 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/f.1e.0.170107
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_256198762792434E9DC9DE218506599Cciscocom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Int-area] Review of draft-ietf-intarea-provisioning-domains
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF Internet Area Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 29 Mar 2018 06:59:13 -0000

We understand your point of view: the PvD option in the RA is more 'layer-3' while the JSON added information for application is obviously 'higher layers' => could be in two different documents indeed. We had a similar idea but OTOH the two concepts are so intertwined that this two-documents construction would be kind of artificial (and the JSON file over TLS adds some security to the concept).

We will extend the concept of this JSON (beyond the mandatory information in the current I-D) in other documents, probably in other WG



From: Ted Lemon <>
Date: Wednesday 28 March 2018 at 17:51
To: Eric Vyncke <>
Cc: int-area <>
Subject: Re: [Int-area] Review of draft-ietf-intarea-provisioning-domains

On Mar 28, 2018, at 10:53 AM, Eric Vyncke (evyncke) <<>> wrote:
While the authors will review your comments and come back to the list, I want to stress that the HTTPS/JSON is really at the core of our proposal in order to add network information to the application (notably for CAPPORT WG or other).

Yup, I get that.   I don't personally have a big interest in the JSON bit, but I'm not saying don't do it—I'm just saying it doesn't mix well.  The two are sufficiently conceptually dissimilar that trying to mix them into the same document is really muddying the water, and I think it's actually preventing you from making the document as clear as it should be.   If you consider them as separate, related problems rather than a single problem I think you will find that both pieces of this solution benefit.