Re: 6MAN WG Adoption call : draft-jeong-6man-rdnss-rfc6106-bis

"Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com> Wed, 07 October 2015 00:32 UTC

Return-Path: <jaehoon.paul@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52DF41B2F82 for <ipv6@ietfa.amsl.com>; Tue, 6 Oct 2015 17:32:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level:
X-Spam-Status: No, score=-1.699 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, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
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 opaFtEZ7nYx6 for <ipv6@ietfa.amsl.com>; Tue, 6 Oct 2015 17:32:55 -0700 (PDT)
Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) (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 B24BB1B2F61 for <ipv6@ietf.org>; Tue, 6 Oct 2015 17:32:54 -0700 (PDT)
Received: by ykft14 with SMTP id t14so2103919ykf.0 for <ipv6@ietf.org>; Tue, 06 Oct 2015 17:32:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ACNupX018nwNBLMV2TpB8LcBQftxOk1vhTe9Qz4ClrY=; b=XWOEM9NtReNvcD4q7U9e5nOfDsDROd7beIkRNqxqiAZKDE+L/hntC7gvzSRnSq4zZD t9MXYea1NFxUFDnorZcvEMqNigsk/08mCSDnl78gVdbyZkCjmFbs+uCWXEfRhw5Il+Lx mXd+SkEwyHDl/EyD0H7lISGICR9FcCxcbdSMqHxBlnvHpfrg9wgbL1gJ36NLs/rl3PmP mXsgeUsa78+msN3LXxQ/TwVV03jLCyGtNaYvo96fQkkOHrhTHYrVH81VjEFopByhgxEM TZkbAHyaQaSu3NWFvlpz/REdKL33PoPV4MtZSel6zE4wf3my/LOT6O/t4UzR4Hyo3RZl 1o6w==
MIME-Version: 1.0
X-Received: by 10.13.229.193 with SMTP id o184mr4377872ywe.232.1444177973912; Tue, 06 Oct 2015 17:32:53 -0700 (PDT)
Received: by 10.129.109.142 with HTTP; Tue, 6 Oct 2015 17:32:53 -0700 (PDT)
In-Reply-To: <CAJE_bqf3MK0YU-=dVR0nL7mgic4nE9BARp5=0hGne0M++045iw@mail.gmail.com>
References: <20CE2629-7D40-4B5B-833E-4A401308027F@employees.org> <CAKD1Yr0aQ8yQR+2GyuVXJS0DrJasmqFz6RLQcodrCW982pNVGA@mail.gmail.com> <CAO42Z2wMNuPe5mmjDx5xG+3GmN-k47gsabiMQX56fiT+Kk-QcA@mail.gmail.com> <CAKD1Yr2AJ4+cvPk-XDzuxehCP+Pw-nUngxhaVMYwUvQJDK8ExA@mail.gmail.com> <CAJE_bqfb-8SBc0_f+tBfSST7-StQp_ug27r=ntRAmfjPwj=rmA@mail.gmail.com> <CAO42Z2wHGNhbC9+Zg3DDO_FCNxY5JxJoe2i0PK1yjF4=JgrGnA@mail.gmail.com> <CAKD1Yr1U8MtHQcoRK7dStF9mkmcnHfN2e7qdm1LVPigKzhaQWg@mail.gmail.com> <CAPK2Dew++U+TsP6D1+Q8xxb6dPOxyO5+7GZd5c1NUd074VMX-A@mail.gmail.com> <CAPK2DewF5KUwzsH2Mfaohdcz3e3=G3GeFHNdw-h=myJtzzdmoA@mail.gmail.com> <CAJE_bqf3MK0YU-=dVR0nL7mgic4nE9BARp5=0hGne0M++045iw@mail.gmail.com>
Date: Wed, 07 Oct 2015 09:32:53 +0900
Message-ID: <CAPK2Dew9yMhbubP3JnuoT-VtAffwG9ZE_k+arupBaHwWetp9KA@mail.gmail.com>
Subject: Re: 6MAN WG Adoption call : draft-jeong-6man-rdnss-rfc6106-bis
From: "Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com>
To: 神明達哉 <jinmei@wide.ad.jp>
Content-Type: multipart/alternative; boundary="94eb2c081d7420ae04052178e3e2"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipv6/D8v6LgvmcGv3QhqEKUL61e83s74>
Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 6man WG <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Oct 2015 00:32:57 -0000

Hi Jinmei,
Thanks for your clarified comments.
I prefer to explicitly note the usage of link-local addresses
to prevent possible problems addressed by Lorenzo.

I think your revised text for the note looks good to me.
One thing to modify is the term of link indices and link zone indices.
I believe that one unified term such as link zone indices will be better as
follows:

 Note:  The addresses for recursive DNS servers in the RDNSS option
       MAY be link-local addresses.  Such link-local addresses SHOULD be
       registered into the resolver repository along with the
       corresponding link zone indices of the links that receive the RDNSS
       option(s) for them.  The link zone indices SHOULD
       be represented in the textual format for scoped addresses as
       described in [RFC4007].  When a resolver sends a DNS query message
       to an RDNSS with a link-local address, it MUST use the
       corresponding link.

If it is okay, I will revise the draft to reflect this change.

Thanks.

Paul


On Wed, Oct 7, 2015 at 1:47 AM, 神明達哉 <jinmei@wide.ad.jp> wrote:

> At Mon, 5 Oct 2015 19:30:47 +0900,
> "Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com> wrote:
>
> > Here is the revised draft reflecting the discussion of link-local
> addresses
> > for recursive DNS servers:
> > https://tools.ietf.org/html/draft-ietf-6man-rdnss-rfc6106bis-03
> >
> > The major changes are as follows:
> >
> > 5.1.  Recursive DNS Server Option
> > ...
> > Note:  The addresses for recursive DNS servers in the RDNSS option
> >       MAY be link-local addresses.  Such link-local addresses SHOULD be
> >       registered into the resolver repository along with the
> >       corresponding interfaces (or zones) that received the RDNSS
> >       option(s) for them.  The interface names (or zone indices) SHOULD
> >       be represented in the textual format for scoped addresses in
> >       described in [RFC4007].  When a resolver sends a DNS query message
> >       to an RDNSS with a link-local address, it MUST use the
> >       corresponding interface.
>
> I guess you're trying to address the following comment of mine:
>
> >> I don't have a strong opinion on whether to allow link-local
> >> addresses per se, but if we allow that, I think we should clarify
> >> which link (or link zone, in RFC4007 terminology) that link-local
> >> address belongs to.  In the case of router advertisements, I guess it
> >> makes most sense if it's the link over which the RA is sent out and
> >> received.
>
> My impression of that discussion was that for others this is too
> trivial to explicitly note.  So I would have been okay with not saying
> anything about it, but now you're actually trying to address that
> (which I appreciate), I'd like to offer some changes based on the
> following observations:
>
> - the above text seems to indicate the common confusion on the
>   difference between interfaces and links. For example, technically,
>   there's no "corresponding interface" or a link-local address;
>   there's only "corresponding link", and you can identify the link if
>   you know an interface that belongs to the link as a context, but
>   that's not the "corresponding interface of a link-local address".
> - using the interface name to represent a link index is an
>   implementation specific hack with the implicit assumption of
>   one-to-one mapping between links and interfaces (that's often the
>   case but architecturally not entirely correct).  so I suspect it's
>   not really appropriate for normative and generic text like this
>
> So I suggest revising the above note as follows:
>
>  Note:  The addresses for recursive DNS servers in the RDNSS option
>        MAY be link-local addresses.  Such link-local addresses SHOULD be
>        registered into the resolver repository along with the
>        corresponding link indices of the links that receive the RDNSS
>        option(s) for them.  The link zone indices SHOULD
>        be represented in the textual format for scoped addresses as
>        described in [RFC4007].  When a resolver sends a DNS query message
>        to an RDNSS with a link-local address, it MUST use the
>        corresponding link.
>
> Or, as we saw in the previous discussion, if many others don't see
> the need for a note like this in the first place, I wouldn't be
> opposed to removing it completely.
>
> --
> JINMEI, Tatuya
>



-- 
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: jaehoon.paul@gmail.com, pauljeong@skku.edu
Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php