IETF Logo Mail Archive

Re: [lisp] Mirja Kühlewind's Discuss on draft-ietf-lisp-rfc6833bis-13: (with DISCUSS and COMMENT)

Dino Farinacci <farinacci@gmail.com> Wed, 12 September 2018 22:04 UTC

Return-Path: <farinacci@gmail.com>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CADD130EC8; Wed, 12 Sep 2018 15:04:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIdiigiGNPj3; Wed, 12 Sep 2018 15:03:59 -0700 (PDT)
Received: from mail-pg1-x543.google.com (mail-pg1-x543.google.com [IPv6:2607:f8b0:4864:20::543]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C57F7130DFA; Wed, 12 Sep 2018 15:03:59 -0700 (PDT)
Received: by mail-pg1-x543.google.com with SMTP id l63-v6so1723781pga.7; Wed, 12 Sep 2018 15:03:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PI1nJRHNevTPlLcRL78x4qwd0wzC+A9VuiOAAhGmBH8=; b=jorxbxUaG0bHOYxlQjMfg0lCprZkTEQl2zk1wdqW9ZMpc5RLMDyxFG8CjLWklj3x5a OCIqtqSuBh8IKeNBBztsP8Woa7b5PFEh9Ce5sN+widMuuXBTpjgIvPpi4P6FYPLQB7JW scjzPFWKWo6dh/qGtyOerlgTvy1GDyCUxfwY/F53IQGe8XpR6x2fTdJTTmCl7MHHEkXK 4qjZd+4PP7RZm1YDB+SyZKnQ6pLWfVx0VwK3SdPxzgxmhvekyw/P9yC3is0KsFNTRGBh UypIgKhvXFkYo1nw01t0CzWNlUxChayUotOFSqc02ZDaXXqJgBXZ2Yx7186jWpNP78uL DWfA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PI1nJRHNevTPlLcRL78x4qwd0wzC+A9VuiOAAhGmBH8=; b=f6fuFB9UYNCVushqv+uhvxgVl1VcThqwYPPTGonkdvDN1V5C0hHjPCQi1Szy+XDCJA U+g626RfEOxtEH8uUkmGQ6luigR6E0D7a7wlOpEm/wwmkc6e52XG63tGJ3e+14LAt8g8 s212RBH127a4O5pKkB7hOkhYwgwRGrOFEPsZNnrTZrMJfFUKwUFM4DOZiyBN7kH4oSMo WVfYbH7kXCLOtTN/GXaD6d6PbWv/kaW9gXZ1cuVs1tdYQ/G8unSG8Mnx7JPoWRPdG/KZ o3Tkj57SWkNyM0YygCz69A7MnCTNlcrFmFeDT1eUMT1jsst6h9X6QQ/WxlRbHsx++iGM kUWQ==
X-Gm-Message-State: APzg51Cj/GTh30tYXMH6pFdKwtG5HbB3dn1Xrg2tK8iJr/FAJH3/6E18 Ul+3YH15/IU7E3KE9P19s6o=
X-Google-Smtp-Source: ANB0VdaPpYFkOOfp1k17Uwsvc6iWFNKX5VOmBe4Ecpn7plyRteQRJk+k2tJxXWt4uT6CjZQpbXa1MA==
X-Received: by 2002:a63:5055:: with SMTP id q21-v6mr4252075pgl.397.1536789839394; Wed, 12 Sep 2018 15:03:59 -0700 (PDT)
Received: from [172.31.99.184] (96-86-164-193-static.hfc.comcastbusiness.net. [96.86.164.193]) by smtp.gmail.com with ESMTPSA id o62-v6sm2915528pfb.0.2018.09.12.15.03.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Sep 2018 15:03:58 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <0F740BE5-63AF-4D18-BD79-D7D6A352B40A@kuehlewind.net>
Date: Wed, 12 Sep 2018 15:03:57 -0700
Cc: Luigi Iannone <ggx@gigix.net>, The IESG <iesg@ietf.org>, draft-ietf-lisp-rfc6833bis@ietf.org, lisp-chairs@ietf.org, "lisp@ietf.org list" <lisp@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <2A356E01-FD24-4F6E-9800-4718BCA907F8@gmail.com>
References: <153667812809.16741.10796738054406466412.idtracker@ietfa.amsl.com> <9D08CA59-8AC4-4866-944E-98553C37E547@gmail.com> <00DCC7FC-096E-4822-A702-2EE4C70327EB@gigix.net> <0F740BE5-63AF-4D18-BD79-D7D6A352B40A@kuehlewind.net>
To: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/CXNVIjIR6FA-_U001MW9x19UBl0>
Subject: Re: [lisp] Mirja Kühlewind's Discuss on draft-ietf-lisp-rfc6833bis-13: (with DISCUSS and COMMENT)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Sep 2018 22:04:03 -0000

Hi Luigi,
> 
> please see below.
> 
>> Am 12.09.2018 um 09:30 schrieb Luigi Iannone <ggx@gigix.net>:
>> 
>> Hi,
>> 
>> two quick comments inline.
>> 
>> 
>>> On 11 Sep 2018, at 20:13, Dino Farinacci <farinacci@gmail.com> wrote:
>>> 
>>>> 3) Given the following statement:
>>>> "Note that while this document assumes a LISP-ALT database mapping
>>>> infrastructure to illustrate certain aspects of Map-Server and Map-
>>>> Resolver operation..."
>>>> it seems that RFC6836 should be a normative reference, as it might not be
>>>> possible to understand all details explained in this doc with knowing ALT.
>>> 
>>> I would like the lisp-chairs and/or Deborah to comment on this.
>>> 
>> 
>> IMO We can completely delete that sentence. The documents does a pretty good job to talk in general terms about the mapping system and the use of its front-end Map-Servers/Map-Resolvers.
>> 
>> In the few cases where something specific to ALT and DDT can be said the document actually does it.
> 
> Actually I brought this up because there were more cases where I found that ALT knowledge is needed. If you don’t want this to be a normative reference and remove the sentence above (which I’m not sure is helpful), please also double-check all other occurrences of ALT and make sure the discussed case is also understandable without ALT knowledge.

I think it should left in and we should add LISP-DDT to the paragraph. Since the two mapping transport systems that have moved forward to RFC are ALT and DDT. And I believe they should both be Normative References.

> 
>> 
>> 
>> 
>>>> 4) Further I would also think that I-D.ietf-lisp-mn and I-D.ietf-lisp-pubsub
>>>> should be normative references as the meaning of the respective bits it not
>>>> further specified in this doc. Or can these bits just be ignored if
>>>> I-D.ietf-lisp-mn and I-D.ietf-lisp-pubsub are not implemented? If so that
>>>> should be stated.
>>> 
>>> I would like the lisp-chairs and/or Deborah to comment on this.
>>> 
>> 
>> Those bits can be ignored if an implementer choses not to support those mechanisms.
>> Hence, the documents do not really need to be normative.
> 
> Okay, that these bits can be ignored should be stated in the doc!

I will add text for this.

Dino

> 
> Mirja
> 
> 
> 
>> 
>> Ciao
>> 
>> L.
>> 
>> 
>

v2.23.0 | Report a Bug | By Email