From tireddy@cisco.com Mon Oct 17 05:59:47 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97E4521F8B78 for ; Mon, 17 Oct 2011 05:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-mE0e67IL1t for ; Mon, 17 Oct 2011 05:59:46 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 4952021F8B68 for ; Mon, 17 Oct 2011 05:59:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tireddy@cisco.com; l=6474; q=dns/txt; s=iport; t=1318856386; x=1320065986; h=mime-version:subject:date:message-id:references:from:to; bh=n1iFh7iCN/ukKP1trZr82QABPk2ojMzBm1LB5rRRSZM=; b=DrCnpyQontwPz1dQuJGUCE6aceYaZVp1dbJJgAwI/UAj3w9e1931GDq7 z4RFVAOOP2/quHa/t4IEzDcvYl7xjMdUqChRmGVBLtxVwBN8I6B9ysofZ ewbjgHrlxgrn9BAwGH4OJDHzXKLszfBM1CpqECqH43XYZX2g0hJrsEzPl g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEQmnE5Io8UQ/2dsb2JhbABDgk2mGoEFgW8BAQQSAQkRA1kCASoGGAYBVgEBBAEKEAEZh2WUWgGeJ4cnYQSIAJEsjCw X-IronPort-AV: E=Sophos;i="4.69,359,1315180800"; d="scan'208,217";a="1160860" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-3.cisco.com with ESMTP; 17 Oct 2011 12:59:44 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9HCxi6W022974 for ; Mon, 17 Oct 2011 12:59:44 GMT Received: from xmb-bgl-41b.cisco.com ([72.163.129.217]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Oct 2011 18:29:44 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC8CCC.A3EF1E9C" Date: Mon, 17 Oct 2011 18:29:42 +0530 Message-ID: <454A16E4DA86094EB66BB2C1DBBBC01805ED56A0@XMB-BGL-41B.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Draft - Relay-Supplied DHCPv6 Precedence Options Thread-Index: AcyLOccRrjIwEfq9Tk6CTmkgR/tdNwBj+JGQAAAdr0A= References: <201110151255.p9FCtpg20223@ftpeng-update.cisco.com> From: "Tirumaleswar Reddy (tireddy)" To: , "Dan Wing (dwing)" , "Prashanth Patil (praspati)" X-OriginalArrivalTime: 17 Oct 2011 12:59:44.0037 (UTC) FILETIME=[A40C0550:01CC8CCC] X-Mailman-Approved-At: Mon, 17 Oct 2011 06:18:24 -0700 Subject: [mif] New Draft - Relay-Supplied DHCPv6 Precedence Options X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 12:59:47 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC8CCC.A3EF1E9C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A New Internet-Draft is available from the on-line Internet-Drafts directories. =20 Title : Relay-Supplied DHCPv6 Precedence Options Author(s) : Tirumaleswar Reddy Prashanth Patil Dan Wing Filename : draft-reddy-mif-dhcpv6-precedence-ops-00.txt Pages : 11 Date : 2011-10-14 =20 This draft proposes a new DHCPv6 options to be added by the DHCPv6 relay agent when it generates a Relay-Forwarded message. These new DHCPv6 options convey information about the host and about dynamic network characteristics to influence the DHCPv6 server to generate a reply that is appropriate for that host and the current network characteristics. On a dynamic network, the DHCPv6 relay agent can observe characteristics of a network -- such as IPv6 multihoming which might be temporarily unavailable or need load balancing of traffic towards each upstream ISPs, can disable IPv6 Temporary address. By including additional information in relayed DHCPv6 messages, the DHCPv6 relay agent can influence the DHCPv6 server to provide answers that are better suited to the host's configuration on the network. =20 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-reddy-mif-dhcpv6-precedence-op s-00.txt =20 This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-reddy-mif-dhcpv6-precedence-ops -00.txt =20 Please kindly review it. Comments welcome. =20 --Tiru. ------_=_NextPart_001_01CC8CCC.A3EF1E9C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A New Internet-Draft is available from the = on-line Internet-Drafts directories.

 

Title : Relay-Supplied DHCPv6 Precedence = Options

Author(s) : Tirumaleswar Reddy

        &nbs= p;   Prashanth Patil

        &nbs= p;   Dan Wing

Filename : = draft-reddy-mif-dhcpv6-precedence-ops-00.txt

Pages : 11

Date : 2011-10-14

 

This draft proposes a new DHCPv6 options to be = added by the DHCPv6 relay agent when it generates a Relay-Forwarded message. = These new DHCPv6 options convey information about the host and about dynamic = network characteristics to influence the DHCPv6 server to generate a reply that = is appropriate for that host and the current network characteristics. On a = dynamic network, the DHCPv6 relay agent can observe characteristics of a network = -- such as IPv6 multihoming which might be temporarily unavailable or need = load balancing of traffic towards each upstream ISPs, can disable IPv6 = Temporary address. By including additional information in relayed DHCPv6 messages, = the DHCPv6 relay agent can influence the DHCPv6 server to provide answers = that are better suited to the host's configuration on the network.

 

A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-reddy-mif-dhcp= v6-precedence-ops-00.txt

 

This Internet-Draft can be retrieved = at:

ftp://ftp.ietf.org/internet-drafts/draft-reddy-mif-dhcpv6= -precedence-ops-00.txt

 

Please kindly review it. Comments = welcome.

 

--Tiru.

------_=_NextPart_001_01CC8CCC.A3EF1E9C-- From internet-drafts@ietf.org Tue Oct 18 23:33:01 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88EC021F84D8; Tue, 18 Oct 2011 23:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aXMF1vI6zHaQ; Tue, 18 Oct 2011 23:33:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F0D621F84BB; Tue, 18 Oct 2011 23:33:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20111019063301.1618.2068.idtracker@ietfa.amsl.com> Date: Tue, 18 Oct 2011 23:33:01 -0700 Cc: mif@ietf.org Subject: [mif] I-D Action: draft-ietf-mif-dns-server-selection-06.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 06:33:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiple Interfaces Working Group of = the IETF. Title : Improved DNS Server Selection for Multi-Interfaced Nodes Author(s) : Teemu Savolainen Jun-ya Kato Ted Lemon Filename : draft-ietf-mif-dns-server-selection-06.txt Pages : 26 Date : 2011-10-18 A multi-interfaced node is connected to multiple networks, some of which may be utilizing private DNS namespaces. A node commonly receives DNS server configuration information from all connected networks. Some of the DNS servers may have information about namespaces other servers do not have. When a multi-interfaced node needs to utilize DNS, the node has to choose which of the servers to contact to. This document describes DHCPv4 and DHCPv6 options that can be used to configure nodes with information required to perform informed DNS server selection decisions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mif-dns-server-selection-06.= txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mif-dns-server-selection-06.t= xt From teemu.savolainen@nokia.com Tue Oct 18 23:43:07 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F06AA11E8090; Tue, 18 Oct 2011 23:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.57 X-Spam-Level: X-Spam-Status: No, score=-1.57 tagged_above=-999 required=5 tests=[AWL=-1.422, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofBKIgqDODaI; Tue, 18 Oct 2011 23:43:06 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 742A811E8073; Tue, 18 Oct 2011 23:43:04 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p9J6ghAa026319; Wed, 19 Oct 2011 09:42:58 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Oct 2011 09:42:49 +0300 Received: from 008-AM1MMR1-006.mgdnok.nokia.com (65.54.30.61) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 19 Oct 2011 08:42:48 +0200 Received: from 008-AM1MPN1-037.mgdnok.nokia.com ([169.254.7.8]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0339.002; Wed, 19 Oct 2011 08:42:47 +0200 From: To: , , , , Thread-Topic: [mif] 2nd Last Call for MIF DNS server selection document Thread-Index: AQHMf4YJc1OWueh3WEqDYlN2BZxXYpWDUwvA Date: Wed, 19 Oct 2011 06:42:46 +0000 Message-ID: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Company Confidential;Project=None; x-titus-version: 3.3.8.1 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IplYcKbXY4PV0ei3gFpNObHe+lTM1U1xbihCwzQd/31+Vpsv1JI/CghilcM/oudMLL/ZE5yjuV1btDJGeMSb+omF450JciYLYU6qxQQ8Xaa1p2Xz8pU5JtexlfPCe2LbkrEsd18wN+6h+QJs60yrUp8zy2fyngKs2jNCwrbSbF3kVd3WmTuyR23nTH2VpieUXQIilkTpcKD2+yW1jpOLBqNLbcidN3Qq8iOyoJwvL7FOJmRcjJdjp9CW/t54mdvKEg== x-originating-ip: [10.162.59.225] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0245_01CC8E43.73EFA520" MIME-Version: 1.0 X-OriginalArrivalTime: 19 Oct 2011 06:42:49.0594 (UTC) FILETIME=[519D5DA0:01CC8E2A] X-Nokia-AV: Clean Cc: sa.morris7@googlemail.com, pk@isoc.de, john_brzozowski@cable.comcast.com Subject: Re: [mif] 2nd Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 06:43:07 -0000 ------=_NextPart_000_0245_01CC8E43.73EFA520 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0246_01CC8E43.73EFA520" ------=_NextPart_001_0246_01CC8E43.73EFA520 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi all, =20 This second WGLC resulted in very few comments. In the DHC WG we = discussed about DHCPv4 option structure and in MIF there was a comment about document-internal reference bug. =20 I have now uploaded a version six that contains: - Fixes to the DHCPv4 option structure - Highlighting stricter length limitation in case of DHCPv4 = option - Fix to the reference bug - Small fixes to missing DHCPv4 considerations in sections 4.5 = and 4.6. =20 Please see diff: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-mif-dns-server-selection-= 06 =20 If no further comments, I think this document is ready to go to the = IESG. =20 Thank you, =20 Teemu =20 =20 From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of = ext Hui Deng Sent: 30. syyskuuta 2011 18:29 To: mif@ietf.org; dnsext@ietf.org; dnsop@ietf.org; dhcwg@ietf.org Cc: pk@isoc.de; john_brzozowski@cable.comcast.com; = sa.morris7@googlemail.com Subject: [mif] 2nd Last Call for MIF DNS server selection document =20 Dear all =20 Based on 1st round WG LC, the authors have received significant advice = about revision and submited a new version accordingly: http://www.ietf.org/internet-drafts/draft-ietf-mif-dns-server-selection-0= 5.t xt =20 And we plan to issue a second round WG LC, and cc to DHCWG, DNSEXT, = DNSOP related working groups, please DNSEXT/DNSOP chairs help to forward to = the MLs since I may not subscribe to them. =20 This is a 2 weeks with little extension LC, it will finish on October = 17, Please send substantive review and editorial comments to mif@ietf.org =20 Thanks a lot for youre view Best regards, =20 Margaret and Hui =20 =20 =20 Below are Teemu's writeup about the revision: =20 I uploaded -05 update so that next comments would take into account = changes I already did based on discussions with Murray (as was copied to this = list). The biggest clarifications related to how DNS queries are sent to = different servers and when all servers are waited for answers (if reply is not validated) and when not. I.e. this text: -- A node SHALL send requests to DNS servers in the order defined by the priority list until an acceptable reply is received, all replies are received, or a time out occurs. In the case of a requested name matching to a specific domain or network rule accepted from any interface, a DNSSEC-aware resolver MUST NOT proceed with a reply that cannot be validated using DNSSEC until all DNS servers on the priority list have been contacted or timed out. This protects against possible redirection attacks. In the case of the requested name not matching to any specific domain or network, first received response from any DNS server MAY be considered acceptable. A DNSSEC- aware node MAY always contact all DNS server in an attempt to receive a response that can be validated, but contacting all DNS servers is not mandated for the default case as in some deployments that would consume excess resources. -- Teemu > -----Original Message----- > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of > ext internet-drafts@ietf.org > Sent: 20. syyskuuta 2011 22:10 > To: i-d-announce@ietf.org > Cc: mif@ietf.org > Subject: [mif] I-D Action: draft-ietf-mif-dns-server-selection-05.txt - =CF=D4=CA=BE=D2=FD=D3=C3=CE=C4=D7=D6 - > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Multiple Interfaces Working Group of = the > IETF. > > Title : Improved DNS Server Selection for = Multi-Interfaced > Nodes > Author(s) : Teemu Savolainen > Jun-ya Kato > Ted Lemon > Filename : draft-ietf-mif-dns-server-selection-0 5.txt > Pages : 26 > Date : 2011-09-20 > > A multi-interfaced node is connected to multiple networks, some of > which may be utilizing private DNS namespaces. A node commonly > receives DNS server configuration information from all connected > networks. Some of the DNS servers may have information about > namespaces other servers do not have. When a multi-interfaced node > needs to utilize DNS, the node has to choose which of the servers = to > contact to. This document describes DHCPv4 and DHCPv6 option that > can be used to configure nodes with inform ation required to = perform > informed DNS server selection decisions. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mif-dns-server-selection-0= 5.t xt ------=_NextPart_001_0246_01CC8E43.73EFA520 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi all,

 

This second WGLC resulted in very few comments. In the DHC WG we = discussed about DHCPv4 option structure and in MIF there was a comment = about document-internal reference bug.

 

I have now uploaded a version six that = contains:

-          = Fixes to the DHCPv4 option structure

-          = Highlighting stricter length limitation in case of DHCPv4 = option

-          = Fix to the reference bug

-          = Small fixes to missing DHCPv4 considerations in sections 4.5 and = 4.6.

 

Please see diff: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-mif-dns-serve= r-selection-06

 

If no further comments, I think this document is ready to go to the = IESG.

 

Thank you,

 

           &nbs= p;    Teemu

 

 

From:= = mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of = ext Hui Deng
Sent: 30. syyskuuta 2011 18:29
To: = mif@ietf.org; dnsext@ietf.org; dnsop@ietf.org; = dhcwg@ietf.org
Cc: pk@isoc.de; = john_brzozowski@cable.comcast.com; = sa.morris7@googlemail.com
Subject: [mif] 2nd Last Call for MIF = DNS server selection document

 

Dear = all
 
Based on 1st round WG LC, the authors have received = significant advice about revision and submited a new version = accordingly:
http://www.ietf.org/internet-drafts/draft-ietf-mif-dns-ser= ver-selection-05.txt
 
And we plan to issue a second = round WG LC, and cc to DHCWG, DNSEXT, DNSOP related working groups, = please DNSEXT/DNSOP chairs help to forward to the MLs since I may not = subscribe to them.
 
This is a 2 weeks with little = extension LC, it will finish on October 17,
Please send = substantive review and editorial comments to mif@ietf.org
 
Thanks a lot = for youre view
Best regards,
 
Margaret and = Hui
 
 
 
Below are Teemu's writeup = about the revision:
 
I uploaded -05 update so that next = comments would take into account changes
I already did based on = discussions with Murray (as was copied to this list).
The biggest = clarifications related to how DNS queries are sent to = different
servers and when all servers are waited for answers (if = reply is not
validated) and when not. I.e. this text:
--
  = A node SHALL send requests to DNS servers in the order defined by = the
  priority list until an acceptable reply is received, all = replies are
  received, or a time out occurs.  In the case = of a requested name
  matching to a specific domain or network = rule accepted from any
  interface, a DNSSEC-aware resolver MUST = NOT proceed with a reply that
  cannot be validated using DNSSEC = until all DNS servers on the
  priority list have been contacted = or timed out.  This protects
  against possible redirection = attacks.  In the case of the requested
  name not matching = to any specific domain or network, first received
  response = from any DNS server MAY be considered acceptable.  A = DNSSEC-
  aware node MAY always contact all DNS server in an = attempt to receive
  a response that can be validated, but = contacting all DNS servers is
  not mandated for the default = case as in some deployments that would
  consume excess = resources.
--
       Teemu
> = -----Original Message-----
> From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.or= g] On Behalf Of
> ext internet-drafts@ietf.org
= > Sent: 20. syyskuuta 2011 22:10
> To: i-d-announce@ietf.org
> = Cc: mif@ietf.org
> Subject: = [mif] I-D Action: draft-ietf-mif-dns-server-selection-05.txt
- = =CF=D4=CA=BE=D2=FD=D3=C3=CE=C4=D7=D6 = -
>
> A New Internet-Draft is available from the on-line = Internet-Drafts
directories.
> This draft is a work item of the = Multiple Interfaces Working Group of the
> = IETF.
>
>       = Title           : = Improved DNS Server Selection for Multi-Interfaced
> = Nodes
>       = Author(s)       : Teemu = Savolainen
>         &= nbsp;           &n= bsp;     Jun-ya = Kato
>          &= nbsp;           &n= bsp;    Ted = Lemon
>       = Filename        : = draft-ietf-mif-dns-server-selection-0 = 5.txt
>       = Pages           : = 26
>       = Date            : = 2011-09-20
>
>    A multi-interfaced node is = connected to multiple networks, some of
>    which = may be utilizing private DNS namespaces.  A node = commonly
>    receives DNS server configuration = information from all connected
>    networks.  = Some of the DNS servers may have information = about
>    namespaces other servers do not = have.  When a multi-interfaced node
>    needs = to utilize DNS, the node has to choose which of the servers = to
>    contact to.  This document describes = DHCPv4 and DHCPv6 option that
>    can be used to = configure nodes with inform ation required to = perform
>    informed DNS server selection = decisions.
>
>
> A URL for this Internet-Draft = is:
> http://www.ietf.org/internet-drafts/draft-ietf-mif-dns-ser= ver-selection-05.txt

------=_NextPart_001_0246_01CC8E43.73EFA520-- ------=_NextPart_000_0245_01CC8E43.73EFA520 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOuzCCAzYw ggIeoAMCAQICBDpVqdkwDQYJKoZIhvcNAQEFBQAwKTEOMAwGA1UEChMFTm9raWExFzAVBgNVBAMT Dk5va2lhICBSb290IENBMB4XDTAxMDEwNTExMDUwNVoXDTE2MDEwMjExMDUwNVowKTEOMAwGA1UE ChMFTm9raWExFzAVBgNVBAMTDk5va2lhICBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsrTy8gLmr4LYvp0khVUVHw7ascdl+Cjr+yI5MlZ6J/U6Qsvkiqthgqq8rPcLV0P1 92TfBr27VgKEeCaZe0icS1jC2spM/wRv3j2WxdkKxb9kDJtuCNJaRBqvi5vGTHB15nmEmKuL5f3i rAxeHqPjgS496oWcudzFT1e7Xrc/gWGFYd72+/ykIFXjWOMZv6QpxD8x1hLPyh2YVXRk9U7N7pvm RQNX29g4SCFJY2BBIa5JPlwIF8Nc9IePaC/E/2M4tGMtiOOZlm99EoL7N0hJZtFSvUwdCBud/viH 4DgsKGjNkNKi6pAHc9IaXB6tIykcoYp+L+oe/3+cuEJaCj1EKwIDAQABo2YwZDASBgNVHRMBAf8E CDAGAQH/AgEEMB0GA1UdDgQWBBSNjfefoQ0AITLvqe0iruA79NB9sDAfBgNVHSMEGDAWgBSNjfef oQ0AITLvqe0iruA79NB9sDAOBgNVHQ8BAf8EBAMCAYYwDQYJKoZIhvcNAQEFBQADggEBAIGEPql2 TALyKi/h1J+Mh5XolAtYppcSOLMtBkoA7ZovGBDNvl0VbZs8AAojJqkUoWBB+L6DKyl/jKhNfKcu rWRGRyj7pnbxrKLsI3gmWNWkyo2b60wJwe9fqPD5ZQy3oEiMit9l0Ba6il/k2GqYopUCNMa7mfeb E2LeBy5ChYMiCi97UQSJvAdzEYylTJw8Awc6AiM2Ve5N+XxsmKgNf/2A/5IJ3EZZ+wFRmkI4062A oNU302rqAt0HH88jzoUF4AfYHWl6HpYhGXFbcX44rHINyPmFBRxLYIFJ6ZWUr/mXpL/e6rqFtNWO kV6UoJND7OVZkbLh7F1+lcqXRU8TPBMwggOHMIICb6ADAgECAgRBtbHpMA0GCSqGSIb3DQEBBQUA MCkxDjAMBgNVBAoTBU5va2lhMRcwFQYDVQQDEw5Ob2tpYSAgUm9vdCBDQTAeFw0wNjAzMzAwOTU3 MTFaFw0xNjAxMDIxMTA1MDVaMDMxCzAJBgNVBAYTAkZJMQ4wDAYDVQQKEwVOb2tpYTEUMBIGA1UE AxMLTm9raWEgQkkgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDtFCg3QEjSCg6T IUxoWsNwELh8bBNiUQPCPmg8c2DHQYXWWCSCMb+S0Fvh1qqI1xt+XnzyFq+5eqzGzDj4UaBcG+d9 qxrCFly8sHyoPTryyPrR0EI2UUDWwfS6ojhqgwghRqo8G38TjFusyBtLub/5L6yvWYSOHD+JcB+q VM2fbkArPYK4Ydv8WG/DbHjGn0gKq0zwpVZKI/gCK/QALYvte02NXseqvY9/GOyLtjy3Z8erFv71 KKTq+gxI/7DK55pJf3PoD+kT4kyGm6EF9DTdK4ojMdar17uyX0IOZz/4vkkF0d+60nmnLX63FJPA jUyB0HUNJ32NXDo9UsM38aoNAgMBAAGjgawwgakwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAI MAYGBFUdIAAwDgYDVR0PAQH/BAQDAgGGMFQGA1UdIwRNMEuAFI2N95+hDQAhMu+p7SKu4Dv00H2w oS2kKzApMQ4wDAYDVQQKEwVOb2tpYTEXMBUGA1UEAxMOTm9raWEgIFJvb3QgQ0GCBDpVqdkwHQYD VR0OBBYEFKcksD7Fg+8EDlB2Sxgy58pW0Sy6MA0GCSqGSIb3DQEBBQUAA4IBAQAC3lEUplDlVNOT Pjz/XFezXx2bV2XbCFindhA3F815Egi55H6/cYezEjoP4QLNEGGl2I3aLvkn5A0T8I4pbiFPhIiu B/frbbGg6k6GjQLe/bFQ8F1mAOOR+GyneKZFPfzaRV0jiIR9QqnMXTf8RvKkCJyFj10MZVsLIy/Y uBkzeP3JhzDhUdtPfwmJN6ZbIhH5uR/2BwAGtgQknb8WX3I4wnhWtMUxB8XmayayYs8qWYeIiVkI FV+sLTkWUWVvvKUjyakBpbAW2vUP84DYsJ8TL1YefNjf/nIOByMcORLuV/1gPjyv00qJbcB59AA+ iXe3zIo8QNcgXG0uPQQFmrGDMIID5DCCAsygAwIBAgIQMH5apak8lEy6LmLlLsJy8TANBgkqhkiG 9w0BAQUFADAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJ IENBMB4XDTExMDkwNjA1NTIwNFoXDTE0MDkwNjA1NTIwNFowVjEOMAwGA1UECgwFTm9raWExDzAN BgNVBAsMBlBlb3BsZTEYMBYGCgmSJomT8ixkAQEMCDEwMDI0Njc2MRkwFwYDVQQDDBBTYXZvbGFp bmVuIFRlZW11MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAshEsmw6Yiz6XWX26oF+I s5fsfE1OfCjOelclmtqCiIgXND5klkNOBs2d4ZGzgD9mN+XnTZnOTh249c2WxPBugf12DCcDmBAJ gL+VuWUJVBTE5NRchm/O8nZnZsRFst+gAC9/Juykh4+EYewZ7QbpnlwW7hNpj8eH+rMr+OZHKzdp KTftgVjmuF4JJ/cPMQUjL8SuGj+zBW6IWPOZdqkEMtf7Pr8kkYbZsh0SgJ0ceRHZ7Uc06mB/y+C1 UnJPxehTTdu8tpCjdzXgBw/H2uuW1J3qdHbCfbuDILql8V8RiZKubcZLhdsD3Jvj8qK0DGWBJa6x p90q5p3pLE8LvAeCgQIDAQABo4HQMIHNMA4GA1UdDwEB/wQEAwIEMDAfBgNVHSMEGDAWgBSnJLA+ xYPvBA5QdksYMufKVtEsujAZBgNVHSAEEjAQMA4GDCsGAQQBXgExBgEHAzA5BgNVHR8EMjAwMC6g LKAqhihodHRwOi8vY3JsLm5va2lhLmNvbS9Ob2tpYSUyMEJJJTIwQ0EuY3JsMCUGA1UdEQQeMByB GnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBQTRzvZsgmQrAGCeuzdHTGAC6Jg UzANBgkqhkiG9w0BAQUFAAOCAQEACmPVsdi07pjK5gDa+W5JlE2C74kVVsB8alBqfioYeR5At2FG B7sua4Dz5H7TJMpZ1jYFeI+zjexD5f+beY2IlV15lMoWD+5e38QlLYjwfe2LAyvdzBKXW0e0U6Bt p78ft4gyVak1X+Db+ebR+FNHUOMNhm+yK3w9sy5ZQzBFusIx4OgxGvcZhyhmd9WjipSTalgPwgqV Ju2aPADCG++OEXmgEWRLsR4yNopkgK4ftVqrN5uUtLs83qdeXTRcNRiET1IOx5zmYFZ6q3gjKIx5 iyuxcDeYas93vVHUcaRRYpsoby5CHq7Z/j/TQhtqO/knWuxLFFiCUgdGKMKrRkg29DCCBAowggLy oAMCAQICEQCBvi+p+bA/dBtBtybwA6YYMA0GCSqGSIb3DQEBBQUAMDMxCzAJBgNVBAYTAkZJMQ4w DAYDVQQKEwVOb2tpYTEUMBIGA1UEAxMLTm9raWEgQkkgQ0EwHhcNMTEwOTA2MDU1MDM0WhcNMTMw OTA1MDU1MDM0WjBWMQ4wDAYDVQQKDAVOb2tpYTEPMA0GA1UECwwGUGVvcGxlMRgwFgYKCZImiZPy LGQBAQwIMTAwMjQ2NzYxGTAXBgNVBAMMEFNhdm9sYWluZW4gVGVlbXUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDFPmbRVwuo52v+h6xnQUqokAx2xsHjmPBniEkzgtgBNJsFi838ATEg 1zsx+VotoJg7hMijcrQfpTAgW6gpLGnlmw5QQswrNK1zleOHb4pA5JguU3WhVKFkAH/6/2EU2k/9 m8Pb/gwP55cYg80R6fRmbdsWKhseXF/1isW/rJcWLmIYDg/rXfo3ixqtT9MroAMiuoXnb0ij1L2d Jj64LDp3Ld8Jo0qZzk3Fj4apo8PBd8eAH6HloVBJkxQcwAnv561A+Xi1GHZ2mafRYJGO+1uBDwyd g/8ybEXXA4MKo8lPKjBebYBUFvz80DBA/Lq74UysXkG23BSulcG4xQSYGlyzAgMBAAGjgfUwgfIw HwYDVR0jBBgwFoAUpySwPsWD7wQOUHZLGDLnylbRLLowGQYDVR0gBBIwEDAOBgwrBgEEAV4BMQYB BgQwOQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5ub2tpYS5jb20vTm9raWElMjBCSSUyMENB LmNybDAjBgNVHSUEHDAaBggrBgEFBQcDAgYEVR0lAAYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgeA MCUGA1UdEQQeMByBGnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBTGhbTJF0EX iagjymQo6GIuSQeRVDANBgkqhkiG9w0BAQUFAAOCAQEAqai6TxZ/BlMHZIhJNPriBPXkQhUlBkGA buJZ5sVm1HIQhWN8elZKjjJdHi1qWEKhMg7yHjEMZsyV8XAZzK0UnOqkpUnt+jnVkNZ9O7/jRtyK f4WUtq5jErc8Hlv4bbGFRHk1T7AuLLE52r1lYOdmoibnQp03QtlDvHUNa68G7jvzThJhieB7U1xh vH3yy0ktaVnWEgAylqf9yIUFjnqau5R6cE1Xo57IYPk/KitX0YF+OigEI/bOQVMi+fze93ZsAOJv /z6g/NGemvUgl5YSdX0uPQK6kEHf/sp/nZyUWWQ7OjtVSqkq2YuYEueQFxTfafl+78GWqgm6W/Bl 32laYzGCAuswggLnAgEBMEgwMzELMAkGA1UEBhMCRkkxDjAMBgNVBAoTBU5va2lhMRQwEgYDVQQD EwtOb2tpYSBCSSBDQQIRAIG+L6n5sD90G0G3JvADphgwCQYFKw4DAhoFAKCCAXgwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTExMDE5MDY0MjQ0WjAjBgkqhkiG9w0B CQQxFgQUh/1sRybEX9NHS82b5N4VBmYzuZwwVgYJKwYBBAGCNxAEMUkwRzAzMQswCQYDVQQGEwJG STEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLx MFgGCyqGSIb3DQEJEAILMUmgRzAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNV BAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLxMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMA0GCSqGSIb3DQEBAQUABIIBAC7ZXA5t+QbKGyps1ra3 HYshigKckLE3cD0T3ki8ZzfKp0MPP5O+JluVSZqatiARmOi3wZ2BM3weUiwg94kLkP598Fl8EsGJ /0PMbKwfL8TLslYGY+D9PVl0brhAMqjs8kCAQ8yA/hV4IGTgvQc1yw6nkAeX5A+iOuBpJN+UWoJr iMdYFacJzwF3BddyrqCW2UGJjw7oLgB7p5/MOo2Ym3oYC0slBcL4C8hpNK1nTf934GBzfSKeGgaO lLwFfqh9vLz9ywQ2XV0SaN9Y+DYHbXy6TmrqBVlVGrJVFGteBEs4hnxhE5RPlBhlrDbOrziXgCXT c1zH20OU1j/c33aM2AsAAAAAAAA= ------=_NextPart_000_0245_01CC8E43.73EFA520-- From Ray.Bellis@nominet.org.uk Wed Oct 19 03:40:24 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B781C21F8B9A; Wed, 19 Oct 2011 03:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.35 X-Spam-Level: X-Spam-Status: No, score=-8.35 tagged_above=-999 required=5 tests=[AWL=0.496, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUjRrRhe0Z6N; Wed, 19 Oct 2011 03:40:24 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by ietfa.amsl.com (Postfix) with ESMTP id E87B021F8B92; Wed, 19 Oct 2011 03:40:22 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: Content-ID:Content-Transfer-Encoding:MIME-Version; b=caaUtaFTHB5H3HAANahafeEaDk1Jw8+Hd5QVMMi3mxtsbS4/zKpm0dLA 8YpsPN1ZBFsm8cI6uJtJ95uFqzYyCOLlngnIXDaSh7Z6w2zUu6w6ONcS3 2GVnnxX0Qd89xJV; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1319020823; x=1350556823; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20[dnsext]=20[mif]=202nd=20Last=20Call=20 for=20MIF=20DNS=20server=20selection=0D=0A=09document |Date:=20Wed,=2019=20Oct=202011=2010:39:59=20+0000 |Message-ID:=20<121DABD1-65E8-4275-8471-9FA38D25C434@nomi net.org.uk>|To:=20"=20=20"=0D=0A=09|CC:=20""=20,=20""=0D=0A=09,=20""=20,=20"" =0D=0A=09,=20""=20,=20""=0D=0A=09,=20""=0D=0A=09|MIME-Version:=201.0 |Content-Transfer-Encoding:=20base64|Content-ID:=20|In-Reply-To:=20<916CE6CF 87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.n okia.com>|References:=20=0D=0A=20<916CE6CF87173740BC8A2CE443096962037 82D75@008-AM1MPN1-037.mgdnok.nokia.com>; bh=wjXrwR/5mZrsxKodJhBl0WBtDXFA5FKFX13mPqu7Hv0=; b=5UBvh3985+KrOG/aG36B72pWXl5sB+9xnPyWVTktv20rqxCE7tiZ8fSB cjM/HkAdJyn2Mup19fNJiIzjAP8C2SlM5cnGC7Na617jvF07KYOuneWB2 jwqMWSAJKHOVTEL; X-IronPort-AV: E=Sophos;i="4.69,371,1315177200"; d="scan'208";a="29067810" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx4.nominet.org.uk with ESMTP; 19 Oct 2011 11:40:00 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%19]) with mapi; Wed, 19 Oct 2011 11:40:00 +0100 From: Ray Bellis To: " " Thread-Topic: [dnsext] [mif] 2nd Last Call for MIF DNS server selection document Thread-Index: AQHMjipy2DQifQawrE6jw+Ds3oKeKpWDac2A Date: Wed, 19 Oct 2011 10:39:59 +0000 Message-ID: <121DABD1-65E8-4275-8471-9FA38D25C434@nominet.org.uk> References: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="gb2312" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 19 Oct 2011 04:15:59 -0700 Cc: "" , "" , "" , "" , "" , "" , "" Subject: Re: [mif] [dnsext] 2nd Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 10:40:24 -0000 DQpPbiAxOSBPY3QgMjAxMSwgYXQgMDc6NDIsIDx0ZWVtdS5zYXZvbGFpbmVuQG5va2lhLmNvbT4N CiA8dGVlbXUuc2F2b2xhaW5lbkBub2tpYS5jb20+IHdyb3RlOg0KDQo+IEhpIGFsbCwNCj4gIA0K PiBUaGlzIHNlY29uZCBXR0xDIHJlc3VsdGVkIGluIHZlcnkgZmV3IGNvbW1lbnRzLiBJbiB0aGUg REhDIFdHIHdlIGRpc2N1c3NlZCBhYm91dCBESENQdjQgb3B0aW9uIHN0cnVjdHVyZSBhbmQgaW4g TUlGIHRoZXJlIHdhcyBhIGNvbW1lbnQgYWJvdXQgZG9jdW1lbnQtaW50ZXJuYWwgcmVmZXJlbmNl IGJ1Zy4NCj4gIA0KPiBJIGhhdmUgbm93IHVwbG9hZGVkIGEgdmVyc2lvbiBzaXggdGhhdCBjb250 YWluczoNCj4gLSAgICAgICAgICBGaXhlcyB0byB0aGUgREhDUHY0IG9wdGlvbiBzdHJ1Y3R1cmUN Cj4gLSAgICAgICAgICBIaWdobGlnaHRpbmcgc3RyaWN0ZXIgbGVuZ3RoIGxpbWl0YXRpb24gaW4g Y2FzZSBvZiBESENQdjQgb3B0aW9uDQo+IC0gICAgICAgICAgRml4IHRvIHRoZSByZWZlcmVuY2Ug YnVnDQo+IC0gICAgICAgICAgU21hbGwgZml4ZXMgdG8gbWlzc2luZyBESENQdjQgY29uc2lkZXJh dGlvbnMgaW4gc2VjdGlvbnMgNC41IGFuZCA0LjYuDQo+ICANCj4gUGxlYXNlIHNlZSBkaWZmOiBo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtbWlmLWRucy1zZXJ2 ZXItc2VsZWN0aW9uLTA2DQoNCkFwb2xvZ2llcyBmb3IgdGhlIGxhdGUgY29tbWVudCAtIEkgaGF2 ZSBiZWVuIHRpZWQgdXAgd2l0aCBteSBvd24gV0cgYW5kIGJlZW4gb2ZmIHNpY2sgdG9vLg0KDQpJ IGhhdmUgY29uY2VybnMgYWJvdXQgoew0LjY6DQoNCiJBIGJhcmUgbmFtZSAoYSBuYW1lIHdpdGhv dXQgYW55IGRvdHMpIE1VU1QgYmUgZmlyc3QgdHJlYXRlZCBhcyBhIHByZS0NCiBETlMgaG9zdG5h bWUsIGFuZCBvbmx5IGFmdGVyIHRoYXQgdGhlIG5hbWUgU0hBTEwgYmUgYXBwZW5kZWQgd2l0aA0K IGRvbWFpbiBpbmZvcm1hdGlvbiBhbmQgZGVzY3JpYmVkIEROUyBzZXJ2ZXIgc2VsZWN0aW9uIGxv Z2ljIGJlDQogdXRpbGl6ZWQuIg0KDQpXaGVuIG5ldyBnVExEcyBhcmUgaW50cm9kdWNlZCBpdCBp cyBsaWtlbHkgZm9yIGJyYW5kLW5hbWUgZ1RMRHMgdGhhdCB0aGV5IHdpbGwgd2lzaCB0byB1c2Ug YmFyZSBuYW1lcyBpbiB0aGUgRE5TIChpLmUuIGEgc2luZ2xlIGxhYmVsIGhvc3RuYW1lKSBmb3Ig dGhlaXIgcHJpbWFyeSB3ZWIgc2l0ZXMuDQoNCkhlbmNlIGJhcmUgbmFtZXMgbWF5IGJlY29tZSBt dWNoIG1vcmUgZnJlcXVlbnRseSB1c2VkIGFzIEROUyBuYW1lcywgYW5kIKHsNC42IHdvdWxkbid0 IHBlcm1pdCB0aG9zZSB0byB3b3JrIHVubGVzcyAnLicgaXMgYWxzbyBpbiB0aGUgc3VmZml4IGxp c3QuDQoNCk15IG93biB2aWV3IGlzIHRoYXQgRE5TIHNlYXJjaCBzdWZmaXhlcyBzaG91bGQgYmUg ZGVwcmVjYXRlZCBhbmQgdGhhdCB0aGV5IGNhdXNlIG1vcmUgaGFybSB0aGFuIGdvb2QuDQoNCkEg cmVsYXRlZCBpc3N1ZSBpcyB0aGF0IHRoZXkgZW5jb3VyYWdlIHRoZSBzaGFyaW5nIG9mIGFiYnJl dmlhdGVkIFVSTHMgdGhhdCBkb24ndCB3b3JrIHdoZW4gdGhlIHJlY2lwaWVudCBpcyBub3QgdXNp bmcgdGhlIHJpZ2h0IHNlYXJjaCBzdWZmaXgsIHBlcmhhcHMgYmVjYXVzZSB0aGV5J3JlIG9mZiBz aXRlLiAgU29tZSBvZiBteSBjb2xsZWFndWVzIG9mdGVuIHNoYXJlIGRvY3VtZW50cyBvbiBvdXIg aW50cmFuZXQgYnkgc2VuZGluZyBhcm91bmQgbGlua3MgbGlrZSA8aHR0cDovL2ludHJhbmV0L3Bh dGg+LiAgSWYgSSdtIG9mZiBzaXRlIG5vdCBvbmx5IHdpbGwgdGhhdCBub3Qgd29yaywgYnV0IGl0 IGNvdWxkIHJlc3VsdCBpbiBhIGNvbm5lY3Rpb24gdG8gdGhlIHdyb25nIHNlcnZlciBhbmQgYSBw b3RlbnRpYWwgbGVha2FnZSBvZiBjcmVkZW50aWFscy4NCg0KSSd2ZSBkaXNjdXNzZWQgdGhlc2Ug aXNzdWVzIHdpdGggc2VhcmNoIHN1ZmZpeGVzIHdpdGggdmFyaW91cyBvdGhlciBETlMgZm9sayBh bmQgbm90IGhlYXJkIGFueSBkaXNhZ3JlZW1lbnQuDQoNClNlZSBhbHNvIDxodHRwOi8vd3d3LmNp cmNsZWlkLmNvbS9wb3N0cy8yMDExMDYyMF9kb21haW5fbmFtZXNfd2l0aG91dF9kb3RzLz4gZnJv bSBWaXhpZSBmb3Igc29tZSBpbmZvcm1lZCBjb21tZW50YXJ5IG9uIHRoaXMgaXNzdWUuDQoNCkkn ZCBsaWtlIHRvIGhlYXIgdGhlIGF1dGhvcnMnIHRob3VnaHRzIG9uIHRoZXNlLiAgSSdtIG5vdCBz dXJlIHRoYXQgdGhpcyBkcmFmdCBuZWNlc3NhcmlseSBuZWVkcyBhbnkgc2lnbmlmaWNhbnQgY2hh bmdlcyAtIGl0IG1heSBvbmx5IHJlcXVpcmUgY2hhbmdlcyB0byBlbnN1cmUgdGhhdCBiYXJlIG5h bWVzIGFyZSBhbHNvIGNvbnNpZGVyZWQgYXMgcG90ZW50aWFsIEROUyBuYW1lcyBpbiB0aGVpciBv d24gcmlnaHQuDQoNCkknbSBhbHNvIGNvbnNpZGVyaW5nIHRha2luZyB1cCBWaXhpZSdzIGNoYWxs ZW5nZSBhbmQgd3JpdGluZyB1cCBhIGRyYWZ0IHRvIGZvcm1hbGx5IGRlcHJlY2F0ZSBzZWFyY2gg c3VmZml4ZXMuDQoNCmtpbmQgcmVnYXJkcywNCg0KUmF5DQoNCg== From moore@network-heretics.com Wed Oct 19 04:23:44 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7753221F8B92; Wed, 19 Oct 2011 04:23:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.932 X-Spam-Level: X-Spam-Status: No, score=-3.932 tagged_above=-999 required=5 tests=[AWL=-0.334, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id icS9UX6rSuuL; Wed, 19 Oct 2011 04:23:43 -0700 (PDT) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 998B821F8B7A; Wed, 19 Oct 2011 04:23:43 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id A80E420A54; Wed, 19 Oct 2011 07:23:42 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute6.internal (MEProxy); Wed, 19 Oct 2011 07:23:42 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; s=smtpout; bh=wS7 mQwdhJMKRXy153rWKRoM7znE=; b=DWHItNfRGYj94ScbMWss3zAcdbVdyYmR47W XdQtqq/+0rSRaQtIS0W9wpXzZyrY9WdwfzzHH1u2orr+T3ceDuZIaq0CJXujRBAF qaklVTxD7VqJetmbRq2uwSh65JnMVJbuBrihWihm1ePSggU1fTtVERNf637YFkHQ DpuUs5aY= X-Sasl-enc: BGjFQ+RkS6H51ygInKuqC5DpPke97MZ+nh/sc/cEx3Lk 1319023422 Received: from [192.168.1.16] (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id E0DF2407BD6; Wed, 19 Oct 2011 07:23:40 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-52--733704108 From: Keith Moore In-Reply-To: <121DABD1-65E8-4275-8471-9FA38D25C434@nominet.org.uk> Date: Wed, 19 Oct 2011 07:23:15 -0400 Message-Id: <8EFC868A-8796-4013-BB07-F3D33F33C552@network-heretics.com> References: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> <121DABD1-65E8-4275-8471-9FA38D25C434@nominet.org.uk> To: Ray Bellis X-Mailer: Apple Mail (2.1084) Cc: "" , "" , "" , "" , "" , "" , "" Subject: Re: [mif] [dnsext] 2nd Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 11:23:44 -0000 --Apple-Mail-52--733704108 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 19, 2011, at 6:39 AM, Ray Bellis wrote: >=20 > When new gTLDs are introduced it is likely for brand-name gTLDs that = they will wish to use bare names in the DNS (i.e. a single label = hostname) for their primary web sites. I don't see why IETF should give a flying *#&(*#$ what the owners of = brand-name gTLDs want. Brand-name gTLDs are an exceedingly stupid = idea, and treating single label names as anything other than local = abbreviations flies in the face of 25+ years of practice. =20 The best thing that IETF could do is to make sure that use of = single-label gTLDs is so unreliable that no megacorporation would dare = use them. Keith --Apple-Mail-52--733704108 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

When new gTLDs = are introduced it is likely for brand-name gTLDs that they will wish to = use bare names in the DNS (i.e. a single label hostname) for their = primary web sites.

I don't see = why IETF should give a flying *#&(*#$ what the owners of brand-name = gTLDs want.   Brand-name gTLDs are an exceedingly stupid idea, and = treating single label names as anything other than local abbreviations = flies in the face of 25+ years of practice. =   

The best thing that IETF could do = is to make sure that use of single-label gTLDs is so unreliable that no = megacorporation would dare use = them.

Keith

= --Apple-Mail-52--733704108-- From ajs@anvilwalrusden.com Wed Oct 19 06:26:40 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 973A721F8BE8; Wed, 19 Oct 2011 06:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.114 X-Spam-Level: X-Spam-Status: No, score=-2.114 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3XFgoPb0hKR; Wed, 19 Oct 2011 06:26:40 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 234FD21F8A95; Wed, 19 Oct 2011 06:26:40 -0700 (PDT) Received: from shinkuro.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 0B6E31ECB428; Wed, 19 Oct 2011 13:26:25 +0000 (UTC) Date: Wed, 19 Oct 2011 09:26:34 -0400 From: Andrew Sullivan To: mif@ietf.org, dnsext@ietf.org, dnsop@ietf.org, dhcwg@ietf.org Message-ID: <20111019132633.GB18523@shinkuro.com> References: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> <121DABD1-65E8-4275-8471-9FA38D25C434@nominet.org.uk> <8EFC868A-8796-4013-BB07-F3D33F33C552@network-heretics.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8EFC868A-8796-4013-BB07-F3D33F33C552@network-heretics.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [mif] bare names (was: [dnsext] 2nd Last Call for MIF DNS server selection document) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mif@ietf.org List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 13:26:40 -0000 Note: I trimmed the cc:s down to just the lists, but if we're going to pursue this dicussion we probably ought to follow up in mif, since that's where the draft comes from. That's why I set reply-to. Also, I sent this first from the wrong address, so apologies to those who see it twice. On Wed, Oct 19, 2011 at 07:23:15AM -0400, Keith Moore wrote: > I don't see why IETF should give a flying *#&(*#$ what the owners of > brand-name gTLDs want. Brand-name gTLDs are an exceedingly stupid > idea, and treating single label names as anything other than local > abbreviations flies in the face of 25+ years of practice. If you said, "25+ years of practice illustrating how broken the search-path mechanism is," I'd agree with you. I think it is largely true that single-label domain names are going to fail to work in all sorts of amusing ways that will surprise gullible people who forked over a pile of cash for the privilege of registering them. Nevertheless, the search path mechanism has never worked very well and is notoriously unreliable in the face of split-brain DNS. Still, too many people continue to rely on the search path for this document to be the place to deprecate it. But I agree with Ray (and apparently Paul Vixie) that the mechanism ought to go away. Now that Ray has mentioned it, however, perhaps a sentence along these lines in the second paragraph of 4.6 would be useful: It should be noted that the DNS search list mechanism may cause surprising results when used with more than one network at a time. That addresses the other point that Ray was making: search list-style bare names are often broken if you're not on the right network, and the point of this draft is precisely that you're _not_ on only one network, so it isn't clear what "the right network" is. > The best thing that IETF could do is to make sure that use of > single-label gTLDs is so unreliable that no megacorporation would > dare use them. And clearly that will work, because the IETF has a long record of success of standing before the tide and telling it to stop. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From moore@network-heretics.com Wed Oct 19 06:48:51 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18DE321F8B4E; Wed, 19 Oct 2011 06:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNFuZRJLHH-g; Wed, 19 Oct 2011 06:48:50 -0700 (PDT) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 22A4421F8B5C; Wed, 19 Oct 2011 06:48:50 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id B4F5420E58; Wed, 19 Oct 2011 09:48:49 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute3.internal (MEProxy); Wed, 19 Oct 2011 09:48:49 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=9t0F312M2ZXsV+O5xsM0MIAhPUU=; b=uP 0PZPHXPQoD9Bd8L6H5ZvS2sdmUhJiIIC2WPD8hVXXx99aykrh2i7b4oFW7+55p3e RpLMKEA+OoC1IkFf98XPpEPBD0luhyXcKSywJd6YWNyj9oa/ajz0IEkZsAQ6AW+Y k8KcxkpFR86/utCNVrTuC3tez7LaW3By1iUKZIHwk= X-Sasl-enc: uomQefLftWEkbnnMVAiBfZec6wUFII8JnV/hVNkHhdy4 1319032129 Received: from [192.168.1.16] (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 76B1F407CA3; Wed, 19 Oct 2011 09:48:48 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <20111019132633.GB18523@shinkuro.com> Date: Wed, 19 Oct 2011 09:48:23 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <79350865-2ED5-4B12-BA36-B53550CB01F7@network-heretics.com> References: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> <121DABD1-65E8-4275-8471-9FA38D25C434@nominet.org.uk> <8EFC868A-8796-4013-BB07-F3D33F33C552@network-heretics.com> <20111019132633.GB18523@shinkuro.com> To: mif@ietf.org X-Mailer: Apple Mail (2.1084) Cc: dhcwg@ietf.org, dnsop@ietf.org, dnsext@ietf.org Subject: Re: [mif] bare names (was: [dnsext] 2nd Last Call for MIF DNS server selection document) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 13:48:51 -0000 On Oct 19, 2011, at 9:26 AM, Andrew Sullivan wrote: > Note: I trimmed the cc:s down to just the lists, but if we're going to > pursue this dicussion we probably ought to follow up in mif, since > that's where the draft comes from. That's why I set reply-to. Also, > I sent this first from the wrong address, so apologies to those who > see it twice. >=20 > On Wed, Oct 19, 2011 at 07:23:15AM -0400, Keith Moore wrote: >=20 >> I don't see why IETF should give a flying *#&(*#$ what the owners of >> brand-name gTLDs want. Brand-name gTLDs are an exceedingly stupid >> idea, and treating single label names as anything other than local >> abbreviations flies in the face of 25+ years of practice. >=20 > If you said, "25+ years of practice illustrating how broken the > search-path mechanism is," I'd agree with you. I agree that search paths are somewhat broken. What's not broken is = the idea of using single-label names as local names. =20 > I think it is largely true that single-label domain names are going to > fail to work in all sorts of amusing ways that will surprise gullible > people who forked over a pile of cash for the privilege of registering > them. Nevertheless, the search path mechanism has never worked very > well and is notoriously unreliable in the face of split-brain DNS. split-brain DNS is an abomination that should be eradicated from the = planet. > Still, too many people continue to rely on the search path for this > document to be the place to deprecate it. But I agree with Ray (and > apparently Paul Vixie) that the mechanism ought to go away. I don't think it should necessarily go away. But perhaps it needs to be = better defined, and/or more advice needs to be given to applications = about how to deal with single-label names. > Now that Ray has mentioned it, however, perhaps a sentence along these > lines in the second paragraph of 4.6 would be useful: >=20 > It should be noted that the DNS search list mechanism may cause > surprising results when used with more than one network at a time. >=20 > That addresses the other point that Ray was making: search list-style > bare names are often broken if you're not on the right network, and > the point of this draft is precisely that you're _not_ on only one > network, so it isn't clear what "the right network" is. and sometimes, single-label names are set up to work correctly on = multiple networks - the salient point being that the meaning of the name = might be inherently context-sensitive. >> The best thing that IETF could do is to make sure that use of >> single-label gTLDs is so unreliable that no megacorporation would >> dare use them. >=20 > And clearly that will work, because the IETF has a long record of > success of standing before the tide and telling it to stop. this isn't a tide. this is a small number of parties bent on abuse of = the Internet. they deserve to fail. Keith From ajs@anvilwalrusden.com Wed Oct 19 07:27:19 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE2AB21F8BA7 for ; Wed, 19 Oct 2011 07:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.405 X-Spam-Level: X-Spam-Status: No, score=-2.405 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KvGsxTfkBELT for ; Wed, 19 Oct 2011 07:27:19 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 35FB521F8B84 for ; Wed, 19 Oct 2011 07:27:19 -0700 (PDT) Received: from shinkuro.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id D3FE71ECB428; Wed, 19 Oct 2011 14:26:18 +0000 (UTC) Date: Wed, 19 Oct 2011 10:26:27 -0400 From: Andrew Sullivan To: mif@ietf.org Message-ID: <20111019142626.GC18523@shinkuro.com> References: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> <121DABD1-65E8-4275-8471-9FA38D25C434@nominet.org.uk> <8EFC868A-8796-4013-BB07-F3D33F33C552@network-heretics.com> <20111019132633.GB18523@shinkuro.com> <79350865-2ED5-4B12-BA36-B53550CB01F7@network-heretics.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <79350865-2ED5-4B12-BA36-B53550CB01F7@network-heretics.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Keith Moore Subject: Re: [mif] bare names (was: [dnsext] 2nd Last Call for MIF DNS server selection document) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 14:27:19 -0000 On Wed, Oct 19, 2011 at 09:48:23AM -0400, Keith Moore wrote: > I agree that search paths are somewhat broken. What's not broken > is the idea of using single-label names as local names. [. . .] > > split-brain DNS is an abomination that should be eradicated from the planet. By "local names", do you just mean "globally-accessible names that are of special interest to me?" (If not, then unless you are arguing that everyone ought to be configuring /etc/hosts themselves, I don't see how the above two claims are consistent. The way you get single-label names as local names (at least as deployed) is to use the seach path mechanism and look things up in the "local" DNS. By definition, that means that split-brain DNS is in action: the DNS namespace is not, in that case, global.) In any case, we do not have the option of eradicating split-brain DNS any more than we can un-know how to split atoms and make bombs. Once such an innovation exits, we have to figure out how to cope with it to the extent it can be coped with. I too think that split-brain DNS is a mistake, and I think most of the things people are doing with it are foolish and stupid, but they are doing it. We can either make the network work as well as it can in the presence of such systems, or live with the inventions that such innovators come up with in an attempt to bandage the foot they just shot. > and sometimes, single-label names are set up to work correctly on > multiple networks - the salient point being that the meaning of the > name might be inherently context-sensitive. Right, but not by virtue of it being single-label. You can look up single labels in the DNS just fine. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From moore@network-heretics.com Wed Oct 19 07:46:39 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4C7C21F8B14 for ; Wed, 19 Oct 2011 07:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.844 X-Spam-Level: X-Spam-Status: No, score=-3.844 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6UpVdaNd+EN for ; Wed, 19 Oct 2011 07:46:39 -0700 (PDT) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 023A721F8B09 for ; Wed, 19 Oct 2011 07:46:38 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id B538E20DFB; Wed, 19 Oct 2011 10:45:05 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 19 Oct 2011 10:45:05 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=BK58V2LFx7wBn6qJPTW9xLcDizs=; b=JA munW8LTUSENrCIwcD+K+vrvdKck8+D5g5N7y63Cm41lnkgF7h2Lwt4h1Mj1qdMZF RhFAITWxBVVYzKr4BTP7gHpb9TjcrEZoJP5hJXRX2Shk1xjxFu5RsIlvZ0u0kedB krh5cRLvxcPLjwC8uPE6zeBTUrHmyY459lrXyH8v8= X-Sasl-enc: 6+TnX1Q/z4UjKt0tUz0cjxaPK5mGOh/nRn3qsTiS2GGd 1319035505 Received: from [192.168.1.16] (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id BF382407D0A; Wed, 19 Oct 2011 10:45:04 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <20111019142626.GC18523@shinkuro.com> Date: Wed, 19 Oct 2011 10:44:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5302EE55-5EF8-4C9C-9CF5-F7008A900374@network-heretics.com> References: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> <121DABD1-65E8-4275-8471-9FA38D25C434@nominet.org.uk> <8EFC868A-8796-4013-BB07-F3D33F33C552@network-heretics.com> <20111019132633.GB18523@shinkuro.com> <79350865-2ED5-4B12-BA36-B53550CB01F7@network-heretics.com> <20111019142626.GC18523@shinkuro.com> To: Andrew Sullivan X-Mailer: Apple Mail (2.1084) Cc: mif@ietf.org Subject: Re: [mif] bare names (was: [dnsext] 2nd Last Call for MIF DNS server selection document) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 14:46:39 -0000 On Oct 19, 2011, at 10:26 AM, Andrew Sullivan wrote: > On Wed, Oct 19, 2011 at 09:48:23AM -0400, Keith Moore wrote: >=20 >> I agree that search paths are somewhat broken. What's not broken >> is the idea of using single-label names as local names. >=20 > [. . .] >=20 >>=20 >> split-brain DNS is an abomination that should be eradicated from the = planet. >=20 > By "local names", do you just mean "globally-accessible names that are > of special interest to me?" No, I'm saying that there is a need for a naming convention that allows = names with local meaning (however the meaning is determined) to be = distinguished from DNS names. And longstanding practice is to use = single-label names for this. > (If not, then unless you are arguing that > everyone ought to be configuring /etc/hosts themselves, I don't see > how the above two claims are consistent. The way you get single-label > names as local names (at least as deployed) is to use the seach path > mechanism and look things up in the "local" DNS. By definition, that > means that split-brain DNS is in action: the DNS namespace is not, in > that case, global.) There are several different mechanisms in common use by which = single-label names are resolved. DNS search path is only one such = mechanism. > In any case, we do not have the option of eradicating split-brain DNS > any more than we can un-know how to split atoms and make bombs. Once > such an innovation exits, we have to figure out how to cope with it to > the extent it can be coped with. I too think that split-brain DNS is > a mistake, and I think most of the things people are doing with it are > foolish and stupid, but they are doing it. We can either make the > network work as well as it can in the presence of such systems, or > live with the inventions that such innovators come up with in an > attempt to bandage the foot they just shot.=20 Sometimes the thing to do is not to try to accommodate every mistake = that people make, but to clearly set a path forward that addresses = people's problems in a better way. >> and sometimes, single-label names are set up to work correctly on >> multiple networks - the salient point being that the meaning of the >> name might be inherently context-sensitive. >=20 > Right, but not by virtue of it being single-label. You can look up > single labels in the DNS just fine. Yes, technically speaking, the DNS protocol can be used to look up = single-label names at the root. But because single label names existed = before DNS, and also because single label names haven't been used with = DNS to date, longstanding practice is to treat single label names = differently than names with dots in them. Keith From Ted.Lemon@nominum.com Wed Oct 19 09:06:46 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03B7A21F8C4E; Wed, 19 Oct 2011 09:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.722 X-Spam-Level: X-Spam-Status: No, score=-105.722 tagged_above=-999 required=5 tests=[AWL=-0.876, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f927hEfWBLbG; Wed, 19 Oct 2011 09:06:45 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id 5883621F8C4C; Wed, 19 Oct 2011 09:06:44 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP; Wed, 19 Oct 2011 09:06:44 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 561EF1B8319; Wed, 19 Oct 2011 09:06:43 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 47918190065; Wed, 19 Oct 2011 09:06:43 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.01.0323.003; Wed, 19 Oct 2011 09:06:43 -0700 From: Ted Lemon To: " " Thread-Topic: [dhcwg] [mif] 2nd Last Call for MIF DNS server selection document Thread-Index: AQHMjipiaz0g2rqs70G2ngGlfgipv5WESzGA Date: Wed, 19 Oct 2011 16:06:42 +0000 Message-ID: <8B37A60F-0C55-4543-9ADB-2BA5A659B212@nominum.com> References: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="gb2312" Content-ID: <528A81F214D8144FAB5EFE644EC273C3@nominum.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "" , "dnsop@ietf.org WG" , dnsext List , "pk@isoc.de" , DHC WG , "sa.morris7@googlemail.com" , Hui Deng Subject: Re: [mif] [dhcwg] 2nd Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 16:06:46 -0000 VGhlIERIQ1AgY2hhbmdlcyBsb29rIGdvb2QuICBZb3UgY2FuIGdldCBtdWx0aXBsZSBzZWxlY3Rp b24gdHVwbGVzIGluIERIQ1B2NCBpZiB5b3Ugd2FudCwgYnV0IHlvdSBzZWVtIHRvIGhhdmUgZGVj aWRlZCBpdHMgbm90IGltcG9ydGFudCwgd2hpY2ggaXMgZmluZSBieSBtZS4gICBMZXQgbWUga25v dyBpZiB5b3Ugd2FudCBtZSB0byBleHBsYWluIGhvdyB0byBkbyB0aGF0Lg0KDQpIb3dldmVyLCBJ IHJlcmVhZCB0aGUgdGV4dCBvbiBzZXJ2ZXIgc2VsZWN0aW9uLCBhbmQgaXQgc3RpbGwgaGFzIGEg c2VyaW91cyBhbmQgZWFzaWx5IGV4cGxvaXRlZCBzZWN1cml0eSBmbGF3LiAgIEluIG9yZGVyIGZv ciBETlNTRUMgdmFsaWRhdGlvbiB0byBzYXZlIHlvdSBmcm9tIGFuIGF0dGFjaywgaXQgaGFzIHRv IGJlIHRoZSBjYXNlIHRoYXQgeW91IGxvb2sgdGhlIG5hbWUgdXAgb24gZXZlcnkgcG9zc2libGUg bmFtZSBzZXJ2ZXIgdG8gc2VlIGlmIGFueSBjbGFpbSBpdCdzIGluIGEgc2lnbmVkIHpvbmUuICAg SWYgb25lIGRvZXMsIGl0IGhhcyB0byBiZSB2YWxpZGF0ZWQuICAgUmlnaHQgbm93IGl0IGxvb2tz IGxpa2UgaWYgdGhlICJ0cnVzdGVkIiBzZXJ2ZXIgZG9lc24ndCBzaWduIHRoZSB6b25lLCB0aGUg RE5TU0VDIHZhbGlkYXRpb24gd2lsbCBuZXZlciBoYXBwZW4uICAgV2UgZGVhbHQgd2l0aCB0aGlz IGJ5IHRydXN0aW5nIHNvbWUgbmV0d29ya3MgbW9yZSB0aGFuIG90aGVycywgYW5kIHRoYXQgZWxp bWluYXRlcyBhIGxvdCBvZiB0aGUgcmlzay4NCg0KRm9yIGV4YW1wbGUsIGluIHRoZSBjYXNlIG9m IGEgaG90ZWwgbmV0IHdlJ3JlIG9rYXksIGJlY2F1c2UgaXQgd2lsbCBiZSBsZXNzIHRydXN0ZWQg dGhhbiB0aGUgM0cgbmV0d29yay4gICBUaGUgY2FzZSBJIGFtIG1vc3QgY29uY2VybmVkIHdpdGgg aXMgd2hlbiB5b3UgVlBOIHRvIGEgc2l0ZSB0aGF0IGlzIG5vdCB0cnVzdGVkOiB0aGUgZGVmYXVs dCBiZWhhdmlvciB3aWxsIGJlIHRvIHByZWZlciB0aGUgVlBOIGxpbmssIGJlY2F1c2Ugd2UgcHJl c3VtZSBpdCBpcyBtb3JlIHRydXN0d29ydGh5LiAgQSBjb25zdWx0YW50IHdobyBWUE5zIHRvIG11 bHRpcGxlIGNvcnBvcmF0ZSBzaXRlcyBjb3VsZCBiZSBzcG9vZmVkIGhlcmUgdGhvdWdoLCBhcyBj b3VsZCBhIHVzZXIgb2YgYSBmaXJld2FsbCBieXBhc3MgVlBOLg0KDQpVbmZvcnR1bmF0ZWx5LCBJ IGRvbid0IGtub3cgb2YgYSB3YXkgdG8gZml4IHRoaXMgdGhhdCBkb2Vzbid0IGZpcmUgdXAgYm90 aCByYWRpb3MgZm9yIGV2ZXJ5IHF1ZXJ5LiAgIExlYXZpbmcgdGhpcyBvZmYgYnkgZGVmYXVsdCBp cyBwcm9iYWJseSB0aGUgYmVzdCB3ZSBjYW4gZG8sIGJ1dCBpdCBtaWdodCBiZSBnb29kIHRvIGFk ZCBtb3JlIHRleHQgdG8gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gZGVzY3Jp YmluZyBzcGVjaWZpYyBleHBsb2l0IHNjZW5hcmlvcy4gICBUaGUgdGV4dCBpbiAxMC4xIGFuZCAx MC4yIGRvZXNuJ3QgYWRkcmVzcyB0aGlzIHBhcnRpY3VsYXIgYXR0YWNrIHZlY3Rvci4NCg0KSSB3 b3VsZCBwcm9wb3NlIGFkZGluZyBhIHJlcXVpcmVtZW50IHRoYXQgdGhlcmUgYmUgYSBtb2RlLCBv ZmYgYnkgZGVmYXVsdCwgZW5hYmxlZCBieSBVSSwgaW4gd2hpY2ggdGhlIHJlc29sdmVyIGp1c3Qg ZmlyZXMgdXAgYm90aCByYWRpb3MsIGJhdHRlcnkgYmUgZGFtbmVkLCBidXQgSSBhbSBub3Qgc3Vy ZSBhbnlvbmUgd291bGQgdXNlIGl0LCBiZWNhdXNlIGl0IHdvdWxkIGJlIGRpZmZpY3VsdCB0byBl eHBsYWluIHdoeSBhbmQgd2hlbiB0aGV5IHNob3VsZC4NCg0KU28gcHJhY3RpY2FsbHkgc3BlYWtp bmcsIEkgYW0ganVzdCBwcm9wb3NpbmcgYSB0d2VhayB0byB0aGUgc2VjdXJpdHkgY29uc2lkZXJh dGlvbnMuICAgSSB3aWxsIHNlbmQgdGV4dCBpZiB5b3UgZG9uJ3Qgb2JqZWN0LiAgIFNvcnJ5IGZv ciB0aGUgbGF0ZSByZXZpZXcu From mrw@lilacglade.org Wed Oct 19 09:07:28 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9843E21F8CBD; Wed, 19 Oct 2011 09:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Z9YmLp0vtl4; Wed, 19 Oct 2011 09:07:28 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 1B52121F8CA0; Wed, 19 Oct 2011 09:07:28 -0700 (PDT) Received: from [10.36.0.36] (pool-108-7-232-64.bstnma.fios.verizon.net [108.7.232.64]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.suchdamage.org (Postfix) with ESMTPSA id 077DF20188; Wed, 19 Oct 2011 12:08:41 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Margaret Wasserman In-Reply-To: <79350865-2ED5-4B12-BA36-B53550CB01F7@network-heretics.com> Date: Wed, 19 Oct 2011 12:07:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <70C7ABD5-DF78-4F35-89DE-152EB1D21954@lilacglade.org> References: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> <121DABD1-65E8-4275-8471-9FA38D25C434@nominet.org.uk> <8EFC868A-8796-4013-BB07-F3D33F33C552@network-heretics.com> <20111019132633.GB18523@shinkuro.com> <79350865-2ED5-4B12-BA36-B53550CB01F7@network-heretics.com> To: Keith Moore X-Mailer: Apple Mail (2.1084) Cc: dhcwg@ietf.org, dnsop@ietf.org, mif@ietf.org, dnsext@ietf.org Subject: Re: [mif] bare names (was: [dnsext] 2nd Last Call for MIF DNS server selection document) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 16:07:28 -0000 Hi Keith, On Oct 19, 2011, at 9:48 AM, Keith Moore wrote: > split-brain DNS is an abomination that should be eradicated from the = planet. Split DNS exists and is in wide-spread use, and that is just a fact. We = don't have the power to eradicate it, nor do we currently have a better = solution for the types of things that people use split DNS for. Margaret From Ted.Lemon@nominum.com Wed Oct 19 09:16:10 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A84221F8AD6 for ; Wed, 19 Oct 2011 09:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.489 X-Spam-Level: X-Spam-Status: No, score=-106.489 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3k2Bodq0XpuI for ; Wed, 19 Oct 2011 09:16:10 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id AF14521F8AD2 for ; Wed, 19 Oct 2011 09:16:09 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP; Wed, 19 Oct 2011 09:16:09 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 5B9441B830F for ; Wed, 19 Oct 2011 09:15:14 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 54269190065; Wed, 19 Oct 2011 09:15:14 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.01.0323.003; Wed, 19 Oct 2011 09:15:14 -0700 From: Ted Lemon To: Keith Moore Thread-Topic: [mif] bare names (was: [dnsext] 2nd Last Call for MIF DNS server selection document) Thread-Index: AQHMjm3rbOmsTKztt0GFP7I6u0RcMZWETQyA Date: Wed, 19 Oct 2011 16:15:13 +0000 Message-ID: <2328BDA8-57EA-4A36-90E7-B11B2FA3248C@nominum.com> References: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> <121DABD1-65E8-4275-8471-9FA38D25C434@nominet.org.uk> <8EFC868A-8796-4013-BB07-F3D33F33C552@network-heretics.com> <20111019132633.GB18523@shinkuro.com> <79350865-2ED5-4B12-BA36-B53550CB01F7@network-heretics.com> <20111019142626.GC18523@shinkuro.com> <5302EE55-5EF8-4C9C-9CF5-F7008A900374@network-heretics.com> In-Reply-To: <5302EE55-5EF8-4C9C-9CF5-F7008A900374@network-heretics.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_2328BDA857EA4A3690E7B11B2FA3248Cnominumcom_" MIME-Version: 1.0 Cc: "" Subject: Re: [mif] bare names (was: [dnsext] 2nd Last Call for MIF DNS server selection document) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 16:16:10 -0000 --_000_2328BDA857EA4A3690E7B11B2FA3248Cnominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Oct 19, 2011, at 10:44 AM, Keith Moore wrote: No, I'm saying that there is a need for a naming convention that allows nam= es with local meaning (however the meaning is determined) to be distinguish= ed from DNS names. And longstanding practice is to use single-label names f= or this. You mean like "foo.local"? --_000_2328BDA857EA4A3690E7B11B2FA3248Cnominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <6DE9123E2E61C740ACF284E38FE867AB@nominum.com> Content-Transfer-Encoding: quoted-printable
On Oct 19, 2011, at 10:44 AM, Keith Moore wrote:
No, I'm saying that there is a need for a naming convention that allows names = with local meaning (however the meaning is determined) to be distinguished = from DNS names. And longstanding practice is to use single-label names for = this.

You mean like "foo.local"?

--_000_2328BDA857EA4A3690E7B11B2FA3248Cnominumcom_-- From moore@network-heretics.com Wed Oct 19 10:53:06 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 495FE11E80A5 for ; Wed, 19 Oct 2011 10:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.823 X-Spam-Level: X-Spam-Status: No, score=-3.823 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2MUxOtppOlnR for ; Wed, 19 Oct 2011 10:53:01 -0700 (PDT) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id DF4F521F8B8A for ; Wed, 19 Oct 2011 10:52:53 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id C35D2205DE; Wed, 19 Oct 2011 13:52:48 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute6.internal (MEProxy); Wed, 19 Oct 2011 13:52:48 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; s=smtpout; bh=z+f 8zUj0Hhj0St4wlgOpC5Q0uXs=; b=VDlhk90eTifS3KAbiEju0F5vU5WU8feJr3R MuCQaIO8ZU3ZgqnDsjqIZ2td41XSf6N9PPuFNCL9VXf8CUKKs+ubY9Ep7rdr1azV PADL9nD1zqqvA+ANnToqjGBMkaXUciCycwtU9zXQTIedGqMZ5MbKguA+mLYmtdGb Szk//+qQ= X-Sasl-enc: k7mdGh7MWpbcuUNpt7L+tCnGCQVbd44t8EK78HKsyCPu 1319046767 Received: from [192.168.1.16] (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 17BF440293C; Wed, 19 Oct 2011 13:52:45 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-55--710360817 From: Keith Moore In-Reply-To: <2328BDA8-57EA-4A36-90E7-B11B2FA3248C@nominum.com> Date: Wed, 19 Oct 2011 13:52:19 -0400 Message-Id: <8C287338-5903-4B56-8EB3-2A76FAB1EA75@network-heretics.com> References: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> <121DABD1-65E8-4275-8471-9FA38D25C434@nominet.org.uk> <8EFC868A-8796-4013-BB07-F3D33F33C552@network-heretics.com> <20111019132633.GB18523@shinkuro.com> <79350865-2ED5-4B12-BA36-B53550CB01F7@network-heretics.com> <20111019142626.GC18523@shinkuro.com> <5302EE55-5EF8-4C9C-9CF5-F7008A900374@network-heretics.com> <2328BDA8-57EA-4A36-90E7-B11B2FA3248C@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1084) Cc: "" Subject: Re: [mif] bare names (was: [dnsext] 2nd Last Call for MIF DNS server selection document) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 17:53:06 -0000 --Apple-Mail-55--710360817 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 19, 2011, at 12:15 PM, Ted Lemon wrote: > On Oct 19, 2011, at 10:44 AM, Keith Moore wrote: >> No, I'm saying that there is a need for a naming convention that = allows names with local meaning (however the meaning is determined) to = be distinguished from DNS names. And longstanding practice is to use = single-label names for this. >=20 > You mean like "foo.local"? no. "foo.local" is a lousy idea because it looks to an application = exactly like a DNS name. --Apple-Mail-55--710360817 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On Oct 19, 2011, at 12:15 PM, Ted Lemon wrote:

On Oct 19, 2011, at 10:44 AM, Keith Moore wrote:
No, I'm saying that there is a need for a naming convention that allows names with local meaning (however the meaning is determined) to be distinguished from DNS names. And longstanding practice is to use single-label names for this.

You mean like "foo.local"?

no.  "foo.local" is a lousy idea because it looks to an application exactly like a DNS name.

--Apple-Mail-55--710360817-- From teemu.savolainen@nokia.com Wed Oct 19 10:58:59 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A95B311E808A; Wed, 19 Oct 2011 10:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.603 X-Spam-Level: X-Spam-Status: No, score=-2.603 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m1eaLz0w0hve; Wed, 19 Oct 2011 10:58:59 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id B9D4B21F8C69; Wed, 19 Oct 2011 10:58:58 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p9JHwV1b005940; Wed, 19 Oct 2011 20:58:55 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Oct 2011 20:58:40 +0300 Received: from 008-AM1MMR1-004.mgdnok.nokia.com (65.54.30.59) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 19 Oct 2011 19:58:40 +0200 Received: from 008-AM1MPN1-037.mgdnok.nokia.com ([169.254.7.8]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0339.002; Wed, 19 Oct 2011 19:58:39 +0200 From: To: Thread-Topic: [dhcwg] [mif] 2nd Last Call for MIF DNS server selection document Thread-Index: AQHMjnkxnryNBBR3OkaQECaRsTmFHJWD8JIg Date: Wed, 19 Oct 2011 17:58:39 +0000 Message-ID: <916CE6CF87173740BC8A2CE4430969620378363C@008-AM1MPN1-037.mgdnok.nokia.com> References: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> <8B37A60F-0C55-4543-9ADB-2BA5A659B212@nominum.com> In-Reply-To: <8B37A60F-0C55-4543-9ADB-2BA5A659B212@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Company Confidential;Project=None; x-titus-version: 3.3.8.1 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IvIhRytp+v9DPNmP/PIMrEEivHvrY5HV8ew2GaKnuV0phiGjieXUeaEr+yWBsV/pAsnh9Djy2SNxS7msksx6Z/OfCHRgEKpVgcONay+XxEo47aGlgukvaxzNwzA5o/3oGr9YnD+Nx0L9julOW/aDgk0kRd8q5+uGxXPDniEItQeQ733va8gB28zcacTy+Qv0p7MLPMeWb08YY03IqTg6hyvhN84V9KfPuJSEirxMClXnvaRX3+lusqXxPZI8ft7LsmccsCMBn7YMpmJQLMRmzFM= x-originating-ip: [10.162.93.230] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_02C9_01CC8EA1.DFA5DDD0" MIME-Version: 1.0 X-OriginalArrivalTime: 19 Oct 2011 17:58:40.0501 (UTC) FILETIME=[BBD6BA50:01CC8E88] X-Nokia-AV: Clean Cc: mif@ietf.org, dnsop@ietf.org, dnsext@ietf.org, pk@isoc.de, dhcwg@ietf.org, sa.morris7@googlemail.com, denghui02@hotmail.com Subject: Re: [mif] [dhcwg] 2nd Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 17:58:59 -0000 ------=_NextPart_000_02C9_01CC8EA1.DFA5DDD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Ted, thank you for comments. Please feel free to propose text - I love constructive text proposals:-) During following week would be nice, if possible, so that we can move forward with the draft before the next IETF. Now that you say it, we might state that not any VPN can be trusted by default (but VPN is an example here), but e.g. a VPN Configuration Profile could enable the setting for that particular VPN connection. If the trusted VPN then **cks you up, then, well, trusted parties sometimes do that.. Best regards, Teemu > -----Original Message----- > From: ext Ted Lemon [mailto:Ted.Lemon@nominum.com] > Sent: 19. lokakuuta 2011 19:07 > To: Savolainen Teemu (Nokia-CTO/Tampere) > Cc: Hui Deng; ; dnsext List; dnsop@ietf.org WG; DHC WG; > sa.morris7@googlemail.com; pk@isoc.de > Subject: Re: [dhcwg] [mif] 2nd Last Call for MIF DNS server selection > document > > The DHCP changes look good. You can get multiple selection tuples in > DHCPv4 if you want, but you seem to have decided its not important, which > is fine by me. Let me know if you want me to explain how to do that. > > However, I reread the text on server selection, and it still has a serious and > easily exploited security flaw. In order for DNSSEC validation to save you > from an attack, it has to be the case that you look the name up on every > possible name server to see if any claim it's in a signed zone. If one does, it > has to be validated. Right now it looks like if the "trusted" server doesn't > sign the zone, the DNSSEC validation will never happen. We dealt with this > by trusting some networks more than others, and that eliminates a lot of the > risk. > > For example, in the case of a hotel net we're okay, because it will be less > trusted than the 3G network. The case I am most concerned with is when > you VPN to a site that is not trusted: the default behavior will be to prefer > the VPN link, because we presume it is more trustworthy. A consultant who > VPNs to multiple corporate sites could be spoofed here though, as could a > user of a firewall bypass VPN. > > Unfortunately, I don't know of a way to fix this that doesn't fire up both > radios for every query. Leaving this off by default is probably the best we > can do, but it might be good to add more text to the security considerations > section describing specific exploit scenarios. The text in 10.1 and 10.2 > doesn't address this particular attack vector. > > I would propose adding a requirement that there be a mode, off by default, > enabled by UI, in which the resolver just fires up both radios, battery be > damned, but I am not sure anyone would use it, because it would be difficult > to explain why and when they should. > > So practically speaking, I am just proposing a tweak to the security > considerations. I will send text if you don't object. Sorry for the late > review. ------=_NextPart_000_02C9_01CC8EA1.DFA5DDD0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOuzCCAzYw ggIeoAMCAQICBDpVqdkwDQYJKoZIhvcNAQEFBQAwKTEOMAwGA1UEChMFTm9raWExFzAVBgNVBAMT Dk5va2lhICBSb290IENBMB4XDTAxMDEwNTExMDUwNVoXDTE2MDEwMjExMDUwNVowKTEOMAwGA1UE ChMFTm9raWExFzAVBgNVBAMTDk5va2lhICBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsrTy8gLmr4LYvp0khVUVHw7ascdl+Cjr+yI5MlZ6J/U6Qsvkiqthgqq8rPcLV0P1 92TfBr27VgKEeCaZe0icS1jC2spM/wRv3j2WxdkKxb9kDJtuCNJaRBqvi5vGTHB15nmEmKuL5f3i rAxeHqPjgS496oWcudzFT1e7Xrc/gWGFYd72+/ykIFXjWOMZv6QpxD8x1hLPyh2YVXRk9U7N7pvm RQNX29g4SCFJY2BBIa5JPlwIF8Nc9IePaC/E/2M4tGMtiOOZlm99EoL7N0hJZtFSvUwdCBud/viH 4DgsKGjNkNKi6pAHc9IaXB6tIykcoYp+L+oe/3+cuEJaCj1EKwIDAQABo2YwZDASBgNVHRMBAf8E CDAGAQH/AgEEMB0GA1UdDgQWBBSNjfefoQ0AITLvqe0iruA79NB9sDAfBgNVHSMEGDAWgBSNjfef oQ0AITLvqe0iruA79NB9sDAOBgNVHQ8BAf8EBAMCAYYwDQYJKoZIhvcNAQEFBQADggEBAIGEPql2 TALyKi/h1J+Mh5XolAtYppcSOLMtBkoA7ZovGBDNvl0VbZs8AAojJqkUoWBB+L6DKyl/jKhNfKcu rWRGRyj7pnbxrKLsI3gmWNWkyo2b60wJwe9fqPD5ZQy3oEiMit9l0Ba6il/k2GqYopUCNMa7mfeb E2LeBy5ChYMiCi97UQSJvAdzEYylTJw8Awc6AiM2Ve5N+XxsmKgNf/2A/5IJ3EZZ+wFRmkI4062A oNU302rqAt0HH88jzoUF4AfYHWl6HpYhGXFbcX44rHINyPmFBRxLYIFJ6ZWUr/mXpL/e6rqFtNWO kV6UoJND7OVZkbLh7F1+lcqXRU8TPBMwggOHMIICb6ADAgECAgRBtbHpMA0GCSqGSIb3DQEBBQUA MCkxDjAMBgNVBAoTBU5va2lhMRcwFQYDVQQDEw5Ob2tpYSAgUm9vdCBDQTAeFw0wNjAzMzAwOTU3 MTFaFw0xNjAxMDIxMTA1MDVaMDMxCzAJBgNVBAYTAkZJMQ4wDAYDVQQKEwVOb2tpYTEUMBIGA1UE AxMLTm9raWEgQkkgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDtFCg3QEjSCg6T IUxoWsNwELh8bBNiUQPCPmg8c2DHQYXWWCSCMb+S0Fvh1qqI1xt+XnzyFq+5eqzGzDj4UaBcG+d9 qxrCFly8sHyoPTryyPrR0EI2UUDWwfS6ojhqgwghRqo8G38TjFusyBtLub/5L6yvWYSOHD+JcB+q VM2fbkArPYK4Ydv8WG/DbHjGn0gKq0zwpVZKI/gCK/QALYvte02NXseqvY9/GOyLtjy3Z8erFv71 KKTq+gxI/7DK55pJf3PoD+kT4kyGm6EF9DTdK4ojMdar17uyX0IOZz/4vkkF0d+60nmnLX63FJPA jUyB0HUNJ32NXDo9UsM38aoNAgMBAAGjgawwgakwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAI MAYGBFUdIAAwDgYDVR0PAQH/BAQDAgGGMFQGA1UdIwRNMEuAFI2N95+hDQAhMu+p7SKu4Dv00H2w oS2kKzApMQ4wDAYDVQQKEwVOb2tpYTEXMBUGA1UEAxMOTm9raWEgIFJvb3QgQ0GCBDpVqdkwHQYD VR0OBBYEFKcksD7Fg+8EDlB2Sxgy58pW0Sy6MA0GCSqGSIb3DQEBBQUAA4IBAQAC3lEUplDlVNOT Pjz/XFezXx2bV2XbCFindhA3F815Egi55H6/cYezEjoP4QLNEGGl2I3aLvkn5A0T8I4pbiFPhIiu B/frbbGg6k6GjQLe/bFQ8F1mAOOR+GyneKZFPfzaRV0jiIR9QqnMXTf8RvKkCJyFj10MZVsLIy/Y uBkzeP3JhzDhUdtPfwmJN6ZbIhH5uR/2BwAGtgQknb8WX3I4wnhWtMUxB8XmayayYs8qWYeIiVkI FV+sLTkWUWVvvKUjyakBpbAW2vUP84DYsJ8TL1YefNjf/nIOByMcORLuV/1gPjyv00qJbcB59AA+ iXe3zIo8QNcgXG0uPQQFmrGDMIID5DCCAsygAwIBAgIQMH5apak8lEy6LmLlLsJy8TANBgkqhkiG 9w0BAQUFADAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJ IENBMB4XDTExMDkwNjA1NTIwNFoXDTE0MDkwNjA1NTIwNFowVjEOMAwGA1UECgwFTm9raWExDzAN BgNVBAsMBlBlb3BsZTEYMBYGCgmSJomT8ixkAQEMCDEwMDI0Njc2MRkwFwYDVQQDDBBTYXZvbGFp bmVuIFRlZW11MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAshEsmw6Yiz6XWX26oF+I s5fsfE1OfCjOelclmtqCiIgXND5klkNOBs2d4ZGzgD9mN+XnTZnOTh249c2WxPBugf12DCcDmBAJ gL+VuWUJVBTE5NRchm/O8nZnZsRFst+gAC9/Juykh4+EYewZ7QbpnlwW7hNpj8eH+rMr+OZHKzdp KTftgVjmuF4JJ/cPMQUjL8SuGj+zBW6IWPOZdqkEMtf7Pr8kkYbZsh0SgJ0ceRHZ7Uc06mB/y+C1 UnJPxehTTdu8tpCjdzXgBw/H2uuW1J3qdHbCfbuDILql8V8RiZKubcZLhdsD3Jvj8qK0DGWBJa6x p90q5p3pLE8LvAeCgQIDAQABo4HQMIHNMA4GA1UdDwEB/wQEAwIEMDAfBgNVHSMEGDAWgBSnJLA+ xYPvBA5QdksYMufKVtEsujAZBgNVHSAEEjAQMA4GDCsGAQQBXgExBgEHAzA5BgNVHR8EMjAwMC6g LKAqhihodHRwOi8vY3JsLm5va2lhLmNvbS9Ob2tpYSUyMEJJJTIwQ0EuY3JsMCUGA1UdEQQeMByB GnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBQTRzvZsgmQrAGCeuzdHTGAC6Jg UzANBgkqhkiG9w0BAQUFAAOCAQEACmPVsdi07pjK5gDa+W5JlE2C74kVVsB8alBqfioYeR5At2FG B7sua4Dz5H7TJMpZ1jYFeI+zjexD5f+beY2IlV15lMoWD+5e38QlLYjwfe2LAyvdzBKXW0e0U6Bt p78ft4gyVak1X+Db+ebR+FNHUOMNhm+yK3w9sy5ZQzBFusIx4OgxGvcZhyhmd9WjipSTalgPwgqV Ju2aPADCG++OEXmgEWRLsR4yNopkgK4ftVqrN5uUtLs83qdeXTRcNRiET1IOx5zmYFZ6q3gjKIx5 iyuxcDeYas93vVHUcaRRYpsoby5CHq7Z/j/TQhtqO/knWuxLFFiCUgdGKMKrRkg29DCCBAowggLy oAMCAQICEQCBvi+p+bA/dBtBtybwA6YYMA0GCSqGSIb3DQEBBQUAMDMxCzAJBgNVBAYTAkZJMQ4w DAYDVQQKEwVOb2tpYTEUMBIGA1UEAxMLTm9raWEgQkkgQ0EwHhcNMTEwOTA2MDU1MDM0WhcNMTMw OTA1MDU1MDM0WjBWMQ4wDAYDVQQKDAVOb2tpYTEPMA0GA1UECwwGUGVvcGxlMRgwFgYKCZImiZPy LGQBAQwIMTAwMjQ2NzYxGTAXBgNVBAMMEFNhdm9sYWluZW4gVGVlbXUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDFPmbRVwuo52v+h6xnQUqokAx2xsHjmPBniEkzgtgBNJsFi838ATEg 1zsx+VotoJg7hMijcrQfpTAgW6gpLGnlmw5QQswrNK1zleOHb4pA5JguU3WhVKFkAH/6/2EU2k/9 m8Pb/gwP55cYg80R6fRmbdsWKhseXF/1isW/rJcWLmIYDg/rXfo3ixqtT9MroAMiuoXnb0ij1L2d Jj64LDp3Ld8Jo0qZzk3Fj4apo8PBd8eAH6HloVBJkxQcwAnv561A+Xi1GHZ2mafRYJGO+1uBDwyd g/8ybEXXA4MKo8lPKjBebYBUFvz80DBA/Lq74UysXkG23BSulcG4xQSYGlyzAgMBAAGjgfUwgfIw HwYDVR0jBBgwFoAUpySwPsWD7wQOUHZLGDLnylbRLLowGQYDVR0gBBIwEDAOBgwrBgEEAV4BMQYB BgQwOQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5ub2tpYS5jb20vTm9raWElMjBCSSUyMENB LmNybDAjBgNVHSUEHDAaBggrBgEFBQcDAgYEVR0lAAYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgeA MCUGA1UdEQQeMByBGnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBTGhbTJF0EX iagjymQo6GIuSQeRVDANBgkqhkiG9w0BAQUFAAOCAQEAqai6TxZ/BlMHZIhJNPriBPXkQhUlBkGA buJZ5sVm1HIQhWN8elZKjjJdHi1qWEKhMg7yHjEMZsyV8XAZzK0UnOqkpUnt+jnVkNZ9O7/jRtyK f4WUtq5jErc8Hlv4bbGFRHk1T7AuLLE52r1lYOdmoibnQp03QtlDvHUNa68G7jvzThJhieB7U1xh vH3yy0ktaVnWEgAylqf9yIUFjnqau5R6cE1Xo57IYPk/KitX0YF+OigEI/bOQVMi+fze93ZsAOJv /z6g/NGemvUgl5YSdX0uPQK6kEHf/sp/nZyUWWQ7OjtVSqkq2YuYEueQFxTfafl+78GWqgm6W/Bl 32laYzGCAuswggLnAgEBMEgwMzELMAkGA1UEBhMCRkkxDjAMBgNVBAoTBU5va2lhMRQwEgYDVQQD EwtOb2tpYSBCSSBDQQIRAIG+L6n5sD90G0G3JvADphgwCQYFKw4DAhoFAKCCAXgwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTExMDE5MTc1ODM3WjAjBgkqhkiG9w0B CQQxFgQUzkUPv1FiwE7Y9M/CRmEpeIBC8uUwVgYJKwYBBAGCNxAEMUkwRzAzMQswCQYDVQQGEwJG STEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLx MFgGCyqGSIb3DQEJEAILMUmgRzAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNV BAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLxMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMA0GCSqGSIb3DQEBAQUABIIBADu3ApDBqYXUSFZ5+/kd KKtYpXtN3SOiGWOmITv91lXYNkU/vwkCkWslOK+c4U0jKUPtmkpqeMzJLqv6yR63K9CmvsKU34sS zBzxuTclX2FVTD1mz7JfBSjRU4Mx5cQFzYruLjARt5qaV0HYMlr4f91lVgI5yIDhLdZtX4RM/56V 7CZSL6iThhMSWdQFkq3nc1EcmzqM3e+8/kNuhR4J7PyEH4DRv6XdYxWiFKR6NwNqeZHOUYAVglPy MoMWeEdWpOUg8BAv6cYa1gejcOsy4GXdHqE7X+JIWsoaUD/nwGQNavFWTB4TMO2CwSOIR8vxwYHW +UpT+0P4DJtM4e/xMcMAAAAAAAA= ------=_NextPart_000_02C9_01CC8EA1.DFA5DDD0-- From Ted.Lemon@nominum.com Wed Oct 19 12:09:01 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EDE821F8C7F; Wed, 19 Oct 2011 12:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.51 X-Spam-Level: X-Spam-Status: No, score=-106.51 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkCwLvS9dVXd; Wed, 19 Oct 2011 12:09:00 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id E23CC21F8C7E; Wed, 19 Oct 2011 12:08:59 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP; Wed, 19 Oct 2011 12:09:00 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 15A031B8315; Wed, 19 Oct 2011 12:08:59 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 0F458190065; Wed, 19 Oct 2011 12:08:59 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.01.0323.003; Wed, 19 Oct 2011 12:08:59 -0700 From: Ted Lemon To: " " Thread-Topic: [dhcwg] [mif] 2nd Last Call for MIF DNS server selection document Thread-Index: AQHMjipiaz0g2rqs70G2ngGlfgipv5WESzGAgAAfSICAABOmAA== Date: Wed, 19 Oct 2011 19:08:58 +0000 Message-ID: References: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> <8B37A60F-0C55-4543-9ADB-2BA5A659B212@nominum.com> <916CE6CF87173740BC8A2CE4430969620378363C@008-AM1MPN1-037.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE4430969620378363C@008-AM1MPN1-037.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_D773D6AE500C407AB0B555A035E8B904nominumcom_" MIME-Version: 1.0 Cc: "" , "" , "" , "" , "" , "" , "" Subject: Re: [mif] [dhcwg] 2nd Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 19:09:01 -0000 --_000_D773D6AE500C407AB0B555A035E8B904nominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Oct 19, 2011, at 1:58 PM, > > wrote: Now that you say it, we might state that not any VPN can be trusted by default (but VPN is an example here), but e.g. a VPN Configuration Profile could enable the setting for that particular VPN connection. If the trusted VPN then **cks you up, then, well, trusted parties sometimes do that.. I suppose requiring the user to explicitly mark the VPN trusted would help. --_000_D773D6AE500C407AB0B555A035E8B904nominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On Oct 19, 2011, at 1:58 PM, <teemu.savolainen@nokia.com>
Now that you say it, we might state that not any VPN can be trusted by
default (but VPN is an example here), but e.g. a VPN Configuration Profile<= br> could enable the setting for that particular VPN connection. If the trusted=
VPN then **cks you up, then, well, trusted parties sometimes do that..

I suppose requiring the user to explicitly mark the VPN trusted would = help.

--_000_D773D6AE500C407AB0B555A035E8B904nominumcom_-- From brian.e.carpenter@gmail.com Wed Oct 19 13:37:18 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0C921F8B4F for ; Wed, 19 Oct 2011 13:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.554 X-Spam-Level: X-Spam-Status: No, score=-103.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJqgoUlYmc8C for ; Wed, 19 Oct 2011 13:37:17 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 8A18921F8A6C for ; Wed, 19 Oct 2011 13:37:17 -0700 (PDT) Received: by qyk31 with SMTP id 31so1961032qyk.10 for ; Wed, 19 Oct 2011 13:37:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=8l3vyF9y7bgboaYbiAo78b3jSgh/tk+AZKnn3uZ0EYU=; b=xcB/DFJbPjlj826y4EEB+XS7R0ErmKhqF6m5lWdwtZyEAosD7KCa3urBjfqcYJegCM QHw4O8QKOjShFMxl9kcsFK4n9+2AD/8lnNmTuHZPmV61LJfYnKMdqaShvG+zlm9J7OVr vKjDvm3gfdwH1LSRdOtxMADhoqDjtChJn4tOA= Received: by 10.229.67.39 with SMTP id p39mr1756312qci.283.1319056637109; Wed, 19 Oct 2011 13:37:17 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id z1sm8075659qao.1.2011.10.19.13.37.14 (version=SSLv3 cipher=OTHER); Wed, 19 Oct 2011 13:37:16 -0700 (PDT) Message-ID: <4E9F34F6.20503@gmail.com> Date: Thu, 20 Oct 2011 09:37:10 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Keith Moore References: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> <121DABD1-65E8-4275-8471-9FA38D25C434@nominet.org.uk> <8EFC868A-8796-4013-BB07-F3D33F33C552@network-heretics.com> <20111019132633.GB18523@shinkuro.com> <79350865-2ED5-4B12-BA36-B53550CB01F7@network-heretics.com> <20111019142626.GC18523@shinkuro.com> <5302EE55-5EF8-4C9C-9CF5-F7008A900374@network-heretics.com> <2328BDA8-57EA-4A36-90E7-B11B2FA3248C@nominum.com> <8C287338-5903-4B56-8EB3-2A76FAB1EA75@network-heretics.com> In-Reply-To: <8C287338-5903-4B56-8EB3-2A76FAB1EA75@network-heretics.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [mif] bare names X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 20:37:18 -0000 On 2011-10-20 06:52, Keith Moore wrote: > On Oct 19, 2011, at 12:15 PM, Ted Lemon wrote: > >> On Oct 19, 2011, at 10:44 AM, Keith Moore wrote: >>> No, I'm saying that there is a need for a naming convention that allows names with local meaning (however the meaning is determined) to be distinguished from DNS names. And longstanding practice is to use single-label names for this. >> You mean like "foo.local"? > > no. "foo.local" is a lousy idea because it looks to an application exactly like a DNS name. I have thought for some time that the way to fix that problem is to make sure that it *is* a DNS name. Face the fact that split-horizon DNS is a fact, as Margaret said. Then figure out how to deal with it. I suspect that defining .local. as the DNS equivalent of fc00::/7 would work much better than instructing the tide to retreat. This would be very useful for solving part of the 6renum problem, as well as some aspects of mif and homenet. Brian From brian.peter.dickson@gmail.com Wed Oct 19 11:34:21 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA9C11E80B2; Wed, 19 Oct 2011 11:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.496 X-Spam-Level: X-Spam-Status: No, score=-3.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZF0XDnuqAUBL; Wed, 19 Oct 2011 11:34:20 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4514111E80B3; Wed, 19 Oct 2011 11:34:19 -0700 (PDT) Received: by bkas6 with SMTP id s6so2854607bka.31 for ; Wed, 19 Oct 2011 11:34:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=09eh2298okK5eqGD2ReXW6CQ0OT/2xe2GF9wWKGpgiA=; b=aGOi0PIsGKCvZ1ljy7ufP9lxs0sdzt7jRVYPqXssZ81PZN2PLVanXoVbG1XXFtECBU hTYZAD9g2SHX3/pATQSCG+NszXA08wXrsbUfD2tkHfdNycoRyFbLe6V//4YwaZfYfxyq 4dZSXkAemadgYB7Kp8jN9AHDOc5QrWo5OvvH4= MIME-Version: 1.0 Received: by 10.223.63.75 with SMTP id a11mr12752210fai.9.1319049256645; Wed, 19 Oct 2011 11:34:16 -0700 (PDT) Received: by 10.223.16.78 with HTTP; Wed, 19 Oct 2011 11:34:16 -0700 (PDT) In-Reply-To: <916CE6CF87173740BC8A2CE4430969620378363C@008-AM1MPN1-037.mgdnok.nokia.com> References: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> <8B37A60F-0C55-4543-9ADB-2BA5A659B212@nominum.com> <916CE6CF87173740BC8A2CE4430969620378363C@008-AM1MPN1-037.mgdnok.nokia.com> Date: Wed, 19 Oct 2011 14:34:16 -0400 Message-ID: From: Brian Dickson To: teemu.savolainen@nokia.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 19 Oct 2011 16:47:35 -0700 Cc: mif@ietf.org, dnsop@ietf.org, dnsext@ietf.org, pk@isoc.de, dhcwg@ietf.org, denghui02@hotmail.com Subject: Re: [mif] [dnsext] [dhcwg] 2nd Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 18:34:21 -0000 I'm not sure where it would belong, exactly, but certainly between "best practices" and DNSSEC security concerns, is the basic tenet: The DNS is a unified namespace. This leads to a number of potential issues, which can largely be addressed by viewing the issues from the perspective of a unified name-space's root. And by providing lots of literal and explicit examples. E.g.: - It is recommended that use of private namespaces be restricted to subdomains of legitimately-assigned domains by the domain owner exclusively (e.g. ".private.example.com." and NOT ".private.") - It is recommended that unofficial namespaces be avoided where practical to do so (e.g. .local, .fake-domain, .TBD) - It is recommended that any and all domain names be anchored with a trailing "." when expressed in text form, regardless of scope (global/private, bare TLD or otherwise) to remove any possible ambiguity (e.g. ".example.com.", NOT ".example.com" which might suggest use of search lists) - It is recommended that inconsistent or conflicting namespace or contents be avoided (e.g. split DNS with same labels having different RVALUEs) (possibly handled by non-anchored names and search lists, which result in unambigous names upon expansion) - It is recommended that handling of restricting access to "private" namespaces be handled in a manner that does not induce look-up failures if the "wrong" nameserver is consulted first (e.g. ISP/global before VPN/private, have ".private.example.com." return something OTHER than NXDOMAIN, e.g. servfail or whatever anyone smarter than me suggests) - It is recommended that configured Trust Anchors (for private namespaces) and "learned" Trust Anchors (KSK or ZSK of securely delegated zones) be handled in a manner compatible with any usage of split DNS (so that signature validation is deterministic) - It is recommended that private namespaces underneath secure global namespaces be DNSSEC-protected with either a global learned Trust Anchor, or a configured Trust Anchor - It is recommended that private namespaces be DNSSEC-protected where practical to do so The above is just off the top of my head as possible text that could be used. Comments on style, content, etc., are more than welcome. Brian On Wed, Oct 19, 2011 at 1:58 PM, wrote: > Ted, thank you for comments. > > Please feel free to propose text - I love constructive text proposals:-) > During following week would be nice, if possible, so that we can move > forward with the draft before the next IETF. > > Now that you say it, we might state that not any VPN can be trusted by > default (but VPN is an example here), but e.g. a VPN Configuration Profil= e > could enable the setting for that particular VPN connection. If the trust= ed > VPN then **cks you up, then, well, trusted parties sometimes do that.. > > Best regards, > > =A0 =A0 =A0 =A0Teemu > >> -----Original Message----- >> From: ext Ted Lemon [mailto:Ted.Lemon@nominum.com] >> Sent: 19. lokakuuta 2011 19:07 >> To: Savolainen Teemu (Nokia-CTO/Tampere) >> Cc: Hui Deng; ; dnsext List; dnsop@ietf.org WG; DHC WG; >> sa.morris7@googlemail.com; pk@isoc.de >> Subject: Re: [dhcwg] [mif] 2nd Last Call for MIF DNS server selection >> document >> >> The DHCP changes look good. =A0You can get multiple selection tuples in >> DHCPv4 if you want, but you seem to have decided its not important, whic= h >> is fine by me. =A0 Let me know if you want me to explain how to do that. >> >> However, I reread the text on server selection, and it still has a serio= us > and >> easily exploited security flaw. =A0 In order for DNSSEC validation to sa= ve > you >> from an attack, it has to be the case that you look the name up on every >> possible name server to see if any claim it's in a signed zone. =A0 If o= ne > does, it >> has to be validated. =A0 Right now it looks like if the "trusted" server > doesn't >> sign the zone, the DNSSEC validation will never happen. =A0 We dealt wit= h > this >> by trusting some networks more than others, and that eliminates a lot of > the >> risk. >> >> For example, in the case of a hotel net we're okay, because it will be > less >> trusted than the 3G network. =A0 The case I am most concerned with is wh= en >> you VPN to a site that is not trusted: the default behavior will be to > prefer >> the VPN link, because we presume it is more trustworthy. =A0A consultant= who >> VPNs to multiple corporate sites could be spoofed here though, as could = a >> user of a firewall bypass VPN. >> >> Unfortunately, I don't know of a way to fix this that doesn't fire up bo= th >> radios for every query. =A0 Leaving this off by default is probably the = best > we >> can do, but it might be good to add more text to the security > considerations >> section describing specific exploit scenarios. =A0 The text in 10.1 and = 10.2 >> doesn't address this particular attack vector. >> >> I would propose adding a requirement that there be a mode, off by defaul= t, >> enabled by UI, in which the resolver just fires up both radios, battery = be >> damned, but I am not sure anyone would use it, because it would be > difficult >> to explain why and when they should. >> >> So practically speaking, I am just proposing a tweak to the security >> considerations. =A0 I will send text if you don't object. =A0 Sorry for = the > late >> review. > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > > From marka@isc.org Wed Oct 19 17:06:25 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 700B221F87D3; Wed, 19 Oct 2011 17:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ha1k4BVJkVTB; Wed, 19 Oct 2011 17:06:25 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id CFC8F21F87C9; Wed, 19 Oct 2011 17:06:24 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id C61E45F98E7; Thu, 20 Oct 2011 00:06:09 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 805CE216C6A; Thu, 20 Oct 2011 00:06:07 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id B961B159AF2F; Thu, 20 Oct 2011 11:06:05 +1100 (EST) To: Margaret Wasserman From: Mark Andrews References: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> <121DABD1-65E8-4275-8471-9FA38D25C434@nominet.org.uk> <8EFC868A-8796-4013-BB07-F3D33F33C552@network-heretics.com> <20111019132633.GB18523@shinkuro.com> <79350865-2ED5-4B12-BA36-B53550CB01F7@network-heretics.com> <70C7ABD5-DF78-4F35-89DE-152EB1D21954@lilacglade.org> In-reply-to: Your message of "Wed, 19 Oct 2011 12:07:27 EDT." <70C7ABD5-DF78-4F35-89DE-152EB1D21954@lilacglade.org> Date: Thu, 20 Oct 2011 11:06:05 +1100 Message-Id: <20111020000605.B961B159AF2F@drugs.dv.isc.org> X-Mailman-Approved-At: Wed, 19 Oct 2011 20:56:56 -0700 Cc: dhcwg@ietf.org, dnsop@ietf.org, mif@ietf.org, Keith Moore , dnsext@ietf.org Subject: Re: [mif] [dnsext] bare names (was: 2nd Last Call for MIF DNS server selection document) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 00:06:25 -0000 In message <70C7ABD5-DF78-4F35-89DE-152EB1D21954@lilacglade.org>, Margaret Wass erman writes: > > Hi Keith, > > On Oct 19, 2011, at 9:48 AM, Keith Moore wrote: > > split-brain DNS is an abomination that should be eradicated from the planet > . > > Split DNS exists and is in wide-spread use, and that is just a fact. We don' > t have the power to eradicate it, nor do we currently have a better solution > for the types of things that people use split DNS for. > > Margaret That said there is little technical need for split brain with IPv6 only networks. IPv4 networks and RFC 1918 addresses created a technical problem (ambigious address use) that split brain DNS addresses. Publishing ULA addresses on the public internet shouldn't cause problem. One could even publish link local addresses on the public internet if we added a globally unique differentiator for the link to the records. e.g. AAAA The domain would announced in RAs so that nodes on the link could correctly filter the responses. It would also allow getaddrinfo to fill in scope. 8 byte address records would have solved the RFC 1918 address issue. First 4 bytes are the A records and the next 4 are the public address of the NAT or 0.0.0.0. Resolvers would just filter out anything that wasn't to 0.0.0.0 or their public NAT address. One could have even used them to route throuh the NAT using LSR. > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From teemu.savolainen@nokia.com Wed Oct 19 22:44:29 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7700F11E8085 for ; Wed, 19 Oct 2011 22:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CBl0i3z9YxDk for ; Wed, 19 Oct 2011 22:44:28 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id B51DE11E807F for ; Wed, 19 Oct 2011 22:44:28 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p9K5iOct027577; Thu, 20 Oct 2011 08:44:27 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Oct 2011 08:44:20 +0300 Received: from 008-AM1MMR1-001.mgdnok.nokia.com (65.54.30.56) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 20 Oct 2011 07:44:19 +0200 Received: from 008-AM1MPN1-037.mgdnok.nokia.com ([169.254.7.8]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0339.002; Thu, 20 Oct 2011 07:44:14 +0200 From: To: Thread-Topic: How long domains and networks field is required for DHCPv4 DNS server select option Thread-Index: AQHMjur5NBeT3WUzF0GquxdFNFZq1w== Date: Thu, 20 Oct 2011 05:44:14 +0000 Message-ID: <916CE6CF87173740BC8A2CE44309696203783C97@008-AM1MPN1-037.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [88.115.224.28] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 20 Oct 2011 05:44:20.0156 (UTC) FILETIME=[503D5FC0:01CC8EEB] X-Nokia-AV: Clean Cc: Matt.Ryan@nominum.com Subject: [mif] How long domains and networks field is required for DHCPv4 DNS server select option X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 05:44:29 -0000 Hi Mif,=0A= =0A= Is it enough to have 246 octets to describe the domains and networks fields= in the case of DHCPv4, or do you want to have possibility for longer list = of domains? =0A= =0A= We are discussing at the DHC WG what would be the optimal format for the DH= CPv4 option, and the decisions depend on how much domains and networks info= rmation is needed in the case of DHCPv4. If we agree that 246 octets is eno= ugh, we can design far simpler DHCPv4 option than otherwise.=0A= =0A= I prefer the simpler way even though it is more limited in size, as I don't= really see need to go beyond that.=0A= =0A= Best regards,=0A= =0A= Teemu=0A= =0A= ________________________________________=0A= From: ext Matthew Ryan [Matt.Ryan@nominum.com]=0A= Sent: Thursday, October 20, 2011 1:45 AM=0A= To: Savolainen Teemu (Nokia-CTO/Tampere)=0A= Cc: dhcwg@ietf.org=0A= Subject: Re: [dhcwg] [mif] 2nd Last Call for MIF DNS server selection docum= ent=0A= =0A= On Oct 19, 2011, at 14:03 , wrote:=0A= =0A= > No, we decided against suboptions and concatenation as well - to just hav= e single option and strictly limit the lenght of the domains-field. If I re= call correctly, it was due DHCPv4 relays in some cases limiting the availab= le DHCPv4 message size.. That's why the latest version is changed in so man= y locations related to this issue.=0A= > Ok on alignment issue.=0A= >=0A= > Could we then remove the second length field and hence gain one additiona= l byte for domains variable lenght field?=0A= =0A= That seems strange to me, since the DHPCv6 version is able=0A= to specify multiple redirections. It's beyond the scope of=0A= DHCP, so I can only assume that the other WG(s) decided=0A= the feature wasn't necessary for IPv4 networks, but is=0A= still necessary for IPv6 networks.=0A= =0A= If that is indeed the case, then yes, you can just remove the=0A= payload length octet from section 4.3 in draft -06.=0A= =0A= - Matt=0A= From teemu.savolainen@nokia.com Thu Oct 20 00:01:37 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1135121F85A1; Thu, 20 Oct 2011 00:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4+0TEhUqtys6; Thu, 20 Oct 2011 00:01:36 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 3320621F8593; Thu, 20 Oct 2011 00:01:35 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p9K71K4Z007935; Thu, 20 Oct 2011 10:01:29 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Oct 2011 10:01:20 +0300 Received: from 008-AM1MMR1-002.mgdnok.nokia.com (65.54.30.57) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 20 Oct 2011 09:01:18 +0200 Received: from 008-AM1MPN1-037.mgdnok.nokia.com ([169.254.7.8]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.01.0339.002; Thu, 20 Oct 2011 09:01:18 +0200 From: To: Thread-Topic: [dnsext] [mif] 2nd Last Call for MIF DNS server selection document Thread-Index: AQHMjlOod32iNq3Hr0aVNz752afFi5WEy7FQ Date: Thu, 20 Oct 2011 07:01:17 +0000 Message-ID: <916CE6CF87173740BC8A2CE44309696203783EE0@008-AM1MPN1-037.mgdnok.nokia.com> References: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> <121DABD1-65E8-4275-8471-9FA38D25C434@nominet.org.uk> In-Reply-To: <121DABD1-65E8-4275-8471-9FA38D25C434@nominet.org.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Company Confidential;Project=None; x-titus-version: 3.3.8.1 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IvQmQ0o/K2jquxqC2Uue5GHpzEuo3S9zNfeh3beuXC4d4U+9SoG2zegA7qMLdX6PTG17IL7pxR5S/KY/iCJNnn1c5UqLju8bmTWbhVRC5KYyRvx6Lux+omb+cjLr4ZT4xGr6EYlMoJAb4mKk7Ygo2IOCLEfvotq8eZrg90l9H1dML3IGXW5CR0VaroyKyJb6YmetiFAenF/tDgR293RVPdnMoKPAurwSeBTTqO8uNr6TcXVEvm613p4YTVwzPTjUYrSShwM2n81B2EdPx398YIM= x-originating-ip: [10.162.69.25] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_000B_01CC8F0F.35163130" MIME-Version: 1.0 X-OriginalArrivalTime: 20 Oct 2011 07:01:20.0574 (UTC) FILETIME=[123935E0:01CC8EF6] X-Nokia-AV: Clean Cc: mif@ietf.org, dnsop@ietf.org, dnsext@ietf.org, pk@isoc.de, john_brzozowski@cable.comcast.com, dhcwg@ietf.org, denghui02@hotmail.com Subject: Re: [mif] [dnsext] 2nd Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 07:01:37 -0000 ------=_NextPart_000_000B_01CC8F0F.35163130 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ray, > -----Original Message----- > From: ext Ray Bellis [mailto:Ray.Bellis@nominet.org.uk] > Sent: 19. lokakuuta 2011 13:40 > To: Savolainen Teemu (Nokia-CTO/Tampere) > Cc: ; ; ; > ; ; ; > > Subject: Re: [dnsext] [mif] 2nd Last Call for MIF DNS server selection > document >=20 > I have concerns about =A74.6: >=20 > "A bare name (a name without any dots) MUST be first treated as a pre- DNS > hostname, and only after that the name SHALL be appended with domain > information and described DNS server selection logic be utilized." >=20 > When new gTLDs are introduced it is likely for brand-name gTLDs that = they > will wish to use bare names in the DNS (i.e. a single label hostname) = for their > primary web sites. >=20 > Hence bare names may become much more frequently used as DNS names, > and =A74.6 wouldn't permit those to work unless '.' is also in the = suffix list. > > I'd like to hear the authors' thoughts on these. I'm not sure that = this draft > necessarily needs any significant changes - it may only require = changes to > ensure that bare names are also considered as potential DNS names in = their > own right. Okay, I understand there is no clear consensus yet how these single = label names should be handled by the resolvers at the first place? Should = resolver first treat them as pre-DNS hostnames, then as DNS hostnames, and then = try search list? The DNS server selection logic would be applied already = when resolving single label name, i.e. the network could provide a single = label domain "brand" in the domains list. Maybe section 4.6 could be like this, perhaps (changes in second = paragraph and title)? -- 4.6. Interactions with DNS search lists and single label hostnames A node may be configured with DNS search list by DHCPv6 OPTION_DOMAIN_LIST [RFC3646] or DHCPv4 Domain Search Option [RFC3397]. A bare name (a name without any dots) MUST be first treated as a pre- DNS hostname, after which resolution of the name SHALL be attempted with DNS, and as a last resort the name SHALL be appended with domain information. DNS server selection logic SHALL be=20 utilized for both of the latter two DNS using methods. Resolution for the name containing any dots SHOULD first be attempted with DNS servers of all interfaces. Only if the resolution fails the node SHOULD append the name with search list domain(s) and then again utilize improved DNS server selection algorithm to decide which DNS server(s) to contact. -- Best regards, Teemu ------=_NextPart_000_000B_01CC8F0F.35163130 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOuzCCAzYw ggIeoAMCAQICBDpVqdkwDQYJKoZIhvcNAQEFBQAwKTEOMAwGA1UEChMFTm9raWExFzAVBgNVBAMT Dk5va2lhICBSb290IENBMB4XDTAxMDEwNTExMDUwNVoXDTE2MDEwMjExMDUwNVowKTEOMAwGA1UE ChMFTm9raWExFzAVBgNVBAMTDk5va2lhICBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsrTy8gLmr4LYvp0khVUVHw7ascdl+Cjr+yI5MlZ6J/U6Qsvkiqthgqq8rPcLV0P1 92TfBr27VgKEeCaZe0icS1jC2spM/wRv3j2WxdkKxb9kDJtuCNJaRBqvi5vGTHB15nmEmKuL5f3i rAxeHqPjgS496oWcudzFT1e7Xrc/gWGFYd72+/ykIFXjWOMZv6QpxD8x1hLPyh2YVXRk9U7N7pvm RQNX29g4SCFJY2BBIa5JPlwIF8Nc9IePaC/E/2M4tGMtiOOZlm99EoL7N0hJZtFSvUwdCBud/viH 4DgsKGjNkNKi6pAHc9IaXB6tIykcoYp+L+oe/3+cuEJaCj1EKwIDAQABo2YwZDASBgNVHRMBAf8E CDAGAQH/AgEEMB0GA1UdDgQWBBSNjfefoQ0AITLvqe0iruA79NB9sDAfBgNVHSMEGDAWgBSNjfef oQ0AITLvqe0iruA79NB9sDAOBgNVHQ8BAf8EBAMCAYYwDQYJKoZIhvcNAQEFBQADggEBAIGEPql2 TALyKi/h1J+Mh5XolAtYppcSOLMtBkoA7ZovGBDNvl0VbZs8AAojJqkUoWBB+L6DKyl/jKhNfKcu rWRGRyj7pnbxrKLsI3gmWNWkyo2b60wJwe9fqPD5ZQy3oEiMit9l0Ba6il/k2GqYopUCNMa7mfeb E2LeBy5ChYMiCi97UQSJvAdzEYylTJw8Awc6AiM2Ve5N+XxsmKgNf/2A/5IJ3EZZ+wFRmkI4062A oNU302rqAt0HH88jzoUF4AfYHWl6HpYhGXFbcX44rHINyPmFBRxLYIFJ6ZWUr/mXpL/e6rqFtNWO kV6UoJND7OVZkbLh7F1+lcqXRU8TPBMwggOHMIICb6ADAgECAgRBtbHpMA0GCSqGSIb3DQEBBQUA MCkxDjAMBgNVBAoTBU5va2lhMRcwFQYDVQQDEw5Ob2tpYSAgUm9vdCBDQTAeFw0wNjAzMzAwOTU3 MTFaFw0xNjAxMDIxMTA1MDVaMDMxCzAJBgNVBAYTAkZJMQ4wDAYDVQQKEwVOb2tpYTEUMBIGA1UE AxMLTm9raWEgQkkgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDtFCg3QEjSCg6T IUxoWsNwELh8bBNiUQPCPmg8c2DHQYXWWCSCMb+S0Fvh1qqI1xt+XnzyFq+5eqzGzDj4UaBcG+d9 qxrCFly8sHyoPTryyPrR0EI2UUDWwfS6ojhqgwghRqo8G38TjFusyBtLub/5L6yvWYSOHD+JcB+q VM2fbkArPYK4Ydv8WG/DbHjGn0gKq0zwpVZKI/gCK/QALYvte02NXseqvY9/GOyLtjy3Z8erFv71 KKTq+gxI/7DK55pJf3PoD+kT4kyGm6EF9DTdK4ojMdar17uyX0IOZz/4vkkF0d+60nmnLX63FJPA jUyB0HUNJ32NXDo9UsM38aoNAgMBAAGjgawwgakwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAI MAYGBFUdIAAwDgYDVR0PAQH/BAQDAgGGMFQGA1UdIwRNMEuAFI2N95+hDQAhMu+p7SKu4Dv00H2w oS2kKzApMQ4wDAYDVQQKEwVOb2tpYTEXMBUGA1UEAxMOTm9raWEgIFJvb3QgQ0GCBDpVqdkwHQYD VR0OBBYEFKcksD7Fg+8EDlB2Sxgy58pW0Sy6MA0GCSqGSIb3DQEBBQUAA4IBAQAC3lEUplDlVNOT Pjz/XFezXx2bV2XbCFindhA3F815Egi55H6/cYezEjoP4QLNEGGl2I3aLvkn5A0T8I4pbiFPhIiu B/frbbGg6k6GjQLe/bFQ8F1mAOOR+GyneKZFPfzaRV0jiIR9QqnMXTf8RvKkCJyFj10MZVsLIy/Y uBkzeP3JhzDhUdtPfwmJN6ZbIhH5uR/2BwAGtgQknb8WX3I4wnhWtMUxB8XmayayYs8qWYeIiVkI FV+sLTkWUWVvvKUjyakBpbAW2vUP84DYsJ8TL1YefNjf/nIOByMcORLuV/1gPjyv00qJbcB59AA+ iXe3zIo8QNcgXG0uPQQFmrGDMIID5DCCAsygAwIBAgIQMH5apak8lEy6LmLlLsJy8TANBgkqhkiG 9w0BAQUFADAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJ IENBMB4XDTExMDkwNjA1NTIwNFoXDTE0MDkwNjA1NTIwNFowVjEOMAwGA1UECgwFTm9raWExDzAN BgNVBAsMBlBlb3BsZTEYMBYGCgmSJomT8ixkAQEMCDEwMDI0Njc2MRkwFwYDVQQDDBBTYXZvbGFp bmVuIFRlZW11MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAshEsmw6Yiz6XWX26oF+I s5fsfE1OfCjOelclmtqCiIgXND5klkNOBs2d4ZGzgD9mN+XnTZnOTh249c2WxPBugf12DCcDmBAJ gL+VuWUJVBTE5NRchm/O8nZnZsRFst+gAC9/Juykh4+EYewZ7QbpnlwW7hNpj8eH+rMr+OZHKzdp KTftgVjmuF4JJ/cPMQUjL8SuGj+zBW6IWPOZdqkEMtf7Pr8kkYbZsh0SgJ0ceRHZ7Uc06mB/y+C1 UnJPxehTTdu8tpCjdzXgBw/H2uuW1J3qdHbCfbuDILql8V8RiZKubcZLhdsD3Jvj8qK0DGWBJa6x p90q5p3pLE8LvAeCgQIDAQABo4HQMIHNMA4GA1UdDwEB/wQEAwIEMDAfBgNVHSMEGDAWgBSnJLA+ xYPvBA5QdksYMufKVtEsujAZBgNVHSAEEjAQMA4GDCsGAQQBXgExBgEHAzA5BgNVHR8EMjAwMC6g LKAqhihodHRwOi8vY3JsLm5va2lhLmNvbS9Ob2tpYSUyMEJJJTIwQ0EuY3JsMCUGA1UdEQQeMByB GnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBQTRzvZsgmQrAGCeuzdHTGAC6Jg UzANBgkqhkiG9w0BAQUFAAOCAQEACmPVsdi07pjK5gDa+W5JlE2C74kVVsB8alBqfioYeR5At2FG B7sua4Dz5H7TJMpZ1jYFeI+zjexD5f+beY2IlV15lMoWD+5e38QlLYjwfe2LAyvdzBKXW0e0U6Bt p78ft4gyVak1X+Db+ebR+FNHUOMNhm+yK3w9sy5ZQzBFusIx4OgxGvcZhyhmd9WjipSTalgPwgqV Ju2aPADCG++OEXmgEWRLsR4yNopkgK4ftVqrN5uUtLs83qdeXTRcNRiET1IOx5zmYFZ6q3gjKIx5 iyuxcDeYas93vVHUcaRRYpsoby5CHq7Z/j/TQhtqO/knWuxLFFiCUgdGKMKrRkg29DCCBAowggLy oAMCAQICEQCBvi+p+bA/dBtBtybwA6YYMA0GCSqGSIb3DQEBBQUAMDMxCzAJBgNVBAYTAkZJMQ4w DAYDVQQKEwVOb2tpYTEUMBIGA1UEAxMLTm9raWEgQkkgQ0EwHhcNMTEwOTA2MDU1MDM0WhcNMTMw OTA1MDU1MDM0WjBWMQ4wDAYDVQQKDAVOb2tpYTEPMA0GA1UECwwGUGVvcGxlMRgwFgYKCZImiZPy LGQBAQwIMTAwMjQ2NzYxGTAXBgNVBAMMEFNhdm9sYWluZW4gVGVlbXUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDFPmbRVwuo52v+h6xnQUqokAx2xsHjmPBniEkzgtgBNJsFi838ATEg 1zsx+VotoJg7hMijcrQfpTAgW6gpLGnlmw5QQswrNK1zleOHb4pA5JguU3WhVKFkAH/6/2EU2k/9 m8Pb/gwP55cYg80R6fRmbdsWKhseXF/1isW/rJcWLmIYDg/rXfo3ixqtT9MroAMiuoXnb0ij1L2d Jj64LDp3Ld8Jo0qZzk3Fj4apo8PBd8eAH6HloVBJkxQcwAnv561A+Xi1GHZ2mafRYJGO+1uBDwyd g/8ybEXXA4MKo8lPKjBebYBUFvz80DBA/Lq74UysXkG23BSulcG4xQSYGlyzAgMBAAGjgfUwgfIw HwYDVR0jBBgwFoAUpySwPsWD7wQOUHZLGDLnylbRLLowGQYDVR0gBBIwEDAOBgwrBgEEAV4BMQYB BgQwOQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5ub2tpYS5jb20vTm9raWElMjBCSSUyMENB LmNybDAjBgNVHSUEHDAaBggrBgEFBQcDAgYEVR0lAAYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgeA MCUGA1UdEQQeMByBGnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBTGhbTJF0EX iagjymQo6GIuSQeRVDANBgkqhkiG9w0BAQUFAAOCAQEAqai6TxZ/BlMHZIhJNPriBPXkQhUlBkGA buJZ5sVm1HIQhWN8elZKjjJdHi1qWEKhMg7yHjEMZsyV8XAZzK0UnOqkpUnt+jnVkNZ9O7/jRtyK f4WUtq5jErc8Hlv4bbGFRHk1T7AuLLE52r1lYOdmoibnQp03QtlDvHUNa68G7jvzThJhieB7U1xh vH3yy0ktaVnWEgAylqf9yIUFjnqau5R6cE1Xo57IYPk/KitX0YF+OigEI/bOQVMi+fze93ZsAOJv /z6g/NGemvUgl5YSdX0uPQK6kEHf/sp/nZyUWWQ7OjtVSqkq2YuYEueQFxTfafl+78GWqgm6W/Bl 32laYzGCAuswggLnAgEBMEgwMzELMAkGA1UEBhMCRkkxDjAMBgNVBAoTBU5va2lhMRQwEgYDVQQD EwtOb2tpYSBCSSBDQQIRAIG+L6n5sD90G0G3JvADphgwCQYFKw4DAhoFAKCCAXgwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTExMDIwMDcwMTE2WjAjBgkqhkiG9w0B CQQxFgQUuTt7teHeqB8ooGagy/SG3Xnw4zwwVgYJKwYBBAGCNxAEMUkwRzAzMQswCQYDVQQGEwJG STEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLx MFgGCyqGSIb3DQEJEAILMUmgRzAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNV BAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLxMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMA0GCSqGSIb3DQEBAQUABIIBAMSkBzqjbdHlBTpm8zsK dARLhoIexypjdRC2/tQrlf4SnuH8xOK1vrRiObBqVszG5Blj3s1j3rTEG/QFiK+tN6N3Ms4ZhyXG aSOAZ4URmpXl06bZk8fh/dVCS9DidvLv8r22W6EvXvDcz3kiPd4Rti/3OOdOoZY0QyBWElaOv0+J Fsi8OvPTy3hn9Fr4jo5OCbTQYNn6WNdFZGEMQg8OOw4zg2uIgyJjE6IH0IfImz5zegcp5In5h3u6 Q5J+qCaOklPY5rF3nyCajjg0jwgNzQ1/dCmwWpO77Fs4/dAhylHAINz++9vHwcYJPJc4PETz5VoS eADAIKURiY31TO1q+PkAAAAAAAA= ------=_NextPart_000_000B_01CC8F0F.35163130-- From sm@resistor.net Thu Oct 20 01:22:20 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2717021F8B23; Thu, 20 Oct 2011 01:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.418 X-Spam-Level: X-Spam-Status: No, score=-102.418 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UI5RY41Z1ijk; Thu, 20 Oct 2011 01:22:17 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C69F421F8B25; Thu, 20 Oct 2011 01:22:17 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5) with ESMTP id p9K8M9SL023882; Thu, 20 Oct 2011 01:22:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1319098935; bh=N3Dmm0lWJa/6t0ZCU0mtRthZuL/xuzuCCgy/aU4giNQ=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=cx/COIgK9lBuxWjV5XuWHWlxxnPbqSrYUVIF+pMj4MBkjWiYhe1GPFUzydELeuvSb 32X+xmJj4Z+IgQUKUbNMSYM7pOSWVrnLdOwksl2+B+RxYqNIOiPWGWVcF2pgkrRCKE cvUF9gEK4giQNYNAJGBLtWp4ZEkQJFfB+knDAa7g= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1319098935; bh=N3Dmm0lWJa/6t0ZCU0mtRthZuL/xuzuCCgy/aU4giNQ=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=YIbV39CPRK/5uGvGipxguGj3vPhgOpwVgZNNvgNgKp5cZlOvGhw6QfFFIU4UiAldK iD3ov+2hbJsPb7DXBFqPgdqloKg/5hGuhMQ8OTKOMAdyD6IM/hNu5MEGl4E1hso2zb P+LC0cIqDZ8SLOZq5lx0BIx52brlBSawnDpjkbwU= Message-Id: <6.2.5.6.2.20111020004109.09649270@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 20 Oct 2011 01:21:28 -0700 To: teemu.savolainen@nokia.com From: SM In-Reply-To: <916CE6CF87173740BC8A2CE44309696203783EE0@008-AM1MPN1-037.m gdnok.nokia.com> References: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> <121DABD1-65E8-4275-8471-9FA38D25C434@nominet.org.uk> <916CE6CF87173740BC8A2CE44309696203783EE0@008-AM1MPN1-037.mgdnok.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailman-Approved-At: Thu, 20 Oct 2011 01:44:27 -0700 Cc: mif@ietf.org, dnsext@ietf.org Subject: Re: [mif] [dnsext] 2nd Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 08:22:20 -0000 Hi Teemu, [message trimmed to MIF and DNSEXT] At 00:01 20-10-2011, teemu.savolainen@nokia.com wrote: >Okay, I understand there is no clear consensus yet how these single label >names should be handled by the resolvers at the first place? Should resolver Section 4.6 discusses about domain search lists. It's not DNS search lists. From RFC 3646 (it's not a normative reference in the draft): "Resolve a name containing no dots by appending with the searchlist right away, but once again, no implicit searchlists should be used." >first treat them as pre-DNS hostnames, then as DNS hostnames, and then try What's pre-DNS hostnames? >search list? The DNS server selection logic would be applied already when >resolving single label name, i.e. the network could provide a single label >domain "brand" in the domains list. Do you want to make domain "brands" your problem? From Section 7: "Private namespaces MUST be globally unique in order to keep DNS unambiguous and henceforth avoiding caching related issues and destination selection problems (see Section 2.3). Exceptions to this rule are domains utilized for local name resolution (such as .local)." How can the requirement for global uniqueness of anmespace be met? I found a discussion of a unique name space in RFC 2826 but it is only for the public name space. As there is an exception to the requirement, it is no longer a MUST. Regards, -sm From brian.e.carpenter@gmail.com Thu Oct 20 14:50:25 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35F4F1F0C53; Thu, 20 Oct 2011 14:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.359 X-Spam-Level: X-Spam-Status: No, score=-103.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DlSfIPvfBPIJ; Thu, 20 Oct 2011 14:50:24 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC241F0C45; Thu, 20 Oct 2011 14:50:21 -0700 (PDT) Received: by eyg24 with SMTP id 24so3550333eyg.31 for ; Thu, 20 Oct 2011 14:50:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=BAeL1KQxui7l8vQAhsztSwZSRk+wxJ5NyURdFer+LNg=; b=qTtgY1y4hVghqupw1YTKZ9PTT5fzguwM37w22g7MWcPYkA7bG3kdTrKVgkoL+yTey4 j4agKFOLbDbitTEoCExF7wOQFyaS6J0Y/07LIfavyBiA8M2+FAn7uyevwBw/B/Qewz0o yGnoxx4jnvxFVpEQcnI3mtDsaVBnsTNHukJmE= Received: by 10.223.58.83 with SMTP id f19mr20388590fah.36.1319147421132; Thu, 20 Oct 2011 14:50:21 -0700 (PDT) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id a1sm18056250fab.4.2011.10.20.14.50.14 (version=SSLv3 cipher=OTHER); Thu, 20 Oct 2011 14:50:19 -0700 (PDT) Message-ID: <4EA09791.8010705@gmail.com> Date: Fri, 21 Oct 2011 10:50:09 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: teemu.savolainen@nokia.com References: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> <121DABD1-65E8-4275-8471-9FA38D25C434@nominet.org.uk> <916CE6CF87173740BC8A2CE44309696203783EE0@008-AM1MPN1-037.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE44309696203783EE0@008-AM1MPN1-037.mgdnok.nokia.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mif@ietf.org, dnsop@ietf.org, dnsext@ietf.org, pk@isoc.de, john_brzozowski@cable.comcast.com, dhcwg@ietf.org, denghui02@hotmail.com Subject: Re: [mif] [dnsext] 2nd Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 21:50:25 -0000 Teemu, I don't believe this is a topic where consensus in MIF is very relevant. It needs to be decided in a much wider community rather than as a subsidi= ary question in a MIF document. I suggest leaving it FFS (for further study) in MIF. Regards Brian Carpenter On 2011-10-20 20:01, teemu.savolainen@nokia.com wrote: > Hi Ray, >=20 >> -----Original Message----- >> From: ext Ray Bellis [mailto:Ray.Bellis@nominet.org.uk] >> Sent: 19. lokakuuta 2011 13:40 >> To: Savolainen Teemu (Nokia-CTO/Tampere) >> Cc: ; ; ; >> ; ; ; >> >> Subject: Re: [dnsext] [mif] 2nd Last Call for MIF DNS server selection= >> document >> >> I have concerns about =C2=A74.6: >> >> "A bare name (a name without any dots) MUST be first treated as a pre-= > DNS >> hostname, and only after that the name SHALL be appended with domain >> information and described DNS server selection logic be utilized." >> >> When new gTLDs are introduced it is likely for brand-name gTLDs that t= hey >> will wish to use bare names in the DNS (i.e. a single label hostname) = for > their >> primary web sites. >> >> Hence bare names may become much more frequently used as DNS names, >> and =C2=A74.6 wouldn't permit those to work unless '.' is also in the = suffix > list. >> I'd like to hear the authors' thoughts on these. I'm not sure that th= is > draft >> necessarily needs any significant changes - it may only require change= s to >> ensure that bare names are also considered as potential DNS names in t= heir >> own right. >=20 > Okay, I understand there is no clear consensus yet how these single lab= el > names should be handled by the resolvers at the first place? Should res= olver > first treat them as pre-DNS hostnames, then as DNS hostnames, and then = try > search list? The DNS server selection logic would be applied already wh= en > resolving single label name, i.e. the network could provide a single la= bel > domain "brand" in the domains list. >=20 > Maybe section 4.6 could be like this, perhaps (changes in second paragr= aph > and title)? > -- > 4.6. Interactions with DNS search lists and single label hostnames >=20 > A node may be configured with DNS search list by DHCPv6 > OPTION_DOMAIN_LIST [RFC3646] or DHCPv4 Domain Search Option > [RFC3397]. >=20 > A bare name (a name without any dots) MUST be first treated as a pre= - > DNS hostname, after which resolution of the name SHALL be attempted > with DNS, and as a last resort the name SHALL be appended with > domain information. DNS server selection logic SHALL be=20 > utilized for both of the latter two DNS using methods. >=20 > Resolution for the name containing any dots SHOULD first be attempte= d > with DNS servers of all interfaces. Only if the resolution fails th= e > node SHOULD append the name with search list domain(s) and then agai= n > utilize improved DNS server selection algorithm to decide which DNS > server(s) to contact. > -- >=20 > Best regards, >=20 > Teemu >=20 >=20 >=20 > -----------------------------------------------------------------------= - >=20 > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From moore@network-heretics.com Thu Oct 20 18:08:11 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A74E911E8099; Thu, 20 Oct 2011 18:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.807 X-Spam-Level: X-Spam-Status: No, score=-3.807 tagged_above=-999 required=5 tests=[AWL=-0.208, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAAg6U9lEK09; Thu, 20 Oct 2011 18:08:10 -0700 (PDT) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id B0DC811E8091; Thu, 20 Oct 2011 18:08:10 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id CD42F21172; Thu, 20 Oct 2011 21:08:09 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute3.internal (MEProxy); Thu, 20 Oct 2011 21:08:09 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=qHOj5RVNbeLDBZ3kqQ9hlPRTsH8=; b=nx nXShspT+8/SvrDB8r/9XbhQAzGq0Y1VDp6pdUPzAptbhklkFQeg1AN3F/BlJpCG6 FKBQ7DfHYiWKySxY/r/EIHHdfeJ/SWHrYBNnZJBvmcY2AGRdz+C/2bQV4G/SMGQZ 5l9mqRGunAXTbg6+eC+9SFtGxtCC4QyGDNYPbOqbw= X-Sasl-enc: oPXSpLq6gHGfeqDCFDuJw/Y+OPTvaTI+76jYhQAU+cxB 1319159289 Received: from [192.168.1.16] (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id B0A5F4833E7; Thu, 20 Oct 2011 21:08:07 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Keith Moore In-Reply-To: <4EA09791.8010705@gmail.com> Date: Thu, 20 Oct 2011 21:07:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> <121DABD1-65E8-4275-8471-9FA38D25C434@nominet.org.uk> <916CE6CF87173740BC8A2CE44309696203783EE0@008-AM1MPN1-037.mgdnok.nokia.com> <4EA09791.8010705@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1084) Cc: mif@ietf.org, dnsop@ietf.org, dnsext@ietf.org, pk@isoc.de, john_brzozowski@cable.comcast.com, dhcwg@ietf.org, denghui02@hotmail.com Subject: Re: [mif] [dnsext] 2nd Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 01:08:11 -0000 It might that IETF should consider "bare names" out of its scope, except = perhaps to say that they're not DNS names, they don't have to = necessarily be mappable to DNS names, and that their use and behavior is = host and application-dependent. Keith On Oct 20, 2011, at 5:50 PM, Brian E Carpenter wrote: > Teemu, >=20 > I don't believe this is a topic where consensus in MIF is very = relevant. > It needs to be decided in a much wider community rather than as a = subsidiary > question in a MIF document. I suggest leaving it FFS (for further = study) > in MIF. >=20 > Regards > Brian Carpenter >=20 > On 2011-10-20 20:01, teemu.savolainen@nokia.com wrote: >> Hi Ray, >>=20 >>> -----Original Message----- >>> From: ext Ray Bellis [mailto:Ray.Bellis@nominet.org.uk] >>> Sent: 19. lokakuuta 2011 13:40 >>> To: Savolainen Teemu (Nokia-CTO/Tampere) >>> Cc: ; ; ; >>> ; ; ; >>> >>> Subject: Re: [dnsext] [mif] 2nd Last Call for MIF DNS server = selection >>> document >>>=20 >>> I have concerns about =A74.6: >>>=20 >>> "A bare name (a name without any dots) MUST be first treated as a = pre- >> DNS >>> hostname, and only after that the name SHALL be appended with = domain >>> information and described DNS server selection logic be utilized." >>>=20 >>> When new gTLDs are introduced it is likely for brand-name gTLDs that = they >>> will wish to use bare names in the DNS (i.e. a single label = hostname) for >> their >>> primary web sites. >>>=20 >>> Hence bare names may become much more frequently used as DNS names, >>> and =A74.6 wouldn't permit those to work unless '.' is also in the = suffix >> list. >>> I'd like to hear the authors' thoughts on these. I'm not sure that = this >> draft >>> necessarily needs any significant changes - it may only require = changes to >>> ensure that bare names are also considered as potential DNS names in = their >>> own right. >>=20 >> Okay, I understand there is no clear consensus yet how these single = label >> names should be handled by the resolvers at the first place? Should = resolver >> first treat them as pre-DNS hostnames, then as DNS hostnames, and = then try >> search list? The DNS server selection logic would be applied already = when >> resolving single label name, i.e. the network could provide a single = label >> domain "brand" in the domains list. >>=20 >> Maybe section 4.6 could be like this, perhaps (changes in second = paragraph >> and title)? >> -- >> 4.6. Interactions with DNS search lists and single label hostnames >>=20 >> A node may be configured with DNS search list by DHCPv6 >> OPTION_DOMAIN_LIST [RFC3646] or DHCPv4 Domain Search Option >> [RFC3397]. >>=20 >> A bare name (a name without any dots) MUST be first treated as a = pre- >> DNS hostname, after which resolution of the name SHALL be attempted >> with DNS, and as a last resort the name SHALL be appended with >> domain information. DNS server selection logic SHALL be=20 >> utilized for both of the latter two DNS using methods. >>=20 >> Resolution for the name containing any dots SHOULD first be = attempted >> with DNS servers of all interfaces. Only if the resolution fails = the >> node SHOULD append the name with search list domain(s) and then = again >> utilize improved DNS server selection algorithm to decide which DNS >> server(s) to contact. >> -- >>=20 >> Best regards, >>=20 >> Teemu >>=20 >>=20 >>=20 >> = ------------------------------------------------------------------------ >>=20 >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif >=20 > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From moore@network-heretics.com Thu Oct 20 18:39:27 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A575C1F0C47; Thu, 20 Oct 2011 18:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.792 X-Spam-Level: X-Spam-Status: No, score=-3.792 tagged_above=-999 required=5 tests=[AWL=-0.193, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jidTSuKNg4Vu; Thu, 20 Oct 2011 18:39:27 -0700 (PDT) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 034D71F0C3C; Thu, 20 Oct 2011 18:39:27 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 88D7E2067F; Thu, 20 Oct 2011 21:39:26 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute6.internal (MEProxy); Thu, 20 Oct 2011 21:39:26 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=63q2SBi6u8A4nDGLr3DDLXaMfps=; b=Rn rO5oMbPjMub7bH20PmCW391uID4P7/95wKfDFEcD+JA6w/JPnwL6eVdk36l7Dasg ZQhJ+/MVWSJ8GmjRy9Q/VJnph02tb8SylgtB26Q7ihKJ3an1ObEC/McCIDV03aOi T80Ds01OsXKVs00vwm3rKN2xjS9d/gRssXPamEtqs= X-Sasl-enc: 4NGv0e7cIBi+zvGFuuisqbcmpKgbEx9ToGkpLUFi34x7 1319161166 Received: from [192.168.1.16] (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id B70494833A4; Thu, 20 Oct 2011 21:39:24 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <94C2E518-F34F-49E4-B15C-2CCCFAA96667@virtualized.org> Date: Thu, 20 Oct 2011 21:38:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <12477381-9F74-4C50-B576-47EE4322F6BC@network-heretics.com> References: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> <121DABD1-65E8-4275-8471-9FA38D25C434@nominet.org.uk> <916CE6CF87173740BC8A2CE44309696203783EE0@008-AM1MPN1-037.mgdnok.nokia.com> <4EA09791.8010705@gmail.com> <94C2E518-F34F-49E4-B15C-2CCCFAA96667@virtualized.org> To: David Conrad X-Mailer: Apple Mail (2.1084) Cc: mif@ietf.org, dnsop@ietf.org, dnsext@ietf.org, pk@isoc.de, john_brzozowski@cable.comcast.com, dhcwg@ietf.org, denghui02@hotmail.com Subject: Re: [mif] [dnsext] 2nd Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 01:39:27 -0000 On Oct 20, 2011, at 9:19 PM, David Conrad wrote: > On Oct 20, 2011, at 6:07 PM, Keith Moore wrote: >> It might that IETF should consider "bare names" out of its scope, = except perhaps to say that they're not DNS names, they don't have to = necessarily be mappable to DNS names, and that their use and behavior is = host and application-dependent. >=20 > Can we please not redefine what a "DNS name" is to meet a particular = agenda? I wasn't trying to do so. > Isn't it sufficient to say a 'bare name' does not conform to a = hostname as defined in RFC 952 and modified by RFCs 1122? Probably. I'm just suggesting that trying to nail down the behavior of = such names is probably a rathole as well as likely to cause significant = disruption. From teemu.savolainen@nokia.com Fri Oct 21 00:15:16 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D95A11E80A1; Fri, 21 Oct 2011 00:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8JFbRmyWmsd8; Fri, 21 Oct 2011 00:15:15 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id D5C6711E808C; Fri, 21 Oct 2011 00:15:14 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p9L7F7ca025097; Fri, 21 Oct 2011 10:15:07 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 21 Oct 2011 10:15:06 +0300 Received: from 008-AM1MMR1-003.mgdnok.nokia.com (65.54.30.58) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 21 Oct 2011 09:15:06 +0200 Received: from 008-AM1MPN1-037.mgdnok.nokia.com ([169.254.7.8]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.01.0339.002; Fri, 21 Oct 2011 09:15:05 +0200 From: To: Thread-Topic: [mif] [dnsext] 2nd Last Call for MIF DNS server selection document Thread-Index: AQHMj3JGB7FreQH6+EqCg+ltMTYsr5WGYYlQ Date: Fri, 21 Oct 2011 07:15:05 +0000 Message-ID: <916CE6CF87173740BC8A2CE44309696203784B1F@008-AM1MPN1-037.mgdnok.nokia.com> References: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> <121DABD1-65E8-4275-8471-9FA38D25C434@nominet.org.uk> <916CE6CF87173740BC8A2CE44309696203783EE0@008-AM1MPN1-037.mgdnok.nokia.com> <4EA09791.8010705@gmail.com> In-Reply-To: <4EA09791.8010705@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Company Confidential;Project=None; x-titus-version: 3.3.8.1 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IleTS5gKgr+JhCehPOzQb7X8VPIDGtFQ+zxfOgeaBUZsOG8Ek7lD2xu5WHF5/rxKyBmC4Zgoz9lY65iVD+EwKfx/HOyCbcbCouTzciSIqgIMf/5bLh0Sai/jE6sG24Xx+7Vb5YLSzlGNh/xlWFKXjhG/VugZS7r2MiqJJ+wJiYnj7oW0F1q2Pewb5bJXqVC5toWbFgVuespx3qoYFmYIO7yzifaaSr9b380ixgq8cDxL9AfCqPWq32/ZgZAi48Q3WSxOadDP3x3m22zqpSDkV30= x-originating-ip: [10.162.93.230] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0164_01CC8FDA.4BCA8DB0" MIME-Version: 1.0 X-OriginalArrivalTime: 21 Oct 2011 07:15:06.0851 (UTC) FILETIME=[2922D330:01CC8FC1] X-Nokia-AV: Clean Cc: mif@ietf.org, dnsop@ietf.org, dnsext@ietf.org, pk@isoc.de, john_brzozowski@cable.comcast.com, dhcwg@ietf.org, denghui02@hotmail.com Subject: Re: [mif] [dnsext] 2nd Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 07:15:16 -0000 ------=_NextPart_000_0164_01CC8FDA.4BCA8DB0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Brian, Would the following text be then ok? Please note I changed the domain = addition from SHOULD to MAY, if there is going to be attempt to = deprecate/redefine/update search list logics. Or do you think it should = remain SHOULD? -- 4.6. Interactions with DNS search lists A node may be configured with DNS search list via DHCPv6 OPTION_DOMAIN_LIST [RFC3646] or via DHCPv4 Domain Search Option [RFC3397]. A bare name (a name without any dots) MUST be first treated as a pre- DNS hostname or handled by other means that, as of this writing, are under discussion in the IETF and that are out of the scope of this document. If the bare name resolution fails, the name MAY then be appended with the domain information. If the bare name is appended with the domain information the described DNS server selection logic SHALL be utilized for the resulting name. Resolution for the name containing any dots SHOULD first be attempted with DNS servers of all interfaces. Only if the resolution fails the node MAY append the name with search list domain(s) and then again utilize improved DNS server selection algorithm to decide which DNS server(s) to contact. -- Best regards, Teemu > -----Original Message----- > From: ext Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > Sent: 21. lokakuuta 2011 00:50 > To: Savolainen Teemu (Nokia-CTO/Tampere) > Cc: Ray.Bellis@nominet.org.uk; mif@ietf.org; dnsop@ietf.org; > dnsext@ietf.org; pk@isoc.de; john_brzozowski@cable.comcast.com; > dhcwg@ietf.org; denghui02@hotmail.com > Subject: Re: [mif] [dnsext] 2nd Last Call for MIF DNS server selection > document >=20 > Teemu, >=20 > I don't believe this is a topic where consensus in MIF is very = relevant. > It needs to be decided in a much wider community rather than as a = subsidiary > question in a MIF document. I suggest leaving it FFS (for further = study) in MIF. >=20 > Regards > Brian Carpenter >=20 > On 2011-10-20 20:01, teemu.savolainen@nokia.com wrote: > > Hi Ray, > > > >> -----Original Message----- > >> From: ext Ray Bellis [mailto:Ray.Bellis@nominet.org.uk] > >> Sent: 19. lokakuuta 2011 13:40 > >> To: Savolainen Teemu (Nokia-CTO/Tampere) > >> Cc: ; ; ; > >> ; ; ; > >> > >> Subject: Re: [dnsext] [mif] 2nd Last Call for MIF DNS server > >> selection document > >> > >> I have concerns about =C2=A74.6: > >> > >> "A bare name (a name without any dots) MUST be first treated as a > >> pre- > > DNS > >> hostname, and only after that the name SHALL be appended with = domain > >> information and described DNS server selection logic be utilized." > >> > >> When new gTLDs are introduced it is likely for brand-name gTLDs = that > >> they will wish to use bare names in the DNS (i.e. a single label > >> hostname) for > > their > >> primary web sites. > >> > >> Hence bare names may become much more frequently used as DNS > names, > >> and =C2=A74.6 wouldn't permit those to work unless '.' is also in = the > >> suffix > > list. > >> I'd like to hear the authors' thoughts on these. I'm not sure that > >> this > > draft > >> necessarily needs any significant changes - it may only require > >> changes to ensure that bare names are also considered as potential > >> DNS names in their own right. > > > > Okay, I understand there is no clear consensus yet how these single > > label names should be handled by the resolvers at the first place? > > Should resolver first treat them as pre-DNS hostnames, then as DNS > > hostnames, and then try search list? The DNS server selection logic > > would be applied already when resolving single label name, i.e. the > > network could provide a single label domain "brand" in the domains = list. > > > > Maybe section 4.6 could be like this, perhaps (changes in second > > paragraph and title)? > > -- > > 4.6. Interactions with DNS search lists and single label hostnames > > > > A node may be configured with DNS search list by DHCPv6 > > OPTION_DOMAIN_LIST [RFC3646] or DHCPv4 Domain Search Option > > [RFC3397]. > > > > A bare name (a name without any dots) MUST be first treated as a = pre- > > DNS hostname, after which resolution of the name SHALL be = attempted > > with DNS, and as a last resort the name SHALL be appended with > > domain information. DNS server selection logic SHALL be > > utilized for both of the latter two DNS using methods. > > > > Resolution for the name containing any dots SHOULD first be = attempted > > with DNS servers of all interfaces. Only if the resolution fails = the > > node SHOULD append the name with search list domain(s) and then = again > > utilize improved DNS server selection algorithm to decide which = DNS > > server(s) to contact. > > -- > > > > Best regards, > > > > Teemu > > > > > > > > = ---------------------------------------------------------------------- > > -- > > > > _______________________________________________ > > mif mailing list > > mif@ietf.org > > https://www.ietf.org/mailman/listinfo/mif ------=_NextPart_000_0164_01CC8FDA.4BCA8DB0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOuzCCAzYw ggIeoAMCAQICBDpVqdkwDQYJKoZIhvcNAQEFBQAwKTEOMAwGA1UEChMFTm9raWExFzAVBgNVBAMT Dk5va2lhICBSb290IENBMB4XDTAxMDEwNTExMDUwNVoXDTE2MDEwMjExMDUwNVowKTEOMAwGA1UE ChMFTm9raWExFzAVBgNVBAMTDk5va2lhICBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsrTy8gLmr4LYvp0khVUVHw7ascdl+Cjr+yI5MlZ6J/U6Qsvkiqthgqq8rPcLV0P1 92TfBr27VgKEeCaZe0icS1jC2spM/wRv3j2WxdkKxb9kDJtuCNJaRBqvi5vGTHB15nmEmKuL5f3i rAxeHqPjgS496oWcudzFT1e7Xrc/gWGFYd72+/ykIFXjWOMZv6QpxD8x1hLPyh2YVXRk9U7N7pvm RQNX29g4SCFJY2BBIa5JPlwIF8Nc9IePaC/E/2M4tGMtiOOZlm99EoL7N0hJZtFSvUwdCBud/viH 4DgsKGjNkNKi6pAHc9IaXB6tIykcoYp+L+oe/3+cuEJaCj1EKwIDAQABo2YwZDASBgNVHRMBAf8E CDAGAQH/AgEEMB0GA1UdDgQWBBSNjfefoQ0AITLvqe0iruA79NB9sDAfBgNVHSMEGDAWgBSNjfef oQ0AITLvqe0iruA79NB9sDAOBgNVHQ8BAf8EBAMCAYYwDQYJKoZIhvcNAQEFBQADggEBAIGEPql2 TALyKi/h1J+Mh5XolAtYppcSOLMtBkoA7ZovGBDNvl0VbZs8AAojJqkUoWBB+L6DKyl/jKhNfKcu rWRGRyj7pnbxrKLsI3gmWNWkyo2b60wJwe9fqPD5ZQy3oEiMit9l0Ba6il/k2GqYopUCNMa7mfeb E2LeBy5ChYMiCi97UQSJvAdzEYylTJw8Awc6AiM2Ve5N+XxsmKgNf/2A/5IJ3EZZ+wFRmkI4062A oNU302rqAt0HH88jzoUF4AfYHWl6HpYhGXFbcX44rHINyPmFBRxLYIFJ6ZWUr/mXpL/e6rqFtNWO kV6UoJND7OVZkbLh7F1+lcqXRU8TPBMwggOHMIICb6ADAgECAgRBtbHpMA0GCSqGSIb3DQEBBQUA MCkxDjAMBgNVBAoTBU5va2lhMRcwFQYDVQQDEw5Ob2tpYSAgUm9vdCBDQTAeFw0wNjAzMzAwOTU3 MTFaFw0xNjAxMDIxMTA1MDVaMDMxCzAJBgNVBAYTAkZJMQ4wDAYDVQQKEwVOb2tpYTEUMBIGA1UE AxMLTm9raWEgQkkgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDtFCg3QEjSCg6T IUxoWsNwELh8bBNiUQPCPmg8c2DHQYXWWCSCMb+S0Fvh1qqI1xt+XnzyFq+5eqzGzDj4UaBcG+d9 qxrCFly8sHyoPTryyPrR0EI2UUDWwfS6ojhqgwghRqo8G38TjFusyBtLub/5L6yvWYSOHD+JcB+q VM2fbkArPYK4Ydv8WG/DbHjGn0gKq0zwpVZKI/gCK/QALYvte02NXseqvY9/GOyLtjy3Z8erFv71 KKTq+gxI/7DK55pJf3PoD+kT4kyGm6EF9DTdK4ojMdar17uyX0IOZz/4vkkF0d+60nmnLX63FJPA jUyB0HUNJ32NXDo9UsM38aoNAgMBAAGjgawwgakwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAI MAYGBFUdIAAwDgYDVR0PAQH/BAQDAgGGMFQGA1UdIwRNMEuAFI2N95+hDQAhMu+p7SKu4Dv00H2w oS2kKzApMQ4wDAYDVQQKEwVOb2tpYTEXMBUGA1UEAxMOTm9raWEgIFJvb3QgQ0GCBDpVqdkwHQYD VR0OBBYEFKcksD7Fg+8EDlB2Sxgy58pW0Sy6MA0GCSqGSIb3DQEBBQUAA4IBAQAC3lEUplDlVNOT Pjz/XFezXx2bV2XbCFindhA3F815Egi55H6/cYezEjoP4QLNEGGl2I3aLvkn5A0T8I4pbiFPhIiu B/frbbGg6k6GjQLe/bFQ8F1mAOOR+GyneKZFPfzaRV0jiIR9QqnMXTf8RvKkCJyFj10MZVsLIy/Y uBkzeP3JhzDhUdtPfwmJN6ZbIhH5uR/2BwAGtgQknb8WX3I4wnhWtMUxB8XmayayYs8qWYeIiVkI FV+sLTkWUWVvvKUjyakBpbAW2vUP84DYsJ8TL1YefNjf/nIOByMcORLuV/1gPjyv00qJbcB59AA+ iXe3zIo8QNcgXG0uPQQFmrGDMIID5DCCAsygAwIBAgIQMH5apak8lEy6LmLlLsJy8TANBgkqhkiG 9w0BAQUFADAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJ IENBMB4XDTExMDkwNjA1NTIwNFoXDTE0MDkwNjA1NTIwNFowVjEOMAwGA1UECgwFTm9raWExDzAN BgNVBAsMBlBlb3BsZTEYMBYGCgmSJomT8ixkAQEMCDEwMDI0Njc2MRkwFwYDVQQDDBBTYXZvbGFp bmVuIFRlZW11MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAshEsmw6Yiz6XWX26oF+I s5fsfE1OfCjOelclmtqCiIgXND5klkNOBs2d4ZGzgD9mN+XnTZnOTh249c2WxPBugf12DCcDmBAJ gL+VuWUJVBTE5NRchm/O8nZnZsRFst+gAC9/Juykh4+EYewZ7QbpnlwW7hNpj8eH+rMr+OZHKzdp KTftgVjmuF4JJ/cPMQUjL8SuGj+zBW6IWPOZdqkEMtf7Pr8kkYbZsh0SgJ0ceRHZ7Uc06mB/y+C1 UnJPxehTTdu8tpCjdzXgBw/H2uuW1J3qdHbCfbuDILql8V8RiZKubcZLhdsD3Jvj8qK0DGWBJa6x p90q5p3pLE8LvAeCgQIDAQABo4HQMIHNMA4GA1UdDwEB/wQEAwIEMDAfBgNVHSMEGDAWgBSnJLA+ xYPvBA5QdksYMufKVtEsujAZBgNVHSAEEjAQMA4GDCsGAQQBXgExBgEHAzA5BgNVHR8EMjAwMC6g LKAqhihodHRwOi8vY3JsLm5va2lhLmNvbS9Ob2tpYSUyMEJJJTIwQ0EuY3JsMCUGA1UdEQQeMByB GnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBQTRzvZsgmQrAGCeuzdHTGAC6Jg UzANBgkqhkiG9w0BAQUFAAOCAQEACmPVsdi07pjK5gDa+W5JlE2C74kVVsB8alBqfioYeR5At2FG B7sua4Dz5H7TJMpZ1jYFeI+zjexD5f+beY2IlV15lMoWD+5e38QlLYjwfe2LAyvdzBKXW0e0U6Bt p78ft4gyVak1X+Db+ebR+FNHUOMNhm+yK3w9sy5ZQzBFusIx4OgxGvcZhyhmd9WjipSTalgPwgqV Ju2aPADCG++OEXmgEWRLsR4yNopkgK4ftVqrN5uUtLs83qdeXTRcNRiET1IOx5zmYFZ6q3gjKIx5 iyuxcDeYas93vVHUcaRRYpsoby5CHq7Z/j/TQhtqO/knWuxLFFiCUgdGKMKrRkg29DCCBAowggLy oAMCAQICEQCBvi+p+bA/dBtBtybwA6YYMA0GCSqGSIb3DQEBBQUAMDMxCzAJBgNVBAYTAkZJMQ4w DAYDVQQKEwVOb2tpYTEUMBIGA1UEAxMLTm9raWEgQkkgQ0EwHhcNMTEwOTA2MDU1MDM0WhcNMTMw OTA1MDU1MDM0WjBWMQ4wDAYDVQQKDAVOb2tpYTEPMA0GA1UECwwGUGVvcGxlMRgwFgYKCZImiZPy LGQBAQwIMTAwMjQ2NzYxGTAXBgNVBAMMEFNhdm9sYWluZW4gVGVlbXUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDFPmbRVwuo52v+h6xnQUqokAx2xsHjmPBniEkzgtgBNJsFi838ATEg 1zsx+VotoJg7hMijcrQfpTAgW6gpLGnlmw5QQswrNK1zleOHb4pA5JguU3WhVKFkAH/6/2EU2k/9 m8Pb/gwP55cYg80R6fRmbdsWKhseXF/1isW/rJcWLmIYDg/rXfo3ixqtT9MroAMiuoXnb0ij1L2d Jj64LDp3Ld8Jo0qZzk3Fj4apo8PBd8eAH6HloVBJkxQcwAnv561A+Xi1GHZ2mafRYJGO+1uBDwyd g/8ybEXXA4MKo8lPKjBebYBUFvz80DBA/Lq74UysXkG23BSulcG4xQSYGlyzAgMBAAGjgfUwgfIw HwYDVR0jBBgwFoAUpySwPsWD7wQOUHZLGDLnylbRLLowGQYDVR0gBBIwEDAOBgwrBgEEAV4BMQYB BgQwOQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5ub2tpYS5jb20vTm9raWElMjBCSSUyMENB LmNybDAjBgNVHSUEHDAaBggrBgEFBQcDAgYEVR0lAAYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgeA MCUGA1UdEQQeMByBGnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBTGhbTJF0EX iagjymQo6GIuSQeRVDANBgkqhkiG9w0BAQUFAAOCAQEAqai6TxZ/BlMHZIhJNPriBPXkQhUlBkGA buJZ5sVm1HIQhWN8elZKjjJdHi1qWEKhMg7yHjEMZsyV8XAZzK0UnOqkpUnt+jnVkNZ9O7/jRtyK f4WUtq5jErc8Hlv4bbGFRHk1T7AuLLE52r1lYOdmoibnQp03QtlDvHUNa68G7jvzThJhieB7U1xh vH3yy0ktaVnWEgAylqf9yIUFjnqau5R6cE1Xo57IYPk/KitX0YF+OigEI/bOQVMi+fze93ZsAOJv /z6g/NGemvUgl5YSdX0uPQK6kEHf/sp/nZyUWWQ7OjtVSqkq2YuYEueQFxTfafl+78GWqgm6W/Bl 32laYzGCAuswggLnAgEBMEgwMzELMAkGA1UEBhMCRkkxDjAMBgNVBAoTBU5va2lhMRQwEgYDVQQD EwtOb2tpYSBCSSBDQQIRAIG+L6n5sD90G0G3JvADphgwCQYFKw4DAhoFAKCCAXgwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTExMDIxMDcxNTAyWjAjBgkqhkiG9w0B CQQxFgQU/Vl+6RAs5fBf/r2vYheh9YPWN/4wVgYJKwYBBAGCNxAEMUkwRzAzMQswCQYDVQQGEwJG STEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLx MFgGCyqGSIb3DQEJEAILMUmgRzAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNV BAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLxMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMA0GCSqGSIb3DQEBAQUABIIBAFTY/9GrEc/npbelzD08 P8a6qXVjWULhmI5reF2GjAJ2Rhpx1cHq+H1/4PTCzagCxvYmuwoBbHzd4jFDAd1m3Pbq9RNRHkZf Nfmv9WU5QyjgsmqQL2MnWWD3ne2PCplPCcAa3/lPVGccem1EEQUsD+glrTFBmQh+YExUxg/Bol1e oct6irB2Aem7wUWKMsrgOshO1Ytx3z+fwmqSwPNIrHFZ1Mk8bBOzg1rZDDH+UBPGQgVVl+dT9nvt lscLjzp8xfYdqocIOP/69pT3SJLEUwLXO7Znb7A1SlZ0y42hC+R9AZ8kpEElpWGnDBRl17UlziQv +IHz2NRL2+wcVeiFQ1wAAAAAAAA= ------=_NextPart_000_0164_01CC8FDA.4BCA8DB0-- From teemu.savolainen@nokia.com Fri Oct 21 00:22:03 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4072A1F0C59; Fri, 21 Oct 2011 00:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XsrjmcP6wB27; Fri, 21 Oct 2011 00:22:02 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id C55D41F0C3B; Fri, 21 Oct 2011 00:22:01 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p9L7LuO7002664; Fri, 21 Oct 2011 10:21:57 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 21 Oct 2011 10:21:53 +0300 Received: from 008-AM1MMR1-002.mgdnok.nokia.com (65.54.30.57) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 21 Oct 2011 09:21:53 +0200 Received: from 008-AM1MPN1-037.mgdnok.nokia.com ([169.254.7.8]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.01.0339.002; Fri, 21 Oct 2011 09:21:52 +0200 From: To: Thread-Topic: [dnsext] [mif] 2nd Last Call for MIF DNS server selection document Thread-Index: AQHMj6R+QZ795RKazUe9WQ1xF1IpB5WGZKHA Date: Fri, 21 Oct 2011 07:21:51 +0000 Message-ID: <916CE6CF87173740BC8A2CE44309696203784B63@008-AM1MPN1-037.mgdnok.nokia.com> References: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> <121DABD1-65E8-4275-8471-9FA38D25C434@nominet.org.uk> <916CE6CF87173740BC8A2CE44309696203783EE0@008-AM1MPN1-037.mgdnok.nokia.com> <4EA09791.8010705@gmail.com> <94C2E518-F34F-49E4-B15C-2CCCFAA96667@virtualized.org> <12477381-9F74-4C50-B576-47EE4322F6BC@network-heretics.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Company Confidential;Project=None; x-titus-version: 3.3.8.1 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IvQmQ0o/K2jquxqC2Uue5GHpzEuo3S9zNfeh3beuXC4d4U+9SoG2zegA7qMLdX6PTG17IL7pxR5S/KY/iCJNnn1c5UqLju8bmTWbhVRC5KYyRvx6Lux+omb+cjLr4ZT4xGr6EYlMoJAb4mKk7Ygo2IOCLEfvotq8eZrg90l9H1dML3IGXW5CR0VaroyKyJb6YmetiFAenF/tDgR293RVPdnMoKPAurwSeBTTqO8uNr6TcXVEvm613p4YTVwzPTjUYrSShwM2n81B2EdPx398YIM= x-originating-ip: [10.162.93.230] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_017A_01CC8FDB.3D0BB910" MIME-Version: 1.0 X-OriginalArrivalTime: 21 Oct 2011 07:21:53.0406 (UTC) FILETIME=[1B7631E0:01CC8FC2] X-Nokia-AV: Clean Cc: dhcwg@ietf.org, dnsop@ietf.org, mif@ietf.org, dnsext@ietf.org Subject: Re: [mif] [dnsext] 2nd Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 07:22:03 -0000 ------=_NextPart_000_017A_01CC8FDB.3D0BB910 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable (resending only to mailing list recipients) Brian, Do you agree that nodes' behavioral differences between "foo" and "foo." names is out of the scope of this particular MIF draft? There could perhaps be another draft, which would say that if name is = "foo" it should not be appended with search lists but "foo." might? And = whatever other differences in their handling would be, and what impacts it would = have e.g. intranet designers? Please see also in another email my suggestion for section 4.6 text. = That text should now allow possible changes for the bare name handling while still allowing coexistence with DNS server selection. Best regards, Teemu > -----Original Message----- > From: dnsext-bounces@ietf.org [mailto:dnsext-bounces@ietf.org] On = Behalf > Of ext Brian Dickson > Sent: 21. lokakuuta 2011 06:16 > To: Keith Moore > Cc: mif@ietf.org; dnsop@ietf.org; dnsext@ietf.org; pk@isoc.de; > john_brzozowski@cable.comcast.com; dhcwg@ietf.org; > denghui02@hotmail.com; Brian E Carpenter > Subject: Re: [dnsext] [mif] 2nd Last Call for MIF DNS server selection > document >=20 > I think we can skirt this rat-hole if we separate the two following distinct > cases: >=20 > Case A: "foo" > Case B: "foo." (with terminating "dot"). >=20 > Case B meets the technical requirements of a Fully Qualified Domain = Name, > structurally speaking. > Case A does not. >=20 > Case A is a "bare name", case B is not. >=20 > If we stick to the notions of FQDN versus anything else, we can avoid > entering the rat-hole, IMHO. >=20 > (I.e., We don't need to get into any issues over the number of labels = in an > FQDN; an FQDN does not require treatment, special or otherwise; etc., etc.,) >=20 > Brian Dickson >=20 > On Thu, Oct 20, 2011 at 9:38 PM, Keith Moore heretics.com> wrote: > > > > On Oct 20, 2011, at 9:19 PM, David Conrad wrote: > > > >> On Oct 20, 2011, at 6:07 PM, Keith Moore wrote: > >>> It might that IETF should consider "bare names" out of its scope, except > perhaps to say that they're not DNS names, they don't have to = necessarily be > mappable to DNS names, and that their use and behavior is host and > application-dependent. > >> > >> Can we please not redefine what a "DNS name" is to meet a = particular > agenda? > > > > I wasn't trying to do so. > > > >> Isn't it sufficient to say a 'bare name' does not conform to a = hostname as > defined in RFC 952 and modified by RFCs 1122? > > > > Probably. =A0I'm just suggesting that trying to nail down the = behavior of such > names is probably a rathole as well as likely to cause significant disruption. > > > > _______________________________________________ > > dnsext mailing list > > dnsext@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsext > > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext ------=_NextPart_000_017A_01CC8FDB.3D0BB910 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOuzCCAzYw ggIeoAMCAQICBDpVqdkwDQYJKoZIhvcNAQEFBQAwKTEOMAwGA1UEChMFTm9raWExFzAVBgNVBAMT Dk5va2lhICBSb290IENBMB4XDTAxMDEwNTExMDUwNVoXDTE2MDEwMjExMDUwNVowKTEOMAwGA1UE ChMFTm9raWExFzAVBgNVBAMTDk5va2lhICBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsrTy8gLmr4LYvp0khVUVHw7ascdl+Cjr+yI5MlZ6J/U6Qsvkiqthgqq8rPcLV0P1 92TfBr27VgKEeCaZe0icS1jC2spM/wRv3j2WxdkKxb9kDJtuCNJaRBqvi5vGTHB15nmEmKuL5f3i rAxeHqPjgS496oWcudzFT1e7Xrc/gWGFYd72+/ykIFXjWOMZv6QpxD8x1hLPyh2YVXRk9U7N7pvm RQNX29g4SCFJY2BBIa5JPlwIF8Nc9IePaC/E/2M4tGMtiOOZlm99EoL7N0hJZtFSvUwdCBud/viH 4DgsKGjNkNKi6pAHc9IaXB6tIykcoYp+L+oe/3+cuEJaCj1EKwIDAQABo2YwZDASBgNVHRMBAf8E CDAGAQH/AgEEMB0GA1UdDgQWBBSNjfefoQ0AITLvqe0iruA79NB9sDAfBgNVHSMEGDAWgBSNjfef oQ0AITLvqe0iruA79NB9sDAOBgNVHQ8BAf8EBAMCAYYwDQYJKoZIhvcNAQEFBQADggEBAIGEPql2 TALyKi/h1J+Mh5XolAtYppcSOLMtBkoA7ZovGBDNvl0VbZs8AAojJqkUoWBB+L6DKyl/jKhNfKcu rWRGRyj7pnbxrKLsI3gmWNWkyo2b60wJwe9fqPD5ZQy3oEiMit9l0Ba6il/k2GqYopUCNMa7mfeb E2LeBy5ChYMiCi97UQSJvAdzEYylTJw8Awc6AiM2Ve5N+XxsmKgNf/2A/5IJ3EZZ+wFRmkI4062A oNU302rqAt0HH88jzoUF4AfYHWl6HpYhGXFbcX44rHINyPmFBRxLYIFJ6ZWUr/mXpL/e6rqFtNWO kV6UoJND7OVZkbLh7F1+lcqXRU8TPBMwggOHMIICb6ADAgECAgRBtbHpMA0GCSqGSIb3DQEBBQUA MCkxDjAMBgNVBAoTBU5va2lhMRcwFQYDVQQDEw5Ob2tpYSAgUm9vdCBDQTAeFw0wNjAzMzAwOTU3 MTFaFw0xNjAxMDIxMTA1MDVaMDMxCzAJBgNVBAYTAkZJMQ4wDAYDVQQKEwVOb2tpYTEUMBIGA1UE AxMLTm9raWEgQkkgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDtFCg3QEjSCg6T IUxoWsNwELh8bBNiUQPCPmg8c2DHQYXWWCSCMb+S0Fvh1qqI1xt+XnzyFq+5eqzGzDj4UaBcG+d9 qxrCFly8sHyoPTryyPrR0EI2UUDWwfS6ojhqgwghRqo8G38TjFusyBtLub/5L6yvWYSOHD+JcB+q VM2fbkArPYK4Ydv8WG/DbHjGn0gKq0zwpVZKI/gCK/QALYvte02NXseqvY9/GOyLtjy3Z8erFv71 KKTq+gxI/7DK55pJf3PoD+kT4kyGm6EF9DTdK4ojMdar17uyX0IOZz/4vkkF0d+60nmnLX63FJPA jUyB0HUNJ32NXDo9UsM38aoNAgMBAAGjgawwgakwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAI MAYGBFUdIAAwDgYDVR0PAQH/BAQDAgGGMFQGA1UdIwRNMEuAFI2N95+hDQAhMu+p7SKu4Dv00H2w oS2kKzApMQ4wDAYDVQQKEwVOb2tpYTEXMBUGA1UEAxMOTm9raWEgIFJvb3QgQ0GCBDpVqdkwHQYD VR0OBBYEFKcksD7Fg+8EDlB2Sxgy58pW0Sy6MA0GCSqGSIb3DQEBBQUAA4IBAQAC3lEUplDlVNOT Pjz/XFezXx2bV2XbCFindhA3F815Egi55H6/cYezEjoP4QLNEGGl2I3aLvkn5A0T8I4pbiFPhIiu B/frbbGg6k6GjQLe/bFQ8F1mAOOR+GyneKZFPfzaRV0jiIR9QqnMXTf8RvKkCJyFj10MZVsLIy/Y uBkzeP3JhzDhUdtPfwmJN6ZbIhH5uR/2BwAGtgQknb8WX3I4wnhWtMUxB8XmayayYs8qWYeIiVkI FV+sLTkWUWVvvKUjyakBpbAW2vUP84DYsJ8TL1YefNjf/nIOByMcORLuV/1gPjyv00qJbcB59AA+ iXe3zIo8QNcgXG0uPQQFmrGDMIID5DCCAsygAwIBAgIQMH5apak8lEy6LmLlLsJy8TANBgkqhkiG 9w0BAQUFADAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJ IENBMB4XDTExMDkwNjA1NTIwNFoXDTE0MDkwNjA1NTIwNFowVjEOMAwGA1UECgwFTm9raWExDzAN BgNVBAsMBlBlb3BsZTEYMBYGCgmSJomT8ixkAQEMCDEwMDI0Njc2MRkwFwYDVQQDDBBTYXZvbGFp bmVuIFRlZW11MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAshEsmw6Yiz6XWX26oF+I s5fsfE1OfCjOelclmtqCiIgXND5klkNOBs2d4ZGzgD9mN+XnTZnOTh249c2WxPBugf12DCcDmBAJ gL+VuWUJVBTE5NRchm/O8nZnZsRFst+gAC9/Juykh4+EYewZ7QbpnlwW7hNpj8eH+rMr+OZHKzdp KTftgVjmuF4JJ/cPMQUjL8SuGj+zBW6IWPOZdqkEMtf7Pr8kkYbZsh0SgJ0ceRHZ7Uc06mB/y+C1 UnJPxehTTdu8tpCjdzXgBw/H2uuW1J3qdHbCfbuDILql8V8RiZKubcZLhdsD3Jvj8qK0DGWBJa6x p90q5p3pLE8LvAeCgQIDAQABo4HQMIHNMA4GA1UdDwEB/wQEAwIEMDAfBgNVHSMEGDAWgBSnJLA+ xYPvBA5QdksYMufKVtEsujAZBgNVHSAEEjAQMA4GDCsGAQQBXgExBgEHAzA5BgNVHR8EMjAwMC6g LKAqhihodHRwOi8vY3JsLm5va2lhLmNvbS9Ob2tpYSUyMEJJJTIwQ0EuY3JsMCUGA1UdEQQeMByB GnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBQTRzvZsgmQrAGCeuzdHTGAC6Jg UzANBgkqhkiG9w0BAQUFAAOCAQEACmPVsdi07pjK5gDa+W5JlE2C74kVVsB8alBqfioYeR5At2FG B7sua4Dz5H7TJMpZ1jYFeI+zjexD5f+beY2IlV15lMoWD+5e38QlLYjwfe2LAyvdzBKXW0e0U6Bt p78ft4gyVak1X+Db+ebR+FNHUOMNhm+yK3w9sy5ZQzBFusIx4OgxGvcZhyhmd9WjipSTalgPwgqV Ju2aPADCG++OEXmgEWRLsR4yNopkgK4ftVqrN5uUtLs83qdeXTRcNRiET1IOx5zmYFZ6q3gjKIx5 iyuxcDeYas93vVHUcaRRYpsoby5CHq7Z/j/TQhtqO/knWuxLFFiCUgdGKMKrRkg29DCCBAowggLy oAMCAQICEQCBvi+p+bA/dBtBtybwA6YYMA0GCSqGSIb3DQEBBQUAMDMxCzAJBgNVBAYTAkZJMQ4w DAYDVQQKEwVOb2tpYTEUMBIGA1UEAxMLTm9raWEgQkkgQ0EwHhcNMTEwOTA2MDU1MDM0WhcNMTMw OTA1MDU1MDM0WjBWMQ4wDAYDVQQKDAVOb2tpYTEPMA0GA1UECwwGUGVvcGxlMRgwFgYKCZImiZPy LGQBAQwIMTAwMjQ2NzYxGTAXBgNVBAMMEFNhdm9sYWluZW4gVGVlbXUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDFPmbRVwuo52v+h6xnQUqokAx2xsHjmPBniEkzgtgBNJsFi838ATEg 1zsx+VotoJg7hMijcrQfpTAgW6gpLGnlmw5QQswrNK1zleOHb4pA5JguU3WhVKFkAH/6/2EU2k/9 m8Pb/gwP55cYg80R6fRmbdsWKhseXF/1isW/rJcWLmIYDg/rXfo3ixqtT9MroAMiuoXnb0ij1L2d Jj64LDp3Ld8Jo0qZzk3Fj4apo8PBd8eAH6HloVBJkxQcwAnv561A+Xi1GHZ2mafRYJGO+1uBDwyd g/8ybEXXA4MKo8lPKjBebYBUFvz80DBA/Lq74UysXkG23BSulcG4xQSYGlyzAgMBAAGjgfUwgfIw HwYDVR0jBBgwFoAUpySwPsWD7wQOUHZLGDLnylbRLLowGQYDVR0gBBIwEDAOBgwrBgEEAV4BMQYB BgQwOQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5ub2tpYS5jb20vTm9raWElMjBCSSUyMENB LmNybDAjBgNVHSUEHDAaBggrBgEFBQcDAgYEVR0lAAYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgeA MCUGA1UdEQQeMByBGnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBTGhbTJF0EX iagjymQo6GIuSQeRVDANBgkqhkiG9w0BAQUFAAOCAQEAqai6TxZ/BlMHZIhJNPriBPXkQhUlBkGA buJZ5sVm1HIQhWN8elZKjjJdHi1qWEKhMg7yHjEMZsyV8XAZzK0UnOqkpUnt+jnVkNZ9O7/jRtyK f4WUtq5jErc8Hlv4bbGFRHk1T7AuLLE52r1lYOdmoibnQp03QtlDvHUNa68G7jvzThJhieB7U1xh vH3yy0ktaVnWEgAylqf9yIUFjnqau5R6cE1Xo57IYPk/KitX0YF+OigEI/bOQVMi+fze93ZsAOJv /z6g/NGemvUgl5YSdX0uPQK6kEHf/sp/nZyUWWQ7OjtVSqkq2YuYEueQFxTfafl+78GWqgm6W/Bl 32laYzGCAuswggLnAgEBMEgwMzELMAkGA1UEBhMCRkkxDjAMBgNVBAoTBU5va2lhMRQwEgYDVQQD EwtOb2tpYSBCSSBDQQIRAIG+L6n5sD90G0G3JvADphgwCQYFKw4DAhoFAKCCAXgwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTExMDIxMDcyMTQ3WjAjBgkqhkiG9w0B CQQxFgQU/bt/B0rQv3tXWH/VWaFd5Jxuc+UwVgYJKwYBBAGCNxAEMUkwRzAzMQswCQYDVQQGEwJG STEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLx MFgGCyqGSIb3DQEJEAILMUmgRzAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNV BAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLxMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMA0GCSqGSIb3DQEBAQUABIIBAH4fWcHUHaqLq7VSsA/L VPnpWJ409zY/ASwFn0TVo/n3fnC9W5E2KgpzOFLjaa8A2Fxn2GB6jRhRyAVn/LBRjYXCPdm0q47m Ce0KpR1DY4ekloMqJnRGE6t1Ye4eodux9DGCQ4TErS7Dr4k6ytHjW0T4kdJ+HIZex+oeTuxZRQKE 7Hr6vdn6iFnSoYVskxrHAfH3vkhfIKCO1hpm4vppevOrtwPqy1j/XWvg7B8GF0z/xu+dbeRyEXOZ a9ZJ1IvGNRij+ouTTljaH8OKW8LE3B2mac5QfVkQjNxnX6bL3dC6+fnCqgCEa3JWRsK7/8bpPwym wc0THHNYNSMAq7rAU7oAAAAAAAA= ------=_NextPart_000_017A_01CC8FDB.3D0BB910-- From Ray.Bellis@nominet.org.uk Fri Oct 21 00:46:42 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A134521F8573; Fri, 21 Oct 2011 00:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.392 X-Spam-Level: X-Spam-Status: No, score=-9.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lpy8rUyDKuk1; Fri, 21 Oct 2011 00:46:42 -0700 (PDT) Received: from mx4.nominet.org.uk (mail.nominet.org.uk [213.248.199.24]) by ietfa.amsl.com (Postfix) with ESMTP id 139D921F8558; Fri, 21 Oct 2011 00:46:39 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: Content-ID:Content-Transfer-Encoding:MIME-Version; b=4lIPe9h/lP5oeitSpD+/S8S+PqTENj9FOMu10FwfIwiNacJY/oDbnPTO qOPsByGxsWjgCql8yraPUdsXbgmm00naRICl39YJfvWSnOFkuaTHFyD4E 4FsO1lKPmtn61h3; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1319183201; x=1350719201; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20[mif]=20[dnsext]=202nd=20Last=20Call=20 for=20MIF=20DNS=20server=09selection=0D=0A=09document |Date:=20Fri,=2021=20Oct=202011=2007:46:30=20+0000 |Message-ID:=20<7B1BA1C2-3EC4-48B7-B02F-85E78456D726@nomi net.org.uk>|To:=20"=20=20"=0D=0A=09|CC:=20""=20,=0D=0A=09""=20,=20""=20,=0D =0A=09""=20,=20""=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |Content-ID:=20<629d8135-1b4c-46b1-8d20-8923cdfff68d> |In-Reply-To:=20<916CE6CF87173740BC8A2CE44309696203784B63 @008-AM1MPN1-037.mgdnok.nokia.com>|References:=20=0D=0A=20<916CE6CF87 173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nok ia.com>=0D=0A=20<121DABD1-65E8-4275-8471-9FA38D25C434@nom inet.org.uk>=0D=0A=20<916CE6CF87173740BC8A2CE443096962037 83EE0@008-AM1MPN1-037.mgdnok.nokia.com>=0D=0A=20<4EA09791 .8010705@gmail.com>=0D=0A=20=0D=0A=20<94C2E518-F34F-49E 4-B15C-2CCCFAA96667@virtualized.org>=0D=0A=20<12477381-9F 74-4C50-B576-47EE4322F6BC@network-heretics.com>=0D=0A=20< CAH1iCiqsN-R87VK3vKityPsY+NXA=3D0DRASYf_vmBSy8gvYwHdQ@mai l.gmail.com>=0D=0A=20<916CE6CF87173740BC8A2CE443096962037 84B63@008-AM1MPN1-037.mgdnok.nokia.com>; bh=WZZN/BdQ6CyR1gwX5EH1rUOG3EV73LdrRq/d3r4AVMU=; b=dGbdwyTSANfvyA3UCm7GUYTK2WtbVFjuaggnRl9oH9b3IiNjmVuDtnwF yEsqKpD6aFmX6k4Dni7uySvW8gMK8rmgvHJiCna+3tFlgWS43IRTtMmKi XzPTa6G/XgH0xOL; X-IronPort-AV: E=Sophos;i="4.69,384,1315177200"; d="scan'208";a="29100681" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx4.nominet.org.uk with ESMTP; 21 Oct 2011 08:46:32 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%19]) with mapi; Fri, 21 Oct 2011 08:46:32 +0100 From: Ray Bellis To: " " Thread-Topic: [mif] [dnsext] 2nd Last Call for MIF DNS server selection document Thread-Index: AQHMj8Imxcbx/iS/+UW6nUgghEBBq5WGWs8A Date: Fri, 21 Oct 2011 07:46:30 +0000 Message-ID: <7B1BA1C2-3EC4-48B7-B02F-85E78456D726@nominet.org.uk> References: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> <121DABD1-65E8-4275-8471-9FA38D25C434@nominet.org.uk> <916CE6CF87173740BC8A2CE44309696203783EE0@008-AM1MPN1-037.mgdnok.nokia.com> <4EA09791.8010705@gmail.com> <94C2E518-F34F-49E4-B15C-2CCCFAA96667@virtualized.org> <12477381-9F74-4C50-B576-47EE4322F6BC@network-heretics.com> <916CE6CF87173740BC8A2CE44309696203784B63@008-AM1MPN1-037.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE44309696203784B63@008-AM1MPN1-037.mgdnok.nokia.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-ID: <629d8135-1b4c-46b1-8d20-8923cdfff68d> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" , "" , "" , "" Subject: Re: [mif] [dnsext] 2nd Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 07:46:42 -0000 On 21 Oct 2011, at 08:21, wrote: > Do you agree that nodes' behavioral differences between "foo" and "foo." > names is out of the scope of this particular MIF draft? In my view neither the draft nor MIF should be encoding any changes to clie= nt name resolution behaviour that depend on the "bareness" of a supplied na= me. Existing OSes have many varying algorithms for deciding which name service(= s) to use to resolve any particular name, some of which have user-configura= ble knobs (e.g. "options: ndots" in /etc/resolv.conf). By all means use server selection once the OS has decided that "DNS" is the= correct name service, but that algorithm shouldn't IMHO impact or otherwis= e specify the prior name service selection algorithm. > There could perhaps be another draft, which would say that if name is "fo= o" > it should not be appended with search lists but "foo." might? If anything it would be the other way around - 'foo.' is explicitly already= full qualified, and MUST NOT be appended with search lists. Ray From drc@virtualized.org Thu Oct 20 18:19:44 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF4BB11E8096; Thu, 20 Oct 2011 18:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2coio1NjPHS2; Thu, 20 Oct 2011 18:19:44 -0700 (PDT) Received: from trantor.virtualized.org (trantor.virtualized.org [199.48.134.42]) by ietfa.amsl.com (Postfix) with ESMTP id 5B1EE11E8091; Thu, 20 Oct 2011 18:19:44 -0700 (PDT) Received: from [10.0.1.5] (c-24-4-109-25.hsd1.ca.comcast.net [24.4.109.25]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: drc) by trantor.virtualized.org (Postfix) with ESMTPSA id 1B4431704E; Fri, 21 Oct 2011 01:19:43 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: David Conrad In-Reply-To: Date: Thu, 20 Oct 2011 18:19:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <94C2E518-F34F-49E4-B15C-2CCCFAA96667@virtualized.org> References: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> <121DABD1-65E8-4275-8471-9FA38D25C434@nominet.org.uk> <916CE6CF87173740BC8A2CE44309696203783EE0@008-AM1MPN1-037.mgdnok.nokia.com> <4EA09791.8010705@gmail.com> To: Keith Moore X-Mailer: Apple Mail (2.1251.1) X-Mailman-Approved-At: Fri, 21 Oct 2011 04:07:28 -0700 Cc: mif@ietf.org, dnsop@ietf.org, dnsext@ietf.org, pk@isoc.de, john_brzozowski@cable.comcast.com, dhcwg@ietf.org, denghui02@hotmail.com Subject: Re: [mif] [dnsext] 2nd Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 01:19:44 -0000 On Oct 20, 2011, at 6:07 PM, Keith Moore wrote: > It might that IETF should consider "bare names" out of its scope, = except perhaps to say that they're not DNS names, they don't have to = necessarily be mappable to DNS names, and that their use and behavior is = host and application-dependent. Can we please not redefine what a "DNS name" is to meet a particular = agenda? Isn't it sufficient to say a 'bare name' does not conform to a hostname = as defined in RFC 952 and modified by RFCs 1122? Regards, -drc From marka@isc.org Thu Oct 20 18:50:13 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34D8721F8A35; Thu, 20 Oct 2011 18:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dj2nn88JorR8; Thu, 20 Oct 2011 18:50:12 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 651AF21F8634; Thu, 20 Oct 2011 18:50:10 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 069365F988D; Fri, 21 Oct 2011 01:49:54 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 3F472216C6A; Fri, 21 Oct 2011 01:49:52 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id B2A8815ACCA7; Fri, 21 Oct 2011 12:49:49 +1100 (EST) To: David Conrad From: Mark Andrews References: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> <121DABD1-65E8-4275-8471-9FA38D25C434@nominet.org.uk> <916CE6CF87173740BC8A2CE44309696203783EE0@008-AM1MPN1-037.mgdnok.nokia.com> <4EA09791.8010705@gmail.com> <94C2E518-F34F-49E4-B15C-2CCCFAA96667@virtualized.org> In-reply-to: Your message of "Thu, 20 Oct 2011 18:19:41 PDT." <94C2E518-F34F-49E4-B15C-2CCCFAA96667@virtualized.org> Date: Fri, 21 Oct 2011 12:49:49 +1100 Message-Id: <20111021014949.B2A8815ACCA7@drugs.dv.isc.org> X-Mailman-Approved-At: Fri, 21 Oct 2011 04:07:28 -0700 Cc: mif@ietf.org, Keith Moore , dnsop@ietf.org, dnsext@ietf.org, pk@isoc.de, john_brzozowski@cable.comcast.com, dhcwg@ietf.org, denghui02@hotmail.com Subject: Re: [mif] [dnsext] 2nd Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 01:50:13 -0000 In message <94C2E518-F34F-49E4-B15C-2CCCFAA96667@virtualized.org>, David Conrad writes: > On Oct 20, 2011, at 6:07 PM, Keith Moore wrote: > > It might that IETF should consider "bare names" out of its scope, except pe > rhaps to say that they're not DNS names, they don't have to necessarily be ma > ppable to DNS names, and that their use and behavior is host and application- > dependent. > > Can we please not redefine what a "DNS name" is to meet a particular agenda? > > Isn't it sufficient to say a 'bare name' does not conform to a hostname as de > fined in RFC 952 and modified by RFCs 1122? The problem is that they *are* hostnames, just not "domain style" (RFC 952) or "hierarchical" (RFC 921) hostnames. > Regards, > -drc > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From brian.peter.dickson@gmail.com Thu Oct 20 20:15:35 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F31FA1F0C41; Thu, 20 Oct 2011 20:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.522 X-Spam-Level: X-Spam-Status: No, score=-3.522 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QnpfhUF6OSF; Thu, 20 Oct 2011 20:15:34 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id AC1C11F0C3B; Thu, 20 Oct 2011 20:15:33 -0700 (PDT) Received: by bkas6 with SMTP id s6so4925088bka.31 for ; Thu, 20 Oct 2011 20:15:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=4/MacuvD/MPyqs8qwmxiyGvn1PLyk5nLFdimmTH87R0=; b=obGZ8HsKsSgUSkRNGoox557xXXrkrgDONSBC9WSP4XOH+a/XHYcj9Ky+0r3k2m9bNY CnqO3lF6zND+t0HUm8TPafrIvAwNQHCocrqWS8gbUgD4htJyG2NwP9FNaFH48wJA/JP2 Y6+f6SoVxXR8QSCsxjLmDkJm8DWIk/nk68dgg= MIME-Version: 1.0 Received: by 10.223.77.77 with SMTP id f13mr14270480fak.19.1319166932717; Thu, 20 Oct 2011 20:15:32 -0700 (PDT) Received: by 10.223.16.78 with HTTP; Thu, 20 Oct 2011 20:15:32 -0700 (PDT) In-Reply-To: <12477381-9F74-4C50-B576-47EE4322F6BC@network-heretics.com> References: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> <121DABD1-65E8-4275-8471-9FA38D25C434@nominet.org.uk> <916CE6CF87173740BC8A2CE44309696203783EE0@008-AM1MPN1-037.mgdnok.nokia.com> <4EA09791.8010705@gmail.com> <94C2E518-F34F-49E4-B15C-2CCCFAA96667@virtualized.org> <12477381-9F74-4C50-B576-47EE4322F6BC@network-heretics.com> Date: Thu, 20 Oct 2011 23:15:32 -0400 Message-ID: From: Brian Dickson To: Keith Moore Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 21 Oct 2011 04:07:28 -0700 Cc: mif@ietf.org, dnsop@ietf.org, David Conrad , dnsext@ietf.org, pk@isoc.de, john_brzozowski@cable.comcast.com, dhcwg@ietf.org, denghui02@hotmail.com Subject: Re: [mif] [dnsext] 2nd Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 03:15:35 -0000 I think we can skirt this rat-hole if we separate the two following distinct cases: Case A: "foo" Case B: "foo." (with terminating "dot"). Case B meets the technical requirements of a Fully Qualified Domain Name, structurally speaking. Case A does not. Case A is a "bare name", case B is not. If we stick to the notions of FQDN versus anything else, we can avoid entering the rat-hole, IMHO. (I.e., We don't need to get into any issues over the number of labels in an FQDN; an FQDN does not require treatment, special or otherwise; etc., etc.,) Brian Dickson On Thu, Oct 20, 2011 at 9:38 PM, Keith Moore w= rote: > > On Oct 20, 2011, at 9:19 PM, David Conrad wrote: > >> On Oct 20, 2011, at 6:07 PM, Keith Moore wrote: >>> It might that IETF should consider "bare names" out of its scope, excep= t perhaps to say that they're not DNS names, they don't have to necessarily= be mappable to DNS names, and that their use and behavior is host and appl= ication-dependent. >> >> Can we please not redefine what a "DNS name" is to meet a particular age= nda? > > I wasn't trying to do so. > >> Isn't it sufficient to say a 'bare name' does not conform to a hostname = as defined in RFC 952 and modified by RFCs 1122? > > Probably. =A0I'm just suggesting that trying to nail down the behavior of= such names is probably a rathole as well as likely to cause significant di= sruption. > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > From teemu.savolainen@nokia.com Fri Oct 21 00:15:16 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA90911E808C; Fri, 21 Oct 2011 00:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2lvJQYVyTRK; Fri, 21 Oct 2011 00:15:15 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id D5CFD11E8095; Fri, 21 Oct 2011 00:15:14 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p9L7F7lh025099; Fri, 21 Oct 2011 10:15:10 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 21 Oct 2011 10:15:07 +0300 Received: from 008-AM1MMR1-004.mgdnok.nokia.com (65.54.30.59) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 21 Oct 2011 09:15:07 +0200 Received: from 008-AM1MPN1-037.mgdnok.nokia.com ([169.254.7.8]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0339.002; Fri, 21 Oct 2011 09:15:06 +0200 From: To: , Thread-Topic: [dnsext] [mif] 2nd Last Call for MIF DNS server selection document Thread-Index: AQHMj6R+QZ795RKazUe9WQ1xF1IpB5WGXdfw Date: Fri, 21 Oct 2011 07:15:06 +0000 Message-ID: <916CE6CF87173740BC8A2CE44309696203784B27@008-AM1MPN1-037.mgdnok.nokia.com> References: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> <121DABD1-65E8-4275-8471-9FA38D25C434@nominet.org.uk> <916CE6CF87173740BC8A2CE44309696203783EE0@008-AM1MPN1-037.mgdnok.nokia.com> <4EA09791.8010705@gmail.com> <94C2E518-F34F-49E4-B15C-2CCCFAA96667@virtualized.org> <12477381-9F74-4C50-B576-47EE4322F6BC@network-heretics.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Company Confidential;Project=None; x-titus-version: 3.3.8.1 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IvQmQ0o/K2jquxqC2Uue5GHpzEuo3S9zNfeh3beuXC4d4U+9SoG2zegA7qMLdX6PTG17IL7pxR5S/KY/iCJNnn1c5UqLju8bmTWbhVRC5KYyRvx6Lux+omb+cjLr4ZT4xGr6EYlMoJAb4mKk7Ygo2IOCLEfvotq8eZrg90l9H1dML3IGXW5CR0VaroyKyJb6YmetiFAenF/tDgR293RVPdnMoKPAurwSeBTTqO8uNr6TcXVEvm613p4YTVwzPTjUYrSShwM2n81B2EdPx398YIM= x-originating-ip: [10.162.93.230] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0168_01CC8FDA.4CD5BC20" MIME-Version: 1.0 X-OriginalArrivalTime: 21 Oct 2011 07:15:07.0820 (UTC) FILETIME=[29B6AEC0:01CC8FC1] X-Nokia-AV: Clean X-Mailman-Approved-At: Fri, 21 Oct 2011 04:07:28 -0700 Cc: mif@ietf.org, dnsop@ietf.org, dnsext@ietf.org, pk@isoc.de, john_brzozowski@cable.comcast.com, dhcwg@ietf.org, denghui02@hotmail.com Subject: Re: [mif] [dnsext] 2nd Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 07:15:17 -0000 ------=_NextPart_000_0168_01CC8FDA.4CD5BC20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Brian, Do you agree that nodes' behavioral differences between "foo" and "foo." names is out of the scope of this particular MIF draft? There could perhaps be another draft, which would say that if name is = "foo" it should not be appended with search lists but "foo." might? And = whatever other differences in their handling would be, and what impacts it would = have e.g. intranet designers? Please see also in another email my suggestion for section 4.6 text. = That text should now allow possible changes for the bare name handling while still allowing coexistence with DNS server selection. Best regards, Teemu > -----Original Message----- > From: dnsext-bounces@ietf.org [mailto:dnsext-bounces@ietf.org] On = Behalf > Of ext Brian Dickson > Sent: 21. lokakuuta 2011 06:16 > To: Keith Moore > Cc: mif@ietf.org; dnsop@ietf.org; dnsext@ietf.org; pk@isoc.de; > john_brzozowski@cable.comcast.com; dhcwg@ietf.org; > denghui02@hotmail.com; Brian E Carpenter > Subject: Re: [dnsext] [mif] 2nd Last Call for MIF DNS server selection > document >=20 > I think we can skirt this rat-hole if we separate the two following distinct > cases: >=20 > Case A: "foo" > Case B: "foo." (with terminating "dot"). >=20 > Case B meets the technical requirements of a Fully Qualified Domain = Name, > structurally speaking. > Case A does not. >=20 > Case A is a "bare name", case B is not. >=20 > If we stick to the notions of FQDN versus anything else, we can avoid > entering the rat-hole, IMHO. >=20 > (I.e., We don't need to get into any issues over the number of labels = in an > FQDN; an FQDN does not require treatment, special or otherwise; etc., etc.,) >=20 > Brian Dickson >=20 > On Thu, Oct 20, 2011 at 9:38 PM, Keith Moore heretics.com> wrote: > > > > On Oct 20, 2011, at 9:19 PM, David Conrad wrote: > > > >> On Oct 20, 2011, at 6:07 PM, Keith Moore wrote: > >>> It might that IETF should consider "bare names" out of its scope, except > perhaps to say that they're not DNS names, they don't have to = necessarily be > mappable to DNS names, and that their use and behavior is host and > application-dependent. > >> > >> Can we please not redefine what a "DNS name" is to meet a = particular > agenda? > > > > I wasn't trying to do so. > > > >> Isn't it sufficient to say a 'bare name' does not conform to a = hostname as > defined in RFC 952 and modified by RFCs 1122? > > > > Probably. =A0I'm just suggesting that trying to nail down the = behavior of such > names is probably a rathole as well as likely to cause significant disruption. > > > > _______________________________________________ > > dnsext mailing list > > dnsext@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsext > > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext ------=_NextPart_000_0168_01CC8FDA.4CD5BC20 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOuzCCAzYw ggIeoAMCAQICBDpVqdkwDQYJKoZIhvcNAQEFBQAwKTEOMAwGA1UEChMFTm9raWExFzAVBgNVBAMT Dk5va2lhICBSb290IENBMB4XDTAxMDEwNTExMDUwNVoXDTE2MDEwMjExMDUwNVowKTEOMAwGA1UE ChMFTm9raWExFzAVBgNVBAMTDk5va2lhICBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsrTy8gLmr4LYvp0khVUVHw7ascdl+Cjr+yI5MlZ6J/U6Qsvkiqthgqq8rPcLV0P1 92TfBr27VgKEeCaZe0icS1jC2spM/wRv3j2WxdkKxb9kDJtuCNJaRBqvi5vGTHB15nmEmKuL5f3i rAxeHqPjgS496oWcudzFT1e7Xrc/gWGFYd72+/ykIFXjWOMZv6QpxD8x1hLPyh2YVXRk9U7N7pvm RQNX29g4SCFJY2BBIa5JPlwIF8Nc9IePaC/E/2M4tGMtiOOZlm99EoL7N0hJZtFSvUwdCBud/viH 4DgsKGjNkNKi6pAHc9IaXB6tIykcoYp+L+oe/3+cuEJaCj1EKwIDAQABo2YwZDASBgNVHRMBAf8E CDAGAQH/AgEEMB0GA1UdDgQWBBSNjfefoQ0AITLvqe0iruA79NB9sDAfBgNVHSMEGDAWgBSNjfef oQ0AITLvqe0iruA79NB9sDAOBgNVHQ8BAf8EBAMCAYYwDQYJKoZIhvcNAQEFBQADggEBAIGEPql2 TALyKi/h1J+Mh5XolAtYppcSOLMtBkoA7ZovGBDNvl0VbZs8AAojJqkUoWBB+L6DKyl/jKhNfKcu rWRGRyj7pnbxrKLsI3gmWNWkyo2b60wJwe9fqPD5ZQy3oEiMit9l0Ba6il/k2GqYopUCNMa7mfeb E2LeBy5ChYMiCi97UQSJvAdzEYylTJw8Awc6AiM2Ve5N+XxsmKgNf/2A/5IJ3EZZ+wFRmkI4062A oNU302rqAt0HH88jzoUF4AfYHWl6HpYhGXFbcX44rHINyPmFBRxLYIFJ6ZWUr/mXpL/e6rqFtNWO kV6UoJND7OVZkbLh7F1+lcqXRU8TPBMwggOHMIICb6ADAgECAgRBtbHpMA0GCSqGSIb3DQEBBQUA MCkxDjAMBgNVBAoTBU5va2lhMRcwFQYDVQQDEw5Ob2tpYSAgUm9vdCBDQTAeFw0wNjAzMzAwOTU3 MTFaFw0xNjAxMDIxMTA1MDVaMDMxCzAJBgNVBAYTAkZJMQ4wDAYDVQQKEwVOb2tpYTEUMBIGA1UE AxMLTm9raWEgQkkgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDtFCg3QEjSCg6T IUxoWsNwELh8bBNiUQPCPmg8c2DHQYXWWCSCMb+S0Fvh1qqI1xt+XnzyFq+5eqzGzDj4UaBcG+d9 qxrCFly8sHyoPTryyPrR0EI2UUDWwfS6ojhqgwghRqo8G38TjFusyBtLub/5L6yvWYSOHD+JcB+q VM2fbkArPYK4Ydv8WG/DbHjGn0gKq0zwpVZKI/gCK/QALYvte02NXseqvY9/GOyLtjy3Z8erFv71 KKTq+gxI/7DK55pJf3PoD+kT4kyGm6EF9DTdK4ojMdar17uyX0IOZz/4vkkF0d+60nmnLX63FJPA jUyB0HUNJ32NXDo9UsM38aoNAgMBAAGjgawwgakwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAI MAYGBFUdIAAwDgYDVR0PAQH/BAQDAgGGMFQGA1UdIwRNMEuAFI2N95+hDQAhMu+p7SKu4Dv00H2w oS2kKzApMQ4wDAYDVQQKEwVOb2tpYTEXMBUGA1UEAxMOTm9raWEgIFJvb3QgQ0GCBDpVqdkwHQYD VR0OBBYEFKcksD7Fg+8EDlB2Sxgy58pW0Sy6MA0GCSqGSIb3DQEBBQUAA4IBAQAC3lEUplDlVNOT Pjz/XFezXx2bV2XbCFindhA3F815Egi55H6/cYezEjoP4QLNEGGl2I3aLvkn5A0T8I4pbiFPhIiu B/frbbGg6k6GjQLe/bFQ8F1mAOOR+GyneKZFPfzaRV0jiIR9QqnMXTf8RvKkCJyFj10MZVsLIy/Y uBkzeP3JhzDhUdtPfwmJN6ZbIhH5uR/2BwAGtgQknb8WX3I4wnhWtMUxB8XmayayYs8qWYeIiVkI FV+sLTkWUWVvvKUjyakBpbAW2vUP84DYsJ8TL1YefNjf/nIOByMcORLuV/1gPjyv00qJbcB59AA+ iXe3zIo8QNcgXG0uPQQFmrGDMIID5DCCAsygAwIBAgIQMH5apak8lEy6LmLlLsJy8TANBgkqhkiG 9w0BAQUFADAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJ IENBMB4XDTExMDkwNjA1NTIwNFoXDTE0MDkwNjA1NTIwNFowVjEOMAwGA1UECgwFTm9raWExDzAN BgNVBAsMBlBlb3BsZTEYMBYGCgmSJomT8ixkAQEMCDEwMDI0Njc2MRkwFwYDVQQDDBBTYXZvbGFp bmVuIFRlZW11MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAshEsmw6Yiz6XWX26oF+I s5fsfE1OfCjOelclmtqCiIgXND5klkNOBs2d4ZGzgD9mN+XnTZnOTh249c2WxPBugf12DCcDmBAJ gL+VuWUJVBTE5NRchm/O8nZnZsRFst+gAC9/Juykh4+EYewZ7QbpnlwW7hNpj8eH+rMr+OZHKzdp KTftgVjmuF4JJ/cPMQUjL8SuGj+zBW6IWPOZdqkEMtf7Pr8kkYbZsh0SgJ0ceRHZ7Uc06mB/y+C1 UnJPxehTTdu8tpCjdzXgBw/H2uuW1J3qdHbCfbuDILql8V8RiZKubcZLhdsD3Jvj8qK0DGWBJa6x p90q5p3pLE8LvAeCgQIDAQABo4HQMIHNMA4GA1UdDwEB/wQEAwIEMDAfBgNVHSMEGDAWgBSnJLA+ xYPvBA5QdksYMufKVtEsujAZBgNVHSAEEjAQMA4GDCsGAQQBXgExBgEHAzA5BgNVHR8EMjAwMC6g LKAqhihodHRwOi8vY3JsLm5va2lhLmNvbS9Ob2tpYSUyMEJJJTIwQ0EuY3JsMCUGA1UdEQQeMByB GnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBQTRzvZsgmQrAGCeuzdHTGAC6Jg UzANBgkqhkiG9w0BAQUFAAOCAQEACmPVsdi07pjK5gDa+W5JlE2C74kVVsB8alBqfioYeR5At2FG B7sua4Dz5H7TJMpZ1jYFeI+zjexD5f+beY2IlV15lMoWD+5e38QlLYjwfe2LAyvdzBKXW0e0U6Bt p78ft4gyVak1X+Db+ebR+FNHUOMNhm+yK3w9sy5ZQzBFusIx4OgxGvcZhyhmd9WjipSTalgPwgqV Ju2aPADCG++OEXmgEWRLsR4yNopkgK4ftVqrN5uUtLs83qdeXTRcNRiET1IOx5zmYFZ6q3gjKIx5 iyuxcDeYas93vVHUcaRRYpsoby5CHq7Z/j/TQhtqO/knWuxLFFiCUgdGKMKrRkg29DCCBAowggLy oAMCAQICEQCBvi+p+bA/dBtBtybwA6YYMA0GCSqGSIb3DQEBBQUAMDMxCzAJBgNVBAYTAkZJMQ4w DAYDVQQKEwVOb2tpYTEUMBIGA1UEAxMLTm9raWEgQkkgQ0EwHhcNMTEwOTA2MDU1MDM0WhcNMTMw OTA1MDU1MDM0WjBWMQ4wDAYDVQQKDAVOb2tpYTEPMA0GA1UECwwGUGVvcGxlMRgwFgYKCZImiZPy LGQBAQwIMTAwMjQ2NzYxGTAXBgNVBAMMEFNhdm9sYWluZW4gVGVlbXUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDFPmbRVwuo52v+h6xnQUqokAx2xsHjmPBniEkzgtgBNJsFi838ATEg 1zsx+VotoJg7hMijcrQfpTAgW6gpLGnlmw5QQswrNK1zleOHb4pA5JguU3WhVKFkAH/6/2EU2k/9 m8Pb/gwP55cYg80R6fRmbdsWKhseXF/1isW/rJcWLmIYDg/rXfo3ixqtT9MroAMiuoXnb0ij1L2d Jj64LDp3Ld8Jo0qZzk3Fj4apo8PBd8eAH6HloVBJkxQcwAnv561A+Xi1GHZ2mafRYJGO+1uBDwyd g/8ybEXXA4MKo8lPKjBebYBUFvz80DBA/Lq74UysXkG23BSulcG4xQSYGlyzAgMBAAGjgfUwgfIw HwYDVR0jBBgwFoAUpySwPsWD7wQOUHZLGDLnylbRLLowGQYDVR0gBBIwEDAOBgwrBgEEAV4BMQYB BgQwOQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5ub2tpYS5jb20vTm9raWElMjBCSSUyMENB LmNybDAjBgNVHSUEHDAaBggrBgEFBQcDAgYEVR0lAAYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgeA MCUGA1UdEQQeMByBGnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBTGhbTJF0EX iagjymQo6GIuSQeRVDANBgkqhkiG9w0BAQUFAAOCAQEAqai6TxZ/BlMHZIhJNPriBPXkQhUlBkGA buJZ5sVm1HIQhWN8elZKjjJdHi1qWEKhMg7yHjEMZsyV8XAZzK0UnOqkpUnt+jnVkNZ9O7/jRtyK f4WUtq5jErc8Hlv4bbGFRHk1T7AuLLE52r1lYOdmoibnQp03QtlDvHUNa68G7jvzThJhieB7U1xh vH3yy0ktaVnWEgAylqf9yIUFjnqau5R6cE1Xo57IYPk/KitX0YF+OigEI/bOQVMi+fze93ZsAOJv /z6g/NGemvUgl5YSdX0uPQK6kEHf/sp/nZyUWWQ7OjtVSqkq2YuYEueQFxTfafl+78GWqgm6W/Bl 32laYzGCAuswggLnAgEBMEgwMzELMAkGA1UEBhMCRkkxDjAMBgNVBAoTBU5va2lhMRQwEgYDVQQD EwtOb2tpYSBCSSBDQQIRAIG+L6n5sD90G0G3JvADphgwCQYFKw4DAhoFAKCCAXgwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTExMDIxMDcxNTA0WjAjBgkqhkiG9w0B CQQxFgQUDDMIkeZ29XpoWjvkPuAvxyx0y68wVgYJKwYBBAGCNxAEMUkwRzAzMQswCQYDVQQGEwJG STEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLx MFgGCyqGSIb3DQEJEAILMUmgRzAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNV BAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLxMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMA0GCSqGSIb3DQEBAQUABIIBAMUR7QP/iKgkAZELwgMy IpZqWhbry6stGPrfAj8vR+HzKFhLVaedisM+XzTSi1loA+LoMzLkCUTSjNXwCL1dVw4mWDWbTs3U lxDrMbSAv1Q3qabcpiEuEgh7yIt67Ja9zSObNGdPd1h+q/JREOLalFBeXwyAh+OiagZ3QCRjN6Ww CQBHndreNOv5yIDgOXg22Tg68anNBOjXR+GQwBex9YPRin3RM7xAT0gvgQKb8VxUV8mNqWvT8q3l aG98K8IqsncMXApPxBALOTfQsih0tjXnD2GzeGAnqFhgK7gBQf9a5HhHJD0EOBLtQJa+ueCmyQ6l jbhUWf4iw9LGOuWuvR0AAAAAAAA= ------=_NextPart_000_0168_01CC8FDA.4CD5BC20-- From moore@network-heretics.com Fri Oct 21 07:10:48 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3295121F8AED; Fri, 21 Oct 2011 07:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.768 X-Spam-Level: X-Spam-Status: No, score=-3.768 tagged_above=-999 required=5 tests=[AWL=-0.169, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lo6DlaJCxZ77; Fri, 21 Oct 2011 07:10:47 -0700 (PDT) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 6021521F8B1A; Fri, 21 Oct 2011 07:10:44 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id C652921427; Fri, 21 Oct 2011 10:10:35 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute6.internal (MEProxy); Fri, 21 Oct 2011 10:10:35 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=cRfCSQxXa5CuxeLAc8AqVR6bGf8=; b=b/ HCS9HcV76vueIB9sRyneIyxwRBxjEtzShrKef+XfVgVLINGqy2Iysea5eXR/lGSQ Q4q10dZokjR83OJExfDk/0Mece1kYdkPQE/MzgUtDBQnCc32PymS0QaUoVaNckpg HIsn4REWVKE3mnpGQCEHgZAzChtaRf/9snXOJjwqo= X-Sasl-enc: Ha7BrwBdL6cjhz3taJOw+wulibPHp2Rydy1NpM65Lsim 1319206235 Received: from [192.168.1.16] (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id F0FFF408BCC; Fri, 21 Oct 2011 10:10:33 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <916CE6CF87173740BC8A2CE44309696203784B1F@008-AM1MPN1-037.mgdnok.nokia.com> Date: Fri, 21 Oct 2011 10:10:07 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <71BF497E-6C6F-4EAF-817F-1478FFB51FE2@network-heretics.com> References: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> <121DABD1-65E8-4275-8471-9FA38D25C434@nominet.org.uk> <916CE6CF87173740BC8A2CE44309696203783EE0@008-AM1MPN1-037.mgdnok.nokia.com> <4EA09791.8010705@gmail.com> <916CE6CF87173740BC8A2CE44309696203784B1F@008-AM1MPN1-037.mgdnok.nokia.com> To: X-Mailer: Apple Mail (2.1084) Cc: mif@ietf.org, dnsop@ietf.org, dnsext@ietf.org, pk@isoc.de, john_brzozowski@cable.comcast.com, dhcwg@ietf.org, denghui02@hotmail.com Subject: Re: [mif] [dnsext] 2nd Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 14:10:48 -0000 On Oct 21, 2011, at 3:15 AM, wrote: > Brian, >=20 > Would the following text be then ok? Please note I changed the domain = addition from SHOULD to MAY, if there is going to be attempt to = deprecate/redefine/update search list logics. Or do you think it should = remain SHOULD? > -- > 4.6. Interactions with DNS search lists >=20 > A node may be configured with DNS search list via DHCPv6 > OPTION_DOMAIN_LIST [RFC3646] or via DHCPv4 Domain Search Option > [RFC3397]. >=20 > A bare name (a name without any dots) MUST be first treated as a = pre- > DNS hostname or handled by other means that, as of this writing, are > under discussion in the IETF and that are out of the scope of this > document. If the bare name resolution fails, the name MAY then be > appended with the domain information. If the bare name is appended > with the domain information the described DNS server selection logic > SHALL be utilized for the resulting name. Associating MUST with undefined behavior makes no sense at all. > Resolution for the name containing any dots SHOULD first be = attempted > with DNS servers of all interfaces. Only if the resolution fails = the > node MAY append the name with search list domain(s) and then again > utilize improved DNS server selection algorithm to decide which DNS > server(s) to contact. Names containing dots SHOULD NOT (perhaps MUST NOT) be subject to = searches. They should already be considered fully qualified. Just because a lookup "fails" does not mean that the name is not valid. = It could fail for temporary reasons, or because the TLD server wasn't = reachable. Back before there was a .CS TLD, searching on names containing dots was = common. Lots of computer science departments had .CS subdomains (e.g. = cs.utk.edu used to be my mail domain), and people were accustomed to = being able to send mail to moore@cs or moore@host.cs). Once the .CS = TLD was defined it became obvious that domains containing any dots = should not be subject to search. Keith From marka@isc.org Fri Oct 21 04:30:25 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A88E21F8B57; Fri, 21 Oct 2011 04:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id erbvr9Lt53+v; Fri, 21 Oct 2011 04:30:24 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 2165E21F8B56; Fri, 21 Oct 2011 04:30:24 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 80A76C941E; Fri, 21 Oct 2011 11:30:11 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id CDDF5216C6B; Fri, 21 Oct 2011 11:30:10 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 0653615B8AA7; Fri, 21 Oct 2011 22:30:08 +1100 (EST) To: Brian Dickson From: Mark Andrews References: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> <121DABD1-65E8-4275-8471-9FA38D25C434@nominet.org.uk> <916CE6CF87173740BC8A2CE44309696203783EE0@008-AM1MPN1-037.mgdnok.nokia.com> <4EA09791.8010705@gmail.com> <94C2E518-F34F-49E4-B15C-2CCCFAA96667@virtualized.org> <12477381-9F74-4C50-B576-47EE4322F6BC@network-heretics.com> In-reply-to: Your message of "Thu, 20 Oct 2011 23:15:32 EDT." Date: Fri, 21 Oct 2011 22:30:08 +1100 Message-Id: <20111021113008.0653615B8AA7@drugs.dv.isc.org> X-Mailman-Approved-At: Fri, 21 Oct 2011 08:17:34 -0700 Cc: mif@ietf.org, Keith Moore , dnsop@ietf.org, dnsext@ietf.org, David Conrad , pk@isoc.de, dhcwg@ietf.org, denghui02@hotmail.com Subject: Re: [mif] [DNSOP] [dnsext] 2nd Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 11:30:25 -0000 In message , Brian Dickson writes: > I think we can skirt this rat-hole if we separate the two following > distinct cases: > > Case A: "foo" > Case B: "foo." (with terminating "dot"). > > Case B meets the technical requirements of a Fully Qualified Domain > Name, structurally speaking. > Case A does not. > > Case A is a "bare name", case B is not. > > If we stick to the notions of FQDN versus anything else, we can avoid > entering the rat-hole, IMHO. > > (I.e., We don't need to get into any issues over the number of labels > in an FQDN; an FQDN does not require treatment, special or otherwise; > etc., etc.,) A domain style hostname have periods *seperating* labels. RFC 952. > Brian Dickson > > On Thu, Oct 20, 2011 at 9:38 PM, Keith Moore w= > rote: > > > > On Oct 20, 2011, at 9:19 PM, David Conrad wrote: > > > >> On Oct 20, 2011, at 6:07 PM, Keith Moore wrote: > >>> It might that IETF should consider "bare names" out of its scope, excep= > t perhaps to say that they're not DNS names, they don't have to necessarily= > be mappable to DNS names, and that their use and behavior is host and appl= > ication-dependent. > >> > >> Can we please not redefine what a "DNS name" is to meet a particular age= > nda? > > > > I wasn't trying to do so. > > > >> Isn't it sufficient to say a 'bare name' does not conform to a hostname = > as defined in RFC 952 and modified by RFCs 1122? > > > > Probably. =A0I'm just suggesting that trying to nail down the behavior of= > such names is probably a rathole as well as likely to cause significant di= > sruption. > > > > _______________________________________________ > > dnsext mailing list > > dnsext@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsext > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From moore@network-heretics.com Fri Oct 21 07:05:24 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 894D811E8098; Fri, 21 Oct 2011 07:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.779 X-Spam-Level: X-Spam-Status: No, score=-3.779 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2vjS6HGjVnp; Fri, 21 Oct 2011 07:05:24 -0700 (PDT) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id DC4EF11E8082; Fri, 21 Oct 2011 07:05:23 -0700 (PDT) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id DC37E211EE; Fri, 21 Oct 2011 10:05:22 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute4.internal (MEProxy); Fri, 21 Oct 2011 10:05:22 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=ntspVps5aKo4yODxjI0+szf2FEo=; b=Lz a/V6hpk23qZRn2DhBOnx9wiDoWk1vZvAWNq0ryQGF3oOTBOW9R41lg8mh9Poq9zS 5Ux2+JlQ9YXHWajUbZbLwxtpx5D6vXOdE1s6R8aJ5r/7rmp7sa3QBG5hPWsYYm8A ry7gulVyn0YtULhegq/IHAO2z1G7Ab90Z+Zv7cC+U= X-Sasl-enc: V8xt21HSkfyeN+uGMyOnlZA2xiV99+2HCQ41Q23Q2nZJ 1319205922 Received: from [192.168.1.16] (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 90540408BF4; Fri, 21 Oct 2011 10:05:18 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <916CE6CF87173740BC8A2CE44309696203784B27@008-AM1MPN1-037.mgdnok.nokia.com> Date: Fri, 21 Oct 2011 10:04:50 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <814EB5AF-16C2-4016-9D52-61183B82988C@network-heretics.com> References: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> <121DABD1-65E8-4275-8471-9FA38D25C434@nominet.org.uk> <916CE6CF87173740BC8A2CE44309696203783EE0@008-AM1MPN1-037.mgdnok.nokia.com> <4EA09791.8010705@gmail.com> <94C2E518-F34F-49E4-B15C-2CCCFAA96667@virtualized.org> <12477381-9F74-4C50-B576-47EE4322F6BC@network-heretics.com> <916CE6CF87173740BC8A2CE44309696203784B27@008-AM1MPN1-037.mgdnok.nokia.com> To: X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Fri, 21 Oct 2011 08:17:34 -0700 Cc: mif@ietf.org, brian.peter.dickson@gmail.com, dnsop@ietf.org, dnsext@ietf.org, pk@isoc.de, john_brzozowski@cable.comcast.com, dhcwg@ietf.org, denghui02@hotmail.com Subject: Re: [mif] [dnsext] 2nd Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 14:05:24 -0000 On Oct 21, 2011, at 3:15 AM, wrote: > Brian, >=20 > Do you agree that nodes' behavioral differences between "foo" and = "foo." > names is out of the scope of this particular MIF draft? That's not how I would state it. I think handling of "foo." is = something that IETF can define, but handling of "foo" is probably better = left undefined. And honestly I don't see why handling of non-DNS names like "foo" is in = scope for MIF. =20 As for lookup of DNS names, results of DNS lookup on any interface = should be considered valid for all interfaces.=20 > There could perhaps be another draft, which would say that if name is = "foo" > it should not be appended with search lists but "foo." might? Actually, it's the other way around. "foo." is already an FQDN and = shouldn't be subject to any search lists. The behavior of lookups of = "foo" is implementation dependent, but it's common practice to subject = it to searching. =20 Keith From Ted.Lemon@nominum.com Fri Oct 21 08:07:52 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCAB521F8B77; Fri, 21 Oct 2011 08:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.525 X-Spam-Level: X-Spam-Status: No, score=-106.525 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SxNpsV9a-nlm; Fri, 21 Oct 2011 08:07:52 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5F621F8B72; Fri, 21 Oct 2011 08:07:51 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP; Fri, 21 Oct 2011 08:07:52 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id A43B01B828A; Fri, 21 Oct 2011 08:07:50 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 73029190065; Fri, 21 Oct 2011 08:07:50 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.01.0323.003; Fri, 21 Oct 2011 08:07:50 -0700 From: Ted Lemon To: " " Thread-Topic: [DNSOP] [dnsext] [mif] 2nd Last Call for MIF DNS server selection document Thread-Index: AQHMj8FjrK4qqOtNf0uZ77rRbwqOEJWHXDkA Date: Fri, 21 Oct 2011 15:07:49 +0000 Message-ID: <708F3212-3C9C-4B61-AA77-EFA8F1CA5B04@nominum.com> References: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> <121DABD1-65E8-4275-8471-9FA38D25C434@nominet.org.uk> <916CE6CF87173740BC8A2CE44309696203783EE0@008-AM1MPN1-037.mgdnok.nokia.com> <4EA09791.8010705@gmail.com> <94C2E518-F34F-49E4-B15C-2CCCFAA96667@virtualized.org> <12477381-9F74-4C50-B576-47EE4322F6BC@network-heretics.com> <916CE6CF87173740BC8A2CE44309696203784B27@008-AM1MPN1-037.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE44309696203784B27@008-AM1MPN1-037.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_708F32123C9C4B61AA77EFA8F1CA5B04nominumcom_" MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 21 Oct 2011 08:17:34 -0700 Cc: "" , "" , "" , "" , "" , "" , "" , "" Subject: Re: [mif] [DNSOP] [dnsext] 2nd Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 15:07:52 -0000 --_000_708F32123C9C4B61AA77EFA8F1CA5B04nominumcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Oct 21, 2011, at 3:15 AM, > > wrote: There could perhaps be another draft, which would say that if name is "foo" it should not be appended with search lists but "foo." might? And whatever other differences in their handling would be, and what impacts it would hav= e e.g. intranet designers? I tend to agree with others who have observed that this question is beyond = the WG's core competency. But there really is a mif question having to do = with how search lists are handled. Personally I tend to side with the cro= wd that believes that DNS search lists should be deprecated with extreme pr= ejudice, but if the consensus is otherwise, I think this draft you describe= does need to be written. --_000_708F32123C9C4B61AA77EFA8F1CA5B04nominumcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <6C8905D726ECDB408A4A5BA1A546CE39@nominum.com> Content-Transfer-Encoding: quoted-printable
On Oct 21, 2011, at 3:15 AM, <teemu.savolainen@nokia.com>
There could perhaps be another draft, which would say that if name is "foo&= quot;
it should not be appended with search lists but "foo." might? And= whatever
other differences in their handling would be, and what impacts it would hav= e
e.g. intranet designers?

I tend to agree with others who have observed that this question is be= yond the WG's core competency.  But there really is a mif question hav= ing to do with how search lists are handled.   Personally I tend to si= de with the crowd that believes that DNS search lists should be deprecated with extreme prejudice, but if the consensus is= otherwise, I think this draft you describe does need to be written.

--_000_708F32123C9C4B61AA77EFA8F1CA5B04nominumcom_-- From Ted.Lemon@nominum.com Fri Oct 21 08:11:15 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E66C21F84D3; Fri, 21 Oct 2011 08:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.531 X-Spam-Level: X-Spam-Status: No, score=-106.531 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tjSWOssWhG5v; Fri, 21 Oct 2011 08:11:14 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id F3BEB21F899D; Fri, 21 Oct 2011 08:11:13 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP; Fri, 21 Oct 2011 08:11:14 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 3B65E1B8289; Fri, 21 Oct 2011 08:11:12 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 2D6FF190065; Fri, 21 Oct 2011 08:11:12 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.01.0323.003; Fri, 21 Oct 2011 08:11:12 -0700 From: Ted Lemon To: Keith Moore Thread-Topic: [DNSOP] [dnsext] [mif] 2nd Last Call for MIF DNS server selection document Thread-Index: AQHMj/p/EJ7srXfEcECXhO5NFotd3ZWHXLmA Date: Fri, 21 Oct 2011 15:11:11 +0000 Message-ID: <75E5E225-5E08-48AC-8FA4-2C4174486514@nominum.com> References: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> <121DABD1-65E8-4275-8471-9FA38D25C434@nominet.org.uk> <916CE6CF87173740BC8A2CE44309696203783EE0@008-AM1MPN1-037.mgdnok.nokia.com> <4EA09791.8010705@gmail.com> <94C2E518-F34F-49E4-B15C-2CCCFAA96667@virtualized.org> <12477381-9F74-4C50-B576-47EE4322F6BC@network-heretics.com> <916CE6CF87173740BC8A2CE44309696203784B27@008-AM1MPN1-037.mgdnok.nokia.com> <814EB5AF-16C2-4016-9D52-61183B82988C@network-heretics.com> In-Reply-To: <814EB5AF-16C2-4016-9D52-61183B82988C@network-heretics.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_75E5E2255E0848AC8FA42C4174486514nominumcom_" MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 21 Oct 2011 08:17:34 -0700 Cc: "" , "" , "" , "" , "" , "" , "" Subject: Re: [mif] [DNSOP] [dnsext] 2nd Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 15:11:15 -0000 --_000_75E5E2255E0848AC8FA42C4174486514nominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Oct 21, 2011, at 10:04 AM, Keith Moore wrote: And honestly I don't see why handling of non-DNS names like "foo" is in sco= pe for MIF. Because such names are typically resolved using DNS search lists, and at le= ase one mechanism for setting up search lists is interface-specific. --_000_75E5E2255E0848AC8FA42C4174486514nominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <28F19B1C4F11B245AB55DE864221E7BD@nominum.com> Content-Transfer-Encoding: quoted-printable
On Oct 21, 2011, at 10:04 AM, Keith Moore wrote:
And honestly I don't see why handling of non-DNS names like "foo" is= in scope for MIF.    

Because such names are typically resolved using DNS search lists, and = at lease one mechanism for setting up search lists is interface-specific.

--_000_75E5E2255E0848AC8FA42C4174486514nominumcom_-- From moore@network-heretics.com Fri Oct 21 08:13:57 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 888B21F0C64; Fri, 21 Oct 2011 08:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.457 X-Spam-Level: X-Spam-Status: No, score=-3.457 tagged_above=-999 required=5 tests=[AWL=-0.459, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfw8aZqjxkAq; Fri, 21 Oct 2011 08:13:56 -0700 (PDT) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id B89821F0C69; Fri, 21 Oct 2011 08:13:53 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 54B2620AB5; Fri, 21 Oct 2011 11:13:53 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute3.internal (MEProxy); Fri, 21 Oct 2011 11:13:53 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; s=smtpout; bh=lCO X1kCTIlP095ifCEhUWw/V1Zw=; b=jdcervDjgROLH43YBshK5JCzcGkDR2Lx1rY L1WYX01xjYjaTtvchGmev+oCzNagHTiRkrjg/eRxzKDZNk+lwMbG85oHOO5rB5W/ 8QIpWhQCpyv2QIXtAiydGATcb763ywDuta5WD2GP8ptkui6lho49wFbv4/MCRbYF Ts4bI7to= X-Sasl-enc: bQ9eg22JollG3hR4uNW4sZJbiW43Gqc9UOPy+j63j6Yc 1319210032 Received: from [192.168.1.16] (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 2BD84408A4E; Fri, 21 Oct 2011 11:13:51 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-67--547095658 From: Keith Moore In-Reply-To: <708F3212-3C9C-4B61-AA77-EFA8F1CA5B04@nominum.com> Date: Fri, 21 Oct 2011 11:13:24 -0400 Message-Id: <30B1AE01-0A35-48D2-91AF-46FC8B60466C@network-heretics.com> References: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> <121DABD1-65E8-4275-8471-9FA38D25C434@nominet.org.uk> <916CE6CF87173740BC8A2CE44309696203783EE0@008-AM1MPN1-037.mgdnok.nokia.com> <4EA09791.8010705@gmail.com> <94C2E518-F34F-49E4-B15C-2CCCFAA96667@virtualized.org> <12477381-9F74-4C50-B576-47EE4322F6BC@network-heretics.com> <916CE6CF87173740BC8A2CE44309696203784B27@008-AM1MPN1-037.mgdnok.nokia.com> <708F3212-3C9C-4B61-AA77-EFA8F1CA5B04@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Fri, 21 Oct 2011 08:17:34 -0700 Cc: "" , "" , "" , "" , "" , "" , "" Subject: Re: [mif] [DNSOP] [dnsext] 2nd Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 15:13:57 -0000 --Apple-Mail-67--547095658 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 21, 2011, at 11:07 AM, Ted Lemon wrote: > On Oct 21, 2011, at 3:15 AM, > wrote: >> There could perhaps be another draft, which would say that if name is = "foo" >> it should not be appended with search lists but "foo." might? And = whatever >> other differences in their handling would be, and what impacts it = would have >> e.g. intranet designers? >=20 > I tend to agree with others who have observed that this question is = beyond the WG's core competency. But there really is a mif question = having to do with how search lists are handled. Personally I tend to = side with the crowd that believes that DNS search lists should be = deprecated with extreme prejudice, but if the consensus is otherwise, I = think this draft you describe does need to be written. >=20 IMO: search lists are useful, but only with "bare names" - and the = behavior of those should be implementation dependent. Trying to nail it = down will break too much widespread practice. Names containing "." should not be subject to search lists. Given a = name like foo.bar, there's no reliable way to tell whether "bar" is a = TLD or a subdomain of something in the search list.=20 (No, trying to look up "foo.bar" starting from the DNS root, and failing = over if that lookup fails, is not sufficient, because of (a) temporary = failures and (b) it still doesn't tell you what the user _meant_. It = makes much more sense to say that any name containing a "." is = unambiguously an FQDN.) --Apple-Mail-67--547095658 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On Oct 21, 2011, at 11:07 AM, Ted Lemon wrote:

On Oct 21, 2011, at 3:15 AM, <teemu.savolainen@nokia.com>
There could perhaps be another draft, which would say that if name is "foo"
it should not be appended with search lists but "foo." might? And whatever
other differences in their handling would be, and what impacts it would have
e.g. intranet designers?

I tend to agree with others who have observed that this question is beyond the WG's core competency.  But there really is a mif question having to do with how search lists are handled.   Personally I tend to side with the crowd that believes that DNS search lists should be deprecated with extreme prejudice, but if the consensus is otherwise, I think this draft you describe does need to be written.


IMO: search lists are useful, but only with "bare names" - and the behavior of those should be implementation dependent.  Trying to nail it down will break too much widespread practice.

Names containing "." should not be subject to search lists.  Given a name like foo.bar, there's no reliable way to tell whether "bar" is a TLD or a subdomain of something in the search list. 

(No, trying to look up "foo.bar" starting from the DNS root, and failing over if that lookup fails, is not sufficient, because of (a) temporary failures and (b) it still doesn't tell you what the user _meant_.  It makes much more sense to say that any name containing a "." is unambiguously an FQDN.)

--Apple-Mail-67--547095658-- From Ted.Lemon@nominum.com Fri Oct 21 08:19:09 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D50F21F8B3D; Fri, 21 Oct 2011 08:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.535 X-Spam-Level: X-Spam-Status: No, score=-106.535 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgKyUCzLPAEQ; Fri, 21 Oct 2011 08:19:08 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id 0B68021F8AD8; Fri, 21 Oct 2011 08:19:07 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Fri, 21 Oct 2011 08:19:08 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id BEA181B827A; Fri, 21 Oct 2011 08:19:06 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id B6735190065; Fri, 21 Oct 2011 08:19:06 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.01.0323.003; Fri, 21 Oct 2011 08:19:07 -0700 From: Ted Lemon To: Keith Moore Thread-Topic: [DNSOP] [dnsext] [mif] 2nd Last Call for MIF DNS server selection document Thread-Index: AQHMkAQNa5aq/ROWxEuy8rvfsHIUPpWHXtwA Date: Fri, 21 Oct 2011 15:19:06 +0000 Message-ID: References: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> <121DABD1-65E8-4275-8471-9FA38D25C434@nominet.org.uk> <916CE6CF87173740BC8A2CE44309696203783EE0@008-AM1MPN1-037.mgdnok.nokia.com> <4EA09791.8010705@gmail.com> <94C2E518-F34F-49E4-B15C-2CCCFAA96667@virtualized.org> <12477381-9F74-4C50-B576-47EE4322F6BC@network-heretics.com> <916CE6CF87173740BC8A2CE44309696203784B27@008-AM1MPN1-037.mgdnok.nokia.com> <708F3212-3C9C-4B61-AA77-EFA8F1CA5B04@nominum.com> <30B1AE01-0A35-48D2-91AF-46FC8B60466C@network-heretics.com> In-Reply-To: <30B1AE01-0A35-48D2-91AF-46FC8B60466C@network-heretics.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_F932CA9C348948ACA4545B7A91CF129Anominumcom_" MIME-Version: 1.0 Cc: DHC WG , "dnsop@ietf.org WG" , "" , dnsext List Subject: Re: [mif] [DNSOP] [dnsext] 2nd Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 15:19:09 -0000 --_000_F932CA9C348948ACA4545B7A91CF129Anominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Oct 21, 2011, at 11:13 AM, Keith Moore wrote: IMO: search lists are useful, but only with "bare names" - and the behavior= of those should be implementation dependent. Trying to nail it down will = break too much widespread practice. On a desktop workstation they are useful, because you can largely trust the= security of the physical network. On mobile nodes, though, they are harm= ful, because they open up a really easy avenue for exploit. On MIF nodes, they also open up potential for mistakes. So if we are to m= eet the spirit of your request here, it will still require a document descr= ibing what the mistakes are, and providing advice on how to avoid them. --_000_F932CA9C348948ACA4545B7A91CF129Anominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On Oct 21, 2011, at 11:13 AM, Keith Moore wrote:
IMO: search lists are useful, but only with "bare names" - and the be= havior of those should be implementation dependent.  Trying to nail it= down will break too much widespread practice.

On a desktop workstation they are useful, because you can largely trus= t the security of the physical network.   On mobile nodes, though, the= y are harmful, because they open up a really easy avenue for exploit.

On MIF nodes, they also open up potential for mistakes.   So if w= e are to meet the spirit of your request here, it will still require a docu= ment describing what the mistakes are, and providing advice on how to avoid= them.

--_000_F932CA9C348948ACA4545B7A91CF129Anominumcom_-- From moore@network-heretics.com Fri Oct 21 08:31:40 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCA6D1F0C86; Fri, 21 Oct 2011 08:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.725 X-Spam-Level: X-Spam-Status: No, score=-3.725 tagged_above=-999 required=5 tests=[AWL=-0.127, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJC+7-eR9wM8; Fri, 21 Oct 2011 08:31:40 -0700 (PDT) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id DEA8E1F0C6F; Fri, 21 Oct 2011 08:31:39 -0700 (PDT) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 8D08920ED3; Fri, 21 Oct 2011 11:31:34 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute5.internal (MEProxy); Fri, 21 Oct 2011 11:31:34 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; s=smtpout; bh=RJ8 /hnttN06bpudUkmxXY+8hH9M=; b=PFb+3ysonRxnPG/EvBeDnSfHXinPKZW7Tjm CFMB37t3ClqFtPZa3e7ez8i08VjpVHebMJ8MpODdYX8XLqbjq7nOM1p4ylEPDvG2 tJwk7Hzw13eNqTaQBLC7pyvSK3jmZz87DFUC1nr8T0mC9a6HJX0NLa4S2+5Shxz7 NADCl5ZU= X-Sasl-enc: BzEFGSjkiIBbwK80rQASp2a9o7T/Qd5G2tJt+7/7ULLg 1319211093 Received: from [192.168.1.16] (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id F2938408C18; Fri, 21 Oct 2011 11:31:32 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-69--546033778 From: Keith Moore In-Reply-To: Date: Fri, 21 Oct 2011 11:31:06 -0400 Message-Id: <1DF30BB4-76DB-427A-8ACF-A345BAE26FA6@network-heretics.com> References: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> <121DABD1-65E8-4275-8471-9FA38D25C434@nominet.org.uk> <916CE6CF87173740BC8A2CE44309696203783EE0@008-AM1MPN1-037.mgdnok.nokia.com> <4EA09791.8010705@gmail.com> <94C2E518-F34F-49E4-B15C-2CCCFAA96667@virtualized.org> <12477381-9F74-4C50-B576-47EE4322F6BC@network-heretics.com> <916CE6CF87173740BC8A2CE44309696203784B27@008-AM1MPN1-037.mgdnok.nokia.com> <708F3212-3C9C-4B61-AA77-EFA8F1CA5B04@nominum.com> <30B1AE01-0A35-48D2-91AF-46FC8B60466C@network-heretics.com> To: Ted Lemon X-Mailer: Apple Mail (2.1084) Cc: DHC WG , "dnsop@ietf.org WG" , "" , dnsext List Subject: Re: [mif] [DNSOP] [dnsext] 2nd Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 15:31:41 -0000 --Apple-Mail-69--546033778 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 21, 2011, at 11:19 AM, Ted Lemon wrote: > On Oct 21, 2011, at 11:13 AM, Keith Moore wrote: >> IMO: search lists are useful, but only with "bare names" - and the = behavior of those should be implementation dependent. Trying to nail it = down will break too much widespread practice. >=20 > On a desktop workstation they are useful, because you can largely = trust the security of the physical network. On mobile nodes, though, = they are harmful, because they open up a really easy avenue for exploit. True. But unsecured DNS is easily exploited regardless of whether bare = names are used. (and I've never bought the idea that DNSSEC = verification can reasonably be done by an external host) (When I think about things, I generally assume that nearly all nodes are = mobile, because that's clearly the way things are going. I expect that = desktop workstations - in the sense of hosts that serve individual users = and have fixed locations in the network - will be almost nonexistent in = a very short time. They don't need to be special-cased.) > On MIF nodes, they also open up potential for mistakes. So if we are = to meet the spirit of your request here, it will still require a = document describing what the mistakes are, and providing advice on how = to avoid them. Understood. I just think it's going to be tricky to do that without = breaking a lot of existing behavior. But in principle, there's nothing = wrong with describing security vulnerabilities and workarounds for = those. Keith --Apple-Mail-69--546033778 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On Oct 21, 2011, at 11:19 AM, Ted Lemon wrote:

On Oct 21, 2011, at 11:13 AM, Keith Moore wrote:
IMO: search lists are useful, but only with "bare names" - and the behavior of those should be implementation dependent.  Trying to nail it down will break too much widespread practice.

On a desktop workstation they are useful, because you can largely trust the security of the physical network.   On mobile nodes, though, they are harmful, because they open up a really easy avenue for exploit.

True.  But unsecured DNS is easily exploited regardless of whether bare names are used.  (and I've never bought the idea that DNSSEC verification can reasonably be done by an external host)

(When I think about things, I generally assume that nearly all nodes are mobile, because that's clearly the way things are going.  I expect that desktop workstations - in the sense of hosts that serve individual users and have fixed locations in the network - will be almost nonexistent in a very short time.  They don't need to be special-cased.)

On MIF nodes, they also open up potential for mistakes.   So if we are to meet the spirit of your request here, it will still require a document describing what the mistakes are, and providing advice on how to avoid them.

Understood.   I just think it's going to be tricky to do that without breaking a lot of existing behavior.  But in principle, there's nothing wrong with describing security vulnerabilities and workarounds for those.

Keith

--Apple-Mail-69--546033778-- From denghui02@gmail.com Fri Oct 21 08:48:56 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86C0311E80AD for ; Fri, 21 Oct 2011 08:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zwmcaz79QPN for ; Fri, 21 Oct 2011 08:48:56 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id CDCD511E8098 for ; Fri, 21 Oct 2011 08:48:55 -0700 (PDT) Received: by wwe6 with SMTP id 6so4170656wwe.13 for ; Fri, 21 Oct 2011 08:48:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=3p7vFnSqGqmsf8lsPjoT5gkvRT7qJA1Dnat+WUH3AZc=; b=QPEWCxoBdN6PSWSLxK7QJQoI/YRz7BAOXw24L/s/po7KGC6XBazDFgIIyvgNqOWqtg oG6FRgYUYlFtNUQ/CPGOivXxgGdC7GfhLSh23Y29ygMfFs0Swy3q6ASK285r3wEbhFn1 7Lv6no+wvXGSG2JPcQT3vmxwdeFO2CqrmPcIE= MIME-Version: 1.0 Received: by 10.216.138.209 with SMTP id a59mr3722465wej.94.1319212134873; Fri, 21 Oct 2011 08:48:54 -0700 (PDT) Received: by 10.216.65.4 with HTTP; Fri, 21 Oct 2011 08:48:54 -0700 (PDT) Date: Fri, 21 Oct 2011 23:48:54 +0800 Message-ID: From: Hui Deng To: MIF Mailing List Content-Type: multipart/alternative; boundary=0016e6d58fcdaeb99c04afd102e2 Subject: [mif] mif post error X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 15:48:56 -0000 --0016e6d58fcdaeb99c04afd102e2 Content-Type: text/plain; charset=ISO-8859-1 Hello all Please remove receipients as much as possible, mailing list will take it as error if too many receipients there. especially for DNS discussion thanks -Hui --0016e6d58fcdaeb99c04afd102e2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello all
=A0
Please remove receipients as much as possible, mailing list will take = it as error if too many receipients there.
especially for DNS discussion
=A0
thanks
=A0
-Hui
--0016e6d58fcdaeb99c04afd102e2-- From teemu.savolainen@nokia.com Fri Oct 21 11:54:32 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C80A1F0C81; Fri, 21 Oct 2011 11:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9+GnTtVoNXXS; Fri, 21 Oct 2011 11:54:31 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 7E78B1F0C62; Fri, 21 Oct 2011 11:54:31 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p9LIsTjq028071; Fri, 21 Oct 2011 21:54:30 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 21 Oct 2011 21:54:24 +0300 Received: from 008-AM1MMR1-006.mgdnok.nokia.com (65.54.30.61) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 21 Oct 2011 20:54:23 +0200 Received: from 008-AM1MPN1-037.mgdnok.nokia.com ([169.254.7.8]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0339.002; Fri, 21 Oct 2011 20:54:23 +0200 From: To: Thread-Topic: [mif] [dnsext] 2nd Last Call for MIF DNS server selection document Thread-Index: AQHMj3JGB7FreQH6+EqCg+ltMTYsr5WGYYlQgABUUICAAG8GUA== Date: Fri, 21 Oct 2011 18:54:23 +0000 Message-ID: <916CE6CF87173740BC8A2CE4430969620378524D@008-AM1MPN1-037.mgdnok.nokia.com> References: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> <121DABD1-65E8-4275-8471-9FA38D25C434@nominet.org.uk> <916CE6CF87173740BC8A2CE44309696203783EE0@008-AM1MPN1-037.mgdnok.nokia.com> <4EA09791.8010705@gmail.com> <916CE6CF87173740BC8A2CE44309696203784B1F@008-AM1MPN1-037.mgdnok.nokia.com> <71BF497E-6C6F-4EAF-817F-1478FFB51FE2@network-heretics.com> In-Reply-To: <71BF497E-6C6F-4EAF-817F-1478FFB51FE2@network-heretics.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Company Confidential;Project=None; x-titus-version: 3.3.8.1 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IleTS5gKgr+JhCehPOzQb7X8VPIDGtFQ+zxfOgeaBUZsOG8Ek7lD2xu5WHF5/rxKyBmC4Zgoz9lY65iVD+EwKfx/HOyCbcbCouTzciSIqgIMf/5bLh0Sai/jE6sG24Xx+7Vb5YLSzlGNh/xlWFKXjhG/VugZS7r2MiqJJ+wJiYnj7oW0F1q2Pewb5bJXqVC5toWbFgVuespx3qoYFmYIO7yzifaaSr9b380ixgq8cDxL9AfCqPWq32/ZgZAi48Q3WSxOadDP3x3m22zqpSDkV30= x-originating-ip: [10.162.69.25] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_005E_01CC903B.FD6CFBF0" MIME-Version: 1.0 X-OriginalArrivalTime: 21 Oct 2011 18:54:24.0657 (UTC) FILETIME=[D9EFF010:01CC9022] X-Nokia-AV: Clean Cc: dhcwg@ietf.org, dnsop@ietf.org, mif@ietf.org, dnsext@ietf.org Subject: Re: [mif] [dnsext] 2nd Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 18:54:32 -0000 ------=_NextPart_000_005E_01CC903B.FD6CFBF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Now that more people are involved in discussions, this bare name / DNS search list area seems to look like quite a deep swamp without clear IETF consensus. Perhaps we should discuss first if this particular topic (=section 4.6) is needed in this document at all, because, after all, the focus is on selecting the DNS server based on matching domains. Best regards, Teemu > -----Original Message----- > From: ext Keith Moore [mailto:moore@network-heretics.com] > Sent: 21. lokakuuta 2011 17:10 > To: Savolainen Teemu (Nokia-CTO/Tampere) > Cc: brian.e.carpenter@gmail.com; mif@ietf.org; dnsop@ietf.org; > dnsext@ietf.org; pk@isoc.de; john_brzozowski@cable.comcast.com; > dhcwg@ietf.org; denghui02@hotmail.com > Subject: Re: [mif] [dnsext] 2nd Last Call for MIF DNS server selection > document > > > On Oct 21, 2011, at 3:15 AM, wrote: > > > Brian, > > > > Would the following text be then ok? Please note I changed the domain > addition from SHOULD to MAY, if there is going to be attempt to > deprecate/redefine/update search list logics. Or do you think it should > remain SHOULD? > > -- > > 4.6. Interactions with DNS search lists > > > > A node may be configured with DNS search list via DHCPv6 > > OPTION_DOMAIN_LIST [RFC3646] or via DHCPv4 Domain Search Option > > [RFC3397]. > > > > A bare name (a name without any dots) MUST be first treated as a pre- > > DNS hostname or handled by other means that, as of this writing, are > > under discussion in the IETF and that are out of the scope of this > > document. If the bare name resolution fails, the name MAY then be > > appended with the domain information. If the bare name is appended > > with the domain information the described DNS server selection logic > > SHALL be utilized for the resulting name. > > Associating MUST with undefined behavior makes no sense at all. > > > Resolution for the name containing any dots SHOULD first be attempted > > with DNS servers of all interfaces. Only if the resolution fails the > > node MAY append the name with search list domain(s) and then again > > utilize improved DNS server selection algorithm to decide which DNS > > server(s) to contact. > > Names containing dots SHOULD NOT (perhaps MUST NOT) be subject to > searches. They should already be considered fully qualified. > > Just because a lookup "fails" does not mean that the name is not valid. It > could fail for temporary reasons, or because the TLD server wasn't > reachable. > > Back before there was a .CS TLD, searching on names containing dots was > common. Lots of computer science departments had .CS subdomains (e.g. > cs.utk.edu used to be my mail domain), and people were accustomed to > being able to send mail to moore@cs or moore@host.cs). Once the .CS TLD > was defined it became obvious that domains containing any dots should not > be subject to search. > > Keith > ------=_NextPart_000_005E_01CC903B.FD6CFBF0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOuzCCAzYw ggIeoAMCAQICBDpVqdkwDQYJKoZIhvcNAQEFBQAwKTEOMAwGA1UEChMFTm9raWExFzAVBgNVBAMT Dk5va2lhICBSb290IENBMB4XDTAxMDEwNTExMDUwNVoXDTE2MDEwMjExMDUwNVowKTEOMAwGA1UE ChMFTm9raWExFzAVBgNVBAMTDk5va2lhICBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsrTy8gLmr4LYvp0khVUVHw7ascdl+Cjr+yI5MlZ6J/U6Qsvkiqthgqq8rPcLV0P1 92TfBr27VgKEeCaZe0icS1jC2spM/wRv3j2WxdkKxb9kDJtuCNJaRBqvi5vGTHB15nmEmKuL5f3i rAxeHqPjgS496oWcudzFT1e7Xrc/gWGFYd72+/ykIFXjWOMZv6QpxD8x1hLPyh2YVXRk9U7N7pvm RQNX29g4SCFJY2BBIa5JPlwIF8Nc9IePaC/E/2M4tGMtiOOZlm99EoL7N0hJZtFSvUwdCBud/viH 4DgsKGjNkNKi6pAHc9IaXB6tIykcoYp+L+oe/3+cuEJaCj1EKwIDAQABo2YwZDASBgNVHRMBAf8E CDAGAQH/AgEEMB0GA1UdDgQWBBSNjfefoQ0AITLvqe0iruA79NB9sDAfBgNVHSMEGDAWgBSNjfef oQ0AITLvqe0iruA79NB9sDAOBgNVHQ8BAf8EBAMCAYYwDQYJKoZIhvcNAQEFBQADggEBAIGEPql2 TALyKi/h1J+Mh5XolAtYppcSOLMtBkoA7ZovGBDNvl0VbZs8AAojJqkUoWBB+L6DKyl/jKhNfKcu rWRGRyj7pnbxrKLsI3gmWNWkyo2b60wJwe9fqPD5ZQy3oEiMit9l0Ba6il/k2GqYopUCNMa7mfeb E2LeBy5ChYMiCi97UQSJvAdzEYylTJw8Awc6AiM2Ve5N+XxsmKgNf/2A/5IJ3EZZ+wFRmkI4062A oNU302rqAt0HH88jzoUF4AfYHWl6HpYhGXFbcX44rHINyPmFBRxLYIFJ6ZWUr/mXpL/e6rqFtNWO kV6UoJND7OVZkbLh7F1+lcqXRU8TPBMwggOHMIICb6ADAgECAgRBtbHpMA0GCSqGSIb3DQEBBQUA MCkxDjAMBgNVBAoTBU5va2lhMRcwFQYDVQQDEw5Ob2tpYSAgUm9vdCBDQTAeFw0wNjAzMzAwOTU3 MTFaFw0xNjAxMDIxMTA1MDVaMDMxCzAJBgNVBAYTAkZJMQ4wDAYDVQQKEwVOb2tpYTEUMBIGA1UE AxMLTm9raWEgQkkgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDtFCg3QEjSCg6T IUxoWsNwELh8bBNiUQPCPmg8c2DHQYXWWCSCMb+S0Fvh1qqI1xt+XnzyFq+5eqzGzDj4UaBcG+d9 qxrCFly8sHyoPTryyPrR0EI2UUDWwfS6ojhqgwghRqo8G38TjFusyBtLub/5L6yvWYSOHD+JcB+q VM2fbkArPYK4Ydv8WG/DbHjGn0gKq0zwpVZKI/gCK/QALYvte02NXseqvY9/GOyLtjy3Z8erFv71 KKTq+gxI/7DK55pJf3PoD+kT4kyGm6EF9DTdK4ojMdar17uyX0IOZz/4vkkF0d+60nmnLX63FJPA jUyB0HUNJ32NXDo9UsM38aoNAgMBAAGjgawwgakwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAI MAYGBFUdIAAwDgYDVR0PAQH/BAQDAgGGMFQGA1UdIwRNMEuAFI2N95+hDQAhMu+p7SKu4Dv00H2w oS2kKzApMQ4wDAYDVQQKEwVOb2tpYTEXMBUGA1UEAxMOTm9raWEgIFJvb3QgQ0GCBDpVqdkwHQYD VR0OBBYEFKcksD7Fg+8EDlB2Sxgy58pW0Sy6MA0GCSqGSIb3DQEBBQUAA4IBAQAC3lEUplDlVNOT Pjz/XFezXx2bV2XbCFindhA3F815Egi55H6/cYezEjoP4QLNEGGl2I3aLvkn5A0T8I4pbiFPhIiu B/frbbGg6k6GjQLe/bFQ8F1mAOOR+GyneKZFPfzaRV0jiIR9QqnMXTf8RvKkCJyFj10MZVsLIy/Y uBkzeP3JhzDhUdtPfwmJN6ZbIhH5uR/2BwAGtgQknb8WX3I4wnhWtMUxB8XmayayYs8qWYeIiVkI FV+sLTkWUWVvvKUjyakBpbAW2vUP84DYsJ8TL1YefNjf/nIOByMcORLuV/1gPjyv00qJbcB59AA+ iXe3zIo8QNcgXG0uPQQFmrGDMIID5DCCAsygAwIBAgIQMH5apak8lEy6LmLlLsJy8TANBgkqhkiG 9w0BAQUFADAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJ IENBMB4XDTExMDkwNjA1NTIwNFoXDTE0MDkwNjA1NTIwNFowVjEOMAwGA1UECgwFTm9raWExDzAN BgNVBAsMBlBlb3BsZTEYMBYGCgmSJomT8ixkAQEMCDEwMDI0Njc2MRkwFwYDVQQDDBBTYXZvbGFp bmVuIFRlZW11MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAshEsmw6Yiz6XWX26oF+I s5fsfE1OfCjOelclmtqCiIgXND5klkNOBs2d4ZGzgD9mN+XnTZnOTh249c2WxPBugf12DCcDmBAJ gL+VuWUJVBTE5NRchm/O8nZnZsRFst+gAC9/Juykh4+EYewZ7QbpnlwW7hNpj8eH+rMr+OZHKzdp KTftgVjmuF4JJ/cPMQUjL8SuGj+zBW6IWPOZdqkEMtf7Pr8kkYbZsh0SgJ0ceRHZ7Uc06mB/y+C1 UnJPxehTTdu8tpCjdzXgBw/H2uuW1J3qdHbCfbuDILql8V8RiZKubcZLhdsD3Jvj8qK0DGWBJa6x p90q5p3pLE8LvAeCgQIDAQABo4HQMIHNMA4GA1UdDwEB/wQEAwIEMDAfBgNVHSMEGDAWgBSnJLA+ xYPvBA5QdksYMufKVtEsujAZBgNVHSAEEjAQMA4GDCsGAQQBXgExBgEHAzA5BgNVHR8EMjAwMC6g LKAqhihodHRwOi8vY3JsLm5va2lhLmNvbS9Ob2tpYSUyMEJJJTIwQ0EuY3JsMCUGA1UdEQQeMByB GnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBQTRzvZsgmQrAGCeuzdHTGAC6Jg UzANBgkqhkiG9w0BAQUFAAOCAQEACmPVsdi07pjK5gDa+W5JlE2C74kVVsB8alBqfioYeR5At2FG B7sua4Dz5H7TJMpZ1jYFeI+zjexD5f+beY2IlV15lMoWD+5e38QlLYjwfe2LAyvdzBKXW0e0U6Bt p78ft4gyVak1X+Db+ebR+FNHUOMNhm+yK3w9sy5ZQzBFusIx4OgxGvcZhyhmd9WjipSTalgPwgqV Ju2aPADCG++OEXmgEWRLsR4yNopkgK4ftVqrN5uUtLs83qdeXTRcNRiET1IOx5zmYFZ6q3gjKIx5 iyuxcDeYas93vVHUcaRRYpsoby5CHq7Z/j/TQhtqO/knWuxLFFiCUgdGKMKrRkg29DCCBAowggLy oAMCAQICEQCBvi+p+bA/dBtBtybwA6YYMA0GCSqGSIb3DQEBBQUAMDMxCzAJBgNVBAYTAkZJMQ4w DAYDVQQKEwVOb2tpYTEUMBIGA1UEAxMLTm9raWEgQkkgQ0EwHhcNMTEwOTA2MDU1MDM0WhcNMTMw OTA1MDU1MDM0WjBWMQ4wDAYDVQQKDAVOb2tpYTEPMA0GA1UECwwGUGVvcGxlMRgwFgYKCZImiZPy LGQBAQwIMTAwMjQ2NzYxGTAXBgNVBAMMEFNhdm9sYWluZW4gVGVlbXUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDFPmbRVwuo52v+h6xnQUqokAx2xsHjmPBniEkzgtgBNJsFi838ATEg 1zsx+VotoJg7hMijcrQfpTAgW6gpLGnlmw5QQswrNK1zleOHb4pA5JguU3WhVKFkAH/6/2EU2k/9 m8Pb/gwP55cYg80R6fRmbdsWKhseXF/1isW/rJcWLmIYDg/rXfo3ixqtT9MroAMiuoXnb0ij1L2d Jj64LDp3Ld8Jo0qZzk3Fj4apo8PBd8eAH6HloVBJkxQcwAnv561A+Xi1GHZ2mafRYJGO+1uBDwyd g/8ybEXXA4MKo8lPKjBebYBUFvz80DBA/Lq74UysXkG23BSulcG4xQSYGlyzAgMBAAGjgfUwgfIw HwYDVR0jBBgwFoAUpySwPsWD7wQOUHZLGDLnylbRLLowGQYDVR0gBBIwEDAOBgwrBgEEAV4BMQYB BgQwOQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5ub2tpYS5jb20vTm9raWElMjBCSSUyMENB LmNybDAjBgNVHSUEHDAaBggrBgEFBQcDAgYEVR0lAAYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgeA MCUGA1UdEQQeMByBGnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBTGhbTJF0EX iagjymQo6GIuSQeRVDANBgkqhkiG9w0BAQUFAAOCAQEAqai6TxZ/BlMHZIhJNPriBPXkQhUlBkGA buJZ5sVm1HIQhWN8elZKjjJdHi1qWEKhMg7yHjEMZsyV8XAZzK0UnOqkpUnt+jnVkNZ9O7/jRtyK f4WUtq5jErc8Hlv4bbGFRHk1T7AuLLE52r1lYOdmoibnQp03QtlDvHUNa68G7jvzThJhieB7U1xh vH3yy0ktaVnWEgAylqf9yIUFjnqau5R6cE1Xo57IYPk/KitX0YF+OigEI/bOQVMi+fze93ZsAOJv /z6g/NGemvUgl5YSdX0uPQK6kEHf/sp/nZyUWWQ7OjtVSqkq2YuYEueQFxTfafl+78GWqgm6W/Bl 32laYzGCAuswggLnAgEBMEgwMzELMAkGA1UEBhMCRkkxDjAMBgNVBAoTBU5va2lhMRQwEgYDVQQD EwtOb2tpYSBCSSBDQQIRAIG+L6n5sD90G0G3JvADphgwCQYFKw4DAhoFAKCCAXgwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTExMDIxMTg1NDIxWjAjBgkqhkiG9w0B CQQxFgQU5wmECRjjm3m7PM7WRTXt97yiDMcwVgYJKwYBBAGCNxAEMUkwRzAzMQswCQYDVQQGEwJG STEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLx MFgGCyqGSIb3DQEJEAILMUmgRzAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNV BAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLxMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMA0GCSqGSIb3DQEBAQUABIIBAEn5Stq0HHCpnpjywKhC aFiEB9QeAOwG9aodNxSHqZKsZ7w/QB74Qk5ru2Yxsu8vebjBQhPOfe3wckdS0E0boW01h9OoxTqn EafuRy+CoQMOYdifyJpp8hpR6tF5P29K42k5XyKKTxyvwl0ixaJ84T6arbaL2IPQWdgeXEg4YPJa oyNb0HDZIVbPb8SW+DGpFibBYhM2vpVRp17r8XJS5wIh8p2d+e4PWbrYzQ4hoqkeVMCJroF2p6i2 QxUv+gjgZ+86I/6eDEJgjBUd+Os20bwgOESTHjdsiaiz3ToGwcS460lqhkXUJzSf0MOFF71o+BMc Q4MvXLXHL2ycF2/hhncAAAAAAAA= ------=_NextPart_000_005E_01CC903B.FD6CFBF0-- From brian.e.carpenter@gmail.com Fri Oct 21 12:29:52 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34F5321F8B3F; Fri, 21 Oct 2011 12:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.089 X-Spam-Level: X-Spam-Status: No, score=-103.089 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yrHI8wz7X9MH; Fri, 21 Oct 2011 12:29:51 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id A378421F8B3D; Fri, 21 Oct 2011 12:29:50 -0700 (PDT) Received: by mail-bw0-f44.google.com with SMTP id s6so6056678bka.31 for ; Fri, 21 Oct 2011 12:29:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=JRwdP+KXzPm8ahbrR73oyzDeY8fLfo6xr/DukOIFsV8=; b=L1waKSsjziLu8EsUyV6O2WPOf5IH2Nt5MRYoWO95UfHlu7on+Jm861Ysh8UripP9M2 AWzMq3nl+5NtP20mLhRNzrx1xyvlO4nnUiwGLFp8pLvLcDPDf/99EEv3ltLsffLCl4q7 jFOsXlJ4DOHXtgEEn7wR9Jy3hr1mV5V6gJ7rs= Received: by 10.223.76.201 with SMTP id d9mr26561529fak.12.1319225390225; Fri, 21 Oct 2011 12:29:50 -0700 (PDT) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id n12sm23804539fan.9.2011.10.21.12.29.44 (version=SSLv3 cipher=OTHER); Fri, 21 Oct 2011 12:29:49 -0700 (PDT) Message-ID: <4EA1C81D.8000805@gmail.com> Date: Sat, 22 Oct 2011 08:29:33 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: teemu.savolainen@nokia.com References: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> <121DABD1-65E8-4275-8471-9FA38D25C434@nominet.org.uk> <916CE6CF87173740BC8A2CE44309696203783EE0@008-AM1MPN1-037.mgdnok.nokia.com> <4EA09791.8010705@gmail.com> <916CE6CF87173740BC8A2CE44309696203784B1F@008-AM1MPN1-037.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE44309696203784B1F@008-AM1MPN1-037.mgdnok.nokia.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mif@ietf.org, dnsop@ietf.org, dnsext@ietf.org, pk@isoc.de, john_brzozowski@cable.comcast.com, dhcwg@ietf.org, denghui02@hotmail.com Subject: Re: [mif] [dnsext] 2nd Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 19:29:52 -0000 Teemu, I think that the spirit of what you propose is correct, but as Keith poin= ts out it really isn't appropriate to use RFC 2119 language about a pragmati= c approach that clearly lies outside the definition of the DNS namespace. If an implementor is willing to take the risk of transforming www.example= into www.example.com, because at the time of writing there is no TLD "exa= mple", that's the implementor's risk, but it shouldn't be dignified with normati= ve keywords IMHO. Regards Brian Carpenter On 2011-10-21 20:15, teemu.savolainen@nokia.com wrote: > Brian, >=20 > Would the following text be then ok? Please note I changed the domain a= ddition from SHOULD to MAY, if there is going to be attempt to deprecate/= redefine/update search list logics. Or do you think it should remain SHOU= LD? > -- > 4.6. Interactions with DNS search lists >=20 > A node may be configured with DNS search list via DHCPv6 > OPTION_DOMAIN_LIST [RFC3646] or via DHCPv4 Domain Search Option > [RFC3397]. >=20 > A bare name (a name without any dots) MUST be first treated as a pre= - > DNS hostname or handled by other means that, as of this writing, are= > under discussion in the IETF and that are out of the scope of this > document. If the bare name resolution fails, the name MAY then be > appended with the domain information. If the bare name is appended > with the domain information the described DNS server selection logic= > SHALL be utilized for the resulting name. >=20 > Resolution for the name containing any dots SHOULD first be attempte= d > with DNS servers of all interfaces. Only if the resolution fails th= e > node MAY append the name with search list domain(s) and then again > utilize improved DNS server selection algorithm to decide which DNS > server(s) to contact. > -- >=20 > Best regards, >=20 > Teemu >=20 >> -----Original Message----- >> From: ext Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >> Sent: 21. lokakuuta 2011 00:50 >> To: Savolainen Teemu (Nokia-CTO/Tampere) >> Cc: Ray.Bellis@nominet.org.uk; mif@ietf.org; dnsop@ietf.org; >> dnsext@ietf.org; pk@isoc.de; john_brzozowski@cable.comcast.com; >> dhcwg@ietf.org; denghui02@hotmail.com >> Subject: Re: [mif] [dnsext] 2nd Last Call for MIF DNS server selection= >> document >> >> Teemu, >> >> I don't believe this is a topic where consensus in MIF is very relevan= t. >> It needs to be decided in a much wider community rather than as a subs= idiary >> question in a MIF document. I suggest leaving it FFS (for further stud= y) in MIF. >> >> Regards >> Brian Carpenter >> >> On 2011-10-20 20:01, teemu.savolainen@nokia.com wrote: >>> Hi Ray, >>> >>>> -----Original Message----- >>>> From: ext Ray Bellis [mailto:Ray.Bellis@nominet.org.uk] >>>> Sent: 19. lokakuuta 2011 13:40 >>>> To: Savolainen Teemu (Nokia-CTO/Tampere) >>>> Cc: ; ; ; >>>> ; ; ; >>>> >>>> Subject: Re: [dnsext] [mif] 2nd Last Call for MIF DNS server >>>> selection document >>>> >>>> I have concerns about =C2=A74.6: >>>> >>>> "A bare name (a name without any dots) MUST be first treated as a >>>> pre- >>> DNS >>>> hostname, and only after that the name SHALL be appended with domai= n >>>> information and described DNS server selection logic be utilized." >>>> >>>> When new gTLDs are introduced it is likely for brand-name gTLDs that= >>>> they will wish to use bare names in the DNS (i.e. a single label >>>> hostname) for >>> their >>>> primary web sites. >>>> >>>> Hence bare names may become much more frequently used as DNS >> names, >>>> and =C2=A74.6 wouldn't permit those to work unless '.' is also in th= e >>>> suffix >>> list. >>>> I'd like to hear the authors' thoughts on these. I'm not sure that >>>> this >>> draft >>>> necessarily needs any significant changes - it may only require >>>> changes to ensure that bare names are also considered as potential >>>> DNS names in their own right. >>> Okay, I understand there is no clear consensus yet how these single >>> label names should be handled by the resolvers at the first place? >>> Should resolver first treat them as pre-DNS hostnames, then as DNS >>> hostnames, and then try search list? The DNS server selection logic >>> would be applied already when resolving single label name, i.e. the >>> network could provide a single label domain "brand" in the domains li= st. >>> >>> Maybe section 4.6 could be like this, perhaps (changes in second >>> paragraph and title)? >>> -- >>> 4.6. Interactions with DNS search lists and single label hostnames >>> >>> A node may be configured with DNS search list by DHCPv6 >>> OPTION_DOMAIN_LIST [RFC3646] or DHCPv4 Domain Search Option >>> [RFC3397]. >>> >>> A bare name (a name without any dots) MUST be first treated as a p= re- >>> DNS hostname, after which resolution of the name SHALL be attempte= d >>> with DNS, and as a last resort the name SHALL be appended with >>> domain information. DNS server selection logic SHALL be >>> utilized for both of the latter two DNS using methods. >>> >>> Resolution for the name containing any dots SHOULD first be attemp= ted >>> with DNS servers of all interfaces. Only if the resolution fails = the >>> node SHOULD append the name with search list domain(s) and then ag= ain >>> utilize improved DNS server selection algorithm to decide which DN= S >>> server(s) to contact. >>> -- >>> >>> Best regards, >>> >>> Teemu >>> >>> >>> >>> ---------------------------------------------------------------------= - >>> -- >>> >>> _______________________________________________ >>> mif mailing list >>> mif@ietf.org >>> https://www.ietf.org/mailman/listinfo/mif >=20 From moore@network-heretics.com Fri Oct 21 08:23:29 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C20241F0C7A; Fri, 21 Oct 2011 08:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.732 X-Spam-Level: X-Spam-Status: No, score=-3.732 tagged_above=-999 required=5 tests=[AWL=-0.134, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHKl4j3-2McO; Fri, 21 Oct 2011 08:23:28 -0700 (PDT) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 9FAB81F0C7E; Fri, 21 Oct 2011 08:23:24 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 522A5212ED; Fri, 21 Oct 2011 11:22:53 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute6.internal (MEProxy); Fri, 21 Oct 2011 11:22:53 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; s=smtpout; bh=EMs naNbFWAbzYVTmyAPeyIEOvaM=; b=JhOGr+0bYJQTTEeukNUKTLnraTetWpYnsnr pb6b3qdGV/2lDNjgBIPcElwF44LhDhkKAImfMDxPbht/Cr4jT3MBwQLxD0UfCQAa y/XS5rSpwC0/ywP7kYDFuYwlYAQFtW1+pqzSKtbeIo4X4YwGPgkncqvWsSP38dRj In2T6fYo= X-Sasl-enc: Qf8h6JOfifsvLjYPPPW90nSw7CLtRuk73ndPBq5FV+P/ 1319210572 Received: from [192.168.1.16] (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id BB9A2408B64; Fri, 21 Oct 2011 11:22:50 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-68--546556678 From: Keith Moore In-Reply-To: <75E5E225-5E08-48AC-8FA4-2C4174486514@nominum.com> Date: Fri, 21 Oct 2011 11:22:23 -0400 Message-Id: References: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> <121DABD1-65E8-4275-8471-9FA38D25C434@nominet.org.uk> <916CE6CF87173740BC8A2CE44309696203783EE0@008-AM1MPN1-037.mgdnok.nokia.com> <4EA09791.8010705@gmail.com> <94C2E518-F34F-49E4-B15C-2CCCFAA96667@virtualized.org> <12477381-9F74-4C50-B576-47EE4322F6BC@network-heretics.com> <916CE6CF87173740BC8A2CE44309696203784B27@008-AM1MPN1-037.mgdnok.nokia.com> <814EB5AF-16C2-4016-9D52-61183B82988C@network-heretics.com> <75E5E225-5E08-48AC-8FA4-2C4174486514@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Fri, 21 Oct 2011 18:11:47 -0700 Cc: "" , "" , "" , "" , "" , "" , "" Subject: Re: [mif] [DNSOP] [dnsext] 2nd Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 15:23:30 -0000 --Apple-Mail-68--546556678 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 21, 2011, at 11:11 AM, Ted Lemon wrote: > On Oct 21, 2011, at 10:04 AM, Keith Moore wrote: >> And honestly I don't see why handling of non-DNS names like "foo" is = in scope for MIF. =20 >=20 > Because such names are typically resolved using DNS search lists, and = at lease one mechanism for setting up search lists is = interface-specific. I don't think it's MIF's job to try to make all existing hacks work, = while limiting its scope to specifying how hosts and apps implement = things. =20 I think it's potentially reasonable for MIF to say things like "here's = how you should configure your networks if you want them to be usable = from hosts with multiple interfaces." Also, the subject of multiple active interfaces per host exposes a = number of cracks in the Internet architecture, and also exposes cracks = in some of the hacks that people have used to work around cracks in the = Internet architecture. IMO, MIF should not be trying to add more = hacks. MIF should primarily do what's best for the Internet = architecture in the long term, realizing that IPv4 and therefore RFC = 1918 are at EOL. Hacks to accommodate the existing world should be = considered of secondary importance, and should only be considered if = they don't pollute the architecture in the long run. Also, it's arguable that v6 link-local addresses should not be used by = applications, even on ad hoc networks, because randomly-generated ULIA = prefixes are much better. And the way you figure out which interface(s) = to use in order to reach ULIAs is via routing protocols, not via = assuming that a DNS query is specific to a particular network interface. --Apple-Mail-68--546556678 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Oct 21, 2011, at 10:04 AM, Keith Moore wrote:
And honestly I don't see why handling of non-DNS names like "foo" is in = scope for MIF.    

Because such names are typically resolved using DNS search lists, = and at lease one mechanism for setting up search lists is = interface-specific.

I don't think it's MIF's job to try to make = all existing hacks work, while limiting its scope to specifying how = hosts and apps implement things.  

I think = it's potentially reasonable for MIF to say things like "here's how you = should configure your networks if you want them to be usable from hosts = with multiple interfaces."

Also, the subject of multiple = active interfaces per host exposes a number of cracks in the Internet = architecture, and also exposes cracks in some of the hacks that people = have used to work around cracks in the Internet architecture.   = IMO, MIF should not be trying to add more hacks.  MIF should = primarily do what's best for the Internet architecture in the long term, = realizing that IPv4 and therefore RFC 1918 are at EOL.  Hacks to = accommodate the existing world should be considered of secondary = importance, and should only be considered if they don't pollute the = architecture in the long run.

Also, it's = arguable that v6 link-local addresses should not be used by = applications, even on ad hoc networks, because randomly-generated ULIA = prefixes are much better.  And the way you figure out which = interface(s) to use in order to reach ULIAs is via routing protocols, = not via assuming that a DNS query is specific to a particular network = interface.

= --Apple-Mail-68--546556678-- From moore@network-heretics.com Sat Oct 22 12:21:31 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63A0C21F85B9; Sat, 22 Oct 2011 12:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.419 X-Spam-Level: X-Spam-Status: No, score=-3.419 tagged_above=-999 required=5 tests=[AWL=-0.420, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LiNvaQlA53FK; Sat, 22 Oct 2011 12:21:30 -0700 (PDT) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE2221F85AE; Sat, 22 Oct 2011 12:21:30 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id D6C55204B3; Sat, 22 Oct 2011 15:21:29 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute3.internal (MEProxy); Sat, 22 Oct 2011 15:21:29 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=OYf4hyQkCqr26hQ3ulZWEawjd8k=; b=hI EBRptIVlofYveBd0pH/3t6+bVz/VR2ZibRmXuuCqGArgPF9AEqCOBxOIXn8Nc5yW ZxbBtNKGvp+hh0ezBx3LH0i0nYTOowl/bkFIF58cF1E1Tm6ZfekWBG9n1o6ZDiGw w1YT/xKt00q9SlhzMYHpyrb3QJ5h4CI/VPKQ7sOAc= X-Sasl-enc: MHQtqGbQzFJaAEuw0+prAzhI2zEDgD0oFib6Qk2xscXw 1319311289 Received: from [192.168.1.16] (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id DDFCC483363; Sat, 22 Oct 2011 15:21:27 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <4EA30EB0.6080605@dougbarton.us> Date: Sat, 22 Oct 2011 15:21:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> <121DABD1-65E8-4275-8471-9FA38D25C434@nominet.org.uk> <916CE6CF87173740BC8A2CE44309696203783EE0@008-AM1MPN1-037.mgdnok.nokia.com> <4EA09791.8010705@gmail.com> <94C2E518-F34F-49E4-B15C-2CCCFAA96667@virtualized.org> <12477381-9F74-4C50-B576-47EE4322F6BC@network-heretics.com> <916CE6CF87173740BC8A2CE44309696203784B27@008-AM1MPN1-037.mgdnok.nokia.com> <708F3212-3C9C-4B61-AA77-EFA8F1CA5B04@nominum.com> <30B1AE01-0A35-48D2-91AF-46FC8B60466C@network-heretics.com> <4EA30EB0.6080605@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1084) Cc: "" , "" , "" , "" , "" , "" Subject: Re: [mif] [dnsext] [DNSOP] 2nd Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2011 19:21:31 -0000 On Oct 22, 2011, at 2:42 PM, Doug Barton wrote: > On 10/21/2011 08:13, Keith Moore wrote: >> Names containing "." should not be subject to search lists. Given a >> name like foo.bar, there's no reliable way to tell whether "bar" is a >> TLD or a subdomain of something in the search list.=20 >=20 > I've been following this discussion, mostly in the hopes that it would > go away. :) However since the discussion keeps circling I thought I'd > throw in my 2 cents. >=20 > 1. I think we're all in agreement that dot-terminated names (e.g., > example.) should not be subject to search lists. I personally don't = have > any problems with any document mentioning that this is the expected > behavior. agree. however there are standard protocols for which a trailing dot in = a domain name is a syntax error. > 2. I think most of us agree that a bare label (no dots, e.g., example) > will almost certainly be subject to a search list. My suggestion would > be that the common behavior be described in a "here be dragons" = format, > without attempting to be proscriptive. mostly agree. I don't think "will almost certainly be subject to a = search list" is accurate, though I do think "may be subject to a search = list" is reasonable. > 3. For hostnames with a dot (although not necessarily ending in a TLD, > such as foo.example) I think it's reasonable to say that the desired > behavior is to first try to look them up "as is" without applying a > search list, and if that fails to then apply the search list; with the > same caveat as above, descriptive language for this document instead = of > proscriptive. Strongly disagree. That would leave users without a = protocol-independent way of unambiguously specifying "this is a = fully-qualified domain name". The practice of applying search lists to names with "."s in them needs = to die. Keith From Ted.Lemon@nominum.com Sat Oct 22 12:42:03 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9288821F8505; Sat, 22 Oct 2011 12:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.54 X-Spam-Level: X-Spam-Status: No, score=-106.54 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGDQIyPt4o4C; Sat, 22 Oct 2011 12:42:03 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6A821F84F8; Sat, 22 Oct 2011 12:42:01 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP; Sat, 22 Oct 2011 12:42:02 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id B06331B80CC; Sat, 22 Oct 2011 12:41:59 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 8EAD4190065; Sat, 22 Oct 2011 12:41:58 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.01.0323.003; Sat, 22 Oct 2011 12:41:58 -0700 From: Ted Lemon To: Keith Moore Thread-Topic: [DNSOP] [dnsext] [mif] 2nd Last Call for MIF DNS server selection document Thread-Index: AQHMkAQNa5aq/ROWxEuy8rvfsHIUPpWHXtwAgAADWgCAAdhrgA== Date: Sat, 22 Oct 2011 19:41:58 +0000 Message-ID: <835BF3F4-B0A1-4BBA-988F-FE147573CED0@nominum.com> References: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> <121DABD1-65E8-4275-8471-9FA38D25C434@nominet.org.uk> <916CE6CF87173740BC8A2CE44309696203783EE0@008-AM1MPN1-037.mgdnok.nokia.com> <4EA09791.8010705@gmail.com> <94C2E518-F34F-49E4-B15C-2CCCFAA96667@virtualized.org> <12477381-9F74-4C50-B576-47EE4322F6BC@network-heretics.com> <916CE6CF87173740BC8A2CE44309696203784B27@008-AM1MPN1-037.mgdnok.nokia.com> <708F3212-3C9C-4B61-AA77-EFA8F1CA5B04@nominum.com> <30B1AE01-0A35-48D2-91AF-46FC8B60466C@network-heretics.com> <1DF30BB4-76DB-427A-8ACF-A345BAE26FA6@network-heretics.com> In-Reply-To: <1DF30BB4-76DB-427A-8ACF-A345BAE26FA6@network-heretics.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_835BF3F4B0A14BBA988FFE147573CED0nominumcom_" MIME-Version: 1.0 Cc: DHC WG , "dnsop@ietf.org WG" , "" , dnsext List Subject: Re: [mif] [DNSOP] [dnsext] 2nd Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2011 19:42:03 -0000 --_000_835BF3F4B0A14BBA988FFE147573CED0nominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Oct 21, 2011, at 11:31 AM, Keith Moore wrote: True. But unsecured DNS is easily exploited regardless of whether bare nam= es are used. (and I've never bought the idea that DNSSEC verification can = reasonably be done by an external host) Yes. But if a bare name is used, a bogus search list can also bypass DNSS= EC validation. --_000_835BF3F4B0A14BBA988FFE147573CED0nominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <74A845C4EF7F6B46885862A4F1B79942@nominum.com> Content-Transfer-Encoding: quoted-printable
On Oct 21, 2011, at 11:31 AM, Keith Moore wrote:
True.  But unsecured DNS is easily exploited regardless of whether bare nam= es are used.  (and I've never bought the idea that DNSSEC verification= can reasonably be done by an external host)

Yes.   But if a bare name is used, a bogus search list can also b= ypass DNSSEC validation.
--_000_835BF3F4B0A14BBA988FFE147573CED0nominumcom_-- From dougb@dougbarton.us Sat Oct 22 11:43:04 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76E7021F88B6 for ; Sat, 22 Oct 2011 11:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=-0.135, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BIKCDGebNhpE for ; Sat, 22 Oct 2011 11:43:03 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id 9472E21F8801 for ; Sat, 22 Oct 2011 11:43:03 -0700 (PDT) Received: (qmail 10717 invoked by uid 399); 22 Oct 2011 18:43:01 -0000 Received: from unknown (HELO 172-17-198-245.globalsuite.net) (dougb@dougbarton.us@12.207.105.210) by mail2.fluidhosting.com with ESMTPAM; 22 Oct 2011 18:43:01 -0000 X-Originating-IP: 12.207.105.210 X-Sender: dougb@dougbarton.us Message-ID: <4EA30EB0.6080605@dougbarton.us> Date: Sat, 22 Oct 2011 11:42:56 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111001 Thunderbird/7.0.1 MIME-Version: 1.0 To: Keith Moore References: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> <121DABD1-65E8-4275-8471-9FA38D25C434@nominet.org.uk> <916CE6CF87173740BC8A2CE44309696203783EE0@008-AM1MPN1-037.mgdnok.nokia.com> <4EA09791.8010705@gmail.com> <94C2E518-F34F-49E4-B15C-2CCCFAA96667@virtualized.org> <12477381-9F74-4C50-B576-47EE4322F6BC@network-heretics.com> <916CE6CF87173740BC8A2CE44309696203784B27@008-AM1MPN1-037.mgdnok.nokia.com> <708F3212-3C9C-4B61-AA77-EFA8F1CA5B04@nominum.com> <30B1AE01-0A35-48D2-91AF-46FC8B60466C@network-heretics.com> In-Reply-To: <30B1AE01-0A35-48D2-91AF-46FC8B60466C@network-heretics.com> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 22 Oct 2011 17:32:26 -0700 Cc: "" , "" , "" , "" , "" , "" Subject: Re: [mif] [dnsext] [DNSOP] 2nd Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2011 18:43:04 -0000 On 10/21/2011 08:13, Keith Moore wrote: > Names containing "." should not be subject to search lists. Given a > name like foo.bar, there's no reliable way to tell whether "bar" is a > TLD or a subdomain of something in the search list. I've been following this discussion, mostly in the hopes that it would go away. :) However since the discussion keeps circling I thought I'd throw in my 2 cents. 1. I think we're all in agreement that dot-terminated names (e.g., example.) should not be subject to search lists. I personally don't have any problems with any document mentioning that this is the expected behavior. 2. I think most of us agree that a bare label (no dots, e.g., example) will almost certainly be subject to a search list. My suggestion would be that the common behavior be described in a "here be dragons" format, without attempting to be proscriptive. 3. For hostnames with a dot (although not necessarily ending in a TLD, such as foo.example) I think it's reasonable to say that the desired behavior is to first try to look them up "as is" without applying a search list, and if that fails to then apply the search list; with the same caveat as above, descriptive language for this document instead of proscriptive. In regards to 3, let's say I have a domain, example.org. In my network I have various subdomains that represent various network segments, let's say foo, bar, and baz. Personally, I find it convenient to put 'example.com' in the search list for all of my hosts, and then type 'ssh host.bar' and go off on my merry way. Yes, I understand that in my simple example I could theoretically put all 3 subdomains in the search list. Now assume that my network isn't actually that simple ... hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From matt@conundrum.com Sat Oct 22 23:41:20 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF3B21F84B7; Sat, 22 Oct 2011 23:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ER42OZwPrrB; Sat, 22 Oct 2011 23:41:20 -0700 (PDT) Received: from coke.conundrum.com (coke.conundrum.com [216.235.9.139]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5A121F84B5; Sat, 22 Oct 2011 23:41:19 -0700 (PDT) Received: from chani.conundrum.com (chani.conundrum.com [216.235.10.34]) by coke.conundrum.com (8.13.1/8.12.6) with ESMTP id p9N6dTF1070668; Sun, 23 Oct 2011 02:39:33 -0400 (EDT) (envelope-from matt@conundrum.com) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Matthew Pounsett In-Reply-To: Date: Sun, 23 Oct 2011 02:39:23 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <96472FB7-8425-4928-8F55-2ABF2CB59A93@conundrum.com> References: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> <121DABD1-65E8-4275-8471-9FA38D25C434@nominet.org.uk> <916CE6CF87173740BC8A2CE44309696203783EE0@008-AM1MPN1-037.mgdnok.nokia.com> <4EA09791.8010705@gmail.com> <94C2E518-F34F-49E4-B15C-2CCCFAA96667@virtualized.org> <12477381-9F74-4C50-B576-47EE4322F6BC@network-heretics.com> <916CE6CF87173740BC8A2CE44309696203784B27@008-AM1MPN1-037.mgdnok.nokia.com> <708F3212-3C9C-4B61-AA77-EFA8F1CA5B04@nominum.com> <30B1AE01-0A35-48D2-91AF-46FC8B60466C@network-heretics.com> <4EA30EB0.6080605@dougbarton.us> To: Keith Moore X-Mailer: Apple Mail (2.1251.1) X-Mailman-Approved-At: Sun, 23 Oct 2011 08:39:19 -0700 Cc: "" , "" , Doug Barton , "" , "" , "" , "" Subject: Re: [mif] [dnsext] [DNSOP] 2nd Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2011 06:41:20 -0000 On 2011/10/22, at 15:21, Keith Moore wrote: >=20 > On Oct 22, 2011, at 2:42 PM, Doug Barton wrote: >=20 >> 1. I think we're all in agreement that dot-terminated names (e.g., >> example.) should not be subject to search lists. I personally don't = have >> any problems with any document mentioning that this is the expected >> behavior. >=20 > agree. however there are standard protocols for which a trailing dot = in a domain name is a syntax error. Any protocol that makes a standard FQDN a syntax error is itself in = error. Not to say that these don't exist, but if people are writing = protocols that can't deal with a properly formatted FQDN they need to = stop. Now. > Strongly disagree. That would leave users without a = protocol-independent way of unambiguously specifying "this is a = fully-qualified domain name". >=20 > The practice of applying search lists to names with "."s in them needs = to die. I can't agree with this statement. As others have said, the practice of = using a search list to allow 'ssh foo.bar' to reach = 'foo.bar.example.com' isn't going anywhere, and there are a lot of = people that make extensive use of the convenience. Ask any security = professional about how easy it is to compete with convenient access. I think we need to accept that this practice is here to stay, and figure = out how to deal with it on those terms. From Ted.Lemon@nominum.com Sun Oct 23 12:16:58 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E9E421F8AFB; Sun, 23 Oct 2011 12:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.543 X-Spam-Level: X-Spam-Status: No, score=-106.543 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CaOR2W2z9cxV; Sun, 23 Oct 2011 12:16:57 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id A319221F8AF1; Sun, 23 Oct 2011 12:16:56 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP; Sun, 23 Oct 2011 12:16:57 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 984601B8100; Sun, 23 Oct 2011 12:16:46 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id E5345190061; Sun, 23 Oct 2011 12:16:44 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.01.0323.003; Sun, 23 Oct 2011 12:16:44 -0700 From: Ted Lemon To: Matthew Pounsett Thread-Topic: [dnsext] [DNSOP] [mif] 2nd Last Call for MIF DNS server selection document Thread-Index: AQHMkOpvITs2+PZEH0y/sWnZoIPa2ZWJMvoAgAC9ioCAANObgA== Date: Sun, 23 Oct 2011 19:16:44 +0000 Message-ID: References: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> <121DABD1-65E8-4275-8471-9FA38D25C434@nominet.org.uk> <916CE6CF87173740BC8A2CE44309696203783EE0@008-AM1MPN1-037.mgdnok.nokia.com> <4EA09791.8010705@gmail.com> <94C2E518-F34F-49E4-B15C-2CCCFAA96667@virtualized.org> <12477381-9F74-4C50-B576-47EE4322F6BC@network-heretics.com> <916CE6CF87173740BC8A2CE44309696203784B27@008-AM1MPN1-037.mgdnok.nokia.com> <708F3212-3C9C-4B61-AA77-EFA8F1CA5B04@nominum.com> <30B1AE01-0A35-48D2-91AF-46FC8B60466C@network-heretics.com> <4EA30EB0.6080605@dougbarton.us> <96472FB7-8425-4928-8F55-2ABF2CB59A93@conundrum.com> In-Reply-To: <96472FB7-8425-4928-8F55-2ABF2CB59A93@conundrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_A3FA9584ECE74EA08F86F3CD483F96E8nominumcom_" MIME-Version: 1.0 Cc: DHC WG , "dnsop@ietf.org WG" , "" , dnsext List Subject: Re: [mif] [dnsext] [DNSOP] 2nd Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2011 19:16:58 -0000 --_000_A3FA9584ECE74EA08F86F3CD483F96E8nominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Oct 23, 2011, at 2:39 AM, Matthew Pounsett wrote: I think we need to accept that this practice is here to stay, and figure ou= t how to deal with it on those terms. There is no secure way to do search lists in a MIF environment. Or, reall= y, even in a SIF environment. So saying "we just have to deal with it," w= hile it may seem pragmatic, is really just avoiding the issue: it won't go = away just because we ignore it. Remember: it used to be the case that people would authenticate rsh traffic= using the source IP address, and this persisted long after it was clear th= at it was untenable. But the practice has been largely eliminated at this= point. So it's not the case that just because some practice is "crucial,= " it will inevitably persist forever. The way search lists ought to be handled in a UI is to come up with a list = of all the names that match the term the user has typed, and offer the user= the opportunity to select which of those names to choose. But that's a U= I hack, so essentially out of scope. Also, in order to do this in a MIF e= nvironment, you have to try resolving the name on both interfaces, which so= me people think is not acceptable. --_000_A3FA9584ECE74EA08F86F3CD483F96E8nominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On Oct 23, 2011, at 2:39 AM, Matthew Pounsett wrote:
I think we need to accept that this practice is here to stay, and figure out= how to deal with it on those terms.

There is no secure way to do search lists in a MIF environment.  = Or, really, even in a SIF environment.   So saying "we just have= to deal with it," while it may seem pragmatic, is really just avoidin= g the issue: it won't go away just because we ignore it.

Remember: it used to be the case that people would authenticate rsh tr= affic using the source IP address, and this persisted long after it was cle= ar that it was untenable.   But the practice has been largely eliminat= ed at this point.   So it's not the case that just because some practice is "crucial," it will inevitably= persist forever.

The way search lists ought to be handled in a UI is to come up with a = list of all the names that match the term the user has typed, and offer the= user the opportunity to select which of those names to choose.   But = that's a UI hack, so essentially out of scope.   Also, in order to do this in a MIF environment, you have = to try resolving the name on both interfaces, which some people think is no= t acceptable.

--_000_A3FA9584ECE74EA08F86F3CD483F96E8nominumcom_-- From marka@isc.org Sun Oct 23 16:49:46 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07F1E21F8B5A; Sun, 23 Oct 2011 16:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.268 X-Spam-Level: X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[AWL=-0.269, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kB8Yn68lZHkv; Sun, 23 Oct 2011 16:49:45 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 3D48521F8B2B; Sun, 23 Oct 2011 16:49:45 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 7EEAD5F984C; Sun, 23 Oct 2011 23:49:29 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 39EDD216C6A; Sun, 23 Oct 2011 23:49:27 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 6E1D915C005F; Mon, 24 Oct 2011 10:49:21 +1100 (EST) To: Matthew Pounsett From: Mark Andrews References: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> <121DABD1-65E8-4275-8471-9FA38D25C434@nominet.org.uk> <916CE6CF87173740BC8A2CE44309696203783EE0@008-AM1MPN1-037.mgdnok.nokia.com> <4EA09791.8010705@gmail.com> <94C2E518-F34F-49E4-B15C-2CCCFAA96667@virtualized.org> <12477381-9F74-4C50-B576-47EE4322F6BC@network-heretics.com> <916CE6CF87173740BC8A2CE44309696203784B27@008-AM1MPN1-037.mgdnok.nokia.com> <708F3212-3C9C-4B61-AA77-EFA8F1CA5B04@nominum.com> <30B1AE01-0A35-48D2-91AF-46FC8B60466C@network-heretics.com> <4EA30EB0.6080605@dougbarton.us> <96472FB7-8425-4928-8F55-2ABF2CB59A93@conundrum.com> In-reply-to: Your message of "Sun, 23 Oct 2011 02:39:23 EDT." <96472FB7-8425-4928-8F55-2ABF2CB59A93@conundrum.com> Date: Mon, 24 Oct 2011 10:49:21 +1100 Message-Id: <20111023234921.6E1D915C005F@drugs.dv.isc.org> X-Mailman-Approved-At: Sun, 23 Oct 2011 17:09:09 -0700 Cc: "" , Keith Moore , "" , "" , "" , "" , "" Subject: Re: [mif] [DNSOP] [dnsext] 2nd Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2011 23:49:46 -0000 In message <96472FB7-8425-4928-8F55-2ABF2CB59A93@conundrum.com>, Matthew Pounse tt writes: > > On 2011/10/22, at 15:21, Keith Moore wrote: > > > > > On Oct 22, 2011, at 2:42 PM, Doug Barton wrote: > > > >> 1. I think we're all in agreement that dot-terminated names (e.g., > >> example.) should not be subject to search lists. I personally don't have > >> any problems with any document mentioning that this is the expected > >> behavior. > > > > agree. however there are standard protocols for which a trailing dot in a > domain name is a syntax error. > > Any protocol that makes a standard FQDN a syntax error is itself in error. N > ot to say that these don't exist, but if people are writing protocols that ca > n't deal with a properly formatted FQDN they need to stop. Now. Except it isn't a standard hostname. Periods *seperate* labels in hostnames RFC 952. They DO NOT appear at the end of hostnames. Appending a period to the end of a name is user interface hack to prevent searching. If is also a way to prevent the appending of the current origin to all names in a DNS master file as the current origin is always appended if it isn't done. In addition single labels are not HEIRACHICAL / DOMAIN STYLE names as envisioned when we went from a flat namespace of simple hostnames to a heirarchical namespace. foo.bar is a heirachical hostname. bar is a simple hostname. Why are we trying to bring them back on a global context? > > Strongly disagree. That would leave users without a protocol-independent w > ay of unambiguously specifying "this is a fully-qualified domain name". > > > > The practice of applying search lists to names with "."s in them needs to d > ie. > > I can't agree with this statement. As others have said, the practice of usin > g a search list to allow 'ssh foo.bar' to reach 'foo.bar.example.com' isn't g > oing anywhere, and there are a lot of people that make extensive use of the c > onvenience. Ask any security professional about how easy it is to compete wi > th convenient access. > > I think we need to accept that this practice is here to stay, and figure out > how to deal with it on those terms. People deal with all sorts of changes. Point out the obvious security flaws, make enough fuss, vendors have to ship with this behaviour gone/disabled. People stop worrying about it. > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From moore@network-heretics.com Sun Oct 23 18:17:46 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC6521F86F6; Sun, 23 Oct 2011 18:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cFvrrG6Bz7v7; Sun, 23 Oct 2011 18:17:45 -0700 (PDT) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 4431921F86EE; Sun, 23 Oct 2011 18:17:45 -0700 (PDT) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 86E4820D46; Sun, 23 Oct 2011 21:17:44 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute5.internal (MEProxy); Sun, 23 Oct 2011 21:17:44 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=2ab8+ViZ27U9NFEJlh9l3c60myQ=; b=h2 tC7SBBxmGTJTc7gNDSE+ubRcWNwX4qDtaeZFmBzxwjqsBW1a4QD6eQRIGmsrdnqj MYf2w6Wv7eYdxM3UrYf3ynM0fdYLyw8HTxXAviCUGFXj2Rkc8GVH2sHF8z02Cuhj TUf4iUhtvETBLUZZZfDQfzpN1J+7ZakAFOVWhay/M= X-Sasl-enc: y9OuLXkWY312JgkI8BhujiI98xkBJ+fvetjH0MQAZMnV 1319419063 Received: from [192.168.1.16] (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 6B6E7483436; Sun, 23 Oct 2011 21:17:42 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <96472FB7-8425-4928-8F55-2ABF2CB59A93@conundrum.com> Date: Sun, 23 Oct 2011 21:17:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <628C128E-BDA8-46C3-BF07-364A482FE199@network-heretics.com> References: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> <121DABD1-65E8-4275-8471-9FA38D25C434@nominet.org.uk> <916CE6CF87173740BC8A2CE44309696203783EE0@008-AM1MPN1-037.mgdnok.nokia.com> <4EA09791.8010705@gmail.com> <94C2E518-F34F-49E4-B15C-2CCCFAA96667@virtualized.org> <12477381-9F74-4C50-B576-47EE4322F6BC@network-heretics.com> <916CE6CF87173740BC8A2CE44309696203784B27@008-AM1MPN1-037.mgdnok.nokia.com> <708F3212-3C9C-4B61-AA77-EFA8F1CA5B04@nominum.com> <30B1AE01-0A35-48D2-91AF-46FC8B60466C@network-heretics.com> <4EA30EB0.6080605@dougbarton.us> <96472FB7-8425-4928-8F55-2ABF2CB59A93@conundrum.com> To: Matthew Pounsett X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Sun, 23 Oct 2011 19:08:58 -0700 Cc: "" , "" , Doug Barton , "" , "" , "" , "" Subject: Re: [mif] [dnsext] [DNSOP] 2nd Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 01:17:46 -0000 On Oct 23, 2011, at 2:39 AM, Matthew Pounsett wrote: >=20 > On 2011/10/22, at 15:21, Keith Moore wrote: >=20 >>=20 >> On Oct 22, 2011, at 2:42 PM, Doug Barton wrote: >>=20 >>> 1. I think we're all in agreement that dot-terminated names (e.g., >>> example.) should not be subject to search lists. I personally don't = have >>> any problems with any document mentioning that this is the expected >>> behavior. >>=20 >> agree. however there are standard protocols for which a trailing dot = in a domain name is a syntax error. >=20 > Any protocol that makes a standard FQDN a syntax error is itself in = error. Not to say that these don't exist, but if people are writing = protocols that can't deal with a properly formatted FQDN they need to = stop. Now. Per RFC 952, a standard FQDN does not contain a trailing dot. Neither = do email addresses nor domains in URLs. Changing that set of embedded = practices is much more difficult than changing the expectations of the = relative few who currently expect names with dots to be subject to = search lists. >> Strongly disagree. That would leave users without a = protocol-independent way of unambiguously specifying "this is a = fully-qualified domain name". >>=20 >> The practice of applying search lists to names with "."s in them = needs to die. >=20 > I can't agree with this statement. As others have said, the practice = of using a search list to allow 'ssh foo.bar' to reach = 'foo.bar.example.com' isn't going anywhere, and there are a lot of = people that make extensive use of the convenience. It needs to die because it's fundamentally broken. Vanity TLDs will = only make it worse. I understand that there are sites that use it and = people who are accustomed to it. I don't pretend that we can stop = them. We can, however, explain the negative consequences of doing this = (some of which might be specific to systems with multiple interfaces), = and recommend that they transition away from that practice. And = recommendations for systems with multiple interfaces can be chosen in = such a way as to allow search lists to break even more. Keith From d3e3e3@gmail.com Sun Oct 23 18:18:43 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D503C21F8A35; Sun, 23 Oct 2011 18:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.728 X-Spam-Level: X-Spam-Status: No, score=-103.728 tagged_above=-999 required=5 tests=[AWL=-0.729, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLoYucS6Qaqj; Sun, 23 Oct 2011 18:18:43 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 466B421F89B8; Sun, 23 Oct 2011 18:18:42 -0700 (PDT) Received: by bkas6 with SMTP id s6so8676336bka.31 for ; Sun, 23 Oct 2011 18:18:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=HsFoV4+GW+UNolfedzuqmFG2y0VHS31eIeqxoYGb6sw=; b=p9hn9TaQQ5kcjDNImX5HXStldfMQN91wAZBNP7br1LKZqIJOTVIZ5MtX0g925FjZwv EDGR+B47ydds4vBdrUJBvJuuvXfpxKktRVCf2c4Clpyz6jCdZBqcZ4XBQeQ24F2ocflh a8ixAOf9w2SyRTJ9Ktdcm0pEILhq9td6CkOJk= Received: by 10.223.62.15 with SMTP id v15mr39979659fah.22.1319419119269; Sun, 23 Oct 2011 18:18:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.2.4 with HTTP; Sun, 23 Oct 2011 18:18:19 -0700 (PDT) In-Reply-To: <20111023234921.6E1D915C005F@drugs.dv.isc.org> References: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> <121DABD1-65E8-4275-8471-9FA38D25C434@nominet.org.uk> <916CE6CF87173740BC8A2CE44309696203783EE0@008-AM1MPN1-037.mgdnok.nokia.com> <4EA09791.8010705@gmail.com> <94C2E518-F34F-49E4-B15C-2CCCFAA96667@virtualized.org> <12477381-9F74-4C50-B576-47EE4322F6BC@network-heretics.com> <916CE6CF87173740BC8A2CE44309696203784B27@008-AM1MPN1-037.mgdnok.nokia.com> <708F3212-3C9C-4B61-AA77-EFA8F1CA5B04@nominum.com> <30B1AE01-0A35-48D2-91AF-46FC8B60466C@network-heretics.com> <4EA30EB0.6080605@dougbarton.us> <96472FB7-8425-4928-8F55-2ABF2CB59A93@conundrum.com> <20111023234921.6E1D915C005F@drugs.dv.isc.org> From: Donald Eastlake Date: Sun, 23 Oct 2011 21:18:19 -0400 Message-ID: To: Mark Andrews Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sun, 23 Oct 2011 19:08:58 -0700 Cc: "" , Keith Moore , Matthew Pounsett , "" , "" , "" , "" , "" Subject: Re: [mif] [dhcwg] [DNSOP] [dnsext] 2nd Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 01:18:44 -0000 Hi, On Sun, Oct 23, 2011 at 7:49 PM, Mark Andrews wrote: > > In message <96472FB7-8425-4928-8F55-2ABF2CB59A93@conundrum.com>, Matthew = Pounse > tt writes: >> >> On 2011/10/22, at 15:21, Keith Moore wrote: >> >> > >> > On Oct 22, 2011, at 2:42 PM, Doug Barton wrote: >> > >> >> 1. I think we're all in agreement that dot-terminated names (e.g., >> >> example.) should not be subject to search lists. I personally don't h= ave >> >> any problems with any document mentioning that this is the expected >> >> behavior. >> > >> > agree. =A0however there are standard protocols for which a trailing do= t in a >> domain name is a syntax error. >> >> Any protocol that makes a standard FQDN a syntax error is itself in erro= r. =A0N >> ot to say that these don't exist, but if people are writing protocols th= at ca >> n't deal with a properly formatted FQDN they need to stop. =A0Now. > > Except it isn't a standard hostname. =A0Periods *seperate* labels in > hostnames RFC 952. =A0They DO NOT appear at the end of hostnames. Isn't there the the root label, which is the null string, at the end of all FQDNs, so the period at the end does separate labels? Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com > Appending a period to the end of a name is user interface hack to > prevent searching. =A0If is also a way to prevent the appending of > the current origin to all names in a DNS master file as the current > origin is always appended if it isn't done. > > In addition single labels are not HEIRACHICAL / DOMAIN STYLE names > as envisioned when we went from a flat namespace of simple hostnames > to a heirarchical namespace. > > =A0 =A0 =A0 =A0foo.bar is a heirachical hostname. > =A0 =A0 =A0 =A0bar is a simple hostname. > > Why are we trying to bring them back on a global context? > >> > Strongly disagree. =A0That would leave users without a protocol-indepe= ndent w >> ay of unambiguously specifying "this is a fully-qualified domain name". >> > >> > The practice of applying search lists to names with "."s in them needs= to d >> ie. >> >> I can't agree with this statement. =A0As others have said, the practice = of usin >> g a search list to allow 'ssh foo.bar' to reach 'foo.bar.example.com' is= n't g >> oing anywhere, and there are a lot of people that make extensive use of = the c >> onvenience. =A0Ask any security professional about how easy it is to com= pete wi >> th convenient access. >> >> I think we need to accept that this practice is here to stay, and figure= out >> how to deal with it on those terms. > > People deal with all sorts of changes. =A0Point out the obvious > security flaws, make enough fuss, vendors have to ship with this > behaviour gone/disabled. =A0People stop worrying about it. > >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: marka@is= c.org > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > From marka@isc.org Sun Oct 23 20:57:59 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E56A521F8ACC; Sun, 23 Oct 2011 20:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4XEzklZgECr; Sun, 23 Oct 2011 20:57:59 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 2724721F8A80; Sun, 23 Oct 2011 20:57:59 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id C35C5C9425; Mon, 24 Oct 2011 03:57:43 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 3458B216C6B; Mon, 24 Oct 2011 03:57:43 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 18A9915CA56E; Mon, 24 Oct 2011 14:57:38 +1100 (EST) To: Donald Eastlake From: Mark Andrews References: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> <121DABD1-65E8-4275-8471-9FA38D25C434@nominet.org.uk> <916CE6CF87173740BC8A2CE44309696203783EE0@008-AM1MPN1-037.mgdnok.nokia.com> <4EA09791.8010705@gmail.com> <94C2E518-F34F-49E4-B15C-2CCCFAA96667@virtualized.org> <12477381-9F74-4C50-B576-47EE4322F6BC@network-heretics.com> <916CE6CF87173740BC8A2CE44309696203784B27@008-AM1MPN1-037.mgdnok.nokia.com> <708F3212-3C9C-4B61-AA77-EFA8F1CA5B04@nominum.com> <30B1AE01-0A35-48D2-91AF-46FC8B60466C@network-heretics.com> <4EA30EB0.6080605@dougbarton.us> <96472FB7-8425-4928-8F55-2ABF2CB59A93@conundrum.com> <20111023234921.6E1D915C005F@drugs.dv.isc.org> In-reply-to: Your message of "Sun, 23 Oct 2011 21:18:19 EDT." Date: Mon, 24 Oct 2011 14:57:38 +1100 Message-Id: <20111024035738.18A9915CA56E@drugs.dv.isc.org> Cc: "" , "" , "" , "" Subject: Re: [mif] [dhcwg] [DNSOP] [dnsext] 2nd Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 03:58:00 -0000 In message , Donald Eastlake writes: > Hi, > > On Sun, Oct 23, 2011 at 7:49 PM, Mark Andrews wrote: > > > > In message <96472FB7-8425-4928-8F55-2ABF2CB59A93@conundrum.com>, Matthew = > Pounse > > tt writes: > >> > >> On 2011/10/22, at 15:21, Keith Moore wrote: > >> > >> > > >> > On Oct 22, 2011, at 2:42 PM, Doug Barton wrote: > >> > > >> >> 1. I think we're all in agreement that dot-terminated names (e.g., > >> >> example.) should not be subject to search lists. I personally don't have > >> >> any problems with any document mentioning that this is the expected > >> >> behavior. > >> > > >> > agree. however there are standard protocols for which a trailing dot in a > >> domain name is a syntax error. > >> > >> Any protocol that makes a standard FQDN a syntax error is itself in erro= > r. N > >> ot to say that these don't exist, but if people are writing protocols th= > at ca > >> n't deal with a properly formatted FQDN they need to stop. Now. > > > > Except it isn't a standard hostname. Periods *seperate* labels in > > hostnames RFC 952. They DO NOT appear at the end of hostnames. > > Isn't there the the root label, which is the null string, at the end > of all FQDNs, so the period at the end does separate labels? Not in hostnames. See RFC 952. > Thanks, > Donald > ============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From sthaug@nethelp.no Sun Oct 23 23:08:27 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AECFC11E8091 for ; Sun, 23 Oct 2011 23:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ndtzd1tCHOah for ; Sun, 23 Oct 2011 23:08:26 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 32E4611E808F for ; Sun, 23 Oct 2011 23:08:25 -0700 (PDT) Received: (qmail 49707 invoked from network); 24 Oct 2011 06:08:23 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 24 Oct 2011 06:08:23 -0000 Date: Mon, 24 Oct 2011 08:08:22 +0200 (CEST) Message-Id: <20111024.080822.74700976.sthaug@nethelp.no> To: moore@network-heretics.com From: sthaug@nethelp.no In-Reply-To: <628C128E-BDA8-46C3-BF07-364A482FE199@network-heretics.com> References: <96472FB7-8425-4928-8F55-2ABF2CB59A93@conundrum.com> <628C128E-BDA8-46C3-BF07-364A482FE199@network-heretics.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 23 Oct 2011 23:35:53 -0700 Cc: mif@ietf.org, matt@conundrum.com, dnsop@ietf.org, dnsext@ietf.org, pk@isoc.de, dhcwg@ietf.org, denghui02@hotmail.com Subject: Re: [mif] [DNSOP] [dnsext] 2nd Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 06:08:27 -0000 > > I can't agree with this statement. As others have said, the practice of using a search list to allow 'ssh foo.bar' to reach 'foo.bar.example.com' isn't going anywhere, and there are a lot of people that make extensive use of the convenience. > > It needs to die because it's fundamentally broken. Vanity TLDs will only make it worse. I understand that there are sites that use it and people who are accustomed to it. I don't pretend that we can stop them. We can, however, explain the negative consequences of doing this (some of which might be specific to systems with multiple interfaces), and recommend that they transition away from that practice. And recommendations for systems with multiple interfaces can be chosen in such a way as to allow search lists to break even more. I routinely use short names (and thus search lists) in my work. I am aware of vanity domains, and of RFC 1535. Have I stopped using short names and search lists? No, the convenience is just too great. In trying to stop the use of short names and search lists I believe you're trying to fight human nature. It's a waste of time, and unlikely to be productive. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From moore@network-heretics.com Mon Oct 24 03:53:10 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0AE21F8BDB; Mon, 24 Oct 2011 03:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.381 X-Spam-Level: X-Spam-Status: No, score=-3.381 tagged_above=-999 required=5 tests=[AWL=-0.382, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6eU3CmqIhTcs; Mon, 24 Oct 2011 03:53:08 -0700 (PDT) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id D054B21F8BD8; Mon, 24 Oct 2011 03:53:08 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id E1063205F2; Mon, 24 Oct 2011 06:53:07 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute1.internal (MEProxy); Mon, 24 Oct 2011 06:53:07 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=XxqCXQNflGGfqp26mZ9XFd1o+Mk=; b=GW qiDNEXydGYg5SKe5/z9GL+FpG500FnR8qaqdYUK3zL4FOqaHE/b0yWbZGWrfMPdN rjfpf+mFSo4XOWOGBtwn/5BhX7jMcVH/Pn6QW6ql3B2ONUFJO+R1Yz/eFQqEh6K3 mlrRCvydWtjfyTCGGBTuPy8STt11nsOjP3JES22ls= X-Sasl-enc: GZQd13ftozDfZsaK5kHKyuE49V5sXYB6/QLlNAr2GSkz 1319453587 Received: from [192.168.1.16] (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id E3DB24833A2; Mon, 24 Oct 2011 06:53:05 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <20111024.080822.74700976.sthaug@nethelp.no> Date: Mon, 24 Oct 2011 06:53:05 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <59274CC1-611A-445B-A1CF-A0F49329DC1F@network-heretics.com> References: <96472FB7-8425-4928-8F55-2ABF2CB59A93@conundrum.com> <628C128E-BDA8-46C3-BF07-364A482FE199@network-heretics.com> <20111024.080822.74700976.sthaug@nethelp.no> To: sthaug@nethelp.no X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Mon, 24 Oct 2011 03:58:16 -0700 Cc: mif@ietf.org, matt@conundrum.com, dnsop@ietf.org, dnsext@ietf.org, pk@isoc.de, dhcwg@ietf.org, denghui02@hotmail.com Subject: Re: [mif] [DNSOP] [dnsext] 2nd Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 10:53:10 -0000 On Oct 24, 2011, at 2:08 AM, sthaug@nethelp.no wrote: >>> I can't agree with this statement. As others have said, the = practice of using a search list to allow 'ssh foo.bar' to reach = 'foo.bar.example.com' isn't going anywhere, and there are a lot of = people that make extensive use of the convenience. >>=20 >> It needs to die because it's fundamentally broken. Vanity TLDs will = only make it worse. I understand that there are sites that use it and = people who are accustomed to it. I don't pretend that we can stop = them. We can, however, explain the negative consequences of doing this = (some of which might be specific to systems with multiple interfaces), = and recommend that they transition away from that practice. And = recommendations for systems with multiple interfaces can be chosen in = such a way as to allow search lists to break even more. >=20 > I routinely use short names (and thus search lists) in my work. I am > aware of vanity domains, and of RFC 1535. Have I stopped using short > names and search lists? No, the convenience is just too great. >=20 > In trying to stop the use of short names and search lists I believe > you're trying to fight human nature. It's a waste of time, and = unlikely > to be productive. Just to be clear, I'm not trying to forbid the use of search lists with = "bare" (single-label) names. I'm just pointing out that for the vast = majority of the contexts in which domain names are used, the expectation = is that a domain name that contains a "." is fully-qualified. The need = for domain names to behave consistently from one host to another and one = application to another is much, much more important, than the need to = apply search lists to queries of domain names that contain "."s. =20 From alex@alex.org.uk Mon Oct 24 04:19:26 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D65C21F8CFB; Mon, 24 Oct 2011 04:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92+JBbx-W4Dz; Mon, 24 Oct 2011 04:19:25 -0700 (PDT) Received: from mail.avalus.com (mail.avalus.com [IPv6:2001:41c8:10:1dd::10]) by ietfa.amsl.com (Postfix) with ESMTP id AE59D21F8CFA; Mon, 24 Oct 2011 04:19:25 -0700 (PDT) Received: from [192.168.100.15] (87-194-71-186.bethere.co.uk [87.194.71.186]) by mail.avalus.com (Postfix) with ESMTPSA id B71E6C56100; Mon, 24 Oct 2011 12:19:21 +0100 (BST) Date: Mon, 24 Oct 2011 12:19:21 +0100 From: Alex Bligh To: Keith Moore , sthaug@nethelp.no Message-ID: In-Reply-To: <59274CC1-611A-445B-A1CF-A0F49329DC1F@network-heretics.com> References: <96472FB7-8425-4928-8F55-2ABF2CB59A93@conundrum.com> <628C128E-BDA8-46C3-BF07-364A482FE199@network-heretics.com> <20111024.080822.74700976.sthaug@nethelp.no> <59274CC1-611A-445B-A1CF-A0F49329DC1F@network-heretics.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Mailman-Approved-At: Mon, 24 Oct 2011 04:49:17 -0700 Cc: mif@ietf.org, matt@conundrum.com, dnsop@ietf.org, dnsext@ietf.org, pk@isoc.de, Alex Bligh , dhcwg@ietf.org, denghui02@hotmail.com Subject: Re: [mif] [DNSOP] [dnsext] 2nd Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Alex Bligh List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 11:19:26 -0000 --On 24 October 2011 06:53:05 -0400 Keith Moore wrote: > I'm just pointing out that for the vast majority of the contexts in which > domain names are used, the expectation is that a domain name that > contains a "." is fully-qualified. This is sampling bias. In the vast majority of contexts where domain names (term used loosely) are used, those domain names contain at least one dot. In the vast majority of contexts where domain names (term used loosely) are used, those domain names are fully qualified. It is therefore statistically unsurprising that in the vast majority of contexts where domain with a dot in them, are used they are fully qualified. The question here should be "where search lists are used, are they frequently used in combination with domain names that are not fully qualified". I would suggest the answer to this question is "yes". If so, then to the extent that search lists are supported, you need to make them interwork names with dots in them. Moreover, with a search list of "example.com", having "mail" work, but not "mail.dev" is going to be a pretty surprising outcome. I think the two options are either deprecating search lists (or not supporting them), or supporting them properly, in which case they must be used whatever domain name is specified, and the way to avoid using a search list is the same old hack as before (i.e. putting a dot on the end). -- Alex Bligh From alex@alex.org.uk Mon Oct 24 04:20:54 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51B7421F886A; Mon, 24 Oct 2011 04:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5PVQU91LeoEz; Mon, 24 Oct 2011 04:20:54 -0700 (PDT) Received: from mail.avalus.com (mail.avalus.com [IPv6:2001:41c8:10:1dd::10]) by ietfa.amsl.com (Postfix) with ESMTP id CECAB21F8801; Mon, 24 Oct 2011 04:20:53 -0700 (PDT) Received: from [192.168.100.15] (87-194-71-186.bethere.co.uk [87.194.71.186]) by mail.avalus.com (Postfix) with ESMTPSA id 79769C56100; Mon, 24 Oct 2011 12:20:51 +0100 (BST) Date: Mon, 24 Oct 2011 12:20:50 +0100 From: Alex Bligh To: Ted Lemon , Keith Moore Message-ID: In-Reply-To: <835BF3F4-B0A1-4BBA-988F-FE147573CED0@nominum.com> References: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> <121DABD1-65E8-4275-8471-9FA38D25C434@nominet.org.uk> <916CE6CF87173740BC8A2CE44309696203783EE0@008-AM1MPN1-037.mgdnok.nokia.com> <4EA09791.8010705@gmail.com> <94C2E518-F34F-49E4-B15C-2CCCFAA96667@virtualized.org> <12477381-9F74-4C50-B576-47EE4322F6BC@network-heretics.com> <916CE6CF87173740BC8A2CE44309696203784B27@008-AM1MPN1-037.mgdnok.nokia.com> <708F3212-3C9C-4B61-AA77-EFA8F1CA5B04@nominum.com> <30B1AE01-0A35-48D2-91AF-46FC8B60466C@network-heretics.com> <1DF30BB4-76DB-427A-8ACF-A345BAE26FA6@network-heretics.com> <835BF3F4-B0A1-4BBA-988F-FE147573CED0@nominum.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Mailman-Approved-At: Mon, 24 Oct 2011 04:49:17 -0700 Cc: DHC WG , "dnsop@ietf.org WG" , "" , dnsext List , Alex Bligh Subject: Re: [mif] [dnsext] [DNSOP] 2nd Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Alex Bligh List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 11:20:54 -0000 --On 22 October 2011 19:41:58 +0000 Ted Lemon wrote: > Yes. But if a bare name is used, a bogus search list can also bypass > DNSSEC validation. For the hard of understanding, please could you expand on this? Doesn't the client know the full name being looked up, even with a search list? -- Alex Bligh From moore@network-heretics.com Mon Oct 24 04:30:00 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1689221F8D0A; Mon, 24 Oct 2011 04:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.664 X-Spam-Level: X-Spam-Status: No, score=-3.664 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5KjWjx7pmI0T; Mon, 24 Oct 2011 04:29:59 -0700 (PDT) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 564B621F8D10; Mon, 24 Oct 2011 04:29:59 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id E30F22069D; Mon, 24 Oct 2011 07:29:58 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute3.internal (MEProxy); Mon, 24 Oct 2011 07:29:58 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=jAXQvOkjqKiLN+83phnbP3ADYoA=; b=sD 0now8Xf63AyRMiplS5cWsJdp2t00qNDfDtgqJqi07FujJr4QgP18OauqL6KieZ/+ kVbFZ+FOnr6J4vUzWUwmWsEcyKGCtV0IkB4to93PSQE9404QStuFG5ygSibIQYBr ZpzGpr1H7qVcqMmtR9RA71jhUr7xy0Nxqpz6OY7W4= X-Sasl-enc: +XEezKKO7/7jLeKv5Zb3tBJvhlp1ghuET5P0asA+ObTA 1319455798 Received: from [192.168.1.16] (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id B3B4748336D; Mon, 24 Oct 2011 07:29:56 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Mon, 24 Oct 2011 07:29:55 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <96472FB7-8425-4928-8F55-2ABF2CB59A93@conundrum.com> <628C128E-BDA8-46C3-BF07-364A482FE199@network-heretics.com> <20111024.080822.74700976.sthaug@nethelp.no> <59274CC1-611A-445B-A1CF-A0F49329DC1F@network-heretics.com> To: Alex Bligh X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Mon, 24 Oct 2011 04:49:17 -0700 Cc: mif@ietf.org, matt@conundrum.com, dnsop@ietf.org, dnsext@ietf.org, pk@isoc.de, sthaug@nethelp.no, dhcwg@ietf.org, denghui02@hotmail.com Subject: Re: [mif] [DNSOP] [dnsext] 2nd Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 11:30:00 -0000 On Oct 24, 2011, at 7:19 AM, Alex Bligh wrote: > --On 24 October 2011 06:53:05 -0400 Keith Moore = wrote: >=20 >> I'm just pointing out that for the vast majority of the contexts in = which >> domain names are used, the expectation is that a domain name that >> contains a "." is fully-qualified. >=20 > This is sampling bias. No, I don't think so. The vast majority of contexts where domain names = are used, are contexts in which the domain is supplied by one party and = (at least potentially) used by another party. Email addresses, URLs, = domain names written on advertisements and business cards, etc. =20 > The question here should be "where search lists are used, are > they frequently used in combination with domain names that > are not fully qualified". I would suggest the answer to this > question is "yes". That's not a useful way to phrase the question, because there's no way = for software to know whether or not the user intends that a name = containing "." is fully-qualified. > If so, then to the extent that search lists > are supported, you need to make them interwork names with > dots in them. Moreover, with a search list of "example.com", > having "mail" work, but not "mail.dev" is going to be a > pretty surprising outcome. It will be surprising to that relatively small portion of users that = relies on search lists being applied to multi-label names. But = overall, having a clear, visible distinction between names for which = searching is potentially applied (i.e. bare or single-label names), and = names for which searching is not applied (multi-label names) results in = less surprising behavior for everyone. > I think the two options are either deprecating search lists > (or not supporting them), or supporting them properly, in > which case they must be used whatever domain name is > specified, and the way to avoid using a search list > is the same old hack as before (i.e. putting a dot on the > end). Supporting search lists "properly" is NOT using them whenever a domain = name is specified. That makes all domain names context-sensitive, and = breaks every application that uses domain names supplied by other = parties or in other contexts. Keith From alex@alex.org.uk Mon Oct 24 04:55:47 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B590921F87D3; Mon, 24 Oct 2011 04:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95J0Z4Do5UMZ; Mon, 24 Oct 2011 04:55:47 -0700 (PDT) Received: from mail.avalus.com (mail.avalus.com [IPv6:2001:41c8:10:1dd::10]) by ietfa.amsl.com (Postfix) with ESMTP id C771521F8C60; Mon, 24 Oct 2011 04:55:33 -0700 (PDT) Received: from [192.168.100.15] (87-194-71-186.bethere.co.uk [87.194.71.186]) by mail.avalus.com (Postfix) with ESMTPSA id 3D8D8C560FA; Mon, 24 Oct 2011 12:55:30 +0100 (BST) Date: Mon, 24 Oct 2011 12:55:29 +0100 From: Alex Bligh To: Keith Moore Message-ID: In-Reply-To: References: <96472FB7-8425-4928-8F55-2ABF2CB59A93@conundrum.com> <628C128E-BDA8-46C3-BF07-364A482FE199@network-heretics.com> <20111024.080822.74700976.sthaug@nethelp.no> <59274CC1-611A-445B-A1CF-A0F49329DC1F@network-heretics.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Mailman-Approved-At: Mon, 24 Oct 2011 04:58:39 -0700 Cc: mif@ietf.org, matt@conundrum.com, dnsop@ietf.org, dnsext@ietf.org, pk@isoc.de, Alex Bligh , dhcwg@ietf.org, denghui02@hotmail.com Subject: Re: [mif] [DNSOP] [dnsext] 2nd Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Alex Bligh List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 11:55:48 -0000 --On 24 October 2011 07:29:55 -0400 Keith Moore wrote: >>> I'm just pointing out that for the vast majority of the contexts in >>> which domain names are used, the expectation is that a domain name that >>> contains a "." is fully-qualified. >> >> This is sampling bias. > > No, I don't think so. The vast majority of contexts where domain names > are used, are contexts in which the domain is supplied by one party and > (at least potentially) used by another party. Email addresses, URLs, > domain names written on advertisements and business cards, etc. Of course, but that explicitly excludes every case where a search list is useful. That's why I'm saying you have to look at the cases were a search list is used. In large organisations "domain names" (used loosely) can have dots in and be expected to have search list items appended. Given search list use is rare, it's obviously going to be rare to have them with dots. >> The question here should be "where search lists are used, are >> they frequently used in combination with domain names that >> are not fully qualified". I would suggest the answer to this >> question is "yes". > > That's not a useful way to phrase the question, because there's no way > for software to know whether or not the user intends that a name > containing "." is fully-qualified. You are begging the question. Of course the name "foo.bar" is ambiguous. That's precisely /why/ there is a search list, so foo.bar is only looked up if foo.bar.example.com (or whatever) does not exist. The existence of the "if" step means that the software cannot know what the domain means (in the sense of what it will ultimately resolve to) without doing a lookup. >> If so, then to the extent that search lists >> are supported, you need to make them interwork names with >> dots in them. Moreover, with a search list of "example.com", >> having "mail" work, but not "mail.dev" is going to be a >> pretty surprising outcome. > > It will be surprising to that relatively small portion of users that > relies on search lists being applied to multi-label names. But overall, > having a clear, visible distinction between names for which searching is > potentially applied (i.e. bare or single-label names), and names for > which searching is not applied (multi-label names) results in less > surprising behavior for everyone. I do not think you have established that a relatively small number of users of search lists use multi-label names. I suspect that is not true. >> I think the two options are either deprecating search lists >> (or not supporting them), or supporting them properly, in >> which case they must be used whatever domain name is >> specified, and the way to avoid using a search list >> is the same old hack as before (i.e. putting a dot on the >> end). > > Supporting search lists "properly" is NOT using them whenever a domain > name is specified. That makes all domain names context-sensitive, and > breaks every application that uses domain names supplied by other parties > or in other contexts. I don't have RFC references to hand, but precisely for the reasons you have set out above, I do not believe there is anything within them that search lists should only be used if "a domain name is specified", precisely because it's impossible to tell whether a string with dots in it is "a domain name", or merely something to go on the front of search lists. What you are, I think, saying, is that you want to change the behaviour of search lists so they only work with single labels. What I'm saying is that there are likely to be a significant number of users of search lists who are affected by that, as they currently pass things with dots in them. A completely unscientific analysis I know, but every internet company I have worked with since we moved out of uucp naming has done this, and not because I have told them to. Even current 20 person software house does this. So, if you are going to substantially break search lists (which is not inherently a bad idea - they have caused all sorts of trouble in times past), you might as well just deprecate them or not support them. -- Alex Bligh From moore@network-heretics.com Mon Oct 24 05:16:22 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97AB221F8D07; Mon, 24 Oct 2011 05:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.361 X-Spam-Level: X-Spam-Status: No, score=-3.361 tagged_above=-999 required=5 tests=[AWL=-0.362, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FvmIR3Gn0xsE; Mon, 24 Oct 2011 05:16:21 -0700 (PDT) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id B413C21F8D06; Mon, 24 Oct 2011 05:16:21 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 2C8A0200CE; Mon, 24 Oct 2011 08:16:21 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute3.internal (MEProxy); Mon, 24 Oct 2011 08:16:21 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=UmQDL+lxJSKsSYskY8PEi/zl51Q=; b=Q/ OdCbFI4DrI5390aHKwofEJs5wiLNbOsOL1oFdbX4547tPKTKK8log8HJHi0I11K9 K8qmehl+buwAHP37Bk+Sjwn8Ofm5hW2IY9CoAfk2tEf0D/xDa4HG/GkW+OObAOhX BoSNlUreY046ykOjtgbGj1yCcmXrbNBbbw7vtX2/g= X-Sasl-enc: nGCVSs1QPiuJ+WId8Q20kbu/o7g5mPJG///tgD0gq41j 1319458580 Received: from [192.168.1.16] (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id B08764833D6; Mon, 24 Oct 2011 08:16:18 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Mon, 24 Oct 2011 08:16:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <96472FB7-8425-4928-8F55-2ABF2CB59A93@conundrum.com> <628C128E-BDA8-46C3-BF07-364A482FE199@network-heretics.com> <20111024.080822.74700976.sthaug@nethelp.no> <59274CC1-611A-445B-A1CF-A0F49329DC1F@network-heretics.com> To: Alex Bligh X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Mon, 24 Oct 2011 05:42:10 -0700 Cc: mif@ietf.org, matt@conundrum.com, dnsop@ietf.org, dnsext@ietf.org, pk@isoc.de, dhcwg@ietf.org, denghui02@hotmail.com Subject: Re: [mif] [DNSOP] [dnsext] 2nd Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 12:16:22 -0000 On Oct 24, 2011, at 7:55 AM, Alex Bligh wrote: >=20 >=20 > --On 24 October 2011 07:29:55 -0400 Keith Moore = wrote: >=20 >=20 >>>> I'm just pointing out that for the vast majority of the contexts in >>>> which domain names are used, the expectation is that a domain name = that >>>> contains a "." is fully-qualified. >>>=20 >>> This is sampling bias. >>=20 >> No, I don't think so. The vast majority of contexts where domain = names >> are used, are contexts in which the domain is supplied by one party = and >> (at least potentially) used by another party. Email addresses, URLs, >> domain names written on advertisements and business cards, etc. >=20 > Of course, but that explicitly excludes every case where a search > list is useful. That's the point - search lists are not appropriate most of the time, = and it's very hard for software to distinguish the cases where they are = potentially appropriate from the cases when they're not, and it's not = possible for software to do this in all cases. The presence or absence of a '.' is a simple and easily-understood = convention. It might be somewhat inconvenient for large organizations = that currently rely on search lists for multi-label names, but overall = that's a small price to pay in exchange for having consistent behavior = of domain names across the board. =20 The only reason that those organizations have managed to get away with = it so far is that TLDs (particularly TLDs with more than 2 characters) = have been relatively few in number. But with vanity TLDs this will no = longer be the case. >>> The question here should be "where search lists are used, are >>> they frequently used in combination with domain names that >>> are not fully qualified". I would suggest the answer to this >>> question is "yes". >>=20 >> That's not a useful way to phrase the question, because there's no = way >> for software to know whether or not the user intends that a name >> containing "." is fully-qualified. >=20 > You are begging the question. Of course the name "foo.bar" is > ambiguous. No, it's not ambiguous. It's fully qualified. =20 > That's precisely /why/ there is a search list, so > foo.bar is only looked up if foo.bar.example.com (or whatever) > does not exist. That's insane. That allows a local enterprise to change the meaning of = every domain name. Domain names are supposed to have the same meaning = everywhere in the Internet. >>> If so, then to the extent that search lists >>> are supported, you need to make them interwork names with >>> dots in them. Moreover, with a search list of "example.com", >>> having "mail" work, but not "mail.dev" is going to be a >>> pretty surprising outcome. >>=20 >> It will be surprising to that relatively small portion of users that >> relies on search lists being applied to multi-label names. But = overall, >> having a clear, visible distinction between names for which searching = is >> potentially applied (i.e. bare or single-label names), and names for >> which searching is not applied (multi-label names) results in less >> surprising behavior for everyone. >=20 > I do not think you have established that a relatively small number > of users of search lists use multi-label names. I suspect that > is not true. My assumption is that search lists in conjunction with multi-label names = are mostly used within fairly large enterprises, but search lists are = potentially in much wider use. >>> I think the two options are either deprecating search lists >>> (or not supporting them), or supporting them properly, in >>> which case they must be used whatever domain name is >>> specified, and the way to avoid using a search list >>> is the same old hack as before (i.e. putting a dot on the >>> end). >>=20 >> Supporting search lists "properly" is NOT using them whenever a = domain >> name is specified. That makes all domain names context-sensitive, = and >> breaks every application that uses domain names supplied by other = parties >> or in other contexts. >=20 > I don't have RFC references to hand, but precisely for the reasons you = have > set out above, I do not believe there is anything within them that = search > lists should only be used if "a domain name is specified", precisely > because it's impossible to tell whether a string with dots in it is "a > domain name", or merely something to go on the front of search lists. >=20 > What you are, I think, saying, is that you want to change the = behaviour of > search lists so they only work with single labels. What I'm saying is = that > there are likely to be a significant number of users of search lists = who > are affected by that, as they currently pass things with dots in them. No disagreement on that point. But search lists always have been = broken. It's just unfortunate that DNS APIs have supported them for so = long, and their behavior has become entrenched in several organizations = (including some that ought to know better). My belief is that local names (i.e. bare or single-label names) are = useful and necessary but their behavior cannot really be standardized. = So letting them continue to be subject to search lists is a useful = compromise that is less drastic than doing away with search lists = entirely. It also has the virtue of being a simple rule that users can = easily understand (a name with a "." is always fully qualified and = usable in a global context, a name without a "." is ambiguous and only = useful in a local context). Keith From dougb@dougbarton.us Mon Oct 24 13:52:44 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0694F11E80A4 for ; Mon, 24 Oct 2011 13:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.067 X-Spam-Level: X-Spam-Status: No, score=-3.067 tagged_above=-999 required=5 tests=[AWL=0.532, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7R2Q9RQQ8W0 for ; Mon, 24 Oct 2011 13:52:42 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id F37DC21F8C42 for ; Mon, 24 Oct 2011 13:52:41 -0700 (PDT) Received: (qmail 11010 invoked by uid 399); 24 Oct 2011 20:52:36 -0000 Received: from unknown (HELO 172-17-198-245.globalsuite.net) (dougb@dougbarton.us@12.207.105.210) by mail2.fluidhosting.com with ESMTPAM; 24 Oct 2011 20:52:36 -0000 X-Originating-IP: 12.207.105.210 X-Sender: dougb@dougbarton.us Message-ID: <4EA5D012.9090708@dougbarton.us> Date: Mon, 24 Oct 2011 13:52:34 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111001 Thunderbird/7.0.1 MIME-Version: 1.0 To: Keith Moore References: <96472FB7-8425-4928-8F55-2ABF2CB59A93@conundrum.com> <628C128E-BDA8-46C3-BF07-364A482FE199@network-heretics.com> <20111024.080822.74700976.sthaug@nethelp.no> <59274CC1-611A-445B-A1CF-A0F49329DC1F@network-heretics.com> In-Reply-To: X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: mif@ietf.org, dnsop@ietf.org, dnsext@ietf.org, pk@isoc.de, Alex Bligh , dhcwg@ietf.org Subject: Re: [mif] [dnsext] [DNSOP] 2nd Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 20:52:44 -0000 On 10/24/2011 05:16, Keith Moore wrote: > That's the point - search lists are not appropriate most of the time, and it's very hard for software to distinguish the cases where they are potentially appropriate from the cases when they're not, and it's not possible for software to do this in all cases. There's been something missing from this discussion, and I finally put my finger on it. TMK most stub resolvers have an option similar to this one from ISC's: ndots:n sets a threshold for the number of dots which must appear in a name given to res_query() (see resolver(3)) before an initial absolute query will be made. The default for n is “1â€, mean†ing that if there are any dots in a name, the name will be tried first as an absolute name before any search list elements are appended to it. So it seems that this question is already a matter of local policy, which given the number and quality of the divergent views seems eminently reasonable. Can we move on now? Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From moore@network-heretics.com Mon Oct 24 13:58:53 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42CCA21F8C5A; Mon, 24 Oct 2011 13:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VqDN4cuWe+SI; Mon, 24 Oct 2011 13:58:52 -0700 (PDT) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 8FCA621F8C56; Mon, 24 Oct 2011 13:58:52 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id D566620A34; Mon, 24 Oct 2011 16:58:51 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute1.internal (MEProxy); Mon, 24 Oct 2011 16:58:51 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=IRB4Gz658TNDQWj+N4Ot8jigmhI=; b=O3 OhK1kLvs6eW77HbfkGrexZcqeVv1c+hdsra2Waknt583kAtrgNbKlP1WSg30kM7Y 9EyDlBVvchsdFNtia9ZME+iwywIpabCYY4FvPdPOmczxCch90lSzDDaM4zRnTAlf VAJVRCD1EiaKcwNq8EfEdtuIb65bi9+xAVUsCKP2Y= X-Sasl-enc: IIWzyM/J8Wgor2KFWDbIhub1hhy7v2uriFKA/LuGAMDO 1319489931 Received: from [192.168.1.16] (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 32E9A483436; Mon, 24 Oct 2011 16:58:50 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: Keith Moore In-Reply-To: <4EA5D012.9090708@dougbarton.us> Date: Mon, 24 Oct 2011 16:58:49 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <45E6700D-4207-4807-B8A4-2CFC56440038@network-heretics.com> References: <96472FB7-8425-4928-8F55-2ABF2CB59A93@conundrum.com> <628C128E-BDA8-46C3-BF07-364A482FE199@network-heretics.com> <20111024.080822.74700976.sthaug@nethelp.no> <59274CC1-611A-445B-A1CF-A0F49329DC1F@network-heretics.com> <4EA5D012.9090708@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1084) Cc: mif@ietf.org, dnsop@ietf.org, dnsext@ietf.org, pk@isoc.de, Alex Bligh , dhcwg@ietf.org Subject: Re: [mif] [dnsext] [DNSOP] 2nd Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 20:58:53 -0000 On Oct 24, 2011, at 4:52 PM, Doug Barton wrote: > On 10/24/2011 05:16, Keith Moore wrote: >> That's the point - search lists are not appropriate most of the time, = and it's very hard for software to distinguish the cases where they are = potentially appropriate from the cases when they're not, and it's not = possible for software to do this in all cases. >=20 > There's been something missing from this discussion, and I finally put > my finger on it. TMK most stub resolvers have an option similar to = this > one from ISC's: >=20 > ndots:n > sets a threshold for the number of dots which > must appear in a name given to res_query() (see > resolver(3)) before an initial absolute query > will be made. The default for n is =E2=80=9C1=E2=80=9D, = mean=E2=80=90 > ing that if there are any dots in a name, the > name will be tried first as an absolute name > before any search list elements are appended to > it. >=20 > So it seems that this question is already a matter of local policy, > which given the number and quality of the divergent views seems > eminently reasonable. Can we move on now? No, because relying on "local policy" is not sufficient for = interoperability. I think there's a need for IETF to document why any other value than 1 = is a Bad Idea, and more to the point, why it will break things. The = problem isn't entirely specific to hosts with multiple interfaces. But = given that using multiple interfaces makes the problem worse, MIF might = want to take on some of the work of documenting why it will break = things. Keith From dougb@dougbarton.us Mon Oct 24 14:36:22 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C945C11E8160 for ; Mon, 24 Oct 2011 14:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.952 X-Spam-Level: X-Spam-Status: No, score=-2.952 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lacy9SWf2z9U for ; Mon, 24 Oct 2011 14:36:22 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id 546F011E8146 for ; Mon, 24 Oct 2011 14:36:22 -0700 (PDT) Received: (qmail 25785 invoked by uid 399); 24 Oct 2011 21:29:39 -0000 Received: from unknown (HELO 172-17-198-245.globalsuite.net) (dougb@dougbarton.us@12.207.105.210) by mail2.fluidhosting.com with ESMTPAM; 24 Oct 2011 21:29:39 -0000 X-Originating-IP: 12.207.105.210 X-Sender: dougb@dougbarton.us Message-ID: <4EA5D8C1.9060303@dougbarton.us> Date: Mon, 24 Oct 2011 14:29:37 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111001 Thunderbird/7.0.1 MIME-Version: 1.0 To: Keith Moore References: <96472FB7-8425-4928-8F55-2ABF2CB59A93@conundrum.com> <628C128E-BDA8-46C3-BF07-364A482FE199@network-heretics.com> <20111024.080822.74700976.sthaug@nethelp.no> <59274CC1-611A-445B-A1CF-A0F49329DC1F@network-heretics.com> <4EA5D012.9090708@dougbarton.us> <45E6700D-4207-4807-B8A4-2CFC56440038@network-heretics.com> In-Reply-To: <45E6700D-4207-4807-B8A4-2CFC56440038@network-heretics.com> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: mif@ietf.org, dnsop@ietf.org, dnsext@ietf.org, pk@isoc.de, Alex Bligh , dhcwg@ietf.org Subject: Re: [mif] [dnsext] [DNSOP] 2nd Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 21:36:22 -0000 On 10/24/2011 13:58, Keith Moore wrote: > > On Oct 24, 2011, at 4:52 PM, Doug Barton wrote: > >> On 10/24/2011 05:16, Keith Moore wrote: >>> That's the point - search lists are not appropriate most of the time, and it's very hard for software to distinguish the cases where they are potentially appropriate from the cases when they're not, and it's not possible for software to do this in all cases. >> >> There's been something missing from this discussion, and I finally put >> my finger on it. TMK most stub resolvers have an option similar to this >> one from ISC's: >> >> ndots:n >> sets a threshold for the number of dots which >> must appear in a name given to res_query() (see >> resolver(3)) before an initial absolute query >> will be made. The default for n is “1â€, mean†>> ing that if there are any dots in a name, the >> name will be tried first as an absolute name >> before any search list elements are appended to >> it. >> >> So it seems that this question is already a matter of local policy, >> which given the number and quality of the divergent views seems >> eminently reasonable. Can we move on now? > > No, because relying on "local policy" is not sufficient for interoperability. I don't see how local resolution issues feed into interoperability here. > I think there's a need for IETF to document why any other value than 1 is a Bad Idea, and more to the point, why it will break things. The problem isn't entirely specific to hosts with multiple interfaces. But given that using multiple interfaces makes the problem worse, MIF might want to take on some of the work of documenting why it will break things. That seems to be an opinion of yours that isn't widely shared. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From moore@network-heretics.com Mon Oct 24 16:30:13 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D35711E81DB; Mon, 24 Oct 2011 16:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[AWL=0.348, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id min-Btt8dL2c; Mon, 24 Oct 2011 16:30:12 -0700 (PDT) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id CD64A11E81E6; Mon, 24 Oct 2011 16:30:11 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 6BACB20A60; Mon, 24 Oct 2011 19:30:11 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute6.internal (MEProxy); Mon, 24 Oct 2011 19:30:11 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=fMTskqonfUOLo+LqPAWo2oS/tZ0=; b=Or ZV0teLABvMSqecZZWVflatvadDZYVVLPDA6vn0nkuUHrrtXPoEmSi/xnxcMyyp82 DWBxUpqaOfx3dD+SF5iYH6WrCRfLkQ5xwsoPD6eX0P47BUIfCIs78zwYSYetP7w7 UVVCILNZIn1smCY1FyBEJhkeOrJjVsSKojNzglYpM= X-Sasl-enc: VHzIfnm4khwY8ZXipl/UYTYzRW6f5Edit35m/RnWH21M 1319499010 Received: from [192.168.1.16] (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 648364833DA; Mon, 24 Oct 2011 19:30:09 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <1319496624.28149.399.camel@destiny.pc.cs.cmu.edu> Date: Mon, 24 Oct 2011 19:30:08 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <96472FB7-8425-4928-8F55-2ABF2CB59A93@conundrum.com> <628C128E-BDA8-46C3-BF07-364A482FE199@network-heretics.com> <20111024.080822.74700976.sthaug@nethelp.no> <59274CC1-611A-445B-A1CF-A0F49329DC1F@network-heretics.com> <4EA5D012.9090708@dougbarton.us> <28623_1319491641_p9OLRK2S028590_45E6700D-4207-4807-B8A4-2CFC56440038@network-heretics.com> <1319496624.28149.399.camel@destiny.pc.cs.cmu.edu> To: Jeffrey Hutzelman X-Mailer: Apple Mail (2.1084) Cc: mif@ietf.org, dnsop@ietf.org, Doug Barton , dnsext@ietf.org, pk@isoc.de, Alex Bligh , dhcwg@ietf.org Subject: Re: [mif] [dhcwg] [dnsext] [DNSOP] 2nd Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 23:30:13 -0000 On Oct 24, 2011, at 6:50 PM, Jeffrey Hutzelman wrote: >>> So it seems that this question is already a matter of local policy, >>> which given the number and quality of the divergent views seems >>> eminently reasonable. Can we move on now? >>=20 >> No, because relying on "local policy" is not sufficient for = interoperability. >=20 > For interoperability, one can use absolute names, with the trailing = dot, uh, no. Names with trailing dots aren't allowed in many contexts. = And in some of the contexts in which they are allowed, they get = "canonicalized" to names without trailing dots. > or specify that in the context of whatever protocol, all names are to = be > taken as relative to the root, or use other than a printed > representation. ...so a DNS name means different things in one context than in another. = Bad Idea. > In some cases this may require that implementations use > resolver interfaces which make it clear that a name to be resolved is > absolute, or that they append the empty label to relative names before > passing them on to the resolver. >=20 > On the other hand, in user interface, which is primarily where = relative > names are intended to be used, local policy is quite sufficient. no. Domain names are written on buses, billboards, business cards. = They do get transcribed, quite often actually, and they need to have the = same meanings when typed in as they do when clicked on. In a small number of cases, where a user gets immediate feedback after = he types in the name and before a host attempts to contact a server, it = might be sufficient to "canonicalize" a name, show the user how the name = will actually be interpreted, and let him click "ok" before contacting = the server. But even then, what if the "canonicalization" is wrong? = How is the user supposed to know how to tell the software to treat the = name as an FQDN? If he types in the '.', the dot will disappear when = the name is canonicalized. That's not exactly effective reinforcement. = It says to the user "you should not have typed in that final dot". = And the practice of not using a trailing "." is nearly universal. = Changing that practice is much harder than changing from IPv4 and IPv6. Some people are working way too hard to try to save something that was = never a good idea in the first place. =20 I'm not arguing that all software that currently applies searching to = names with dots in them has to die a violent death, and immediately = either be updated or deleted from all computers everywhere (as if...). = I'm just saying that IETF should recommend against the practice of using = search lists with multi-label names, and document the harm that it does. = Sites can still do it if they want to, or they can manage their own = transitions away from using search paths for such names, on their own = timeframes. After all, this has been a practice for ~30 years in some = places, nobody should expect it all to change overnight. > As long as I and the software on my machine agree on what a name I = type means, it's none of the IETF's business. (So what? It's also none of IETF's business if you _______________ = <---- pick anything that is utterly senseless here) Of course, you can do whatever you want. But IETF should promote = practices that make good sense, even though we realize that some people = will decide for themselves to not follow them. > Can an enterprise change the name of every domain name? On machines > they control, yes. Of course they can. But it makes absolutely no sense for IETF to bless = that practice or to ignore it when we know that it does harm. =20 The presumption of the standards is that you want your machines to = interoperate with other machines. If you don't want interoperability, = have a day - screw things up however you want. (as long as you only = affect your own machines, of course.). Nobody's forcing you to keep = your machines conforming. > While I agree wholeheartedly with the notion of a unique domain name > space, I also believe that mapping a relative or abbreviated name onto > that namespace is _entirely_ a matter of local policy. That's a convenient philosophy if you _only_ care that local things = interoperate with one another. > It is perhaps > appropriate for the IETF to provide mechanisms for distributing that > policy, for those who wish to use them, but not to dictate what the > policy must be. IETF's job is to help the Internet work, not to endorse every bit of = local brain damage that people are attached to. > Do things get worse as new TLDs appear? Yes, sometimes. Be prepared for it to happen more often. Do you really want to rethink = your naming scheme every time someone creates a vanity TLD that happens = to collide with some subdomain of cmu.edu? Even if that's only once = every year or three, how often does it need to happen before it's no = longer worth the trouble? I mean, I'm sure that the relevant people at CMU are quite capable of = evaluating that decision for themselves. An IETF RFC isn't going to = tell them anything that they can't figure out already. But that's not = true of Internet users, network administrators, software implementors in = general. > Does that mean we're abandoning "options ndots:2"? Not aggressively. > It has faded over time, but more due to a failure to actively apply it > to newer systems than to any conscious decision that it's a problem. >=20 > Further, given this position, I wonder why you think even a value of 1 > is acceptable in the face of vanity TLDs. Because (a) local names are essential, (b) the ability to distinguish = local names from FQDNs is also essential, and (c) use of a single-label = name as a local name (meaning, a name subject to local interpretation) = is a very widespread and well-entrenched practice. Sites that = associate address (or MX) records with vanity TLDs will lose, and they = deserve to lose. > I know why I do, both from > the perspective of an IETF (it's a local policy matter, period) and = for > myself (search for local names first, don't trust DNS results (yet) = for > security, and write absolute names when you want to bypass search > lists). The way you write an absolute name is to include a '.' in it. Keith From marka@isc.org Mon Oct 24 17:09:23 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5DFE21F8C4A; Mon, 24 Oct 2011 17:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.259 X-Spam-Level: X-Spam-Status: No, score=-2.259 tagged_above=-999 required=5 tests=[AWL=-0.260, BAYES_00=-2.599, J_CHICKENPOX_51=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6UpPCwVf8ZW; Mon, 24 Oct 2011 17:09:23 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 9C91621F8C09; Mon, 24 Oct 2011 17:09:22 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 5EFE85F984C; Tue, 25 Oct 2011 00:09:02 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 507EA216C6A; Tue, 25 Oct 2011 00:08:55 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 61F9815CE347; Tue, 25 Oct 2011 11:08:53 +1100 (EST) To: Lawrence Conroy From: Mark Andrews References: <96472FB7-8425-4928-8F55-2ABF2CB59A93@conundrum.com> <628C128E-BDA8-46C3-BF07-364A482FE199@network-heretics.com> <20111024.080822.74700976.sthaug@nethelp.no> <59274CC1-611A-445B-A1CF-A0F49329DC1F@network-heretics.com> <4EA5D012.9090708@dougbarton.us> In-reply-to: Your message of "Mon, 24 Oct 2011 22:34:23 BST." Date: Tue, 25 Oct 2011 11:08:53 +1100 Message-Id: <20111025000853.61F9815CE347@drugs.dv.isc.org> Cc: dnsop@ietf.org, mif@ietf.org, dnsext@ietf.org Subject: Re: [mif] [dnsext] [DNSOP] 2nd Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 00:09:23 -0000 In message , Lawrence Con roy writes: > Hi there Doug, Keith, folks, > Speaking of broken mechanisms ... how many dots? > arstechnica.com is OK > co.uk is not OK > > ndots strikes me as a chocolate soldier in the fire used to warm the > chocolate teapot that is search lists. > > At best these are context dependent (and keep IT support in business). At > worst ... > one day I WILL be arrested for tazering the bean counter (why is it > always one of > those?) who insists that "intranet" is a fine web server name useful > anywhere. > > [I came damn close a few times with Yankee hotel reservations accessible > only via > 1-800 'phone numbers] > > Speaking of interoperability -- the comment "it works for everyone here" > is not > a good sign that the solution is interoperable. > > IMO, search lists and ndots are both abominations, and should not be > given the oxygen of publicity. > > all the best, > Lawrence > > > > On 24 Oct 2011, at 21:52, Doug Barton wrote: > > On 10/24/2011 05:16, Keith Moore wrote: > >> That's the point - search lists are not appropriate most of the time, > and it's very hard for software to distinguish the cases where they are > potentially appropriate from the cases when they're not, and it's not > possible for software to do this in all cases. > > > > There's been something missing from this discussion, and I finally put > > my finger on it. TMK most stub resolvers have an option similar to this > > one from ISC's: > > > > ndots:n > > sets a threshold for the number of dots which > > must appear in a name given to res_query() (see > > resolver(3)) before an initial absolute query > > will be made. The default for n is “1â€, mean†> > ing that if there are any dots in a name, the > > name will be tried first as an absolute name > > before any search list elements are appended to > > it. > > > > So it seems that this question is already a matter of local policy, > > which given the number and quality of the divergent views seems > > eminently reasonable. Can we move on now? > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext In many cases when ndots is not 1 there are no DNS entries that will match .. That said the set of is growing so it is going to get harder and harder to ensure that this condition is being met. Walled gardens shouldn't be creating their own TLDs. ISP's, hotspots, etc. should not be search list at all. The definitely should not be relying on "label" being found on a search list. As far as I can tell there are only two places where setting search list make sense. 1. Enterprises. 2. Homes. Everywhere else you DO NOT control the machine requesting the address and setting search lists could actually result in criminal prosecution. Just because the machine requested a search list it doesn't mean that you should be supplying one. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From mayer@gis.net Mon Oct 24 10:19:07 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 717C811E8094; Mon, 24 Oct 2011 10:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ekL5QH-mgr1z; Mon, 24 Oct 2011 10:19:07 -0700 (PDT) Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by ietfa.amsl.com (Postfix) with ESMTP id C0A9711E808D; Mon, 24 Oct 2011 10:19:06 -0700 (PDT) Received: from [198.22.153.6] (helo=[10.60.100.127]) by mail1.ntp.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RIOAk-000HJu-6D; Mon, 24 Oct 2011 17:18:51 +0000 Message-ID: <4EA59DF0.9090802@gis.net> Date: Mon, 24 Oct 2011 13:18:40 -0400 From: Danny Mayer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Mark Andrews References: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> <121DABD1-65E8-4275-8471-9FA38D25C434@nominet.org.uk> <916CE6CF87173740BC8A2CE44309696203783EE0@008-AM1MPN1-037.mgdnok.nokia.com> <4EA09791.8010705@gmail.com> <94C2E518-F34F-49E4-B15C-2CCCFAA96667@virtualized.org> <12477381-9F74-4C50-B576-47EE4322F6BC@network-heretics.com> <916CE6CF87173740BC8A2CE44309696203784B27@008-AM1MPN1-037.mgdnok.nokia.com> <708F3212-3C9C-4B61-AA77-EFA8F1CA5B04@nominum.com> <30B1AE01-0A35-48D2-91AF-46FC8B60466C@network-heretics.com> <4EA30EB0.6080605@dougbarton.us> <96472FB7-8425-4928-8F55-2ABF2CB59A93@conundrum.com> <20111023234921.6E1D915C005F@drugs.dv.isc.org> In-Reply-To: <20111023234921.6E1D915C005F@drugs.dv.isc.org> X-Enigmail-Version: 1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 198.22.153.6 X-SA-Exim-Rcpt-To: marka@isc.org, matt@conundrum.com, mif@ietf.org, moore@network-heretics.com, dnsop@ietf.org, dnsext@ietf.org, pk@isoc.de, Ted.Lemon@nominum.com, dhcwg@ietf.org, denghui02@hotmail.com, brian.e.carpenter@gmail.com X-SA-Exim-Mail-From: mayer@gis.net X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) X-Mailman-Approved-At: Mon, 24 Oct 2011 20:24:55 -0700 Cc: "" , Keith Moore , Matthew Pounsett , "" , "" , "" , "" , "" Subject: Re: [mif] [dhcwg] [DNSOP] [dnsext] 2nd Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mayer@gis.net List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 17:19:07 -0000 On 10/23/2011 7:49 PM, Mark Andrews wrote: > > In message <96472FB7-8425-4928-8F55-2ABF2CB59A93@conundrum.com>, Matthew Pounse > tt writes: >> >> On 2011/10/22, at 15:21, Keith Moore wrote: >> >>> >>> On Oct 22, 2011, at 2:42 PM, Doug Barton wrote: >>> >>>> 1. I think we're all in agreement that dot-terminated names (e.g., >>>> example.) should not be subject to search lists. I personally don't have >>>> any problems with any document mentioning that this is the expected >>>> behavior. >>> >>> agree. however there are standard protocols for which a trailing dot in a >> domain name is a syntax error. >> >> Any protocol that makes a standard FQDN a syntax error is itself in error. N >> ot to say that these don't exist, but if people are writing protocols that ca >> n't deal with a properly formatted FQDN they need to stop. Now. > > Except it isn't a standard hostname. Periods *seperate* labels in > hostnames RFC 952. They DO NOT appear at the end of hostnames. > > Appending a period to the end of a name is user interface hack to > prevent searching. If is also a way to prevent the appending of > the current origin to all names in a DNS master file as the current > origin is always appended if it isn't done. > > In addition single labels are not HEIRACHICAL / DOMAIN STYLE names > as envisioned when we went from a flat namespace of simple hostnames > to a heirarchical namespace. > > foo.bar is a heirachical hostname. > bar is a simple hostname. > > Why are we trying to bring them back on a global context? I'm not even sure why we are having this discussion. You are right, of course. DNS doesn't know anything about search lists, nor does it care. Any valid string presented to DNS is by definition a FQDN and DNS will proceed accordingly. If the application choosing to consult a domain search list it's up to that application, but DNS is not involved in the consultation. Danny From lconroy@insensate.co.uk Mon Oct 24 14:34:27 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48E5D21F8A97; Mon, 24 Oct 2011 14:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_51=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NsQIbihlDX51; Mon, 24 Oct 2011 14:34:26 -0700 (PDT) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by ietfa.amsl.com (Postfix) with ESMTP id 5052221F867F; Mon, 24 Oct 2011 14:34:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id D7BA9D27E2; Mon, 24 Oct 2011 22:34:24 +0100 (BST) X-Virus-Scanned: amavisd-new at insensate.co.uk Received: from insensate.co.uk ([127.0.0.1]) by localhost (psyche.insensate.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZ1aekG6CA5N; Mon, 24 Oct 2011 22:34:24 +0100 (BST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id CC905D27D7; Mon, 24 Oct 2011 22:34:23 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: Lawrence Conroy In-Reply-To: <4EA5D012.9090708@dougbarton.us> Date: Mon, 24 Oct 2011 22:34:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <96472FB7-8425-4928-8F55-2ABF2CB59A93@conundrum.com> <628C128E-BDA8-46C3-BF07-364A482FE199@network-heretics.com> <20111024.080822.74700976.sthaug@nethelp.no> <59274CC1-611A-445B-A1CF-A0F49329DC1F@network-heretics.com> <4EA5D012.9090708@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Mon, 24 Oct 2011 20:24:55 -0700 Cc: dnsop@ietf.org, mif@ietf.org, Keith Moore , dnsext@ietf.org Subject: Re: [mif] [dnsext] [DNSOP] 2nd Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 21:34:27 -0000 Hi there Doug, Keith, folks, Speaking of broken mechanisms ... how many dots? arstechnica.com is OK co.uk is not OK ndots strikes me as a chocolate soldier in the fire used to warm the = chocolate teapot that is search lists. At best these are context dependent (and keep IT support in business). = At worst ... one day I WILL be arrested for tazering the bean counter (why is it = always one of those?) who insists that "intranet" is a fine web server name useful = anywhere. [I came damn close a few times with Yankee hotel reservations accessible = only via 1-800 'phone numbers] Speaking of interoperability -- the comment "it works for everyone here" = is not a good sign that the solution is interoperable. IMO, search lists and ndots are both abominations, and should not be = given the oxygen of publicity. all the best, Lawrence On 24 Oct 2011, at 21:52, Doug Barton wrote: > On 10/24/2011 05:16, Keith Moore wrote: >> That's the point - search lists are not appropriate most of the time, = and it's very hard for software to distinguish the cases where they are = potentially appropriate from the cases when they're not, and it's not = possible for software to do this in all cases. >=20 > There's been something missing from this discussion, and I finally put > my finger on it. TMK most stub resolvers have an option similar to = this > one from ISC's: >=20 > ndots:n > sets a threshold for the number of dots which > must appear in a name given to res_query() (see > resolver(3)) before an initial absolute query > will be made. The default for n is =E2=80=9C1=E2=80=9D, = mean=E2=80=90 > ing that if there are any dots in a name, the > name will be tried first as an absolute name > before any search list elements are appended to > it. >=20 > So it seems that this question is already a matter of local policy, > which given the number and quality of the divergent views seems > eminently reasonable. Can we move on now? From jhutz@cmu.edu Mon Oct 24 15:50:47 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C58111E81D3; Mon, 24 Oct 2011 15:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.249 X-Spam-Level: X-Spam-Status: No, score=-107.249 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2L6j9wsUbB0E; Mon, 24 Oct 2011 15:50:46 -0700 (PDT) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by ietfa.amsl.com (Postfix) with ESMTP id 10B3511E81CD; Mon, 24 Oct 2011 15:50:42 -0700 (PDT) Received: from [66.233.146.161] (66-233-146-161.pit.clearwire-wmx.net [66.233.146.161] (may be forged)) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id p9OMoQWP023425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Oct 2011 18:50:28 -0400 (EDT) From: Jeffrey Hutzelman To: Keith Moore In-Reply-To: <28623_1319491641_p9OLRK2S028590_45E6700D-4207-4807-B8A4-2CFC56440038@network-heretics.com> References: <96472FB7-8425-4928-8F55-2ABF2CB59A93@conundrum.com> <628C128E-BDA8-46C3-BF07-364A482FE199@network-heretics.com> <20111024.080822.74700976.sthaug@nethelp.no> <59274CC1-611A-445B-A1CF-A0F49329DC1F@network-heretics.com> <4EA5D012.9090708@dougbarton.us> <28623_1319491641_p9OLRK2S028590_45E6700D-4207-4807-B8A4-2CFC56440038@network-heretics.com> Content-Type: text/plain; charset="UTF-8" Date: Mon, 24 Oct 2011 18:50:24 -0400 Message-ID: <1319496624.28149.399.camel@destiny.pc.cs.cmu.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 8bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 X-Mailman-Approved-At: Mon, 24 Oct 2011 20:24:55 -0700 Cc: mif@ietf.org, dnsop@ietf.org, dnsext@ietf.org, Doug Barton , pk@isoc.de, Alex Bligh , dhcwg@ietf.org, jhutz@cmu.edu Subject: Re: [mif] [dhcwg] [dnsext] [DNSOP] 2nd Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 22:50:47 -0000 On Mon, 2011-10-24 at 16:58 -0400, Keith Moore wrote: > On Oct 24, 2011, at 4:52 PM, Doug Barton wrote: > > > On 10/24/2011 05:16, Keith Moore wrote: > >> That's the point - search lists are not appropriate most of the time, and it's very hard for software to distinguish the cases where they are potentially appropriate from the cases when they're not, and it's not possible for software to do this in all cases. > > > > There's been something missing from this discussion, and I finally put > > my finger on it. TMK most stub resolvers have an option similar to this > > one from ISC's: > > > > ndots:n > > sets a threshold for the number of dots which > > must appear in a name given to res_query() (see > > resolver(3)) before an initial absolute query > > will be made. The default for n is “1â€, mean†> > ing that if there are any dots in a name, the > > name will be tried first as an absolute name > > before any search list elements are appended to > > it. > > > > So it seems that this question is already a matter of local policy, > > which given the number and quality of the divergent views seems > > eminently reasonable. Can we move on now? > > No, because relying on "local policy" is not sufficient for interoperability. For interoperability, one can use absolute names, with the trailing dot, or specify that in the context of whatever protocol, all names are to be taken as relative to the root, or use other than a printed representation. In some cases this may require that implementations use resolver interfaces which make it clear that a name to be resolved is absolute, or that they append the empty label to relative names before passing them on to the resolver. On the other hand, in user interface, which is primarily where relative names are intended to be used, local policy is quite sufficient. As long as I and the software on my machine agree on what a name I type means, it's none of the IETF's business. Can an enterprise change the name of every domain name? On machines they control, yes. While I agree wholeheartedly with the notion of a unique domain name space, I also believe that mapping a relative or abbreviated name onto that namespace is _entirely_ a matter of local policy. It is perhaps appropriate for the IETF to provide mechanisms for distributing that policy, for those who wish to use them, but not to dictate what the policy must be. > I think there's a need for IETF to document why any other value than 1 > is a Bad Idea, and more to the point, why it will break things. It's not a Bad Idea, and it doesn't break things, or at least not so badly that the convenience isn't worth it. In this, I speak from years of operational experience, not only of personal use of also that of the many users of systems I operate support. Do things get worse as new TLDs appear? Yes, sometimes. Have we mostly had to abandon use of relative names ending in .cs and other two-letter suffixes? Yes, but we _mostly_ didn't use them anyway, due to our deep namespace and the appearance of those domains in our search list (here, "foo.bar" usually means "foo.bar.cs.cmu.edu"). Does that mean we're abandoning "options ndots:2"? Not aggressively. It has faded over time, but more due to a failure to actively apply it to newer systems than to any conscious decision that it's a problem. Further, given this position, I wonder why you think even a value of 1 is acceptable in the face of vanity TLDs. I know why I do, both from the perspective of an IETF (it's a local policy matter, period) and for myself (search for local names first, don't trust DNS results (yet) for security, and write absolute names when you want to bypass search lists). > The > problem isn't entirely specific to hosts with multiple interfaces. > But given that using multiple interfaces makes the problem worse, MIF > might want to take on some of the work of documenting why it will > break things. I can see how using an untrusted search list makes it worse. I can also see how using multiple sets of nameservers which provide different views of the namespace makes things worse, and I can see how using multiple interfaces makes this more likely. But, that has nothing to do with search lists and occurs even if every name is always treated as absolute. I can see two answers to this: 1) Use DNSSEC 2) Don't trust results from unsecured DNS for anything important. I fail to see how using multiple interfaces makes the problem worse, in itself. Can you elaborate? -- Jeff From jhutz@cmu.edu Mon Oct 24 17:05:08 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F16B621F8CC4; Mon, 24 Oct 2011 17:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.656 X-Spam-Level: X-Spam-Status: No, score=-106.656 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1dCJQgvUqE7Z; Mon, 24 Oct 2011 17:05:07 -0700 (PDT) Received: from smtp01.srv.cs.cmu.edu (SMTP01.SRV.CS.CMU.EDU [128.2.217.196]) by ietfa.amsl.com (Postfix) with ESMTP id EE16321F8CB8; Mon, 24 Oct 2011 17:05:06 -0700 (PDT) Received: from [66.233.146.161] (66-233-146-161.pit.clearwire-wmx.net [66.233.146.161] (may be forged)) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id p9P04sjx010043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Oct 2011 20:04:56 -0400 (EDT) From: Jeffrey Hutzelman To: Keith Moore In-Reply-To: References: <96472FB7-8425-4928-8F55-2ABF2CB59A93@conundrum.com> <628C128E-BDA8-46C3-BF07-364A482FE199@network-heretics.com> <20111024.080822.74700976.sthaug@nethelp.no> <59274CC1-611A-445B-A1CF-A0F49329DC1F@network-heretics.com> <4EA5D012.9090708@dougbarton.us> <28623_1319491641_p9OLRK2S028590_45E6700D-4207-4807-B8A4-2CFC56440038@network-heretics.com> <1319496624.28149.399.camel@destiny.pc.cs.cmu.edu> Content-Type: text/plain; charset="UTF-8" Date: Mon, 24 Oct 2011 20:04:52 -0400 Message-ID: <1319501092.28149.545.camel@destiny.pc.cs.cmu.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.196 X-Mailman-Approved-At: Mon, 24 Oct 2011 20:24:55 -0700 Cc: mif@ietf.org, dnsop@ietf.org, dnsext@ietf.org, Doug Barton , pk@isoc.de, Alex Bligh , dhcwg@ietf.org, jhutz@cmu.edu Subject: Re: [mif] [dhcwg] [dnsext] [DNSOP] 2nd Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 00:05:08 -0000 On Mon, 2011-10-24 at 19:30 -0400, Keith Moore wrote: > On Oct 24, 2011, at 6:50 PM, Jeffrey Hutzelman wrote: > > >>> So it seems that this question is already a matter of local policy, > >>> which given the number and quality of the divergent views seems > >>> eminently reasonable. Can we move on now? > >> > >> No, because relying on "local policy" is not sufficient for interoperability. > > > > For interoperability, one can use absolute names, with the trailing dot, > > uh, no. Names with trailing dots aren't allowed in many contexts. > And in some of the contexts in which they are allowed, they get > "canonicalized" to names without trailing dots. Yup; that's a problem. And I agree that changing it may not be the most practical solution to the problem. > > > or specify that in the context of whatever protocol, all names are to be > > taken as relative to the root, or use other than a printed > > representation. > > ...so a DNS name means different things in one context than in another. Bad Idea. Hm? Not at all. Really, only unambiguous names ought to ever appear on the wire. One way for a protocol to do that is too use absolute names exclusively; another is to use "relative" names which are always relative to the root; this is the same as using absolute names without the trailing dot. Another is to use names relative to some unambiguous origin, as is done in DNS master files. The important thing is that a name always mean the same thing, not that it be represented the same way in all protocols. > > In some cases this may require that implementations use > > resolver interfaces which make it clear that a name to be resolved is > > absolute, or that they append the empty label to relative names before > > passing them on to the resolver. > > > > On the other hand, in user interface, which is primarily where relative > > names are intended to be used, local policy is quite sufficient. > > no. Domain names are written on buses, billboards, business cards. > They do get transcribed, quite often actually, and they need to have > the same meanings when typed in as they do when clicked on. Yup, that's a problem, too, in many ways. Of course, such names should always be fully-qualified; you can't expect useful results if you use a relative name on the side of a bus. Or at least, you can't unless you really meant an absolute name but left off the trailing dot, which is what everyone will think you meant anyway. > Some people are working way too hard to try to save something that was > never a good idea in the first place. > > I'm not arguing that all software that currently applies searching to > names with dots in them has to die a violent death, and immediately > either be updated or deleted from all computers everywhere (as > if...). I'm just saying that IETF should recommend against the > practice of using search lists with multi-label names, and document > the harm that it does. Sites can still do it if they want to, or they > can manage their own transitions away from using search paths for such > names, on their own timeframes. After all, this has been a practice > for ~30 years in some places, nobody should expect it all to change > overnight. Right. That's what local policy _is_. Of course it's reasonable for the IETF to recommend default policy, and describe some of the pitfalls associated with other possible policies. And I certainly agree that ndots:1 is a reasonable default policy that will work for most people while causing few problems. Which makes it convenient that it's what most vendors already do today. > > While I agree wholeheartedly with the notion of a unique domain name > > space, I also believe that mapping a relative or abbreviated name onto > > that namespace is _entirely_ a matter of local policy. > > That's a convenient philosophy if you _only_ care that local things > interoperate with one another. I only care that abbreviated names work for local things. For non-local things, I find it acceptable that fully-qualified names must be used to obtain interoperability. > > Further, given this position, I wonder why you think even a value of 1 > > is acceptable in the face of vanity TLDs. > Because (a) local names are essential, (b) the ability to distinguish > local names from FQDNs is also essential, and (c) use of a > single-label name as a local name (meaning, a name subject to local > interpretation) is a very widespread and well-entrenched practice. > Sites that associate address (or MX) records with vanity TLDs will > lose, and they deserve to lose. OK; on these points we agree. Note, however, that to me "local interpretation" means as defined by me and whoever else is involved in setting policy for me, and _not_ as defined by the coffee shop I happen to be sitting in. IMHO, local names are useless if I cannot depend on their meaning. Ideally, it would be desirable to have an interoperable way to have multi-label local names. When "local" gets to be large, a flat namespace becomes unwieldy, but abbreviation is still highly desirable. Why should I have to type more to talk to a relatively nearby machine that is part of my organization than to talk to a total stranger? But, since such a thing is basically impossible, I am satisfied with the idea that, as a matter of local policy, I can decide that some things that would otherwise be treated as fully-qualified are instead treated as local names. Other people shouldn't get to decide that for me without my permission, of course. > > I know why I do, both from > > the perspective of an IETF (it's a local policy matter, period) and for > > myself (search for local names first, don't trust DNS results (yet) for > > security, and write absolute names when you want to bypass search > > lists). > > The way you write an absolute name is to include a '.' in it. Well, yes. -- Jeff From jhutz@cmu.edu Mon Oct 24 17:31:39 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0D9511E811A; Mon, 24 Oct 2011 17:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.349 X-Spam-Level: X-Spam-Status: No, score=-106.349 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zOcHNyVP3ERV; Mon, 24 Oct 2011 17:31:39 -0700 (PDT) Received: from smtp01.srv.cs.cmu.edu (SMTP01.SRV.CS.CMU.EDU [128.2.217.196]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8BC11E80DB; Mon, 24 Oct 2011 17:31:39 -0700 (PDT) Received: from [66.233.146.161] (66-233-146-161.pit.clearwire-wmx.net [66.233.146.161] (may be forged)) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id p9P0VWE5010357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Oct 2011 20:31:33 -0400 (EDT) From: Jeffrey Hutzelman To: Doug Barton In-Reply-To: <23284_1319373366_p9NCa52k028390_4EA30EB0.6080605@dougbarton.us> References: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> <121DABD1-65E8-4275-8471-9FA38D25C434@nominet.org.uk> <916CE6CF87173740BC8A2CE44309696203783EE0@008-AM1MPN1-037.mgdnok.nokia.com> <4EA09791.8010705@gmail.com> <94C2E518-F34F-49E4-B15C-2CCCFAA96667@virtualized.org> <12477381-9F74-4C50-B576-47EE4322F6BC@network-heretics.com> <916CE6CF87173740BC8A2CE44309696203784B27@008-AM1MPN1-037.mgdnok.nokia.com> <708F3212-3C9C-4B61-AA77-EFA8F1CA5B04@nominum.com> <30B1AE01-0A35-48D2-91AF-46FC8B60466C@network-heretics.com> <23284_1319373366_p9NCa52k028390_4EA30EB0.6080605@dougbarton.us> Content-Type: text/plain; charset="UTF-8" Date: Mon, 24 Oct 2011 20:30:53 -0400 Message-ID: <1319502653.28149.572.camel@destiny.pc.cs.cmu.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.196 X-Mailman-Approved-At: Mon, 24 Oct 2011 20:24:55 -0700 Cc: "" , Keith Moore , "" , "" , "" , "" , "" , jhutz@cmu.edu Subject: Re: [mif] [dhcwg] [dnsext] [DNSOP] 2nd Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 00:31:40 -0000 On Sat, 2011-10-22 at 11:42 -0700, Doug Barton wrote: > In regards to 3, let's say I have a domain, example.org. In my network I > have various subdomains that represent various network segments, let's > say foo, bar, and baz. Personally, I find it convenient to put > 'example.com' in the search list for all of my hosts, and then type 'ssh > host.bar' and go off on my merry way. Yes, I understand that in my > simple example I could theoretically put all 3 subdomains in the search > list. Now assume that my network isn't actually that simple ... For example, suppose that each of foo, bar, and baz in turn has a number of subdomains, and that the total number of such 4th-level domains is over 250. Now, imagine that major resolver implementations limit the search list to a total of 6 domains... From Ted.Lemon@nominum.com Tue Oct 25 10:20:41 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEEB611E8083; Tue, 25 Oct 2011 10:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.557 X-Spam-Level: X-Spam-Status: No, score=-106.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RHv9ZsOe5DYm; Tue, 25 Oct 2011 10:20:40 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id 0DFED21F8C14; Tue, 25 Oct 2011 10:20:39 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP; Tue, 25 Oct 2011 10:20:40 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 6AC1E1B8225; Tue, 25 Oct 2011 10:20:38 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 56E2C190061; Tue, 25 Oct 2011 10:20:37 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.01.0323.003; Tue, 25 Oct 2011 10:20:37 -0700 From: Ted Lemon To: Doug Barton Thread-Topic: [dnsext] [DNSOP] [mif] 2nd Last Call for MIF DNS server selection document Thread-Index: AQHMkpQpQamRm2eD6Eax/sfGruR2mJWNT6kN Date: Tue, 25 Oct 2011 17:20:37 +0000 Message-ID: References: <96472FB7-8425-4928-8F55-2ABF2CB59A93@conundrum.com> <628C128E-BDA8-46C3-BF07-364A482FE199@network-heretics.com> <20111024.080822.74700976.sthaug@nethelp.no> <59274CC1-611A-445B-A1CF-A0F49329DC1F@network-heretics.com> <4EA5D012.9090708@dougbarton.us> <45E6700D-4207-4807-B8A4-2CFC56440038@network-heretics.com>, <4EA5D8C1.9060303@dougbarton.us> In-Reply-To: <4EA5D8C1.9060303@dougbarton.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pk@isoc.de" , "dnsop@ietf.org" , "mif@ietf.org" , "dnsext@ietf.org" , "dhcwg@ietf.org" Subject: Re: [mif] [dnsext] [DNSOP] 2nd Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 17:20:41 -0000 On Oct 24, 2011, at 5:30 PM, "Doug Barton" wrote: >> I think there's a need for IETF to document why any other value than 1 i= s a Bad Idea, and more to the point, why it will break things. The probl= em isn't entirely specific to hosts with multiple interfaces. But given th= at using multiple interfaces makes the problem worse, MIF might want to tak= e on some of the work of documenting why it will break things. >=20 > That seems to be an opinion of yours that isn't widely shared. The fact that many of us are tired of this interminable rathole and want it= to stop is not an indication that we agree with you, Doug. Consensus is no= t, or at least should not be, determined by counting the number of email me= ssages for and against. = From dougb@dougbarton.us Tue Oct 25 11:33:36 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1155021F8C35 for ; Tue, 25 Oct 2011 11:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.296 X-Spam-Level: X-Spam-Status: No, score=-3.296 tagged_above=-999 required=5 tests=[AWL=0.303, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7m8XbQM9PQSX for ; Tue, 25 Oct 2011 11:33:35 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id 0771721F8C30 for ; Tue, 25 Oct 2011 11:33:34 -0700 (PDT) Received: (qmail 10757 invoked by uid 399); 25 Oct 2011 18:33:26 -0000 Received: from unknown (HELO 172-17-198-245.globalsuite.net) (dougb@dougbarton.us@12.207.105.210) by mail2.fluidhosting.com with ESMTPAM; 25 Oct 2011 18:33:26 -0000 X-Originating-IP: 12.207.105.210 X-Sender: dougb@dougbarton.us Message-ID: <4EA700F4.5050003@dougbarton.us> Date: Tue, 25 Oct 2011 11:33:24 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111001 Thunderbird/7.0.1 MIME-Version: 1.0 To: Ted Lemon References: <96472FB7-8425-4928-8F55-2ABF2CB59A93@conundrum.com> <628C128E-BDA8-46C3-BF07-364A482FE199@network-heretics.com> <20111024.080822.74700976.sthaug@nethelp.no> <59274CC1-611A-445B-A1CF-A0F49329DC1F@network-heretics.com> <4EA5D012.9090708@dougbarton.us> <45E6700D-4207-4807-B8A4-2CFC56440038@network-heretics.com>, <4EA5D8C1.9060303@dougbarton.us> In-Reply-To: X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "pk@isoc.de" , "dnsop@ietf.org" , "mif@ietf.org" , "dnsext@ietf.org" , "dhcwg@ietf.org" Subject: Re: [mif] [dnsext] [DNSOP] 2nd Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 18:33:36 -0000 On 10/25/2011 10:20, Ted Lemon wrote: > > > On Oct 24, 2011, at 5:30 PM, "Doug Barton" > wrote: > >>> I think there's a need for IETF to document why any other value >>> than 1 is a Bad Idea, and more to the point, why it will break >>> things. The problem isn't entirely specific to hosts with >>> multiple interfaces. But given that using multiple interfaces >>> makes the problem worse, MIF might want to take on some of the >>> work of documenting why it will break things. >> >> That seems to be an opinion of yours that isn't widely shared. > > The fact that many of us are tired of this interminable rathole and > want it to stop is not an indication that we agree with you, Doug. > Consensus is not, or at least should not be, determined by counting > the number of email messages for and against. Thank $DEITY that's true, or Keith would "win" every "vote." :) -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From internet-drafts@ietf.org Tue Oct 25 23:54:56 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4DD321F8B26; Tue, 25 Oct 2011 23:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xqjtVrnRbn1e; Tue, 25 Oct 2011 23:54:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BCF821F8663; Tue, 25 Oct 2011 23:54:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.61 Message-ID: <20111026065456.26567.87369.idtracker@ietfa.amsl.com> Date: Tue, 25 Oct 2011 23:54:56 -0700 Cc: mif@ietf.org Subject: [mif] I-D Action: draft-ietf-mif-dns-server-selection-07.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 06:54:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiple Interfaces Working Group of = the IETF. Title : Improved DNS Server Selection for Multi-Interfaced Nodes Author(s) : Teemu Savolainen Jun-ya Kato Ted Lemon Filename : draft-ietf-mif-dns-server-selection-07.txt Pages : 26 Date : 2011-10-25 A multi-interfaced node is connected to multiple networks, some of which may be utilizing private DNS namespaces. A node commonly receives DNS server configuration information from all connected networks. Some of the DNS servers may have information about namespaces other servers do not have. When a multi-interfaced node needs to utilize DNS, the node has to choose which of the servers to contact to. This document describes DHCPv4 and DHCPv6 options that can be used to configure nodes with information required to perform informed DNS server selection decisions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mif-dns-server-selection-07.= txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mif-dns-server-selection-07.t= xt From teemu.savolainen@nokia.com Wed Oct 26 00:01:28 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E694621F84AF; Wed, 26 Oct 2011 00:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.482 X-Spam-Level: X-Spam-Status: No, score=-0.482 tagged_above=-999 required=5 tests=[AWL=-2.087, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zdeipHsh++P; Wed, 26 Oct 2011 00:01:26 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 2003521F8484; Wed, 26 Oct 2011 00:01:19 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p9Q71CPd024271; Wed, 26 Oct 2011 10:01:18 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 26 Oct 2011 10:00:51 +0300 Received: from 008-AM1MMR1-007.mgdnok.nokia.com (65.54.30.23) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 26 Oct 2011 09:00:47 +0200 Received: from 008-AM1MPN1-037.mgdnok.nokia.com ([169.254.7.8]) by 008-AM1MMR1-007.mgdnok.nokia.com ([65.54.30.23]) with mapi id 14.01.0339.002; Wed, 26 Oct 2011 09:00:46 +0200 From: To: , , , Thread-Topic: New rev of MIF DNS server selection document Thread-Index: AcyTq3sQ9JbsYFTkR5yAi3kg51bouw== Date: Wed, 26 Oct 2011 07:00:46 +0000 Message-ID: <916CE6CF87173740BC8A2CE44309696203787DCE@008-AM1MPN1-037.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Company Confidential;Project=None; x-titus-version: 3.3.8.1 x-headerinfofordlp: None x-tituslabs-classificationhash-30: 0Ywc1/TmJmZP14okFmB8GOGuG+9CndY/chBUg2sNqfclVQc560ay4nTVu+Pyk2IAuFttQ0hJIgNZv0C/nLXvVl6FFyrPFpbSBOJjV37tYwuNoeTkhogx7FiT8UlHtNh3raK/yv2tgY3MgXDEMDyjWF7v2fpwqE5b1AYchEkJFQCkQUWl7EB+ZbJkdpe0Azkr2V/cOFBVnD04GNJZ4cF4iaQZsj+MbhDweV76wYxTT/s6Sm6Cel+NQRlCDM/kxxA4 x-originating-ip: [10.162.56.71] Content-Type: multipart/alternative; boundary="_000_916CE6CF87173740BC8A2CE44309696203787DCE008AM1MPN1037mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 26 Oct 2011 07:00:51.0909 (UTC) FILETIME=[FF9DC750:01CC93AC] X-Nokia-AV: Clean Subject: [mif] New rev of MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 07:01:28 -0000 --_000_916CE6CF87173740BC8A2CE44309696203787DCE008AM1MPN1037mg_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQoNCg0KVGhhbmsgeW91IGZvciBhbGwgdGhlIGRpc2N1c3Npb25zLg0KDQoNCg0K SSBoYXZlIHN1Ym1pdHRlZCAtMDcgdmVyc2lvbiB3aXRoIHRoZSBmb2xsb3dpbmcgY2hhbmdlczoN Cg0KLSAgICAgICAgICBDb21wbGV0ZSByZW1vdmFsIG9mIHNlY3Rpb24gNC42IGFib3V0IEROUyBz ZWFyY2ggbGlzdCBvcHRpb24gaGFuZGxpbmcuIFRoaXMgdG9waWMgY2xlYXJseSBpcyBzb21ldGhp bmcgdGhhdCBpcyB0b28gYmlnIGZvciB0aGlzIGRyYWZ0IHRvIGNvdmVyIGFuZCBhbHNvIHNlZW1z IHRvIGJlIG1vc3RseSBvdXQgb2YgdGhlIHNjb3BlIG9mIHRoaXMgZHJhZnQuIElmIHRoZXJlIHNv bWUgZGF5IHdpbGwgYmUgYSBuZXcgZHJhZnQgdGhhdCBhZGRyZXNzZXMgdmFyaW91cyBpc3N1ZXMg d2l0aCBETlMgc2VhcmNoIGxpc3RzLCBpdCBtaWdodCBhbHNvIGRpc2N1c3MgdGhlIGlzc3VlcyBy ZWxhdGVkIHRvIE1JRg0KDQotICAgICAgICAgIFNlY3VyaXR5IGFkZGl0aW9ucywgbmFtZWx5IHRo ZSBmb2xsb3dpbmcgdHdvIGFkZGl0aW9uczoNCg0KbyAgIKGwSW4gc29tZSBvY2Nhc2lvbnMgYW4g aW50ZXJmYWNlIG1heSBiZSBjb25zaWRlcmVkIHRydXN0ZWQgb25seSBpZiBleHBsaWNpdGx5IGNv bmZpZ3VyZWQgdG8gYmUgdHJ1c3RlZC6hsQ0KDQpvICAgobBBbiBpbXBsZW1lbnRhdGlvbiBtYXkg bm90IGJlIGFibGUgdG8gZGV0ZXJtaW5lIHRydXN0IGxldmVscyB3aXRob3V0IGV4cGxpY2l0IGNv bmZpZ3VyYXRpb24gcHJvdmlkZWQgYnkgdXNlciBvciBhZG1pbmlzdHJhdG9yLiAgVGhlcmVmb3Jl LCBmb3IgZXhhbXBsZSwgYW4gaW1wbGVtZW50YXRpb24gbWF5IG5vdCBieSBkZWZhdWx0IHRydXN0 IGNvbmZpZ3VyYXRpb24gcmVjZWl2ZWQgZXZlbiBvdmVyIFZQTiBpbnRlcmZhY2VzLqGxDQoNCi0g ICAgICAgICAgREhDUHY0IG9wdGlvbiBzdHJ1Y3R1cmUgY2xhcmlmaWNhdGlvbjoNCg0KbyAgIFBv c3NpYmlsaXR5IHRvIGhhdmUgbXVsdGlwbGUgb3B0aW9ucyB0aGF0IGFyZSBjb25jYXRlbmF0ZWQg YXMgZGVzY3JpYmVkIGluIFJGQzMzOTYNCg0KbyAgIFJlbW92YWwgb2YgobBwYXlsb2FkIGxlbqGx IGZpZWxkDQoNCg0KDQpJIG5vdyB0aGluayB0aGF0IGFmdGVyIHRoZXNlIGltcHJvdmVtZW50cyB0 aGlzIGlzIGV2ZW4gbW9yZSByZWFkeSB0byBnbyB0b3dhcmRzIElFU0dKDQoNCg0KDQpJLUQgaXRz ZWxmOiBodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWlldGYtbWlmLWRucy1zZXJ2ZXItc2Vs ZWN0aW9uLTA3LnR4dA0KDQoNCg0KRGlmZiB0byAtMDY6ICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcv cmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtbWlmLWRucy1zZXJ2ZXItc2VsZWN0aW9uLTA3DQoNCg0K DQpCZXN0IHJlZ2FyZHMsDQoNCg0KDQogICAgICAgICAgICAgICAgVGVlbXUNCg0KDQoNCkZyb206 IGRoY3dnLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpkaGN3Zy1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgU2F2b2xhaW5lbiBUZWVtdSAoTm9raWEtQ1RPL1RhbXBlcmUpDQpTZW50OiAx OS4gbG9rYWt1dXRhIDIwMTEgMDk6NDMNClRvOiBkZW5naHVpMDJAaG90bWFpbC5jb207IG1pZkBp ZXRmLm9yZzsgZG5zZXh0QGlldGYub3JnOyBkbnNvcEBpZXRmLm9yZzsgZGhjd2dAaWV0Zi5vcmcN CkNjOiBzYS5tb3JyaXM3QGdvb2dsZW1haWwuY29tOyBwa0Bpc29jLmRlDQpTdWJqZWN0OiBSZTog W2RoY3dnXSBbbWlmXSAybmQgTGFzdCBDYWxsIGZvciBNSUYgRE5TIHNlcnZlciBzZWxlY3Rpb24g ZG9jdW1lbnQNCg0KDQoNCkhpIGFsbCwNCg0KDQoNClRoaXMgc2Vjb25kIFdHTEMgcmVzdWx0ZWQg aW4gdmVyeSBmZXcgY29tbWVudHMuIEluIHRoZSBESEMgV0cgd2UgZGlzY3Vzc2VkIGFib3V0IERI Q1B2NCBvcHRpb24gc3RydWN0dXJlIGFuZCBpbiBNSUYgdGhlcmUgd2FzIGEgY29tbWVudCBhYm91 dCBkb2N1bWVudC1pbnRlcm5hbCByZWZlcmVuY2UgYnVnLg0KDQoNCg0KSSBoYXZlIG5vdyB1cGxv YWRlZCBhIHZlcnNpb24gc2l4IHRoYXQgY29udGFpbnM6DQoNCi0gICAgICAgICAgRml4ZXMgdG8g dGhlIERIQ1B2NCBvcHRpb24gc3RydWN0dXJlDQoNCi0gICAgICAgICAgSGlnaGxpZ2h0aW5nIHN0 cmljdGVyIGxlbmd0aCBsaW1pdGF0aW9uIGluIGNhc2Ugb2YgREhDUHY0IG9wdGlvbg0KDQotICAg ICAgICAgIEZpeCB0byB0aGUgcmVmZXJlbmNlIGJ1Zw0KDQotICAgICAgICAgIFNtYWxsIGZpeGVz IHRvIG1pc3NpbmcgREhDUHY0IGNvbnNpZGVyYXRpb25zIGluIHNlY3Rpb25zIDQuNSBhbmQgNC42 Lg0KDQoNCg0KUGxlYXNlIHNlZSBkaWZmOiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj91 cmwyPWRyYWZ0LWlldGYtbWlmLWRucy1zZXJ2ZXItc2VsZWN0aW9uLTA2DQoNCg0KDQpJZiBubyBm dXJ0aGVyIGNvbW1lbnRzLCBJIHRoaW5rIHRoaXMgZG9jdW1lbnQgaXMgcmVhZHkgdG8gZ28gdG8g dGhlIElFU0cuDQoNCg0KDQpUaGFuayB5b3UsDQoNCg0KDQogICAgICAgICAgICAgICAgVGVlbXUN Cg0KDQoNCg0KDQpGcm9tOiBtaWYtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bWlmLWJvdW5jZXNA aWV0Zi5vcmc+IFttYWlsdG86bWlmLWJvdW5jZXNAaWV0Zi5vcmddPG1haWx0bzpbbWFpbHRvOm1p Zi1ib3VuY2VzQGlldGYub3JnXT4gT24gQmVoYWxmIE9mIGV4dCBIdWkgRGVuZw0KU2VudDogMzAu IHN5eXNrdXV0YSAyMDExIDE4OjI5DQpUbzogbWlmQGlldGYub3JnPG1haWx0bzptaWZAaWV0Zi5v cmc+OyBkbnNleHRAaWV0Zi5vcmc8bWFpbHRvOmRuc2V4dEBpZXRmLm9yZz47IGRuc29wQGlldGYu b3JnPG1haWx0bzpkbnNvcEBpZXRmLm9yZz47IGRoY3dnQGlldGYub3JnPG1haWx0bzpkaGN3Z0Bp ZXRmLm9yZz4NCkNjOiBwa0Bpc29jLmRlPG1haWx0bzpwa0Bpc29jLmRlPjsgam9obl9icnpvem93 c2tpQGNhYmxlLmNvbWNhc3QuY29tPG1haWx0bzpqb2huX2Jyem96b3dza2lAY2FibGUuY29tY2Fz dC5jb20+OyBzYS5tb3JyaXM3QGdvb2dsZW1haWwuY29tPG1haWx0bzpzYS5tb3JyaXM3QGdvb2ds ZW1haWwuY29tPg0KU3ViamVjdDogW21pZl0gMm5kIExhc3QgQ2FsbCBmb3IgTUlGIEROUyBzZXJ2 ZXIgc2VsZWN0aW9uIGRvY3VtZW50DQoNCg0KDQpEZWFyIGFsbA0KDQpCYXNlZCBvbiAxc3Qgcm91 bmQgV0cgTEMsIHRoZSBhdXRob3JzIGhhdmUgcmVjZWl2ZWQgc2lnbmlmaWNhbnQgYWR2aWNlIGFi b3V0IHJldmlzaW9uIGFuZCBzdWJtaXRlZCBhIG5ldyB2ZXJzaW9uIGFjY29yZGluZ2x5Og0KaHR0 cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1taWYtZG5zLXNlcnZl ci1zZWxlY3Rpb24tMDUudHh0DQoNCkFuZCB3ZSBwbGFuIHRvIGlzc3VlIGEgc2Vjb25kIHJvdW5k IFdHIExDLCBhbmQgY2MgdG8gREhDV0csIEROU0VYVCwgRE5TT1AgcmVsYXRlZCB3b3JraW5nIGdy b3VwcywgcGxlYXNlIEROU0VYVC9ETlNPUCBjaGFpcnMgaGVscCB0byBmb3J3YXJkIHRvIHRoZSBN THMgc2luY2UgSSBtYXkgbm90IHN1YnNjcmliZSB0byB0aGVtLg0KDQpUaGlzIGlzIGEgMiB3ZWVr cyB3aXRoIGxpdHRsZSBleHRlbnNpb24gTEMsIGl0IHdpbGwgZmluaXNoIG9uIE9jdG9iZXIgMTcs DQpQbGVhc2Ugc2VuZCBzdWJzdGFudGl2ZSByZXZpZXcgYW5kIGVkaXRvcmlhbCBjb21tZW50cyB0 byBtaWZAaWV0Zi5vcmc8bWFpbHRvOm1pZkBpZXRmLm9yZz4NCg0KVGhhbmtzIGEgbG90IGZvciB5 b3VyZSB2aWV3DQpCZXN0IHJlZ2FyZHMsDQoNCk1hcmdhcmV0IGFuZCBIdWkNCg0KDQoNCkJlbG93 IGFyZSBUZWVtdSdzIHdyaXRldXAgYWJvdXQgdGhlIHJldmlzaW9uOg0KDQpJIHVwbG9hZGVkIC0w NSB1cGRhdGUgc28gdGhhdCBuZXh0IGNvbW1lbnRzIHdvdWxkIHRha2UgaW50byBhY2NvdW50IGNo YW5nZXMNCkkgYWxyZWFkeSBkaWQgYmFzZWQgb24gZGlzY3Vzc2lvbnMgd2l0aCBNdXJyYXkgKGFz IHdhcyBjb3BpZWQgdG8gdGhpcyBsaXN0KS4NClRoZSBiaWdnZXN0IGNsYXJpZmljYXRpb25zIHJl bGF0ZWQgdG8gaG93IEROUyBxdWVyaWVzIGFyZSBzZW50IHRvIGRpZmZlcmVudA0Kc2VydmVycyBh bmQgd2hlbiBhbGwgc2VydmVycyBhcmUgd2FpdGVkIGZvciBhbnN3ZXJzIChpZiByZXBseSBpcyBu b3QNCnZhbGlkYXRlZCkgYW5kIHdoZW4gbm90LiBJLmUuIHRoaXMgdGV4dDoNCi0tDQogIEEgbm9k ZSBTSEFMTCBzZW5kIHJlcXVlc3RzIHRvIEROUyBzZXJ2ZXJzIGluIHRoZSBvcmRlciBkZWZpbmVk IGJ5IHRoZQ0KICBwcmlvcml0eSBsaXN0IHVudGlsIGFuIGFjY2VwdGFibGUgcmVwbHkgaXMgcmVj ZWl2ZWQsIGFsbCByZXBsaWVzIGFyZQ0KICByZWNlaXZlZCwgb3IgYSB0aW1lIG91dCBvY2N1cnMu ICBJbiB0aGUgY2FzZSBvZiBhIHJlcXVlc3RlZCBuYW1lDQogIG1hdGNoaW5nIHRvIGEgc3BlY2lm aWMgZG9tYWluIG9yIG5ldHdvcmsgcnVsZSBhY2NlcHRlZCBmcm9tIGFueQ0KICBpbnRlcmZhY2Us IGEgRE5TU0VDLWF3YXJlIHJlc29sdmVyIE1VU1QgTk9UIHByb2NlZWQgd2l0aCBhIHJlcGx5IHRo YXQNCiAgY2Fubm90IGJlIHZhbGlkYXRlZCB1c2luZyBETlNTRUMgdW50aWwgYWxsIEROUyBzZXJ2 ZXJzIG9uIHRoZQ0KICBwcmlvcml0eSBsaXN0IGhhdmUgYmVlbiBjb250YWN0ZWQgb3IgdGltZWQg b3V0LiAgVGhpcyBwcm90ZWN0cw0KICBhZ2FpbnN0IHBvc3NpYmxlIHJlZGlyZWN0aW9uIGF0dGFj a3MuICBJbiB0aGUgY2FzZSBvZiB0aGUgcmVxdWVzdGVkDQogIG5hbWUgbm90IG1hdGNoaW5nIHRv IGFueSBzcGVjaWZpYyBkb21haW4gb3IgbmV0d29yaywgZmlyc3QgcmVjZWl2ZWQNCiAgcmVzcG9u c2UgZnJvbSBhbnkgRE5TIHNlcnZlciBNQVkgYmUgY29uc2lkZXJlZCBhY2NlcHRhYmxlLiAgQSBE TlNTRUMtDQogIGF3YXJlIG5vZGUgTUFZIGFsd2F5cyBjb250YWN0IGFsbCBETlMgc2VydmVyIGlu IGFuIGF0dGVtcHQgdG8gcmVjZWl2ZQ0KICBhIHJlc3BvbnNlIHRoYXQgY2FuIGJlIHZhbGlkYXRl ZCwgYnV0IGNvbnRhY3RpbmcgYWxsIEROUyBzZXJ2ZXJzIGlzDQogIG5vdCBtYW5kYXRlZCBmb3Ig dGhlIGRlZmF1bHQgY2FzZSBhcyBpbiBzb21lIGRlcGxveW1lbnRzIHRoYXQgd291bGQNCiAgY29u c3VtZSBleGNlc3MgcmVzb3VyY2VzLg0KLS0NCiAgICAgICBUZWVtdQ0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBtaWYtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bWlmLWJv dW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86bWlmLWJvdW5jZXNAaWV0Zi5vcmddPG1haWx0bzpbbWFp bHRvOm1pZi1ib3VuY2VzQGlldGYub3JnXT4gT24gQmVoYWxmIE9mDQo+IGV4dCBpbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NCj4gU2VudDog MjAuIHN5eXNrdXV0YSAyMDExIDIyOjEwDQo+IFRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmc8bWFp bHRvOmktZC1hbm5vdW5jZUBpZXRmLm9yZz4NCj4gQ2M6IG1pZkBpZXRmLm9yZzxtYWlsdG86bWlm QGlldGYub3JnPg0KPiBTdWJqZWN0OiBbbWlmXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLW1pZi1k bnMtc2VydmVyLXNlbGVjdGlvbi0wNS50eHQNCi0gz9TKvtL908POxNfWIC0NCj4NCj4gQSBOZXcg SW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJh ZnRzDQpkaXJlY3Rvcmllcy4NCj4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgTXVs dGlwbGUgSW50ZXJmYWNlcyBXb3JraW5nIEdyb3VwIG9mIHRoZQ0KPiBJRVRGLg0KPg0KPiAgICAg ICBUaXRsZSAgICAgICAgICAgOiBJbXByb3ZlZCBETlMgU2VydmVyIFNlbGVjdGlvbiBmb3IgTXVs dGktSW50ZXJmYWNlZA0KPiBOb2Rlcw0KPiAgICAgICBBdXRob3IocykgICAgICAgOiBUZWVtdSBT YXZvbGFpbmVuDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgSnVuLXlhIEthdG8NCj4gICAg ICAgICAgICAgICAgICAgICAgICAgICBUZWQgTGVtb24NCj4gICAgICAgRmlsZW5hbWUgICAgICAg IDogZHJhZnQtaWV0Zi1taWYtZG5zLXNlcnZlci1zZWxlY3Rpb24tMCA1LnR4dA0KPiAgICAgICBQ YWdlcyAgICAgICAgICAgOiAyNg0KPiAgICAgICBEYXRlICAgICAgICAgICAgOiAyMDExLTA5LTIw DQo+DQo+ICAgIEEgbXVsdGktaW50ZXJmYWNlZCBub2RlIGlzIGNvbm5lY3RlZCB0byBtdWx0aXBs ZSBuZXR3b3Jrcywgc29tZSBvZg0KPiAgICB3aGljaCBtYXkgYmUgdXRpbGl6aW5nIHByaXZhdGUg RE5TIG5hbWVzcGFjZXMuICBBIG5vZGUgY29tbW9ubHkNCj4gICAgcmVjZWl2ZXMgRE5TIHNlcnZl ciBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9uIGZyb20gYWxsIGNvbm5lY3RlZA0KPiAgICBuZXR3 b3Jrcy4gIFNvbWUgb2YgdGhlIEROUyBzZXJ2ZXJzIG1heSBoYXZlIGluZm9ybWF0aW9uIGFib3V0 DQo+ICAgIG5hbWVzcGFjZXMgb3RoZXIgc2VydmVycyBkbyBub3QgaGF2ZS4gIFdoZW4gYSBtdWx0 aS1pbnRlcmZhY2VkIG5vZGUNCj4gICAgbmVlZHMgdG8gdXRpbGl6ZSBETlMsIHRoZSBub2RlIGhh cyB0byBjaG9vc2Ugd2hpY2ggb2YgdGhlIHNlcnZlcnMgdG8NCj4gICAgY29udGFjdCB0by4gIFRo aXMgZG9jdW1lbnQgZGVzY3JpYmVzIERIQ1B2NCBhbmQgREhDUHY2IG9wdGlvbiB0aGF0DQo+ICAg IGNhbiBiZSB1c2VkIHRvIGNvbmZpZ3VyZSBub2RlcyB3aXRoIGluZm9ybSBhdGlvbiByZXF1aXJl ZCB0byBwZXJmb3JtDQo+ICAgIGluZm9ybWVkIEROUyBzZXJ2ZXIgc2VsZWN0aW9uIGRlY2lzaW9u cy4NCj4NCj4NCj4gQSBVUkwgZm9yIHRoaXMgSW50ZXJuZXQtRHJhZnQgaXM6DQo+IGh0dHA6Ly93 d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtbWlmLWRucy1zZXJ2ZXItc2Vs ZWN0aW9uLTA1LnR4dA0KDQo= --_000_916CE6CF87173740BC8A2CE44309696203787DCE008AM1MPN1037mg_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi all,=

 <= /p>

Thank you for all the dis= cussions.

 <= /p>

I have submitted -07 vers= ion with the following changes:

- = ;         Complete removal = of section 4.6 about DNS search list option handling. This topic clearly is= something that is too big for this draft to cover and also seems to be mostly out of the scope of this draft. If there some day = will be a new draft that addresses various issues with DNS search lists, it= might also discuss the issues related to MIF

- = ;         Security addition= s, namely the following two additions:

o   =A1=B0In some occ= asions an interface may be considered trusted only if explicitly configured= to be trusted.=A1=B1

o   =A1=B0An implemen= tation may not be able to determine trust levels without explicit configura= tion provided by user or administrator.  Therefore, for example, an implementation may not by default trust configuration received even ove= r VPN interfaces.=A1=B1

- = ;         DHCPv4 option str= ucture clarification:

o   Possibility to ha= ve multiple options that are concatenated as described in RFC3396

o   Removal of =A1=B0= payload len=A1=B1 field

 <= /p>

I now think that after th= ese improvements this is even more ready to go towards IESGJ

 <= /p>

I-D itself: http://www.ie= tf.org/id/draft-ietf-mif-dns-server-selection-07.txt

 <= /p>

Diff to -06:  http:/= /tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-mif-dns-server-selection-07<= /o:p>

 <= /p>

Best regards,<= /span>

 <= /p>

    &= nbsp;           Teemu

 <= /p>

From: dhcwg-bo= unces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Savolainen Teemu (Nokia-CTO/Tampere)
Sent: 19. lokakuuta 2011 09:43
To: denghui02@hotmail.com; mif@ietf.org; dnsext@ietf.org; dnsop@ietf= .org; dhcwg@ietf.org
Cc: sa.morris7@googlemail.com; pk@isoc.de
Subject: Re: [dhcwg] [mif] 2nd Last Call for MIF DNS server selectio= n document

 

Hi all,=

 <= /p>

This second WGLC resulted= in very few comments. In the DHC WG we discussed about DHCPv4 option struc= ture and in MIF there was a comment about document-internal reference bug.

 <= /p>

I have now uploaded a ver= sion six that contains:

- = ;         Fixes to the DHCP= v4 option structure

- = ;         Highlighting stri= cter length limitation in case of DHCPv4 option

- = ;         Fix to the refere= nce bug

- = ;         Small fixes to mi= ssing DHCPv4 considerations in sections 4.5 and 4.6.

 <= /p>

Please see diff: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-mif-dns-server-selection-06=

 <= /p>

If no further comments, I= think this document is ready to go to the IESG.

 <= /p>

Thank you,

 <= /p>

    &= nbsp;           Teemu

 <= /p>

 <= /p>

From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of ext Hui Deng
Sent: 30. syyskuuta 2011 18:29
To: mif@ietf.org; dnsext@ietf.org; dnsop@ietf.org; = dhcwg@ietf.org
Cc: pk@isoc.de; john_brzozowski@cable.comcast.com; sa.morris7@googlemail.com
Subject: [mif] 2nd Last Call for MIF DNS server selection document

 

Dear all<= br>  
Based on 1st round WG LC, the authors have received significant advice abou= t revision and submited a new version accordingly:
http://www.ietf.org/internet-drafts/draft-ietf-mif-dns-serv= er-selection-05.txt
 
And we plan to issue a second round WG LC, and cc to DHCWG, DNSEXT, DN= SOP related working groups, please DNSEXT/DNSOP chairs help to forward to t= he MLs since I may not subscribe to them.
 
This is a 2 weeks with little extension LC, it will finish on Oct= ober 17,
Please send substantive review and editorial comments to mif@ietf.org
 
Thanks a lot for youre view
Best regards,
 
Margaret and Hui
 
 
 
Below are Teemu's writeup about the revision:
 
I uploaded -05 update so that next comments would take into account changes=
I already did based on discussions with Murray (as was copied to this list)= .
The biggest clarifications related to how DNS queries are sent to different=
servers and when all servers are waited for answers (if reply is not
validated) and when not. I.e. this text:
--
  A node SHALL send requests to DNS servers in the order defined by th= e
  priority list until an acceptable reply is received, all replies are=
  received, or a time out occurs.  In the case of a requested nam= e
  matching to a specific domain or network rule accepted from any
  interface, a DNSSEC-aware resolver MUST NOT proceed with a reply tha= t
  cannot be validated using DNSSEC until all DNS servers on the
  priority list have been contacted or timed out.  This protects<= br>   against possible redirection attacks.  In the case of the reque= sted
  name not matching to any specific domain or network, first received<= br>   response from any DNS server MAY be considered acceptable.  A D= NSSEC-
  aware node MAY always contact all DNS server in an attempt to receiv= e
  a response that can be validated, but contacting all DNS servers is<= br>   not mandated for the default case as in some deployments that would<= br>   consume excess resources.
--
       Teemu
> -----Original Message-----
> From: mif-bounces@ietf.org= [mailto:mif-bounces@ietf.org] On Behalf Of
> ext internet-drafts@ietf.o= rg
> Sent: 20. syyskuuta 2011 22:10
> To: i-d-announce@ietf.org=
> Cc: mif@ietf.org
> Subject: [mif] I-D Action: draft-ietf-mif-dns-server-selection-05.txt<= br> - =CF=D4=CA=BE=D2=FD= =D3=C3=CE=C4=D7=D6 -
>
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> This draft is a work item of the Multiple Interfaces Working Group of = the
> IETF.
>
>       Title     = ;      : Improved DNS Server Selection for Multi-I= nterfaced
> Nodes
>       Author(s)    &= nbsp;  : Teemu Savolainen
>            = ;            &n= bsp;  Jun-ya Kato
>            = ;            &n= bsp;  Ted Lemon
>       Filename    &n= bsp;   : draft-ietf-mif-dns-server-selection-0 5.txt
>       Pages     = ;      : 26
>       Date     =        : 2011-09-20
>
>    A multi-interfaced node is connected to multiple net= works, some of
>    which may be utilizing private DNS namespaces. = A node commonly
>    receives DNS server configuration information from a= ll connected
>    networks.  Some of the DNS servers may have inf= ormation about
>    namespaces other servers do not have.  When a m= ulti-interfaced node
>    needs to utilize DNS, the node has to choose which o= f the servers to
>    contact to.  This document describes DHCPv4 and= DHCPv6 option that
>    can be used to configure nodes with inform ation req= uired to perform
>    informed DNS server selection decisions.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-mif-dns-server-selection-05.= txt

--_000_916CE6CF87173740BC8A2CE44309696203787DCE008AM1MPN1037mg_-- From tomasz.mrugalski@gmail.com Thu Oct 27 05:18:02 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54D1321F858C for ; Thu, 27 Oct 2011 05:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xCH1TvNgFoOy for ; Thu, 27 Oct 2011 05:18:01 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6C88221F8541 for ; Thu, 27 Oct 2011 05:18:01 -0700 (PDT) Received: by wyh22 with SMTP id 22so3232225wyh.31 for ; Thu, 27 Oct 2011 05:17:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=xtCFd1EhoXs/yDEiwcueWftX5u+z56VHGaw6IooAp9U=; b=QIGMMbw/HGeDi4H6teAglM9pCDOAcKJXwi0r2PotaM6ZXHad6TzuIe7IxD+L2VBAlT f1PW7iUosSKohrVzaExdlmKZTsuF07nwz7wJSjprfQ2I8la+8+WiQPAqPiGiFBPbqzAk oCQ+tD0utoUZDzS2zIq64cBU5BInjZ3yObmjE= Received: by 10.227.206.211 with SMTP id fv19mr15512221wbb.27.1319717878874; Thu, 27 Oct 2011 05:17:58 -0700 (PDT) Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPS id fi11sm9038274wbb.9.2011.10.27.05.17.56 (version=SSLv3 cipher=OTHER); Thu, 27 Oct 2011 05:17:57 -0700 (PDT) Message-ID: <4EA94BF6.5020501@gmail.com> Date: Thu, 27 Oct 2011 14:17:58 +0200 From: Tomasz Mrugalski User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: mif@ietf.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: Margaret Wasserman , Hui Deng Subject: [mif] A request for Last Call on draft-ietf-mif-dhcpv6-route-option X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 12:18:02 -0000 Dear Chairs, Dear MIF, DHCPv6 Route Option draft has been presented in MIF several times. It was also presented in DHC WG and most* (see below) comments were addressed. I would also like to point out that this draft incorporates changes after Routing Directorate review, especially insightful comments from Joel Halpern about potential problems in networks that use dynamic routing. The lastest (-03) drafts contains clear warning that configuring routing over DHCPv6 in networks that use dynamic routing is a very bad idea (unless you exactly now what you are doing). * Authors chose to not incorporate some of the comments, raised by authors of dlro draft. There was a discussion in MIF list. Route option authors believe that: 1. defining separate option for just default route would be wrong. Let me qoute Ted Lemon (DHC chair): "It's always a bad idea to have two ways of specifying the same information—it creates a very clear potential for interoperability problems.". On a related note, I was involved in work on DS-Lite configuration over DHCPv6 and we initially had the same idea - define two options (address and FQDN) for the same thing. This approach was firmly rejected during IESG review. The message was clear: "choose one option". 2. conveying MAC (or link-layer in general) address is not necessary. There are other mechanisms like ND to obtain that information. Forcing this information on every client is just a waste of space as all clients that I know of can obtain this information on their own. They can do that in a timely manner, so raised argument about speed-up is not valid in my opinion. Another aspect is operational consideration. It would be very cumbersome to deploy and use. If operator changes interface in its router, DHCP configuration had to be updated and reconfigure procedure initiated. It could work in theory, but reconfigure is not commonly supported. DHCP server configuration would require knowledge of link-layer addresses of announced router(s). We could gain nothing by including MAC address, but get a lot of problems in the process. Therefore dhcpv6-route-option authors chose to not include link-layer information field. I would like to point out again that route-option proposal is extensible. It is designed as a minimal useful set of informations necessary for routing configuration. There are many more aspects of routing that may be useful in *some* cases. Therefore we made it clear that proposed options are extensible. If there are valid cases when extra information is useful, it should be defined as extension option. That's they recommendation I offer to anyone who says "can you add parameter X to route options? I really need it". To summarize this summary, we believe that mif-dhcpv6-route-option draft received enough reviews by experts in MIF, DHC and routing fields and is ready for WGLC. Therefore I'd like to ask MIF chairs to announce one. If we choose to have LC done in a timely fashion, we could discuss the results in Taipei. If that is the case, I would like to request time slot in Taipei meeting. I can't guess how many comments we will receive during WGLC, but I hope 10 or 15 minutes will be enough. Cheers, Tomek From alexandru.petrescu@gmail.com Thu Oct 27 05:23:55 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD89D21F8610 for ; Thu, 27 Oct 2011 05:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F2p+-Roc3Elh for ; Thu, 27 Oct 2011 05:23:55 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 8E98C21F85A4 for ; Thu, 27 Oct 2011 05:23:54 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id p9RCNpve004170 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 27 Oct 2011 14:23:51 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p9RCNopQ005947 for ; Thu, 27 Oct 2011 14:23:50 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p9RCNnOj025581 for ; Thu, 27 Oct 2011 14:23:50 +0200 Message-ID: <4EA94D55.1080605@gmail.com> Date: Thu, 27 Oct 2011 14:23:49 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: mif@ietf.org References: <4EA94BF6.5020501@gmail.com> In-Reply-To: <4EA94BF6.5020501@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mif] A request for Last Call on draft-ietf-mif-dhcpv6-route-option X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 12:23:55 -0000 Can you provide software for this? Please contact me off-list if yes. Alex Le 27/10/2011 14:17, Tomasz Mrugalski a écrit : > Dear Chairs, Dear MIF, > > DHCPv6 Route Option draft has been presented in MIF several times. It > was also presented in DHC WG and most* (see below) comments were addressed. > > I would also like to point out that this draft incorporates changes > after Routing Directorate review, especially insightful comments from > Joel Halpern about potential problems in networks that use dynamic > routing. The lastest (-03) drafts contains clear warning that > configuring routing over DHCPv6 in networks that use dynamic routing is > a very bad idea (unless you exactly now what you are doing). > > * Authors chose to not incorporate some of the comments, raised by > authors of dlro draft. There was a discussion in MIF list. Route option > authors believe that: > > 1. defining separate option for just default route would be wrong. Let > me qoute Ted Lemon (DHC chair): "It's always a bad idea to have two ways > of specifying the same information—it creates a very clear potential for > interoperability problems.". On a related note, I was involved in work > on DS-Lite configuration over DHCPv6 and we initially had the same idea > - define two options (address and FQDN) for the same thing. This > approach was firmly rejected during IESG review. The message was clear: > "choose one option". > > 2. conveying MAC (or link-layer in general) address is not necessary. > There are other mechanisms like ND to obtain that information. Forcing > this information on every client is just a waste of space as all clients > that I know of can obtain this information on their own. They can do > that in a timely manner, so raised argument about speed-up is not valid > in my opinion. Another aspect is operational consideration. It would be > very cumbersome to deploy and use. If operator changes interface in its > router, DHCP configuration had to be updated and reconfigure procedure > initiated. It could work in theory, but reconfigure is not commonly > supported. DHCP server configuration would require knowledge of > link-layer addresses of announced router(s). We could gain nothing by > including MAC address, but get a lot of problems in the process. > Therefore dhcpv6-route-option authors chose to not include link-layer > information field. > > I would like to point out again that route-option proposal is > extensible. It is designed as a minimal useful set of informations > necessary for routing configuration. There are many more aspects of > routing that may be useful in *some* cases. Therefore we made it clear > that proposed options are extensible. If there are valid cases when > extra information is useful, it should be defined as extension option. > That's they recommendation I offer to anyone who says "can you add > parameter X to route options? I really need it". > > To summarize this summary, we believe that mif-dhcpv6-route-option draft > received enough reviews by experts in MIF, DHC and routing fields and is > ready for WGLC. Therefore I'd like to ask MIF chairs to announce one. > > If we choose to have LC done in a timely fashion, we could discuss the > results in Taipei. If that is the case, I would like to request time > slot in Taipei meeting. I can't guess how many comments we will receive > during WGLC, but I hope 10 or 15 minutes will be enough. > > Cheers, > Tomek > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > From alexandru.petrescu@gmail.com Thu Oct 27 07:33:56 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D871121F88B7 for ; Thu, 27 Oct 2011 07:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.249 X-Spam-Level: X-Spam-Status: No, score=-7.249 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_INVITATION=-2, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KU-HLUUilHxN for ; Thu, 27 Oct 2011 07:33:55 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 3AAA521F8A4E for ; Thu, 27 Oct 2011 07:33:55 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id p9REXoHt026101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 27 Oct 2011 16:33:50 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p9REXn4K000839; Thu, 27 Oct 2011 16:33:49 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p9REXkpf021551; Thu, 27 Oct 2011 16:33:49 +0200 Message-ID: <4EA96BCA.204@gmail.com> Date: Thu, 27 Oct 2011 16:33:46 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Tomasz Mrugalski References: <4E88B6EF.9050800@gmail.com> <4EA93870.4020302@gmail.com> <4EA94CB3.5090606@gmail.com> <4EA9654D.2010506@gmail.com> In-Reply-To: <4EA9654D.2010506@gmail.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit Cc: mif , Margaret , maximouton@gmail.com, Hui Deng Subject: Re: [mif] I won't be in Taipei for MIF WG X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 14:33:57 -0000 [MIF list - this is ongoing private discussion about route-option vs drlo draft; much private discussion happened recently on this topic and I am now invited to publish this on the mailing list, so I do]. Tomasz, Thank you for the remarks. I am happy we have an opportunity to express so obviously the difference in our points of view. Let me try to reply. Le 27/10/2011 16:06, Tomasz Mrugalski a ¨¦crit : > On 27.10.2011 14:21, Alexandru Petrescu wrote: >> I do not oppose the time decided by Chairs to do WGLC for >> route-option. > I'm happy to learn that. Thank you. Sure and genuinely wishing good luck. >> Efficient (shorter messages) encoding is highly important for >> Machine-to-Machine communications which have stringent >> requirements in terms of bandwidth usage (the lower the better). > > That is a desired aspect of all protocols: choose shorter encoding if > it is feasible. However, our perception is that the most optimal > approach is not to include redundant information at all. Right, it is not good to include redundant information. Our method of encoding avoids redundancy as much as possible. At its best it only include the IPv6 address, and then if MAC is needed it is added without inserting new subtype numbers - it just follows one after the other. With your method - route option - if one needs to add MAC address then one needs to add some separator, like suboption number, if I'm not mistaken. > >>> I also ask for not postponing this process any further. There >>> are customers who are asking for this feature and we would like >>> to have it deployed sooner rather than later. >> >> Are your customers asking for the draft? Or for the >> implementation of the features described in the draft? > > I'll skip most of the rest of your post, because I find it > increasingly more inappropriate. Let me point out several things that > I consider obvious. > > 1. While having working implementation helps if the design is sound, > you can't use working implementation to substantiate a proposal. Hm? How does this statement compare to "rough consensus and running code" substantiating a proposal? > The approach you propose "I have a code that works. Let's write a > draft about it and make it a standard" is a negation of the very > spirit of IETF. I really hope I just mis-interpreted your mail. Hm, I am not trying to expose the spirit of IETF. You may have misinterpreted me. > 2. IETF is dedicated to development of protocols, recommendations > and practices, not a sharing place for exchanging implementations. But a protocol is made for two machines to exchange data understanding each other. > 3. Discussion about specific arrangements with customers is > definitely inappropriate in IETF. I agree, so one would not mention as motivator for a Last Call the fact that customers are waiting for this, no? >> Can you provide me implementation of route-option to replace my >> existing draft-mouton implementation? > > You chose to document your implementation (or implement -00 > individual draft, doesn't matter), you publish -00 draft and are > expecting that it will not change a bit and be approved as is? Right... please allow me to say I do not try to be arrogant. I can agree to modify my implementation, but you're proposing is to get rid of it alltogether. > And now you asking that I provide a contingency solution for your > mis-planned project? This is ridiculous. No no, I am not asking for a contingency plan; but what if we tried to interoperate code? Interoperability is useful right? >> (I can provide you our implementation of draft-mouton, under a >> certain license.) > > I believe you mentioned that on a list. You have patches for ISC > DHCP (that is distributed under BSD license). You also have patches > for wireshark (that you are obliged to publish as source code under > GPLv2 as soon as you distribute patched wireshark in any form). That > does say nothing about reasonableness (or lack of thereof) of > draft-moulton proposal. It does say that there is implementation of draft-mouton, i.e. time spent and software I don't want to through awat. Hm... then tell me about your implementation and your licensing scheme? At this point I have no indication whatsoever that route-option draft is implemented at all. What happens if I submit my code to ISC and to kernel.org? Would they accept it? Would they ask whether a similar implementation exist? > I'm sorry. I don't see any point in continuing this discussion any > further. If you want to continue it, I suggest that you your comments > on a list. Maybe someone else is interested in continuing this > conversation. Let me Cc the list based on your invitation. Alex > > Tomek From Ted.Lemon@nominum.com Thu Oct 27 08:29:47 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C406D21F8B8B for ; Thu, 27 Oct 2011 08:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.683 X-Spam-Level: X-Spam-Status: No, score=-105.683 tagged_above=-999 required=5 tests=[AWL=-0.839, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZMnrK+54R4Z for ; Thu, 27 Oct 2011 08:29:47 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id 0A0A121F8B80 for ; Thu, 27 Oct 2011 08:29:46 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP; Thu, 27 Oct 2011 08:29:47 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 7C8E21B80BA for ; Thu, 27 Oct 2011 08:29:39 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 8D044190052; Thu, 27 Oct 2011 08:29:36 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.01.0323.003; Thu, 27 Oct 2011 08:29:36 -0700 From: Ted Lemon To: Alexandru Petrescu Thread-Topic: I won't be in Taipei for MIF WG Thread-Index: AQHMgTbc3T/2qJI6ZUqP6EfUEEdfzJWQgrEAgAAd4ACAABgogIAAHVSAgAAHvACAAA+WgA== Date: Thu, 27 Oct 2011 15:29:35 +0000 Message-ID: References: <4E88B6EF.9050800@gmail.com> <4EA93870.4020302@gmail.com> <4EA94CB3.5090606@gmail.com> <4EA9654D.2010506@gmail.com> <4EA96BCA.204@gmail.com> In-Reply-To: <4EA96BCA.204@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_E6AE72A6B520475DBC3C27567745D1C0nominumcom_" MIME-Version: 1.0 Cc: mif , Margaret , "" , Hui Deng Subject: Re: [mif] I won't be in Taipei for MIF WG X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 15:29:47 -0000 --_000_E6AE72A6B520475DBC3C27567745D1C0nominumcom_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 T24gT2N0IDI3LCAyMDExLCBhdCAxMDozMyBBTSwgQWxleGFuZHJ1IFBldHJlc2N1IHdyb3RlOg0K MS4gV2hpbGUgaGF2aW5nIHdvcmtpbmcgaW1wbGVtZW50YXRpb24gaGVscHMgaWYgdGhlIGRlc2ln biBpcyBzb3VuZCwNCnlvdSBjYW4ndCB1c2Ugd29ya2luZyBpbXBsZW1lbnRhdGlvbiB0byBzdWJz dGFudGlhdGUgYSBwcm9wb3NhbC4NCg0KSG0/ICBIb3cgZG9lcyB0aGlzIHN0YXRlbWVudCBjb21w YXJlIHRvICJyb3VnaCBjb25zZW5zdXMgYW5kIHJ1bm5pbmcNCmNvZGUiIHN1YnN0YW50aWF0aW5n IGEgcHJvcG9zYWw/DQoNClRoZXJlIGlzIG5vIHJvdWdoIGNvbnNlbnN1cyBmb3IgeW91ciBwcm9w b3NhbCwgQWxleGFuZHJ1Lg0KDQpJZiB5b3VyIGltcGxlbWVudGF0aW9uIGlzIHNvIGNvbXBsaWNh dGVkIHRoYXQgaXQgcmVxdWlyZXMgeW91IHRvIGNvbnRyaWJ1dGUgY29kZSB0byB0aGUgSVNDLCB0 aGF0IHNob3VsZCBhbHJlYWR5IGJlIGEgY2x1ZSB0aGF0IGl0J3MgYSBiYWQgaWRlYTogREhDUCBv cHRpb25zIGFyZSBzaW1wbGUsIG5vdCBjb21wbGljYXRlZC4gICBZb3UgYXJlbid0IHN1cHBvc2Vk IHRvIGhhdmUgdG8gY2hhbmdlIHRoZSBzZXJ2ZXIgc291cmNlIGNvZGUgdG8gYWRkIGFuIG9wdGlv bi4gICBZb3UgYXJlIHN1cHBvc2VkIHRvIGJlIGFibGUgdG8ganVzdCBzcGVjaWZ5IHRoZSBvcHRp b24gZm9ybWF0LCBhbmQgdGhlIGV4aXN0aW5nIHNlcnZlciBzaG91bGQgYmUgYWJsZSB0byBwYXJz ZSBpdC4gICBUaGlzIGlzIGEgZmVhdHVyZSBvZiBldmVyeSBzZXJ2ZXIgSSBrbm93IG9mLCBjZXJ0 YWlubHkgaW5jbHVkaW5nIHRoZSBJU0Mgc2VydmVyLCB3aGljaCBoYXMgYW4gb3B0aW9uIGZvcm1h dCBncmFtbWFyLCBhbmQgdGhlIE5vbWludW0gc2VydmVyLCB3aGljaCBoYXMgc29tZXRoaW5nIHZl cnkgc2ltaWxhci4NCg0KVGhlIElTQyBESENQIGNsaWVudCBpcyBsaWtld2lzZSBjb25maWd1cmFi bGUgdG8gYWxsb3cgbmV3IG9wdGlvbnMgdG8gYmUgZGVzY3JpYmVkIHdpdGhvdXQgc291cmNlIGNv ZGUgY2hhbmdlcy4gICBTbyB0aGUgc3VtIHRvdGFsIGNvZGUgcmVxdWlyZWQgdG8gaW1wbGVtZW50 IHRoZSByb3V0ZSBvcHRpb24gc2hvdWxkIGJlIHplcm8gbGluZXMuDQoNCg== --_000_E6AE72A6B520475DBC3C27567745D1C0nominumcom_ Content-Type: text/html; charset="gb2312" Content-ID: <8B393261124872408BF1BB90EE871767@nominum.com> Content-Transfer-Encoding: quoted-printable
On Oct 27, 2011, at 10:33 AM, Alexandru Petrescu wrote:
1. While having working implementation helps if t= he design is sound,
you can't use working implementation to substanti= ate a proposal.

Hm?  How does this statement compare to "rough consensus and runn= ing
code" substantiating a proposal?

There is no rough consensus for your proposal, Alexandru.

If your implementation is so complicated that it requires you to contr= ibute code to the ISC, that should already be a clue that it's a bad idea: = DHCP options are simple, not complicated.   You aren't supposed to hav= e to change the server source code to add an option.   You are supposed to be able to just specify the opti= on format, and the existing server should be able to parse it.   This = is a feature of every server I know of, certainly including the ISC server,= which has an option format grammar, and the Nominum server, which has something very similar.

The ISC DHCP client is likewise configurable to allow new options to b= e described without source code changes.   So the sum total code requi= red to implement the route option should be zero lines.

--_000_E6AE72A6B520475DBC3C27567745D1C0nominumcom_-- From alexandru.petrescu@gmail.com Thu Oct 27 09:15:31 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC22D21F8C3F for ; Thu, 27 Oct 2011 09:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.749 X-Spam-Level: X-Spam-Status: No, score=-6.749 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLZOXyPJxgoH for ; Thu, 27 Oct 2011 09:15:31 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id C895321F8C33 for ; Thu, 27 Oct 2011 09:15:30 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id p9RGFRwA021788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 27 Oct 2011 18:15:27 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p9RGFQu9004536; Thu, 27 Oct 2011 18:15:26 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p9RGFKCr027500; Thu, 27 Oct 2011 18:15:26 +0200 Message-ID: <4EA98398.5010901@gmail.com> Date: Thu, 27 Oct 2011 18:15:20 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Ted Lemon References: <4E88B6EF.9050800@gmail.com> <4EA93870.4020302@gmail.com> <4EA94CB3.5090606@gmail.com> <4EA9654D.2010506@gmail.com> <4EA96BCA.204@gmail.com> In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit Cc: mif , Margaret , "" , Hui Deng Subject: Re: [mif] I won't be in Taipei for MIF WG X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 16:15:32 -0000 Le 27/10/2011 17:29, Ted Lemon a ¨¦crit : > On Oct 27, 2011, at 10:33 AM, Alexandru Petrescu wrote: >>> 1. While having working implementation helps if the design is >>> sound, you can't use working implementation to substantiate a >>> proposal. >> >> Hm? How does this statement compare to "rough consensus and running >> code" substantiating a proposal? > > There is no rough consensus for your proposal, Alexandru. And is there running code for route-option? > If your implementation is so complicated that it requires you to > contribute code to the ISC, that should already be a clue that it's > a bad idea: DHCP options are simple, not complicated. Efficiency sometimes rightfully implies code complexity (check e.g. PacketBB encoding for wireless settings). > You aren't supposed to have to change the server source code to add > an option. You are supposed to be able to just specify the option > format, and the existing server should be able to parse it. I believe the code format is C code currently (e.g. some quoted text). > This is a feature of every server I know of, certainly including the > ISC server, which has an option format grammar, and the Nominum > server, which has something very similar. > > The ISC DHCP client is likewise configurable to allow new options to > be described without source code changes. I am not sure about it. > So the sum total code required to implement the route option should > be zero lines. I am not sure really. There should be some code (script? bash? textual conf lines?) Please provide some sort of explanation or proof or so, if possible, thank you. Alex > From alexandru.petrescu@gmail.com Thu Oct 27 09:42:57 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9152721F8492 for ; Thu, 27 Oct 2011 09:42:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.582 X-Spam-Level: X-Spam-Status: No, score=-6.582 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zSm80muHEind for ; Thu, 27 Oct 2011 09:42:57 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.144]) by ietfa.amsl.com (Postfix) with ESMTP id BD4A721F849E for ; Thu, 27 Oct 2011 09:42:56 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id p9RGgqPP022597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 27 Oct 2011 18:42:52 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p9RGgpPJ013122; Thu, 27 Oct 2011 18:42:51 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p9RGgoeX008506; Thu, 27 Oct 2011 18:42:51 +0200 Message-ID: <4EA98A0A.7090407@gmail.com> Date: Thu, 27 Oct 2011 18:42:50 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Ted Lemon References: <4E88B6EF.9050800@gmail.com> <4EA93870.4020302@gmail.com> <4EA94CB3.5090606@gmail.com> <4EA9654D.2010506@gmail.com> <4EA96BCA.204@gmail.com> <4EA98398.5010901@gmail.com> In-Reply-To: <4EA98398.5010901@gmail.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit Cc: mif , Margaret , "" , Hui Deng Subject: Re: [mif] I won't be in Taipei for MIF WG X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 16:42:57 -0000 Let me add further to this. One of the first steps some implementers do is make sure their wireshark understands their messages... has one tried that on route-option? (for my information thanks). (we have tried wireshark extensions for drlo and it works, dissectors available upon request - that is C code as well). Alex Le 27/10/2011 18:15, Alexandru Petrescu a ¨¦crit : > Le 27/10/2011 17:29, Ted Lemon a ¨¦crit : >> On Oct 27, 2011, at 10:33 AM, Alexandru Petrescu wrote: >>>> 1. While having working implementation helps if the design is >>>> sound, you can't use working implementation to substantiate a >>>> proposal. >>> >>> Hm? How does this statement compare to "rough consensus and running >>> code" substantiating a proposal? >> >> There is no rough consensus for your proposal, Alexandru. > > And is there running code for route-option? > >> If your implementation is so complicated that it requires you to >> contribute code to the ISC, that should already be a clue that it's >> a bad idea: DHCP options are simple, not complicated. > > Efficiency sometimes rightfully implies code complexity (check e.g. > PacketBB encoding for wireless settings). > >> You aren't supposed to have to change the server source code to add >> an option. You are supposed to be able to just specify the option >> format, and the existing server should be able to parse it. > > I believe the code format is C code currently (e.g. some quoted text). > >> This is a feature of every server I know of, certainly including the >> ISC server, which has an option format grammar, and the Nominum >> server, which has something very similar. >> >> The ISC DHCP client is likewise configurable to allow new options to >> be described without source code changes. > > I am not sure about it. > >> So the sum total code required to implement the route option should >> be zero lines. > > I am not sure really. There should be some code (script? bash? textual > conf lines?) > > Please provide some sort of explanation or proof or so, if possible, > thank you. > > Alex > >> > From denghui02@hotmail.com Fri Oct 28 01:06:44 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54EC321F8A97 for ; Fri, 28 Oct 2011 01:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.264 X-Spam-Level: X-Spam-Status: No, score=-99.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFNPXAuYpfzc for ; Fri, 28 Oct 2011 01:06:43 -0700 (PDT) Received: from col0-omc2-s6.col0.hotmail.com (col0-omc2-s6.col0.hotmail.com [65.55.34.80]) by ietfa.amsl.com (Postfix) with ESMTP id 63F3321F87E2 for ; Fri, 28 Oct 2011 01:06:40 -0700 (PDT) Received: from COL118-W18 ([65.55.34.72]) by col0-omc2-s6.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 28 Oct 2011 01:06:40 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_83cc3442-3ff3-4ec0-bc92-d8161b3ff45b_" X-Originating-IP: [123.124.244.125] From: Hui Deng To: , , Teemu Savolainen , Margaret , Jari Arkko , ralph droms , , Date: Fri, 28 Oct 2011 16:06:40 +0800 Importance: Normal In-Reply-To: <82965628686B49EEA46E9C2F7766C170@nex.west.ntt.co.jp> References: <4E88B6EF.9050800@gmail.com> <4EA93870.4020302@gmail.com> <4EA94CB3.5090606@gmail.com> <4EA9654D.2010506@gmail.com> <4EA96BCA.204@gmail.com> <4EA98398.5010901@gmail.com>,<4EA98A0A.7090407@gmail.com> , , <82965628686B49EEA46E9C2F7766C170@nex.west.ntt.co.jp> MIME-Version: 1.0 X-OriginalArrivalTime: 28 Oct 2011 08:06:40.0045 (UTC) FILETIME=[85B705D0:01CC9548] Subject: Re: [mif] mif route implementation X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 08:06:44 -0000 --_83cc3442-3ff3-4ec0-bc92-d8161b3ff45b_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit Hello all People are asking the implementation here, thanks Okimoto-san about their information below, thanks a lot -Hui From: t.okimoto@rdc.west.ntt.co.jp To: denghui02@hotmail.com; matsumoto.arifumi@lab.ntt.co.jp; teemu.savolainen@nokia.com; margaretw42@gmail.com; jari.arkko@piuha.net; rdroms@cisco.com; kato.junya@lab.ntt.co.jp Subject: RE: mif route implementation Date: Fri, 28 Oct 2011 17:01:44 +0900 Hi Teemu and Jun-ya, How do you think about posting below information to MIF list? # up to you. ;-) Best Regards, Tadahisa Okimoto From: Hui Deng [mailto:denghui02@hotmail.com] Sent: Friday, October 28, 2011 4:58 PM To: Î÷ÑÐé_ ›_±¾ ÖÒ¾Ã; matsumoto.arifumi@lab.ntt.co.jp; Teemu Savolainen; Margaret; Jari Arkko; ralph droms; kato.junya@lab.ntt.co.jp Subject: RE: mif route implementation Hi Okimoto-san, Can you kindly help to forward this information to the mif mailing list? thanks a lot for your help -Hui From: t.okimoto@rdc.west.ntt.co.jp To: denghui02@hotmail.com; matsumoto.arifumi@lab.ntt.co.jp; teemu.savolainen@nokia.com; margaretw42@gmail.com; jari.arkko@piuha.net; rdroms@cisco.com; kato.junya@lab.ntt.co.jp Subject: RE: mif route implementation Date: Fri, 28 Oct 2011 16:55:46 +0900 Hi Hui-san, NTT lab shows demonstration with running codes at both IETF78 and IETF79. https://github.com/otroan/IETF-Non-Congruent-Multi-homing/wiki Jun-ya is the guy. Best Regards, Tadahisa Okimoto From: Hui Deng [mailto:denghui02@hotmail.com] Sent: Friday, October 28, 2011 4:12 PM To: Î÷ÑÐé_ ›_±¾ ÖÒ¾Ã; matsumoto.arifumi@lab.ntt.co.jp; Teemu Savolainen; Margaret; Jari Arkko; ralph droms Subject: mif route implementation Dear Okimoto-san MIF mailing list is discussing the implementation, I remeber that NTT has showed this demonstration before. Can you share this in the mailing list? thanks a lot -Hui --_83cc3442-3ff3-4ec0-bc92-d8161b3ff45b_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit
 Hello all
 
People are asking the implementation here,
thanks Okimoto-san about their information below,
 
thanks a lot
 
-Hui
From: t.okimoto@rdc.west.ntt.co.jp
To: denghui02@hotmail.com; matsumoto.arifumi@lab.ntt.co.jp; teemu.savolainen@nokia.com; margaretw42@gmail.com; jari.arkko@piuha.net; rdroms@cisco.com; kato.junya@lab.ntt.co.jp
Subject: RE: mif route implementation
Date: Fri, 28 Oct 2011 17:01:44 +0900

Hi Teemu and Jun-ya,
 
How do you think about posting below information to MIF list?
# up to you. ;-)
 
Best Regards,
Tadahisa Okimoto

From: Hui Deng [mailto:denghui02@hotmail.com]
Sent: Friday, October 28, 2011 4:58 PM
To: Î÷ÑÐé_ ›_±¾ ÖÒ¾Ã; matsumoto.arifumi@lab.ntt.co.jp; Teemu Savolainen; Margaret; Jari Arkko; ralph droms; kato.junya@lab.ntt.co.jp
Subject: RE: mif route implementation

Hi Okimoto-san,
 
Can you kindly help to forward this information to the mif mailing list?
thanks a lot for your help
 
-Hui
 
From: t.okimoto@rdc.west.ntt.co.jp
To: denghui02@hotmail.com; matsumoto.arifumi@lab.ntt.co.jp; teemu.savolainen@nokia.com; margaretw42@gmail.com; jari.arkko@piuha.net; rdroms@cisco.com; kato.junya@lab.ntt.co.jp
Subject: RE: mif route implementation
Date: Fri, 28 Oct 2011 16:55:46 +0900

Hi Hui-san,
 
NTT lab shows demonstration with running codes at both IETF78 and IETF79.
 
 
Jun-ya is the guy.
 
Best Regards,
Tadahisa Okimoto

From: Hui Deng [mailto:denghui02@hotmail.com]
Sent: Friday, October 28, 2011 4:12 PM
To: Î÷ÑÐé_ ›_±¾ ÖÒ¾Ã; matsumoto.arifumi@lab.ntt.co.jp; Teemu Savolainen; Margaret; Jari Arkko; ralph droms
Subject: mif route implementation

Dear Okimoto-san
 
MIF mailing list is discussing the implementation, I remeber that NTT has showed this demonstration before.
Can you share this in the mailing list?
 
thanks a lot
 
-Hui
 
--_83cc3442-3ff3-4ec0-bc92-d8161b3ff45b_-- From teemu.savolainen@nokia.com Fri Oct 28 01:07:11 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6337621F8AF4 for ; Fri, 28 Oct 2011 01:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.968 X-Spam-Level: X-Spam-Status: No, score=-2.968 tagged_above=-999 required=5 tests=[AWL=0.631, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FESyVGppCeg8 for ; Fri, 28 Oct 2011 01:07:10 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 78F6A21F8AEE for ; Fri, 28 Oct 2011 01:07:10 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p9S874ew027967; Fri, 28 Oct 2011 11:07:07 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 28 Oct 2011 11:07:01 +0300 Received: from 008-AM1MMR1-002.mgdnok.nokia.com (65.54.30.57) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 28 Oct 2011 10:07:00 +0200 Received: from 008-AM1MPN1-037.mgdnok.nokia.com ([169.254.7.120]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.01.0339.002; Fri, 28 Oct 2011 10:06:59 +0200 From: To: , Thread-Topic: I won't be in Taipei for MIF WG Thread-Index: AQHMgTbgybDGuofRrUmCzA1VPuKH9pWP69EAgAAd4QCAABgngIAAHVSAgABFvLiAAAp8MA== Date: Fri, 28 Oct 2011 08:06:59 +0000 Message-ID: <916CE6CF87173740BC8A2CE44309696203792B9B@008-AM1MPN1-037.mgdnok.nokia.com> References: <4E88B6EF.9050800@gmail.com> <4EA93870.4020302@gmail.com> <4EA94CB3.5090606@gmail.com> <4EA9654D.2010506@gmail.com> <4EA96BCA.204@gmail.com> <4EA98398.5010901@gmail.com> In-Reply-To: <4EA98398.5010901@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Company Confidential;Project=None; x-titus-version: 3.3.8.1 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IpQXDHt1zk6X9/SfGRWWDsRJk7rmELM52TQMlD/w5WK9K27zeZmGPyS3FOnTIEQDK5jS55UQumwz+iBF0K0p1sbVXICJ53WBGjsb/wpFrV2czDl5/Rm2zYvGRGGyhXG0vEjLhWm4KnM2rDCA0R472ujiN9ALdHeM1kUxk5k+ywfd3iDsnDpS93Y+neLYAHvSARSNezLNlrw17Z2gaiq7xFsNPEudFZlVQj08eA0JcD3M x-originating-ip: [10.162.62.61] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 28 Oct 2011 08:07:01.0060 (UTC) FILETIME=[923DA840:01CC9548] X-Nokia-AV: Clean Cc: mif@ietf.org, margaretw42@gmail.com, maximouton@gmail.com, denghui02@hotmail.com Subject: Re: [mif] I won't be in Taipei for MIF WG X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 08:07:11 -0000 > > There is no rough consensus for your proposal, Alexandru. >=20 > And is there running code for route-option? At the IETF#79 we had demonstration of our client side implementation (usin= g ISC's DHCP-client) done with Nokia N900 against NTT's implementation of t= he DHCPv6 server: http://www.ietf.org/registration/MeetingWiki/wiki/79bofs = (see section " Interoperability demonstration regarding IPv6 Multihoming wi= th multiple prefixes and interfaces"). In addition to that, in my lab I configured ISC's DHCP-4.2.0 server with th= e following configuration (masquerading real addresses with 'x'). The unass= igned option code 92 refers to DNS server selection option (as was specifie= d in draft-savolainen-mif-dns-server-selection-04) and unassigned code 93 f= or DHCPv6 option (as was specified in draft-dec-dhcpv6-route-option-05). I = had to use "string" type for OPTION-IA-RT as the grammar for some reason (b= ug or not-yet-implemented or my lack of skill, don't recall which) did not = work with options having multiple sub-options. Please note that all option = codes are just "random numbers" selected for implementation. -- option dhcp6.option-dns-server-selection-policy code 92 =3D=20 { ip6-address, integer 8, domain-list }; option dhcp6.option-ia-rt code 93 =3D string; subnet6 2001:xxx:xxx:42::/64 { option dhcp6.name-servers 2001:xxxx:xxxx:xx::x; option dhcp6.option-dns-server-selection-policy 2001:xxxx:xxxx:xxxx::x 00 "nokia.com", "ovi.com"; option dhcp6.option-ia-rt=09 00:01:00:3C: // OPTION_NEXT_HOP + len 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00: // next hop address 00:01:00:12: // OPTION_RT_PREFIX + len 60:01: = // Prefix Length + metric 64:FF:9B:00:00:00:00:00:00:00:00:00:00:00:00:00: // Prefix 00:01:00:12: // OPTION_RT_PREFIX + len 30:02: // Prefix Length + metric 2A:00:xx:xx:xx:xx:00:00:00:00:00:00:00:00:00:00: // Prefix 00:01:00:26: = // OPTION_NEXT_HOP + len 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00: // Next Hop address 00:01:00:12: // OPTION_RT_PREFIX + len 00:00: // Prefix Length + metric 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 // Prefix =3D=3D default ro= ute -- The point here is that the option could be defined without touching server= 's source code (or scripts) and I imagine some GUI-based configuration crea= tion tool could also use the string-format without trouble. The ISC's client side implementation was similarly unable to parse the sub-= options, hence I used "string" also there: -- option dhcp6.option-dns-server-selection-policy code 92 =3D { ip6-address, = integer 8, domain-list }; option dhcp6.option-ia-rt code 93 =3D string; -- I admit that on the client side I had to do quite many lines of scripting i= nto "dhclient-enter-hooks" for fetching the data out of the said string. I also had to modify the C-code of the client to fetch the IPv6 address of = the DHCP server, as that was not provided by the ISC DHCP client via any en= vironment variable (this was needed for this case: --copy-- When processing a received Route Option a client MUST substitute a received 0::0 value in the Next Hop Option with the source IPv6 address of the received DHCPv6 message. --copy-- Of course I then needed some addition code for implementing all the actions= received information triggered (setting up routes etc), but I guess that p= art is out of scope of this thread. The dhclient-enter-hooks script actuall= y called a small program that did the actual tricks: -- /usr/sbin/parse_ia_rt $new_dhcp6_option_ia_rt $interface $dhcpv6_server_add= ress -- Best regards, Teemu From maximilien.mouton@gmail.com Fri Oct 28 03:29:58 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC82A21F886A for ; Fri, 28 Oct 2011 03:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gw-1g7Ql1+ug for ; Fri, 28 Oct 2011 03:29:58 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id CD67B21F87FC for ; Fri, 28 Oct 2011 03:29:57 -0700 (PDT) Received: by wwe6 with SMTP id 6so3941820wwe.13 for ; Fri, 28 Oct 2011 03:29:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=TMMBuxr39rwBoi8we5JKlv4UCj7EzHCOtOvnWsdzqk0=; b=olq0K8iSm3GOvoL4Yy5H6iFKy6j+cUIH2cSoqnHDNya59KMbAow24MKeNu49i6wwB9 LwzRBJUzawK8Ye+coFc9hFC4yY9jZs3dUk0TpnzOLO13t/iBNXaRKjG32v2g75hlkBDm 2dVL9/3frT+p+Qh2cS541Qw3XoWirMgIiRf5g= Received: by 10.227.57.147 with SMTP id c19mr2989194wbh.8.1319797794147; Fri, 28 Oct 2011 03:29:54 -0700 (PDT) Received: from [127.0.0.1] (scy57-1-88-169-184-224.fbx.proxad.net. [88.169.184.224]) by mx.google.com with ESMTPS id ei16sm14662439wbb.21.2011.10.28.03.29.53 (version=SSLv3 cipher=OTHER); Fri, 28 Oct 2011 03:29:53 -0700 (PDT) Message-ID: <4EAA841E.2030000@gmail.com> Date: Fri, 28 Oct 2011 12:29:50 +0200 From: maximilien mouton User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Tomasz Mrugalski References: <4EA94BF6.5020501@gmail.com> In-Reply-To: <4EA94BF6.5020501@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: Margaret Wasserman , mif@ietf.org, Hui Deng Subject: Re: [mif] A request for Last Call on draft-ietf-mif-dhcpv6-route-option X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 10:29:59 -0000 Tomek, You use a wrong argument for criticize our proposition of defining separate options. You quote Ted saying it is not a good idea having two different ways providing the same information but it is actually not what we proposed. We proposed the same organization than DHCPv4 option router and classful static route option defined in RFC 2132 ie not allow route option to provide default route and use a specific option for default route. Thus there is no interoperability problem in our proposition. But this mail doesn't aim to continue this discussion. Anyway my only comment is that I think lifetime field of the default route should be up to 65535 (no more for compatibility reasons) with a recommendation to limit it at 9000 to be consistent with ND. Maximilien Le 27/10/2011 14:17, Tomasz Mrugalski a écrit : > Dear Chairs, Dear MIF, > > DHCPv6 Route Option draft has been presented in MIF several times. It > was also presented in DHC WG and most* (see below) comments were addressed. > > I would also like to point out that this draft incorporates changes > after Routing Directorate review, especially insightful comments from > Joel Halpern about potential problems in networks that use dynamic > routing. The lastest (-03) drafts contains clear warning that > configuring routing over DHCPv6 in networks that use dynamic routing is > a very bad idea (unless you exactly now what you are doing). > > * Authors chose to not incorporate some of the comments, raised by > authors of dlro draft. There was a discussion in MIF list. Route option > authors believe that: > > 1. defining separate option for just default route would be wrong. Let > me qoute Ted Lemon (DHC chair): "It's always a bad idea to have two ways > of specifying the same information—it creates a very clear potential for > interoperability problems.". On a related note, I was involved in work > on DS-Lite configuration over DHCPv6 and we initially had the same idea > - define two options (address and FQDN) for the same thing. This > approach was firmly rejected during IESG review. The message was clear: > "choose one option". > > 2. conveying MAC (or link-layer in general) address is not necessary. > There are other mechanisms like ND to obtain that information. Forcing > this information on every client is just a waste of space as all clients > that I know of can obtain this information on their own. They can do > that in a timely manner, so raised argument about speed-up is not valid > in my opinion. Another aspect is operational consideration. It would be > very cumbersome to deploy and use. If operator changes interface in its > router, DHCP configuration had to be updated and reconfigure procedure > initiated. It could work in theory, but reconfigure is not commonly > supported. DHCP server configuration would require knowledge of > link-layer addresses of announced router(s). We could gain nothing by > including MAC address, but get a lot of problems in the process. > Therefore dhcpv6-route-option authors chose to not include link-layer > information field. > > I would like to point out again that route-option proposal is > extensible. It is designed as a minimal useful set of informations > necessary for routing configuration. There are many more aspects of > routing that may be useful in *some* cases. Therefore we made it clear > that proposed options are extensible. If there are valid cases when > extra information is useful, it should be defined as extension option. > That's they recommendation I offer to anyone who says "can you add > parameter X to route options? I really need it". > > To summarize this summary, we believe that mif-dhcpv6-route-option draft > received enough reviews by experts in MIF, DHC and routing fields and is > ready for WGLC. Therefore I'd like to ask MIF chairs to announce one. > > If we choose to have LC done in a timely fashion, we could discuss the > results in Taipei. If that is the case, I would like to request time > slot in Taipei meeting. I can't guess how many comments we will receive > during WGLC, but I hope 10 or 15 minutes will be enough. > > Cheers, > Tomek > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From alexandru.petrescu@gmail.com Fri Oct 28 04:52:53 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85EB721F8B82 for ; Fri, 28 Oct 2011 04:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id upb1vEWkAOKK for ; Fri, 28 Oct 2011 04:52:53 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 2106121F8B70 for ; Fri, 28 Oct 2011 04:52:51 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id p9SBqoPs010936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 28 Oct 2011 13:52:50 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p9SBqoPE001577 for ; Fri, 28 Oct 2011 13:52:50 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p9SBqlr9016969 for ; Fri, 28 Oct 2011 13:52:50 +0200 Message-ID: <4EAA978E.80609@gmail.com> Date: Fri, 28 Oct 2011 13:52:46 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: mif@ietf.org References: <4E88B6EF.9050800@gmail.com> <4EA93870.4020302@gmail.com> <4EA94CB3.5090606@gmail.com> <4EA9654D.2010506@gmail.com> <4EA96BCA.204@gmail.com> <4EA98398.5010901@gmail.com>, <4EA98A0A.7090407@gmail.com> , , <82965628686B49EEA46E9C2F7766C170@nex.west.ntt.co.jp> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mif] mif route implementation X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 11:52:58 -0000 Thank you for the information below, this is relevant support to route-option draft. Side remark: it says to support route-option-02, whereas now route-option is at its version 03. There is difference in message format which may impact implementation. Alex Le 28/10/2011 10:06, Hui Deng a écrit : > Hello all > > People are asking the implementation here, > thanks Okimoto-san about their information below, > > thanks a lot > > -Hui > ------------------------------------------------------------------------ > From: t.okimoto@rdc.west.ntt.co.jp > To: denghui02@hotmail.com; matsumoto.arifumi@lab.ntt.co.jp; > teemu.savolainen@nokia.com; margaretw42@gmail.com; jari.arkko@piuha.net; > rdroms@cisco.com; kato.junya@lab.ntt.co.jp > Subject: RE: mif route implementation > Date: Fri, 28 Oct 2011 17:01:44 +0900 > > Hi Teemu and Jun-ya, > How do you think about posting below information to MIF list? > # up to you. ;-) > Best Regards, > Tadahisa Okimoto > > ------------------------------------------------------------------------ > *From:* Hui Deng [mailto:denghui02@hotmail.com] > *Sent:* Friday, October 28, 2011 4:58 PM > *To:* 西研開 沖本 å¿ ä¹…; matsumoto.arifumi@lab.ntt.co.jp; Teemu > Savolainen; Margaret; Jari Arkko; ralph droms; kato.junya@lab.ntt.co.jp > *Subject:* RE: mif route implementation > > Hi Okimoto-san, > > Can you kindly help to forward this information to the mif mailing list? > thanks a lot for your help > > -Hui > > ------------------------------------------------------------------------ > From: t.okimoto@rdc.west.ntt.co.jp > To: denghui02@hotmail.com; matsumoto.arifumi@lab.ntt.co.jp; > teemu.savolainen@nokia.com; margaretw42@gmail.com; > jari.arkko@piuha.net; rdroms@cisco.com; kato.junya@lab.ntt.co.jp > Subject: RE: mif route implementation > Date: Fri, 28 Oct 2011 16:55:46 +0900 > > Hi Hui-san, > NTT lab shows demonstration with running codes at both IETF78 and > IETF79. > https://github.com/otroan/IETF-Non-Congruent-Multi-homing/wiki > Jun-ya is the guy. > Best Regards, > Tadahisa Okimoto > > ------------------------------------------------------------------------ > *From:* Hui Deng [mailto:denghui02@hotmail.com] > *Sent:* Friday, October 28, 2011 4:12 PM > *To:* 西研開 沖本 å¿ ä¹…; matsumoto.arifumi@lab.ntt.co.jp; Teemu > Savolainen; Margaret; Jari Arkko; ralph droms > *Subject:* mif route implementation > > Dear Okimoto-san > > MIF mailing list is discussing the implementation, I remeber > that NTT has showed this demonstration before. > Can you share this in the mailing list? > > thanks a lot > > -Hui > > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From alexandru.petrescu@gmail.com Fri Oct 28 05:04:33 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9818521F84F8 for ; Fri, 28 Oct 2011 05:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JxsIaiZ7qxYN for ; Fri, 28 Oct 2011 05:04:32 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.144]) by ietfa.amsl.com (Postfix) with ESMTP id 98A7821F84F5 for ; Fri, 28 Oct 2011 05:04:32 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id p9SC4SIY021183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 28 Oct 2011 14:04:28 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p9SC4R73006837; Fri, 28 Oct 2011 14:04:27 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p9SC4NrB023948; Fri, 28 Oct 2011 14:04:27 +0200 Message-ID: <4EAA9A47.3060707@gmail.com> Date: Fri, 28 Oct 2011 14:04:23 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: teemu.savolainen@nokia.com References: <4E88B6EF.9050800@gmail.com> <4EA93870.4020302@gmail.com> <4EA94CB3.5090606@gmail.com> <4EA9654D.2010506@gmail.com> <4EA96BCA.204@gmail.com> <4EA98398.5010901@gmail.com> <916CE6CF87173740BC8A2CE44309696203792B9B@008-AM1MPN1-037.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE44309696203792B9B@008-AM1MPN1-037.mgdnok.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: mif@ietf.org, margaretw42@gmail.com, maximouton@gmail.com, denghui02@hotmail.com Subject: Re: [mif] route-option implementation X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 12:04:33 -0000 Le 28/10/2011 10:06, teemu.savolainen@nokia.com a écrit : >>> There is no rough consensus for your proposal, Alexandru. >> >> And is there running code for route-option? > > At the IETF#79 we had demonstration of our client side implementation > (using ISC's DHCP-client) done with Nokia N900 against NTT's > implementation of the DHCPv6 server: > http://www.ietf.org/registration/MeetingWiki/wiki/79bofs (see section > " Interoperability demonstration regarding IPv6 Multihoming with > multiple prefixes and interfaces"). > > In addition to that, in my lab I configured ISC's DHCP-4.2.0 server > with the following configuration (masquerading real addresses with > 'x'). The unassigned option code 92 refers to DNS server selection > option (as was specified in > draft-savolainen-mif-dns-server-selection-04) and unassigned code 93 > for DHCPv6 option (as was specified in > draft-dec-dhcpv6-route-option-05). I had to use "string" type for > OPTION-IA-RT as the grammar for some reason (bug or > not-yet-implemented or my lack of skill, don't recall which) did not > work with options having multiple sub-options. Please note that all > option codes are just "random numbers" selected for implementation. > -- option dhcp6.option-dns-server-selection-policy code 92 = { > ip6-address, integer 8, domain-list }; > > option dhcp6.option-ia-rt code 93 = string; > > subnet6 2001:xxx:xxx:42::/64 { option dhcp6.name-servers > 2001:xxxx:xxxx:xx::x; option > dhcp6.option-dns-server-selection-policy 2001:xxxx:xxxx:xxxx::x 00 > "nokia.com", "ovi.com"; > > option dhcp6.option-ia-rt 00:01:00:3C: // OPTION_NEXT_HOP > + len 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00: // next hop > address 00:01:00:12: // OPTION_RT_PREFIX + len 60:01: > // Prefix Length + metric > 64:FF:9B:00:00:00:00:00:00:00:00:00:00:00:00:00: // Prefix > 00:01:00:12: // OPTION_RT_PREFIX + len 30:02: > // Prefix Length + metric > 2A:00:xx:xx:xx:xx:00:00:00:00:00:00:00:00:00:00: // Prefix > 00:01:00:26: > // OPTION_NEXT_HOP + len > 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00: // Next Hop address > 00:01:00:12: // OPTION_RT_PREFIX + len 00:00: > // Prefix Length + metric > 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 // Prefix == default > route -- The point here is that the option could be defined without > touching server's source code (or scripts) and I imagine some > GUI-based configuration creation tool could also use the > string-format without trouble. I understand. Let me tell further how I understand it. The way ISC DHCP software is written, it does not allow to define new options in the DHCP messages such as to convey lifetime and MAC address (be it for a default route, or for other route) in an efficient manner (i.e. avoid artificial "type" and "len" separators). If one wants to do that then one has to modify the ISC software more than just reusing its standard software way of extensions like option dhcp6.option-ia-rt. This further modification (MAC, lifetime) can only be done by C code. If find it artificial to limit the specification of protocol to the way one particular implementation (ISC, which is very good) lets an implementer to do. In this sense, I do not think the current route-option spec is extensible in a way my requirements needs it (limited ressources wireless, interactions with ND); the current route-option spec is extensible only in the way that ISC software is extensible. If route-option draft would not do "default route" - but do "all routes except default" - then another later option will be able to do "default route" in a more efficient manner. Alex Let me put it otherwise: because ISC implementation doesn't allow one to avoid touching C code defining new option (e.g. MAC), or a more efficient way of sequencing > > The ISC's client side implementation was similarly unable to parse > the sub-options, hence I used "string" also there: -- option > dhcp6.option-dns-server-selection-policy code 92 = { ip6-address, > integer 8, domain-list }; > > option dhcp6.option-ia-rt code 93 = string; -- > > I admit that on the client side I had to do quite many lines of > scripting into "dhclient-enter-hooks" for fetching the data out of > the said string. > > I also had to modify the C-code of the client to fetch the IPv6 > address of the DHCP server, as that was not provided by the ISC DHCP > client via any environment variable (this was needed for this case: > --copy-- When processing a received Route Option a client MUST > substitute a received 0::0 value in the Next Hop Option with the > source IPv6 address of the received DHCPv6 message. --copy-- > > Of course I then needed some addition code for implementing all the > actions received information triggered (setting up routes etc), but I > guess that part is out of scope of this thread. The > dhclient-enter-hooks script actually called a small program that did > the actual tricks: -- /usr/sbin/parse_ia_rt $new_dhcp6_option_ia_rt > $interface $dhcpv6_server_address -- > > Best regards, > > Teemu > > > From alexandru.petrescu@gmail.com Fri Oct 28 05:11:27 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7A0F21F8B48 for ; Fri, 28 Oct 2011 05:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.416 X-Spam-Level: X-Spam-Status: No, score=-6.416 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbCZhqNTNozW for ; Fri, 28 Oct 2011 05:11:27 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 25D8821F8B42 for ; Fri, 28 Oct 2011 05:11:26 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id p9SCBQMO020720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 28 Oct 2011 14:11:26 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p9SCBPG8009253 for ; Fri, 28 Oct 2011 14:11:26 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p9SCBMEW001817 for ; Fri, 28 Oct 2011 14:11:25 +0200 Message-ID: <4EAA9BEA.1060108@gmail.com> Date: Fri, 28 Oct 2011 14:11:22 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: mif Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mif] route-option vs drlo, possible advantageous way forward X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 12:11:28 -0000 WG MIF, Excuse me if I repeat myself. I wanted to share explicitely a possible way forward that I discussed with a number of colleagues, and that looked advantageous on our side: - draft route-option would do all routes except default route. - draft drlo would do only default route and no generic route. This would satisfy the requirement of only one means to achieve one goal. (I have discussed this privately with Tomasz, I think I rememember not agreement; but I would dare now to try ask other opionion from WG members - what do you think?) Yours, Alex From simon.perreault@viagenie.ca Fri Oct 28 05:27:14 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56AAC21F8B8C for ; Fri, 28 Oct 2011 05:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id btkot08Q4Bw5 for ; Fri, 28 Oct 2011 05:27:13 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id C4A3321F8B4C for ; Fri, 28 Oct 2011 05:27:13 -0700 (PDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 1575420CC2 for ; Fri, 28 Oct 2011 08:27:13 -0400 (EDT) Message-ID: <4EAA9FA0.8080105@viagenie.ca> Date: Fri, 28 Oct 2011 08:27:12 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110720 Thunderbird/5.0 MIME-Version: 1.0 To: mif@ietf.org References: <4EAA9BEA.1060108@gmail.com> In-Reply-To: <4EAA9BEA.1060108@gmail.com> X-Enigmail-Version: 1.2.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [mif] route-option vs drlo, possible advantageous way forward X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 12:27:14 -0000 On 2011-10-28 08:11, Alexandru Petrescu wrote: > - draft route-option would do all routes except default route. > - draft drlo would do only default route and no generic route. I've been watching the discussion unfold. I am still unconvinced of any benefit of this proposal. Furthermore, I think there has been enough discussion at this point. We should move on. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From Ted.Lemon@nominum.com Fri Oct 28 05:33:04 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ECA721F8B5B for ; Fri, 28 Oct 2011 05:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.534 X-Spam-Level: X-Spam-Status: No, score=-106.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NxVKH+Pr08nD for ; Fri, 28 Oct 2011 05:33:03 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 7D23121F8B2B for ; Fri, 28 Oct 2011 05:33:03 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP; Fri, 28 Oct 2011 05:33:03 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 760181B8274 for ; Fri, 28 Oct 2011 05:32:52 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 7BAA5190052; Fri, 28 Oct 2011 05:32:49 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.01.0323.003; Fri, 28 Oct 2011 05:32:49 -0700 From: Ted Lemon To: Alexandru Petrescu Thread-Topic: [mif] route-option vs drlo, possible advantageous way forward Thread-Index: AQHMlWq7p60UWax4k0O/c99sBcL01JWRsJPI Date: Fri, 28 Oct 2011 12:32:49 +0000 Message-ID: <6A9A0ED8-D763-4788-9E98-C54633152CE1@nominum.com> References: <4EAA9BEA.1060108@gmail.com> In-Reply-To: <4EAA9BEA.1060108@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mif Subject: Re: [mif] route-option vs drlo, possible advantageous way forward X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 12:33:04 -0000 On Oct 28, 2011, at 8:11 AM, "Alexandru Petrescu" wrote: > (I have discussed this privately with Tomasz, I think I rememember not > agreement; but I would dare now to try ask other opionion from WG > members - what do you think?) Maximilian quite eloquently explained the needless additional complexity in= troduced by the default route option. He didn't point out that in order f= or the route lifetime field to be meaningful, changes would have to be made= to the DHCPv6 client state machine, but this is also true. It seems really clear cut to me: the route option is simpler, and does ever= ything we need, and so that is what we should use going forward. I also a= gree with Simon that this has been discussed to death. From alexandru.petrescu@gmail.com Fri Oct 28 07:03:48 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C736921F8B64 for ; Fri, 28 Oct 2011 07:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.392 X-Spam-Level: X-Spam-Status: No, score=-6.392 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uzXu+GrbxkWf for ; Fri, 28 Oct 2011 07:03:48 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 102CD21F8B42 for ; Fri, 28 Oct 2011 07:03:47 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id p9SE3khG023109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 28 Oct 2011 16:03:46 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p9SE3kBm020728 for ; Fri, 28 Oct 2011 16:03:46 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p9SE3gOC019312 for ; Fri, 28 Oct 2011 16:03:45 +0200 Message-ID: <4EAAB63F.3030808@gmail.com> Date: Fri, 28 Oct 2011 16:03:43 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: mif Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mif] Option size for lifetimed default route: route-option vs drlo X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 14:03:48 -0000 DHCP to communicate a default route with lifetime, to Client: - with route-option, the option size is: 48bytes. - with drlo, the option size is: 28bytes. Alex From alexandru.petrescu@cea.fr Fri Oct 28 07:03:51 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB9E21F8B7C for ; Fri, 28 Oct 2011 07:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwlDqwkwYE7S for ; Fri, 28 Oct 2011 07:03:50 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.144]) by ietfa.amsl.com (Postfix) with ESMTP id 376A621F8B76 for ; Fri, 28 Oct 2011 07:03:50 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id p9SE3nge001214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 28 Oct 2011 16:03:49 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p9SE3m39020777 for ; Fri, 28 Oct 2011 16:03:49 +0200 (envelope-from alexandru.petrescu@cea.fr) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p9SE3lqZ019385 for ; Fri, 28 Oct 2011 16:03:48 +0200 Message-ID: <4EAAB644.2050400@cea.fr> Date: Fri, 28 Oct 2011 16:03:48 +0200 From: Alexandru Petrescu Organization: CEA User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: mif Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070802050702060602000601" X-Mailman-Approved-At: Fri, 28 Oct 2011 08:14:49 -0700 Subject: [mif] Possible requirements for DRLO that Route-Option does not satisfy X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 14:03:51 -0000 Ceci est un message signC) cryptographiquement au format MIME. --------------ms070802050702060602000601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Possible requirements for DRLO that Route-Option does not satisfy: In memory- and bandwidth-constrained environments there are strong requirements to: - use only one software implementation (DHCP or ND but not both); or, when needing to solve the MAC address, route-option relies on ND. - avoid unnecessary chatter (avoid NS-NA); route-option requires the use of NS-NA in addition to DHCP, for a default route to solve its MAC address. - send as little control data as possible; route-option communicates more data than necessary (many unneeded separation fields) - communicate _only_ the default route and no other route; route-option sends too much data which necessary only in the generic route case, unnecessary for the default route (e.g. metrics). Yours, Alex --------------ms070802050702060602000601 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: Signature cryptographique S/MIME MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIK0zCC BUMwggQroAMCAQICARIwDQYJKoZIhvcNAQEFBQAwQDELMAkGA1UEBhMCZnIxDDAKBgNVBAoT A2NlYTELMAkGA1UECxMCQUMxFjAUBgNVBAMTDUNFQSBBQyBSYWNpbmUwHhcNMDcwOTE0MTMz MjIyWhcNMTMwNDAxMTMzMjIyWjBKMQswCQYDVQQGEwJGUjEMMAoGA1UECgwDY2VhMQswCQYD VQQLDAJBQzEgMB4GA1UEAwwXQ0VBIEFDIFV0aWxpc2F0ZXVyIDIwMDcwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQChEQI65o/qmEcBpmJbg8o0FuGd3dhegyEO3NqTFfybHFXN yswJw4Y7axYY+Cw0wipB/NSMKCSJPalNoN4mkXcmfJW5Y1NXw8a5dC81s02kSp/KhMNtmNKn bixB1wDi/fHc4qGjNYnnGUeBr3I1L2gAgcrHUWugbowFfEVib18YycArepx/jnT5XoW1F02h Krp/f1vPx1KLUWPI/gKp7/79h2EAxxwX6zQqUEtLBRm23HtWTXLns1oCpjhtfpp9dyIbTQO4 Bfzh57JDKe/6uK/dTowBPeabL/rIRcikODTiJd+i9pnpKYGZirI+QPOs+rVRGjiacyhvTMx+ JKDoE5EhAgMBAAGjggI8MIICODAOBgNVHQ8BAf8EBAMCAQYwPgYDVR0fBDcwNTAzoDGgL4Yt aHR0cDovL2NybC1hYy1yYWNpbmUuY2VhLmZyL2NybC9hYy1yYWNpbmUuY3JsMEIGCCsGAQUF BwEBBDYwNDAyBggrBgEFBQcwAoYmaHR0cDovL3d3dy1pZ2MuY2VhLmZyL2FjL2FjLXJhY2lu ZS5jZXIwgcgGA1UdIASBwDCBvTCBugYKKwYBBAHgYAEEATCBqzAlBggrBgEFBQcCARYZaHR0 cDovL3d3dy1pZ2MuY2VhLmZyL3BjLzCBgQYIKwYBBQUHAgIwdTANFgNDRUEwBgIBAgIBABpk Vm91cyBkZXZleiBhY2NlcHRlciBsYSBwb2xpdGlxdWUgZGUgY2VydGlmaWNhdGlvbiBhdmFu dCBkJ3V0aWxpc2VyIGNlIGNlcnRpZmljYXQsIGNmLiB3d3ctaWdjLmNlYS5mcjARBglghkgB hvhCAQEEBAMCAAcwcwYJYIZIAYb4QgENBGYWZFZvdXMgZGV2ZXogYWNjZXB0ZXIgbGEgcG9s aXRpcXVlIGRlIGNlcnRpZmljYXRpb24gYXZhbnQgZCd1dGlsaXNlciBjZSBjZXJ0aWZpY2F0 LCBjZi4gd3d3LWlnYy5jZWEuZnIwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUSB9iW9Ok VOso08GkO3J6Sq9CKLwwHwYDVR0jBBgwFoAULh+VugJUUoworW/R94+gVFaTKJEwDQYJKoZI hvcNAQEFBQADggEBAL9hw5b6yWkQK44U6xhvMKGYIwmxo/8yYNsaZlfa5v4pTIPVZPg4L9VZ 5cSsJeeu/nqSgRGmF01uLxZ7vcbSWKKobJVmbiowszmbpTKbmMo/bYFoYNH15LP8ymWiapzo DiP++hqhXRWeS4LHjgdCZqZBYxedeoaWjVmT+1ZGd7x6M7KOteWZecRv7OgYcKt7SvGXbjTF fjtYJB9DeKadr3W/PYK9kZ77ZkCDzpQLqUoRBuStSIWvhJRhnxGLRpwP/wRqZksvMupThSyE B19XMekJE0mUYezbttma1FEhGLEKMU3nk40ojIvanUPViwb4nCJE6Lubym1GdA/OdNU8thcw ggWIMIIEcKADAgECAgIhjzANBgkqhkiG9w0BAQUFADBKMQswCQYDVQQGEwJGUjEMMAoGA1UE CgwDY2VhMQswCQYDVQQLDAJBQzEgMB4GA1UEAwwXQ0VBIEFDIFV0aWxpc2F0ZXVyIDIwMDcw HhcNMTEwMjE2MTU1NTA4WhcNMTMwMjE2MTU1NTA4WjBYMQswCQYDVQQGEwJGUjEMMAoGA1UE CgwDY2VhMRQwEgYDVQQLDAtVdGlsaXNhdGV1cjElMCMGA1UEAwwcUEVUUkVTQ1UgQWxleGFu ZHJ1IEFQMjIyMDQwQjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKmIjiUSNboW 7BkJ+1//1thQ5kufQ9leW4nrAqzaUSlNIzRYGUa86AMXeNKWLKdmqLqTwkaW8u0CKEcBOyjq 5hLgeXPmyjmN6Jc/OZdy/owvkun0rtp6IESbRhwGNNXNKHN8VAgThfcDGCfcDyIKRGNK2cnr yEqWoJlydkAydrsUHMElIuckhyfIXi8S3/6SsGnrIT5iLVc1EJ0+0iNmlcv0HMcN91FjsXIv t/4pb0RbeSNiKA4+mVCYG7a2qfHRxmgNXw2wHltUo0nrqBPFtqYr1HP0pjwJPmk57YNwCXHk HuMLsukuDd7tiI6M/LoeHTD91Lh1Deq670puPRA0T0MCAwEAAaOCAmgwggJkMB0GA1UdDgQW BBQ5zvh22ilQSmLiI/PSmXqhQ0Ar9DAfBgNVHSMEGDAWgBRIH2Jb06RU6yjTwaQ7cnpKr0Io vDCBxwYDVR0gBIG/MIG8MIG5BgorBgEEAeBgAQQCMIGqMCUGCCsGAQUFBwIBFhlodHRwOi8v d3d3LWlnYy5jZWEuZnIvcGMvMIGABggrBgEFBQcCAjB0MA0WA0NFQTAGAgECAgEAGmNWb3Vz IGRldmV6IGFjZXB0ZXIgbGEgcG9saXRpcXVlIGRlIGNlcnRpZmljYXRpb24gYXZhbnQgZCd1 dGlsaXNlciBjZSBjZXJ0aWZpY2F0LCBjZi4gd3d3LWlnYy5jZWEuZnIwEQYJYIZIAYb4QgEB BAQDAgWgMA4GA1UdDwEB/wQEAwIEsDAkBgNVHREEHTAbgRlhbGV4YW5kcnUucGV0cmVzY3VA Y2VhLmZyME0GA1UdHwRGMEQwQqBAoD6GPGh0dHA6Ly9jcmwtYWMtdXRpbGlzYXRldXIuY2Vh LmZyL2NybC9hYy11dGlsaXNhdGV1ci0yMDA3LmNybDByBglghkgBhvhCAQ0EZRZjVm91cyBk ZXZleiBhY2VwdGVyIGxhIHBvbGl0aXF1ZSBkZSBjZXJ0aWZpY2F0aW9uIGF2YW50IGQndXRp bGlzZXIgY2UgY2VydGlmaWNhdCwgY2YuIHd3dy1pZ2MuY2VhLmZyMEwGCCsGAQUFBwEBBEAw PjA8BggrBgEFBQcwAoYwaHR0cDovL3d3dy1pZ2MuY2VhLmZyL2FjL2FjLXV0aWxpc2F0ZXVy LTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQB6zYPUd0glvvwbDiDOYb4lT9+xXt1IBxjI 6TTxrmB+gHVqLxB6oswDC/xXLOKtV1PERNaiOFOkaLBUq52TuVbLKjI2w1N0WamrO9TBrRoF xvr2gPncX5HMKYQDBmANQdt2Sa1Hjl8RLmlXv11n+JT/I0E3h5PaA6HN+nueAA/HlmmCCZal 8C7Xi9VLiyG1Lq5ShJd4waRRI5Gp1nI24bDH2ee2xQcONBroptNNxDMqXitRFjK6teVwdMgH h1Sx4MNJxHFmVP5qyHjDbIhcXWuxKAp15NYsKuB7kg7iNVunLDK80ETBhHoH/vDDyGTe2pzm 1VnALP+Vf4nbDVA0xCcpMYIC/TCCAvkCAQEwUDBKMQswCQYDVQQGEwJGUjEMMAoGA1UECgwD Y2VhMQswCQYDVQQLDAJBQzEgMB4GA1UEAwwXQ0VBIEFDIFV0aWxpc2F0ZXVyIDIwMDcCAiGP MAkGBSsOAwIaBQCgggGCMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTExMTAyODE0MDM0OFowIwYJKoZIhvcNAQkEMRYEFNx0GaMS0z+7mGeYgwM43DHqFAlG MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMC AgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDBfBgkrBgEEAYI3 EAQxUjBQMEoxCzAJBgNVBAYTAkZSMQwwCgYDVQQKDANjZWExCzAJBgNVBAsMAkFDMSAwHgYD VQQDDBdDRUEgQUMgVXRpbGlzYXRldXIgMjAwNwICIY8wYQYLKoZIhvcNAQkQAgsxUqBQMEox CzAJBgNVBAYTAkZSMQwwCgYDVQQKDANjZWExCzAJBgNVBAsMAkFDMSAwHgYDVQQDDBdDRUEg QUMgVXRpbGlzYXRldXIgMjAwNwICIY8wDQYJKoZIhvcNAQEBBQAEggEAeLz6lgzE4IlBU8Kp 3av1xdCZWgJyTiQftE+14yplx+h+OvnxDFgmFuP2pjmawx3KBgIgTljEH5hexZa9ACO0222V GzYbCu4n3rvHbKswXRSZjL2mTOUm3rdC+SGJ3SVlFkgzlu3Vqg6rYXtoMhNRxmBGVM9Xr2tl 8LW3TX8eSlN/vbxzDiAbDZgwAHNAbdPkDj0pXyaNwlnsiX6wznK+ze/zAn5p06vkZCoj8Zcs 98WZrQM8t9DgPi1WbofcP4/3TlIPOl9vmdY6q+ImO/mdTPwoF38BxPbXbDVu6d1uHEmmwOWD rW6GG6rPeAh/MpeAdSv/39RumavMUkbhjwAoOAAAAAAAAA== --------------ms070802050702060602000601-- From tomasz.mrugalski@gmail.com Fri Oct 28 10:51:09 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5316011E808C for ; Fri, 28 Oct 2011 10:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjDsOdR3qkPO for ; Fri, 28 Oct 2011 10:51:08 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 07E5511E8089 for ; Fri, 28 Oct 2011 10:51:07 -0700 (PDT) Received: by wyh22 with SMTP id 22so4918956wyh.31 for ; Fri, 28 Oct 2011 10:51:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-tagtoolbar-keys:content-type :content-transfer-encoding; bh=DHl4ydiR19aX8/Jp8uJQDowGOSoujFkwrX5+00tVfm0=; b=uMaWJn4u3+RdswUyXRetjl967+QabbwjEmlKF+dnHGmcH3OrrATo5fy5iPGSZNRicQ U7lt4rLBudS4zOPrAZu4mwl1fCOjfk5DoYqMwE3o1IiVCH2drCJlBSuOclt233PuVfAW PbnQM4Q7oZjHdcSKwwSA4gdW6uoWfUR74nSns= Received: by 10.227.208.81 with SMTP id gb17mr5001857wbb.24.1319824267182; Fri, 28 Oct 2011 10:51:07 -0700 (PDT) Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPS id a27sm16827530wbp.16.2011.10.28.10.51.04 (version=SSLv3 cipher=OTHER); Fri, 28 Oct 2011 10:51:05 -0700 (PDT) Message-ID: <4EAAEB8B.6050005@gmail.com> Date: Fri, 28 Oct 2011 19:51:07 +0200 From: Tomasz Mrugalski User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: mif@ietf.org References: <4EAAB63F.3030808@gmail.com> In-Reply-To: <4EAAB63F.3030808@gmail.com> X-TagToolbar-Keys: D20111028195107440 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [mif] Option size for lifetimed default route: route-option vs drlo X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 17:51:09 -0000 On 28.10.2011 16:03, Alexandru Petrescu wrote: > DHCP to communicate a default route with lifetime, to Client: > > - with route-option, the option size is: 48bytes. Not true. You can convey default route information using just NEXT_HOP option, which is 20 octets actually. Please read section 3.1, paragraphs 2 and 3 (discussion about bandwidth limited cases) and section 4.1 of route-option-03. I'd like to remind you that this paragraph was added specifically to address your concerns about bandwidth limitations. > - with drlo, the option size is: 28bytes. I take your word for it. I read that draft a long a ago. As you see, route-option is more flexible (supports specific routes and a default route) and it can be more efficient if you need it. While I acknowledge that your specific use case exists, you must also acknowledge that not every use case is exactly like yours. I see that you are trying to find one specific very narrow metric and use that to point out that one solution is better than another. Please don't assume that if you need something, everyone else needs it as well. Have a nice weekend, Tomek From denghui02@hotmail.com Fri Oct 28 11:07:22 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84B0921F86C1 for ; Fri, 28 Oct 2011 11:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MofW7rAvoCwE for ; Fri, 28 Oct 2011 11:07:21 -0700 (PDT) Received: from col0-omc2-s7.col0.hotmail.com (col0-omc2-s7.col0.hotmail.com [65.55.34.81]) by ietfa.amsl.com (Postfix) with ESMTP id CF3FA21F86A5 for ; Fri, 28 Oct 2011 11:07:21 -0700 (PDT) Received: from COL118-W38 ([65.55.34.73]) by col0-omc2-s7.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 28 Oct 2011 11:07:20 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_eee32fd6-09b7-405b-ace5-eb87c17e271a_" X-Originating-IP: [117.136.0.107] From: Hui Deng To: Date: Sat, 29 Oct 2011 02:07:20 +0800 Importance: Normal In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3032A71C3@XMB-RCD-109.cisco.com> References: <4EAAA9FE.9030600@innovationslab.net> , <5B6B2B64C9FE2A489045EEEADDAFF2C3032A71C3@XMB-RCD-109.cisco.com> MIME-Version: 1.0 X-OriginalArrivalTime: 28 Oct 2011 18:07:20.0852 (UTC) FILETIME=[6FB5BD40:01CC959C] Subject: [mif] FW: Review requested: draft-ietf-mif-dhcpv6-route-option X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 18:07:22 -0000 --_eee32fd6-09b7-405b-ace5-eb87c17e271a_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit Just want to remind that there is on-going review in 6MAN for this draft. thanks -Hui > Date: Fri, 28 Oct 2011 12:58:06 -0500 > From: shemant@cisco.com > To: wbeebee@cisco.com; brian@innovationslab.net; ipv6@ietf.org > CC: 6man-ads@tools.ietf.org; bob.hinden@gmail.com; mif-chairs@tools.ietf.org > Subject: RE: Review requested: draft-ietf-mif-dhcpv6-route-option > > This is precisely the question that I and Bernie Volz asked a year or > two back. Similarly when it was discussed to add a DNS option to the > IPv6 ND RA when the DNS option was already supported by DHCPv6. The > question was if the receiving node gets the same information from two > different sources, which information wins? What if one information was > fat-fingered at the SP provisioning system while the other was not? We > should look at the RFC that added the DNS option to the RA and see if > that RFC has a section regarding this question and we could copy that > guidance. > > Hemant > > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Wes Beebee (wbeebee) > Sent: Friday, October 28, 2011 1:52 PM > To: Brian Haberman; IPv6 WG Mailing List > Cc: 6man-ads@tools.ietf.org; Bob Hinden; mif-chairs@tools.ietf.org > Subject: Re: Review requested: draft-ietf-mif-dhcpv6-route-option > > What happens when both RA and DHCPv6 are configured? > > - Wes > > On 10/28/11 9:11 AM, "Brian Haberman" wrote: > > > All, > > The MIF WG is currently defining a DHCPv6 option for defining > > routes (including default routes) on client nodes. Please review the > > draft and provide any feedback you have. > > > > http://tools.ietf.org/html/draft-ietf-mif-dhcpv6-route-option-03 > > > > Regards, > > Brian > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --_eee32fd6-09b7-405b-ace5-eb87c17e271a_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit
Just want to remind that there is on-going review in 6MAN for this draft.
 
thanks
 
-Hui
 
> Date: Fri, 28 Oct 2011 12:58:06 -0500
> From: shemant@cisco.com
> To: wbeebee@cisco.com; brian@innovationslab.net; ipv6@ietf.org
> CC: 6man-ads@tools.ietf.org; bob.hinden@gmail.com; mif-chairs@tools.ietf.org
> Subject: RE: Review requested: draft-ietf-mif-dhcpv6-route-option
>
> This is precisely the question that I and Bernie Volz asked a year or
> two back. Similarly when it was discussed to add a DNS option to the
> IPv6 ND RA when the DNS option was already supported by DHCPv6. The
> question was if the receiving node gets the same information from two
> different sources, which information wins? What if one information was
> fat-fingered at the SP provisioning system while the other was not? We
> should look at the RFC that added the DNS option to the RA and see if
> that RFC has a section regarding this question and we could copy that
> guidance.
>
> Hemant
>
> -----Original Message-----
> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of
> Wes Beebee (wbeebee)
> Sent: Friday, October 28, 2011 1:52 PM
> To: Brian Haberman; IPv6 WG Mailing List
> Cc: 6man-ads@tools.ietf.org; Bob Hinden; mif-chairs@tools.ietf.org
> Subject: Re: Review requested: draft-ietf-mif-dhcpv6-route-option
>
> What happens when both RA and DHCPv6 are configured?
>
> - Wes
>
> On 10/28/11 9:11 AM, "Brian Haberman" <brian@innovationslab.net> wrote:
>
> > All,
> > The MIF WG is currently defining a DHCPv6 option for defining
> > routes (including default routes) on client nodes. Please review the
> > draft and provide any feedback you have.
> >
> > http://tools.ietf.org/html/draft-ietf-mif-dhcpv6-route-option-03
> >
> > Regards,
> > Brian
> > ---------------- ----------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
--_eee32fd6-09b7-405b-ace5-eb87c17e271a_-- From alexandru.petrescu@gmail.com Fri Oct 28 12:04:48 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 433A721F8515 for ; Fri, 28 Oct 2011 12:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LrEbnhyrbVdl for ; Fri, 28 Oct 2011 12:04:47 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1CDEB21F8509 for ; Fri, 28 Oct 2011 12:04:46 -0700 (PDT) Received: by wwe6 with SMTP id 6so4441070wwe.13 for ; Fri, 28 Oct 2011 12:04:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=fIDsWcocgIdVw4+/VW/7dben6Cdkt/iV2TsYSAy7g8s=; b=wpYNgJYjEMmWG5pWI2JOh2BtxUmBCcSxBdDDQXTVbJTi+cIOkAVXOUsU84pQrNwmJo ByFQNcvrK0CQ2S7qklmQNzblV/6CkAEl0cKi4ClA638QcimmbJrRjxOaLa0h/OMVKyQq tAX7CMmTrkvL7nDFttcwQUxcjNSm930aUfgB4= Received: by 10.227.204.135 with SMTP id fm7mr5511860wbb.2.1319828686135; Fri, 28 Oct 2011 12:04:46 -0700 (PDT) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net. [82.239.213.32]) by mx.google.com with ESMTPS id gg13sm17180403wbb.8.2011.10.28.12.04.44 (version=SSLv3 cipher=OTHER); Fri, 28 Oct 2011 12:04:45 -0700 (PDT) Message-ID: <4EAAFCC9.20508@gmail.com> Date: Fri, 28 Oct 2011 21:04:41 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Tomasz Mrugalski References: <4EAAB63F.3030808@gmail.com> <4EAAEB8B.6050005@gmail.com> In-Reply-To: <4EAAEB8B.6050005@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: mif@ietf.org Subject: Re: [mif] Option size for lifetimed default route: route-option vs drlo X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 19:04:48 -0000 Le 28/10/2011 19:51, Tomasz Mrugalski a écrit : > On 28.10.2011 16:03, Alexandru Petrescu wrote: >> DHCP to communicate a default route with lifetime, to Client: >> >> - with route-option, the option size is: 48bytes. > > Not true. You can convey default route information using just > NEXT_HOP option, which is 20 octets actually. Yes, if one wants to convey solely the IPv6 address . Correct me if I'm wrong, but if one wants to add the lifetime (Subject says "lifetimed default route") then the size is 48bytes. Even though the size of the lifetime field could be very small (2 or 4bytes), the fact that this lifetime is encoded as part of OPTION_RT_PREFIX it adds many other unnecessary fields (type, option-len, Prefix-len, Metric, Prefix) - Figure 2 of route-option: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_RT_PREFIX | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Route lifetime | +-------------------------------+-------------------------------+ | Prefix-Length | Metric | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Prefix | | (16 octets) | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . RT_PREFIX options . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Please read section 3.1, paragraphs 2 and 3 (discussion about > bandwidth limited cases) Yes, section 3.1 says: > In bandwidth constrained networks, server MAY send NEXT_HOP option > without any RT_PREFIX options. Right, the RT_PREFIX options part of the OPTION_RT_PREFIX is eliminated and this is already reduction of encoding space compared to the earlier version of route-option draft. But if one needs to convey lifetime to this default route then one is forced to include the OPTION_RT_PREFIX option (even though the RT_PREFIX options is absent) - am I wrong? > and section 4.1 of route-option-03. Yes, section 4.1 tells how the IPv6 address and prefix are conveyed. Prefix can indeed be removed by this draft (it is "0"). But if one wants to convey the lifetime then the OPTIONS_RT_PREFIX must be included, no? > I'd like to remind you that this paragraph was added specifically to > address your concerns about bandwidth limitations. Yes, and thank you for that addition. When I noticed that addition I was happy that my comment was taken into account. However, it was added without consulting me. If I were to be consulted then I would have recommended a different way of doing it, as it is done in the drlo draft. >> - with drlo, the option size is: 28bytes. > > I take your word for it. I read that draft a long a ago. Thank you for having read it. It has not changed since then. The DRLO encoding is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_DEFAULT_ROUTER_LIST | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | router_address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | router_lifetime | lla_len | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . router_link_layer_address(opt) . . ... . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > As you see, route-option is more flexible (supports specific routes > and a default route) and it can be more efficient if you need it. It is extensible yes, but not such that small messages can be conveyed. > While I acknowledge that your specific use case exists, you must > also acknowledge that not every use case is exactly like yours. I acknowledge that not every use-case is like this. The single specific use case that I am referring to may mean a much larger number of devices than those considered by all other numerous use case taken all together. I am referring to the single specific use-case of: Low-cost devices in Machine-to-Machine communications in LTE future generation systems. > I see that you are trying to find one specific very narrow metric > and use that to point out that one solution is better than another. > Please don't assume that if you need something, everyone else needs > it as well. Well I don't assume so. But I do appreciate default route different than specific routes: e.g. it is the only route needed by simplest devices, the prefix is "0", the metric is 1, the lifetime is like 9000 and the MAC address could optionally help. This one specific case can happen on a very large number of devices. It is like the 80-20 rule: optimize the cases which risk happening most of the time. > Have a nice weekend, Tomek Thanks for the reply and have a nice long weekend :-) Alex > _______________________________________________ mif mailing list > mif@ietf.org https://www.ietf.org/mailman/listinfo/mif From denghui02@gmail.com Sat Oct 29 08:22:00 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68C1021F84E1; Sat, 29 Oct 2011 08:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.519 X-Spam-Level: X-Spam-Status: No, score=-103.519 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7VoAFDfYZMow; Sat, 29 Oct 2011 08:21:59 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 33B1021F84ED; Sat, 29 Oct 2011 08:21:59 -0700 (PDT) Received: by wyh22 with SMTP id 22so5607231wyh.31 for ; Sat, 29 Oct 2011 08:21:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=eQyHDfbAYbaFgn52oKaaVai2hphGaRXROGBPtYxC7jk=; b=wifIt0t2HYAP7OvMro3BRySA4x6LIj46KFsEcNYPzxkt9QE8D2I1U5x3WH0iGVcPDo 982KqkEKPY8lRWjT2EKZbDRE3uRvr3ITp2B/4OU6TBDfP6MCBMPqfU5Rq8htc1UA6RjQ BeS6UC9fEUotrF3E/IAs4BeIFnS+9t1HI7TSQ= MIME-Version: 1.0 Received: by 10.216.221.145 with SMTP id r17mr304426wep.65.1319901711487; Sat, 29 Oct 2011 08:21:51 -0700 (PDT) Received: by 10.216.82.199 with HTTP; Sat, 29 Oct 2011 08:21:51 -0700 (PDT) Date: Sat, 29 Oct 2011 23:21:51 +0800 Message-ID: From: Hui Deng To: MIF Mailing List , Margaret Wasserman , dhc WG , ipv6@ietf.org Content-Type: multipart/alternative; boundary=0016e65ae75aa6d33e04b071901a Subject: [mif] Last Call for draft-ietf-mif-dhcpv6-route-option-03 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2011 15:22:00 -0000 --0016e65ae75aa6d33e04b071901a Content-Type: text/plain; charset=ISO-8859-1 Hello all >From the MIF mailing list, chairs have observed that most issues raised for the document have been sufficiently discussed. Based on the current mif milestone, we are issueing working group last call for the document: http://tools.ietf.org/html/draft-ietf-mif-dhcpv6-route-option-03 This is a 2 week LC, it will finish on Nov. 12, we are cc this LC to DHC and 6MAN working group. Please kindly help to send substantive review and editorial comments to mif@ietf.org, thanks, Margaret and Hui Based on 1st round WG LC, the authors have received significant advice about revision and submited a new version accordingly: http://www.ietf.org/internet-drafts/draft-ietf-mif-dns-server-selection-05.txt And we plan to issue a second round WG LC, and cc to DHCWG, DNSEXT, DNSOP related working groups, please DNSEXT/DNSOP chairs help to forward to the MLs since I may not subscribe to them. This is a 2 weeks with little extension LC, it will finish on October 17, Please send substantive review and editorial comments to mif@ietf.org Thanks a lot for youre view Best regards, Margaret and Hui --0016e65ae75aa6d33e04b071901a Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
H= ello all
 
From the MIF mailing list, chairs have observed that most issues r= aised for the document  have been sufficiently discussed.<= /span>
<= span style=3D"FONT-FAMILY: 'Tahoma','sans-serif'; FONT-SIZE= : 10pt; mso-fareast-font-family: =CB=CE=CC=E5; mso-ansi-language: EN-US; ms= o-fareast-language: ZH-CN; mso-bidi-language: AR-SA" lang=3D"EN-US">=  
<= span style=3D"FONT-FAMILY: 'Tahoma','sans-serif'; FONT-SIZE= : 10pt; mso-fareast-font-family: =CB=CE=CC=E5; mso-ansi-language: EN-US; ms= o-fareast-language: ZH-CN; mso-bidi-language: AR-SA" lang=3D"EN-US">Based o= n the current mif milestone, we are issueing working group last call for th= e document:
http://tools.ietf.org/html/draft-ietf-mif-dhcpv6-route-option-03
&= nbsp;
This is a 2 week LC, it will finish on Nov. 12, we are cc this LC = to DHC and 6MAN working group.
Please kindly help to send substantive review and editorial comme= nts to mif@ietf.org, 
&nbs= p;
thanks,
 
Margaret and Hui
 
B= ased on 1st round WG LC, the authors have received significant advice about= revision and submited a new version accordingly:
http://www.ietf.org/internet-drafts/draft-ietf-mif-dns-serv= er-selection-05.txt
 
And we plan to issue a second rou= nd WG LC, and cc to DHCWG, DNSEXT, DNSOP related working groups, please DNS= EXT/DNSOP chairs help to forward to the MLs since I may not subscribe to th= em.
 
This is a 2 weeks with little extension LC, it will finish o= n October 17,
Please send substantive review and editorial comments= to mif@ietf.org
 
Thanks a = lot for youre view
Best regards,
 
Margaret and Hui
--0016e65ae75aa6d33e04b071901a-- From denghui02@gmail.com Sat Oct 29 08:32:33 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6DB221F8753; Sat, 29 Oct 2011 08:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.546 X-Spam-Level: X-Spam-Status: No, score=-103.546 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Oj-W7BUHs8j; Sat, 29 Oct 2011 08:32:33 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 6EFA221F8677; Sat, 29 Oct 2011 08:32:32 -0700 (PDT) Received: by wwf22 with SMTP id 22so327226wwf.1 for ; Sat, 29 Oct 2011 08:32:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=ymJu0SwXKkoW7GhlCu4mPbaXNeKy2XFxG7HxHv5CVm8=; b=xPg0suIkrTN1LrSlZhAGdhoZESTMAcbUVbekpcqf6b7Th6vP1ympLIAOXrky3WH9PT Fjq6iJ9pSJx3TXHgp9XDR2GPL/y9YmrQQT5Rronotwem9zvlC3lVJJX1l8DLoJL10fH6 I+dmUXXAC+O5DrQSNKtoKXHTuiB0z+oJlMiLw= MIME-Version: 1.0 Received: by 10.216.4.207 with SMTP id 57mr2227511wej.110.1319902350022; Sat, 29 Oct 2011 08:32:30 -0700 (PDT) Received: by 10.216.82.199 with HTTP; Sat, 29 Oct 2011 08:32:29 -0700 (PDT) In-Reply-To: References: Date: Sat, 29 Oct 2011 23:32:29 +0800 Message-ID: From: Hui Deng To: MIF Mailing List , Margaret Wasserman , dhc WG , ipv6@ietf.org Content-Type: multipart/alternative; boundary=001485f85edab6176f04b071b6c7 Subject: Re: [mif] Last Call for draft-ietf-mif-dhcpv6-route-option-03 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2011 15:32:34 -0000 --001485f85edab6176f04b071b6c7 Content-Type: text/plain; charset=ISO-8859-1 Excuse me for copy and pasting mistake, please remove the below part. thanks -Hui Hello all > > From the MIF mailing list, chairs have observed that most issues raised for > the document have been sufficiently discussed. > > Based on the current mif milestone, we are issueing working group last call > for the document: > http://tools.ietf.org/html/draft-ietf-mif-dhcpv6-route-option-03 > > This is a 2 week LC, it will finish on Nov. 12, we are cc this LC to DHC > and 6MAN working group. > Please kindly help to send substantive review and editorial comments to > mif@ietf.org, > > thanks, > > Margaret and Hui > --001485f85edab6176f04b071b6c7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Excuse me for copy and pasting mistake, please remove the below part.<= /div>
=A0
thanks
=A0
-Hui

Hello=A0all
=A0
<= span style=3D"FONT-SIZE: 10pt" lang=3D"EN-US">From the MIF mailing list, ch= airs=A0have observed that most issues raised for the document=A0=A0have bee= n sufficiently discussed.
=A0
Based on the current mif milestone, we are issueing= working group last call for the document:
http://to= ols.ietf.org/html/draft-ietf-mif-dhcpv6-route-option-03
=A0
This is a 2 week LC, it will finish on Nov. 12, we are cc this LC to= DHC and 6MAN working group.
Please kindly help to=A0send substantive re= view and editorial=A0comments=A0to mif@ietf.org,=A0
=A0
thanks,
=A0
Margaret and Hui<= br>
--001485f85edab6176f04b071b6c7-- From denghui02@gmail.com Sun Oct 30 09:24:09 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A59A21F8B34 for ; Sun, 30 Oct 2011 09:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.567 X-Spam-Level: X-Spam-Status: No, score=-103.567 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id icOXtcvWxpC2 for ; Sun, 30 Oct 2011 09:24:09 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id CEF0421F8B19 for ; Sun, 30 Oct 2011 09:24:08 -0700 (PDT) Received: by wwi36 with SMTP id 36so301305wwi.13 for ; Sun, 30 Oct 2011 09:24:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=klWyYwJcVPoK1u5kWvUMJx8jbjaqrryJv8N3J+Odzug=; b=id199zwtcTuElfSGmJ14SsGH6EvxVSXbatSzaAoU7suJZuKBrnd1M/sKeJuZZZ+sDp iTCUirLcNFlbl2U50Nh4BLQKjjEtID6ffEBmiHlBHM9zQdfjisvSZNOgYH1h+evgi6eR 27QyzjiZqAebWGzhn9MiNijvUJ3Eb1UcB+HUA= MIME-Version: 1.0 Received: by 10.216.205.159 with SMTP id j31mr3259163weo.80.1319991844119; Sun, 30 Oct 2011 09:24:04 -0700 (PDT) Received: by 10.216.22.137 with HTTP; Sun, 30 Oct 2011 09:24:04 -0700 (PDT) Date: Mon, 31 Oct 2011 00:24:04 +0800 Message-ID: From: Hui Deng To: MIF Mailing List , Margaret Wasserman Content-Type: multipart/alternative; boundary=0016e6dd8a2ef9a5ab04b0868c55 Subject: [mif] Call for Agenda X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 16:24:09 -0000 --0016e6dd8a2ef9a5ab04b0868c55 Content-Type: text/plain; charset=ISO-8859-1 Hello all Please feel free to chairs know if you need a time slot in the coming IETF Taipei MIF wg meeting. thanks a lot -Chairs --0016e6dd8a2ef9a5ab04b0868c55 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello all
=A0
Please feel free to chairs know if you need a time slot in the coming = IETF Taipei MIF wg meeting.
thanks a lot
=A0
-Chairs
--0016e6dd8a2ef9a5ab04b0868c55-- From alexandru.petrescu@gmail.com Sun Oct 30 10:03:03 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0685221F8B20 for ; Sun, 30 Oct 2011 10:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.028 X-Spam-Level: X-Spam-Status: No, score=-1.028 tagged_above=-999 required=5 tests=[AWL=-0.857, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PD6VaWs9dNLq for ; Sun, 30 Oct 2011 10:03:02 -0700 (PDT) Received: from smtp1-g21.free.fr (unknown [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 2869B21F8B19 for ; Sun, 30 Oct 2011 10:03:00 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 92CAC940292 for ; Sun, 30 Oct 2011 18:02:55 +0100 (CET) Message-ID: <4EAD833E.1020204@gmail.com> Date: Sun, 30 Oct 2011 18:02:54 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: mif@ietf.org References: <4EAAA9FE.9030600@innovationslab.net> , <5B6B2B64C9FE2A489045EEEADDAFF2C3032A71C3@XMB-RCD-109.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 111030-0, 30/10/2011), Outbound message X-Antivirus-Status: Clean Subject: Re: [mif] FW: Review requested: draft-ietf-mif-dhcpv6-route-option X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 17:03:03 -0000 Le 28/10/2011 20:07, Hui Deng a écrit : > Just want to remind that there is on-going review in 6MAN for this > draft. Thanks for the pointer. I have posted separately to 6man on this topic. The question one raised on 6man is about coexistence with RA about default route. One is aware that a similar situation (alternate mechanism DHCP-vs-RA for default route) appeared recently when DNS-in-RA was proposed (DHCP existed doing DNS). RFC6106 proposes to do DNS-in-RA but has a section explaining coexistence with DHCP about DNS address - and gives the latter precedence over. Additionally, the same issue may be raised about co-existence with routing protocols. Currently, the route-option draft says that DHCP-route-option should not be used when dynamic routing protocols are used (section 3.6 Limitations). This is one particular way of building co-existence. In some cases this recommendation may be inappropriate - there may exist cases where routing protocol software _and_ DHCP software should be used on the same machine (e.g. use DHCP to get DNS address, and use OSPF to do routing). At that point it may be hard to prevent some particular option of DHCP (route-option) being physically available on the machine. Accidentally misconfiguration may happen. Another way would be to recommend that all data be in some list, and if conflict arises precedence be given to some data over other. This is of course debatable. (In the past I have myself preferred to recommend to use mechanisms in an alternative manner, rather than keeping prioritized lists.) Alex > > thanks > > -Hui > >> Date: Fri, 28 Oct 2011 12:58:06 -0500 From: shemant@cisco.com To: >> wbeebee@cisco.com; brian@innovationslab.net; ipv6@ietf.org CC: >> 6man-ads@tools.ietf.org; bob.hinden@gmail.com; > mif-chairs@tools.ietf.org >> Subject: RE: Review requested: draft-ietf-mif-dhcpv6-route-option >> >> This is precisely the question that I and Bernie Volz asked a year >> or two back. Similarly when it was discussed to add a DNS option to >> the IPv6 ND RA when the DNS option was already supported by DHCPv6. >> The question was if the receiving node gets the same information >> from two different sources, which information wins? What if one >> information was fat-fingered at the SP provisioning system while >> the other was not? We should look at the RFC that added the DNS >> option to the RA and see if that RFC has a section regarding this >> question and we could copy that guidance. >> >> Hemant >> >> -----Original Message----- From: ipv6-bounces@ietf.org >> [mailto:ipv6-bounces@ietf.org] On Behalf Of Wes Beebee (wbeebee) >> Sent: Friday, October 28, 2011 1:52 PM To: Brian Haberman; IPv6 WG >> Mailing List Cc: 6man-ads@tools.ietf.org; Bob Hinden; >> mif-chairs@tools.ietf.org Subject: Re: Review requested: >> draft-ietf-mif-dhcpv6-route-option >> >> What happens when both RA and DHCPv6 are configured? >> >> - Wes >> >> On 10/28/11 9:11 AM, "Brian Haberman" >> wrote: >> >>> All, The MIF WG is currently defining a DHCPv6 option for >>> defining routes (including default routes) on client nodes. >>> Please review the draft and provide any feedback you have. >>> >>> http://tools.ietf.org/html/draft-ietf-mif-dhcpv6-route-option-03 >>> >>> Regards, Brian ---------------- >>> ---------------------------------------------------- IETF IPv6 >>> working group mailing list ipv6@ietf.org Administrative Requests: >>> https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- > >>> > >> -------------------------------------------------------------------- > >> > IETF IPv6 working group mailing list >> ipv6@ietf.org Administrative Requests: >> https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > >> > > _______________________________________________ mif mailing list > mif@ietf.org https://www.ietf.org/mailman/listinfo/mif From Ted.Lemon@nominum.com Sun Oct 30 10:24:54 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31F6A21F8AF8 for ; Sun, 30 Oct 2011 10:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.536 X-Spam-Level: X-Spam-Status: No, score=-106.536 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXa0eDtWgMr7 for ; Sun, 30 Oct 2011 10:24:53 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 41D9921F8AEA for ; Sun, 30 Oct 2011 10:24:52 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP; Sun, 30 Oct 2011 10:24:53 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 975991B826E for ; Sun, 30 Oct 2011 10:24:36 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 7D912190052; Sun, 30 Oct 2011 10:24:36 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.01.0323.003; Sun, 30 Oct 2011 10:24:36 -0700 From: Ted Lemon To: Alexandru Petrescu Thread-Topic: [mif] Review requested: draft-ietf-mif-dhcpv6-route-option Thread-Index: AQHMlyjLV0Xly0s/BU2jY2wI85ydQQ== Date: Sun, 30 Oct 2011 17:24:35 +0000 Message-ID: References: <4EAAA9FE.9030600@innovationslab.net> , <5B6B2B64C9FE2A489045EEEADDAFF2C3032A71C3@XMB-RCD-109.cisco.com> <4EAD833E.1020204@gmail.com> In-Reply-To: <4EAD833E.1020204@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_A28D1C9D022748E8A9B0EDB769AFD5AAnominumcom_" MIME-Version: 1.0 Cc: "" Subject: Re: [mif] Review requested: draft-ietf-mif-dhcpv6-route-option X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 17:24:54 -0000 --_000_A28D1C9D022748E8A9B0EDB769AFD5AAnominumcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Oct 30, 2011, at 1:02 PM, Alexandru Petrescu wrote: The question one raised on 6man is about coexistence with RA about default route. One is aware that a similar situation (alternate mechanism DHCP-vs-RA for default route) appeared recently when DNS-in-RA was proposed (DHCP existed doing DNS). RFC6106 proposes to do DNS-in-RA but has a section explaining coexistence with DHCP about DNS address - and gives the latter precedence over. This is a very good point, which should be addressed in the route option dr= aft. I think the right thing is to give RA precedence over DHCP for routi= ng information, but am curious to know if others disagree. In some cases this recommendation may be inappropriate - there may exist cases where routing protocol software _and_ DHCP software should be used on the same machine (e.g. use DHCP to get DNS address, and use OSPF to do routing). At that point it may be hard to prevent some particular option of DHCP (route-option) being physically available on the machine. Accidentally misconfiguration may happen. Fortunately, this is not a very serious problem: the router and the DHCP se= rver are both under control of the administrator, so they can simply config= ure them correctly, and the right thing will happen. It is always possibl= e, if the network administrator sets things up wrong, for the network to no= t work, and there is nothing the IETF can do to eliminate this risk. Sinc= e the default case is for the network administrator not to configure DHCP, = I think it's pretty safe to assume that we won't get a bad route configurat= ion without some kind of positive action on the part of the administrator. --_000_A28D1C9D022748E8A9B0EDB769AFD5AAnominumcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <1D7E7102F973804B9574BF1463B3CD8D@nominum.com> Content-Transfer-Encoding: quoted-printable
On Oct 30, 2011, at 1:02 PM, Alexandru Petrescu wrote:
The question one raised on 6man is about coexiste= nce with RA about
default route.  One is aware that a similar situation (alternate
mechanism DHCP-vs-RA for default route) appeared recently when DNS-in-RA was proposed (DHCP existed doing DNS).  RFC6106 proposes to  do DNS-in-RA but has a section explaining coexistence with DHCP about DNS
address - and gives the latter precedence over.

This is a very good point, which should be addressed in the route opti= on draft.   I think the right thing is to give RA precedence over DHCP= for routing information, but am curious to know if others disagree.

In some cases this recommendation may be inappropriate - there may exist
cases where routing protocol software _and_ DHCP software should be used on the same machine (e.g. use DHCP to get DNS address, and use OSPF to
do routing).  At that point it may be hard to prevent some particular<= br> option of DHCP (route-option) being physically available on the machine. Accidentally misconfiguration may happen.

Fortunately, this is not a very serious problem: the router and the DH= CP server are both under control of the administrator, so they can simply c= onfigure them correctly, and the right thing will happen.   It is alwa= ys possible, if the network administrator sets things up wrong, for the network to not work, and there is nothing th= e IETF can do to eliminate this risk.   Since the default case is for = the network administrator not to configure DHCP, I think it's pretty safe t= o assume that we won't get a bad route configuration without some kind of positive action on the part of the admi= nistrator.

--_000_A28D1C9D022748E8A9B0EDB769AFD5AAnominumcom_-- From brian.e.carpenter@gmail.com Sun Oct 30 13:35:07 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9E6921F8B80 for ; Sun, 30 Oct 2011 13:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.224 X-Spam-Level: X-Spam-Status: No, score=-103.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WwuhwX9YRB6s for ; Sun, 30 Oct 2011 13:35:07 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 140B821F850B for ; Sun, 30 Oct 2011 13:35:07 -0700 (PDT) Received: by iabn5 with SMTP id n5so8103317iab.31 for ; Sun, 30 Oct 2011 13:35:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=YlUHn+b3LEZ7Y5onMOVhx82P9p7I6ECSCFPTF3ZsEeg=; b=ZHHIyPDmwe/eQJLNlkmxxaL21qrpv1/PnvikBDnvXwgE5Ri3rjejLqgCJcYLwf+5wu XHrIj+g5wCUlKMs8mdTfxUyjiIQCW2E9+NWhQ8X8Cb/rHnzY20jdrZdAONyyGeUbBIOy OQpJU2bUCWeunDQDIG04CYkbkVCS/dajqnBos= Received: by 10.68.32.2 with SMTP id e2mr18592684pbi.68.1320006906521; Sun, 30 Oct 2011 13:35:06 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id d9sm44113986pbb.13.2011.10.30.13.35.03 (version=SSLv3 cipher=OTHER); Sun, 30 Oct 2011 13:35:05 -0700 (PDT) Message-ID: <4EADB4F5.3030804@gmail.com> Date: Mon, 31 Oct 2011 09:35:01 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ted Lemon References: <4EAAA9FE.9030600@innovationslab.net> , <5B6B2B64C9FE2A489045EEEADDAFF2C3032A71C3@XMB-RCD-109.cisco.com> <4EAD833E.1020204@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "" Subject: [mif] RA vs DHCPv6 config (was Review requested: draft-ietf-mif-dhcpv6-route-option) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 20:35:07 -0000 Ted, On 2011-10-31 06:24, Ted Lemon wrote: > On Oct 30, 2011, at 1:02 PM, Alexandru Petrescu wrote: > The question one raised on 6man is about coexistence with RA about > default route. One is aware that a similar situation (alternate > mechanism DHCP-vs-RA for default route) appeared recently when DNS-in-RA > was proposed (DHCP existed doing DNS). RFC6106 proposes to do > DNS-in-RA but has a section explaining coexistence with DHCP about DNS > address - and gives the latter precedence over. > > This is a very good point, which should be addressed in the route option draft. I think the right thing is to give RA precedence over DHCP for routing information, but am curious to know if others disagree. It makes my head hurt a bit to give RA config priority in one context and DHCPv6 config priority in another context. I think this point requires a wider discussion; you could find opinions about this in (at least) 6man, v6ops, homenet, and 6renum. > In some cases this recommendation may be inappropriate - there may exist > cases where routing protocol software _and_ DHCP software should be used > on the same machine (e.g. use DHCP to get DNS address, and use OSPF to > do routing). At that point it may be hard to prevent some particular > option of DHCP (route-option) being physically available on the machine. > Accidentally misconfiguration may happen. > > Fortunately, this is not a very serious problem: the router and the DHCP server are both under control of the administrator, so they can simply configure them correctly, and the right thing will happen. It is always possible, if the network administrator sets things up wrong, for the network to not work, and there is nothing the IETF can do to eliminate this risk. Since the default case is for the network administrator not to configure DHCP, I think it's pretty safe to assume that we won't get a bad route configuration without some kind of positive action on the part of the administrator. Not necessarily, if you think about out-of-the box default behaviour when someone hooks a few boxes together in an unmanaged network. That's why I have a feeling that "in case of conflict, DHVPv6 always wins" may turn out to be the right answer. Brian From Ted.Lemon@nominum.com Sun Oct 30 14:38:40 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A446821F8B98 for ; Sun, 30 Oct 2011 14:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.238 X-Spam-Level: X-Spam-Status: No, score=-106.238 tagged_above=-999 required=5 tests=[AWL=-0.239, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZYheS14BOqJ for ; Sun, 30 Oct 2011 14:38:40 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id D6E0D21F8B84 for ; Sun, 30 Oct 2011 14:38:39 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP; Sun, 30 Oct 2011 14:38:39 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 0BD351B824F for ; Sun, 30 Oct 2011 14:38:19 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 714F9190052; Sun, 30 Oct 2011 14:38:16 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.01.0323.003; Sun, 30 Oct 2011 14:38:16 -0700 From: Ted Lemon To: Brian E Carpenter Thread-Topic: RA vs DHCPv6 config (was Review requested: draft-ietf-mif-dhcpv6-route-option) Thread-Index: AQHMl0NqObKG560zMkGTar0EyAgE6pWVae/K Date: Sun, 30 Oct 2011 21:38:15 +0000 Message-ID: <091A2980-DC47-403E-BDF9-96EC955815C5@nominum.com> References: <4EAAA9FE.9030600@innovationslab.net> , <5B6B2B64C9FE2A489045EEEADDAFF2C3032A71C3@XMB-RCD-109.cisco.com> <4EAD833E.1020204@gmail.com> , <4EADB4F5.3030804@gmail.com> In-Reply-To: <4EADB4F5.3030804@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [mif] RA vs DHCPv6 config (was Review requested: draft-ietf-mif-dhcpv6-route-option) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 21:38:40 -0000 On Oct 30, 2011, at 4:35 PM, "Brian E Carpenter" wrote: > It makes my head hurt a bit to give RA config priority in one context and > DHCPv6 config priority in another context. I think this point requires > a wider discussion; you could find opinions about this in (at least) > 6man, v6ops, homenet, and 6renum. I really don't see how we can manage that. That's five different mailing = lists, not even counting the DHC mailing list. The way I deal with this i= s to be on all those mailing lists. As for your head hurting, you have my sympathy. In reality, I think that = if DHCP and RA disagree, that is a configuration error, and so it doesn't p= articularly matter which one is given priority. They should agree. > Not necessarily, if you think about out-of-the box default behaviour > when someone hooks a few boxes together in an unmanaged network. That's w= hy > I have a feeling that "in case of conflict, DHVPv6 always wins" may turn = out > to be the right answer. In this case, I would expect there to be no DHCP server. Or if the homene= t group decides that DHCP needs to work in this case, based on prefix deleg= ation, then I would argue that DHCP should not automatically configure itse= lf to provide a default route, since the default route ought to appear in t= he RA anyway. But again, in this situation, even if homenet decides that = DHCP should send a default route, the default route it sends should agree w= ith the one sent in the RA. If you are thinking of a bridged situation, homenet seems to have concluded= that that's not the right thing to do anyway. In a bridged environment, i= f more than one device tries to be the source of truth, it's pretty much a = given that it's simply not going to work.= From tomasz.mrugalski@gmail.com Mon Oct 31 04:06:11 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D49B321F8D0F for ; Mon, 31 Oct 2011 04:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIm1yV2HP2PK for ; Mon, 31 Oct 2011 04:06:11 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id D017121F8C61 for ; Mon, 31 Oct 2011 04:06:10 -0700 (PDT) Received: by wwi36 with SMTP id 36so814882wwi.13 for ; Mon, 31 Oct 2011 04:06:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-tagtoolbar-keys:content-type :content-transfer-encoding; bh=ozPYW/s5cm4b1rbY897RH1bG3M7fJzyQxFZUDOPp/b8=; b=w0TPsN9wbkpPSviZ4S9HIa5jQTYOYE9jGuTFEBMkPEvDVBz02E2HFOPAXY5Uys7YPp 6/wRWGryC17U+yAp7OdsiOl08/RKNoHGM9ZLHlEu42i90Ey8A8XqmX8Rf+RqH8QN4eqX 1BpkjjcWZrnOuDiuy5WNgE18inyUDDf31U5YM= Received: by 10.216.229.223 with SMTP id h73mr4126775weq.79.1320059169960; Mon, 31 Oct 2011 04:06:09 -0700 (PDT) Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPS id ff6sm31779971wbb.10.2011.10.31.04.06.06 (version=SSLv3 cipher=OTHER); Mon, 31 Oct 2011 04:06:08 -0700 (PDT) Message-ID: <4EAE811A.1030005@gmail.com> Date: Mon, 31 Oct 2011 12:06:02 +0100 From: Tomasz Mrugalski User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: Ted Lemon References: <4EAAA9FE.9030600@innovationslab.net> , <5B6B2B64C9FE2A489045EEEADDAFF2C3032A71C3@XMB-RCD-109.cisco.com> <4EAD833E.1020204@gmail.com> , <4EADB4F5.3030804@gmail.com> <091A2980-DC47-403E-BDF9-96EC955815C5@nominum.com> In-Reply-To: <091A2980-DC47-403E-BDF9-96EC955815C5@nominum.com> X-TagToolbar-Keys: D20111031120602446 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [mif] RA vs DHCPv6 config (was Review requested: draft-ietf-mif-dhcpv6-route-option) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 11:06:11 -0000 On 30.10.2011 22:38, Ted Lemon wrote: > On Oct 30, 2011, at 4:35 PM, "Brian E Carpenter" > wrote: >> It makes my head hurt a bit to give RA config priority in one >> context and DHCPv6 config priority in another context. I think this >> point requires a wider discussion; you could find opinions about >> this in (at least) 6man, v6ops, homenet, and 6renum. > > I really don't see how we can manage that. That's five different > mailing lists, not even counting the DHC mailing list. The way I > deal with this is to be on all those mailing lists. > > As for your head hurting, you have my sympathy. In reality, I think > that if DHCP and RA disagree, that is a configuration error, and so > it doesn't particularly matter which one is given priority. They > should agree. How about a different perspective on RA and DHCP disagreement? RA provides generic mechanism for all hosts in a network. DHCP allows to provision routing information on per host basis. Therefore you can deliver additional configuration to selected subset of hosts. That's why I would prefer DHCP over RA as a way to override "default" configuration. There's another aspect and I'm not sure if mentioning this will open can of worms. What about security aspect of it? While is possible to establish security relationship between DHCP server and clients, I'm not aware of any such mechanism for RA. (There's SEND, but that is a different matter. My understanding is that we are talking about "plain" RA). I would propose to favor DHCP over RA, because it may be less prone to attacks. I admit that this may be very strong or very weak (almost nobody uses security in DHCPv6 nowadays) argument, depending on which perspective you take on it. Brian, Thanks for pointers to other groups. Unfortunately, due to other obligations I'm unable to handle additional traffic. I will, occasionally, keep checking out occasionally what is happening in those groups. I'm afraid that if I asked on each group separately, I may get different answer every time. Reaching a consensus on this one may be tricky. Tomek From Ted.Lemon@nominum.com Mon Oct 31 06:30:11 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EEAD21F8C8E for ; Mon, 31 Oct 2011 06:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.53 X-Spam-Level: X-Spam-Status: No, score=-106.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id maCN56RRxXJ9 for ; Mon, 31 Oct 2011 06:30:10 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 8181A21F8C74 for ; Mon, 31 Oct 2011 06:30:10 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP; Mon, 31 Oct 2011 06:30:10 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id E10611B8252 for ; Mon, 31 Oct 2011 06:30:08 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id CB744190052; Mon, 31 Oct 2011 06:30:07 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.01.0323.003; Mon, 31 Oct 2011 06:30:08 -0700 From: Ted Lemon To: Tomasz Mrugalski Thread-Topic: [mif] RA vs DHCPv6 config (was Review requested: draft-ietf-mif-dhcpv6-route-option) Thread-Index: AQHMl0NqObKG560zMkGTar0EyAgE6pWVae/KgAFXCgD//7LpSA== Date: Mon, 31 Oct 2011 13:30:06 +0000 Message-ID: References: <4EAAA9FE.9030600@innovationslab.net> , <5B6B2B64C9FE2A489045EEEADDAFF2C3032A71C3@XMB-RCD-109.cisco.com> <4EAD833E.1020204@gmail.com> , <4EADB4F5.3030804@gmail.com> <091A2980-DC47-403E-BDF9-96EC955815C5@nominum.com>, <4EAE811A.1030005@gmail.com> In-Reply-To: <4EAE811A.1030005@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [mif] RA vs DHCPv6 config (was Review requested: draft-ietf-mif-dhcpv6-route-option) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 13:30:11 -0000 On Oct 31, 2011, at 7:06 AM, "Tomasz Mrugalski" wrote: > How about a different perspective on RA and DHCP disagreement? RA > provides generic mechanism for all hosts in a network. DHCP allows to > provision routing information on per host basis. Therefore you can > deliver additional configuration to selected subset of hosts. That's why > I would prefer DHCP over RA as a way to override "default" configuration. Yup, that's a really good point. I think this is sufficient justification = for preferring the value obtained through DHCP.=20 I will buy the security argument when I see the first successful use of DHC= P security by a naive end user... :)= From alexandru.petrescu@gmail.com Mon Oct 31 10:16:28 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E123021F8D61 for ; Mon, 31 Oct 2011 10:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.742 X-Spam-Level: X-Spam-Status: No, score=-0.742 tagged_above=-999 required=5 tests=[AWL=-0.571, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TwgxsiSxaC1Y for ; Mon, 31 Oct 2011 10:16:28 -0700 (PDT) Received: from smtp1-g21.free.fr (unknown [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id E15BA21F8CFC for ; Mon, 31 Oct 2011 10:16:26 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 700C09401E5; Mon, 31 Oct 2011 18:16:20 +0100 (CET) Message-ID: <4EAED7E1.2040506@gmail.com> Date: Mon, 31 Oct 2011 18:16:17 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Ted Lemon References: <4EAAA9FE.9030600@innovationslab.net> , <5B6B2B64C9FE2A489045EEEADDAFF2C3032A71C3@XMB-RCD-109.cisco.com> <4EAD833E.1020204@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 111031-0, 31/10/2011), Outbound message X-Antivirus-Status: Clean Cc: "" Subject: Re: [mif] Review requested: draft-ietf-mif-dhcpv6-route-option X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 17:16:29 -0000 Le 30/10/2011 18:24, Ted Lemon a écrit : > On Oct 30, 2011, at 1:02 PM, Alexandru Petrescu wrote: >> The question one raised on 6man is about coexistence with RA about >> default route. One is aware that a similar situation (alternate >> mechanism DHCP-vs-RA for default route) appeared recently when DNS-in-RA >> was proposed (DHCP existed doing DNS). RFC6106 proposes to do >> DNS-in-RA but has a section explaining coexistence with DHCP about DNS >> address - and gives the latter precedence over. > > This is a very good point, which should be addressed in the route option > draft. I think the right thing is to give RA precedence over DHCP for > routing information, but am curious to know if others disagree. I do not disagree: in the default route case, if RA offers such data then give it preference over the default route obtained from DHCP. (the preference mechanism can be specified by using the lifetime mechanism). Alex > >> In some cases this recommendation may be inappropriate - there may exist >> cases where routing protocol software _and_ DHCP software should be used >> on the same machine (e.g. use DHCP to get DNS address, and use OSPF to >> do routing). At that point it may be hard to prevent some particular >> option of DHCP (route-option) being physically available on the machine. >> Accidentally misconfiguration may happen. > > Fortunately, this is not a very serious problem: the router and the DHCP > server are both under control of the administrator, so they can simply > configure them correctly, and the right thing will happen. It is always > possible, if the network administrator sets things up wrong, for the > network to not work, and there is nothing the IETF can do to eliminate > this risk. Since the default case is for the network administrator not > to configure DHCP, I think it's pretty safe to assume that we won't get > a bad route configuration without some kind of positive action on the > part of the administrator. > From tomasz.mrugalski@gmail.com Mon Oct 31 10:38:09 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2651F0C7D for ; Mon, 31 Oct 2011 10:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HDo1DtzQ7DCC for ; Mon, 31 Oct 2011 10:38:08 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 41FD41F0C7A for ; Mon, 31 Oct 2011 10:38:08 -0700 (PDT) Received: by wyg30 with SMTP id 30so1552859wyg.31 for ; Mon, 31 Oct 2011 10:38:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-tagtoolbar-keys:content-type :content-transfer-encoding; bh=+lIBW1xMfCxjLPft8VxwtANZx5rBhtiuguPIk9kzElI=; b=hlQzeTKiN6lUUZ7S3hYM8cKBh+PB1bWiij0QJRmTgJDmPvMT0kpalQweCiNp+WaMJp 1mrM69hjZRD2G4Qyc/mIroU9uFYSfoAp1J+giqJl0Q4/DeyZtXordMAFvk/Oud/WWyiz 5sJNWSSl9CBdom5h1XaN+qrjXDHvJaSJfl4Q0= Received: by 10.216.72.65 with SMTP id s43mr4778660wed.40.1320082687467; Mon, 31 Oct 2011 10:38:07 -0700 (PDT) Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPS id e7sm33694098wbh.12.2011.10.31.10.38.05 (version=SSLv3 cipher=OTHER); Mon, 31 Oct 2011 10:38:06 -0700 (PDT) Message-ID: <4EAEDCFA.6050202@gmail.com> Date: Mon, 31 Oct 2011 18:38:02 +0100 From: Tomasz Mrugalski User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: mif@ietf.org References: <4EAAA9FE.9030600@innovationslab.net> , <5B6B2B64C9FE2A489045EEEADDAFF2C3032A71C3@XMB-RCD-109.cisco.com> <4EAD833E.1020204@gmail.com> <4EAED7E1.2040506@gmail.com> In-Reply-To: <4EAED7E1.2040506@gmail.com> X-TagToolbar-Keys: D20111031183802542 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [mif] Review requested: draft-ietf-mif-dhcpv6-route-option X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 17:38:09 -0000 On 31.10.2011 18:16, Alexandru Petrescu wrote: > Le 30/10/2011 18:24, Ted Lemon a écrit : >> On Oct 30, 2011, at 1:02 PM, Alexandru Petrescu wrote: >>> The question one raised on 6man is about coexistence with RA about >>> default route. One is aware that a similar situation (alternate >>> mechanism DHCP-vs-RA for default route) appeared recently when DNS-in-RA >>> was proposed (DHCP existed doing DNS). RFC6106 proposes to do >>> DNS-in-RA but has a section explaining coexistence with DHCP about DNS >>> address - and gives the latter precedence over. >> >> This is a very good point, which should be addressed in the route option >> draft. I think the right thing is to give RA precedence over DHCP for >> routing information, but am curious to know if others disagree. > > I do not disagree: in the default route case, if RA offers such data > then give it preference over the default route obtained from DHCP. Sorry, but I can't parse that sentence. You seem to agree with Ted (DHCP preferred over RA), but the later part of the sentence states otherwise (RA preferred over RA). > (the preference mechanism can be specified by using the lifetime > mechanism). Can you elaborate on that? What has lifetime to do with preference? Do you want to somehow prefer longer (or shorter) lifetimes? That is rather dangerous and I would like to avoid that. I believe that clear statement ("DHCP overrides RA" or "RA overrides DHCP") will help a lot here. Tomek From alexandru.petrescu@gmail.com Mon Oct 31 11:08:00 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 009B11F0CAD for ; Mon, 31 Oct 2011 11:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[AWL=-0.428, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmWG3XWJpk5B for ; Mon, 31 Oct 2011 11:07:59 -0700 (PDT) Received: from smtp1-g21.free.fr (unknown [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 2771F1F0CA8 for ; Mon, 31 Oct 2011 11:07:57 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 7BEF59401CD for ; Mon, 31 Oct 2011 19:07:52 +0100 (CET) Message-ID: <4EAEE3F5.8020605@gmail.com> Date: Mon, 31 Oct 2011 19:07:49 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: mif@ietf.org References: <4EAAA9FE.9030600@innovationslab.net> , <5B6B2B64C9FE2A489045EEEADDAFF2C3032A71C3@XMB-RCD-109.cisco.com> <4EAD833E.1020204@gmail.com> <4EAED7E1.2040506@gmail.com> <4EAEDCFA.6050202@gmail.com> In-Reply-To: <4EAEDCFA.6050202@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 111031-0, 31/10/2011), Outbound message X-Antivirus-Status: Clean Subject: Re: [mif] Review requested: draft-ietf-mif-dhcpv6-route-option X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 18:08:00 -0000 Le 31/10/2011 18:38, Tomasz Mrugalski a écrit : > On 31.10.2011 18:16, Alexandru Petrescu wrote: >> Le 30/10/2011 18:24, Ted Lemon a écrit : >>> On Oct 30, 2011, at 1:02 PM, Alexandru Petrescu wrote: >>>> The question one raised on 6man is about coexistence with RA >>>> about default route. One is aware that a similar situation >>>> (alternate mechanism DHCP-vs-RA for default route) appeared >>>> recently when DNS-in-RA was proposed (DHCP existed doing DNS). >>>> RFC6106 proposes to do DNS-in-RA but has a section explaining >>>> coexistence with DHCP about DNS address - and gives the latter >>>> precedence over. >>> >>> This is a very good point, which should be addressed in the >>> route option draft. I think the right thing is to give RA >>> precedence over DHCP for routing information, but am curious to >>> know if others disagree. >> >> I do not disagree: in the default route case, if RA offers such >> data then give it preference over the default route obtained from >> DHCP. > > Sorry, but I can't parse that sentence. You seem to agree with Ted > (DHCP preferred over RA), but the later part of the sentence states > otherwise (RA preferred over RA). Ted suggested RA to be prefered over DHCP and I agree with it. (in another email you propose DHCP preferred over RA, and Ted seems to agree with you as well). >> (the preference mechanism can be specified by using the lifetime >> mechanism). > > Can you elaborate on that? What has lifetime to do with preference? > Do you want to somehow prefer longer (or shorter) lifetimes? YEs, that. RA has this Router Lifetime field. When two routers send RA each with a default default router, the Host could 'prefer' one over the other based on the longest lifetime. RFC4861 says 'The Router Lifetime applies only to the router's usefulness as a default router'. A similar mechanism could happen to compare a default route obtained from DHCP, and from RA: prefer the one whith longer lifetime. > That is rather dangerous and I would like to avoid that. I believe > that clear statement ("DHCP overrides RA" or "RA overrides DHCP") > will help a lot here. Hm, but that's not how DNS-RA RFC does. DNS-RA RFC6106 does preferences instead of a yes-no alternative. RFC4191 "Default Router Preferences" also works with preferences instead of exclusion. What do you think? Alex > > Tomek _______________________________________________ mif mailing > list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif > From brian.e.carpenter@gmail.com Mon Oct 31 13:42:01 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6105F11E8265 for ; Mon, 31 Oct 2011 13:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.206 X-Spam-Level: X-Spam-Status: No, score=-103.206 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j6svwRva1EPB for ; Mon, 31 Oct 2011 13:42:00 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id C425411E8263 for ; Mon, 31 Oct 2011 13:42:00 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so6232665vcb.31 for ; Mon, 31 Oct 2011 13:42:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=7huDtf9cKlgSMA34gE2MDdKEsaxWjpmvk9H9hiHn+18=; b=q3hDQ8KJQE7/xUHRXRNpDw0ZSCLoCA/LBAOJo7TO18PDv6nhn/tNLsca4S4rEkJ6bj yFlbjrRmZZwv31BcJJbZh0GuvL1t9E69lWB12eowds7usePaGjb8pUINX3RJ+cus6ZtD 4rsttNSPg8POMi/Ocrm2/x2K5/abfxIUmCptA= Received: by 10.220.148.202 with SMTP id q10mr2626854vcv.240.1320093720212; Mon, 31 Oct 2011 13:42:00 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id el1sm11469824vdc.13.2011.10.31.13.41.57 (version=SSLv3 cipher=OTHER); Mon, 31 Oct 2011 13:41:59 -0700 (PDT) Message-ID: <4EAF07FD.3090202@gmail.com> Date: Tue, 01 Nov 2011 09:41:33 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ted Lemon References: <4EAAA9FE.9030600@innovationslab.net> , <5B6B2B64C9FE2A489045EEEADDAFF2C3032A71C3@XMB-RCD-109.cisco.com> <4EAD833E.1020204@gmail.com> , <4EADB4F5.3030804@gmail.com> <091A2980-DC47-403E-BDF9-96EC955815C5@nominum.com>, <4EAE811A.1030005@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [mif] RA vs DHCPv6 config (was Review requested: draft-ietf-mif-dhcpv6-route-option) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 20:42:01 -0000 On 2011-11-01 02:30, Ted Lemon wrote: > On Oct 31, 2011, at 7:06 AM, "Tomasz Mrugalski" wrote: >> How about a different perspective on RA and DHCP disagreement? RA >> provides generic mechanism for all hosts in a network. DHCP allows to >> provision routing information on per host basis. Therefore you can >> deliver additional configuration to selected subset of hosts. That's why >> I would prefer DHCP over RA as a way to override "default" configuration. > > Yup, that's a really good point. I think this is sufficient justification for preferring the value obtained through DHCP. Yes, that's a good way to look at it. I don't see how to avoid some discussion outside MIF, however. Probably v6ops is best for this particular aspect. > I will buy the security argument when I see the first successful use of DHCP security by a naive end user... :) Fair enough, but at least the security benefits should be written down. Brian From Ted.Lemon@nominum.com Mon Oct 31 15:26:50 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D8D211E8310 for ; Mon, 31 Oct 2011 15:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.532 X-Spam-Level: X-Spam-Status: No, score=-106.532 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 275DS2Jbs+CV for ; Mon, 31 Oct 2011 15:26:49 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id 787EB11E830E for ; Mon, 31 Oct 2011 15:26:49 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Mon, 31 Oct 2011 15:26:49 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 1B4F71B8261 for ; Mon, 31 Oct 2011 15:26:37 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 02851190052; Mon, 31 Oct 2011 15:26:37 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.01.0323.003; Mon, 31 Oct 2011 15:26:37 -0700 From: Ted Lemon To: Alexandru Petrescu Thread-Topic: [mif] Review requested: draft-ietf-mif-dhcpv6-route-option Thread-Index: AQHMlyjLV0Xly0s/BU2jY2wI85ydQZWXKKCAgAAGFACAAAhSgIAASE2A Date: Mon, 31 Oct 2011 22:26:36 +0000 Message-ID: References: <4EAAA9FE.9030600@innovationslab.net> , <5B6B2B64C9FE2A489045EEEADDAFF2C3032A71C3@XMB-RCD-109.cisco.com> <4EAD833E.1020204@gmail.com> <4EAED7E1.2040506@gmail.com> <4EAEDCFA.6050202@gmail.com> <4EAEE3F5.8020605@gmail.com> In-Reply-To: <4EAEE3F5.8020605@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_F6C5C3CA179F4B82A9C3C17E498968B2nominumcom_" MIME-Version: 1.0 Cc: "" Subject: Re: [mif] Review requested: draft-ietf-mif-dhcpv6-route-option X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 22:26:50 -0000 --_000_F6C5C3CA179F4B82A9C3C17E498968B2nominumcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Oct 31, 2011, at 2:07 PM, Alexandru Petrescu wrote: (in another email you propose DHCP preferred over RA, and Ted seems to agree with you as well). Tomek changed my mind. :) BTW, lifetimes are a red herring, since both mechanisms provide for and exp= ect lifetimes to be updated, so you'd be predicting the future based on dat= a that gives no indication of the future. --_000_F6C5C3CA179F4B82A9C3C17E498968B2nominumcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
On Oct 31, 2011, at 2:07 PM, Alexandru Petrescu wrote:
(in another email you propose DHCP preferred over RA, and Ted seems to
agree with you as well).

Tomek changed my mind.  :)

BTW, lifetimes are a red herring, since both mechanisms provide for an= d expect lifetimes to be updated, so you'd be predicting the future based o= n data that gives no indication of the future.

--_000_F6C5C3CA179F4B82A9C3C17E498968B2nominumcom_-- From Ted.Lemon@nominum.com Mon Oct 31 15:28:11 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06FDC11E8322 for ; Mon, 31 Oct 2011 15:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.534 X-Spam-Level: X-Spam-Status: No, score=-106.534 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WN8kAp1xXDDO for ; Mon, 31 Oct 2011 15:28:10 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 385A111E8323 for ; Mon, 31 Oct 2011 15:28:10 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP; Mon, 31 Oct 2011 15:28:10 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 4C6011B8261 for ; Mon, 31 Oct 2011 15:28:09 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 457FA190052; Mon, 31 Oct 2011 15:28:09 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.01.0323.003; Mon, 31 Oct 2011 15:28:09 -0700 From: Ted Lemon To: Brian E Carpenter Thread-Topic: [mif] RA vs DHCPv6 config (was Review requested: draft-ietf-mif-dhcpv6-route-option) Thread-Index: AQHMl0NqObKG560zMkGTar0EyAgE6pWVae/KgAFXCgD//7LpSIAA7eOAgAAdxwA= Date: Mon, 31 Oct 2011 22:28:08 +0000 Message-ID: <1C00CFA3-6F88-4DE2-8B87-1D7E3B93EF3D@nominum.com> References: <4EAAA9FE.9030600@innovationslab.net> , <5B6B2B64C9FE2A489045EEEADDAFF2C3032A71C3@XMB-RCD-109.cisco.com> <4EAD833E.1020204@gmail.com> , <4EADB4F5.3030804@gmail.com> <091A2980-DC47-403E-BDF9-96EC955815C5@nominum.com>, <4EAE811A.1030005@gmail.com> <4EAF07FD.3090202@gmail.com> In-Reply-To: <4EAF07FD.3090202@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_1C00CFA36F884DE28B871D7E3B93EF3Dnominumcom_" MIME-Version: 1.0 Cc: "" Subject: Re: [mif] RA vs DHCPv6 config (was Review requested: draft-ietf-mif-dhcpv6-route-option) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 22:28:11 -0000 --_000_1C00CFA36F884DE28B871D7E3B93EF3Dnominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Oct 31, 2011, at 4:41 PM, Brian E Carpenter wrote: Fair enough, but at least the security benefits should be written down. At present I don't think DHCP is better than SEND. --_000_1C00CFA36F884DE28B871D7E3B93EF3Dnominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <98B5105089824C46BEA7D610876E72DE@nominum.com> Content-Transfer-Encoding: quoted-printable
On Oct 31, 2011, at 4:41 PM, Brian E Carpenter wrote:
Fair enough, but at least the security benefits should be written down.

At present I don't think DHCP is better than SEND.

--_000_1C00CFA36F884DE28B871D7E3B93EF3Dnominumcom_--