From dhankins@google.com Sat Oct 1 21:42:55 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51DD021F8C15 for ; Sat, 1 Oct 2011 21:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 fBTVEl8wtpgb for ; Sat, 1 Oct 2011 21:42:53 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5B57221F8C14 for ; Sat, 1 Oct 2011 21:42:51 -0700 (PDT) Received: from hpaq14.eem.corp.google.com (hpaq14.eem.corp.google.com [172.25.149.14]) by smtp-out.google.com with ESMTP id p924jl7Q011736 for ; Sat, 1 Oct 2011 21:45:47 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1317530748; bh=WEvsIktDvkbc5eC1uElJz22/81c=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=kHUhGGz8K6riKLDNZqBSemShRNu3V87ApGVCn2taOiDRmX1tPfHfioZ4vPye6cwnO 0Dy17syzhV0ZLaKpIxmPw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=MVNQHHuQurvEcWv1+1kAWSJX3RMNr5rB3k8u42sQ+mDoNIy0U2+9B0pPt1MEVjp55 RqWXqqnLlfUpxKncIGVGA== Received: from ywn1 (ywn1.prod.google.com [10.192.14.1]) by hpaq14.eem.corp.google.com with ESMTP id p924jjW5030309 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 1 Oct 2011 21:45:46 -0700 Received: by ywn1 with SMTP id 1so2993103ywn.38 for ; Sat, 01 Oct 2011 21:45:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=03KjmLZHppUJNcqGfmAmSGnOVW2Yl+Kjws8NUTrOjwY=; b=jSCrcZ/Y+afkx9XDDN+uIH3spMjXgGan6jq3fkYrBxC0XwCcyPkb/m/q+bSTRE1d9s Edgj0GjF+cl08jxjZ9Eg== Received: by 10.101.65.12 with SMTP id s12mr12049870ank.25.1317530744992; Sat, 01 Oct 2011 21:45:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.65.12 with SMTP id s12mr12049866ank.25.1317530744784; Sat, 01 Oct 2011 21:45:44 -0700 (PDT) Received: by 10.100.14.5 with HTTP; Sat, 1 Oct 2011 21:45:44 -0700 (PDT) In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B920122B5BD@SZXEML506-MBS.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B920122B5BD@SZXEML506-MBS.china.huawei.com> Date: Sat, 1 Oct 2011 21:45:44 -0700 Message-ID: From: David Hankins To: Jiangsheng Content-Type: multipart/alternative; boundary=001636eee02306097304ae4988e0 X-System-Of-Record: true Cc: dhc WG Subject: Re: [dhcwg] Review of draft-ietf-dhc-option-guidelines X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Oct 2011 04:42:55 -0000 --001636eee02306097304ae4988e0 Content-Type: text/plain; charset=ISO-8859-1 I'm finally getting time to work on this again... On Thu, Aug 11, 2011 at 1:16 AM, Jiangsheng wrote: > As agreed in the IETF 81 meeting, I have reviewed > draft-ietf-dhc-option-guidelines and have below comments. > > Overall, this guideline is very useful. If it was published, it should be > recommended in DHC WG charter page. > > 1. The very first and maybe the most important comment is: it is better to > separate DHCPv4 and DHCPv6. It means we should have two dedicated drafts for > DHCPv4 and DHCPv6. DHCPv4 and DHCPv6 are similar, but two different > protocols. Some of discussions may be common between them, some of > discussion may have very different base. Combining this discussion may > harmful. Section 9, "option size" is an example. The option size > requirements for DHCPv4 and DHCPv6 are different. > > Separating them would make the discussion more explicitly and targeting > right readers. Say, one who is designing a new DHCPv6 option would not care > how this may relevant to a DHCPv4 option. > > Furthermore, if DHCPv4 option space has freeze or will freeze, guidelines > for new DHCPv4 option may be meaningless. > I agree, but I don't really have the time to separate the draft. :( > 2. In the introduction section, this draft mentioned support for unknown > options. It is unclear for me, at least from the draft contents, how this > can happen? It may be possible to add new option at the server side, how the > client support it? > The ISC DHCP client and server share the same mechanism described in the Appendix. My understanding of the Windows DHCP client is that it stores a copy of anything it receives in the registry and applications that require or support a new option will fetch it there. Unfortunately, my memory is that there isn't a way to add the option to the PRL. The dhcpinform-clarify draft documents for example the behavior of the Industry Updater ("Windows Updates"), which tickles the DHCP client to send a new set of DHCPINFORMs requesting option 252 - an option not supported (or not requested) by the base DHCP client, but desired by the Industry Updater. The Solaris client, if memory serves, has an extensive configuration in /etc/dhcp. Operators can manipulate the parameter request list, and have it request new options. Again these are stored in a place with a consistent format so the operator's tools can fetch values. More frequently however this feature is most useful to the DHCP Server operator, as you have indicated. 3. The section 2, "when to use DHCP" does not mentioned "IP address > configuration", which is the most important usage of DHCP. Unless this text > is dedicate for new DHCP option (the current text does not claim so), IP > address configuration should be added. > Well, the section was intended to help with the situation where you have a specified problem, and you are asking if DHCP should be used in the solution. Certainly, IP addressing is already handled, but so too should it be appropriate to resolve new addressing problems with DHCP. I tried to provide the generic answer to that question - "any knob, dial, or slider", and only list some examples. It isn't meant to be a complete list. I certainly think "my IP address" counts as host configuration. Do you think the current text is acceptable? 4. Disagree on the order of "when to use DHCP". The current text suggests > using DHCP is first because client want information. But, in my > understanding, network administration want to push/enforce some > configuration is the most important requirements. > The order isn't intended to convey importance...but I think they are of equal importance actually. It's certainly true that in some cases clients only have a knob because administrators want to be able to set it. But I don't think for most new options that that is always the case; usually some new protocol or client feature needs a conveyance for configuration state. 5. The draft states, in section 2, "the client still reserves the right to > ignore values received via DHCP". That's right. But this may be at their own > risk to be rejected by network administration. This kind of observation > should also mentioned. Otherwise, the above next may be misleading: client > can ignore DHCP configuration without any effect. > This section is specifically trying to answer the question of whether it's appropriate to use DHCP for a particular problem statement. I don't want to get encumbered in the minutiae of protocol implementation... The specific problem we've had with objection to using DHCP in a few cases is "we don't want to use DHCP for new protocol X, because I (an IETF attendee) want to be able to configure my laptop myself." If the protocol workers are quite happy being configured by the network administrator, that is already a solved problem. 6. At the end of section 4, there are some rules how to organize values in > the option. There should be more, such as the order of fixed size values, > the order of multiple variable sized values. > I don't think there are any current best practices. We don't sweat micro alignment for particular integer lengths (and it'll be ruined by other options in the payload anyway). However I think the language is a bit stilted for variable length options. In DHCPv4 the main variable length options would simply use the rest of the option data. In DHCPv6 there are some variable length formats. So there are a few things we've seen that we're trying to avoid. The first is defining 6 options for one protocol (which is hard on DHCPv4), where the client would request all 6 all the time. The second was an option I recall that wanted to use a NVT ascii string, followed by a zero byte (NULL value), followed by various fixed length values. The NULL in this case wastes an octet, purely because of ordering, and complicates client parsing (there's no support for such a thing in most software). 7. section 5, using the conclusion as title can be more explicit: "avoid > conditional formatting". This also looks like the title of section 6. > Done. > 8. the title of section 6 has a typo: avoid alciasing/aliasing > I don't know if I already fixed this, but it's fixed in my xml copy. > 9. "in the case where the server is configured with all formats, DHCP > option space is wasted on option contents that are redundant". This is not > necessary true - usage of sub-option can reduce the dhcp option type to be > only 1. Although the usage of sub-option is not recommended in the next > section. The readers may have question here. Suggest to add one sentence for > sub-option and refer to next section. > So, here I think we are talking about an unfortunately overloaded terminology. The "options space" in the DHCPv4 packet (the area after the BOOTP header) is here referred to as the options space. The text isn't referring to the DHCPv4 option code space. :( 10. Title of section 7 is misleading. It looks like it will introduce > several new formats in this section. Suggest to change as "consideration on > creating new formats". > Good point, it's now "Considerations for Creating New Formats". > 11. in Section 9, the discussion regarding to DHCPv6 cannot draw the > conclusion "prefer option formats...in the SMALLEST form factor". Be clear, > I do agree the conclusion, but not the analysis. > Do you think it is possible to describe a specific upper fixed limit for DHCPv6 in all deployments? I don't see how the conclusion isn't supported by the evidence. 12. That the address is better than FQDN is a bad example for we should > separate DHCPv4 and DHCPv6 discussion. FQDN has become favourite over IPv6 > address in many recent DHCPv6 option design. We have RFC6334, > draft-ietf-mif-dhcpv6-route-option and etc. The FQDN is more flexible and > may benefit in load-balance scenarios. > I don't agree. The FQDN has been selected in recent work despite that it is technically inferior. The entirely non-technical motivations for those decisions will continue to over-rule any guidelines we set here. 13. This draft says nothing about option orders, which is also important. > The principle should be not give any specific order when design a new DHCP > option. The option should be allowed to appear any place in the DHCP > message. The only exception is security option(s). They need to perform > algorithm over all other options. They may be allowed to located at the end. > It gets very hard to write concise language here, since the DHCPv6 style of options is for options to contain options whose codes are taken from the same option spaces. "Anywhere in the packet" is nice and simple, but very wrong in DHCPv6. > 14. draft-ietf-dhc-secure-dhcpv6 should be mentioned in the security > consideration section. If it deployed, some threats, like man-in-middle can > be prevented since it introduced an data integrity protection for DHCPv6 > messages. > Are option contents authors going to format their options differently from this information? Mostly, I'd prefer not to gate publication of the draft on the publication of another draft. 15. The text regarding to fixed/variable length options in security > consideration section looks mis-located for me. They are not security > relevant. > Buffer overflows are security problems, especially since most DHCP client software is run by the system's super-user (or in simple firmware, having no user separation). An author of a DHCP option draft would do well to try to think about how they can word the presentation of their option to enhance an implementor's wariness of buffer overruns. -- David W. Hankins SRE - Systems Engineer Google, Inc. --001636eee02306097304ae4988e0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I'm finally getting time to work on this again...

On Thu, Aug 11, 2011 at 1:16 AM, Jiangsheng <jiangsheng@huawei.com> wr= ote:
As agreed in the= IETF 81 meeting, I have reviewed draft-ietf-dhc-option-guidelines and have= below comments.

Overall, this guideline is very useful. If it was published, it should be r= ecommended in DHC WG charter page.

1. The very first and maybe the most important comment is: it is better to = separate DHCPv4 and DHCPv6. It means we should have two dedicated drafts fo= r DHCPv4 and DHCPv6. DHCPv4 and DHCPv6 are similar, but two different proto= cols. Some of discussions may be common between them, some of discussion ma= y have very different base. Combining this discussion may harmful. Section = 9, "option size" is an example. The option size requirements for = DHCPv4 and DHCPv6 are different.

Separating them would make the discussion more explicitly and targeting rig= ht readers. Say, one who is designing a new DHCPv6 option would not care ho= w this may relevant to a DHCPv4 option.

Furthermore, if DHCPv4 option space has freeze or will freeze, guidelines f= or new DHCPv4 option may be meaningless.

I agree, but I don't really have the time to separate the draft. :(
=A0
2. In the introduction section, this draft mentioned support for unknown op= tions. It is unclear for me, at least from the draft contents, how this can= happen? It may be possible to add new option at the server side, how the c= lient support it?

The ISC DHCP client and server share the s= ame mechanism described in the Appendix.

My unders= tanding of the Windows DHCP client is that it stores a copy of anything it = receives in the registry and applications that require or support a new opt= ion will fetch it there. =A0Unfortunately, my memory is that there isn'= t a way to add the option to the PRL. =A0The dhcpinform-clarify draft docum= ents for example the behavior of the Industry Updater ("Windows Update= s"), which tickles the DHCP client to send a new set of DHCPINFORMs re= questing option 252 - an option not supported (or not requested) by the bas= e DHCP client, but desired by the Industry Updater.

The Solaris client, if memory serves, has an extensive = configuration in /etc/dhcp. =A0Operators can manipulate the parameter reque= st list, and have it request new options. =A0Again these are stored in a pl= ace with a consistent format so the operator's tools can fetch values.<= /div>

More frequently however this feature is most useful to = the DHCP Server operator, as you have indicated.

3. The section 2, "when to use DHCP" does not mentioned "IP = address configuration", which is the most important usage of DHCP. Unl= ess this text is dedicate for new DHCP option (the current text does not cl= aim so), IP address configuration should be added.

Well, the section was intended to help wit= h the situation where you have a specified problem, and you are asking if D= HCP should be used in the solution. =A0Certainly, IP addressing is already = handled, but so too should it be appropriate to resolve new addressing prob= lems with DHCP.

I tried to provide the generic answer to that question = - "any knob, dial, or slider", and only list some examples. =A0It= isn't meant to be a complete list. =A0I certainly think "my IP ad= dress" counts as host configuration.

Do you think the current text is acceptable?
=
4. Disagree on the order of "= ;when to use DHCP". The current text suggests using DHCP is first beca= use client want information. But, in my understanding, network administrati= on want to push/enforce some configuration is the most important requiremen= ts.

The order isn't intended to convey imp= ortance...but I think they are of equal importance actually.

=
It's certainly true that in some cases clients only have a k= nob because administrators want to be able to set it. =A0But I don't th= ink for most new options that that is always the case; usually some new pro= tocol or client feature needs a conveyance for configuration state.

5. The draft states, in sect= ion 2, "the client still reserves the right to ignore values received = via DHCP". That's right. But this may be at their own risk to be r= ejected by network administration. This kind of observation should also men= tioned. Otherwise, the above next may be misleading: client can ignore DHCP= configuration without any effect.

This section is specifically trying to ans= wer the question of whether it's appropriate to use DHCP for a particul= ar problem statement. =A0I don't want to get encumbered in the minutiae= of protocol implementation...

The specific problem we've had with objection to us= ing DHCP in a few cases is "we don't want to use DHCP for new prot= ocol X, because I (an IETF attendee) want to be able to configure my laptop= myself."

If the protocol workers are quite happy being configure= d by the network administrator, that is already a solved problem.

6. At the end of section 4, there are some rules how to organize values in = the option. There should be more, such as the order of fixed size values, t= he order of multiple variable sized values.

I don't think there are any current best practices. =A0We don'= t sweat micro alignment for particular integer lengths (and it'll be ru= ined by other options in the payload anyway).

Howe= ver I think the language is a bit stilted for variable length options. =A0I= n DHCPv4 the main variable length options would simply use the rest of the = option data. =A0In DHCPv6 there are some variable length formats.

So there are a few things we've seen that we're= trying to avoid.

The first is defining 6 options = for one protocol (which is hard on DHCPv4), where the client would request = all 6 all the time.

The second was an option I recall that wanted to use a = NVT ascii string, followed by a zero byte (NULL value), followed by various= fixed length values. =A0The NULL in this case wastes an octet, purely beca= use of ordering, and complicates client parsing (there's no support for= such a thing in most software).

7. section 5, using the conc= lusion as title can be more explicit: "avoid conditional formatting&qu= ot;. This also looks like the title of section 6.

Done.
=A0
8. the title of section 6 has a typo: avoid alciasing/aliasi= ng

I don't know if I already fixed this, = but it's fixed in my xml copy.
=A0
9. "in the case where the server is configured with all formats, DHCP = option space is wasted on option contents that are redundant". This is= not necessary true - usage of sub-option can reduce the dhcp option type t= o be only 1. Although the usage of sub-option is not recommended in the nex= t section. The readers may have question here. Suggest to add one sentence = for sub-option and refer to next section.

So, here I think we are talking about an u= nfortunately overloaded terminology.

The "opt= ions space" in the DHCPv4 packet (the area after the BOOTP header) is = here referred to as the options space.

The text isn't referring to the DHCPv4 option code = space. :(

10. Title of = section 7 is misleading. It looks like it will introduce several new format= s in this section. Suggest to change as "consideration on creating new= formats".

Good point, it's now "Considerati= ons for Creating New Formats".
=A0
11. in Section 9, the discussion regarding to DHCPv6 cannot draw the conclu= sion "prefer option formats...in the SMALLEST form factor". Be cl= ear, I do agree the conclusion, but not the analysis.

Do you think it is possible to describe a specific upper fix= ed limit for DHCPv6 in all deployments?

I don'= t see how the conclusion isn't supported by the evidence.

12. That the address is better th= an FQDN is a bad example for we should separate DHCPv4 and DHCPv6 discussio= n. FQDN has become favourite over IPv6 address in many recent DHCPv6 option= design. We have RFC6334, draft-ietf-mif-dhcpv6-route-option and etc. The F= QDN is more flexible and may benefit in load-balance scenarios.

I don't agree. =A0The FQDN has been se= lected in recent work despite that it is technically inferior.
The entirely non-technical motivations for those decisions wil= l continue to over-rule any guidelines we set here.

13. This draft says nothing = about option orders, which is also important. The principle should be not g= ive any specific order when design a new DHCP option. The option should be = allowed to appear any place in the DHCP message. The only exception is secu= rity option(s). They need to perform algorithm over all other options. They= may be allowed to located at the end.

It gets very hard to write concise languag= e here, since the DHCPv6 style of options is for options to contain options= whose codes are taken from the same option spaces. =A0"Anywhere in th= e packet" is nice and simple, but very wrong in DHCPv6.
=A0
14. draft-ietf-dhc-secure-dhc= pv6 should be mentioned in the security consideration section. If it deploy= ed, some threats, like man-in-middle can be prevented since it introduced a= n data integrity protection for DHCPv6 messages.

Are option contents authors going to forma= t their options differently from this information?

Mostly, I'd prefer not to gate publication of the draft on the publica= tion of another draft.

15. The text regarding to fi= xed/variable length options in security consideration section looks mis-loc= ated for me. They are not security relevant.

Buffer overflows are security problems, es= pecially since most DHCP client software is run by the system's super-u= ser (or in simple firmware, having no user separation). =A0An author of a D= HCP option draft would do well to try to think about how they can word the = presentation of their option to enhance an implementor's wariness of bu= ffer overruns.

--
David W. Hankins
SRE - Systems E= ngineer
Google, Inc.
--001636eee02306097304ae4988e0-- From dhankins@google.com Sat Oct 1 22:05:48 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4E021F8E3B for ; Sat, 1 Oct 2011 22:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 y6OGj2UP9X4S for ; Sat, 1 Oct 2011 22:05:47 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 7D69D21F8E38 for ; Sat, 1 Oct 2011 22:05:47 -0700 (PDT) Received: from hpaq12.eem.corp.google.com (hpaq12.eem.corp.google.com [172.25.149.12]) by smtp-out.google.com with ESMTP id p9258jgi000539 for ; Sat, 1 Oct 2011 22:08:45 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1317532125; bh=wtCJwmqoCTTD6Us1WJpERPqhV9s=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=pnDwVbNtmhuoff7VJz7RxjqoBCkh1MRpQECYLnk0TUMB4SDtPvuUrmC/gVOoRX6A0 yeLL7t5Dh1h1h6kFypiqQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=utNofFCFYbFT7lk8URp+MOJHiAbSXl5WUTBUnCq8/6UYXXP4VBTVOQFVKiiFzSSGH 8Su73sIQ64r8blwA/YLmg== Received: from gyg8 (gyg8.prod.google.com [10.243.50.136]) by hpaq12.eem.corp.google.com with ESMTP id p9258hGU019418 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 1 Oct 2011 22:08:43 -0700 Received: by gyg8 with SMTP id 8so3059462gyg.20 for ; Sat, 01 Oct 2011 22:08:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Lf1W2WVrSeSkYO/kv9WlDhuBzix409qqwnwGbQYRtyQ=; b=wFIw22Iu/c3SCH4M0lcdNKyESP7JyYUMbhARHtzh+nC5qCnIakUB64J7WUmj+JbrYN 5zuv5ib9+h7VrYw1fW5w== Received: by 10.101.171.5 with SMTP id y5mr339255ano.3.1317532122886; Sat, 01 Oct 2011 22:08:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.171.5 with SMTP id y5mr339251ano.3.1317532122654; Sat, 01 Oct 2011 22:08:42 -0700 (PDT) Received: by 10.100.14.5 with HTTP; Sat, 1 Oct 2011 22:08:42 -0700 (PDT) In-Reply-To: References: <5D36713D8A4E7348A7E10DF7437A4B920122B5BD@SZXEML506-MBS.china.huawei.com> Date: Sat, 1 Oct 2011 22:08:42 -0700 Message-ID: From: David Hankins To: Jiangsheng Content-Type: multipart/alternative; boundary=001636c927fc26a72404ae49da17 X-System-Of-Record: true Cc: dhc WG Subject: Re: [dhcwg] Review of draft-ietf-dhc-option-guidelines X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Oct 2011 05:05:48 -0000 --001636c927fc26a72404ae49da17 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Oct 1, 2011 at 9:45 PM, David Hankins wrote: > 13. This draft says nothing about option orders, which is also important. >> The principle should be not give any specific order when design a new DHCP >> option. The option should be allowed to appear any place in the DHCP >> message. The only exception is security option(s). They need to perform >> algorithm over all other options. They may be allowed to located at the end. >> > > It gets very hard to write concise language here, since the DHCPv6 style of > options is for options to contain options whose codes are taken from the > same option spaces. "Anywhere in the packet" is nice and simple, but very > wrong in DHCPv6. > I tell a lie, the "Clients Request their Options" section gives advice not to rely on any ordering unless in the most dire of circumstance. The discussion does go along with ORO/PRL, since there can be an expectation that the ORO/PRL order leads to packet ordering. -- David W. Hankins SRE - Systems Engineer Google, Inc. --001636c927fc26a72404ae49da17 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Oct 1, 2011 at 9:45 PM, David Hankins <dhankins@google.com> wrote:
13. This draft says nothing about option orders, which is also important. = The principle should be not give any specific order when design a new DHCP = option. The option should be allowed to appear any place in the DHCP messag= e. The only exception is security option(s). They need to perform algorithm= over all other options. They may be allowed to located at the end.

It gets very hard to write concise l= anguage here, since the DHCPv6 style of options is for options to contain o= ptions whose codes are taken from the same option spaces. =A0"Anywhere= in the packet" is nice and simple, but very wrong in DHCPv6.

I tell a lie, the "Clients Requ= est their Options" section gives advice not to rely on any ordering un= less in the most dire of circumstance.

The discuss= ion does go along with ORO/PRL, since there can be an expectation that the = ORO/PRL order leads to packet ordering.

--=A0
David W. Hankins
SRE - = Systems Engineer
Google, Inc.
--001636c927fc26a72404ae49da17-- From internet-drafts@ietf.org Sat Oct 1 22:10:42 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB1221F8E7A; Sat, 1 Oct 2011 22:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 FLqzoiJ+QOla; Sat, 1 Oct 2011 22:10:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24B8921F8E6C; Sat, 1 Oct 2011 22:10:42 -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: <20111002051042.371.4208.idtracker@ietfa.amsl.com> Date: Sat, 01 Oct 2011 22:10:42 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-option-guidelines-07.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Oct 2011 05:10:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Gr= oup of the IETF. Title : Guidelines for Creating New DHCP Options Author(s) : David W. Hankins Filename : draft-ietf-dhc-option-guidelines-07.txt Pages : 18 Date : 2011-10-01 This document seeks to provide guidance to prospective DHCP Option authors, to help them in producing option formats that are easily adoptable. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-option-guidelines-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-dhc-option-guidelines-07.txt From dhankins@google.com Sat Oct 1 22:16:16 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68A4B21F8DEC for ; Sat, 1 Oct 2011 22:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 e7sP1Fv-QSk4 for ; Sat, 1 Oct 2011 22:16:15 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id BCB9121F8D21 for ; Sat, 1 Oct 2011 22:16:15 -0700 (PDT) Received: from hpaq6.eem.corp.google.com (hpaq6.eem.corp.google.com [172.25.149.6]) by smtp-out.google.com with ESMTP id p925J9m0012617 for ; Sat, 1 Oct 2011 22:19:09 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1317532750; bh=DEIG1Uyd+/XgjPP/VPr0WSy9QpU=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Content-Type; b=gj1x297fT3JQEfJxz6AKrOFwlx/JG0xSE1pmY3zeYVaov7dx8RMgnpjWkUaRimH6u 9otsQBO6zOjZbl/e8oolw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:content-type:x-system-of-record; b=GWCkm13Zk8VkHO1Iw032V1qlGxPipYZz1s1k6mSX+lKV3+Mi9ft+/n6LT9enO/uL/ 7bI5y28EpHbcrk0gavyfw== Received: from ywe9 (ywe9.prod.google.com [10.192.5.9]) by hpaq6.eem.corp.google.com with ESMTP id p925J7lT022125 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 1 Oct 2011 22:19:08 -0700 Received: by ywe9 with SMTP id 9so3423344ywe.14 for ; Sat, 01 Oct 2011 22:19:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=jywSrE6KEE+bpqgo5F3eppVUHhN8EG99X23rwtVP1Eo=; b=ZseSDXeAskBKxRckY1rjM1VyhNdD7LBrPDscTwJUvikUGnm0JaWoE8x5bZTC2bRJXD oBrLlCZOY+l1zqvEYuaw== Received: by 10.101.171.5 with SMTP id y5mr342557ano.3.1317532747258; Sat, 01 Oct 2011 22:19:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.171.5 with SMTP id y5mr342555ano.3.1317532747094; Sat, 01 Oct 2011 22:19:07 -0700 (PDT) Received: by 10.100.14.5 with HTTP; Sat, 1 Oct 2011 22:19:07 -0700 (PDT) In-Reply-To: <20111002051042.371.56024.idtracker@ietfa.amsl.com> References: <20111002051042.371.56024.idtracker@ietfa.amsl.com> Date: Sat, 1 Oct 2011 22:19:07 -0700 Message-ID: From: David Hankins To: DHC WG Content-Type: multipart/alternative; boundary=001636c927fc5ed98f04ae49ff20 X-System-Of-Record: true Subject: Re: [dhcwg] New Version Notification for draft-ietf-dhc-option-guidelines-07.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Oct 2011 05:16:16 -0000 --001636c927fc5ed98f04ae49ff20 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Oct 1, 2011 at 10:10 PM, wrote: > A new version of I-D, draft-ietf-dhc-option-guidelines-07.txt has been > successfully submitted by David Hankins and posted to the IETF repository. > > Filename: draft-ietf-dhc-option-guidelines > Revision: 07 > Title: Guidelines for Creating New DHCP Options > Creation date: 2011-10-01 > WG ID: dhc > Number of pages: 18 > > Abstract: > This document seeks to provide guidance to prospective DHCP Option > authors, to help them in producing option formats that are easily > adoptable. > In this version I've incorporated edits from Jiangsheng's review, an assortment of minor editorial changes (commas, pluralization, s/byte/octet/ for consistency (the RFC editor would only do this anyway)). One notable addition beyond this is the inclusion of an extra sentence to clarify the meaning of "protocol level" options: "; these options carry data that is the result of a routine in some DHCP software" For full context, the new text; There are at least two classes of DHCP options: A bulk class of options which are provided explicitly to carry data from one side of the DHCP exchange to the other (such as nameservers, domain names, or time servers), and a protocol class of options which require special processing on the part of the DHCP software or are used during special processing (such as the FQDN options ([RFC4702], [RFC4704]), DHCPv4 message type option [RFC2132], link selection options ([RFC3011], [RFC3527]), and so forth; these options carry data that is the result of a routine in some DHCP software). -- David W. Hankins SRE - Systems Engineer Google, Inc. --001636c927fc5ed98f04ae49ff20 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Oct 1, 2011 at 10:10 PM, <internet-drafts@ietf.org>= wrote:
A new version of I-D, draft-ietf-dhc-option-guidelines-07.txt has been succ= essfully submitted by David Hankins and posted to the IETF repository.

Filename: =A0 =A0 =A0 =A0draft-ietf-dhc-option-guidelines
Revision: =A0 =A0 =A0 =A007
Title: =A0 =A0 =A0 =A0 =A0 Guidelines for Creating New DHCP Options
Creation date: =A0 2011-10-01
WG ID: =A0 =A0 =A0 =A0 =A0 dhc
Number of pages: 18

Abstract:
=A0 This document seeks to provide guidance to prospective DHCP Option
=A0 authors, to help them in producing option formats that are easily
=A0 adoptable.
=A0
In this version I&= #39;ve incorporated edits from Jiangsheng's review, an assortment of mi= nor editorial changes (commas, pluralization, s/byte/octet/ for consistency= (the RFC editor would only do this anyway)).

One notable addition beyond this is the inclusion of an= extra sentence to clarify the meaning of "protocol level" option= s:

=A0 "; these options carry data that is th= e result of a routine in some DHCP software"

For full context, the new text;

=A0 =A0There are at least two classes of DHCP options: A bulk class = of
=A0 =A0options which are provided explicitly to carry data fro= m one side of
=A0 =A0the DHCP exchange to the other (such as nameservers, domain nam= es, or
=A0 =A0time servers), and a protocol class of options whic= h require special
=A0 =A0processing on the part of the DHCP softw= are or are used during
=A0 =A0special processing (such as the FQDN options ([RFC4702], [RFC47= 04]),
=A0 =A0DHCPv4 message type option [RFC2132], link selection= options
=A0 =A0([RFC3011], [RFC3527]), and so forth; these optio= ns carry data that
=A0 =A0is the result of a routine in some DHCP software).
<= div>
--
David W. Hankins
SRE - Systems Engineer=
Google, Inc.

--001636c927fc5ed98f04ae49ff20-- From internet-drafts@ietf.org Sat Oct 1 22:30:14 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C18221F8E8D; Sat, 1 Oct 2011 22:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 632PM1A7EYRQ; Sat, 1 Oct 2011 22:30:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D494221F8E6F; Sat, 1 Oct 2011 22:30:13 -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: <20111002053013.7637.13458.idtracker@ietfa.amsl.com> Date: Sat, 01 Oct 2011 22:30:13 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpinform-clarify-06.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Oct 2011 05:30:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Gr= oup of the IETF. Title : Dynamic Host Configuration Protocol DHCPINFORM Message C= larifications Author(s) : David W. Hankins Filename : draft-ietf-dhc-dhcpinform-clarify-06.txt Pages : 9 Date : 2011-10-01 The DHCPINFORM message within the DHCPv4 protocol has in operation diverged incompatibly from the current defined standard. This document seeks to provide clarification of actual behaviour and guidance for some situations that were previously omitted. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpinform-clarify-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-dhc-dhcpinform-clarify-06.txt From denghui02@hotmail.com Fri Sep 30 08:26:25 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6881321F8C49; Fri, 30 Sep 2011 08:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.148 X-Spam-Level: X-Spam-Status: No, score=-100.148 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Ozse7vX1UZyG; Fri, 30 Sep 2011 08:26:24 -0700 (PDT) Received: from col0-omc2-s3.col0.hotmail.com (col0-omc2-s3.col0.hotmail.com [65.55.34.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7F10721F8BDB; Fri, 30 Sep 2011 08:26:24 -0700 (PDT) Received: from COL118-W55 ([65.55.34.73]) by col0-omc2-s3.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 30 Sep 2011 08:29:18 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_bcee45fa-b601-421d-9227-642c3b85b5f8_" X-Originating-IP: [117.136.0.1] From: Hui Deng To: , , , Date: Fri, 30 Sep 2011 23:29:18 +0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 30 Sep 2011 15:29:18.0255 (UTC) FILETIME=[B81343F0:01CC7F85] X-Mailman-Approved-At: Sun, 02 Oct 2011 05:10:31 -0700 Cc: ajs@anvilwalrusden.com, pk@isoc.de, Lemon Ted , sa.morris7@googlemail.com, ogud@ogud.com Subject: [dhcwg] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2011 15:26:25 -0000 --_bcee45fa-b601-421d-9227-642c3b85b5f8_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit 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-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 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.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 - 显示引用文字 - > > 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-05.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 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-05.txt --_bcee45fa-b601-421d-9227-642c3b85b5f8_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit
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-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
 
 
 
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.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
- 显示引用文字 -
>
> 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-05.txt

--_bcee45fa-b601-421d-9227-642c3b85b5f8_-- From jhutz@cmu.edu Mon Oct 3 10:18:32 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74D9B21F8C3F for ; Mon, 3 Oct 2011 10:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 vN+SwN0vNPBj for ; Mon, 3 Oct 2011 10:18:31 -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 7F6F821F8C2B for ; Mon, 3 Oct 2011 10:18:31 -0700 (PDT) Received: from [128.2.216.42] (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id p93HLQus008341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Oct 2011 13:21:26 -0400 (EDT) From: Jeffrey Hutzelman To: "ietf-krb-wg@anl.gov" , dhcwg@ietf.org Content-Type: text/plain; charset="UTF-8" Date: Mon, 03 Oct 2011 13:21:26 -0400 Message-ID: <1317662486.10029.103.camel@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 Subject: [dhcwg] WG Last Call: draft-sakane-dhc-dhcpv6-kdc-option-12.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 17:18:32 -0000 This note announces the start of a two-week last call to determine whether to send the following document to the IESG: Title: Kerberos Options for DHCPv6 Filename: draft-sakane-dhc-dhcpv6-kdc-option-12.txt Intended Status: Standards Track(*) This document defines new four options of Dynamic Host Configuration Protocol for IPv6 (DHCPv6) to carry a set of configuration information related to the Kerberos protocol [RFC4120]. (*) Note that the current version of the draft says "Informational", but during discussion leading up to this WGLC, I think Ted and I both agreed that standards track is more appropriate. If anyone has an objection to this, please speak up. This document is a product of the Kerberos working group, but since it defines a DHCPv6 option, review is also required in DHC. As a result, we are running this Last Call simultaneously in both working groups. We request that any comments be sent to both and . This last call will expire at 23:59 EDT on Monday, Oct 17, 2011. The file can be obtained via http://tools.ietf.org/html/draft-sakane-dhc-dhcpv6-kdc-option-12.txt -- Jeffrey T. Hutzelman (N3NHS) Co-Chair, IETF Kerberos Working Group Carnegie Mellon University - Pittsburgh, PA From rdroms.ietf@gmail.com Mon Oct 3 13:02:45 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F85C21F8DCB for ; Mon, 3 Oct 2011 13:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.366 X-Spam-Level: X-Spam-Status: No, score=-103.366 tagged_above=-999 required=5 tests=[AWL=0.233, 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 QfKS+NPrfLi7 for ; Mon, 3 Oct 2011 13:02:45 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id D977121F8DCD for ; Mon, 3 Oct 2011 13:02:44 -0700 (PDT) Received: by qyk32 with SMTP id 32so2215199qyk.10 for ; Mon, 03 Oct 2011 13:05:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=iKVU40HJPlhy3LlgVIHvX7s+ebqWAyQUxNd2equuOdc=; b=LBryEBgZeFj5JCTozvF8ym36xrKImrJFwLTPsO/4VaHAWGphsNloF1QQfSbfwBnH2y 584nr3+JdCVqy9QpdRG+C3JLFwoWRCcS7+8pZBDQ5kir5rO7O7kU9PhEbgegQmpWsoGx QMLaNMM0BOQoNF5FeH2Bm42SVNbETzCW5+meU= Received: by 10.229.66.8 with SMTP id l8mr301046qci.168.1317672347677; Mon, 03 Oct 2011 13:05:47 -0700 (PDT) Received: from che-vpn-cluster-2-139.cisco.com (198-135-0-233.cisco.com. [198.135.0.233]) by mx.google.com with ESMTPS id hn10sm17082441qab.20.2011.10.03.13.05.46 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 03 Oct 2011 13:05:46 -0700 (PDT) From: Ralph Droms Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 3 Oct 2011 16:05:44 -0400 Message-Id: <6B961032-728D-43D6-81E3-9862EF9ADA09@gmail.com> To: "dhcwg@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [dhcwg] review of draft-ietf-geopriv-dhcp-lbyr-uri-option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 20:02:45 -0000 I'd appreciate a review of draft-ietf-geopriv-dhcp-lbyr-uri-option. Are = there any issues, especially with the option format, the suggestions = about dealing with large URIs or the inclusion of a separate lifetime in = the Location URI? - Ralph From Ted.Lemon@nominum.com Mon Oct 3 13:19:45 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB3221F8D1C for ; Mon, 3 Oct 2011 13:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.573 X-Spam-Level: X-Spam-Status: No, score=-106.573 tagged_above=-999 required=5 tests=[AWL=0.025, 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 2Tx3jmlA2L0E for ; Mon, 3 Oct 2011 13:19:44 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id 777C621F8CF8 for ; Mon, 3 Oct 2011 13:19:44 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP; Mon, 03 Oct 2011 13:22: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 294DE1B8207 for ; Mon, 3 Oct 2011 13:22:38 -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 93F92190061; Mon, 3 Oct 2011 13:22:35 -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, 3 Oct 2011 13:22:36 -0700 From: Ted Lemon To: Ralph Droms Thread-Topic: [dhcwg] review of draft-ietf-geopriv-dhcp-lbyr-uri-option Thread-Index: AQHMggfbXjkViOtBlkentTTh6SBa8ZVrha+A Date: Mon, 3 Oct 2011 20:22:34 +0000 Message-ID: <2207D364-CADB-43D2-907B-204180A6E4CC@nominum.com> References: <6B961032-728D-43D6-81E3-9862EF9ADA09@gmail.com> In-Reply-To: <6B961032-728D-43D6-81E3-9862EF9ADA09@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_2207D364CADB43D2907B204180A6E4CCnominumcom_" MIME-Version: 1.0 Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] review of draft-ietf-geopriv-dhcp-lbyr-uri-option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 20:19:45 -0000 --_000_2207D364CADB43D2907B204180A6E4CCnominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Oct 3, 2011, at 4:05 PM, Ralph Droms wrote: I'd appreciate a review of draft-ietf-geopriv-dhcp-lbyr-uri-option. Are th= ere any issues, especially with the option format, the suggestions about de= aling with large URIs or the inclusion of a separate lifetime in the Locati= on URI? Having a separate lifetime is certainly an issue! :) --_000_2207D364CADB43D2907B204180A6E4CCnominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <5B4356EC69251E43BAC6B0B060725142@nominum.com> Content-Transfer-Encoding: quoted-printable
On Oct 3, 2011, at 4:05 PM, Ralph Droms wrote:
I'd appreciate a review of draft-ietf-geopriv-dhcp-lbyr-uri-option.  Are = there any issues, especially with the option format, the suggestions about = dealing with large URIs or the inclusion of a separate lifetime in the Loca= tion URI?

Having a separate lifetime is certainly an issue!   :)

--_000_2207D364CADB43D2907B204180A6E4CCnominumcom_-- From jmpolk@cisco.com Mon Oct 3 15:00:44 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AED221F8EF4 for ; Mon, 3 Oct 2011 15:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.235 X-Spam-Level: X-Spam-Status: No, score=-103.235 tagged_above=-999 required=5 tests=[AWL=-0.636, 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 FWOACuRObLvi for ; Mon, 3 Oct 2011 15:00:38 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 9819721F8EFC for ; Mon, 3 Oct 2011 15:00:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=1496; q=dns/txt; s=iport; t=1317679422; x=1318889022; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=DwvMKk2hTigYKfNbBKl3vPZxmOIXCbJfqZOKmb6F/Xs=; b=jE2yUJhp0s7uywn3God+sMyBcjCCRVzMLW/GLs8Zb6eVyVQ5bE5q6xkP J3tPOsX9a+qUacfkh4eR9+La2uZOuk7fmp4/Io5Jj1CSkbkXszv93lOAP rmc4Woq/0F+Hsue77VxMNQEezuYZJ9hP97v9u+YWsOR/RO7mSPOYCir8U I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAKAwik6rRDoI/2dsb2JhbABCqAOBBYFTAQEBBAEBAQ8BJQI0CxAHBBgeEBkOMAYBEiKHX5paAZ11A4chBId3nUU X-IronPort-AV: E=Sophos;i="4.68,481,1312156800"; d="scan'208";a="5707879" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 03 Oct 2011 22:03:42 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8717.cisco.com [10.99.80.24]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p93M3f5I031107; Mon, 3 Oct 2011 22:03:41 GMT Message-Id: <201110032203.p93M3f5I031107@mtv-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 03 Oct 2011 17:03:40 -0500 To: Ted Lemon , Ralph Droms From: "James M. Polk" In-Reply-To: <2207D364-CADB-43D2-907B-204180A6E4CC@nominum.com> References: <6B961032-728D-43D6-81E3-9862EF9ADA09@gmail.com> <2207D364-CADB-43D2-907B-204180A6E4CC@nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] review of draft-ietf-geopriv-dhcp-lbyr-uri-option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 22:00:44 -0000 At 03:22 PM 10/3/2011, Ted Lemon wrote: >Content-Language: en-US >Content-Type: multipart/alternative; > boundary="_000_2207D364CADB43D2907B204180A6E4CCnominumcom_" > >On Oct 3, 2011, at 4:05 PM, Ralph Droms wrote: >>I'd appreciate a review of >>draft-ietf-geopriv-dhcp-lbyr-uri-option. Are there any issues, >>especially with the option format, the suggestions about dealing >>with large URIs or the inclusion of a separate lifetime in the Location URI? > >Having a separate lifetime is certainly an issue! :) This wasn't my idea. This was something several members of the Geopriv WG wanted, and the chairs directed me to incorporate it into the draft. Geopriv as a WG is worried about location information becoming or being stale (i.e., old or out of date or "no longer valid/applicable"). I tried to argue that what this doc does is create a means to download the URI pointing to the location information (of a client) that can change without updating the URI. But some believed (and still do) that if the location of the client changes, so must the URI. I lost that battle. I have no problems with having the location URI lifetime be exactly the same as what covers the rest of what comes from DHCP (i.e., use of one lease is good enough for me, but the WG needs to be convinced of this). James >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg From Ted.Lemon@nominum.com Mon Oct 3 16:00:18 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83D2721F8F06 for ; Mon, 3 Oct 2011 16:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.574 X-Spam-Level: X-Spam-Status: No, score=-106.574 tagged_above=-999 required=5 tests=[AWL=0.024, 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 xbtDp6LT0VSG for ; Mon, 3 Oct 2011 16:00:18 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id C909E21F8EAC for ; Mon, 3 Oct 2011 16:00:17 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP; Mon, 03 Oct 2011 16:03:21 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 8E7581B8224 for ; Mon, 3 Oct 2011 16:03:20 -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 81349190061; Mon, 3 Oct 2011 16:03:20 -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, 3 Oct 2011 16:03:20 -0700 From: Ted Lemon To: "James M. Polk" Thread-Topic: [dhcwg] review of draft-ietf-geopriv-dhcp-lbyr-uri-option Thread-Index: AQHMggfbXjkViOtBlkentTTh6SBa8ZVrha+AgAAcNwCAABC0gA== Date: Mon, 3 Oct 2011 23:03:20 +0000 Message-ID: <5EA79C2C-F4A2-4D88-85DC-E2F4B931E11A@nominum.com> References: <6B961032-728D-43D6-81E3-9862EF9ADA09@gmail.com> <2207D364-CADB-43D2-907B-204180A6E4CC@nominum.com> <201110032203.p93M3f5I031107@mtv-core-3.cisco.com> In-Reply-To: <201110032203.p93M3f5I031107@mtv-core-3.cisco.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_5EA79C2CF4A24D8885DCE2F4B931E11Anominumcom_" MIME-Version: 1.0 Cc: "dhcwg@ietf.org WG" , Ralph Droms Subject: Re: [dhcwg] review of draft-ietf-geopriv-dhcp-lbyr-uri-option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 23:00:18 -0000 --_000_5EA79C2CF4A24D8885DCE2F4B931E11Anominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Oct 3, 2011, at 6:03 PM, James M. Polk wrote: Geopriv as a WG is worried about location information becoming or being sta= le (i.e., old or out of date or "no longer valid/applicable"). I tried to a= rgue that what this doc does is create a means to download the URI pointing= to the location information (of a client) that can change without updating= the URI. But some believed (and still do) that if the location of the clie= nt changes, so must the URI. Wouldn't the client get a new address if its location changed? --_000_5EA79C2CF4A24D8885DCE2F4B931E11Anominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <47AD507B0647C54597BDEF435652446C@nominum.com> Content-Transfer-Encoding: quoted-printable
On Oct 3, 2011, at 6:03 PM, James M. Polk wrote:
Geopriv as a WG is worried about location information becoming or being stale (i.e= ., old or out of date or "no longer valid/applicable"). I tried t= o argue that what this doc does is create a means to download the URI point= ing to the location information (of a client) that can change without updating the URI. But some believed (and still do)= that if the location of the client changes, so must the URI.

Wouldn't the client get a new address if its location changed?
--_000_5EA79C2CF4A24D8885DCE2F4B931E11Anominumcom_-- From teemu.savolainen@nokia.com Tue Oct 4 00:45:06 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB8F21F8D06 for ; Tue, 4 Oct 2011 00:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.129 X-Spam-Level: X-Spam-Status: No, score=-3.129 tagged_above=-999 required=5 tests=[AWL=0.469, 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 0QVzx0kAd9d5 for ; Tue, 4 Oct 2011 00:45:05 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 5918D21F8D08 for ; Tue, 4 Oct 2011 00:45:05 -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 p947m68t015272; Tue, 4 Oct 2011 10:48:07 +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); Tue, 4 Oct 2011 10:47:38 +0300 Received: from 008-AM1MMR1-003.mgdnok.nokia.com (65.54.30.58) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 4 Oct 2011 09:47:37 +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; Tue, 4 Oct 2011 09:47:37 +0200 From: To: , Thread-Topic: [dhcwg] Call for review: draft-ietf-mif-dns-server-selection-04.txt Thread-Index: AQHMd603zsAt94FrQEezhHcPWyA3B5VWovRQgBVBLSA= Date: Tue, 4 Oct 2011 07:47:37 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962037766B3@008-AM1MPN1-037.mgdnok.nokia.com> References: <916CE6CF87173740BC8A2CE44309696202F2C1F8@008-AM1MPN1-037.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE44309696202F2C1F8@008-AM1MPN1-037.mgdnok.nokia.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+/nZJb9Kg7IkxE1ZbYbe1tqgA8/XISd7i6L6Xpnks3knBmET6wFQit0nV3rwfYOugnSQFYZbZgohb6OjiNKZLJRYiS2rTUXBxMEqdAOGDl6uRarv1qItPS0XVlPLl966gXbcN8JOUv5rCzDhoQD/IJuvsukHC1MgW4Kibbx3A/vCOUnto3dMYcpSZHXZqVR96DqZxqRwhsPdXJoA5c2E+uiQ09qtSm1I1Lp9JqP9+C+BRRXEEAPD1aUVLiqRHgrNJBW449SEt68/IXOYp086tlAarJzzRm+GE= x-originating-ip: [10.162.78.119] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0124_01CC8283.06612C20" MIME-Version: 1.0 X-OriginalArrivalTime: 04 Oct 2011 07:47:38.0414 (UTC) FILETIME=[E355F4E0:01CC8269] X-Nokia-AV: Clean Subject: Re: [dhcwg] Call for review: draft-ietf-mif-dns-server-selection-04.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 07:45:06 -0000 ------=_NextPart_000_0124_01CC8283.06612C20 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0125_01CC8283.06612C20" ------=_NextPart_001_0125_01CC8283.06612C20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I would especially appreciate review of the sanity of the DHCPv4 option structure and usage. Comments to DHCPv6 option and other points are of course welcome as well. Best regards, Teemu From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Savolainen Teemu (Nokia-CTO/Tampere) Sent: 20. syyskuuta 2011 22:13 To: Ted.Lemon@nominum.com; dhcwg@ietf.org Subject: Re: [dhcwg] Call for review: draft-ietf-mif-dns-server-selection-04.txt Hi, we were planning to update to -05 before soliciting dnsext/dnsop/dhc comments.. here is the -05 as I have it currently updated after quite some tsv-area comments. Please check out this -05 instead if you did not read -04 yet. http://www.ietf.org/id/draft-ietf-mif-dns-server-selection-05.txt Thanks, Teemu From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of ext Ted Lemon Sent: 20. syyskuuta 2011 18:52 To: dhc WG Subject: [dhcwg] Call for review: draft-ietf-mif-dns-server-selection-04.txt There's a document going through the mif working group that defines a new DHCP option for configuring DNS resolvers. The document allows the DHCP server to send the DHCP client a list of domains for which specific name servers should be used instead of the name servers configured in the DNS Recursive Name Server option. It would be helpful if some DHC working group members could review the document to see if they can find any problems with it. If you are interested in discussing the validity of the practice described in the document, dnsop or dnsext is probably the right place; if you are interested in making sure that it's a well-formed DHCP option that is clearly described and can be implemented in such a way that interoperability is likely, this is the place. The draft is at: http://tools.ietf.org/id/draft-ietf-mif-dns-server-selection-04.txt Thanks! ------=_NextPart_001_0125_01CC8283.06612C20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I would especially appreciate review of the sanity of the DHCPv4 = option structure and usage. Comments to DHCPv6 option and other points = are of course welcome as well.

 

Best regards,

 

           &nbs= p;    Teemu

 

From:= = dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of = Savolainen Teemu (Nokia-CTO/Tampere)
Sent: 20. syyskuuta = 2011 22:13
To: Ted.Lemon@nominum.com; = dhcwg@ietf.org
Subject: Re: [dhcwg] Call for review: = draft-ietf-mif-dns-server-selection-04.txt

 

Hi, we were planning to update to -05 before soliciting = dnsext/dnsop/dhc comments.. here is the -05 as I have it currently = updated after quite some tsv-area comments. Please check out this -05 = instead if you did not read -04 yet.

 

http://www.ietf.org/id/draft-ietf-mif-dns-server-selection-05.txt

 

Thanks,

 

           &nbs= p;    Teemu

 

From:= = dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@iet= f.org] On Behalf Of ext Ted Lemon
Sent: 20. = syyskuuta 2011 18:52
To: dhc WG     =
Subject: [dhcwg] Call for review: = draft-ietf-mif-dns-server-selection-04.txt

 

There's a document going through the mif working group = that defines a new DHCP option for configuring DNS resolvers.   The = document allows the DHCP server to send the DHCP client a list of = domains for which specific name servers should be used instead of the = name servers configured in the DNS Recursive Name Server option.   = It would be helpful if some DHC working group members could review the = document to see if they can find any problems with it.   If you are = interested in discussing the validity of the practice described in the = document, dnsop or dnsext is probably the right place; if you are = interested in making sure that it's a well-formed DHCP option that is = clearly described and can be implemented in such a way that = interoperability is likely, this is the = place.

 

The draft is at:

 

------=_NextPart_001_0125_01CC8283.06612C20-- ------=_NextPart_000_0124_01CC8283.06612C20 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTExMDA0MDc0NzM0WjAjBgkqhkiG9w0B CQQxFgQUTX1V/T06jk28BdcZrCgD1nD2Ar8wVgYJKwYBBAGCNxAEMUkwRzAzMQswCQYDVQQGEwJG STEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLx MFgGCyqGSIb3DQEJEAILMUmgRzAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNV BAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLxMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMA0GCSqGSIb3DQEBAQUABIIBABtE+jXqlRJB0JVAjOS7 eomfiOkPJrFMjRiG9Sslj1z7wR1f9yDpqOV6cm3aqhEn9Py0/NnK+e0aNFLS0EcNs99yTEt8H2lQ TowOChCbkEie++jTbS9YTmoW9DUZJor+GHFo+VFVrn7FVPxhLbElVOrvZuxRCylObME6PbEjzAEw +U8EGJcbfDwb3QKxeeUex7VTtFt8IP7/DBlsfIRomYmHK8SLb9wiihyN7x9t+lGsbIba7/CNfTaZ tPcKJtMk8ETNp/I3jcDOXIS6Z+HAei8MulV0NOeDm8snsG8PGvps0gUw7loD/2ZEuu+EXkkK81a6 3t06TGQb1L7agxsKPgwAAAAAAAA= ------=_NextPart_000_0124_01CC8283.06612C20-- From jmpolk@cisco.com Tue Oct 4 10:29:06 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1822B21F8DAB for ; Tue, 4 Oct 2011 10:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.223 X-Spam-Level: X-Spam-Status: No, score=-103.223 tagged_above=-999 required=5 tests=[AWL=-0.624, 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 0NhXYTsJLlNN for ; Tue, 4 Oct 2011 10:29:05 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id A71D821F8DA1 for ; Tue, 4 Oct 2011 10:29:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=944; q=dns/txt; s=iport; t=1317749531; x=1318959131; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=h0n3OT36NtIoiFgYa59V7mhIaGiyhuNgFpFo78aggB0=; b=f6G/nDjVJ8P31rmcCX0t+rhC7ebZMQrtFJDyNyklY0LvqC46+W+38vE+ VdwliNAKlSehViKxrUuaFqRTai59VbgahxZ3SIEGAcVCVAPqVfEdM7W4R 7iuYz4NG/DvgWFLP/zf5JxtskmZDIpBIZzuBUmX1Y0KY89pIP8BB7VbNJ s=; X-IronPort-AV: E=Sophos;i="4.68,486,1312156800"; d="scan'208";a="5875002" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 04 Oct 2011 17:32:07 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8717.cisco.com [10.99.80.24]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p94HW6s3000630; Tue, 4 Oct 2011 17:32:06 GMT Message-Id: <201110041732.p94HW6s3000630@mtv-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 04 Oct 2011 12:32:06 -0500 To: Ted Lemon , "James M. Polk" From: "James M. Polk" In-Reply-To: <5EA79C2C-F4A2-4D88-85DC-E2F4B931E11A@nominum.com> References: <6B961032-728D-43D6-81E3-9862EF9ADA09@gmail.com> <2207D364-CADB-43D2-907B-204180A6E4CC@nominum.com> <201110032203.p93M3f5I031107@mtv-core-3.cisco.com> <5EA79C2C-F4A2-4D88-85DC-E2F4B931E11A@nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "dhcwg@ietf.org WG" , Ralph Droms Subject: Re: [dhcwg] review of draft-ietf-geopriv-dhcp-lbyr-uri-option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 17:29:06 -0000 At 06:03 PM 10/3/2011, Ted Lemon wrote: >On Oct 3, 2011, at 6:03 PM, James M. Polk wrote: >>Geopriv as a WG is worried about location information becoming or >>being stale (i.e., old or out of date or "no longer >>valid/applicable"). I tried to argue that what this doc does is >>create a means to download the URI pointing to the location >>information (of a client) that can change without updating the URI. >>But some believed (and still do) that if the location of the client >>changes, so must the URI. > >Wouldn't the client get a new address if its location changed? that argument was tried and failed too... 2 reasons were given: #1 - some were thinking that really flat networks wouldn't necessarily change the router interface even when the dot11 APs changed; #2 - cellular doesn't change an IP address even though an AP or tower changes (DHCP is now part of IMS for those that didn't know). James From Ted.Lemon@nominum.com Tue Oct 4 10:36:01 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9581221F8DEB for ; Tue, 4 Oct 2011 10:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.575 X-Spam-Level: X-Spam-Status: No, score=-106.575 tagged_above=-999 required=5 tests=[AWL=0.023, 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 wpaOhDeOjSX6 for ; Tue, 4 Oct 2011 10:36:00 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 71EC321F8DF4 for ; Tue, 4 Oct 2011 10:36:00 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP; Tue, 04 Oct 2011 10:39:06 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 932DC1B8274 for ; Tue, 4 Oct 2011 10:39:04 -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 82D4E190061; Tue, 4 Oct 2011 10:39:04 -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, 4 Oct 2011 10:39:04 -0700 From: Ted Lemon To: "James M. Polk" Thread-Topic: [dhcwg] review of draft-ietf-geopriv-dhcp-lbyr-uri-option Thread-Index: AQHMggfbXjkViOtBlkentTTh6SBa8ZVrha+AgAAcNwCAABC0gIABNcEAgAAB8YA= Date: Tue, 4 Oct 2011 17:39:04 +0000 Message-ID: <67AEBF45-5C47-43B4-B86C-482ED32E41D3@nominum.com> References: <6B961032-728D-43D6-81E3-9862EF9ADA09@gmail.com> <2207D364-CADB-43D2-907B-204180A6E4CC@nominum.com> <201110032203.p93M3f5I031107@mtv-core-3.cisco.com> <5EA79C2C-F4A2-4D88-85DC-E2F4B931E11A@nominum.com> <201110041732.p94HW6s3000630@mtv-core-1.cisco.com> In-Reply-To: <201110041732.p94HW6s3000630@mtv-core-1.cisco.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_67AEBF455C4743B4B86C482ED32E41D3nominumcom_" MIME-Version: 1.0 Cc: "dhcwg@ietf.org WG" , Ralph Droms Subject: Re: [dhcwg] review of draft-ietf-geopriv-dhcp-lbyr-uri-option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 17:36:01 -0000 --_000_67AEBF455C4743B4B86C482ED32E41D3nominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Oct 4, 2011, at 1:32 PM, James M. Polk wrote: #1 - some were thinking that really flat networks wouldn't necessarily chan= ge the router interface even when the dot11 APs changed; Putting a lifetime on the configuration information doesn't solve this prob= lem, because it's unrelated to movement between access points. A lifetime= on the IP address will accomplish the same thing, but it doesn't solve the= problem you've stated here. In order to solve this problem, you have to = refresh the information when the AP changes, which is not something DHCP ca= n do. #2 - cellular doesn't change an IP address even though an AP or tower chang= es (DHCP is now part of IMS for those that didn't know). In this situation you are not using DHCP, so it's not an issue. --_000_67AEBF455C4743B4B86C482ED32E41D3nominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <851325E1BC4C9042B28D39A62A12972F@nominum.com> Content-Transfer-Encoding: quoted-printable
On Oct 4, 2011, at 1:32 PM, James M. Polk wrote:
#1 - some were thinking that really flat networks= wouldn't necessarily change the router interface even when the dot11 APs c= hanged;

Putting a lifetime on the configuration information doesn't solve this= problem, because it's unrelated to movement between access points.   = A lifetime on the IP address will accomplish the same thing, but it doesn't= solve the problem you've stated here.   In order to solve this problem, you have to refresh the information= when the AP changes, which is not something DHCP can do.

#2 - cellular doesn't change an IP address even though an AP or tower changes= (DHCP is now part of IMS for those that didn't know).

In this situation you are not using DHCP, so it's not an issue.

--_000_67AEBF455C4743B4B86C482ED32E41D3nominumcom_-- From jmpolk@cisco.com Tue Oct 4 13:03:20 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DDBD21F8DE5 for ; Tue, 4 Oct 2011 13:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.212 X-Spam-Level: X-Spam-Status: No, score=-103.212 tagged_above=-999 required=5 tests=[AWL=-0.613, 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 7s7EFt3XygM7 for ; Tue, 4 Oct 2011 13:03:19 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 666E221F8DE8 for ; Tue, 4 Oct 2011 13:03:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=1356; q=dns/txt; s=iport; t=1317758785; x=1318968385; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=PgyOrf+zwdc1l8kTODjwY2ALmDVN/AisknsE3F5/AtE=; b=WAJ5C90uolzjl4SyHuIhoylVgGWdqg1YLtBVKllfFoh/8J4Zphhc2YEt Ubl9It9ZoPoCIKHk5HCCKVxyC/ncr4VroQMrtbqQEz4S0qT6ZLdekNCXo kP0/0wXlC14naKHlwGiH2AHNsgUf8qHkCSB1gjhdTsDRCSRunYIhMgJQv Y=; X-IronPort-AV: E=Sophos;i="4.68,487,1312156800"; d="scan'208";a="5928592" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 04 Oct 2011 20:06:24 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8717.cisco.com [10.99.80.24]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p94K6NX8001171; Tue, 4 Oct 2011 20:06:23 GMT Message-Id: <201110042006.p94K6NX8001171@mtv-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 04 Oct 2011 15:06:23 -0500 To: Ted Lemon , "James M. Polk" From: "James M. Polk" In-Reply-To: <67AEBF45-5C47-43B4-B86C-482ED32E41D3@nominum.com> References: <6B961032-728D-43D6-81E3-9862EF9ADA09@gmail.com> <2207D364-CADB-43D2-907B-204180A6E4CC@nominum.com> <201110032203.p93M3f5I031107@mtv-core-3.cisco.com> <5EA79C2C-F4A2-4D88-85DC-E2F4B931E11A@nominum.com> <201110041732.p94HW6s3000630@mtv-core-1.cisco.com> <67AEBF45-5C47-43B4-B86C-482ED32E41D3@nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "dhcwg@ietf.org WG" , Ralph Droms Subject: Re: [dhcwg] review of draft-ietf-geopriv-dhcp-lbyr-uri-option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 20:03:20 -0000 At 12:39 PM 10/4/2011, Ted Lemon wrote: >On Oct 4, 2011, at 1:32 PM, James M. Polk wrote: >>#1 - some were thinking that really flat networks wouldn't >>necessarily change the router interface even when the dot11 APs changed; > >Putting a lifetime on the configuration information doesn't solve >this problem, because it's unrelated to movement between access >points. A lifetime on the IP address will accomplish the same >thing, but it doesn't solve the problem you've stated here. In >order to solve this problem, you have to refresh the information >when the AP changes, which is not something DHCP can do. I shortened the bullet, but what you say above is part of what I suggested (i.e., needing a trigger upon change of an AP), but that didn't satisfy the discussion in Geopriv. >>#2 - cellular doesn't change an IP address even though an AP or >>tower changes (DHCP is now part of IMS for those that didn't know). > >In this situation you are not using DHCP, so it's not an issue. as cut-n-dry (or black-n-white) as you see this, others see grey (unfortunately). The DHC WG stating there is a problem with the Valid-For field within this document is something concrete that the (Geopriv) chairs would need to address with and into DHC, IMO. Do others have the same issue with this draft? James From Ted.Lemon@nominum.com Tue Oct 4 13:22:37 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16D0021F8E2E for ; Tue, 4 Oct 2011 13:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.576 X-Spam-Level: X-Spam-Status: No, score=-106.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 f6axA35yy5Cr for ; Tue, 4 Oct 2011 13:22:36 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 50F9321F8E24 for ; Tue, 4 Oct 2011 13:22:36 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP; Tue, 04 Oct 2011 13:25:42 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 602D31B8242 for ; Tue, 4 Oct 2011 13:25:35 -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 4C65F190061; Tue, 4 Oct 2011 13:25:34 -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, 4 Oct 2011 13:25:34 -0700 From: Ted Lemon To: "James M. Polk" Thread-Topic: [dhcwg] review of draft-ietf-geopriv-dhcp-lbyr-uri-option Thread-Index: AQHMggfbXjkViOtBlkentTTh6SBa8ZVrha+AgAAcNwCAABC0gIABNcEAgAAB8YCAACkqgIAABVuA Date: Tue, 4 Oct 2011 20:25:33 +0000 Message-ID: <578BA924-AE98-4B72-8857-949C9B76D6F6@nominum.com> References: <6B961032-728D-43D6-81E3-9862EF9ADA09@gmail.com> <2207D364-CADB-43D2-907B-204180A6E4CC@nominum.com> <201110032203.p93M3f5I031107@mtv-core-3.cisco.com> <5EA79C2C-F4A2-4D88-85DC-E2F4B931E11A@nominum.com> <201110041732.p94HW6s3000630@mtv-core-1.cisco.com> <67AEBF45-5C47-43B4-B86C-482ED32E41D3@nominum.com> <201110042006.p94K6NX8001171@mtv-core-3.cisco.com> In-Reply-To: <201110042006.p94K6NX8001171@mtv-core-3.cisco.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="us-ascii" Content-ID: <0409B42AE69A5B45BD6A744E2C7B997A@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org WG" , Ralph Droms Subject: Re: [dhcwg] review of draft-ietf-geopriv-dhcp-lbyr-uri-option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 20:22:37 -0000 On Oct 4, 2011, at 4:06 PM, James M. Polk wrote: > I shortened the bullet, but what you say above is part of what I suggeste= d (i.e., needing a trigger upon change of an AP), but that didn't satisfy t= he discussion in Geopriv. Interesting. So they are willing to take a solution that doesn't fix the = problem, but reject a solution that does fix the problem? They can certai= nly fly in the face of reason like this if they want, but that's not a good= reason to change the way the DHCP protocol works. >> In this situation you are not using DHCP, so it's not an issue. >=20 > as cut-n-dry (or black-n-white) as you see this, others see grey (unfortu= nately). This is actually the same as the previous question. Even if they were to = use DHCP, a lifetime on the address wouldn't actually solve the stated prob= lem, because again the device needs to notice that it's changed cells. And by the way, in both of these cases, even supposing that we did change t= he DHCP protocol in the way that's been proposed, how would the DHCP server= know that the device was connecting through a different access point or ce= ll tower? > The DHC WG stating there is a problem with the Valid-For field within thi= s document is something concrete that the (Geopriv) chairs would need to ad= dress with and into DHC, IMO. Right, so I would be curious to hear from other DHC working group members a= s to whether they have an opinion on whether the DHCP protocol should be ex= tended with an additional lifetime on geopriv URIs. Bear in mind that all= DHCP clients would have to be modified to support this feature. Thoughts? Comments? From rdroms.ietf@gmail.com Tue Oct 4 13:28:46 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3C2821F8F57 for ; Tue, 4 Oct 2011 13:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[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 kC8+PLWMoYth for ; Tue, 4 Oct 2011 13:28:46 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 364F621F8F0D for ; Tue, 4 Oct 2011 13:28:46 -0700 (PDT) Received: by qyk32 with SMTP id 32so3231215qyk.10 for ; Tue, 04 Oct 2011 13:31:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=OOk24EeYK9zkWm7/2IS+65akhdCKURn4ogzjAgxowpE=; b=E3U0w2Um9o30toylh8xC2lDQxAWpPuTtlKA7PZXRH12ubJoXUt2u2lnekeeNA/gU+e xJODPdHaDpLsUeSM3UBYVviXdcUxO/cofzHo4mOmLbMg4IwGR069YREPQ/3XppnGSqcA wBpQzATx4x//Pyclp/vXVy79qGMYOsInOApm4= Received: by 10.229.95.2 with SMTP id b2mr1388066qcn.170.1317760311863; Tue, 04 Oct 2011 13:31:51 -0700 (PDT) Received: from [161.44.65.173] ([161.44.65.173]) by mx.google.com with ESMTPS id hr6sm20938320qab.6.2011.10.04.13.31.49 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 04 Oct 2011 13:31:50 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: <578BA924-AE98-4B72-8857-949C9B76D6F6@nominum.com> Date: Tue, 4 Oct 2011 16:31:48 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <478F3A8B-6ADE-4BC2-BCBE-7214AD983727@gmail.com> References: <6B961032-728D-43D6-81E3-9862EF9ADA09@gmail.com> <2207D364-CADB-43D2-907B-204180A6E4CC@nominum.com> <201110032203.p93M3f5I031107@mtv-core-3.cisco.com> <5EA79C2C-F4A2-4D88-85DC-E2F4B931E11A@nominum.com> <201110041732.p94HW6s3000630@mtv-core-1.cisco.com> <67AEBF45-5C47-43B4-B86C-482ED32E41D3@nominum.com> <201110042006.p94K6NX8001171@mtv-core-3.cisco.com> <578BA924-AE98-4B72-8857-949C9B76D6F6@nominum.com> To: "dhcwg@ietf.org WG" X-Mailer: Apple Mail (2.1084) Cc: "James M. Polk" , Ralph Droms , Lemon Ted Subject: Re: [dhcwg] review of draft-ietf-geopriv-dhcp-lbyr-uri-option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 20:28:47 -0000 On Oct 4, 2011, at 4:25 PM 10/4/11, Ted Lemon wrote: > On Oct 4, 2011, at 4:06 PM, James M. Polk wrote: >> I shortened the bullet, but what you say above is part of what I = suggested (i.e., needing a trigger upon change of an AP), but that = didn't satisfy the discussion in Geopriv. >=20 > Interesting. So they are willing to take a solution that doesn't fix = the problem, but reject a solution that does fix the problem? They can = certainly fly in the face of reason like this if they want, but that's = not a good reason to change the way the DHCP protocol works. >=20 >>> In this situation you are not using DHCP, so it's not an issue. >>=20 >> as cut-n-dry (or black-n-white) as you see this, others see grey = (unfortunately). >=20 > This is actually the same as the previous question. Even if they = were to use DHCP, a lifetime on the address wouldn't actually solve the = stated problem, because again the device needs to notice that it's = changed cells. >=20 > And by the way, in both of these cases, even supposing that we did = change the DHCP protocol in the way that's been proposed, how would the = DHCP server know that the device was connecting through a different = access point or cell tower? And how does the host, after receiving the new URI from its DHCP client, = notify all the holders of that URI that the URI has changed? >=20 >> The DHC WG stating there is a problem with the Valid-For field within = this document is something concrete that the (Geopriv) chairs would need = to address with and into DHC, IMO. >=20 > Right, so I would be curious to hear from other DHC working group = members as to whether they have an opinion on whether the DHCP protocol = should be extended with an additional lifetime on geopriv URIs. Bear = in mind that all DHCP clients would have to be modified to support this = feature. I don't think it's acceptable to extend the DHCP specification and state = machine to include an additional lifetime on geopriv URIs for a couple = of reasons: * in the specific case, the change doesn't solve the problem * in the general case, forcing the recoding of the core code in DHCP = clients and servers to accommodate this new option is inappropriate I- Ralph >=20 > Thoughts? Comments? >=20 From jmpolk@cisco.com Tue Oct 4 13:54:48 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE6C321F8D77 for ; Tue, 4 Oct 2011 13:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.201 X-Spam-Level: X-Spam-Status: No, score=-103.201 tagged_above=-999 required=5 tests=[AWL=-0.602, 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 WBenBbzwNxov for ; Tue, 4 Oct 2011 13:54:48 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id B398321F8D6F for ; Tue, 4 Oct 2011 13:54:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=2915; q=dns/txt; s=iport; t=1317761869; x=1318971469; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=yJBmO2pjp0T88tPBHUyPwZmcMNnvD32cWerTV9MEDnE=; b=Wd2Y5Ledxijfh98/1VlaBVv7BoR+V0hY/hjWNsG3Qjodk4LcG0Lz+/Y6 F+DSc/VqWaCQhUYqw4Cz+CujW/nmuWT90yvhNDehqgzMkaMLOvHgybBBt TeSn4FCBdn3dqI43z9tA8FmPi8pS+35QbeKmicRbC9ReDbRYWLcf7P2T3 Q=; X-IronPort-AV: E=Sophos;i="4.68,487,1312156800"; d="scan'208";a="5929320" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 04 Oct 2011 20:57:49 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8717.cisco.com [10.99.80.24]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p94KvlAJ004802; Tue, 4 Oct 2011 20:57:48 GMT Message-Id: <201110042057.p94KvlAJ004802@mtv-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 04 Oct 2011 15:57:47 -0500 To: Ralph Droms , "dhcwg@ietf.org WG" From: "James M. Polk" In-Reply-To: <478F3A8B-6ADE-4BC2-BCBE-7214AD983727@gmail.com> References: <6B961032-728D-43D6-81E3-9862EF9ADA09@gmail.com> <2207D364-CADB-43D2-907B-204180A6E4CC@nominum.com> <201110032203.p93M3f5I031107@mtv-core-3.cisco.com> <5EA79C2C-F4A2-4D88-85DC-E2F4B931E11A@nominum.com> <201110041732.p94HW6s3000630@mtv-core-1.cisco.com> <67AEBF45-5C47-43B4-B86C-482ED32E41D3@nominum.com> <201110042006.p94K6NX8001171@mtv-core-3.cisco.com> <578BA924-AE98-4B72-8857-949C9B76D6F6@nominum.com> <478F3A8B-6ADE-4BC2-BCBE-7214AD983727@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "James M. Polk" , Ralph Droms , Lemon Ted Subject: Re: [dhcwg] review of draft-ietf-geopriv-dhcp-lbyr-uri-option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 20:54:48 -0000 At 03:31 PM 10/4/2011, Ralph Droms wrote: >On Oct 4, 2011, at 4:25 PM 10/4/11, Ted Lemon wrote: > > > On Oct 4, 2011, at 4:06 PM, James M. Polk wrote: > >> I shortened the bullet, but what you say above is part of what I > suggested (i.e., needing a trigger upon change of an AP), but that > didn't satisfy the discussion in Geopriv. > > > > Interesting. So they are willing to take a solution that > doesn't fix the problem, but reject a solution that does fix the > problem? They can certainly fly in the face of reason like this > if they want, but that's not a good reason to change the way the > DHCP protocol works. > > > >>> In this situation you are not using DHCP, so it's not an issue. > >> > >> as cut-n-dry (or black-n-white) as you see this, others see grey > (unfortunately). > > > > This is actually the same as the previous question. Even if > they were to use DHCP, a lifetime on the address wouldn't actually > solve the stated problem, because again the device needs to notice > that it's changed cells. > > > > And by the way, in both of these cases, even supposing that we > did change the DHCP protocol in the way that's been proposed, how > would the DHCP server know that the device was connecting through a > different access point or cell tower? > >And how does the host, after receiving the new URI from its DHCP >client, notify all the holders of that URI that the URI has changed? I'm a little twisted around, and not completely following your question. Are you asking how does the host inform remote hosts that the URI it sent previously is no longer good or needs to be replaced? - Answer - it needs to send the new URI to all the remote hosts again (each time), which IMO defeats the purpose, but this is what Geopriv wanted > > > >> The DHC WG stating there is a problem with the Valid-For field > within this document is something concrete that the (Geopriv) > chairs would need to address with and into DHC, IMO. > > > > Right, so I would be curious to hear from other DHC working group > members as to whether they have an opinion on whether the DHCP > protocol should be extended with an additional lifetime on geopriv > URIs. Bear in mind that all DHCP clients would have to be > modified to support this feature. > >I don't think it's acceptable to extend the DHCP specification and >state machine to include an additional lifetime on geopriv URIs for >a couple of reasons: > >* in the specific case, the change doesn't solve the problem >* in the general case, forcing the recoding of the core code in DHCP >clients and servers to accommodate this new option is inappropriate > >I- Ralph Thanks - I think this is why Robert asked the experts on DHCP. Other comments, concerns or questions? James > > > > Thoughts? Comments? > > From rdroms.ietf@gmail.com Tue Oct 4 13:58:36 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FDDF21F8E01 for ; Tue, 4 Oct 2011 13:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[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 nE6SSUWFZmEB for ; Tue, 4 Oct 2011 13:58:35 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 92D4F21F8DFF for ; Tue, 4 Oct 2011 13:58:35 -0700 (PDT) Received: by qyk32 with SMTP id 32so3259841qyk.10 for ; Tue, 04 Oct 2011 14:01:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=XWW3Ws2wb4GMnhGfXZlMolCFpDaUCmuCcg2BkibGXXk=; b=q8tQlIHh8vj9RbpF0SwTL2y3DR/hI1SBILKygOAtOrHJSvCwtZqPJMExCf59l8WzJR D2SCokK08DLfninX3Zl1B42SVrO63iW8QEygLqPe9yoUM+Q+cTymtHTLvrS8ikku3PPa h4Ym0GdPVRVyZvz/J30kz6rPAOg4CP+0S2C9Q= Received: by 10.229.64.204 with SMTP id f12mr1362599qci.249.1317762101375; Tue, 04 Oct 2011 14:01:41 -0700 (PDT) Received: from [161.44.65.173] ([161.44.65.173]) by mx.google.com with ESMTPS id fz6sm21014438qab.21.2011.10.04.14.01.39 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 04 Oct 2011 14:01:40 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: <201110042057.p94KvlAJ004802@mtv-core-3.cisco.com> Date: Tue, 4 Oct 2011 17:01:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6B961032-728D-43D6-81E3-9862EF9ADA09@gmail.com> <2207D364-CADB-43D2-907B-204180A6E4CC@nominum.com> <201110032203.p93M3f5I031107@mtv-core-3.cisco.com> <5EA79C2C-F4A2-4D88-85DC-E2F4B931E11A@nominum.com> <201110041732.p94HW6s3000630@mtv-core-1.cisco.com> <67AEBF45-5C47-43B4-B86C-482ED32E41D3@nominum.com> <201110042006.p94K6NX8001171@mtv-core-3.cisco.com> <578BA924-AE98-4B72-8857-949C9B76D6F6@nominum.com> <478F3A8B-6ADE-4BC2-BCBE-7214AD983727@gmail.com> <201110042057.p94KvlAJ004802@mtv-core-3.cisco.com> To: "James M. Polk" X-Mailer: Apple Mail (2.1084) Cc: "dhcwg@ietf.org WG" , Ralph Droms , Lemon Ted Subject: Re: [dhcwg] review of draft-ietf-geopriv-dhcp-lbyr-uri-option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 20:58:36 -0000 On Oct 4, 2011, at 4:57 PM 10/4/11, James M. Polk wrote: > At 03:31 PM 10/4/2011, Ralph Droms wrote: >=20 >> On Oct 4, 2011, at 4:25 PM 10/4/11, Ted Lemon wrote: >>=20 >> > On Oct 4, 2011, at 4:06 PM, James M. Polk wrote: >> >> I shortened the bullet, but what you say above is part of what I = suggested (i.e., needing a trigger upon change of an AP), but that = didn't satisfy the discussion in Geopriv. >> > >> > Interesting. So they are willing to take a solution that doesn't = fix the problem, but reject a solution that does fix the problem? They = can certainly fly in the face of reason like this if they want, but = that's not a good reason to change the way the DHCP protocol works. >> > >> >>> In this situation you are not using DHCP, so it's not an issue. >> >> >> >> as cut-n-dry (or black-n-white) as you see this, others see grey = (unfortunately). >> > >> > This is actually the same as the previous question. Even if they = were to use DHCP, a lifetime on the address wouldn't actually solve the = stated problem, because again the device needs to notice that it's = changed cells. >> > >> > And by the way, in both of these cases, even supposing that we did = change the DHCP protocol in the way that's been proposed, how would the = DHCP server know that the device was connecting through a different = access point or cell tower? >>=20 >> And how does the host, after receiving the new URI from its DHCP = client, notify all the holders of that URI that the URI has changed? >=20 > I'm a little twisted around, and not completely following your = question. Are you asking how does the host inform remote hosts that the = URI it sent previously is no longer good or needs to be replaced? > - Answer - it needs to send the new URI to all the > remote hosts again (each time), which IMO defeats > the purpose, but this is what Geopriv wanted ...and I may have missed this from the draft or other background: does = the host maintain a list of all other hosts to which it has sent the URI = so it can update those hosts? ...which, as you say, seems to defeat the whole purpose of a "permanent" = URI. - Ralph >=20 >=20 >> > >> >> The DHC WG stating there is a problem with the Valid-For field = within this document is something concrete that the (Geopriv) chairs = would need to address with and into DHC, IMO. >> > >> > Right, so I would be curious to hear from other DHC working group = members as to whether they have an opinion on whether the DHCP protocol = should be extended with an additional lifetime on geopriv URIs. Bear = in mind that all DHCP clients would have to be modified to support this = feature. >>=20 >> I don't think it's acceptable to extend the DHCP specification and = state machine to include an additional lifetime on geopriv URIs for a = couple of reasons: >>=20 >> * in the specific case, the change doesn't solve the problem >> * in the general case, forcing the recoding of the core code in DHCP = clients and servers to accommodate this new option is inappropriate >>=20 >> I- Ralph >=20 > Thanks - I think this is why Robert asked the experts on DHCP. >=20 > Other comments, concerns or questions? >=20 > James >=20 >=20 >> > >> > Thoughts? Comments? >> > >=20 From Matt.Ryan@nominum.com Tue Oct 4 15:08:51 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE72121F8EF4 for ; Tue, 4 Oct 2011 15:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 uSymF-mVwAdq for ; Tue, 4 Oct 2011 15:08:51 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 283FA21F8EF2 for ; Tue, 4 Oct 2011 15:08:51 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP; Tue, 04 Oct 2011 15:11:57 PDT Received: from vir.ddns.nominum.com (vir.ddns.nominum.com [64.89.225.15]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by shell-too.nominum.com (Postfix) with ESMTP id 66EAF1B826C for ; Tue, 4 Oct 2011 15:11:49 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Matthew Ryan In-Reply-To: Date: Tue, 4 Oct 2011 15:11:49 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: To: dhc WG X-Mailer: Apple Mail (2.1084) Subject: Re: [dhcwg] Call for review: draft-ietf-mif-dns-server-selection-04.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 22:08:52 -0000 I have two comments on the option formats for this draft. First, I note that the DHCPv6 version has the preference value occupying the two most-significant bits of the octet in which they appear, while in the DHCPv4 version, they occupy the two least-significant bits. No reason for this different is given that I can see, and I can't think of one of the top of my head. Unless there is some driving need, they should be the same for consistency's sake. Second, the format of the DHCPv4 option as currently defined will almost certainly require special-case code in DHCP servers and management consoles to provide formatted display and config- uration (as opposed to an opaque blob of hex), which will hinder its adoption. Converting the "domain count" into a octet-length of the following fields (reserved/prf, address, domains-and-networks) would make it much simpler to parse, by not requiring the DHCP server to count domains in order to find the start of a potential second (concatenated) option. Even this, while cleaner to implement (a generic length-prefix container), would likely require new code in some servers, so other implementors should weigh in here. - Matt From jmpolk@cisco.com Tue Oct 4 15:43:28 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED5121F8ED4 for ; Tue, 4 Oct 2011 15:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.191 X-Spam-Level: X-Spam-Status: No, score=-103.191 tagged_above=-999 required=5 tests=[AWL=-0.592, 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 VgIvAXgKMi+R for ; Tue, 4 Oct 2011 15:43:27 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 7588E21F8ED1 for ; Tue, 4 Oct 2011 15:43:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=4544; q=dns/txt; s=iport; t=1317768393; x=1318977993; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=/omca9xpAQ0sRM1FKCY8IHoUNEv6zLSaRek7u1vpTZM=; b=f+rpxTON7Tv0ZTJPy5FWfw2xt/w+TUo9pYec4lvfodzNrU5agVFfH6zq epEOMWdJq0QAk8H02fU8XAQ7DKV/UktumF8amp0sm4Gh4+a7FedvV3nZg p6QUHkRoSwlglqD3XniDb8KuGyoQcE0QZ0R3cHKfdfJlZvtRq6QFnL9AW s=; X-IronPort-AV: E=Sophos;i="4.68,487,1312156800"; d="scan'208";a="5944862" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 04 Oct 2011 22:46:33 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8717.cisco.com [10.99.80.24]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p94MkXhY032052; Tue, 4 Oct 2011 22:46:33 GMT Message-Id: <201110042246.p94MkXhY032052@mtv-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 04 Oct 2011 17:46:32 -0500 To: Ralph Droms , "James M. Polk" From: "James M. Polk" In-Reply-To: References: <6B961032-728D-43D6-81E3-9862EF9ADA09@gmail.com> <2207D364-CADB-43D2-907B-204180A6E4CC@nominum.com> <201110032203.p93M3f5I031107@mtv-core-3.cisco.com> <5EA79C2C-F4A2-4D88-85DC-E2F4B931E11A@nominum.com> <201110041732.p94HW6s3000630@mtv-core-1.cisco.com> <67AEBF45-5C47-43B4-B86C-482ED32E41D3@nominum.com> <201110042006.p94K6NX8001171@mtv-core-3.cisco.com> <578BA924-AE98-4B72-8857-949C9B76D6F6@nominum.com> <478F3A8B-6ADE-4BC2-BCBE-7214AD983727@gmail.com> <201110042057.p94KvlAJ004802@mtv-core-3.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "dhcwg@ietf.org WG" , Ralph Droms , Lemon Ted Subject: Re: [dhcwg] review of draft-ietf-geopriv-dhcp-lbyr-uri-option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 22:43:28 -0000 At 04:01 PM 10/4/2011, Ralph Droms wrote: >On Oct 4, 2011, at 4:57 PM 10/4/11, James M. Polk wrote: > > > At 03:31 PM 10/4/2011, Ralph Droms wrote: > > > >> On Oct 4, 2011, at 4:25 PM 10/4/11, Ted Lemon wrote: > >> > >> > On Oct 4, 2011, at 4:06 PM, James M. Polk wrote: > >> >> I shortened the bullet, but what you say above is part of > what I suggested (i.e., needing a trigger upon change of an AP), > but that didn't satisfy the discussion in Geopriv. > >> > > >> > Interesting. So they are willing to take a solution that > doesn't fix the problem, but reject a solution that does fix the > problem? They can certainly fly in the face of reason like this > if they want, but that's not a good reason to change the way the > DHCP protocol works. > >> > > >> >>> In this situation you are not using DHCP, so it's not an issue. > >> >> > >> >> as cut-n-dry (or black-n-white) as you see this, others see > grey (unfortunately). > >> > > >> > This is actually the same as the previous question. Even if > they were to use DHCP, a lifetime on the address wouldn't actually > solve the stated problem, because again the device needs to notice > that it's changed cells. > >> > > >> > And by the way, in both of these cases, even supposing that we > did change the DHCP protocol in the way that's been proposed, how > would the DHCP server know that the device was connecting through a > different access point or cell tower? > >> > >> And how does the host, after receiving the new URI from its DHCP > client, notify all the holders of that URI that the URI has changed? > > > > I'm a little twisted around, and not completely following your > question. Are you asking how does the host inform remote hosts that > the URI it sent previously is no longer good or needs to be replaced? > > - Answer - it needs to send the new URI to all the > > remote hosts again (each time), which IMO defeats > > the purpose, but this is what Geopriv wanted > >...and I may have missed this from the draft or other background: >does the host maintain a list of all other hosts to which it has >sent the URI so it can update those hosts? that would be something the specific conveyance (of the URI) applications would need to track, if they wanted to. There's no such text in the draft about this. >...which, as you say, seems to defeat the whole purpose of a "permanent" URI. my view was that the client would get a location URI, pass it around or dereference it via another local protocol, and have "the system" or "the network" where the client was track where the client was and change the information at the record the URI pointed to - without the need for the client to track or be aware of location changes. This seemed easiest for me. Geopriv wanted a new URI sent to the client every time it changes location because the location is now considered stale (or bad). Further, the URI sent to client A is always different than what is sent to any other client, even if on the same AP. Fine, I can live with that last part - though others might have an issue with it. Other comments, concerns or questions? James >- Ralph > > > > > > >> > > >> >> The DHC WG stating there is a problem with the Valid-For > field within this document is something concrete that the (Geopriv) > chairs would need to address with and into DHC, IMO. > >> > > >> > Right, so I would be curious to hear from other DHC working > group members as to whether they have an opinion on whether the > DHCP protocol should be extended with an additional lifetime on > geopriv URIs. Bear in mind that all DHCP clients would have to be > modified to support this feature. > >> > >> I don't think it's acceptable to extend the DHCP specification > and state machine to include an additional lifetime on geopriv URIs > for a couple of reasons: > >> > >> * in the specific case, the change doesn't solve the problem > >> * in the general case, forcing the recoding of the core code in > DHCP clients and servers to accommodate this new option is inappropriate > >> > >> I- Ralph > > > > Thanks - I think this is why Robert asked the experts on DHCP. > > > > Other comments, concerns or questions? > > > > James > > > > > >> > > >> > Thoughts? Comments? > >> > > > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg From Ted.Lemon@nominum.com Tue Oct 4 15:50:23 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B1B421F8F00 for ; Tue, 4 Oct 2011 15:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.576 X-Spam-Level: X-Spam-Status: No, score=-106.576 tagged_above=-999 required=5 tests=[AWL=0.022, 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 W8oycOjeDPXJ for ; Tue, 4 Oct 2011 15:50:22 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id 688E821F8F08 for ; Tue, 4 Oct 2011 15:50:22 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP; Tue, 04 Oct 2011 15:53:29 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 C15CB1B8274 for ; Tue, 4 Oct 2011 15:53:27 -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 AF610190061; Tue, 4 Oct 2011 15:53:27 -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, 4 Oct 2011 15:53:27 -0700 From: Ted Lemon To: "James M. Polk" Thread-Topic: [dhcwg] review of draft-ietf-geopriv-dhcp-lbyr-uri-option Thread-Index: AQHMggfbXjkViOtBlkentTTh6SBa8ZVrha+AgAAcNwCAABC0gIABNcEAgAAB8YCAACkqgIAABVuAgAABvwCAAAdDgIAAARMAgAAdTwCAAAHsgA== Date: Tue, 4 Oct 2011 22:53:26 +0000 Message-ID: References: <6B961032-728D-43D6-81E3-9862EF9ADA09@gmail.com> <2207D364-CADB-43D2-907B-204180A6E4CC@nominum.com> <201110032203.p93M3f5I031107@mtv-core-3.cisco.com> <5EA79C2C-F4A2-4D88-85DC-E2F4B931E11A@nominum.com> <201110041732.p94HW6s3000630@mtv-core-1.cisco.com> <67AEBF45-5C47-43B4-B86C-482ED32E41D3@nominum.com> <201110042006.p94K6NX8001171@mtv-core-3.cisco.com> <578BA924-AE98-4B72-8857-949C9B76D6F6@nominum.com> <478F3A8B-6ADE-4BC2-BCBE-7214AD983727@gmail.com> <201110042057.p94KvlAJ004802@mtv-core-3.cisco.com> <201110042246.p94MkXhY032052@mtv-core-1.cisco.com> In-Reply-To: <201110042246.p94MkXhY032052@mtv-core-1.cisco.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_BDDAB76A9A634E5D893246EFDA08D985nominumcom_" MIME-Version: 1.0 Cc: "dhcwg@ietf.org WG" , Ralph Droms Subject: Re: [dhcwg] review of draft-ietf-geopriv-dhcp-lbyr-uri-option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 22:50:25 -0000 --_000_BDDAB76A9A634E5D893246EFDA08D985nominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Oct 4, 2011, at 6:46 PM, James M. Polk wrote: Geopriv wanted a new URI sent to the client every time it changes location = because the location is now considered stale (or bad). Further, the URI sen= t to client A is always different than what is sent to any other client, ev= en if on the same AP. Fine, I can live with that last part - though others = might have an issue with it. Other comments, concerns or questions? Yes. They need a different protocol. DHCP can't do this. --_000_BDDAB76A9A634E5D893246EFDA08D985nominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On Oct 4, 2011, at 6:46 PM, James M. Polk wrote:
Geopriv wanted a new URI sent to the client every time it changes location because= the location is now considered stale (or bad). Further, the URI sent to cl= ient A is always different than what is sent to any other client, even if o= n the same AP. Fine, I can live with that last part - though others might have an issue with it.

Other comments, concerns or questions?

Yes.   They need a different protocol.   DHCP can't do this.=

--_000_BDDAB76A9A634E5D893246EFDA08D985nominumcom_-- From jmpolk@cisco.com Tue Oct 4 15:57:58 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D126221F8EA2 for ; Tue, 4 Oct 2011 15:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.171 X-Spam-Level: X-Spam-Status: No, score=-103.171 tagged_above=-999 required=5 tests=[AWL=-0.572, 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 G4kEf2D6bx7j for ; Tue, 4 Oct 2011 15:57:58 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7C421F8E0F for ; Tue, 4 Oct 2011 15:57:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=999; q=dns/txt; s=iport; t=1317769265; x=1318978865; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=HJX5b1S4HCYoZoVS7foyWU/tYqh2E6hQ4RdoTJt1E/U=; b=PpF4lG7xA0nfcG3y1XgTzZkAkS6VQaQIatMbjQjYAbx1JI1nvRq/wqU6 7bQ4rNxitgALooo4thZAIK2fJq+FY0AJOfhNqlZeiVgwTlBZPeNBWpHX4 VW4xMACZX24tJ7PZVsR5h9AXR6l+qvSsYv2BdTEILFjX4WCct1ANd5tXT c=; X-IronPort-AV: E=Sophos;i="4.68,487,1312156800"; d="scan'208";a="5952949" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 04 Oct 2011 23:01:05 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8717.cisco.com [10.99.80.24]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p94N14Qs032135; Tue, 4 Oct 2011 23:01:04 GMT Message-Id: <201110042301.p94N14Qs032135@mtv-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 04 Oct 2011 18:01:02 -0500 To: Ted Lemon , "James M. Polk" From: "James M. Polk" In-Reply-To: References: <6B961032-728D-43D6-81E3-9862EF9ADA09@gmail.com> <2207D364-CADB-43D2-907B-204180A6E4CC@nominum.com> <201110032203.p93M3f5I031107@mtv-core-3.cisco.com> <5EA79C2C-F4A2-4D88-85DC-E2F4B931E11A@nominum.com> <201110041732.p94HW6s3000630@mtv-core-1.cisco.com> <67AEBF45-5C47-43B4-B86C-482ED32E41D3@nominum.com> <201110042006.p94K6NX8001171@mtv-core-3.cisco.com> <578BA924-AE98-4B72-8857-949C9B76D6F6@nominum.com> <478F3A8B-6ADE-4BC2-BCBE-7214AD983727@gmail.com> <201110042057.p94KvlAJ004802@mtv-core-3.cisco.com> <201110042246.p94MkXhY032052@mtv-core-1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "dhcwg@ietf.org WG" , Ralph Droms Subject: Re: [dhcwg] review of draft-ietf-geopriv-dhcp-lbyr-uri-option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 22:57:58 -0000 At 05:53 PM 10/4/2011, Ted Lemon wrote: >On Oct 4, 2011, at 6:46 PM, James M. Polk wrote: >>Geopriv wanted a new URI sent to the client every time it changes >>location because the location is now considered stale (or bad). >>Further, the URI sent to client A is always different than what is >>sent to any other client, even if on the same AP. Fine, I can live >>with that last part - though others might have an issue with it. >> >>Other comments, concerns or questions? > >Yes. They need a different protocol. DHCP can't do this. absolutely, which is why I wrote how to do this using SIP (http://www.ietf.org/internet-drafts/draft-ietf-sipcore-location-conveyance-09.txt) others wrote how to do this using HTTP (as HELD) but neither protocol extension (to SIP or HTTP) talked about keeping track of which hosts were sent a Location URI for a (semi)automatic refresh of the previous URI once it is determined that the location information is stale/bad. James From Ted.Lemon@nominum.com Tue Oct 4 16:10:14 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8025321F8E86 for ; Tue, 4 Oct 2011 16:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.576 X-Spam-Level: X-Spam-Status: No, score=-106.576 tagged_above=-999 required=5 tests=[AWL=0.022, 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 XR5k5ARakpW0 for ; Tue, 4 Oct 2011 16:10:14 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id ADA7721F8E76 for ; Tue, 4 Oct 2011 16:09:57 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP; Tue, 04 Oct 2011 16:13:19 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 C769F1B827A for ; Tue, 4 Oct 2011 16:12:55 -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 B4F25190065; Tue, 4 Oct 2011 16:12:55 -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; Tue, 4 Oct 2011 16:12:56 -0700 From: Ted Lemon To: "James M. Polk" Thread-Topic: [dhcwg] review of draft-ietf-geopriv-dhcp-lbyr-uri-option Thread-Index: AQHMggfbXjkViOtBlkentTTh6SBa8ZVrha+AgAAcNwCAABC0gIABNcEAgAAB8YCAACkqgIAABVuAgAABvwCAAAdDgIAAARMAgAAdTwCAAAHsgIAAAiEAgAADUIA= Date: Tue, 4 Oct 2011 23:12:54 +0000 Message-ID: References: <6B961032-728D-43D6-81E3-9862EF9ADA09@gmail.com> <2207D364-CADB-43D2-907B-204180A6E4CC@nominum.com> <201110032203.p93M3f5I031107@mtv-core-3.cisco.com> <5EA79C2C-F4A2-4D88-85DC-E2F4B931E11A@nominum.com> <201110041732.p94HW6s3000630@mtv-core-1.cisco.com> <67AEBF45-5C47-43B4-B86C-482ED32E41D3@nominum.com> <201110042006.p94K6NX8001171@mtv-core-3.cisco.com> <578BA924-AE98-4B72-8857-949C9B76D6F6@nominum.com> <478F3A8B-6ADE-4BC2-BCBE-7214AD983727@gmail.com> <201110042057.p94KvlAJ004802@mtv-core-3.cisco.com> <201110042246.p94MkXhY032052@mtv-core-1.cisco.com> <201110042301.p94N14Qs032135@mtv-core-2.cisco.com> In-Reply-To: <201110042301.p94N14Qs032135@mtv-core-2.cisco.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_CE1B6AC6B2B24CDD9AD16DBEBBBE8599nominumcom_" MIME-Version: 1.0 Cc: "dhcwg@ietf.org WG" , Ralph Droms Subject: Re: [dhcwg] review of draft-ietf-geopriv-dhcp-lbyr-uri-option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 23:10:14 -0000 --_000_CE1B6AC6B2B24CDD9AD16DBEBBBE8599nominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Oct 4, 2011, at 7:01 PM, James M. Polk wrote: but neither protocol extension (to SIP or HTTP) talked about keeping track = of which hosts were sent a Location URI for a (semi)automatic refresh of th= e previous URI once it is determined that the location information is stale= /bad. DHCP doesn't do that either. --_000_CE1B6AC6B2B24CDD9AD16DBEBBBE8599nominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <3A9755FF8C5B5941ACDC60FB3D094909@nominum.com> Content-Transfer-Encoding: quoted-printable
On Oct 4, 2011, at 7:01 PM, James M. Polk wrote:
but neither protocol extension (to SIP or HTTP) talked about keeping track of = which hosts were sent a Location URI for a (semi)automatic refresh of the p= revious URI once it is determined that the location information is stale/ba= d.

DHCP doesn't do that either.

--_000_CE1B6AC6B2B24CDD9AD16DBEBBBE8599nominumcom_-- From jmpolk@cisco.com Tue Oct 4 21:07:59 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1C5B21F8AD8 for ; Tue, 4 Oct 2011 21:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.161 X-Spam-Level: X-Spam-Status: No, score=-103.161 tagged_above=-999 required=5 tests=[AWL=-0.562, 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 YYTldN4Qkfc9 for ; Tue, 4 Oct 2011 21:07:41 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id AB50F21F86A5 for ; Tue, 4 Oct 2011 21:07:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=392; q=dns/txt; s=iport; t=1317787849; x=1318997449; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=leKXZrxv1VafeGS8ZOZud3OQW6zuE5zeR/eber365cE=; b=hVTN1yAws+Av7KxmlkY8DqNM4R6SNO5VoHwvB31rH2/0XKW9CoO1ovYB SssFpwHwz7VeAZ4aAOdsLsZn6PRXOD/FURKL+6kG0UtUYANIx0QgIVtfv +lEEeQxtF5VCq8503dE0rn8ECNsBQPx2sqblZvMoSJWls4+8k5CC2BuPc Y=; X-IronPort-AV: E=Sophos;i="4.68,489,1312156800"; d="scan'208";a="6000966" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 05 Oct 2011 04:10:48 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8717.cisco.com [10.99.80.24]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p954AlHY007711; Wed, 5 Oct 2011 04:10:48 GMT Message-Id: <201110050410.p954AlHY007711@mtv-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 04 Oct 2011 23:10:47 -0500 To: Ted Lemon , "James M. Polk" From: "James M. Polk" In-Reply-To: References: <6B961032-728D-43D6-81E3-9862EF9ADA09@gmail.com> <2207D364-CADB-43D2-907B-204180A6E4CC@nominum.com> <201110032203.p93M3f5I031107@mtv-core-3.cisco.com> <5EA79C2C-F4A2-4D88-85DC-E2F4B931E11A@nominum.com> <201110041732.p94HW6s3000630@mtv-core-1.cisco.com> <67AEBF45-5C47-43B4-B86C-482ED32E41D3@nominum.com> <201110042006.p94K6NX8001171@mtv-core-3.cisco.com> <578BA924-AE98-4B72-8857-949C9B76D6F6@nominum.com> <478F3A8B-6ADE-4BC2-BCBE-7214AD983727@gmail.com> <201110042057.p94KvlAJ004802@mtv-core-3.cisco.com> <201110042246.p94MkXhY032052@mtv-core-1.cisco.com> <201110042301.p94N14Qs032135@mtv-core-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "dhcwg@ietf.org WG" , Ralph Droms Subject: Re: [dhcwg] review of draft-ietf-geopriv-dhcp-lbyr-uri-option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 04:07:59 -0000 At 06:12 PM 10/4/2011, Ted Lemon wrote: >On Oct 4, 2011, at 7:01 PM, James M. Polk wrote: >>but neither protocol extension (to SIP or HTTP) talked about >>keeping track of which hosts were sent a Location URI for a >>(semi)automatic refresh of the previous URI once it is determined >>that the location information is stale/bad. > >DHCP doesn't do that either. nope, it doesn't From teemu.savolainen@nokia.com Wed Oct 5 01:12:05 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBB2B21F8513 for ; Wed, 5 Oct 2011 01:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.143 X-Spam-Level: X-Spam-Status: No, score=-3.143 tagged_above=-999 required=5 tests=[AWL=0.456, 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 qIw9oiksxwV0 for ; Wed, 5 Oct 2011 01:12:05 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 18CE321F84FD for ; Wed, 5 Oct 2011 01:12:05 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p958ErV6019417; Wed, 5 Oct 2011 11:15:11 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 5 Oct 2011 11:14:36 +0300 Received: from 008-AM1MMR1-002.mgdnok.nokia.com (65.54.30.57) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 5 Oct 2011 10:14:35 +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; Wed, 5 Oct 2011 10:14:34 +0200 From: To: , Thread-Topic: [dhcwg] Call for review: draft-ietf-mif-dns-server-selection-04.txt Thread-Index: AQHMguKczsAt94FrQEezhHcPWyA3B5VtZfLQ Date: Wed, 5 Oct 2011 08:14:34 +0000 Message-ID: <916CE6CF87173740BC8A2CE4430969620377722C@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+/nZJb9Kg7IkxE1ZbYbe1tqgA8/XISd7i6L6Xpnks3knBmET6wFQit0nV3rwfYOugnSQFYZbZgohb6OjiNKZLJRYiS2rTUXBxMEqdAOGDl6uRarv1qItPS0XVlPLl966gXbcN8JOUv5rCzDhoQD/IJuvsukHC1MgW4Kibbx3A/vCOUnto3dMYcpSZHXZqVR96DqZxqRwhsPdXJoA5c2E+uiQ09qtSm1I1Lp9JqP9+C+BRRXEEAPD1aUVLiqRHgrNJBW449SEt68/IXOYp086tlAarJzzRm+GE= x-originating-ip: [10.162.26.87] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_01E3_01CC834F.F50EBAA0" MIME-Version: 1.0 X-OriginalArrivalTime: 05 Oct 2011 08:14:36.0400 (UTC) FILETIME=[D224C700:01CC8336] X-Nokia-AV: Clean Subject: Re: [dhcwg] Call for review: draft-ietf-mif-dns-server-selection-04.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 08:12:05 -0000 ------=_NextPart_000_01E3_01CC834F.F50EBAA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Matt, Thank you for your comments, inline: > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf > Of ext Matthew Ryan > Sent: 05. lokakuuta 2011 01:12 > To: dhc WG > Subject: Re: [dhcwg] Call for review: draft-ietf-mif-dns-server-selection- > 04.txt > > I have two comments on the option formats for this draft. > > First, I note that the DHCPv6 version has the preference value occupying the > two most-significant bits of the octet in which they appear, while in the > DHCPv4 version, they occupy the two least-significant bits. No reason for > this different is given that I can see, and I can't think of one of the top of my > head. > > Unless there is some driving need, they should be the same for consistency's > sake. Good point, it is that way by accident and I will change for next rev. Which one btw is better? Nicer to check in code if least-significant bits are used, perhaps (0, 1, 2, 3 in decimal)? > Second, the format of the DHCPv4 option as currently defined will almost > certainly require special-case code in DHCP servers and management > consoles to provide formatted display and config- uration (as opposed to an > opaque blob of hex), which will hinder its adoption. > > Converting the "domain count" into a octet-length of the following fields > (reserved/prf, address, domains-and-networks) would make it much simpler > to parse, by not requiring the DHCP server to count domains in order to find > the start of a potential second (concatenated) option. Even this, while > cleaner to implement (a generic length-prefix container), would likely require > new code in some servers, so other implementors should weigh in here. I'm not sure I fully get this concern. Why would not the option-len field be suitable for that purpose? Best regards, Teemu ------=_NextPart_000_01E3_01CC834F.F50EBAA0 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTExMDA1MDgxNDMyWjAjBgkqhkiG9w0B CQQxFgQUWvByK1CmbC9h8nGEk+StZRp3wA4wVgYJKwYBBAGCNxAEMUkwRzAzMQswCQYDVQQGEwJG STEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLx MFgGCyqGSIb3DQEJEAILMUmgRzAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNV BAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLxMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMA0GCSqGSIb3DQEBAQUABIIBABzDUoQyZnVsThADpV0V 7zn8OiuXJ77gdKEw1l8yocANpZAmhiZuSIlOceAwyathlLPMmsT8qlzHmyB50NgmsLxUkkpHN35J BTQGiNd2AoLrcE9DZ0Z+6YzvhKhC20SwwCGzytd5n6/cgh2JNiP0pi6AcrM1NQu3f3WDiRDo0SDX Q+FnuD80mGPOmEr8unDAF3/a+Egge2aymRNObjF1NGQe9VezDK3xmEc+QCfQeHK+HLnLnunp5SUQ IQaYBBboLONlO93NR/9UmLpavcnIalAU+Jk6hi/Gu2B/2YzsQhHmEgWG6yYXzokcFqwqTfvjcAhI Wr4Hhk5+dWyYLHXAdpsAAAAAAAA= ------=_NextPart_000_01E3_01CC834F.F50EBAA0-- From Matt.Ryan@nominum.com Wed Oct 5 10:15:58 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F5971F0C49 for ; Wed, 5 Oct 2011 10:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 WUuNu78bw281 for ; Wed, 5 Oct 2011 10:15:57 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2F53A1F0C48 for ; Wed, 5 Oct 2011 10:15:54 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP; Wed, 05 Oct 2011 10:19:06 PDT Received: from vir.ddns.nominum.com (vir.ddns.nominum.com [64.89.225.15]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by shell-too.nominum.com (Postfix) with ESMTP id 7DC551B82A2; Wed, 5 Oct 2011 10:18:55 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Matthew Ryan In-Reply-To: <916CE6CF87173740BC8A2CE4430969620377722C@008-AM1MPN1-037.mgdnok.nokia.com> Date: Wed, 5 Oct 2011 10:18:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <415AECEA-6927-4F62-BD6B-44E0B39A0D2B@nominum.com> References: <916CE6CF87173740BC8A2CE4430969620377722C@008-AM1MPN1-037.mgdnok.nokia.com> To: "teemu.savolainen@nokia.com> , dhc WG X-Mailer: Apple Mail (2.1084) Subject: Re: [dhcwg] Call for review: draft-ietf-mif-dns-server-selection-04.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 17:15:58 -0000 Responses inline: On Oct 5, 2011, at 01:14 , = wrote: [re: preference value positions in octets being different between v4 and = v6] >=20 > Good point, it is that way by accident and I will change for next rev. = Which > one btw is better? Nicer to check in code if least-significant bits = are > used, perhaps (0, 1, 2, 3 in decimal)? Likely. >=20 >> Second, the format of the DHCPv4 option as currently defined will = almost >> certainly require special-case code in DHCP servers and management >> consoles to provide formatted display and config- uration (as opposed = to > an >> opaque blob of hex), which will hinder its adoption. >>=20 >> Converting the "domain count" into a octet-length of the following = fields >> (reserved/prf, address, domains-and-networks) would make it much = simpler >> to parse, by not requiring the DHCP server to count domains in order = to > find >> the start of a potential second (concatenated) option. Even this, = while >> cleaner to implement (a generic length-prefix container), would = likely > require >> new code in some servers, so other implementors should weigh in here. >=20 > I'm not sure I fully get this concern. Why would not the option-len = field be > suitable for that purpose? DHCPv4 option concatenation is not a way to get multiple instances of a given option, but rather a way to encode a /single/ instance that is longer than 255 bytes. I'll quote from David Hankins' option guidelines draft [draft-ietf-dhc-option-guidelines-07]: DHCP software processing these fragments will concatenate them, in the order they appear as defined by [RFC2131], prior to evaluating their contents. This is an important distinction that is sometimes overlooked by authors - these multiple options are not individually formatted to convey one unit of information precisely as you have defined, but rather one option that has been split along any = arbitrary octet boundary into multiple containers. What this boils down to is that, when a server or client is parsing a packet, the contents of the multiple instances of your option will be concatenated together into a single buffer, and then parsed according to the expected content format, so the option-length octet is likely not available to use as a marker. The DHCPv4 version of your option should instead be defined as a list of (reserved/pref, server address, domains-and-networks). And, since the domains-and-networks part is of indeterminate length, you need a way to define the length of it, which is why you needed the domain count field. I suggested replacing domain count with an octet count because it would be more general, and less likely to have the entire option definition require custom code to implement, as there are no other options I can think of at the moment which use the "DNS Wire Format Domain Name List" format along with a count of domains elsewhere in the option. There are, on the other hand, several instances of length-prefixed octet strings (RFC-3925, RFC-3004). So, one possible way of defining this option would be (stealing from RFC-3004): The format of this option is as follows: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5=20 +---------------+---------------+ | option-code | option-len | +---------------+---------------+ | | : option-value : | | +-------------------------------+ where option-value consists of one or more instances of DNS Server Selection Data. Each instance of DNS Server Selection Data is formatted as follows: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Len | Reserved |prf| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DNS recursive name server | | (IPv4 address) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : Domains and networks : : (variable length) : +-------------------------------+ =20 It is not lost on me that my proposed format also does not stay within the option-guidelines draft, but it is easier to implement. - Matt From john_brzozowski@cable.comcast.com Thu Oct 6 04:47:09 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8363521F8678 for ; Thu, 6 Oct 2011 04:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.379 X-Spam-Level: X-Spam-Status: No, score=-102.379 tagged_above=-999 required=5 tests=[AWL=-0.644, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 3MdFbEABdT64 for ; Thu, 6 Oct 2011 04:47:09 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id D1DBB21F8557 for ; Thu, 6 Oct 2011 04:47:08 -0700 (PDT) Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP id 5503630.55992471; Thu, 06 Oct 2011 05:57:00 -0600 Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0289.001; Thu, 6 Oct 2011 07:50:07 -0400 From: "Brzozowski, John" To: dhc WG Thread-Topic: Request for agenda items (First call) Thread-Index: AQHMhB4XlJCSv0oLzE27ZV7Th8FQrw== Date: Thu, 6 Oct 2011 11:50:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [147.191.125.12] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dhc Chairs Subject: [dhcwg] Request for agenda items (First call) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 11:47:09 -0000 Please send agenda items requests to Ted and myself for the upcoming dhcwg meeting at IETF82. Thank you! John =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski@cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From Ted.Lemon@nominum.com Thu Oct 6 08:49:23 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADD7C21F8D9D for ; Thu, 6 Oct 2011 08:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.577 X-Spam-Level: X-Spam-Status: No, score=-106.577 tagged_above=-999 required=5 tests=[AWL=0.021, 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 qpjAQ6Jsg+gl for ; Thu, 6 Oct 2011 08:49:23 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id 010AB21F8D94 for ; Thu, 6 Oct 2011 08:49:22 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP; Thu, 06 Oct 2011 08:52:34 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 7658C1B82B9 for ; Thu, 6 Oct 2011 08:52:32 -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 ED157190061; Thu, 6 Oct 2011 08:52:28 -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; Thu, 6 Oct 2011 08:52:29 -0700 From: Ted Lemon To: "Brzozowski, John" Thread-Topic: [dhcwg] Request for agenda items (First call) Thread-Index: AQHMhB4XlJCSv0oLzE27ZV7Th8FQr5Vv7QWA Date: Thu, 6 Oct 2011 15:52:28 +0000 Message-ID: <940FEFC3-262E-493D-BFAA-2BEFB8176F07@nominum.com> References: In-Reply-To: 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_940FEFC3262E493DBFAA2BEFB8176F07nominumcom_" MIME-Version: 1.0 Cc: dhc WG Subject: Re: [dhcwg] Request for agenda items (First call) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 15:49:23 -0000 --_000_940FEFC3262E493DBFAA2BEFB8176F07nominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Oct 6, 2011, at 7:50 AM, Brzozowski, John wrote: Please send agenda items requests to Ted and myself for the upcoming dhcwg meeting at IETF82. Let me rephrase that slightly. If you have something you'd like to discus= s at IETF 82, please bring it up on the mailing list now and let's get a co= nversation started, so that we have something to talk about when we get to = Taipei. The mailing list is where IETF business is supposed to happen, and = we've been having a lot of stuff get discussed in WG meetings that doesn't = get discussed on the mailing list in any meaningful way. --_000_940FEFC3262E493DBFAA2BEFB8176F07nominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <3237F2090D063745AD396F2ED1D11AD1@nominum.com> Content-Transfer-Encoding: quoted-printable
On Oct 6, 2011, at 7:50 AM, Brzozowski, John wrote:
Please send agenda items requests to Ted and myself for the upcoming dhcwg
meeting at IETF82.

Let me rephrase that slightly.   If you have something you'd like= to discuss at IETF 82, please bring it up on the mailing list now and let'= s get a conversation started, so that we have something to talk about when = we get to Taipei. The mailing list is where IETF business is supposed to happen, and we've been having a lot of = stuff get discussed in WG meetings that doesn't get discussed on the mailin= g list in any meaningful way.

--_000_940FEFC3262E493DBFAA2BEFB8176F07nominumcom_-- From acooper@cdt.org Fri Oct 7 08:30:37 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68A8A21F8C1F for ; Fri, 7 Oct 2011 08:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, 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 p2h3iJPS2k9l for ; Fri, 7 Oct 2011 08:30:37 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id C657A21F8C1D for ; Fri, 7 Oct 2011 08:30:36 -0700 (PDT) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Fri, 7 Oct 2011 11:33:40 -0400 From: Alissa Cooper Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 7 Oct 2011 16:33:45 +0100 Message-Id: To: dhcwg@ietf.org, "James M. Polk" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: Re: [dhcwg] review of draft-ietf-geopriv-dhcp-lbyr-uri-option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 15:30:37 -0000 James Polk wrote: > This wasn't my idea. This was something several members of the Geopriv = WG wanted, and the chairs directed me to incorporate it into the draft. > Geopriv as a WG is worried about location information becoming or = being stale (i.e., old or out of date or "no longer valid/applicable"). = I tried to argue that what this doc does is create a means to download = the URI pointing to the location information (of a client) that can = change without updating the URI.But some believed (and still do) that if = the location of the client changes, so must the URI. > I lost that battle. Hi James -- Could you post a link to the geopriv discussion you are = referencing? Thanks, Alissa From jiangsheng@huawei.com Sat Oct 8 00:14:28 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E1FD21F8B3C for ; Sat, 8 Oct 2011 00:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.32 X-Spam-Level: X-Spam-Status: No, score=-6.32 tagged_above=-999 required=5 tests=[AWL=0.278, 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 GCshpBfrFHxT for ; Sat, 8 Oct 2011 00:14:20 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 3740321F86AA for ; Sat, 8 Oct 2011 00:14:20 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSQ00G3EK98Y6@szxga03-in.huawei.com> for dhcwg@ietf.org; Sat, 08 Oct 2011 15:17:32 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSQ00D03K977K@szxga03-in.huawei.com> for dhcwg@ietf.org; Sat, 08 Oct 2011 15:17:32 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEC73844; Sat, 08 Oct 2011 15:17:01 +0800 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Sat, 08 Oct 2011 15:16:52 +0800 Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.124]) by szxeml401-hub.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Sat, 08 Oct 2011 15:16:54 +0800 Date: Sat, 08 Oct 2011 07:16:53 +0000 From: Sheng Jiang In-reply-to: X-Originating-IP: [10.108.4.60] To: David Hankins Message-id: <5D36713D8A4E7348A7E10DF7437A4B9201268307@SZXEML506-MBS.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_aRINEwLcgD3pu3eEXi7ZrQ)" Content-language: zh-CN Accept-Language: en-GB, zh-CN, en-US Thread-topic: [dhcwg] Review of draft-ietf-dhc-option-guidelines Thread-index: AcxX/wF+rNDlhGCESMaq982wYvF4KQofBVgAAUNeZ9A= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <5D36713D8A4E7348A7E10DF7437A4B920122B5BD@SZXEML506-MBS.china.huawei.com> Cc: dhc WG Subject: Re: [dhcwg] Review of draft-ietf-dhc-option-guidelines X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2011 07:14:28 -0000 --Boundary_(ID_aRINEwLcgD3pu3eEXi7ZrQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, David, See your new version that had incorporated my comments. Thanks. Some of them are only my personal understanding, your explanation of your intending in the mail are good enough for me. Still two points below. Sheng> 1. Separating DHCPv4 and DHCPv6 would make the discussion more explicitly and targeting right readers. Say, one who is designing a new DHCPv6 option would not care how this may relevant to a DHCPv4 option. David> I agree, but I don't really have the time to separate the draft. :( If you also prefer separated documents. I can help. :) Sheng> 12. That the address is better than FQDN is a bad example for we should separate DHCPv4 and DHCPv6 discussion. FQDN has become favourite over IPv6 address in many recent DHCPv6 option design. We have RFC6334, draft-ietf-mif-dhcpv6-route-option and etc. The FQDN is more flexible and may benefit in load-balance scenarios. David> I don't agree. The FQDN has been selected in recent work despite that it is technically inferior. The entirely non-technical motivations for those decisions will continue to over-rule any guidelines we set here. I won't say FQDN is always better than address. But it does have some technical advantages: better for load balancing, single failure, redundancy, etc, although its better readability may not important in machine world. Best regards, Sheng From: David Hankins [mailto:dhankins@google.com] Sent: Sunday, October 02, 2011 12:46 PM To: Sheng Jiang Cc: dhc WG Subject: Re: [dhcwg] Review of draft-ietf-dhc-option-guidelines I'm finally getting time to work on this again... On Thu, Aug 11, 2011 at 1:16 AM, Jiangsheng > wrote: As agreed in the IETF 81 meeting, I have reviewed draft-ietf-dhc-option-guidelines and have below comments. Overall, this guideline is very useful. If it was published, it should be recommended in DHC WG charter page. 1. The very first and maybe the most important comment is: it is better to separate DHCPv4 and DHCPv6. It means we should have two dedicated drafts for DHCPv4 and DHCPv6. DHCPv4 and DHCPv6 are similar, but two different protocols. Some of discussions may be common between them, some of discussion may have very different base. Combining this discussion may harmful. Section 9, "option size" is an example. The option size requirements for DHCPv4 and DHCPv6 are different. Separating them would make the discussion more explicitly and targeting right readers. Say, one who is designing a new DHCPv6 option would not care how this may relevant to a DHCPv4 option. Furthermore, if DHCPv4 option space has freeze or will freeze, guidelines for new DHCPv4 option may be meaningless. I agree, but I don't really have the time to separate the draft. :( 2. In the introduction section, this draft mentioned support for unknown options. It is unclear for me, at least from the draft contents, how this can happen? It may be possible to add new option at the server side, how the client support it? The ISC DHCP client and server share the same mechanism described in the Appendix. My understanding of the Windows DHCP client is that it stores a copy of anything it receives in the registry and applications that require or support a new option will fetch it there. Unfortunately, my memory is that there isn't a way to add the option to the PRL. The dhcpinform-clarify draft documents for example the behavior of the Industry Updater ("Windows Updates"), which tickles the DHCP client to send a new set of DHCPINFORMs requesting option 252 - an option not supported (or not requested) by the base DHCP client, but desired by the Industry Updater. The Solaris client, if memory serves, has an extensive configuration in /etc/dhcp. Operators can manipulate the parameter request list, and have it request new options. Again these are stored in a place with a consistent format so the operator's tools can fetch values. More frequently however this feature is most useful to the DHCP Server operator, as you have indicated. 3. The section 2, "when to use DHCP" does not mentioned "IP address configuration", which is the most important usage of DHCP. Unless this text is dedicate for new DHCP option (the current text does not claim so), IP address configuration should be added. Well, the section was intended to help with the situation where you have a specified problem, and you are asking if DHCP should be used in the solution. Certainly, IP addressing is already handled, but so too should it be appropriate to resolve new addressing problems with DHCP. I tried to provide the generic answer to that question - "any knob, dial, or slider", and only list some examples. It isn't meant to be a complete list. I certainly think "my IP address" counts as host configuration. Do you think the current text is acceptable? 4. Disagree on the order of "when to use DHCP". The current text suggests using DHCP is first because client want information. But, in my understanding, network administration want to push/enforce some configuration is the most important requirements. The order isn't intended to convey importance...but I think they are of equal importance actually. It's certainly true that in some cases clients only have a knob because administrators want to be able to set it. But I don't think for most new options that that is always the case; usually some new protocol or client feature needs a conveyance for configuration state. 5. The draft states, in section 2, "the client still reserves the right to ignore values received via DHCP". That's right. But this may be at their own risk to be rejected by network administration. This kind of observation should also mentioned. Otherwise, the above next may be misleading: client can ignore DHCP configuration without any effect. This section is specifically trying to answer the question of whether it's appropriate to use DHCP for a particular problem statement. I don't want to get encumbered in the minutiae of protocol implementation... The specific problem we've had with objection to using DHCP in a few cases is "we don't want to use DHCP for new protocol X, because I (an IETF attendee) want to be able to configure my laptop myself." If the protocol workers are quite happy being configured by the network administrator, that is already a solved problem. 6. At the end of section 4, there are some rules how to organize values in the option. There should be more, such as the order of fixed size values, the order of multiple variable sized values. I don't think there are any current best practices. We don't sweat micro alignment for particular integer lengths (and it'll be ruined by other options in the payload anyway). However I think the language is a bit stilted for variable length options. In DHCPv4 the main variable length options would simply use the rest of the option data. In DHCPv6 there are some variable length formats. So there are a few things we've seen that we're trying to avoid. The first is defining 6 options for one protocol (which is hard on DHCPv4), where the client would request all 6 all the time. The second was an option I recall that wanted to use a NVT ascii string, followed by a zero byte (NULL value), followed by various fixed length values. The NULL in this case wastes an octet, purely because of ordering, and complicates client parsing (there's no support for such a thing in most software). 7. section 5, using the conclusion as title can be more explicit: "avoid conditional formatting". This also looks like the title of section 6. Done. 8. the title of section 6 has a typo: avoid alciasing/aliasing I don't know if I already fixed this, but it's fixed in my xml copy. 9. "in the case where the server is configured with all formats, DHCP option space is wasted on option contents that are redundant". This is not necessary true - usage of sub-option can reduce the dhcp option type to be only 1. Although the usage of sub-option is not recommended in the next section. The readers may have question here. Suggest to add one sentence for sub-option and refer to next section. So, here I think we are talking about an unfortunately overloaded terminology. The "options space" in the DHCPv4 packet (the area after the BOOTP header) is here referred to as the options space. The text isn't referring to the DHCPv4 option code space. :( 10. Title of section 7 is misleading. It looks like it will introduce several new formats in this section. Suggest to change as "consideration on creating new formats". Good point, it's now "Considerations for Creating New Formats". 11. in Section 9, the discussion regarding to DHCPv6 cannot draw the conclusion "prefer option formats...in the SMALLEST form factor". Be clear, I do agree the conclusion, but not the analysis. Do you think it is possible to describe a specific upper fixed limit for DHCPv6 in all deployments? I don't see how the conclusion isn't supported by the evidence. 12. That the address is better than FQDN is a bad example for we should separate DHCPv4 and DHCPv6 discussion. FQDN has become favourite over IPv6 address in many recent DHCPv6 option design. We have RFC6334, draft-ietf-mif-dhcpv6-route-option and etc. The FQDN is more flexible and may benefit in load-balance scenarios. I don't agree. The FQDN has been selected in recent work despite that it is technically inferior. The entirely non-technical motivations for those decisions will continue to over-rule any guidelines we set here. 13. This draft says nothing about option orders, which is also important. The principle should be not give any specific order when design a new DHCP option. The option should be allowed to appear any place in the DHCP message. The only exception is security option(s). They need to perform algorithm over all other options. They may be allowed to located at the end. It gets very hard to write concise language here, since the DHCPv6 style of options is for options to contain options whose codes are taken from the same option spaces. "Anywhere in the packet" is nice and simple, but very wrong in DHCPv6. 14. draft-ietf-dhc-secure-dhcpv6 should be mentioned in the security consideration section. If it deployed, some threats, like man-in-middle can be prevented since it introduced an data integrity protection for DHCPv6 messages. Are option contents authors going to format their options differently from this information? Mostly, I'd prefer not to gate publication of the draft on the publication of another draft. 15. The text regarding to fixed/variable length options in security consideration section looks mis-located for me. They are not security relevant. Buffer overflows are security problems, especially since most DHCP client software is run by the system's super-user (or in simple firmware, having no user separation). An author of a DHCP option draft would do well to try to think about how they can word the presentation of their option to enhance an implementor's wariness of buffer overruns. -- David W. Hankins SRE - Systems Engineer Google, Inc. --Boundary_(ID_aRINEwLcgD3pu3eEXi7ZrQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi, David,

 

See your new version that had incorporated my comments. Thanks. Some of them are only my personal understanding, your explanation of your intending in the mail are good enough for me.

 

Still two points below.

 

Sheng> 1. Separating DHCPv4 and DHCPv6 would make the discussion more explicitly and targeting right readers. Say, one who is designing a new DHCPv6 option would not care how this may relevant to a DHCPv4 option.

David> I agree, but I don't really have the time to separate the draft. :(

 

If you also prefer separated documents. I can help. :)

 

Sheng> 12. That the address is better than FQDN is a bad example for we should separate DHCPv4 and DHCPv6 discussion. FQDN has become favourite over IPv6 address in many recent DHCPv6 option design. We have RFC6334, draft-ietf-mif-dhcpv6-route-option and etc. The FQDN is more flexible and may benefit in load-balance scenarios.

 

David> I don't agree.  The FQDN has been selected in recent work despite that it is technically inferior. The entirely non-technical motivations for those decisions will continue to over-rule any guidelines we set here.

 

I won’t say FQDN is always better than address. But it does have some technical advantages: better for load balancing, single failure, redundancy, etc, although its better readability may not important in machine world.

 

Best regards,

 

Sheng

 

 

From: David Hankins [mailto:dhankins@google.com]
Sent: Sunday, October 02, 2011 12:46 PM
To: Sheng Jiang
Cc: dhc WG
Subject: Re: [dhcwg] Review of draft-ietf-dhc-option-guidelines

 

I'm finally getting time to work on this again...

 

On Thu, Aug 11, 2011 at 1:16 AM, Jiangsheng <jiangsheng@huawei.com> wrote:

As agreed in the IETF 81 meeting, I have reviewed draft-ietf-dhc-option-guidelines and have below comments.

Overall, this guideline is very useful. If it was published, it should be recommended in DHC WG charter page.

1. The very first and maybe the most important comment is: it is better to separate DHCPv4 and DHCPv6. It means we should have two dedicated drafts for DHCPv4 and DHCPv6. DHCPv4 and DHCPv6 are similar, but two different protocols. Some of discussions may be common between them, some of discussion may have very different base. Combining this discussion may harmful. Section 9, "option size" is an example. The option size requirements for DHCPv4 and DHCPv6 are different.

Separating them would make the discussion more explicitly and targeting right readers. Say, one who is designing a new DHCPv6 option would not care how this may relevant to a DHCPv4 option.

Furthermore, if DHCPv4 option space has freeze or will freeze, guidelines for new DHCPv4 option may be meaningless.

 

I agree, but I don't really have the time to separate the draft. :(

 

2. In the introduction section, this draft mentioned support for unknown options. It is unclear for me, at least from the draft contents, how this can happen? It may be possible to add new option at the server side, how the client support it?

 

The ISC DHCP client and server share the same mechanism described in the Appendix.

 

My understanding of the Windows DHCP client is that it stores a copy of anything it receives in the registry and applications that require or support a new option will fetch it there.  Unfortunately, my memory is that there isn't a way to add the option to the PRL.  The dhcpinform-clarify draft documents for example the behavior of the Industry Updater ("Windows Updates"), which tickles the DHCP client to send a new set of DHCPINFORMs requesting option 252 - an option not supported (or not requested) by the base DHCP client, but desired by the Industry Updater.

 

The Solaris client, if memory serves, has an extensive configuration in /etc/dhcp.  Operators can manipulate the parameter request list, and have it request new options.  Again these are stored in a place with a consistent format so the operator's tools can fetch values.

 

More frequently however this feature is most useful to the DHCP Server operator, as you have indicated.

 

3. The section 2, "when to use DHCP" does not mentioned "IP address configuration", which is the most important usage of DHCP. Unless this text is dedicate for new DHCP option (the current text does not claim so), IP address configuration should be added.

 

Well, the section was intended to help with the situation where you have a specified problem, and you are asking if DHCP should be used in the solution.  Certainly, IP addressing is already handled, but so too should it be appropriate to resolve new addressing problems with DHCP.

 

I tried to provide the generic answer to that question - "any knob, dial, or slider", and only list some examples.  It isn't meant to be a complete list.  I certainly think "my IP address" counts as host configuration.

 

Do you think the current text is acceptable?

 

4. Disagree on the order of "when to use DHCP". The current text suggests using DHCP is first because client want information. But, in my understanding, network administration want to push/enforce some configuration is the most important requirements.

 

The order isn't intended to convey importance...but I think they are of equal importance actually.

 

It's certainly true that in some cases clients only have a knob because administrators want to be able to set it.  But I don't think for most new options that that is always the case; usually some new protocol or client feature needs a conveyance for configuration state.

 

5. The draft states, in section 2, "the client still reserves the right to ignore values received via DHCP". That's right. But this may be at their own risk to be rejected by network administration. This kind of observation should also mentioned. Otherwise, the above next may be misleading: client can ignore DHCP configuration without any effect.

 

This section is specifically trying to answer the question of whether it's appropriate to use DHCP for a particular problem statement.  I don't want to get encumbered in the minutiae of protocol implementation...

 

The specific problem we've had with objection to using DHCP in a few cases is "we don't want to use DHCP for new protocol X, because I (an IETF attendee) want to be able to configure my laptop myself."

 

If the protocol workers are quite happy being configured by the network administrator, that is already a solved problem.

 

6. At the end of section 4, there are some rules how to organize values in the option. There should be more, such as the order of fixed size values, the order of multiple variable sized values.

 

I don't think there are any current best practices.  We don't sweat micro alignment for particular integer lengths (and it'll be ruined by other options in the payload anyway).

 

However I think the language is a bit stilted for variable length options.  In DHCPv4 the main variable length options would simply use the rest of the option data.  In DHCPv6 there are some variable length formats.

 

So there are a few things we've seen that we're trying to avoid.

 

The first is defining 6 options for one protocol (which is hard on DHCPv4), where the client would request all 6 all the time.

 

The second was an option I recall that wanted to use a NVT ascii string, followed by a zero byte (NULL value), followed by various fixed length values.  The NULL in this case wastes an octet, purely because of ordering, and complicates client parsing (there's no support for such a thing in most software).

 

7. section 5, using the conclusion as title can be more explicit: "avoid conditional formatting". This also looks like the title of section 6.

 

Done.

 

8. the title of section 6 has a typo: avoid alciasing/aliasing

 

I don't know if I already fixed this, but it's fixed in my xml copy.

 

9. "in the case where the server is configured with all formats, DHCP option space is wasted on option contents that are redundant". This is not necessary true - usage of sub-option can reduce the dhcp option type to be only 1. Although the usage of sub-option is not recommended in the next section. The readers may have question here. Suggest to add one sentence for sub-option and refer to next section.

 

So, here I think we are talking about an unfortunately overloaded terminology.

 

The "options space" in the DHCPv4 packet (the area after the BOOTP header) is here referred to as the options space.

 

The text isn't referring to the DHCPv4 option code space. :(

 

10. Title of section 7 is misleading. It looks like it will introduce several new formats in this section. Suggest to change as "consideration on creating new formats".

 

Good point, it's now "Considerations for Creating New Formats".

 

11. in Section 9, the discussion regarding to DHCPv6 cannot draw the conclusion "prefer option formats...in the SMALLEST form factor". Be clear, I do agree the conclusion, but not the analysis.

 

Do you think it is possible to describe a specific upper fixed limit for DHCPv6 in all deployments?

 

I don't see how the conclusion isn't supported by the evidence.

 

12. That the address is better than FQDN is a bad example for we should separate DHCPv4 and DHCPv6 discussion. FQDN has become favourite over IPv6 address in many recent DHCPv6 option design. We have RFC6334, draft-ietf-mif-dhcpv6-route-option and etc. The FQDN is more flexible and may benefit in load-balance scenarios.

 

I don't agree.  The FQDN has been selected in recent work despite that it is technically inferior.

 

The entirely non-technical motivations for those decisions will continue to over-rule any guidelines we set here.

 

13. This draft says nothing about option orders, which is also important. The principle should be not give any specific order when design a new DHCP option. The option should be allowed to appear any place in the DHCP message. The only exception is security option(s). They need to perform algorithm over all other options. They may be allowed to located at the end.

 

It gets very hard to write concise language here, since the DHCPv6 style of options is for options to contain options whose codes are taken from the same option spaces.  "Anywhere in the packet" is nice and simple, but very wrong in DHCPv6.

 

14. draft-ietf-dhc-secure-dhcpv6 should be mentioned in the security consideration section. If it deployed, some threats, like man-in-middle can be prevented since it introduced an data integrity protection for DHCPv6 messages.

 

Are option contents authors going to format their options differently from this information?

 

Mostly, I'd prefer not to gate publication of the draft on the publication of another draft.

 

15. The text regarding to fixed/variable length options in security consideration section looks mis-located for me. They are not security relevant.

 

Buffer overflows are security problems, especially since most DHCP client software is run by the system's super-user (or in simple firmware, having no user separation).  An author of a DHCP option draft would do well to try to think about how they can word the presentation of their option to enhance an implementor's wariness of buffer overruns.

 

--

David W. Hankins

SRE - Systems Engineer

Google, Inc.

--Boundary_(ID_aRINEwLcgD3pu3eEXi7ZrQ)-- From tomasz.mrugalski@gmail.com Sat Oct 8 00:33:41 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 154C521F8B1F for ; Sat, 8 Oct 2011 00:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.79 X-Spam-Level: X-Spam-Status: No, score=-3.79 tagged_above=-999 required=5 tests=[AWL=-0.191, 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 ZR2NbKkojC5g for ; Sat, 8 Oct 2011 00:33:40 -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 5350921F8876 for ; Sat, 8 Oct 2011 00:33:40 -0700 (PDT) Received: by wyg24 with SMTP id 24so1663140wyg.31 for ; Sat, 08 Oct 2011 00:36:55 -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-enigmail-version:content-type :content-transfer-encoding; bh=UFzVaZPoJBjKKS65B/UKayyaRXb2mssUw5P7vTNh7vU=; b=eiF7Pn1wI0iLrrS0DWs0dJjVr3ohgpJkxoqQLBpNzlU+w2eB4slUW75Iys5WU0hovz 9b/Tec+39C30zN30XCZYALXqJO76o1NdcIe8RxyAR88Ml88MWGVY/Vcuptkel/QyszRh CN0PceOIYngFsCnuezNKdnZ6AVasXQ8xFvcSg= Received: by 10.216.133.160 with SMTP id q32mr1747651wei.108.1318059415461; Sat, 08 Oct 2011 00:36:55 -0700 (PDT) Received: from MacBook-Tomasz-Mrugalski.local (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPS id n21sm20258809wbp.2.2011.10.08.00.36.53 (version=SSLv3 cipher=OTHER); Sat, 08 Oct 2011 00:36:54 -0700 (PDT) Message-ID: <4E8FFD94.30400@gmail.com> Date: Sat, 08 Oct 2011 09:36:52 +0200 From: Tomasz Mrugalski User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15 MIME-Version: 1.0 To: dhcwg@ietf.org References: <5D36713D8A4E7348A7E10DF7437A4B920122B5BD@SZXEML506-MBS.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B9201268307@SZXEML506-MBS.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B9201268307@SZXEML506-MBS.china.huawei.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [dhcwg] Review of draft-ietf-dhc-option-guidelines X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2011 07:33:41 -0000 On 11-10-08 09:16, Sheng Jiang wrote: > Still two points below. Just a small comment about one of them. > Sheng> 12. That the address is better than FQDN is a bad example for we > should separate DHCPv4 and DHCPv6 discussion. FQDN has become favourite > over IPv6 address in many recent DHCPv6 option design. We have RFC6334, > draft-ietf-mif-dhcpv6-route-option and etc. The FQDN is more flexible > and may benefit in load-balance scenarios. In RFC6334 we decided to go with FQDN after very lengthy discussion. See various posts about this on Softwire list if you are insterested in details. Both approaches has their merits and drawbacks. Generalizing this as "always prefer FQDN" or "always prefer address" would not be appropriate. I would recommend something like "prefer address, unless FQDN benefits are really needed". Also, where did read that draft-ietf-mif-dhcpv6-route-option suggest FQDN? All options defined there contain only addresses. Is there any text that suggest otherwise? If that is so, please point it out and I'll clarify the text. > I won抰 say FQDN is always better than address. But it does have some > technical advantages: better for load balancing, single failure, > redundancy, etc, although its better readability may not important in > machine world. Agree. Cheers, Tomek From Martin.Thomson@commscope.com Sun Oct 9 21:22:52 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E7B821F8B0D for ; Sun, 9 Oct 2011 21:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=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 l268j3HCMVaz for ; Sun, 9 Oct 2011 21:22:51 -0700 (PDT) Received: from cdcsmgw01.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id 36BD321F8AF4 for ; Sun, 9 Oct 2011 21:22:51 -0700 (PDT) X-AuditID: 0a0404e8-b7c2eae000002297-49-4e9273190427 Received: from ACDCE7HC1.commscope.com ( [10.86.20.102]) by cdcsmgw01.commscope.com (Symantec Brightmail Gateway) with SMTP id C9.1B.08855.913729E4; Sun, 9 Oct 2011 23:22:49 -0500 (CDT) Received: from CDCE10HC1.commscope.com (10.86.28.21) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.3.192.1; Sun, 9 Oct 2011 23:22:48 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by CDCE10HC1.commscope.com (10.86.28.21) with Microsoft SMTP Server (TLS) id 14.1.339.1; Sun, 9 Oct 2011 23:22:48 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Mon, 10 Oct 2011 12:22:43 +0800 From: "Thomson, Martin" To: "dhcwg@ietf.org" , "James M. Polk" Date: Mon, 10 Oct 2011 12:22:41 +0800 Thread-Topic: Alternative GEOPRIV perspective on draft-ietf-geopriv-dhcp-lbyr-uri-option Thread-Index: AcyHBEBikgHdA/EyRuW3oLsWD46Duw== Message-ID: <27AFD040F6F8AA4193E0614E2E3AF9C910D2F0CC23@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [dhcwg] Alternative GEOPRIV perspective on draft-ietf-geopriv-dhcp-lbyr-uri-option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 04:22:52 -0000 This is response to the discussion here: . I haven't been subscribed to the DHC WG,= so I hope that you'll excuse the starting of a new thread. It appears that the discussion is getting tangled up in the issue of expira= tion. We DID have a discussion in GEOPRIV, but there wasn't a satisfactory= conclusion, from what I can tell: . We sort of spiraled off on other topics. Mo= re on this below. There are other aspects to the draft that I've had my own concerns about. = In particular, the need to provide different URIs to different clients, as = discussed here . This is a big concern when client-controlled authorization policie= s are used for different URIs [RFC5808]. In that case, a different URI MUS= T be provided to each different client, or a different URI for every reques= t. I might disagree with Ted about the ability of DHCP to do this. A DHCP ser= ver _could_ provide a different URI in response to every request and satisf= y the requirement. However, if the point was that no DHCP server in existe= nce would be able to do this without extensive (and probably incompatible o= r destructive) modification:) ..then this truly isn't viable. The draft do= es imply that authorization by possession must be assumed; it should probab= ly go further than that if this is a hard constraint. (This is a bigger problem with , which attempts to add client-controlled authorization polic= ies.) -- On expiration, there's an alternative perspective that could be used to all= eviate the "valid-for" concerns. Though this might not make a jot of diffe= rence to already expressed opinions if it were implemented in the draft... Movement of a mobile host does not invalidate the URI. When we do location= by value (c.f. 4776, 6225), the value becomes invalid as the host moves. = The entire point of adding the layer of indirection is to allow for movemen= t without invalidating the information that DHCP provides. In an ideal implementation, the URI would be cool [1]. That is, the URI i= s unchanging, though the resource that it identifies might change (as the h= ost moves), or be removed (as the host leaves the network, or when a certai= n time elapses). In practice, there might be reasons for the URI to be les= s than cool. The "valid-for" applies not to the URI, but the resource that it refers to.= There is no inherent reason, other than convenience, for the resource to = have a lifetime that is tied to a DHC lease. A shorter duration would prob= ably be bad because it's hard to justify a lease renewal for the purposes o= f acquiring an updated parameter, but longer is probably OK. --Martin [1] From leaf.y.yeh@huawei.com Sun Oct 9 21:29:57 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0215821F8B0D for ; Sun, 9 Oct 2011 21:29:57 -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 uzKK2wGz8iHy for ; Sun, 9 Oct 2011 21:29:56 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 18F4521F8AF4 for ; Sun, 9 Oct 2011 21:29:56 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSU00B3P1SXMA@szxga04-in.huawei.com> for dhcwg@ietf.org; Mon, 10 Oct 2011 12:29:21 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSU00C281SXIK@szxga04-in.huawei.com> for dhcwg@ietf.org; Mon, 10 Oct 2011 12:29:21 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AED37542; Mon, 10 Oct 2011 12:28:40 +0800 Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 10 Oct 2011 12:28:39 +0800 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.227]) by szxeml411-hub.china.huawei.com ([10.82.67.138]) with mapi id 14.01.0270.001; Mon, 10 Oct 2011 12:28:33 +0800 Date: Mon, 10 Oct 2011 04:28:31 +0000 From: Leaf yeh In-reply-to: <940FEFC3-262E-493D-BFAA-2BEFB8176F07@nominum.com> X-Originating-IP: [10.70.39.98] To: dhc WG Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_XLyigSqBOj31BLJ5BRZf3A)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: [dhcwg] Request for agenda items (First call) Thread-index: AQHMhB4XlJCSv0oLzE27ZV7Th8FQr5Vv7QWAgATrDcA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <940FEFC3-262E-493D-BFAA-2BEFB8176F07@nominum.com> Cc: Ted Lemon Subject: Re: [dhcwg] Request for agenda items (First call) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 04:29:57 -0000 --Boundary_(ID_XLyigSqBOj31BLJ5BRZf3A) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7BIT Dear all, Pls. review and feel free to comment on the following individual drafts, which sounds the same design target. 1. draft-yeh-dhc-dhcpv6-prefix-pool-opt-05 2. draft-joshi-dhc-dhcpv6-aggr-route-opt-01 (same as -00) A comparison (in 1 slide) between the above 2 drafts has been showed in the DHC session of IETF81 in Quebec city. Best Regards, Leaf From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ted Lemon Sent: Thursday, October 06, 2011 11:52 PM To: Brzozowski, John Cc: dhc WG Subject: Re: [dhcwg] Request for agenda items (First call) On Oct 6, 2011, at 7:50 AM, Brzozowski, John wrote: Please send agenda items requests to Ted and myself for the upcoming dhcwg meeting at IETF82. Let me rephrase that slightly. If you have something you'd like to discuss at IETF 82, please bring it up on the mailing list now and let's get a conversation started, so that we have something to talk about when we get to Taipei. The mailing list is where IETF business is supposed to happen, and we've been having a lot of stuff get discussed in WG meetings that doesn't get discussed on the mailing list in any meaningful way. --Boundary_(ID_XLyigSqBOj31BLJ5BRZf3A) Content-type: text/html; charset=utf-8 Content-transfer-encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk65a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQg NSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA5a6L5L2TIjsN CglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkJvb2sgQW50aXF1YSI7DQoJcGFub3NlLTE6MiA0IDYgMiA1IDMgNSAz IDMgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJp ZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwg c3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s b3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdy YXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ dGV4dC1pbmRlbnQ6MjEuMHB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLmFwcGxlLXN0eWxlLXNwYW4NCgl7bXNvLXN0 eWxlLW5hbWU6YXBwbGUtc3R5bGUtc3Bhbjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBw dDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVm aW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjExMDUxNDg0OTc7DQoJbXNvLWxp c3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xODM3MjExMzQ4IDE0MDcz NDUzNDIgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3 MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVm dDoxOC4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1p ZDoxNzg1NDE3NzU0Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRl LWlkczotOTU0MzAyNDI4IC03OTgxMzAwMiA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5 ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMTpsZXZl bDENCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjE4LjBwdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCm9s DQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIiBzdHls ZT0id29yZC13cmFwOiBicmVhay13b3JkOy13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTstd2Via2l0 LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Qm9vayBBbnRpcXVhJnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7Ij5EZWFyIGFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Qm9vayBBbnRpcXVhJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Qm9vayBBbnRp cXVhJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5QbHMuIHJldmlldyBhbmQgZmVlbCBmcmVlIHRv IGNvbW1lbnQgb24gdGhlIGZvbGxvd2luZyBpbmRpdmlkdWFsIGRyYWZ0cywgd2hpY2ggc291bmRz IHRoZSBzYW1lIGRlc2lnbiB0YXJnZXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0Jvb2sgQW50aXF1YSZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0 eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMSBs ZXZlbDEgbGZvMiI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Qm9vayBBbnRpcXVhJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4xLjxzcGFu IHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0Jvb2sgQW50aXF1YSZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PGEgaHJlZj0iaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQteWVoLWRoYy1kaGNwdjYtcHJlZml4LXBvb2wt b3B0LyI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPmRyYWZ0LXllaC1kaGMtZGhjcHY2 LXByZWZpeC1wb29sLW9wdC0wNTwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtCb29rIEFudGlxdWEmcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0O3RleHQtaW5kZW50Oi0x OC4wcHQ7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0Jvb2sgQW50aXF1YSZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PHNwYW4gc3R5bGU9Im1zby1s aXN0Oklnbm9yZSI+Mi48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48 L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtCb29rIEFudGlxdWEmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsi PjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWpvc2hpLWRo Yy1kaGNwdjYtYWdnci1yb3V0ZS1vcHQvIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+ ZHJhZnQtam9zaGktZGhjLWRoY3B2Ni1hZ2dyLXJvdXRlLW9wdC0wMTwvc3Bhbj48L2E+DQogKHNh bWUgYXMgLTAwKTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Qm9vayBBbnRpcXVhJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Qm9vayBB bnRpcXVhJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Qm9vayBBbnRpcXVhJnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7Ij5BIGNvbXBhcmlzb24gKGluIDEgc2xpZGUpIGJldHdlZW4gdGhlIGFib3ZlIDIg ZHJhZnRzIGhhcyBiZWVuIHNob3dlZCBpbiB0aGUgREhDIHNlc3Npb24gb2YgSUVURjgxIGluIFF1 ZWJlYyBjaXR5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtCb29rIEFudGlxdWEmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtCb29rIEFudGlxdWEmcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtCb29rIEFudGlxdWEmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkJl c3QgUmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Qm9vayBBbnRpcXVhJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5MZWFmPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Jvb2sgQW50aXF1YSZxdW90Oywm cXVvdDtzZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0Jvb2sgQW50aXF1YSZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+IGRoY3dnLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpkaGN3Zy1ib3VuY2Vz QGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5UZWQgTGVtb248YnI+DQo8Yj5TZW50Ojwv Yj4gVGh1cnNkYXksIE9jdG9iZXIgMDYsIDIwMTEgMTE6NTIgUE08YnI+DQo8Yj5Ubzo8L2I+IEJy em96b3dza2ksIEpvaG48YnI+DQo8Yj5DYzo8L2I+IGRoYyBXRzxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW2RoY3dnXSBSZXF1ZXN0IGZvciBhZ2VuZGEgaXRlbXMgKEZpcnN0IGNhbGwpPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBPY3QgNiwgMjAx MSwgYXQgNzo1MCBBTSwgQnJ6b3pvd3NraSwgSm9obiB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXN0 eWxlLXNwYW4iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+UGxl YXNlIHNlbmQgYWdlbmRhIGl0ZW1zIHJlcXVlc3RzIHRvIFRlZCBhbmQgbXlzZWxmIGZvciB0aGUg dXBjb21pbmcgZGhjd2c8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+PGJyPg0KPHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPm1lZXRp bmcgYXQgSUVURjgyLjwvc3Bhbj48YnI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+TGV0IG1l IHJlcGhyYXNlIHRoYXQgc2xpZ2h0bHkuICZuYnNwOyBJZiB5b3UgaGF2ZSBzb21ldGhpbmcgeW91 J2QgbGlrZSB0byBkaXNjdXNzIGF0IElFVEYgODIsIHBsZWFzZSBicmluZyBpdCB1cCBvbiB0aGUg bWFpbGluZyBsaXN0IG5vdyBhbmQgbGV0J3MgZ2V0IGEgY29udmVyc2F0aW9uIHN0YXJ0ZWQsIHNv IHRoYXQgd2UgaGF2ZSBzb21ldGhpbmcgdG8gdGFsayBhYm91dCB3aGVuIHdlDQogZ2V0IHRvIFRh aXBlaS4gVGhlIG1haWxpbmcgbGlzdCBpcyB3aGVyZSBJRVRGIGJ1c2luZXNzIGlzIHN1cHBvc2Vk IHRvIGhhcHBlbiwgYW5kIHdlJ3ZlIGJlZW4gaGF2aW5nIGEgbG90IG9mIHN0dWZmIGdldCBkaXNj dXNzZWQgaW4gV0cgbWVldGluZ3MgdGhhdCBkb2Vzbid0IGdldCBkaXNjdXNzZWQgb24gdGhlIG1h aWxpbmcgbGlzdCBpbiBhbnkgbWVhbmluZ2Z1bCB3YXkuPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --Boundary_(ID_XLyigSqBOj31BLJ5BRZf3A)-- From teemu.savolainen@nokia.com Mon Oct 10 03:59:00 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC9B21F8B3A for ; Mon, 10 Oct 2011 03:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.74 X-Spam-Level: X-Spam-Status: No, score=-1.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 9rtlwcovDAt3 for ; Mon, 10 Oct 2011 03:58:59 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id A94AA21F8B20 for ; Mon, 10 Oct 2011 03:58:59 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p9AAw1OK021874; Mon, 10 Oct 2011 13:58: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); Mon, 10 Oct 2011 13:58:07 +0300 Received: from 008-AM1MMR1-003.mgdnok.nokia.com (65.54.30.58) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 10 Oct 2011 12:58:04 +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; Mon, 10 Oct 2011 12:58:03 +0200 From: To: , Thread-Topic: [dhcwg] Call for review: draft-ietf-mif-dns-server-selection-04.txt Thread-Index: AQHMg4LkcVWrV0ub10WpLpXX7VOVAZV1awAg Date: Mon, 10 Oct 2011 10:58:03 +0000 Message-ID: <916CE6CF87173740BC8A2CE4430969620377C09C@008-AM1MPN1-037.mgdnok.nokia.com> References: <916CE6CF87173740BC8A2CE4430969620377722C@008-AM1MPN1-037.mgdnok.nokia.com> <415AECEA-6927-4F62-BD6B-44E0B39A0D2B@nominum.com> In-Reply-To: <415AECEA-6927-4F62-BD6B-44E0B39A0D2B@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+/nZJb9Kg7IkxE1ZbYbe1tqgA8/XISd7jiTVGxiiZXQRhUP2GIF4tkeOZkpO4pXTpyL5RcoUkhg5mO3TfIGLYbgTej5qp+7RY8m44dei93Wl8ecrS+Uj1tSWqcYrd7yfbw6IJwleWfQq/P5CdEcN6t13zDNw1rXygNe4p1yQnoLpOq4IvP9Tfw8g047tRtp/VOd8pg4Ea6H2XJ+SMExjI+5Jns/cdjvGKMDxewbfP/vJ0OC7y8CPLpQFscV2c0z5qKeoMtCKuFAPNaschWGy7jrOEl5wDK2ds= x-originating-ip: [10.162.29.44] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0456_01CC8754.9FD7BBA0" MIME-Version: 1.0 X-OriginalArrivalTime: 10 Oct 2011 10:58:07.0803 (UTC) FILETIME=[7E42D0B0:01CC873B] X-Nokia-AV: Clean Subject: Re: [dhcwg] Call for review: draft-ietf-mif-dns-server-selection-04.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 10:59:00 -0000 ------=_NextPart_000_0456_01CC8754.9FD7BBA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, > > Good point, it is that way by accident and I will change for next rev. > > Which one btw is better? Nicer to check in code if least-significant > > bits are used, perhaps (0, 1, 2, 3 in decimal)? > > Likely. Okay, will change that way. > What this boils down to is that, when a server or client is parsing a packet, > the contents of the multiple instances of your option will be concatenated > together into a single buffer, and then parsed according to the expected > content format, so the option-length octet is likely not available to use as a > marker. > > The DHCPv4 version of your option should instead be defined as a list of > (reserved/pref, server address, domains-and-networks). And, since the > domains-and-networks part is of indeterminate length, you need a way to > define the length of it, which is why you needed the domain count field. I > suggested replacing domain count with an octet count because it would be > more general, and less likely to have the entire option definition require > custom code to implement, as there are no other options I can think of at > the moment which use the "DNS Wire Format Domain Name List" format > along with a count of domains elsewhere in the option. There are, on the > other hand, several instances of length-prefixed octet strings (RFC-3925, > RFC-3004). > > So, one possible way of defining this option would be (stealing from RFC- > 3004): > > The format of this option is as follows: > > 0 1 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > +---------------+---------------+ > | option-code | option-len | > +---------------+---------------+ > | | > : option-value : > | | > +-------------------------------+ > > where option-value consists of one or more instances of DNS > Server Selection Data. Each instance of DNS Server Selection > Data is formatted as follows: > > 0 1 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Len | Reserved |prf| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | DNS recursive name server | > | (IPv4 address) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > : Domains and networks : > : (variable length) : > +-------------------------------+ Ok, I think I now see how this concatenation works. But your proposal seems to describe suboption(s) within an option.. Not that fun either - I noticed when implementing client for draft-ietf-mif-dhcpv6-route-option. How about following stealing of reserved bits? 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CODE | Len | Len of domains in oct |Res|prf| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DNS-recursive-name-server (IPv4 address) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .... This would limit to single (possibly concatenated) option , though. If there is need for backup DNS server configuration, then maybe this option should include that as well, i.e: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CODE | Len | Len of domains in oct |Res|prf| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Primary DNS-recursive-name-server (IPv4 address) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Secondary DNS-recursive-name-server (IPv4 address) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ..... ? Best regards, Teemu ------=_NextPart_000_0456_01CC8754.9FD7BBA0 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTExMDEwMTA1ODAxWjAjBgkqhkiG9w0B CQQxFgQUKZqN3CKEezBr1mbAwPMNp/dPkjgwVgYJKwYBBAGCNxAEMUkwRzAzMQswCQYDVQQGEwJG STEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLx MFgGCyqGSIb3DQEJEAILMUmgRzAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNV BAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLxMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMA0GCSqGSIb3DQEBAQUABIIBAIPMP95MZdtabgtkQAil be/2PiP4nZAKQqhuL0nck6nl+sOtKPotSAdSgy7WLn7U4P6xs+xVdl2SxxJOsjJicDA/rIP7p49C iApm9YQBUJffXRuFgbcSw5Pge9j5h3uUR1vypOrpFE6kQ/DdA9r14DD6Xqk9qcltbXIZivgZTJTB +nv6oScCOHIxcM1Zu7Z/g26g7PCPVqEh9C2OuBjj3N3sTS/5MB3ai6ejW84RZA959s/YPEEKtTIh pODjPf8hBQro99si5Pnrm/WUYt16NlUDjhXFCsxErRn9RAwaMARER2WAENJadCHIng1BW21uQxKA 9q8qnzbva3Ee967CfCEAAAAAAAA= ------=_NextPart_000_0456_01CC8754.9FD7BBA0-- From dhankins@google.com Mon Oct 10 17:53:52 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC4421F8CA1 for ; Mon, 10 Oct 2011 17:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.487 X-Spam-Level: X-Spam-Status: No, score=-104.487 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, 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 pX+mAC2hWvXW for ; Mon, 10 Oct 2011 17:53:51 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id CE9C221F8C76 for ; Mon, 10 Oct 2011 17:53:51 -0700 (PDT) Received: from hpaq11.eem.corp.google.com (hpaq11.eem.corp.google.com [172.25.149.11]) by smtp-out.google.com with ESMTP id p9B0rmA6020261 for ; Mon, 10 Oct 2011 17:53:49 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1318294429; bh=Mp+wS3IJE7e6ZxLheSuv8n8UUxo=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Content-Type; b=eTfsYApdXRE5cq54Zanv9saJ/XEPYok1xhbQKdafN4i+P/uq+IfQaQdJsMVlUG4OH LAy1cH/1T+LElRb/GfkMA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:content-type:x-system-of-record; b=tXxAMYqOevocomADz6fJ5q0scHmTCE6iibbl9Uu2zWmuZBUACzHPhvgq+QsfUhOvJ RJINbsebt2ONlZsAzeRng== Received: from pzk34 (pzk34.prod.google.com [10.243.19.162]) by hpaq11.eem.corp.google.com with ESMTP id p9B0j4oH005532 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 10 Oct 2011 17:53:47 -0700 Received: by pzk34 with SMTP id 34so25042713pzk.6 for ; Mon, 10 Oct 2011 17:53:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=4aGmQ2JM5Zf31x909Qaji9gM4oe7NxZ2mXSCDjxULHY=; b=SnreY6CtUSPydB+GPlPVXt1V+QNs/ZmbNGdf3ZeERJOgfQvkEx0DSVum1jkVt1XURt YGFtLfLjSugxbJOgahGw== Received: by 10.68.38.169 with SMTP id h9mr41142171pbk.113.1318294422190; Mon, 10 Oct 2011 17:53:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.38.169 with SMTP id h9mr41142151pbk.113.1318294421999; Mon, 10 Oct 2011 17:53:41 -0700 (PDT) Received: by 10.142.48.3 with HTTP; Mon, 10 Oct 2011 17:53:41 -0700 (PDT) In-Reply-To: <4E8FFD94.30400@gmail.com> References: <5D36713D8A4E7348A7E10DF7437A4B920122B5BD@SZXEML506-MBS.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B9201268307@SZXEML506-MBS.china.huawei.com> <4E8FFD94.30400@gmail.com> Date: Mon, 10 Oct 2011 17:53:41 -0700 Message-ID: From: David Hankins To: DHC WG Content-Type: multipart/alternative; boundary=bcaec520f1bdbb925204aefb56c7 X-System-Of-Record: true Subject: Re: [dhcwg] Review of draft-ietf-dhc-option-guidelines X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 00:53:52 -0000 --bcaec520f1bdbb925204aefb56c7 Content-Type: text/plain; charset=ISO-8859-1 I believe the only text that refers to the preference of FQDN or binary IP address is in Section 9 ("Option Size"): So in either protocol, it is advantageous to prefer option formats which contain the desired information in the smallest form factor that solves the requirements. One example is to use a 4-octet IPv4 address rather than a fully qualified domain name, because many DHCP servers will perform DNS resolution on configured FQDN's (so the DNS recursive lookup is performed anyway). There may be motivations to use the fully qualified domain name anyway, such as if the intended RRSET is not an address, or if the client must refresh the name more frequently than common lease renewal periods. If anyone thinks this is overzealously leaning towards FQDN over binary addresses, or could use different exceptional examples, please suggest text. I considered, but was unable to find a language that seemed polite (not condescending) to cover the recent use-cases of FQDN in DHCPv6 we have seen; namely, to use DNS as a protocol to negotiate configuration between separate administrative domains. There is a very hard limit on DHCPv4 option space available. Pointing out the level of protocol waste that would be required to support the use of DNS as a administrative-domain-bridge is hopefully poignant and helpful to those embroiled in such debates. With DHCPv6, I feel like there's not much more to say than "Try for the best." -- David W. Hankins SRE - Systems Engineer Google, Inc. --bcaec520f1bdbb925204aefb56c7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I believe the only text that refers to the preference of FQDN or binary IP = address is in Section 9 ("Option Size"):

   So in either protocol, it is advantageous to prefer option formats
   which contain the desired information in the smallest form factor
   that solves the requirements.  One example is to use a 4-octet IPv4
   address rather than a fully qualified domain name, because many DHCP
   servers will perform DNS resolution on configured FQDN's (so the DNS
   recursive lookup is performed anyway).  There may be motivations to
   use the fully qualified domain name anyway, such as if the intended
   RRSET is not an address, or if the client must refresh the name more
   frequently than common lease renewal periods.

I= f anyone thinks this is overzealously leaning towards FQDN over binary addr= esses, or could use different exceptional examples, please suggest text. = =A0I considered, but was unable to find a language that seemed polite (not = condescending) to cover the recent use-cases of FQDN in DHCPv6 we have seen= ; namely, to use DNS as a protocol to negotiate configuration between separ= ate administrative domains.

There is a very hard limit on DHCPv4 option space avail= able. =A0Pointing out the level of protocol waste that would be required to= support the use of DNS as a administrative-domain-bridge is hopefully poig= nant and helpful to those embroiled in such debates. =A0With DHCPv6, I feel= like there's not much more to say than "Try for the best."

--
David W. Hankins
SRE - Systems Enginee= r
Google, Inc.
--bcaec520f1bdbb925204aefb56c7-- From dhankins@google.com Mon Oct 10 18:01:05 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C56E21F8B5E for ; Mon, 10 Oct 2011 18:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 cGqFz+EvMa1S for ; Mon, 10 Oct 2011 18:01:04 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1D421F8B34 for ; Mon, 10 Oct 2011 18:01:04 -0700 (PDT) Received: from hpaq12.eem.corp.google.com (hpaq12.eem.corp.google.com [172.25.149.12]) by smtp-out.google.com with ESMTP id p9B111cJ026561 for ; Mon, 10 Oct 2011 18:01:01 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1318294863; bh=q/guk76T/ViLYkeaHQfPp0l8Dqs=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=hTDbiias10a2mJ8ZZfMxdJJ2QmY1yNGoX1ziboGA+ubCX6hGoGCDq1v1OX3pZIAxs pCjkDyoOQuMbin58YjFZQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=WDFMBWndxrwBwA02ul9MkM0fIglWsHdQ3fPqwn2j/a+M8t4Yqr7ZDIh+iGT4Auzdd GF5jqQ+3liv6zMTZDe58Q== Received: from pzk5 (pzk5.prod.google.com [10.243.19.133]) by hpaq12.eem.corp.google.com with ESMTP id p9B105ti032007 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 10 Oct 2011 18:01:00 -0700 Received: by pzk5 with SMTP id 5so23162619pzk.5 for ; Mon, 10 Oct 2011 18:01:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IT0+DJ2joFMnKD7xSx1gSkzpsLC1Q4MrlmhjcYPpZKs=; b=xA2IbuYxs7Ohh3+6Y+GVpEPs2oG4/HdEXbKj+sE2XHxOfJA4ykg7GrjKFEkNB2j6Hb +Gl4oWYcyUc6NgzzOr1Q== Received: by 10.68.39.170 with SMTP id q10mr41244090pbk.96.1318294860324; Mon, 10 Oct 2011 18:01:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.39.170 with SMTP id q10mr41244061pbk.96.1318294860078; Mon, 10 Oct 2011 18:01:00 -0700 (PDT) Received: by 10.142.48.3 with HTTP; Mon, 10 Oct 2011 18:00:59 -0700 (PDT) In-Reply-To: References: <940FEFC3-262E-493D-BFAA-2BEFB8176F07@nominum.com> Date: Mon, 10 Oct 2011 18:00:59 -0700 Message-ID: From: David Hankins To: DHC WG Content-Type: multipart/alternative; boundary=bcaec520e5afd81fc604aefb70f2 X-System-Of-Record: true Cc: Ted Lemon Subject: Re: [dhcwg] Request for agenda items (First call) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 01:01:05 -0000 --bcaec520e5afd81fc604aefb70f2 Content-Type: text/plain; charset=ISO-8859-1 draft-ietf-dhc-dhcpinform-clarify -- There hasn't been any discussion since the last meeting. I've re-upped the draft after a once-over, I wasn't able to identify any changes. Should we last-call this? draft-ietf-dhc-options-guidelines -- There has been WG discussion, and a revision based on feedback. I think we can go in circles here, constantly revising, unless we choose to put a stake in the ground and start new draft revisions. I feel like there wouldn't be much value to my going to Taipei to speak on these two (in Quebec we didn't seem to have critical mass either). -- David W. Hankins SRE - Systems Engineer Google, Inc. --bcaec520e5afd81fc604aefb70f2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
draft-ietf-dhc-dhcpinform-clarify --

There ha= sn't been any discussion since the last meeting. =A0I've re-upped t= he draft after a once-over, I wasn't able to identify any changes. =A0S= hould we last-call this?

draft-ietf-dhc-options-guidelines --

There has been WG discussion, and a revision based on feedback. =A0I= think we can go in circles here, constantly revising, unless we choose to = put a stake in the ground and start new draft revisions.


I feel like there wouldn't be much v= alue to my going to Taipei to speak on these two (in Quebec we didn't s= eem to have critical mass either).

--
David W.= Hankins
SRE - Systems Engineer
Google, Inc.
--bcaec520e5afd81fc604aefb70f2-- From Ted.Lemon@nominum.com Mon Oct 10 18:21:51 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 479F521F8B1F for ; Mon, 10 Oct 2011 18:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[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 kZhpjrCVuaey for ; Mon, 10 Oct 2011 18:21:50 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id C58B321F8C74 for ; Mon, 10 Oct 2011 18:21:48 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP; Mon, 10 Oct 2011 18:21:48 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 480901B827A for ; Mon, 10 Oct 2011 18:21:41 -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 295D1190068; Mon, 10 Oct 2011 18:21:40 -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, 10 Oct 2011 18:21:40 -0700 From: Ted Lemon To: David Hankins Thread-Topic: Discussion on dhcpinform-clarify and option-guidelines Thread-Index: AQHMh7Qgupcz0+Joz0yAGBkW6WHDqg== Date: Tue, 11 Oct 2011 01:21:39 +0000 Message-ID: References: <940FEFC3-262E-493D-BFAA-2BEFB8176F07@nominum.com> In-Reply-To: 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_C1980B2D7C974719B1304E5C445CDFE9nominumcom_" MIME-Version: 1.0 Cc: DHC WG Subject: [dhcwg] Discussion on dhcpinform-clarify and option-guidelines X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 01:21:51 -0000 --_000_C1980B2D7C974719B1304E5C445CDFE9nominumcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Oct 10, 2011, at 9:00 PM, David Hankins wrote: I feel like there wouldn't be much value to my going to Taipei to speak on = these two (in Quebec we didn't seem to have critical mass either). Yeah, it's hard to know who will show up in Taipei. I'd like to see some = discussion on the list. There was certainly some interest in this draft b= ack when you were working on it for ISC; are any of the people who were int= erested in it then still interested now? --_000_C1980B2D7C974719B1304E5C445CDFE9nominumcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
On Oct 10, 2011, at 9:00 PM, David Hankins wrote:
I feel like there wouldn't be much value to my going to Taipei to spea= k on these two (in Quebec we didn't seem to have critical mass either).

Yeah, it's hard to know who will show up in Taipei.   I'd like to= see some discussion on the list.   There was certainly some interest = in this draft back when you were working on it for ISC; are any of the peop= le who were interested in it then still interested now?


--_000_C1980B2D7C974719B1304E5C445CDFE9nominumcom_-- From internet-drafts@ietf.org Tue Oct 11 00:46:58 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9916621F8D69; Tue, 11 Oct 2011 00:46:58 -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 pHpW+yzlIMov; Tue, 11 Oct 2011 00:46:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4272E21F8D68; Tue, 11 Oct 2011 00:46:58 -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: <20111011074658.10349.15024.idtracker@ietfa.amsl.com> Date: Tue, 11 Oct 2011 00:46:58 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-cga-config-dhcpv6-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 07:46:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Gr= oup of the IETF. Title : Configuring Cryptographically Generated Addresses (CGA) = using DHCPv6 Author(s) : Sheng Jiang Filename : draft-ietf-dhc-cga-config-dhcpv6-01.txt Pages : 10 Date : 2011-10-11 A Cryptographically Generated Address is an IPv6 addresses binding with a public/private key pair. However, the current CGA specifications are lack of procedures to enable proper management of the usage of CGAs. This document defines the process using DHCPv6 to manage CGAs in detail. A new DHCPv6 option is defined accordingly. This document also analyses the configuration of the parameters, which are used to generate CGAs, using DHCPv6. Although the document does not define new DHCPv6 option to carry these parameters for various reasons, the configuration procedure is described. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-cga-config-dhcpv6-01.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-dhc-cga-config-dhcpv6-01.txt From jhutz@cmu.edu Wed Oct 12 09:37:07 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D91921F8B98 for ; Wed, 12 Oct 2011 09:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 sxC4CLoayAeE for ; Wed, 12 Oct 2011 09:37: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 F243921F8B8B for ; Wed, 12 Oct 2011 09:37: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 p9CGb26h014342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Oct 2011 12:37:04 -0400 (EDT) From: Jeffrey Hutzelman To: "ietf-krb-wg@anl.gov" In-Reply-To: <1317662486.10029.103.camel@minbar.fac.cs.cmu.edu> References: <1317662486.10029.103.camel@minbar.fac.cs.cmu.edu> Content-Type: text/plain; charset="UTF-8" Date: Wed, 12 Oct 2011 12:37:02 -0400 Message-ID: <1318437422.3424.93.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 Cc: dhcwg@ietf.org, jhutz@cmu.edu Subject: Re: [dhcwg] [Ietf-krb-wg] WG Last Call: draft-sakane-dhc-dhcpv6-kdc-option-12.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 16:37:07 -0000 On Mon, 2011-10-03 at 13:21 -0400, Jeffrey Hutzelman wrote: > This note announces the start of a two-week last call to determine > whether to send the following document to the IESG: > > Title: Kerberos Options for DHCPv6 > Filename: draft-sakane-dhc-dhcpv6-kdc-option-12.txt > Intended Status: Standards Track(*) > > This document defines new four options of Dynamic Host Configuration > Protocol for IPv6 (DHCPv6) to carry a set of configuration > information related to the Kerberos protocol [RFC4120]. > > (*) Note that the current version of the draft says "Informational", but > during discussion leading up to this WGLC, I think Ted and I both agreed > that standards track is more appropriate. If anyone has an objection to > this, please speak up. > > This document is a product of the Kerberos working group, but since it > defines a DHCPv6 option, review is also required in DHC. As a result, > we are running this Last Call simultaneously in both working groups. We > request that any comments be sent to both and > . > > This last call will expire at 23:59 EDT on Monday, Oct 17, 2011. > > The file can be obtained via > > http://tools.ietf.org/html/draft-sakane-dhc-dhcpv6-kdc-option-12.txt So far I've seen no comments on this WGLC from either working group. Since this document has been in WGLC before and the changes since then have been discussed (if briefly) on the mailing list, I will take silence to mean that the Kerberos WG is OK with the updated document. Of course, I cannot speak for the DHC chairs. -- Jeff From Ted.Lemon@nominum.com Wed Oct 12 10:48:34 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76C4221F8B80 for ; Wed, 12 Oct 2011 10:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[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 4ZgRL7FfBpqJ for ; Wed, 12 Oct 2011 10:48:34 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id A9AE121F8B77 for ; Wed, 12 Oct 2011 10:48:32 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP; Wed, 12 Oct 2011 10:48:33 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 C2AEC1B8388 for ; Wed, 12 Oct 2011 10:48:18 -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 956C7190068; Wed, 12 Oct 2011 10:48:17 -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, 12 Oct 2011 10:48:17 -0700 From: Ted Lemon To: Jeffrey Hutzelman Thread-Topic: [Ietf-krb-wg] WG Last Call: draft-sakane-dhc-dhcpv6-kdc-option-12.txt Thread-Index: AQHMiP0xkeosR8hyykil+pNNNFEByJV5cZyA Date: Wed, 12 Oct 2011 17:48:17 +0000 Message-ID: <7390B288-88A5-43DC-804A-1F3B04A5AF0D@nominum.com> References: <1317662486.10029.103.camel@minbar.fac.cs.cmu.edu> <1318437422.3424.93.camel@destiny.pc.cs.cmu.edu> In-Reply-To: <1318437422.3424.93.camel@destiny.pc.cs.cmu.edu> 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_7390B28888A543DC804A1F3B04A5AF0Dnominumcom_" MIME-Version: 1.0 Cc: "ietf-krb-wg@anl.gov" , "" Subject: Re: [dhcwg] [Ietf-krb-wg] WG Last Call: draft-sakane-dhc-dhcpv6-kdc-option-12.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 17:48:34 -0000 --_000_7390B28888A543DC804A1F3B04A5AF0Dnominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Oct 12, 2011, at 12:37 PM, Jeffrey Hutzelman wrote: Of course, I cannot speak for the DHC chairs. Let me give it a last read before we say it's done. I think nobody read i= t, so I'm not comfortable just signing off on it, but it's not fair to you = guys to make you wait. --_000_7390B28888A543DC804A1F3B04A5AF0Dnominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <4E271729C584064D9F50F16E19CF6DBC@nominum.com> Content-Transfer-Encoding: quoted-printable
On Oct 12, 2011, at 12:37 PM, Jeffrey Hutzelman wrote:
Of course, I cannot speak for the DHC chairs.

Let me give it a last read before we say it's done.   I think nob= ody read it, so I'm not comfortable just signing off on it, but it's not fa= ir to you guys to make you wait.

--_000_7390B28888A543DC804A1F3B04A5AF0Dnominumcom_-- From xuxiaohu@huawei.com Wed Oct 12 22:54:14 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 425E921F8B0F for ; Wed, 12 Oct 2011 22:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.231 X-Spam-Level: X-Spam-Status: No, score=-1.231 tagged_above=-999 required=5 tests=[AWL=0.826, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 nTfq+oaIwHgr for ; Wed, 12 Oct 2011 22:54:13 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 5C73B21F8AF4 for ; Wed, 12 Oct 2011 22:54:13 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSZ00K0UPPN2Q@szxga04-in.huawei.com> for dhcwg@ietf.org; Thu, 13 Oct 2011 13:53:47 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSZ00CZ1PPIPD@szxga04-in.huawei.com> for dhcwg@ietf.org; Thu, 13 Oct 2011 13:53:47 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEF08431; Thu, 13 Oct 2011 13:53:46 +0800 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 13 Oct 2011 13:53:38 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.181]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0270.001; Thu, 13 Oct 2011 13:53:37 +0800 Date: Thu, 13 Oct 2011 05:53:36 +0000 From: Xuxiaohu In-reply-to: X-Originating-IP: [10.108.4.66] To: Ted Lemon , "dhcwg@ietf.org WG" Message-id: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE738A4F@szxeml525-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [dhcwg] Call for adoption: draft-guo-softwire-6rd-ipv6-config-02.txt Thread-index: Acwa93bX6KNrWbR0Ry+ENPeReJtDYhudrSqA X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Subject: Re: [dhcwg] Call for adoption: draft-guo-softwire-6rd-ipv6-config-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 05:54:14 -0000 DQo+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiC3orz+yMs6IGRoY3dnLWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzpkaGN3Zy1ib3VuY2VzQGlldGYub3JnXSC0+rHtIFRlZA0KPiBMZW1vbg0KPiC3osvN yrG85DogMjAxMcTqNdTCMjbI1SAwOjE3DQo+IMrVvP7IyzogZGhjd2dAaWV0Zi5vcmcgV0cNCj4g 1vfM4jogUmU6IFtkaGN3Z10gQ2FsbCBmb3IgYWRvcHRpb246IGRyYWZ0LWd1by1zb2Z0d2lyZS02 cmQtaXB2Ni1jb25maWctMDIudHh0DQo+IA0KPiBPbiBNYXkgMTAsIDIwMTEsIGF0IDEwOjU4IFBN LCBUZWQgTGVtb24gd3JvdGU6DQo+ID4gSWYgeW91IGFncmVlIHRoYXQgdGhlIHdvcmtpbmcgZ3Jv dXAgc2hvdWxkIGRvIHRoaXMgd29yaywgcGxlYXNlIGluZGljYXRlIHRoYXQNCj4gYWdyZWVtZW50 IG9uIHRoZSBsaXN0OyBsaWtld2lzZSBpZiB5b3UgZGlzYWdyZWUuICAgSWYgeW91IGhhdmUgbm8g b3BpbmlvbiwgdGhlcmUNCj4gaXMgbm8gbmVlZCB0byBzYXkgc28uDQo+ID4NCj4gPiBXZSB3aWxs IGV2YWx1YXRlIHRoZSBjb25zZW5zdXMgb24gV2VkbmVzZGF5LCBNYXkgMjUuICAgUGxlYXNlIGdl dCB5b3VyDQo+IGNvbW1lbnRzIGluIGJlZm9yZSB0aGF0IHRpbWUuDQo+IA0KPiBUaGUgY29uc2Vu c3VzIHNlZW1zIHRvIGJlIHRoYXQgdGhpcyB3b3JrIGlzIHdvcnRoIGRvaW5nLCBhbHRob3VnaCB0 aGVyZSB3YXMNCj4gc29tZSBkaXNjdXNzaW9uIGFib3V0IHRoZSBzY29wZSBvZiB0aGUgd29yay4g ICBJIHRoaW5rIHRoZSBhdXRob3JzIHNob3VsZA0KPiBjb25zaWRlciB3b3JraW5nIHdpdGggTWFy YyBCbGFuY2hldCB0byBnZXQgdGhlIGRvY3VtZW50IHNjb3BlZCBjb3JyZWN0bHksDQo+IGFuZCBw b3NzaWJseSBicmluZyBoaW0gb24gYXMgYSBjby1hdXRob3IuICBJbiBhbnkgY2FzZSwgdGhlIHdv cmtpbmcgZ3JvdXAgaGFzDQo+IGFkb3B0ZWQgdGhpcyBhcyBhIHdvcmtpbmcgZ3JvdXAgaXRlbSwg c28gdGhlIGF1dGhvcnMgc2hvdWxkIHN1Ym1pdCBhDQo+IGRyYWZ0LWlldGYtLi4uIGRyYWZ0Lg0K PiANCj4gQlRXLCBpZiB0aGUgYXV0aG9ycyBhZ3JlZSB0byBleHBhbmQgdGhlIHNjb3BlLCBJIHdv dWxkIHN1Z2dlc3QgY2FsbGluZyB0aGUNCj4gZHJhZnQgc29tZXRoaW5nIGxpa2UgIkRIQ1B2NiB0 aHJvdWdoIFR1bm5lbHMiIGFuZA0KPiBkcmFmdC1pZXRmLWRoYy1kaGNwdjYtdHVubmVscy0wMC50 eHQgaW5zdGVhZCBvZiBrZWVwaW5nIDZyZCBpbiB0aGUgbmFtZS4NCg0KSGkgVGVkLA0KDQpUaGUg YXV0aG9ycyBpbmNsdWRpbmcgTWFyYyBCbGFuY2hldCBhcyBhIG5ldyBjby1hdXRob3IgaGF2ZSBh Z3JlZWQgdG8gZXhwYW5kIHRoZSBzY29wZSBhbmQgd2UgaGF2ZSBtYWRlIGNvcnJlc3BvbmRpbmcg bW9kaWZpY2F0aW9ucyBhbmQganVzdCBzdWJtaXR0ZWQgdGhlIGRyYWZ0LWlldGYtLi4uIGRyYWZ0 IChzZWUgaHR0cDovL3d3dy5pZXRmLm9yZy9zdGFnaW5nL2RyYWZ0LWlldGYtZGhjLWRoY3B2Ni10 dW5uZWwtMDAudHh0KSBhY2NvcmRpbmcgdG8geW91ciBraW5kbHkgc3VnZ2VzdGlvbnMuDQoNCkFu eSBmdXJ0aGVyIGNvbW1lbnRzIGFyZSB3ZWxjb21lLg0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUv T2xlL01hcmMvTWFyay9EYXlvbmcNCiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gZGhjd2cgbWFpbGluZyBsaXN0DQo+IGRoY3dnQGlldGYub3Jn DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGhjd2cNCg== From Ted.Lemon@nominum.com Thu Oct 13 12:28:47 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B44E21F8B47 for ; Thu, 13 Oct 2011 12:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.001, 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 8onG1Yz7Vct0 for ; Thu, 13 Oct 2011 12:28:46 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 9818C21F8B30 for ; Thu, 13 Oct 2011 12:28:46 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP; Thu, 13 Oct 2011 12:28:46 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 985CD1B838B for ; Thu, 13 Oct 2011 12:28:31 -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 C746B19006B for ; Thu, 13 Oct 2011 12:28:28 -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, 13 Oct 2011 12:28:28 -0700 From: Ted Lemon To: DHC WG Thread-Topic: DHC session in Taipai scheduled for Thursday morning... Thread-Index: AQHMid5Iq8CCHzX6hUK/DTFHBWyJQQ== Date: Thu, 13 Oct 2011 19:28:27 +0000 Message-ID: <174F9552-21AD-405D-AFF3-5037D346122F@nominum.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="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dhcwg] DHC session in Taipai scheduled for Thursday morning... X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 19:28:47 -0000 Please plan accordingly. Of course, schedules can change, so it's always = better to just come for the whole week. From john_brzozowski@cable.comcast.com Fri Oct 14 04:47:36 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8984321F8AF8 for ; Fri, 14 Oct 2011 04:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.735 X-Spam-Level: X-Spam-Status: No, score=-101.735 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 bHZ0PEK7rDoQ for ; Fri, 14 Oct 2011 04:47:35 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id E5D4E21F8ABD for ; Fri, 14 Oct 2011 04:47:34 -0700 (PDT) Received: from ([24.40.55.41]) by copdcimo01.cable.comcast.com with ESMTP id 5503630.57143806; Fri, 14 Oct 2011 05:54:51 -0600 Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%11]) with mapi id 14.01.0289.001; Fri, 14 Oct 2011 07:47:31 -0400 From: "Brzozowski, John" To: dhc WG Thread-Topic: 82nd IETF DRAFT Agenda Thread-Index: AQHMiezvJAfkNKUH0EW224T/2vouxJV7ujcA Date: Fri, 14 Oct 2011 11:47:30 +0000 Message-ID: In-Reply-To: <20111013211312.B6C7421F8AFF@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [98.225.200.29] Content-Type: text/plain; charset="us-ascii" Content-ID: <65E9B1254868D64C88D83BE18056C47A@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dhcwg] FW: 82nd IETF DRAFT Agenda X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 11:47:36 -0000 FYI On 10/13/11 5:13 PM, "IETF Agenda" wrote: >The DRAFT agenda is ready for viewing. Please note the cutoff date for >requests to reschedule Working Group and BOF meetings is October 17, 2011 >17:00 PT. The final agenda will be published on October 21, 2011. > >https://datatracker.ietf.org/meeting/82/agenda.html >https://datatracker.ietf.org/meeting/82/agenda.txt > >http://www.ietf.org/meeting/82/index.html > > >Thanks, >Wanda > >Only 30 days until Taipei, 82nd IETF! >Online registration for the IETF meeting is at: >http://www.ietf.org/meeting/register.html > From xuxiaohu@huawei.com Wed Oct 12 22:04:03 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 838E921F8B10 for ; Wed, 12 Oct 2011 22:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.405 X-Spam-Level: X-Spam-Status: No, score=-0.405 tagged_above=-999 required=5 tests=[AWL=1.652, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 rPQiL8L8I71Q for ; Wed, 12 Oct 2011 22:04:03 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id E094C21F888A for ; Wed, 12 Oct 2011 22:04:02 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSZ00AEQNEN9Q@szxga03-in.huawei.com> for dhcwg@ietf.org; Thu, 13 Oct 2011 13:04:00 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSZ003O3NENGA@szxga03-in.huawei.com> for dhcwg@ietf.org; Thu, 13 Oct 2011 13:03:59 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEF06359; Thu, 13 Oct 2011 13:03:59 +0800 Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 13 Oct 2011 13:03:53 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.181]) by szxeml411-hub.china.huawei.com ([10.82.67.138]) with mapi id 14.01.0270.001; Thu, 13 Oct 2011 13:03:54 +0800 Date: Thu, 13 Oct 2011 05:03:53 +0000 From: Xuxiaohu In-reply-to: X-Originating-IP: [10.108.4.66] To: Ted Lemon , "dhcwg@ietf.org WG" Message-id: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE738A26@szxeml525-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [dhcwg] Call for adoption: draft-guo-softwire-6rd-ipv6-config-02.txt Thread-index: Acwa93bX6KNrWbR0Ry+ENPeReJtDYhuX04NA X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: X-Mailman-Approved-At: Sat, 15 Oct 2011 08:01:43 -0700 Subject: Re: [dhcwg] Call for adoption: draft-guo-softwire-6rd-ipv6-config-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 05:04:03 -0000 DQo+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiC3orz+yMs6IGRoY3dnLWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzpkaGN3Zy1ib3VuY2VzQGlldGYub3JnXSC0+rHtIFRlZA0KPiBMZW1vbg0KPiC3osvN yrG85DogMjAxMcTqNdTCMjbI1SAwOjE3DQo+IMrVvP7IyzogZGhjd2dAaWV0Zi5vcmcgV0cNCj4g 1vfM4jogUmU6IFtkaGN3Z10gQ2FsbCBmb3IgYWRvcHRpb246IGRyYWZ0LWd1by1zb2Z0d2lyZS02 cmQtaXB2Ni1jb25maWctMDIudHh0DQo+IA0KPiBPbiBNYXkgMTAsIDIwMTEsIGF0IDEwOjU4IFBN LCBUZWQgTGVtb24gd3JvdGU6DQo+ID4gSWYgeW91IGFncmVlIHRoYXQgdGhlIHdvcmtpbmcgZ3Jv dXAgc2hvdWxkIGRvIHRoaXMgd29yaywgcGxlYXNlIGluZGljYXRlIHRoYXQNCj4gYWdyZWVtZW50 IG9uIHRoZSBsaXN0OyBsaWtld2lzZSBpZiB5b3UgZGlzYWdyZWUuICAgSWYgeW91IGhhdmUgbm8g b3BpbmlvbiwgdGhlcmUNCj4gaXMgbm8gbmVlZCB0byBzYXkgc28uDQo+ID4NCj4gPiBXZSB3aWxs IGV2YWx1YXRlIHRoZSBjb25zZW5zdXMgb24gV2VkbmVzZGF5LCBNYXkgMjUuICAgUGxlYXNlIGdl dCB5b3VyDQo+IGNvbW1lbnRzIGluIGJlZm9yZSB0aGF0IHRpbWUuDQo+IA0KPiBUaGUgY29uc2Vu c3VzIHNlZW1zIHRvIGJlIHRoYXQgdGhpcyB3b3JrIGlzIHdvcnRoIGRvaW5nLCBhbHRob3VnaCB0 aGVyZSB3YXMNCj4gc29tZSBkaXNjdXNzaW9uIGFib3V0IHRoZSBzY29wZSBvZiB0aGUgd29yay4g ICBJIHRoaW5rIHRoZSBhdXRob3JzIHNob3VsZA0KPiBjb25zaWRlciB3b3JraW5nIHdpdGggTWFy YyBCbGFuY2hldCB0byBnZXQgdGhlIGRvY3VtZW50IHNjb3BlZCBjb3JyZWN0bHksDQo+IGFuZCBw b3NzaWJseSBicmluZyBoaW0gb24gYXMgYSBjby1hdXRob3IuICBJbiBhbnkgY2FzZSwgdGhlIHdv cmtpbmcgZ3JvdXAgaGFzDQo+IGFkb3B0ZWQgdGhpcyBhcyBhIHdvcmtpbmcgZ3JvdXAgaXRlbSwg c28gdGhlIGF1dGhvcnMgc2hvdWxkIHN1Ym1pdCBhDQo+IGRyYWZ0LWlldGYtLi4uIGRyYWZ0Lg0K PiANCj4gQlRXLCBpZiB0aGUgYXV0aG9ycyBhZ3JlZSB0byBleHBhbmQgdGhlIHNjb3BlLCBJIHdv dWxkIHN1Z2dlc3QgY2FsbGluZyB0aGUNCj4gZHJhZnQgc29tZXRoaW5nIGxpa2UgIkRIQ1B2NiB0 aHJvdWdoIFR1bm5lbHMiIGFuZA0KPiBkcmFmdC1pZXRmLWRoYy1kaGNwdjYtdHVubmVscy0wMC50 eHQgaW5zdGVhZCBvZiBrZWVwaW5nIDZyZCBpbiB0aGUgbmFtZS4NCg0KSGkgVGVkLA0KDQpUaGUg YXV0aG9ycyBpbmNsdWRpbmcgTWFyYyBCbGFuY2hldCBhcyBhIG5ldyBjby1hdXRob3IgaGF2ZSBh Z3JlZWQgdG8gZXhwYW5kIHRoZSBzY29wZSBhbmQgd2UgaGF2ZSBtYWRlIGNvcnJlc3BvbmRpbmcg bW9kaWZpY2F0aW9ucyBhbmQganVzdCBzdWJtaXR0ZWQgdGhlIGRyYWZ0LWlldGYtLi4uIGRyYWZ0 IChzZWUgaHR0cDovL3d3dy5pZXRmLm9yZy9zdGFnaW5nL2RyYWZ0LWlldGYtZGhjLWRoY3B2Ni10 dW5uZWwtMDAudHh0KSBhY2NvcmRpbmcgdG8geW91ciBraW5kbHkgc3VnZ2VzdGlvbnMuDQoNCkFu eSBmdXJ0aGVyIGNvbW1lbnRzIGFyZSB3ZWxjb21lLg0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUv T2xlL01hcmMvTWFyay9EYXlvbmcNCg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiBkaGN3ZyBtYWlsaW5nIGxpc3QNCj4gZGhjd2dAaWV0Zi5vcmcN Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaGN3Zw0K From teemu.savolainen@nokia.com Mon Oct 17 00:23:52 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D52721F8AF6 for ; Mon, 17 Oct 2011 00:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.134 X-Spam-Level: X-Spam-Status: No, score=-3.134 tagged_above=-999 required=5 tests=[AWL=0.465, 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 n5T197Rcb1To for ; Mon, 17 Oct 2011 00:23:51 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 7A28921F8AF4 for ; Mon, 17 Oct 2011 00:23:51 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p9H7NUWa031996; Mon, 17 Oct 2011 10:23:49 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Oct 2011 10:21:51 +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; Mon, 17 Oct 2011 09:21:50 +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; Mon, 17 Oct 2011 09:21:49 +0200 From: To: , Thread-Topic: [dhcwg] Call for review: draft-ietf-mif-dns-server-selection-04.txt Thread-Index: AQHMg4LkcVWrV0ub10WpLpXX7VOVAZV1awAggAq5wsA= Date: Mon, 17 Oct 2011 07:21:49 +0000 Message-ID: <916CE6CF87173740BC8A2CE44309696203781433@008-AM1MPN1-037.mgdnok.nokia.com> References: <916CE6CF87173740BC8A2CE4430969620377722C@008-AM1MPN1-037.mgdnok.nokia.com> <415AECEA-6927-4F62-BD6B-44E0B39A0D2B@nominum.com> <916CE6CF87173740BC8A2CE4430969620377C09C@008-AM1MPN1-037.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE4430969620377C09C@008-AM1MPN1-037.mgdnok.nokia.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+/nZJb9Kg7IkxE1ZbYbe1tqgA8/XISd7jiTVGxiiZXQRhUP2GIF4tkeOZkpO4pXTpyL5RcoUkhg5mO3TfIGLYbgTej5qp+7RY8m44dei93Wl8ecrS+Uj1tSWqcYrd7yfbw6IJwleWfQq/P5CdEcN6t13zDNw1rXygNe4p1yQnoLpOq4IvP9Tfw8g047tRtp/VOd8pg4Ea6H2XJ+SMExjI+5Jns/cdjvGKMDxewbfP/vJ0OC7y8CPLpQFscV2c0z5qKeoMtCKuFAPNaschWGy7jrOEl5wDK2ds= x-originating-ip: [10.162.69.25] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_012B_01CC8CAF.E2479810" MIME-Version: 1.0 X-OriginalArrivalTime: 17 Oct 2011 07:21:51.0016 (UTC) FILETIME=[70628280:01CC8C9D] X-Nokia-AV: Clean Subject: Re: [dhcwg] Call for review: draft-ietf-mif-dns-server-selection-04.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 07:23:52 -0000 ------=_NextPart_000_012B_01CC8CAF.E2479810 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I need to update the draft quite soon, so I think I'll go for this approach if no objections: > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | CODE | Len | Len of domains in oct |Res|prf| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Primary DNS-recursive-name-server (IPv4 address) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Secondary DNS-recursive-name-server (IPv4 address) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Domains and networks ..... The Option 6 (Domain Name Server Option) of RFC1533 allows 1 or more domain name server addresses, but for this option, for sake of simplicity, two should suffice? Maybe a question then would be, if there needs to be two IPv6 addresses for DNS servers in the case of DHCPv6 option, or whether just single address is enough there (and then have multiple option instances if multiple servers need to be configured). Best regards, Teemu ------=_NextPart_000_012B_01CC8CAF.E2479810 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTExMDE3MDYzMzUzWjAjBgkqhkiG9w0B CQQxFgQU6XOkRRi+Pmqzmli6ZfFMkDz7oiIwVgYJKwYBBAGCNxAEMUkwRzAzMQswCQYDVQQGEwJG STEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLx MFgGCyqGSIb3DQEJEAILMUmgRzAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNV BAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLxMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMA0GCSqGSIb3DQEBAQUABIIBABt3P7N7cNvKyDRhDk2a V6Ly9L0Vg7PkPjs9zKKqe5CMNNU8bP+4Nsr3g2Z+Hvx+6YG7sFZB/HOoS0Q4Oy65Mxzvrzd8Ypu8 ws36B2G3BpOfAz06SSlDSB8xcZxi8qNrGrVK1cv8iW/xb3y5QKdRyhMPKjsIp7Ro84/OpSd+JIh8 PjQRPf3Fid4xuYdGzdck8RDGHvO+jOsBVBepv8c0tmAfuxyOeWQBBwbcJ6cTCOeuFxRH5xJCW1GV DSyDx6VYG2xpng3W7e5kO6eUVlbWRfAKWpxeyk53Wx+Svmotnls7BH14qva0LQTIoMDRSPaHxSwU JzSFxBMn7Vj+cK8eIagAAAAAAAA= ------=_NextPart_000_012B_01CC8CAF.E2479810-- From mayer@ntp.org Mon Oct 17 04:26:44 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBB0721F8772 for ; Mon, 17 Oct 2011 04:26: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 aRyBW0uuEsHW for ; Mon, 17 Oct 2011 04:26:44 -0700 (PDT) Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3D621F84D3 for ; Mon, 17 Oct 2011 04:26:44 -0700 (PDT) Received: from [198.22.153.9] (helo=[10.60.111.27]) by mail1.ntp.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RFlL4-000LX6-2n; Mon, 17 Oct 2011 11:26:39 +0000 Message-ID: <4E9C10E5.2080505@ntp.org> Date: Mon, 17 Oct 2011 07:26:29 -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: teemu.savolainen@nokia.com References: <916CE6CF87173740BC8A2CE4430969620377722C@008-AM1MPN1-037.mgdnok.nokia.com> <415AECEA-6927-4F62-BD6B-44E0B39A0D2B@nominum.com> <916CE6CF87173740BC8A2CE4430969620377C09C@008-AM1MPN1-037.mgdnok.nokia.com> <916CE6CF87173740BC8A2CE44309696203781433@008-AM1MPN1-037.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE44309696203781433@008-AM1MPN1-037.mgdnok.nokia.com> 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.9 X-SA-Exim-Rcpt-To: teemu.savolainen@nokia.com, Matt.Ryan@nominum.com, dhcwg@ietf.org X-SA-Exim-Mail-From: mayer@ntp.org X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Call for review: draft-ietf-mif-dns-server-selection-04.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 11:26:45 -0000 On 10/17/2011 3:21 AM, teemu.savolainen@nokia.com wrote: > I need to update the draft quite soon, so I think I'll go for this approach > if no objections: > >> 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 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | CODE | Len | Len of domains in oct |Res|prf| >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Primary DNS-recursive-name-server (IPv4 address) | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Secondary DNS-recursive-name-server (IPv4 address) | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Domains and networks ..... > > The Option 6 (Domain Name Server Option) of RFC1533 allows 1 or more domain > name server addresses, but for this option, for sake of simplicity, two > should suffice? > > Maybe a question then would be, if there needs to be two IPv6 addresses for > DNS servers in the case of DHCPv6 option, or whether just single address is > enough there (and then have multiple option instances if multiple servers > need to be configured). You need to support both IPv4 and IPv6 addresses here. This has nothing whatsoever to do with DHCPv6. Danny From Matt.Ryan@nominum.com Mon Oct 17 06:10:30 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF2EE21F8B79 for ; Mon, 17 Oct 2011 06:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 LS4HitHHw5NF for ; Mon, 17 Oct 2011 06:10:30 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id C624A21F8B91 for ; Mon, 17 Oct 2011 06:10:26 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP; Mon, 17 Oct 2011 06:10:30 PDT Received: from vir.ddns.nominum.com (vir.ddns.nominum.com [64.89.225.15]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by shell-too.nominum.com (Postfix) with ESMTP id 2B1EB1B82DB; Mon, 17 Oct 2011 06:10:19 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Matthew Ryan In-Reply-To: <916CE6CF87173740BC8A2CE44309696203781433@008-AM1MPN1-037.mgdnok.nokia.com> Date: Mon, 17 Oct 2011 06:10:18 -0700 Content-Transfer-Encoding: 7bit Message-Id: <46CF2D93-9001-431A-AEE2-1F4F4719130B@nominum.com> References: <916CE6CF87173740BC8A2CE4430969620377722C@008-AM1MPN1-037.mgdnok.nokia.com> <415AECEA-6927-4F62-BD6B-44E0B39A0D2B@nominum.com> <916CE6CF87173740BC8A2CE4430969620377C09C@008-AM1MPN1-037.mgdnok.nokia.com> <916CE6CF87173740BC8A2CE44309696203781433@008-AM1MPN1-037.mgdnok.nokia.com> To: X-Mailer: Apple Mail (2.1084) Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Call for review: draft-ietf-mif-dns-server-selection-04.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 13:10:31 -0000 Apologies for the delay in response... On Oct 17, 2011, at 00:21 , wrote: > I need to update the draft quite soon, so I think I'll go for this approach > if no objections: > >> 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 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | CODE | Len | Len of domains in oct |Res|prf| >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Primary DNS-recursive-name-server (IPv4 address) | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Secondary DNS-recursive-name-server (IPv4 address) | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Domains and networks ..... > This is guaranteed to require custom code to parse. If you truly believe users of this option will need to specify more domains than will fit in 255 octets, then bump it to two octets; this will be vastly easier to implement (and, thus more likely to be implemented - and implemented /correctly/). Remember, though, that space in DHCPv4 packets is even more limited than in DHCPv6. Best case (assuming a MTU of 1500), one has 1236 octets to use for options - but some of that is needed for protocol options, relay agent options, and other client configuration options. Worst case, you have only 284 octets total, which means you almost certainly can not fit more than 255 octets of domain names into the packet. Because of this, I would be inclined to leave len-of-domains at one octet. You already note under Scalability Concerns that users should chose the domains they want to use this for carefully due to space limitations. You should update this section to emphasize this for DHCPv4. - Matt From teemu.savolainen@nokia.com Mon Oct 17 06:18:49 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6A6921F8B8A for ; Mon, 17 Oct 2011 06:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.742 X-Spam-Level: X-Spam-Status: No, score=-2.742 tagged_above=-999 required=5 tests=[AWL=-0.143, 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 Z2mXxceO4U04 for ; Mon, 17 Oct 2011 06:18:49 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id B1C0621F8B87 for ; Mon, 17 Oct 2011 06:18:48 -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 p9HDIlgt009703; Mon, 17 Oct 2011 16:18:47 +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); Mon, 17 Oct 2011 16:18:47 +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; Mon, 17 Oct 2011 15:18:46 +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; Mon, 17 Oct 2011 15:18:46 +0200 From: To: Thread-Topic: [dhcwg] Call for review: draft-ietf-mif-dns-server-selection-04.txt Thread-Index: AQHMg4LkcVWrV0ub10WpLpXX7VOVAZV1awAggAq5wsCAADHrgIAAQKfw Date: Mon, 17 Oct 2011 13:18:45 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962037819B3@008-AM1MPN1-037.mgdnok.nokia.com> References: <916CE6CF87173740BC8A2CE4430969620377722C@008-AM1MPN1-037.mgdnok.nokia.com> <415AECEA-6927-4F62-BD6B-44E0B39A0D2B@nominum.com> <916CE6CF87173740BC8A2CE4430969620377C09C@008-AM1MPN1-037.mgdnok.nokia.com> <916CE6CF87173740BC8A2CE44309696203781433@008-AM1MPN1-037.mgdnok.nokia.com> <4E9C10E5.2080505@ntp.org> In-Reply-To: <4E9C10E5.2080505@ntp.org> 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+/nZJb9Kg7IkxE1ZbYbe1tqgA8/XISd7jiTVGxiiZXQRhUP2GIF4tkeOZkpO4pXTpyL5RcoUkhg5mO3TfIGLYbgTej5qp+7RY8m44dei93Wl8ecrS+Uj1tSWqcYrd7yfbw6IJwleWfQq/P5CdEcN6t13zDNw1rXygNe4p1yQnoLpOq4IvP9Tfw8g047tRtp/VOd8pg4Ea6H2XJ+SMExjI+5Jns/cdjvGKMDxewbfP/vJ0OC7y8CPLpQFscV2c0z5qKeoMtCKuFAPNaschWGy7jrOEl5wDK2ds= x-originating-ip: [10.162.93.230] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0145_01CC8CE8.70D26640" MIME-Version: 1.0 X-OriginalArrivalTime: 17 Oct 2011 13:18:47.0083 (UTC) FILETIME=[4D5AFFB0:01CC8CCF] X-Nokia-AV: Clean Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Call for review: draft-ietf-mif-dns-server-selection-04.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 13:18:49 -0000 ------=_NextPart_000_0145_01CC8CE8.70D26640 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > > Maybe a question then would be, if there needs to be two IPv6 > > addresses for DNS servers in the case of DHCPv6 option, or whether > > just single address is enough there (and then have multiple option > > instances if multiple servers need to be configured). > > You need to support both IPv4 and IPv6 addresses here. This has nothing > whatsoever to do with DHCPv6. How come? DNS servers' IPv6 addresses are configured via DHCPv6 option(s). I don't think DHCPv4 option needs to convey IPv6 addresses for DNS servers. Teemu ------=_NextPart_000_0145_01CC8CE8.70D26640 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTExMDE3MTMxODQ0WjAjBgkqhkiG9w0B CQQxFgQUFHBOX7QVp0fzq0mwVH7mF1gWrawwVgYJKwYBBAGCNxAEMUkwRzAzMQswCQYDVQQGEwJG STEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLx MFgGCyqGSIb3DQEJEAILMUmgRzAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNV BAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLxMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMA0GCSqGSIb3DQEBAQUABIIBAJSLfuC+xWBHg3WCOzZ3 XkcBuTJ7Qp0/Z1Eyd2YeW3p1R6F0W2bgThCUf1tVUQQ6jeHehmjD117QxM8nIUZK8U1AnzMsskIi wR6wPXWZmHmIiSh5OtiFi4ajkAjf5rs6R5c5MSKmqHH79VWC3foL8qXrSKurlVJ2AMS8jP/WTu32 qOLT/18cpuTGFegYwlGt6RJGwT5ez2YBo+2vxudKRutiPEddTd8RmU3QyPLxFPwXhljQq2i04uZO gDEPCItfEChsawZRlAV9LU3W6tgCMr4SYOPh0tdnnqrCIh9v+55NYwnHUeecnEq1Tz65nyB11/dK NvGzULmLEmt12HEzcbEAAAAAAAA= ------=_NextPart_000_0145_01CC8CE8.70D26640-- From teemu.savolainen@nokia.com Mon Oct 17 06:29:09 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB4321F8B63 for ; Mon, 17 Oct 2011 06:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.213 X-Spam-Level: X-Spam-Status: No, score=-3.213 tagged_above=-999 required=5 tests=[AWL=0.386, 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 Hza6tcTa2G10 for ; Mon, 17 Oct 2011 06:29:09 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id CE6A821F8783 for ; Mon, 17 Oct 2011 06:29:08 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p9HDSUoo002199; Mon, 17 Oct 2011 16:29:07 +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); Mon, 17 Oct 2011 16:28:06 +0300 Received: from 008-AM1MMR1-003.mgdnok.nokia.com (65.54.30.58) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 17 Oct 2011 15:28: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; Mon, 17 Oct 2011 15:28:06 +0200 From: To: Thread-Topic: [dhcwg] Call for review: draft-ietf-mif-dns-server-selection-04.txt Thread-Index: AQHMg4LkcVWrV0ub10WpLpXX7VOVAZV1awAggAq5wsCAAE7sAIAAJC9w Date: Mon, 17 Oct 2011 13:28:05 +0000 Message-ID: <916CE6CF87173740BC8A2CE44309696203781A5A@008-AM1MPN1-037.mgdnok.nokia.com> References: <916CE6CF87173740BC8A2CE4430969620377722C@008-AM1MPN1-037.mgdnok.nokia.com> <415AECEA-6927-4F62-BD6B-44E0B39A0D2B@nominum.com> <916CE6CF87173740BC8A2CE4430969620377C09C@008-AM1MPN1-037.mgdnok.nokia.com> <916CE6CF87173740BC8A2CE44309696203781433@008-AM1MPN1-037.mgdnok.nokia.com> <46CF2D93-9001-431A-AEE2-1F4F4719130B@nominum.com> In-Reply-To: <46CF2D93-9001-431A-AEE2-1F4F4719130B@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+/nZJb9Kg7IkxE1ZbYbe1tqgA8/XISd7jiTVGxiiZXQRhUP2GIF4tkeOZkpO4pXTpyL5RcoUkhg5mO3TfIGLYbgTej5qp+7RY8m44dei93Wl8ecrS+Uj1tSWqcYrd7yfbw6IJwleWfQq/P5CdEcN6t13zDNw1rXygNe4p1yQnoLpOq4IvP9Tfw8g047tRtp/VOd8pg4Ea6H2XJ+SMExjI+5Jns/cdjvGKMDxewbfP/vJ0OC7y8CPLpQFscV2c0z5qKeoMtCKuFAPNaschWGy7jrOEl5wDK2ds= x-originating-ip: [10.162.93.230] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_014A_01CC8CE9.BEDA54F0" MIME-Version: 1.0 X-OriginalArrivalTime: 17 Oct 2011 13:28:06.0850 (UTC) FILETIME=[9B00AA20:01CC8CD0] X-Nokia-AV: Clean Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Call for review: draft-ietf-mif-dns-server-selection-04.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 13:29:09 -0000 ------=_NextPart_000_014A_01CC8CE9.BEDA54F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, > -----Original Message----- > From: ext Matthew Ryan [mailto:Matt.Ryan@nominum.com] > Sent: 17. lokakuuta 2011 16:10 > To: Savolainen Teemu (Nokia-CTO/Tampere) > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] Call for review: draft-ietf-mif-dns-server-selection- > 04.txt > > Apologies for the delay in response... > > On Oct 17, 2011, at 00:21 , wrote: > > > I need to update the draft quite soon, so I think I'll go for this > > approach if no objections: > > > >> 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 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | CODE | Len | Len of domains in oct |Res|prf| > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Primary DNS-recursive-name-server (IPv4 address) | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Secondary DNS-recursive-name-server (IPv4 address) | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Domains and networks ..... > > > > This is guaranteed to require custom code to parse. If you truly believe > users of this option will need to specify more domains than will fit in 255 > octets, then bump it to two octets; this will be vastly easier to implement > (and, thus more likely to be implemented - and implemented /correctly/). The scenarios I've seen include just few domains, but in order to prepare for more.. so something like this perhaps? Is there need to align IPv4 addresses into 16 or 32-bit boundaries in DHCPv4 option? (if 16, then I'd add one more reserved byte, or 3 to fit for 32 bit boundary). 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CODE | Len | Len of domains in oct | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |prf| Primary DNS-recursive-name-server IPv4 addr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Secondary DNS-recursive-name-server | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 addr | Domains and networks ..... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ..... > Remember, though, that space in DHCPv4 packets is even more limited than > in DHCPv6. Best case (assuming a MTU of 1500), one has 1236 octets to use > for options - but some of that is needed for protocol options, relay agent > options, and other client configuration options. Worst case, you have only > 284 octets total, which means you almost certainly can not fit more than 255 > octets of domain names into the packet. > > Because of this, I would be inclined to leave len-of-domains at one octet. Hmm, I could easily agree also on placing that kind of limitation. Would it be better then to go this road? But still 2 DNS server addresses like (and this would fit much more nicely to 32-bit boundaries as well: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CODE | Len | domains | Res |prf| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Primary DNS-recursive-name-server IPv4 addr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Secondary DNS-recursive-name-server | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Domains and networks ..... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ..... > You already note under Scalability Concerns that users should chose the > domains they want to use this for carefully due to space limitations. You > should update this section to emphasize this for DHCPv4. Good suggestion. I will. Teemu ------=_NextPart_000_014A_01CC8CE9.BEDA54F0 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTExMDE3MTMyODA0WjAjBgkqhkiG9w0B CQQxFgQUgsfRP/6gAMPNHrAk3xSGA4OGfj8wVgYJKwYBBAGCNxAEMUkwRzAzMQswCQYDVQQGEwJG STEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLx MFgGCyqGSIb3DQEJEAILMUmgRzAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNV BAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLxMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMA0GCSqGSIb3DQEBAQUABIIBAK1nrz1Pan05tFLRrTG9 e8jYaYj0p+sui8GCvJKf5kOiKYR4nS+blnaZWFN4CQ0jsLq7X6XbqvFe+DwSd+ane/r5tpMbYkvU d8wcO7YdLShAOxbtKD5/5koI4VHM2eXr4UeHDxaNpv8pNAKLoqfp0hX19BKgTpCfIjgsg/fX5vYm /nVqhmlfk+ARJ5aYhEwUB9Luu6o7WfoOqqAlq6s+UIkHZK8JU+8r5HSz39bdKxpGJSwoPrAhVmIx uMsD1eOMDYDXKBgV8AxKK4d7NY8atoLM+9heXXlGPreJvbcrKHUej1cQymfjF5IgIwa9KMm1ZoQa 7fewJNSruOqXh0flYdoAAAAAAAA= ------=_NextPart_000_014A_01CC8CE9.BEDA54F0-- From Matt.Ryan@nominum.com Mon Oct 17 07:01:15 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF73D21F85DB for ; Mon, 17 Oct 2011 07:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 FetvsPw2lkkw for ; Mon, 17 Oct 2011 07:01:15 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id B178821F84F8 for ; Mon, 17 Oct 2011 07:01:11 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP; Mon, 17 Oct 2011 07:01:15 PDT Received: from vir.ddns.nominum.com (vir.ddns.nominum.com [64.89.225.15]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by shell-too.nominum.com (Postfix) with ESMTP id 039D91B82F4; Mon, 17 Oct 2011 07:01:10 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Matthew Ryan In-Reply-To: <916CE6CF87173740BC8A2CE44309696203781A5A@008-AM1MPN1-037.mgdnok.nokia.com> Date: Mon, 17 Oct 2011 07:01:09 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <916CE6CF87173740BC8A2CE4430969620377722C@008-AM1MPN1-037.mgdnok.nokia.com> <415AECEA-6927-4F62-BD6B-44E0B39A0D2B@nominum.com> <916CE6CF87173740BC8A2CE4430969620377C09C@008-AM1MPN1-037.mgdnok.nokia.com> <916CE6CF87173740BC8A2CE44309696203781433@008-AM1MPN1-037.mgdnok.nokia.com> <46CF2D93-9001-431A-AEE2-1F4F4719130B@nominum.com> <916CE6CF87173740BC8A2CE44309696203781A5A@008-AM1MPN1-037.mgdnok.nokia.com> To: X-Mailer: Apple Mail (2.1084) Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Call for review: draft-ietf-mif-dns-server-selection-04.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 14:01:15 -0000 On Oct 17, 2011, at 06:28 , wrote: > The scenarios I've seen include just few domains, but in order to prepare > for more.. so something like this perhaps? Is there need to align IPv4 > addresses into 16 or 32-bit boundaries in DHCPv4 option? (if 16, then I'd There is no need to align on 16 or 32 bit boundaries; indeed, even if you did, there's no guarantee that the server packing your option would preserve any such alignment. >> >> Because of this, I would be inclined to leave len-of-domains at one >> octet. > > Hmm, I could easily agree also on placing that kind of limitation. Would it > be better then to go this road? But still 2 DNS server addresses like (and > this would fit much more nicely to 32-bit boundaries as well: > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | CODE | Len | domains | Res |prf| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Primary DNS-recursive-name-server IPv4 addr | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Secondary DNS-recursive-name-server | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Domains and networks ..... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ..... > Assuming 'domains' is "length of domains in octets", then yes. - Matt From tomasz.mrugalski@gmail.com Mon Oct 17 07:24:18 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC0A421F8B98 for ; Mon, 17 Oct 2011 07:24:18 -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 QsCr36T9gyWS for ; Mon, 17 Oct 2011 07:24:18 -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 4667221F8B91 for ; Mon, 17 Oct 2011 07:24:18 -0700 (PDT) Received: by wwe6 with SMTP id 6so1478897wwe.13 for ; Mon, 17 Oct 2011 07:24:16 -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=7LI93HDuLNnlF2eAND9o/DQiKnQ6o4PpMTphbAg0GCE=; b=Ct+yVup9EfAJR5V3ZyuGJCDGP171N3bZn0swn6UG24Tpyet95BOcfhjT3sUSZwYuLI 34gQXAh32n9Ou51T/HBJtQal1zDqArO2b7PgZYanfN/xeNIyq/NVYhwpruC4yYGjxj7l 5RCfmZzoNZgdfsO+BRrm2QUsRxwWwAJ+2m/c0= Received: by 10.227.59.70 with SMTP id k6mr6886811wbh.24.1318861456257; Mon, 17 Oct 2011 07:24:16 -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 ff1sm6092315wbb.8.2011.10.17.07.24.13 (version=SSLv3 cipher=OTHER); Mon, 17 Oct 2011 07:24:14 -0700 (PDT) Message-ID: <4E9C3A8B.9010005@gmail.com> Date: Mon, 17 Oct 2011 16:24:11 +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: dhcwg@ietf.org References: In-Reply-To: X-TagToolbar-Keys: D20111017162411831 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dhcwg] Call for adoption - draft-mrugalski-dhc-dhcpv6-failover-requirements-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 14:24:19 -0000 On 24.09.2011 19:04, Brzozowski, John wrote: > draft-mrugalski-dhc-dhcpv6-failover-requirements was presented during the > IETF81 dhcwg meeting. As previously reported there was significant > interest in this work and no objections. > > The purpose of this email is to confirm with the WG the request to adopt > this draft as a working group work item. > > If no objections are received by 5PM ET October 07, 2011 this draft will > be confirmed as a working group work item. Dear chairs, dear group, This deadline has passed and there seem to be no objections. Can I upload this draft as a WG item? Thanks, Tomek From teemu.savolainen@nokia.com Mon Oct 17 07:36:05 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD62E21F849D for ; Mon, 17 Oct 2011 07:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.777 X-Spam-Level: X-Spam-Status: No, score=-2.777 tagged_above=-999 required=5 tests=[AWL=-0.178, 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 3YMytyFGYTuc for ; Mon, 17 Oct 2011 07:36:05 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 1583B21F8492 for ; Mon, 17 Oct 2011 07:36:04 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p9HEZsMd017248; Mon, 17 Oct 2011 17:35:55 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Oct 2011 17:35:42 +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; Mon, 17 Oct 2011 16:35:41 +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; Mon, 17 Oct 2011 16:35:41 +0200 From: To: Thread-Topic: [dhcwg] Call for review: draft-ietf-mif-dns-server-selection-04.txt Thread-Index: AQHMg4LkcVWrV0ub10WpLpXX7VOVAZV1awAggAq5wsCAAE7sAIAAJC9w///qB4CAACrygA== Date: Mon, 17 Oct 2011 14:35:40 +0000 Message-ID: <916CE6CF87173740BC8A2CE44309696203781B2C@008-AM1MPN1-037.mgdnok.nokia.com> References: <916CE6CF87173740BC8A2CE4430969620377722C@008-AM1MPN1-037.mgdnok.nokia.com> <415AECEA-6927-4F62-BD6B-44E0B39A0D2B@nominum.com> <916CE6CF87173740BC8A2CE4430969620377C09C@008-AM1MPN1-037.mgdnok.nokia.com> <916CE6CF87173740BC8A2CE44309696203781433@008-AM1MPN1-037.mgdnok.nokia.com> <46CF2D93-9001-431A-AEE2-1F4F4719130B@nominum.com> <916CE6CF87173740BC8A2CE44309696203781A5A@008-AM1MPN1-037.mgdnok.nokia.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+/nZJb9Kg7IkxE1ZbYbe1tqgA8/XISd7jiTVGxiiZXQRhUP2GIF4tkeOZkpO4pXTpyL5RcoUkhg5mO3TfIGLYbgTej5qp+7RY8m44dei93Wl8ecrS+Uj1tSWqcYrd7yfbw6IJwleWfQq/P5CdEcN6t13zDNw1rXygNe4p1yQnoLpOq4IvP9Tfw8g047tRtp/VOd8pg4Ea6H2XJ+SMExjI+5Jns/cdjvGKMDxewbfP/vJ0OC7y8CPLpQFscV2c0z5qKeoMtCKuFAPNaschWGy7jrOEl5wDK2ds= x-originating-ip: [10.162.93.230] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0169_01CC8CF3.2FD12900" MIME-Version: 1.0 X-OriginalArrivalTime: 17 Oct 2011 14:35:42.0645 (UTC) FILETIME=[0C71DE50:01CC8CDA] X-Nokia-AV: Clean Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Call for review: draft-ietf-mif-dns-server-selection-04.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 14:36:05 -0000 ------=_NextPart_000_0169_01CC8CF3.2FD12900 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > > 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 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | CODE | Len | domains | Res |prf| > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Primary DNS-recursive-name-server IPv4 addr | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Secondary DNS-recursive-name-server | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Domains and networks ..... | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | ..... > > > > Assuming 'domains' is "length of domains in octets", then yes. Yes, in octets (will clarify). Ok, I'll go with this approach and note the limitations in length, if no other comments. Teemu ------=_NextPart_000_0169_01CC8CF3.2FD12900 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTExMDE3MTQzNTM5WjAjBgkqhkiG9w0B CQQxFgQUO8mjrXCy4xa0THptPEMJKZyAr/AwVgYJKwYBBAGCNxAEMUkwRzAzMQswCQYDVQQGEwJG STEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLx MFgGCyqGSIb3DQEJEAILMUmgRzAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNV BAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLxMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMA0GCSqGSIb3DQEBAQUABIIBAK1C8ZpD/Uqj1T508Uku 2uXjAcF8EhW9YLDI4HQfSqrAhO/UJaaRfqce+cYiq48u0MOCyUo3mWIQKr4eDqQ3s2+pVxh0Y+dJ c4Sof33zlDaYCD/PfVupXFEY2H+2PUIFllFo1q3FY6FgaSGl/8vIdlTRTJQY/mtuLczFujiDbJ1U qcu915Rdp/ebk9wUAaeoVnrygc1uwP0okWQA0DlN1rwPAj1DpjtBd0Xv8menkaq3pM3pguGHvXAc zJllXhodAXdo4ycf8Gx1EeBYqcVYLVJh+rl3+IKTyD5XtCaEpwFssWPXsMEOdwHmeqRPd1cPVrCx Fo4rWR18TSLF+yjYqoQAAAAAAAA= ------=_NextPart_000_0169_01CC8CF3.2FD12900-- From Ted.Lemon@nominum.com Mon Oct 17 08:08:18 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD3B121F8C4C for ; Mon, 17 Oct 2011 08:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 sHN5ZxOQkIMS for ; Mon, 17 Oct 2011 08:08:17 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id 775CF21F8C4A for ; Mon, 17 Oct 2011 08:08:17 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP; Mon, 17 Oct 2011 08:08:17 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 4664C1B82E5 for ; Mon, 17 Oct 2011 08:08:15 -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 3E194190064; Mon, 17 Oct 2011 08:08:12 -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, 17 Oct 2011 08:08:12 -0700 From: Ted Lemon To: Danny Mayer Thread-Topic: [dhcwg] Call for review: draft-ietf-mif-dns-server-selection-04.txt Thread-Index: AQHMjL+qLBg1dcPt2EWz2g2OGdE2RJWBGQeA Date: Mon, 17 Oct 2011 15:08:11 +0000 Message-ID: <6395F23E-CF0B-4FE6-BB83-7B93D6532CFD@nominum.com> References: <916CE6CF87173740BC8A2CE4430969620377722C@008-AM1MPN1-037.mgdnok.nokia.com> <415AECEA-6927-4F62-BD6B-44E0B39A0D2B@nominum.com> <916CE6CF87173740BC8A2CE4430969620377C09C@008-AM1MPN1-037.mgdnok.nokia.com> <916CE6CF87173740BC8A2CE44309696203781433@008-AM1MPN1-037.mgdnok.nokia.com> <4E9C10E5.2080505@ntp.org> In-Reply-To: <4E9C10E5.2080505@ntp.org> 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_6395F23ECF0B4FE6BB837B93D6532CFDnominumcom_" MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] Call for review: draft-ietf-mif-dns-server-selection-04.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 15:08:18 -0000 --_000_6395F23ECF0B4FE6BB837B93D6532CFDnominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Oct 17, 2011, at 7:26 AM, Danny Mayer wrote: You need to support both IPv4 and IPv6 addresses here. This has nothing whatsoever to do with DHCPv6. Can you provide a reason for this bizarre assertion? --_000_6395F23ECF0B4FE6BB837B93D6532CFDnominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On Oct 17, 2011, at 7:26 AM, Danny Mayer wrote:
You need to support both IPv4 and IPv6 addresses here. This has nothing
whatsoever to do with DHCPv6.

Can you provide a reason for this bizarre assertion?

--_000_6395F23ECF0B4FE6BB837B93D6532CFDnominumcom_-- From Ted.Lemon@nominum.com Mon Oct 17 08:18:26 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5483121F8CC2 for ; Mon, 17 Oct 2011 08:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 BOh-BCiOZyKG for ; Mon, 17 Oct 2011 08:18:25 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id 8930D21F8CBC for ; Mon, 17 Oct 2011 08:18:25 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP; Mon, 17 Oct 2011 08:18:25 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 807C01B82F0 for ; Mon, 17 Oct 2011 08:18:06 -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 73A07190064; Mon, 17 Oct 2011 08:18:06 -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, 17 Oct 2011 08:18:06 -0700 From: Ted Lemon To: Tomasz Mrugalski Thread-Topic: [dhcwg] Call for adoption - draft-mrugalski-dhc-dhcpv6-failover-requirements-00 Thread-Index: AQHMjNh4IuR7kdE5qEiEyJK6VGO6epWBG5mA Date: Mon, 17 Oct 2011 15:18:06 +0000 Message-ID: References: <4E9C3A8B.9010005@gmail.com> In-Reply-To: <4E9C3A8B.9010005@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_EFAF5D10D0FD4F27916846F1348FA4D1nominumcom_" MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] Call for adoption - draft-mrugalski-dhc-dhcpv6-failover-requirements-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 15:18:26 -0000 --_000_EFAF5D10D0FD4F27916846F1348FA4D1nominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Oct 17, 2011, at 10:24 AM, Tomasz Mrugalski wrote: This deadline has passed and there seem to be no objections. Can I upload this draft as a WG item? Yes, please do. Thanks! --_000_EFAF5D10D0FD4F27916846F1348FA4D1nominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On Oct 17, 2011, at 10:24 AM, Tomasz Mrugalski wrote:
This deadline has passed and there seem to be no objections. Can I
upload this draft as a WG item?

Yes, please do.    Thanks!
--_000_EFAF5D10D0FD4F27916846F1348FA4D1nominumcom_-- From mayer@ntp.org Mon Oct 17 21:14:23 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4AC31F0C62 for ; Mon, 17 Oct 2011 21:14:23 -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 TMl4gagovMPH for ; Mon, 17 Oct 2011 21:14:23 -0700 (PDT) Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by ietfa.amsl.com (Postfix) with ESMTP id 7789A1F0C5D for ; Mon, 17 Oct 2011 21:14:23 -0700 (PDT) Received: from pool-141-157-188-170.bstnma.btas.verizon.net ([141.157.188.170] helo=[10.10.10.102]) by mail1.ntp.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RG14D-0007Yp-RF; Tue, 18 Oct 2011 04:14:18 +0000 Message-ID: <4E9CFD14.10103@ntp.org> Date: Tue, 18 Oct 2011 00:14:12 -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: teemu.savolainen@nokia.com References: <916CE6CF87173740BC8A2CE4430969620377722C@008-AM1MPN1-037.mgdnok.nokia.com> <415AECEA-6927-4F62-BD6B-44E0B39A0D2B@nominum.com> <916CE6CF87173740BC8A2CE4430969620377C09C@008-AM1MPN1-037.mgdnok.nokia.com> <916CE6CF87173740BC8A2CE44309696203781433@008-AM1MPN1-037.mgdnok.nokia.com> <4E9C10E5.2080505@ntp.org> <916CE6CF87173740BC8A2CE443096962037819B3@008-AM1MPN1-037.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE443096962037819B3@008-AM1MPN1-037.mgdnok.nokia.com> X-Enigmail-Version: 1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 141.157.188.170 X-SA-Exim-Rcpt-To: teemu.savolainen@nokia.com, Matt.Ryan@nominum.com, dhcwg@ietf.org X-SA-Exim-Mail-From: mayer@ntp.org X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Call for review: draft-ietf-mif-dns-server-selection-04.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 04:14:24 -0000 On 10/17/2011 9:18 AM, teemu.savolainen@nokia.com wrote: >>> Maybe a question then would be, if there needs to be two IPv6 >>> addresses for DNS servers in the case of DHCPv6 option, or whether >>> just single address is enough there (and then have multiple option >>> instances if multiple servers need to be configured). >> >> You need to support both IPv4 and IPv6 addresses here. This has nothing >> whatsoever to do with DHCPv6. > > How come? DNS servers' IPv6 addresses are configured via DHCPv6 option(s). I > don't think DHCPv4 option needs to convey IPv6 addresses for DNS servers. > > Teemu So you prefer that not only do the people programming the clients have to deal with two separate protocols to get both the IPv4 and IPv6 addresses you also condemn the admins of the dhcp servers to configure this separately? Danny From jiangsheng@huawei.com Mon Oct 17 21:51:22 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C61D11E80AF for ; Mon, 17 Oct 2011 21:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 dyhyfsUMWWIV for ; Mon, 17 Oct 2011 21:51:22 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id DEEEE11E8089 for ; Mon, 17 Oct 2011 21:51:21 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LT800F20W5I2X@szxga05-in.huawei.com> for dhcwg@ietf.org; Tue, 18 Oct 2011 12:51:18 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LT800I06W5H2F@szxga05-in.huawei.com> for dhcwg@ietf.org; Tue, 18 Oct 2011 12:51:18 +0800 (CST) Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEM79730; Tue, 18 Oct 2011 12:51:17 +0800 Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 18 Oct 2011 12:51:15 +0800 Received: from SZXEML506-MBX.china.huawei.com ([169.254.4.167]) by szxeml408-hub.china.huawei.com ([10.82.67.95]) with mapi id 14.01.0270.001; Tue, 18 Oct 2011 12:51:08 +0800 Date: Tue, 18 Oct 2011 04:51:07 +0000 From: Sheng Jiang X-Originating-IP: [10.108.4.60] To: dhc WG Message-id: <5D36713D8A4E7348A7E10DF7437A4B9213A5F593@SZXEML506-MBX.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-GB, zh-CN, en-US Thread-topic: Can you launch the Adoption call for draft-jiang-dhc-addr-registration Thread-index: AcyNUYwesKk+dCh3QJ2UVzAfJrd9tg== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Cc: ChenGang , Ted Lemon Subject: [dhcwg] Can you launch the Adoption call for draft-jiang-dhc-addr-registration X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 04:51:22 -0000 Hi, DHC chair, The authors of draft-jiang-dhc-addr-registration have updated this draft as agreed in IETF81 meeting - removed the address rejection function. We believe this draft is mature to be adopted as DHC WG document. Could you send out the adoption call? Thanks. Best regards, Sheng From teemu.savolainen@nokia.com Tue Oct 18 04:24:20 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E800221F8B8E for ; Tue, 18 Oct 2011 04:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.252 X-Spam-Level: X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[AWL=0.347, 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 TuqHCd2aityT for ; Tue, 18 Oct 2011 04:24:19 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 53EE821F8B88 for ; Tue, 18 Oct 2011 04:24:19 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p9IBO1qH004364; Tue, 18 Oct 2011 14:24:17 +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); Tue, 18 Oct 2011 14:23:32 +0300 Received: from 008-AM1MMR1-001.mgdnok.nokia.com (65.54.30.56) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 18 Oct 2011 13:23:31 +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; Tue, 18 Oct 2011 13:20:17 +0200 From: To: Thread-Topic: [dhcwg] Call for review: draft-ietf-mif-dns-server-selection-04.txt Thread-Index: AQHMg4LkcVWrV0ub10WpLpXX7VOVAZV1awAggAq5wsCAADHrgIAAQKfwgADY5gCAAJgEMA== Date: Tue, 18 Oct 2011 11:20:16 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962037825ED@008-AM1MPN1-037.mgdnok.nokia.com> References: <916CE6CF87173740BC8A2CE4430969620377722C@008-AM1MPN1-037.mgdnok.nokia.com> <415AECEA-6927-4F62-BD6B-44E0B39A0D2B@nominum.com> <916CE6CF87173740BC8A2CE4430969620377C09C@008-AM1MPN1-037.mgdnok.nokia.com> <916CE6CF87173740BC8A2CE44309696203781433@008-AM1MPN1-037.mgdnok.nokia.com> <4E9C10E5.2080505@ntp.org> <916CE6CF87173740BC8A2CE443096962037819B3@008-AM1MPN1-037.mgdnok.nokia.com> <4E9CFD14.10103@ntp.org> In-Reply-To: <4E9CFD14.10103@ntp.org> 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+/nZJb9Kg7IkxE1ZbYbe1tqgA8/XISd7jiTVGxiiZXQRhUP2GIF4tkeOZkpO4pXTpyL5RcoUkhg5mO3TfIGLYbgTej5qp+7RY8m44dei93Wl8ecrS+Uj1tSWqcYrd7yfbw6IJwleWfQq/P5CdEcN6t13zDNw1rXygNe4p1yQnoLpOq4IvP9Tfw8g047tRtp/VOd8pg4Ea6H2XJ+SMExjI+5Jns/cdjvGKMDxewbfP/vJ0OC7y8CPLpQFscV2c0z5qKeoMtCKuFAPNaschWGy7jrOEl5wDK2ds= x-originating-ip: [10.162.93.230] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_01E1_01CC8DA1.0E14FF90" MIME-Version: 1.0 X-OriginalArrivalTime: 18 Oct 2011 11:23:32.0037 (UTC) FILETIME=[5E147750:01CC8D88] X-Nokia-AV: Clean Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Call for review: draft-ietf-mif-dns-server-selection-04.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 11:24:20 -0000 ------=_NextPart_000_01E1_01CC8DA1.0E14FF90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > >> You need to support both IPv4 and IPv6 addresses here. This has > >> nothing whatsoever to do with DHCPv6. > > > > How come? DNS servers' IPv6 addresses are configured via DHCPv6 > > option(s). I don't think DHCPv4 option needs to convey IPv6 addresses for > DNS servers. > > > > Teemu > > So you prefer that not only do the people programming the clients have to > deal with two separate protocols to get both the IPv4 and IPv6 addresses > you also condemn the admins of the dhcp servers to configure this > separately? That's the life in the DHCP-land, I'm afraid. It is also impossible, last time I checked, to perform IPv6 stateful address autoconfiguration with DHCPv4:-) Teemu ------=_NextPart_000_01E1_01CC8DA1.0E14FF90 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTExMDE4MTEyMDE1WjAjBgkqhkiG9w0B CQQxFgQUQ9Z49aJwlywXZ/K6jlXfNbRqX5kwVgYJKwYBBAGCNxAEMUkwRzAzMQswCQYDVQQGEwJG STEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLx MFgGCyqGSIb3DQEJEAILMUmgRzAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNV BAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLxMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMA0GCSqGSIb3DQEBAQUABIIBAGwaAYagxlUfWSCAZ2/Z NJUjTxBF9zL1+qWpF1HO3IiKoeBigrsp3lWQKCJd1SLjK7PL3q50pVN0xciM9/iww1H3OGgb86XB QGulRsMqGcAjXRMSetnKMSycvB9OgpgkB1QypyfkKZxcQ/vll1bfKZTDKYfIOxTMxS76Y9kF+iDw d8DhhqfGX5UwFjBW0FkZJGt4M4Q215CYpsHrBYhK7UcNlHP459sI+Jpdax6iSMpyAwziy+gVHCMt nF0kukPxnZvsn4wq+vJjyTxVuA83SkPSM1tiph6KY5LLWtXjD3CVIUKQqmOm74xH0/p0mPdAmiq/ 0O0wSB+1cDy6u2OnnXwAAAAAAAA= ------=_NextPart_000_01E1_01CC8DA1.0E14FF90-- From Ted.Lemon@nominum.com Tue Oct 18 07:52:36 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35C8821F8B54 for ; Tue, 18 Oct 2011 07:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 XfaKlGx832xm for ; Tue, 18 Oct 2011 07:52:35 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id 4DFBC21F8B44 for ; Tue, 18 Oct 2011 07:52:35 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP; Tue, 18 Oct 2011 07:52:35 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 BCA6E1B8317 for ; Tue, 18 Oct 2011 07:52:33 -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 AA1DB190065; Tue, 18 Oct 2011 07:52:33 -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; Tue, 18 Oct 2011 07:52:34 -0700 From: Ted Lemon To: Danny Mayer Thread-Topic: [dhcwg] Call for review: draft-ietf-mif-dns-server-selection-04.txt Thread-Index: AQHMjUxwLVmPnVVvVkKtql7AqIv1uZWCpeKA Date: Tue, 18 Oct 2011 14:52:33 +0000 Message-ID: References: <916CE6CF87173740BC8A2CE4430969620377722C@008-AM1MPN1-037.mgdnok.nokia.com> <415AECEA-6927-4F62-BD6B-44E0B39A0D2B@nominum.com> <916CE6CF87173740BC8A2CE4430969620377C09C@008-AM1MPN1-037.mgdnok.nokia.com> <916CE6CF87173740BC8A2CE44309696203781433@008-AM1MPN1-037.mgdnok.nokia.com> <4E9C10E5.2080505@ntp.org> <916CE6CF87173740BC8A2CE443096962037819B3@008-AM1MPN1-037.mgdnok.nokia.com> <4E9CFD14.10103@ntp.org> In-Reply-To: <4E9CFD14.10103@ntp.org> 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_D92E3DEF17AD44EAAAABD73EE2A9975Fnominumcom_" MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] Call for review: draft-ietf-mif-dns-server-selection-04.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 14:52:36 -0000 --_000_D92E3DEF17AD44EAAAABD73EE2A9975Fnominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Oct 18, 2011, at 12:14 AM, Danny Mayer wrote: So you prefer that not only do the people programming the clients have to deal with two separate protocols to get both the IPv4 and IPv6 addresses you also condemn the admins of the dhcp servers to configure this separately? They have to implement these protocols anyway. A dual-stack DHCP protocol= is out of scope. --_000_D92E3DEF17AD44EAAAABD73EE2A9975Fnominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <80765B8D8DB94A44880536304AB17977@nominum.com> Content-Transfer-Encoding: quoted-printable
On Oct 18, 2011, at 12:14 AM, Danny Mayer wrote:
So you prefer that not only do the people programming the clients have
to deal with two separate protocols to get both the IPv4 and IPv6
addresses you also condemn the admins of the dhcp servers to configure
this separately?

They have to implement these protocols anyway.   A dual-stack DHC= P protocol is out of scope. 
--_000_D92E3DEF17AD44EAAAABD73EE2A9975Fnominumcom_-- From teemu.savolainen@nokia.com Tue Oct 18 23:43:07 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@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 Subject: Re: [dhcwg] [mif] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@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 07:23:52 -0700 Cc: "" , "" , "" , "" , "" , "" Subject: Re: [dhcwg] [dnsext] [mif] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@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) X-Mailman-Approved-At: Wed, 19 Oct 2011 07:23:52 -0700 Cc: "" , "" , "" , "" , "" , "" Subject: Re: [dhcwg] [mif] [dnsext] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@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) X-Mailman-Approved-At: Wed, 19 Oct 2011 07:23:52 -0700 Subject: [dhcwg] bare names (was: [mif] [dnsext] 2nd Last Call for MIF DNS server selection document) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mif@ietf.org List-Id: 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: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@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) X-Mailman-Approved-At: Wed, 19 Oct 2011 07:23:52 -0700 Cc: dhcwg@ietf.org, dnsop@ietf.org, dnsext@ietf.org Subject: Re: [dhcwg] [mif] bare names (was: [dnsext] 2nd Last Call for MIF DNS server selection document) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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 Matt.Ryan@nominum.com Wed Oct 19 08:45:10 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1665F21F8B7F for ; Wed, 19 Oct 2011 08:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 AS-0dLRyzY8C for ; Wed, 19 Oct 2011 08:45:09 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id AF8B321F8B73 for ; Wed, 19 Oct 2011 08:45:05 -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 08:45:09 PDT Received: from vir.ddns.nominum.com (vir.ddns.nominum.com [64.89.225.15]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by shell-too.nominum.com (Postfix) with ESMTP id 28FDB1B830F; Wed, 19 Oct 2011 08:45:00 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Matthew Ryan In-Reply-To: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> Date: Wed, 19 Oct 2011 08:44:59 -0700 Content-Transfer-Encoding: 7bit Message-Id: <4A52F3C9-137D-4EC7-B100-B130422D273C@nominum.com> References: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> To: X-Mailer: Apple Mail (2.1084) Cc: dhc WG Subject: Re: [dhcwg] [mif] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 15:45:10 -0000 Reading through the diff made me realize that the format I suggested for the DHCPv4 option has a problem with it - fortunately, easily fixed. There is also potential confusion with the naming chosen for the domains-and-networks length octet. The domains-and-networks length octet, which is now called 'Payload length' is defined to be the length of only the domains-and-networks field. I think, given the name, combined with the position in the option, people may incorrectly interpret it as including the length of the DNS server IP addresses. I believe the octet should be moved to just before the domains-and-networks field. This will not only make it abundantly clear that it only covers the length of that field, but also make it easier to parse. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CODE | Len | Reserved |prf| Primary DNS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Primary DNS cont. (IPv4 address) | Secondary DNS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Secondary DNS cont. (IPv4 address) | Payload len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Domains and networks | | (variable length) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The other option would be to leave the payload-length octet where it is and redefine it to include the DNS server IP addresses, but the reduces the possible number and length of domains that can be included. In either case, it's a bad idea to have something of the form , where only covers . I should've caught that before suggesting the format, but it completely slipped my mind - my apologies. - Matt From Ted.Lemon@nominum.com Wed Oct 19 09:06:46 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@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: [dhcwg] [mif] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@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) X-Mailman-Approved-At: Wed, 19 Oct 2011 10:13:58 -0700 Cc: dhcwg@ietf.org, dnsop@ietf.org, mif@ietf.org, dnsext@ietf.org Subject: Re: [dhcwg] [mif] bare names (was: [dnsext] 2nd Last Call for MIF DNS server selection document) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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 teemu.savolainen@nokia.com Wed Oct 19 10:43:10 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8741D21F8AC9 for ; Wed, 19 Oct 2011 10:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.337 X-Spam-Level: X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[AWL=-0.338, BAYES_00=-2.599, J_CHICKENPOX_83=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 22Cf2CsoH566 for ; Wed, 19 Oct 2011 10:43:10 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id E8E0421F85A1 for ; Wed, 19 Oct 2011 10:43:09 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p9JHgpi4004084; Wed, 19 Oct 2011 20:43:08 +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); Wed, 19 Oct 2011 20:43:04 +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 19:43:04 +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 19:43:03 +0200 From: To: Thread-Topic: [dhcwg] [mif] 2nd Last Call for MIF DNS server selection document Thread-Index: AQHMf4YJc1OWueh3WEqDYlN2BZxXYpWDUwvAgAB4f4CAAEDf4A== Date: Wed, 19 Oct 2011 17:43:03 +0000 Message-ID: <916CE6CF87173740BC8A2CE44309696203783610@008-AM1MPN1-037.mgdnok.nokia.com> References: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> <4A52F3C9-137D-4EC7-B100-B130422D273C@nominum.com> In-Reply-To: <4A52F3C9-137D-4EC7-B100-B130422D273C@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/pAr9wVdKqUwQbUQjCquPHDrqtCI7pRem1bC+EpRaXgzsh80TSJsHP31fVo6KuZY/1s393WMnr+6CwzG6xrh+dkQbig4z1aNhD7YYU269t4wbGeOYyL9viRTGnJsdkzfZPKBTNwW/J6w9rjNSGzHWqcl0t3hSGPtE1/TzA02TnkeWR9qZYIdjPA2HtGk5fpvXlURO+PYDL0BzZy8VYI7fcZjY= x-originating-ip: [10.162.93.230] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_02C4_01CC8E9F.B1B316B0" MIME-Version: 1.0 X-OriginalArrivalTime: 19 Oct 2011 17:43:04.0597 (UTC) FILETIME=[8DFF1C50:01CC8E86] X-Nokia-AV: Clean Cc: dhcwg@ietf.org Subject: Re: [dhcwg] [mif] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 17:43:10 -0000 ------=_NextPart_000_02C4_01CC8E9F.B1B316B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > -----Original Message----- > From: ext Matthew Ryan [mailto:Matt.Ryan@nominum.com] > Sent: 19. lokakuuta 2011 18:45 > To: Savolainen Teemu (Nokia-CTO/Tampere) > Cc: dhc WG > Subject: Re: [dhcwg] [mif] 2nd Last Call for MIF DNS server selection > document > > Reading through the diff made me realize that the format I suggested for > the DHCPv4 option has a problem with it - fortunately, easily fixed. There is > also potential confusion with the naming chosen for the domains-and- > networks length octet. > > The domains-and-networks length octet, which is now called 'Payload > length' is defined to be the length of only the domains-and-networks field. I > think, given the name, combined with the position in the option, people may > incorrectly interpret it as including the length of the DNS server IP addresses. > > I believe the octet should be moved to just before the domains-and- > networks field. This will not only make it abundantly clear that it only covers > the length of that field, but also make it easier to parse. > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | CODE | Len | Reserved |prf| Primary DNS | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Primary DNS cont. (IPv4 address) | Secondary DNS | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Secondary DNS cont. (IPv4 address) | Payload len | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | Domains and networks | > | (variable length) | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The problem with this is that it would take DNS server IPv4 addresses out of the 32-bit boundary, which does not look very nice and can cause implementation issues as well (there are OSes/CPUs where 32 bit values must locate at 32bit boundaries in memory, otherwise they have to be moved/copied per-byte). > The other option would be to leave the payload-length octet where it is and > redefine it to include the DNS server IP addresses, but the reduces the > possible number and length of domains that can be included. I like this one - the option length is anyway dictated by the "Len" field's one byte limitation, right? So we can as well define this "payload len" to include DNS server IP addresses and reserved+prf. But in that case it would be almost the same as "Len" field (1 byte difference), so what do we need the "payload len" again?-) Best regards, Teemu ------=_NextPart_000_02C4_01CC8E9F.B1B316B0 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTExMDE5MTc0MzAxWjAjBgkqhkiG9w0B CQQxFgQUzgZWruumxjAjcM2bnhATDkStTLYwVgYJKwYBBAGCNxAEMUkwRzAzMQswCQYDVQQGEwJG STEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLx MFgGCyqGSIb3DQEJEAILMUmgRzAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNV BAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLxMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMA0GCSqGSIb3DQEBAQUABIIBAKWM8IXoTA8wqK6P553n w4H0QFIQz1k97YppchCOevJl4+YrPVfOv+hK1pEpGqPuzJjlJkVTTsYiUiJQuX9rL9LkJ+dlDVnx E80ZnWEooIg6u9K2u/C1wNoTmIHCM0RTmGhbuhSLir1Cueg0kKaFTCmwrQaC3hq+5/IrEBC4DZW5 xSFdDTrO7BFFjhrMEJU8g0PDd9eAercGWi3kDpq0e4VL9T2vCGQLQh4yldRMBO3mlkzHBE6Xx+JB zkql9MyA+mT4dxYu8foMQxIwjnwC1/4BslujGs8mb6KdoXtWphhh56HHLUzKIgBqhLysashodPqQ Kd8uiG++VZc1rzKCeecAAAAAAAA= ------=_NextPart_000_02C4_01CC8E9F.B1B316B0-- From teemu.savolainen@nokia.com Wed Oct 19 10:58:59 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@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: [dhcwg] [mif] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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 brian.peter.dickson@gmail.com Wed Oct 19 11:34:21 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@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 11:38:55 -0700 Cc: mif@ietf.org, dnsop@ietf.org, dnsext@ietf.org, pk@isoc.de, Ted.Lemon@nominum.com, dhcwg@ietf.org, denghui02@hotmail.com Subject: Re: [dhcwg] [dnsext] [mif] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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 Ted.Lemon@nominum.com Wed Oct 19 12:07:28 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF11C11E80B3 for ; Wed, 19 Oct 2011 12:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.501 X-Spam-Level: X-Spam-Status: No, score=-106.501 tagged_above=-999 required=5 tests=[AWL=0.097, 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 5+T5x5lClnhX for ; Wed, 19 Oct 2011 12:07:28 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id EC72811E80B1 for ; Wed, 19 Oct 2011 12:07:27 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP; Wed, 19 Oct 2011 12:07:28 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 F23161B830F for ; Wed, 19 Oct 2011 12:07:26 -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 DE2B5190065; Wed, 19 Oct 2011 12:07:25 -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 12:07:26 -0700 From: Ted Lemon To: " " Thread-Topic: [dhcwg] [mif] 2nd Last Call for MIF DNS server selection document Thread-Index: AQHMjoaVx8vnMCfCH0ulwC2Rf+gwapWEfPiA Date: Wed, 19 Oct 2011 19:07:25 +0000 Message-ID: <59E9C1BA-CE02-431F-84D2-0ECEA2BB6635@nominum.com> References: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> <4A52F3C9-137D-4EC7-B100-B130422D273C@nominum.com> <916CE6CF87173740BC8A2CE44309696203783610@008-AM1MPN1-037.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE44309696203783610@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_59E9C1BACE02431F84D20ECEA2BB6635nominumcom_" MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] [mif] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 19:07:28 -0000 --_000_59E9C1BACE02431F84D20ECEA2BB6635nominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Oct 19, 2011, at 1:43 PM, > > wrote: The problem with this is that it would take DNS server IPv4 addresses out o= f the 32-bit boundary, which does not look very nice and can cause implementation issues as well (there are OSes/CPUs where 32 bit values must locate at 32bit boundaries in memory, otherwise they have to be moved/copie= d per-byte). DHCP options are never aligned, and must be copied, so this is a non-issue. --_000_59E9C1BACE02431F84D20ECEA2BB6635nominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <53C3DE908694914F83CA23A895FBA7FF@nominum.com> Content-Transfer-Encoding: quoted-printable
On Oct 19, 2011, at 1:43 PM, <teemu.savolainen@nokia.com>
The problem with this is that it would take DNS server IPv4 addresses out of the 32-bit boundary, which does not look very nice and can cause
implementation issues as well (there are OSes/CPUs where 32 bit values must=
locate at 32bit boundaries in memory, otherwise they have to be moved/copie= d
per-byte).

DHCP options are never aligned, and must be copied, so this is a non-i= ssue.

--_000_59E9C1BACE02431F84D20ECEA2BB6635nominumcom_-- From Ted.Lemon@nominum.com Wed Oct 19 12:09:01 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@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: [dhcwg] [mif] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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 Matt.Ryan@nominum.com Wed Oct 19 13:38:21 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 535CE21F8B24 for ; Wed, 19 Oct 2011 13:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_83=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 ZYhSUKG9LWth for ; Wed, 19 Oct 2011 13:38:20 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id CD64421F8B4F for ; Wed, 19 Oct 2011 13:38:16 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP; Wed, 19 Oct 2011 13:38:20 PDT Received: from vir.ddns.nominum.com (vir.ddns.nominum.com [64.89.225.15]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by shell-too.nominum.com (Postfix) with ESMTP id 773321B8315; Wed, 19 Oct 2011 13:38:14 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Matthew Ryan In-Reply-To: <916CE6CF87173740BC8A2CE44309696203783610@008-AM1MPN1-037.mgdnok.nokia.com> Date: Wed, 19 Oct 2011 13:38:13 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> <4A52F3C9-137D-4EC7-B100-B130422D273C@nominum.com> <916CE6CF87173740BC8A2CE44309696203783610@008-AM1MPN1-037.mgdnok.nokia.com> To: X-Mailer: Apple Mail (2.1084) Cc: dhcwg@ietf.org Subject: Re: [dhcwg] [mif] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 20:38:21 -0000 On Oct 19, 2011, at 10:43 , wrote: >> From: ext Matthew Ryan [mailto:Matt.Ryan@nominum.com] >> I believe the octet should be moved to just before the domains-and- >> networks field. This will not only make it abundantly clear that it = only > covers >> the length of that field, but also make it easier to parse. > The problem with this is that it would take DNS server IPv4 addresses = out of > the 32-bit boundary, which does not look very nice and can cause > implementation issues as well (there are OSes/CPUs where 32 bit values = must > locate at 32bit boundaries in memory, otherwise they have to be = moved/copied > per-byte). Except you are already subject to that issue, since there is no guarantee that the start of the option will be aligned on any particular 16 or 32 bit boundary. An option that appears before this option may cause it to be non-aligned. Implementations of DHCP can't require options or their contents to have a given alignment. >=20 >> The other option would be to leave the payload-length octet where it = is > and >> redefine it to include the DNS server IP addresses, but the reduces = the >> possible number and length of domains that can be included. >=20 > I like this one - the option length is anyway dictated by the "Len" = field's > one byte limitation, right? So we can as well define this "payload = len" to > include DNS server IP addresses and reserved+prf. But in that case it = would > be almost the same as "Len" field (1 byte difference), so what do we = need > the "payload len" again?-) Option concatenation - since you want the ability (to match the DHCPv6 version) of being able to specify multiple redirections, e.g., having foo.com go to 1.1.1.1/1.1.1.2, and bar.com go to 2.2.2.1/2.2.2.2. And now I realize that aspect was lost somewhere along the way. From an earlier mail in the discussion (modified to correct the position of the payload length octet, and stealing verbiage from prior RFCs), the actual option format should be: 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=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | option-code | option-len | dssd-list (var. length) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code: (TBD) option-len: Length of the option in octets dssd-list: One or more instances of DNS Server Selection Data, defined below. Each instance of DNS Server Selection Data is formatted as follows: 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=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |prf| Primary DNS (IPv4 address) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pri DNS cont. | Secondary DNS (IPv4 address) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sec DNS cont. | Payload len | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Domains and networks | | (variable length) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The following paragraph in section 4.3 should be removed: The OPTION_DNS_SERVER_SELECT contains one or more domains the related primary and secondary DNS servers have particular knowledge of. The option can occur only once in a single DHCPv4 message and is limited in length. The maximum length in octets for the domains and networks field is 245 octets. and replaced with: The DHCPv4 long-options mechanism described in [RFC 3396] MUST be used if the option exceeds the maximum DHCPv4 option size of 255 octets. The bit about DNS servers having knowledge about related domains is already covered in the description of the "Domains and networks" field. And finally, in Section 6, you should change: The size limitation is stricter in the case of DHCPv4 where only one option instance is possible with maximum of 245 octets for domains and networks list. In the case of DHCPv6 the restriction is not as strict. to something like: This is especially true for DHCPv4, where the maximum DHCP packet size may be as low as 576 octets. =20 - Matt From teemu.savolainen@nokia.com Wed Oct 19 14:03:23 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE0A1F0C55 for ; Wed, 19 Oct 2011 14:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[AWL=-0.305, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_83=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 glQTVjvZH7yY for ; Wed, 19 Oct 2011 14:03:22 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 3156E1F0C4B for ; Wed, 19 Oct 2011 14:03:22 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p9JL3HCl027578; Thu, 20 Oct 2011 00:03:21 +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); Thu, 20 Oct 2011 00:03:19 +0300 Received: from 008-AM1MMR1-002.mgdnok.nokia.com (65.54.30.57) 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 23:03:19 +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; Wed, 19 Oct 2011 23:03:18 +0200 From: To: Thread-Topic: [dhcwg] [mif] 2nd Last Call for MIF DNS server selection document Thread-Index: AQHMf4YJc1OWueh3WEqDYlN2BZxXYpWDUwvAgAB4f4CAAEDf4IAAEQ6AgAAG+oA= Date: Wed, 19 Oct 2011 21:03:18 +0000 Message-ID: <916CE6CF87173740BC8A2CE44309696203783B93@008-AM1MPN1-037.mgdnok.nokia.com> References: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> <4A52F3C9-137D-4EC7-B100-B130422D273C@nominum.com> <916CE6CF87173740BC8A2CE44309696203783610@008-AM1MPN1-037.mgdnok.nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_916CE6CF87173740BC8A2CE44309696203783B93008AM1MPN1037mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 19 Oct 2011 21:03:19.0521 (UTC) FILETIME=[87730510:01CC8EA2] X-Nokia-AV: Clean Cc: dhcwg@ietf.org Subject: Re: [dhcwg] [mif] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 21:03:23 -0000 --_000_916CE6CF87173740BC8A2CE44309696203783B93008AM1MPN1037mg_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm8sIHdlIGRlY2lkZWQgYWdhaW5zdCBzdWJvcHRpb25zIGFuZCBjb25jYXRlbmF0aW9uIGFzIHdl bGwgLSB0byBqdXN0IGhhdmUgc2luZ2xlIG9wdGlvbiBhbmQgc3RyaWN0bHkgbGltaXQgdGhlIGxl bmdodCBvZiB0aGUgZG9tYWlucy1maWVsZC4gSWYgSSByZWNhbGwgY29ycmVjdGx5LCBpdCB3YXMg ZHVlIERIQ1B2NCByZWxheXMgaW4gc29tZSBjYXNlcyBsaW1pdGluZyB0aGUgYXZhaWxhYmxlIERI Q1B2NCBtZXNzYWdlIHNpemUuLiBUaGF0J3Mgd2h5IHRoZSBsYXRlc3QgdmVyc2lvbiBpcyBjaGFu Z2VkIGluIHNvIG1hbnkgbG9jYXRpb25zIHJlbGF0ZWQgdG8gdGhpcyBpc3N1ZS4NCg0KT2sgb24g YWxpZ25tZW50IGlzc3VlLg0KDQoNCkNvdWxkIHdlIHRoZW4gcmVtb3ZlIHRoZSBzZWNvbmQgbGVu Z3RoIGZpZWxkIGFuZCBoZW5jZSBnYWluIG9uZSBhZGRpdGlvbmFsIGJ5dGUgZm9yIGRvbWFpbnMg dmFyaWFibGUgbGVuZ2h0IGZpZWxkPw0KDQotLQ0KU2VudCBmcm9tIG15IE5va2lhIE45DQoNCg0K T24gMTkuMTAuMjAxMSAyMzozOCBleHQgTWF0dGhldyBSeWFuIHdyb3RlOg0KDQpPbiBPY3QgMTks IDIwMTEsIGF0IDEwOjQzICwgPHRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tPiB3cm90ZToNCj4+ IEZyb206IGV4dCBNYXR0aGV3IFJ5YW4gW21haWx0bzpNYXR0LlJ5YW5Abm9taW51bS5jb21dDQo+ PiBJIGJlbGlldmUgdGhlIG9jdGV0IHNob3VsZCBiZSBtb3ZlZCB0byBqdXN0IGJlZm9yZSB0aGUg ZG9tYWlucy1hbmQtDQo+PiBuZXR3b3JrcyBmaWVsZC4gVGhpcyB3aWxsIG5vdCBvbmx5IG1ha2Ug aXQgYWJ1bmRhbnRseSBjbGVhciB0aGF0IGl0IG9ubHkNCj4gY292ZXJzDQo+PiB0aGUgbGVuZ3Ro IG9mIHRoYXQgZmllbGQsIGJ1dCBhbHNvIG1ha2UgaXQgZWFzaWVyIHRvIHBhcnNlLg0KDQo+IFRo ZSBwcm9ibGVtIHdpdGggdGhpcyBpcyB0aGF0IGl0IHdvdWxkIHRha2UgRE5TIHNlcnZlciBJUHY0 IGFkZHJlc3NlcyBvdXQgb2YNCj4gdGhlIDMyLWJpdCBib3VuZGFyeSwgd2hpY2ggZG9lcyBub3Qg bG9vayB2ZXJ5IG5pY2UgYW5kIGNhbiBjYXVzZQ0KPiBpbXBsZW1lbnRhdGlvbiBpc3N1ZXMgYXMg d2VsbCAodGhlcmUgYXJlIE9TZXMvQ1BVcyB3aGVyZSAzMiBiaXQgdmFsdWVzIG11c3QNCj4gbG9j YXRlIGF0IDMyYml0IGJvdW5kYXJpZXMgaW4gbWVtb3J5LCBvdGhlcndpc2UgdGhleSBoYXZlIHRv IGJlIG1vdmVkL2NvcGllZA0KPiBwZXItYnl0ZSkuDQoNCkV4Y2VwdCB5b3UgYXJlIGFscmVhZHkg c3ViamVjdCB0byB0aGF0IGlzc3VlLCBzaW5jZSB0aGVyZSBpcyBubw0KZ3VhcmFudGVlIHRoYXQg dGhlIHN0YXJ0IG9mIHRoZSBvcHRpb24gd2lsbCBiZSBhbGlnbmVkIG9uDQphbnkgcGFydGljdWxh ciAxNiBvciAzMiBiaXQgYm91bmRhcnkuIEFuIG9wdGlvbiB0aGF0IGFwcGVhcnMNCmJlZm9yZSB0 aGlzIG9wdGlvbiBtYXkgY2F1c2UgaXQgdG8gYmUgbm9uLWFsaWduZWQuIEltcGxlbWVudGF0aW9u cw0Kb2YgREhDUCBjYW4ndCByZXF1aXJlIG9wdGlvbnMgb3IgdGhlaXIgY29udGVudHMgdG8gaGF2 ZSBhIGdpdmVuDQphbGlnbm1lbnQuDQoNCj4NCj4+IFRoZSBvdGhlciBvcHRpb24gd291bGQgYmUg dG8gbGVhdmUgdGhlIHBheWxvYWQtbGVuZ3RoIG9jdGV0IHdoZXJlIGl0IGlzDQo+IGFuZA0KPj4g cmVkZWZpbmUgaXQgdG8gaW5jbHVkZSB0aGUgRE5TIHNlcnZlciBJUCBhZGRyZXNzZXMsIGJ1dCB0 aGUgcmVkdWNlcyB0aGUNCj4+IHBvc3NpYmxlIG51bWJlciBhbmQgbGVuZ3RoIG9mIGRvbWFpbnMg dGhhdCBjYW4gYmUgaW5jbHVkZWQuDQo+DQo+IEkgbGlrZSB0aGlzIG9uZSAtIHRoZSBvcHRpb24g bGVuZ3RoIGlzIGFueXdheSBkaWN0YXRlZCBieSB0aGUgIkxlbiIgZmllbGQncw0KPiBvbmUgYnl0 ZSBsaW1pdGF0aW9uLCByaWdodD8gU28gd2UgY2FuIGFzIHdlbGwgZGVmaW5lIHRoaXMgInBheWxv YWQgbGVuIiB0bw0KPiBpbmNsdWRlIEROUyBzZXJ2ZXIgSVAgYWRkcmVzc2VzIGFuZCByZXNlcnZl ZCtwcmYuIEJ1dCBpbiB0aGF0IGNhc2UgaXQgd291bGQNCj4gYmUgYWxtb3N0IHRoZSBzYW1lIGFz ICJMZW4iIGZpZWxkICgxIGJ5dGUgZGlmZmVyZW5jZSksIHNvIHdoYXQgZG8gd2UgbmVlZA0KPiB0 aGUgInBheWxvYWQgbGVuIiBhZ2Fpbj8tKQ0KDQpPcHRpb24gY29uY2F0ZW5hdGlvbiAtIHNpbmNl IHlvdSB3YW50IHRoZSBhYmlsaXR5ICh0byBtYXRjaCB0aGUgREhDUHY2DQp2ZXJzaW9uKSBvZiBi ZWluZyBhYmxlIHRvIHNwZWNpZnkgbXVsdGlwbGUgcmVkaXJlY3Rpb25zLCBlLmcuLCBoYXZpbmcN CmZvby5jb20gZ28gdG8gMS4xLjEuMS8xLjEuMS4yLCBhbmQgYmFyLmNvbSBnbyB0byAyLjIuMi4x LzIuMi4yLjIuDQoNCkFuZCBub3cgSSByZWFsaXplIHRoYXQgYXNwZWN0IHdhcyBsb3N0IHNvbWV3 aGVyZSBhbG9uZyB0aGUgd2F5LiBGcm9tDQphbiBlYXJsaWVyIG1haWwgaW4gdGhlIGRpc2N1c3Np b24gKG1vZGlmaWVkIHRvIGNvcnJlY3QgdGhlIHBvc2l0aW9uIG9mDQp0aGUgcGF5bG9hZCBsZW5n dGggb2N0ZXQsIGFuZCBzdGVhbGluZyB2ZXJiaWFnZSBmcm9tIHByaW9yIFJGQ3MpLCB0aGUNCmFj dHVhbCBvcHRpb24gZm9ybWF0IHNob3VsZCBiZToNCg0KMCAxIDIgMw0KMCAxIDIgMyA0IDUgNiA3 IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxDQorLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Kw0KfCBvcHRpb24tY29kZSB8IG9wdGlvbi1sZW4gfCBkc3NkLWxpc3QgKHZhci4gbGVuZ3RoKSAu Li4NCistKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rDQoNCm9wdGlvbi1jb2RlOiAoVEJEKQ0KDQpvcHRpb24tbGVuOiBMZW5ndGgg b2YgdGhlIG9wdGlvbiBpbiBvY3RldHMNCg0KZHNzZC1saXN0OiBPbmUgb3IgbW9yZSBpbnN0YW5j ZXMgb2YgRE5TIFNlcnZlciBTZWxlY3Rpb24gRGF0YSwNCmRlZmluZWQgYmVsb3cuDQoNCkVhY2gg aW5zdGFuY2Ugb2YgRE5TIFNlcnZlciBTZWxlY3Rpb24gRGF0YSBpcyBmb3JtYXR0ZWQgYXMgZm9s bG93czoNCg0KMCAxIDIgMw0KMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5 IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxDQorLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KfCBSZXNlcnZlZCB8cHJmfCBQcmlt YXJ5IEROUyAoSVB2NCBhZGRyZXNzKSB8DQorLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KfCBQcmkgRE5TIGNvbnQuIHwgU2Vj b25kYXJ5IEROUyAoSVB2NCBhZGRyZXNzKSB8DQorLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KfCBTZWMgRE5TIGNvbnQuIHwg UGF5bG9hZCBsZW4gfCB8DQorLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgfA0KfCB8 DQp8IERvbWFpbnMgYW5kIG5ldHdvcmtzIHwNCnwgKHZhcmlhYmxlIGxlbmd0aCkgfA0KfCB8DQor LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKw0KDQoNCg0KVGhlIGZvbGxvd2luZyBwYXJhZ3JhcGggaW4gc2VjdGlvbiA0LjMgc2hv dWxkIGJlIHJlbW92ZWQ6DQpUaGUgT1BUSU9OX0ROU19TRVJWRVJfU0VMRUNUIGNvbnRhaW5zIG9u ZSBvciBtb3JlIGRvbWFpbnMgdGhlIHJlbGF0ZWQNCnByaW1hcnkgYW5kIHNlY29uZGFyeSBETlMg c2VydmVycyBoYXZlIHBhcnRpY3VsYXIga25vd2xlZGdlIG9mLiBUaGUNCm9wdGlvbiBjYW4gb2Nj dXIgb25seSBvbmNlIGluIGEgc2luZ2xlIERIQ1B2NCBtZXNzYWdlIGFuZCBpcyBsaW1pdGVkDQpp biBsZW5ndGguIFRoZSBtYXhpbXVtIGxlbmd0aCBpbiBvY3RldHMgZm9yIHRoZSBkb21haW5zIGFu ZCBuZXR3b3Jrcw0KZmllbGQgaXMgMjQ1IG9jdGV0cy4NCg0KYW5kIHJlcGxhY2VkIHdpdGg6DQpU aGUgREhDUHY0IGxvbmctb3B0aW9ucyBtZWNoYW5pc20gZGVzY3JpYmVkIGluIFtSRkMgMzM5Nl0g TVVTVCBiZQ0KdXNlZCBpZiB0aGUgb3B0aW9uIGV4Y2VlZHMgdGhlIG1heGltdW0gREhDUHY0IG9w dGlvbiBzaXplIG9mIDI1NQ0Kb2N0ZXRzLg0KDQpUaGUgYml0IGFib3V0IEROUyBzZXJ2ZXJzIGhh dmluZyBrbm93bGVkZ2UgYWJvdXQgcmVsYXRlZCBkb21haW5zDQppcyBhbHJlYWR5IGNvdmVyZWQg aW4gdGhlIGRlc2NyaXB0aW9uIG9mIHRoZSAiRG9tYWlucyBhbmQgbmV0d29ya3MiDQpmaWVsZC4N Cg0KQW5kIGZpbmFsbHksIGluIFNlY3Rpb24gNiwgeW91IHNob3VsZCBjaGFuZ2U6DQpUaGUgc2l6 ZSBsaW1pdGF0aW9uIGlzIHN0cmljdGVyIGluIHRoZSBjYXNlIG9mIERIQ1B2NCB3aGVyZSBvbmx5 DQpvbmUgb3B0aW9uIGluc3RhbmNlIGlzIHBvc3NpYmxlIHdpdGggbWF4aW11bSBvZiAyNDUgb2N0 ZXRzIGZvcg0KZG9tYWlucyBhbmQgbmV0d29ya3MgbGlzdC4gSW4gdGhlIGNhc2Ugb2YgREhDUHY2 IHRoZSByZXN0cmljdGlvbg0KaXMgbm90IGFzIHN0cmljdC4NCnRvIHNvbWV0aGluZyBsaWtlOg0K VGhpcyBpcyBlc3BlY2lhbGx5IHRydWUgZm9yIERIQ1B2NCwgd2hlcmUgdGhlIG1heGltdW0gREhD UCBwYWNrZXQNCnNpemUgbWF5IGJlIGFzIGxvdyBhcyA1NzYgb2N0ZXRzLg0KDQotIE1hdHQNCg0K DQo= --_000_916CE6CF87173740BC8A2CE44309696203783B93008AM1MPN1037mg_ Content-Type: text/html; charset="utf-8" Content-ID: <2E5096A996CC344A83064DF60B1E1904@nokia.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+Ym9keSwg cCwgbGkgeyBmb250LWZhbWlseTogTm9raWFQdXJlVGV4dExpZ2h0OyB9PC9zdHlsZT4NCjwvaGVh ZD4NCjxib2R5Pg0KPGRpdiBpZD0iZmVuaXgtdXNlci1jb250ZW50Ij4NCjxwIHN0eWxlPSIgbWFy Z2luLXRvcDowcHg7IG1hcmdpbi1ib3R0b206MHB4OyBtYXJnaW4tbGVmdDowcHg7IG1hcmdpbi1y aWdodDowcHg7IC1xdC1ibG9jay1pbmRlbnQ6MDsgdGV4dC1pbmRlbnQ6MHB4OyI+DQo8c3BhbiBz dHlsZT0iIGZvbnQtZmFtaWx5OidOb2tpYVB1cmVUZXh0TGlnaHQnOyI+Tm8sIHdlIGRlY2lkZWQg YWdhaW5zdCBzdWJvcHRpb25zIGFuZCBjb25jYXRlbmF0aW9uIGFzIHdlbGwgLSB0byBqdXN0IGhh dmUgc2luZ2xlIG9wdGlvbiBhbmQgc3RyaWN0bHkgbGltaXQgdGhlIGxlbmdodCBvZiB0aGUgZG9t YWlucy1maWVsZC4gSWYgSSByZWNhbGwgY29ycmVjdGx5LCBpdCB3YXMgZHVlIERIQ1B2NCByZWxh eXMgaW4gc29tZSBjYXNlcyBsaW1pdGluZw0KIHRoZSBhdmFpbGFibGUgREhDUHY0IG1lc3NhZ2Ug c2l6ZS4uIFRoYXQncyB3aHkgdGhlIGxhdGVzdCB2ZXJzaW9uIGlzIGNoYW5nZWQgaW4gc28gbWFu eSBsb2NhdGlvbnMgcmVsYXRlZCB0byB0aGlzIGlzc3VlLjxicj4NCjwvc3Bhbj48L3A+DQo8cCBz dHlsZT0iIG1hcmdpbi10b3A6MHB4OyBtYXJnaW4tYm90dG9tOjBweDsgbWFyZ2luLWxlZnQ6MHB4 OyBtYXJnaW4tcmlnaHQ6MHB4OyAtcXQtYmxvY2staW5kZW50OjA7IHRleHQtaW5kZW50OjBweDsi Pg0KPHNwYW4gc3R5bGU9IiBmb250LWZhbWlseTonTm9raWFQdXJlVGV4dExpZ2h0JzsiPk9rIG9u IGFsaWdubWVudCBpc3N1ZS48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Ii1xdC1wYXJhZ3JhcGgtdHlw ZTplbXB0eTsgbWFyZ2luLXRvcDowcHg7IG1hcmdpbi1ib3R0b206MHB4OyBtYXJnaW4tbGVmdDow cHg7IG1hcmdpbi1yaWdodDowcHg7IC1xdC1ibG9jay1pbmRlbnQ6MDsgdGV4dC1pbmRlbnQ6MHB4 OyBmb250LWZhbWlseTonTm9raWFQdXJlVGV4dExpZ2h0JzsiPg0KPGJyPg0KPC9wPg0KPHAgc3R5 bGU9IiBtYXJnaW4tdG9wOjBweDsgbWFyZ2luLWJvdHRvbTowcHg7IG1hcmdpbi1sZWZ0OjBweDsg bWFyZ2luLXJpZ2h0OjBweDsgLXF0LWJsb2NrLWluZGVudDowOyB0ZXh0LWluZGVudDowcHg7Ij4N CjxzcGFuIHN0eWxlPSIgZm9udC1mYW1pbHk6J05va2lhUHVyZVRleHRMaWdodCc7Ij5Db3VsZCB3 ZSB0aGVuIHJlbW92ZSB0aGUgc2Vjb25kIGxlbmd0aCBmaWVsZCBhbmQgaGVuY2UgZ2FpbiBvbmUg YWRkaXRpb25hbCBieXRlIGZvciBkb21haW5zIHZhcmlhYmxlIGxlbmdodCBmaWVsZD88L3NwYW4+ PC9wPg0KPHAgc3R5bGU9IiBtYXJnaW4tdG9wOjBweDsgbWFyZ2luLWJvdHRvbTowcHg7IG1hcmdp bi1sZWZ0OjBweDsgbWFyZ2luLXJpZ2h0OjBweDsgLXF0LWJsb2NrLWluZGVudDowOyB0ZXh0LWlu ZGVudDowcHg7Ij4NCjxzcGFuIHN0eWxlPSIgZm9udC1mYW1pbHk6J05va2lhUHVyZVRleHRMaWdo dCc7Ij48YnI+DQotLSA8YnI+DQpTZW50IGZyb20gbXkgTm9raWEmbmJzcDtOOTwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxicj4NCjxkaXYgaWQ9ImZlbml4LXJlcGx5LWhlYWRlciI+DQo8cD5PbiAxOS4x MC4yMDExIDIzOjM4IGV4dCBNYXR0aGV3IFJ5YW4gd3JvdGU6PGJyPg0KPC9wPg0KPC9kaXY+DQo8 ZGl2IGlkPSJmZW5peC1xdW90ZWQtYm9keSI+PGJyPg0KT24gT2N0IDE5LCAyMDExLCBhdCAxMDo0 MyAsICZsdDt0ZWVtdS5zYXZvbGFpbmVuQG5va2lhLmNvbSZndDsgd3JvdGU6PGJyPg0KJmd0OyZn dDsgRnJvbTogZXh0IE1hdHRoZXcgUnlhbiBbbWFpbHRvOk1hdHQuUnlhbkBub21pbnVtLmNvbV08 YnI+DQomZ3Q7Jmd0OyBJIGJlbGlldmUgdGhlIG9jdGV0IHNob3VsZCBiZSBtb3ZlZCB0byBqdXN0 IGJlZm9yZSB0aGUgZG9tYWlucy1hbmQtPGJyPg0KJmd0OyZndDsgbmV0d29ya3MgZmllbGQuIFRo aXMgd2lsbCBub3Qgb25seSBtYWtlIGl0IGFidW5kYW50bHkgY2xlYXIgdGhhdCBpdCBvbmx5PGJy Pg0KJmd0OyBjb3ZlcnM8YnI+DQomZ3Q7Jmd0OyB0aGUgbGVuZ3RoIG9mIHRoYXQgZmllbGQsIGJ1 dCBhbHNvIG1ha2UgaXQgZWFzaWVyIHRvIHBhcnNlLjxicj4NCjxicj4NCiZndDsgVGhlIHByb2Js ZW0gd2l0aCB0aGlzIGlzIHRoYXQgaXQgd291bGQgdGFrZSBETlMgc2VydmVyIElQdjQgYWRkcmVz c2VzIG91dCBvZjxicj4NCiZndDsgdGhlIDMyLWJpdCBib3VuZGFyeSwgd2hpY2ggZG9lcyBub3Qg bG9vayB2ZXJ5IG5pY2UgYW5kIGNhbiBjYXVzZTxicj4NCiZndDsgaW1wbGVtZW50YXRpb24gaXNz dWVzIGFzIHdlbGwgKHRoZXJlIGFyZSBPU2VzL0NQVXMgd2hlcmUgMzIgYml0IHZhbHVlcyBtdXN0 PGJyPg0KJmd0OyBsb2NhdGUgYXQgMzJiaXQgYm91bmRhcmllcyBpbiBtZW1vcnksIG90aGVyd2lz ZSB0aGV5IGhhdmUgdG8gYmUgbW92ZWQvY29waWVkPGJyPg0KJmd0OyBwZXItYnl0ZSkuPGJyPg0K PGJyPg0KRXhjZXB0IHlvdSBhcmUgYWxyZWFkeSBzdWJqZWN0IHRvIHRoYXQgaXNzdWUsIHNpbmNl IHRoZXJlIGlzIG5vPGJyPg0KZ3VhcmFudGVlIHRoYXQgdGhlIHN0YXJ0IG9mIHRoZSBvcHRpb24g d2lsbCBiZSBhbGlnbmVkIG9uPGJyPg0KYW55IHBhcnRpY3VsYXIgMTYgb3IgMzIgYml0IGJvdW5k YXJ5LiBBbiBvcHRpb24gdGhhdCBhcHBlYXJzPGJyPg0KYmVmb3JlIHRoaXMgb3B0aW9uIG1heSBj YXVzZSBpdCB0byBiZSBub24tYWxpZ25lZC4gSW1wbGVtZW50YXRpb25zPGJyPg0Kb2YgREhDUCBj YW4ndCByZXF1aXJlIG9wdGlvbnMgb3IgdGhlaXIgY29udGVudHMgdG8gaGF2ZSBhIGdpdmVuPGJy Pg0KYWxpZ25tZW50Ljxicj4NCjxicj4NCiZndDsgPGJyPg0KJmd0OyZndDsgVGhlIG90aGVyIG9w dGlvbiB3b3VsZCBiZSB0byBsZWF2ZSB0aGUgcGF5bG9hZC1sZW5ndGggb2N0ZXQgd2hlcmUgaXQg aXM8YnI+DQomZ3Q7IGFuZDxicj4NCiZndDsmZ3Q7IHJlZGVmaW5lIGl0IHRvIGluY2x1ZGUgdGhl IEROUyBzZXJ2ZXIgSVAgYWRkcmVzc2VzLCBidXQgdGhlIHJlZHVjZXMgdGhlPGJyPg0KJmd0OyZn dDsgcG9zc2libGUgbnVtYmVyIGFuZCBsZW5ndGggb2YgZG9tYWlucyB0aGF0IGNhbiBiZSBpbmNs dWRlZC48YnI+DQomZ3Q7IDxicj4NCiZndDsgSSBsaWtlIHRoaXMgb25lIC0gdGhlIG9wdGlvbiBs ZW5ndGggaXMgYW55d2F5IGRpY3RhdGVkIGJ5IHRoZSAmcXVvdDtMZW4mcXVvdDsgZmllbGQnczxi cj4NCiZndDsgb25lIGJ5dGUgbGltaXRhdGlvbiwgcmlnaHQ/IFNvIHdlIGNhbiBhcyB3ZWxsIGRl ZmluZSB0aGlzICZxdW90O3BheWxvYWQgbGVuJnF1b3Q7IHRvPGJyPg0KJmd0OyBpbmNsdWRlIERO UyBzZXJ2ZXIgSVAgYWRkcmVzc2VzIGFuZCByZXNlcnZlZCYjNDM7cHJmLiBCdXQgaW4gdGhhdCBj YXNlIGl0IHdvdWxkPGJyPg0KJmd0OyBiZSBhbG1vc3QgdGhlIHNhbWUgYXMgJnF1b3Q7TGVuJnF1 b3Q7IGZpZWxkICgxIGJ5dGUgZGlmZmVyZW5jZSksIHNvIHdoYXQgZG8gd2UgbmVlZDxicj4NCiZn dDsgdGhlICZxdW90O3BheWxvYWQgbGVuJnF1b3Q7IGFnYWluPy0pPGJyPg0KPGJyPg0KT3B0aW9u IGNvbmNhdGVuYXRpb24gLSBzaW5jZSB5b3Ugd2FudCB0aGUgYWJpbGl0eSAodG8gbWF0Y2ggdGhl IERIQ1B2Njxicj4NCnZlcnNpb24pIG9mIGJlaW5nIGFibGUgdG8gc3BlY2lmeSBtdWx0aXBsZSBy ZWRpcmVjdGlvbnMsIGUuZy4sIGhhdmluZzxicj4NCmZvby5jb20gZ28gdG8gMS4xLjEuMS8xLjEu MS4yLCBhbmQgYmFyLmNvbSBnbyB0byAyLjIuMi4xLzIuMi4yLjIuPGJyPg0KPGJyPg0KQW5kIG5v dyBJIHJlYWxpemUgdGhhdCBhc3BlY3Qgd2FzIGxvc3Qgc29tZXdoZXJlIGFsb25nIHRoZSB3YXku IEZyb208YnI+DQphbiBlYXJsaWVyIG1haWwgaW4gdGhlIGRpc2N1c3Npb24gKG1vZGlmaWVkIHRv IGNvcnJlY3QgdGhlIHBvc2l0aW9uIG9mPGJyPg0KdGhlIHBheWxvYWQgbGVuZ3RoIG9jdGV0LCBh bmQgc3RlYWxpbmcgdmVyYmlhZ2UgZnJvbSBwcmlvciBSRkNzKSwgdGhlPGJyPg0KYWN0dWFsIG9w dGlvbiBmb3JtYXQgc2hvdWxkIGJlOjxicj4NCjxicj4NCjAgMSAyIDM8YnI+DQowIDEgMiAzIDQg NSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgPGJy Pg0KJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzs8YnI+DQp8IG9wdGlvbi1jb2RlIHwgb3B0aW9u LWxlbiB8IGRzc2QtbGlzdCAodmFyLiBsZW5ndGgpIC4uLjxicj4NCiYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7PGJyPg0KPGJyPg0Kb3B0aW9uLWNvZGU6IChUQkQpPGJyPg0KPGJyPg0Kb3B0aW9u LWxlbjogTGVuZ3RoIG9mIHRoZSBvcHRpb24gaW4gb2N0ZXRzPGJyPg0KPGJyPg0KZHNzZC1saXN0 OiBPbmUgb3IgbW9yZSBpbnN0YW5jZXMgb2YgRE5TIFNlcnZlciBTZWxlY3Rpb24gRGF0YSw8YnI+ DQpkZWZpbmVkIGJlbG93Ljxicj4NCjxicj4NCkVhY2ggaW5zdGFuY2Ugb2YgRE5TIFNlcnZlciBT ZWxlY3Rpb24gRGF0YSBpcyBmb3JtYXR0ZWQgYXMgZm9sbG93czo8YnI+DQo8YnI+DQowIDEgMiAz PGJyPg0KMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1 IDYgNyA4IDkgMCAxIDxicj4NCiYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7PGJyPg0KfCBSZXNl cnZlZCB8cHJmfCBQcmltYXJ5IEROUyAoSVB2NCBhZGRyZXNzKSB8PGJyPg0KJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0Mzs8YnI+DQp8IFByaSBETlMgY29udC4gfCBTZWNvbmRhcnkgRE5TIChJUHY0 IGFkZHJlc3MpIHw8YnI+DQomIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOzxicj4NCnwgU2VjIERO UyBjb250LiB8IFBheWxvYWQgbGVuIHwgfDxicj4NCiYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7IHw8YnI+DQp8IHw8YnI+DQp8IERvbWFpbnMgYW5kIG5ldHdvcmtz IHw8YnI+DQp8ICh2YXJpYWJsZSBsZW5ndGgpIHw8YnI+DQp8IHw8YnI+DQomIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOzxicj4NCjxicj4NCjxicj4NCjxicj4NClRoZSBmb2xsb3dpbmcgcGFyYWdy YXBoIGluIHNlY3Rpb24gNC4zIHNob3VsZCBiZSByZW1vdmVkOjxicj4NClRoZSBPUFRJT05fRE5T X1NFUlZFUl9TRUxFQ1QgY29udGFpbnMgb25lIG9yIG1vcmUgZG9tYWlucyB0aGUgcmVsYXRlZDxi cj4NCnByaW1hcnkgYW5kIHNlY29uZGFyeSBETlMgc2VydmVycyBoYXZlIHBhcnRpY3VsYXIga25v d2xlZGdlIG9mLiBUaGU8YnI+DQpvcHRpb24gY2FuIG9jY3VyIG9ubHkgb25jZSBpbiBhIHNpbmds ZSBESENQdjQgbWVzc2FnZSBhbmQgaXMgbGltaXRlZDxicj4NCmluIGxlbmd0aC4gVGhlIG1heGlt dW0gbGVuZ3RoIGluIG9jdGV0cyBmb3IgdGhlIGRvbWFpbnMgYW5kIG5ldHdvcmtzPGJyPg0KZmll bGQgaXMgMjQ1IG9jdGV0cy48YnI+DQo8YnI+DQphbmQgcmVwbGFjZWQgd2l0aDo8YnI+DQpUaGUg REhDUHY0IGxvbmctb3B0aW9ucyBtZWNoYW5pc20gZGVzY3JpYmVkIGluIFtSRkMgMzM5Nl0gTVVT VCBiZTxicj4NCnVzZWQgaWYgdGhlIG9wdGlvbiBleGNlZWRzIHRoZSBtYXhpbXVtIERIQ1B2NCBv cHRpb24gc2l6ZSBvZiAyNTU8YnI+DQpvY3RldHMuPGJyPg0KPGJyPg0KVGhlIGJpdCBhYm91dCBE TlMgc2VydmVycyBoYXZpbmcga25vd2xlZGdlIGFib3V0IHJlbGF0ZWQgZG9tYWluczxicj4NCmlz IGFscmVhZHkgY292ZXJlZCBpbiB0aGUgZGVzY3JpcHRpb24gb2YgdGhlICZxdW90O0RvbWFpbnMg YW5kIG5ldHdvcmtzJnF1b3Q7PGJyPg0KZmllbGQuPGJyPg0KPGJyPg0KQW5kIGZpbmFsbHksIGlu IFNlY3Rpb24gNiwgeW91IHNob3VsZCBjaGFuZ2U6PGJyPg0KVGhlIHNpemUgbGltaXRhdGlvbiBp cyBzdHJpY3RlciBpbiB0aGUgY2FzZSBvZiBESENQdjQgd2hlcmUgb25seTxicj4NCm9uZSBvcHRp b24gaW5zdGFuY2UgaXMgcG9zc2libGUgd2l0aCBtYXhpbXVtIG9mIDI0NSBvY3RldHMgZm9yPGJy Pg0KZG9tYWlucyBhbmQgbmV0d29ya3MgbGlzdC4gSW4gdGhlIGNhc2Ugb2YgREhDUHY2IHRoZSBy ZXN0cmljdGlvbjxicj4NCmlzIG5vdCBhcyBzdHJpY3QuPGJyPg0KdG8gc29tZXRoaW5nIGxpa2U6 PGJyPg0KVGhpcyBpcyBlc3BlY2lhbGx5IHRydWUgZm9yIERIQ1B2NCwgd2hlcmUgdGhlIG1heGlt dW0gREhDUCBwYWNrZXQ8YnI+DQpzaXplIG1heSBiZSBhcyBsb3cgYXMgNTc2IG9jdGV0cy48YnI+ DQo8YnI+DQotIE1hdHQ8YnI+DQo8YnI+DQo8L2Rpdj4NCjxicj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_916CE6CF87173740BC8A2CE44309696203783B93008AM1MPN1037mg_-- From Matt.Ryan@nominum.com Wed Oct 19 15:45:41 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52DAF21F8319 for ; Wed, 19 Oct 2011 15:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, 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 jcRLXbVNXioG for ; Wed, 19 Oct 2011 15:45:40 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id 3412D21F8A6C for ; Wed, 19 Oct 2011 15:45:37 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP; Wed, 19 Oct 2011 15:45:40 PDT Received: from vir.ddns.nominum.com (vir.ddns.nominum.com [64.89.225.15]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by shell-too.nominum.com (Postfix) with ESMTP id AEF331B830F; Wed, 19 Oct 2011 15:45:33 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Matthew Ryan In-Reply-To: <916CE6CF87173740BC8A2CE44309696203783B93@008-AM1MPN1-037.mgdnok.nokia.com> Date: Wed, 19 Oct 2011 15:45:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <119E4891-D349-43DA-9ADE-03A22CC2050D@nominum.com> References: <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> <4A52F3C9-137D-4EC7-B100-B130422D273C@nominum.com> <916CE6CF87173740BC8A2CE44309696203783610@008-AM1MPN1-037.mgdnok.nokia.com> <916CE6CF87173740BC8A2CE44309696203783B93@008-AM1MPN1-037.mgdnok.nokia.com> To: X-Mailer: Apple Mail (2.1084) Cc: dhcwg@ietf.org Subject: Re: [dhcwg] [mif] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 22:45:41 -0000 On Oct 19, 2011, at 14:03 , = wrote: > No, we decided against suboptions and concatenation as well - to just = have single option and strictly limit the lenght of the domains-field. = If I recall correctly, it was due DHCPv4 relays in some cases limiting = the available DHCPv4 message size.. That's why the latest version is = changed in so many locations related to this issue. > Ok on alignment issue. >=20 > Could we then remove the second length field and hence gain one = additional byte for domains variable lenght field? That seems strange to me, since the DHPCv6 version is able to specify multiple redirections. It's beyond the scope of DHCP, so I can only assume that the other WG(s) decided the feature wasn't necessary for IPv4 networks, but is still necessary for IPv6 networks. If that is indeed the case, then yes, you can just remove the payload length octet from section 4.3 in draft -06. - Matt= From marka@isc.org Wed Oct 19 17:06:25 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@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 17:38:17 -0700 Cc: dhcwg@ietf.org, dnsop@ietf.org, mif@ietf.org, Keith Moore , dnsext@ietf.org Subject: Re: [dhcwg] [dnsext] [mif] bare names (was: 2nd Last Call for MIF DNS server selection document) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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 liu.guoyan@zte.com.cn Wed Oct 19 22:59:32 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C436021F8AF7 for ; Wed, 19 Oct 2011 22:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.79 X-Spam-Level: X-Spam-Status: No, score=-92.79 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, 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 A3kLWRafYRw9 for ; Wed, 19 Oct 2011 22:59:32 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 1522C21F8AF2 for ; Wed, 19 Oct 2011 22:59:30 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 46621262235339; Thu, 20 Oct 2011 13:52:44 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 20387.4008274977; Thu, 20 Oct 2011 13:59:16 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p9K5xDMK022427; Thu, 20 Oct 2011 13:59:13 +0800 (GMT-8) (envelope-from liu.guoyan@zte.com.cn) In-Reply-To: <3A3A5770-9064-4AD9-9AB5-9D96C5899D3E@nominum.com> To: Ted Lemon MIME-Version: 1.0 X-KeepSent: 8E4AD49A:90C8E495-4825792F:001591A1; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: liu.guoyan@zte.com.cn Date: Thu, 20 Oct 2011 13:58:58 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-10-20 13:59:14, Serialize complete at 2011-10-20 13:59:14 Content-Type: multipart/alternative; boundary="=_alternative 0020E31C4825792F_=" X-MAIL: mse01.zte.com.cn p9K5xDMK022427 Cc: dhcwg@ietf.org Subject: [dhcwg] =?gb2312?b?tPC4tDogUmU6IFtESENdIEEgcmVxdWVzdCB0byBwcmVz?= =?gb2312?b?ZW50IHR3byBkcmFmdHMgaW4gREhDLCBJRVRGODI=?= X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 05:59:32 -0000 This is a multipart message in MIME format. --=_alternative 0020E31C4825792F_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 RGVhciBUZWQ6DQoNCkZpcnN0bHksIHRoYW5rcyBmb3IgeW91ciByZXBseS4gDQoNCkkgcmVxdWVz dCBhIHNsb3QgKGFib3V0IDMwbWluKSB0byBwcmVzZW50IHRoZSBkcmFmdHMuIA0KDQpGb3IgeW91 ciByZWZlcmVuY2UsIHRoZSBkcmFmdCAwMC12ZXJzaW9uIGNhbiBiZSByZXZpZXdlZCBpbiANCmh0 dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1saXUtZGhjLTNncHAtb3B0aW9uLTAwLnR4dCBh bmQgDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtbGl1LWRoYy1oby0wMC50eHQNCg0K UGxlYXNlIGNvbnNpZGVyIG15IHJlcXVlc3QuDQoNCkluIGFkZGl0aW9uYWxseSwgcGxlYXNlIGZl ZWwgZnJlZSBmb3IgY29tbWVudHMuDQoNClRoYW5rcyENCg0KDQoNClRlZCBMZW1vbiA8VGVkLkxl bW9uQG5vbWludW0uY29tPiANCjIwMTEtMTAtMjAgMDA6MTANCg0KytW8/sjLDQoiPGxpdS5ndW95 YW5AenRlLmNvbS5jbj4gIiA8bGl1Lmd1b3lhbkB6dGUuY29tLmNuPg0Ks63LzQ0KSm9obiBKYXNv biBCcnpvem93c2tpIDxqb2huX2Jyem96b3dza2lAY2FibGUuY29tY2FzdC5jb20+DQrW98ziDQpS ZTogW0RIQ10gQSByZXF1ZXN0IHRvIHByZXNlbnQgdHdvIGRyYWZ0cyBpbiBESEMsIElFVEY4Mg0K DQoNCg0KDQoNCg0KT24gT2N0IDE5LCAyMDExLCBhdCAzOjMxIEFNLCA8bGl1Lmd1b3lhbkB6dGUu Y29tLmNuPg0KIHdyb3RlOg0KSSBoYXZlIHByZXNlbnRlZCB0d28gZHJhZnRzIHdoaWNoIGFyZSBy ZWxhdGVkIHRvIGRoY3AgcHJvdG9jb2wgYXBwbGllZCBpbiANCjNHUFAgbmV0d29yayBzY2VuYXJp byBkdXJpbmcgdGhlIG1lZXRpbmcuIEFuZCBJIHdhbnQgdG8ga25vdyB3aGVuIEkgY2FuIA0KcmVx dWVzdCBzbG90cyBmb3IgdGhlIGRyYWZ0cywgcGxlYXNlLiANCg0KWW91IGFyZSB3ZWxjb21lIHRv IHByZXNlbnQsIGhvd2V2ZXIgSSBzdHJvbmdseSBlbmNvdXJhZ2UgeW91IHRvIGJlZ2luIA0KZGlz Y3Vzc2lvbiBvbiB0aGUgbWFpbGluZyBsaXN0IG5vdyBzbyB0aGF0IHBlb3BsZSBrbm93IHdoYXQg eW91IGFyZSBnb2luZyANCnRvIHByZXNlbnQgYW5kIHdoZXRoZXIgdG8gcHJlcGFyZS4NCg0KQWxz bywgcGxlYXNlIHRlbGwgdXMgd2hpY2ggZHJhZnRzIGFuZCB3aG8gdGhlIGF1dGhvcnMgYXJlLiAg IFRoYW5rcyENCg0KKEJUVywgdGhpcyBlbmNvdXJhZ2VtZW50IGdvZXMgZm9yIG90aGVyIHByZXNl bnRlcnMgYXMgd2VsbC4pDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNl OiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVy dHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24g aXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8g bWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNv bnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBh bnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRl ZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20g dGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVy cm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3 cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBz ZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3Bh bSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 0020E31C4825792F_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+RGVhciBUZWQ6PC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPkZpcnN0bHks IHRoYW5rcyBmb3IgeW91ciByZXBseS4NCjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTMg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5JIHJlcXVlc3QgYSBzbG90IChhYm91dCAzMG1pbikNCnRv IHByZXNlbnQgdGhlIGRyYWZ0cy4gPGJyPg0KPGJyPg0KRm9yIHlvdXIgcmVmZXJlbmNlLCB0aGUg ZHJhZnQgMDAtdmVyc2lvbiBjYW4gYmUgcmV2aWV3ZWQgaW4gJm5ic3A7aHR0cDovL3Rvb2xzLmll dGYub3JnL2lkL2RyYWZ0LWxpdS1kaGMtM2dwcC1vcHRpb24tMDAudHh0DQphbmQgJm5ic3A7IGh0 dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1saXUtZGhjLWhvLTAwLnR4dDwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5QbGVhc2UgY29uc2lk ZXIgbXkgcmVxdWVzdC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+SW4gYWRkaXRpb25hbGx5LCBwbGVhc2UgZmVlbCBmcmVlDQpmb3IgY29tbWVu dHMuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PlRoYW5rcyE8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0 ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM1JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+PGI+VGVkIExlbW9uICZsdDtUZWQuTGVtb25Abm9taW51bS5jb20mZ3Q7PC9iPg0KPC9mb250 Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTEtMTAtMjAgMDA6MTA8L2Zv bnQ+DQo8dGQgd2lkdGg9NjQlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4N Cjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrV vP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1 b3Q7Jmx0O2xpdS5ndW95YW5AenRlLmNvbS5jbiZndDsNCiZxdW90OyAmbHQ7bGl1Lmd1b3lhbkB6 dGUuY29tLmNuJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1y aWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0 ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+Sm9obiBKYXNvbiBCcnpvem93c2tpICZs dDtqb2huX2Jyem96b3dza2lAY2FibGUuY29tY2FzdC5jb20mZ3Q7PC9mb250Pg0KPHRyIHZhbGln bj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij5SZTogW0RIQ10gQSByZXF1ZXN0IHRvIHByZXNlbnQgdHdvIGRyYWZ0cw0KaW4gREhDLCBJRVRG ODI8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0K PHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTM+ T24gT2N0IDE5LCAyMDExLCBhdCAzOjMxIEFNLCAmbHQ7PC9mb250PjxhIGhyZWY9bWFpbHRvOmxp dS5ndW95YW5AenRlLmNvbS5jbj48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48dT5saXUuZ3VveWFu QHp0ZS5jb20uY248L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTM+Jmd0OzwvZm9udD4NCjxicj48 Zm9udCBzaXplPTM+Jm5ic3A7d3JvdGU6PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iPkkgaGF2ZSBwcmVzZW50ZWQgdHdvIGRyYWZ0cyB3aGljaA0KYXJlIHJl bGF0ZWQgdG8gZGhjcCBwcm90b2NvbCBhcHBsaWVkIGluIDNHUFAgbmV0d29yayBzY2VuYXJpbyBk dXJpbmcgdGhlDQptZWV0aW5nLiBBbmQgSSB3YW50IHRvIGtub3cgd2hlbiBJIGNhbiByZXF1ZXN0 IHNsb3RzIGZvciB0aGUgZHJhZnRzLCBwbGVhc2UuPC9mb250Pjxmb250IHNpemU9Mz4NCjwvZm9u dD4NCjxicj4NCjxicj48Zm9udCBzaXplPTM+WW91IGFyZSB3ZWxjb21lIHRvIHByZXNlbnQsIGhv d2V2ZXIgSSBzdHJvbmdseSBlbmNvdXJhZ2UNCnlvdSB0byBiZWdpbiBkaXNjdXNzaW9uIG9uIHRo ZSBtYWlsaW5nIGxpc3Qgbm93IHNvIHRoYXQgcGVvcGxlIGtub3cgd2hhdA0KeW91IGFyZSBnb2lu ZyB0byBwcmVzZW50IGFuZCB3aGV0aGVyIHRvIHByZXBhcmUuPC9mb250Pg0KPGJyPg0KPGJyPjxm b250IHNpemU9Mz5BbHNvLCBwbGVhc2UgdGVsbCB1cyB3aGljaCBkcmFmdHMgYW5kIHdobyB0aGUg YXV0aG9ycw0KYXJlLiAmbmJzcDsgVGhhbmtzITwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXpl PTM+KEJUVywgdGhpcyBlbmNvdXJhZ2VtZW50IGdvZXMgZm9yIG90aGVyIHByZXNlbnRlcnMgYXMN CndlbGwuKTwvZm9udD4NCjxicj4NCjxicj4NCjxicj48cHJlPg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9ybWF0 aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24m bmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtz b2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtv cmdhbml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7 aXMmbmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJv dmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7c2Vj cmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5i c3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNw O2NvbW11bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4NClRoaXMmbmJzcDtlbWFpbCZuYnNw O2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7 aXQmbmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZuYnNw O3NvbGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7 aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhl eSZuYnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJz cDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtw bGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0 aGUmbmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7 aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJz cDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJz cDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDth bmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0u DQo8L3ByZT4= --=_alternative 0020E31C4825792F_=-- From teemu.savolainen@nokia.com Thu Oct 20 00:01:37 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@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, dhcwg@ietf.org, denghui02@hotmail.com Subject: Re: [dhcwg] [dnsext] [mif] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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 brian.e.carpenter@gmail.com Thu Oct 20 14:50:25 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@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, Ray.Bellis@nominet.org.uk, pk@isoc.de, dhcwg@ietf.org, denghui02@hotmail.com Subject: Re: [dhcwg] [mif] [dnsext] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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 drc@virtualized.org Thu Oct 20 18:19:44 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@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) Cc: mif@ietf.org, dnsop@ietf.org, dnsext@ietf.org, pk@isoc.de, dhcwg@ietf.org, denghui02@hotmail.com, Brian E Carpenter Subject: Re: [dhcwg] [dnsext] [mif] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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 teemu.savolainen@nokia.com Fri Oct 21 00:15:16 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@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, Ray.Bellis@nominet.org.uk, pk@isoc.de, dhcwg@ietf.org, denghui02@hotmail.com Subject: Re: [dhcwg] [mif] [dnsext] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@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: [dhcwg] [dnsext] [mif] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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 moore@network-heretics.com Thu Oct 20 18:08:11 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@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) X-Mailman-Approved-At: Fri, 21 Oct 2011 04:35:10 -0700 Cc: mif@ietf.org, dnsop@ietf.org, dnsext@ietf.org, pk@isoc.de, dhcwg@ietf.org, denghui02@hotmail.com Subject: Re: [dhcwg] [mif] [dnsext] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@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) X-Mailman-Approved-At: Fri, 21 Oct 2011 04:35:10 -0700 Cc: mif@ietf.org, dnsop@ietf.org, dnsext@ietf.org, pk@isoc.de, dhcwg@ietf.org, denghui02@hotmail.com, Brian E Carpenter Subject: Re: [dhcwg] [dnsext] [mif] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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 marka@isc.org Thu Oct 20 18:50:13 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@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:35:10 -0700 Cc: mif@ietf.org, Keith Moore , dnsop@ietf.org, dnsext@ietf.org, pk@isoc.de, dhcwg@ietf.org, denghui02@hotmail.com, Brian E Carpenter Subject: Re: [dhcwg] [dnsext] [mif] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@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:35:10 -0700 Cc: mif@ietf.org, dnsop@ietf.org, David Conrad , dnsext@ietf.org, pk@isoc.de, dhcwg@ietf.org, denghui02@hotmail.com, Brian E Carpenter Subject: Re: [dhcwg] [dnsext] [mif] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@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:35:10 -0700 Cc: mif@ietf.org, dnsop@ietf.org, dnsext@ietf.org, pk@isoc.de, dhcwg@ietf.org, denghui02@hotmail.com, brian.e.carpenter@gmail.com Subject: Re: [dhcwg] [dnsext] [mif] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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 Ray.Bellis@nominet.org.uk Fri Oct 21 00:46:42 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@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 X-Mailman-Approved-At: Fri, 21 Oct 2011 04:35:10 -0700 Cc: "" , "" , "" , "" , "" Subject: Re: [dhcwg] [mif] [dnsext] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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 marka@isc.org Fri Oct 21 04:30:25 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@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 04:35:10 -0700 Cc: mif@ietf.org, Keith Moore , dnsop@ietf.org, dnsext@ietf.org, David Conrad , pk@isoc.de, dhcwg@ietf.org, denghui02@hotmail.com, Brian E Carpenter Subject: Re: [dhcwg] [DNSOP] [dnsext] [mif] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@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 07:15:43 -0700 Cc: mif@ietf.org, brian.peter.dickson@gmail.com, dnsop@ietf.org, dnsext@ietf.org, pk@isoc.de, dhcwg@ietf.org, denghui02@hotmail.com, brian.e.carpenter@gmail.com Subject: Re: [dhcwg] [dnsext] [mif] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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 moore@network-heretics.com Fri Oct 21 07:10:48 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@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) X-Mailman-Approved-At: Fri, 21 Oct 2011 07:15:43 -0700 Cc: mif@ietf.org, dnsop@ietf.org, dnsext@ietf.org, pk@isoc.de, dhcwg@ietf.org, denghui02@hotmail.com, brian.e.carpenter@gmail.com Subject: Re: [dhcwg] [mif] [dnsext] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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 Ted.Lemon@nominum.com Fri Oct 21 07:46:40 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A242121F8BEE for ; Fri, 21 Oct 2011 07:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.519 X-Spam-Level: X-Spam-Status: No, score=-106.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 ATDEoTGBPOp2 for ; Fri, 21 Oct 2011 07:46:39 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id 2920D21F8BDE for ; Fri, 21 Oct 2011 07:46:38 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP; Fri, 21 Oct 2011 07:46: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 AAEE81B8275 for ; Fri, 21 Oct 2011 07:46:21 -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 9C254190065 for ; Fri, 21 Oct 2011 07:46:21 -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 07:46:21 -0700 From: Ted Lemon To: DHC WG Thread-Topic: Call for adoption: draft-cui-dhc-dhcpv4-over-ipv6 Thread-Index: AQHMkAAyxrNjwGADf0ePBGnmjz0jGQ== Date: Fri, 21 Oct 2011 14:46:20 +0000 Message-ID: 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="us-ascii" Content-ID: <7925E8E67F9F1E42A92B2CAB32F4532C@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dhcwg] Call for adoption: draft-cui-dhc-dhcpv4-over-ipv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 14:46:40 -0000 This was discussed in the meeting in QC and the sense of the room was that = there was interest in the working group. Please review the document brief= ly and indicate whether you agree that it should be adopted or oppose its a= doption. FYI the basic idea is to provide a mechanism for relaying DHCP across a v6 = network for the purpose of supporting v4 nodes on a v6 network during the t= ransition period. We will determine consensus on November 4, 2011. From Ted.Lemon@nominum.com Fri Oct 21 08:07:52 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@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:12:53 -0700 Cc: "" , "" , "" , "" , "" , "" , "" , "" , "" Subject: Re: [dhcwg] [DNSOP] [dnsext] [mif] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@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:12:53 -0700 Cc: "" , "" , "" , "" , "" , "" , "" , "" Subject: Re: [dhcwg] [DNSOP] [dnsext] [mif] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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 Ted.Lemon@nominum.com Fri Oct 21 08:19:09 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@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: [dhcwg] [DNSOP] [dnsext] [mif] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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:13:57 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@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:33:35 -0700 Cc: "" , "" , "" , "" , "" , "" , "" , "" Subject: Re: [dhcwg] [DNSOP] [dnsext] [mif] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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 moore@network-heretics.com Fri Oct 21 08:23:29 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@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 08:33:35 -0700 Cc: "" , "" , "" , "" , "" , "" , "" , "" Subject: Re: [dhcwg] [DNSOP] [dnsext] [mif] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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 Fri Oct 21 08:31:40 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@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) X-Mailman-Approved-At: Fri, 21 Oct 2011 08:33:35 -0700 Cc: DHC WG , "dnsop@ietf.org WG" , "" , dnsext List Subject: Re: [dhcwg] [DNSOP] [dnsext] [mif] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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 teemu.savolainen@nokia.com Fri Oct 21 11:54:32 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@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: [dhcwg] [mif] [dnsext] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@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, Ray.Bellis@nominet.org.uk, pk@isoc.de, dhcwg@ietf.org, denghui02@hotmail.com Subject: Re: [dhcwg] [mif] [dnsext] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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 Ted.Lemon@nominum.com Sat Oct 22 12:42:03 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@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: [dhcwg] [DNSOP] [dnsext] [mif] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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 tomasz.mrugalski@gmail.com Sun Oct 23 03:54:39 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EDF721F8A6F for ; Sun, 23 Oct 2011 03:54:39 -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 MrBtaX6wmP9v for ; Sun, 23 Oct 2011 03:54:38 -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 7E18521F8A67 for ; Sun, 23 Oct 2011 03:54:38 -0700 (PDT) Received: by eyg24 with SMTP id 24so5228258eyg.31 for ; Sun, 23 Oct 2011 03:54:37 -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 :content-type:content-transfer-encoding; bh=95bXo3et56Yh6/D8yejdtPXC71yI8YgxE8uMBBYPPew=; b=HC+Ui7hNwDI0s2UBHXsBq4hKQwc/KO3aths2M34Ij5uhiTl2MSIiF5KVzuHh/Gi3Ff 5GKsRAcmm0pk9cALWAGn9TguXkg5e9A7f+YEWRC5IQygTd/Xk7Z2zeWU1feZd69eL858 MATL7DT38S/mm2ppoqrdMDXbON0jjQBX/ViHs= Received: by 10.213.20.5 with SMTP id d5mr2562189ebb.116.1319367276296; Sun, 23 Oct 2011 03:54:36 -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 49sm50591109eec.1.2011.10.23.03.54.34 (version=SSLv3 cipher=OTHER); Sun, 23 Oct 2011 03:54:35 -0700 (PDT) Message-ID: <4EA3F26B.9020405@gmail.com> Date: Sun, 23 Oct 2011 12:54:35 +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: dhcwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [dhcwg] Requesting suboptions in DHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2011 10:54:39 -0000 Dear group, Draft mrugalski-dhc-dhcpv6-suboptions-01 [1] was presented in Quebec meeting. It clarifies how should clients requests suboptions. There is no text in RFC3315 that explains that. During last meeting we had a brief discussion regarding the way suboptions are requested. There are two reasonable approaches possible: APPROACH 1. use a single ORO instance, put it in message directly as it is done today. This is simple to implement and does not require modification of existing drafts. Server will need to be smart enough to know which requested options are top-level options, which are sub-options and where to put them. You can't differentiate between different instances of the same option. APPROACH 2. use top-level ORO as it is done today, but also use ORO instance in each scope you want to request suboptions. Require a bit more logic, but is more flexible. Client can specify that it wants specific suboption in only one instance of an option. Bernie provided [5] an excellent example for this approach while discussing PD_EXCLUDE option: "Another reason for placing this into an IA_PD ORO option is what if there are multiple IA_PDs and the requesting router is only interested in supporting this in some cases. Consider the case where the requesting router has already obtained an IA_PD (w/PD_EXCLUDE) and now needs another because there are more prefixes needed. In this case, this request would NOT want to include the PD_EXCLUDE for these additional IA_PD(s) because they would NOT be used on the WAN interface? So, I think having this be at the IA_PD level is the correct way to go." Currently the draft describes approach 2, but please do not consider this as a suggestion that this approach is "preferred" in any way. If we decide that approach 1 is the way to go, I'll update the draft as needed. Chairs suggested that a consensus should be reached about this, before it could be adopted. It would be great if we could reach consensus on this before Taipei (Nov. 13). Personally, I don't have any strong opinion about this. Both approaches are ok for me. I don't want to push one way or the other, I just want to have clear recommendation, how to request suboptions. I just uploaded updated version [2]. There are no significant changes, just minor update to avoid expiration. Your comments are more than welcome. Brief statement about supporting approach 1 or 2 is fine, too. Here's my attempt to summarize the discussion so far. I'm sorry if I missed any comments. Please correct me if I did. This had some discussion, but it was somewhat scattered around different places. Soe far, following people states their opinions: Aproach 1 (single ORO): - Jouni Korhonen [6] (also stated during meeting. Prefers 1, but is willing to accept 2 if it does not require modifications of existing drafts) - Ted Lemon (discussion during Quebec, prefers 1 as it requires smaller modifications in existing implementations (i.e. easier to deploy). Aproach 2 (ORO put in proper scope): Bernie Volz [3,5] (See Bernie's comment above about requesting PD_EXCLUDE in only first IA_PD) Ole Troan [4] 1. draft-mrugalski-dhc-dhcpv6-suboptions-01.txt 2. draft-mrugalski-dhc-dhcpv6-suboptions-02.txt 3. http://www.ietf.org/mail-archive/web/dhcwg/current/msg11846.html 4. http://www.ietf.org/mail-archive/web/dhcwg/current/msg11663.html 5. http://www.ietf.org/mail-archive/web/dhcwg/current/msg11846.html 6. http://www.ietf.org/mail-archive/web/dhcwg/current/msg11827.html Thanks, Tomek From dougb@dougbarton.us Sat Oct 22 11:49:43 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B20521F8485 for ; Sat, 22 Oct 2011 11:49:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=-0.090, 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 PLJWdZPcZEEI for ; Sat, 22 Oct 2011 11:49:43 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id ECD6921F847F for ; Sat, 22 Oct 2011 11:49:42 -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: Sun, 23 Oct 2011 05:36:03 -0700 Cc: "" , "" , "" , "" , Ted Lemon , "" , "" , "" Subject: Re: [dhcwg] [dnsext] [DNSOP] [mif] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2011 18:49:43 -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 moore@network-heretics.com Sat Oct 22 12:21:31 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@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) X-Mailman-Approved-At: Sun, 23 Oct 2011 05:36:03 -0700 Cc: "" , "" , "" , "" , Ted Lemon , "" , "" , "" Subject: Re: [dhcwg] [dnsext] [DNSOP] [mif] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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 matt@conundrum.com Sat Oct 22 23:41:20 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@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 05:36:03 -0700 Cc: "" , "" , Doug Barton , "" , "" , Ted Lemon , "" , "" , "" Subject: Re: [dhcwg] [dnsext] [DNSOP] [mif] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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 gvithal@gmail.com Sun Oct 23 11:19:15 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA1DD21F8B40 for ; Sun, 23 Oct 2011 11:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[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 ah-H2r7Zc4DR for ; Sun, 23 Oct 2011 11:19:14 -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 8CDFA21F8B3D for ; Sun, 23 Oct 2011 11:19:14 -0700 (PDT) Received: by eyg24 with SMTP id 24so5372112eyg.31 for ; Sun, 23 Oct 2011 11:19:13 -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=0Azfi+9YB9FQYE6inxQD+CZ6FqxSMgBLCKRn8eRm6/w=; b=FpDEiRYDktBX94GV0WxRDp9lKiOokxoYRUBFycrA4VS2ZDFVNnhTzZ9+NnpODZU1it Opd/6dzIU53FUPP+dqrEGNybB8FzklwHItz6sk4DYMe/xKZye5080LDUkklPnUDs90AH 4LxFbcsZKPdAcPxO3c/nMFMyMorOOK5HCRQe0= MIME-Version: 1.0 Received: by 10.213.27.204 with SMTP id j12mr468910ebc.141.1319393953694; Sun, 23 Oct 2011 11:19:13 -0700 (PDT) Received: by 10.213.10.211 with HTTP; Sun, 23 Oct 2011 11:19:13 -0700 (PDT) Date: Sun, 23 Oct 2011 23:49:13 +0530 Message-ID: From: VithalPrasad Gaitonde To: dhcwg@ietf.org Content-Type: multipart/alternative; boundary=000e0cd1e324edc29e04affb57bc Subject: [dhcwg] Character Encoding of DNS domain option (option 15) RFC 2132 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2011 18:19:15 -0000 --000e0cd1e324edc29e04affb57bc Content-Type: text/plain; charset=ISO-8859-1 Hi, What is the character format to be used for encoding of DNS domain in option 15. Should this be UTF8 or UTF16 or Unicode. More generically, what is the character format to be used for any option value which is of string data type. RFC 2132 seems to be silent on this aspect. Is this documented in any other standards document. Thanks, Prasad --000e0cd1e324edc29e04affb57bc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
=A0
What is the character format to be used fo= r encoding of DNS domain in option 15.
Should this be UTF8 or UTF= 16 or Unicode.
=A0
More generically, what is the charac= ter format to be used for any option value which is of string data type.
RFC 2132 seems to be silent on this aspect. Is this documented in any = other standards document.
=A0
Thanks,
Prasad<= /div> --000e0cd1e324edc29e04affb57bc-- From Ted.Lemon@nominum.com Sun Oct 23 12:16:58 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@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 , Brian E Carpenter Subject: Re: [dhcwg] [dnsext] [DNSOP] [mif] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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 Ted.Lemon@nominum.com Sun Oct 23 12:21:37 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 990F421F8AFB for ; Sun, 23 Oct 2011 12:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.547 X-Spam-Level: X-Spam-Status: No, score=-106.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 odshJkn2p8-D for ; Sun, 23 Oct 2011 12:21:37 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id D8A5821F86F6 for ; Sun, 23 Oct 2011 12:21:36 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP; Sun, 23 Oct 2011 12:21:36 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 EF82D1B80DD for ; Sun, 23 Oct 2011 12:21:35 -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 DDDF5190061; Sun, 23 Oct 2011 12:21:35 -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:21:35 -0700 From: Ted Lemon To: Tomasz Mrugalski Thread-Topic: [dhcwg] Requesting suboptions in DHCPv6 Thread-Index: AQHMkXIt/JyO7Plg2UyQYltCfkcNCJWKxGoA Date: Sun, 23 Oct 2011 19:21:35 +0000 Message-ID: References: <4EA3F26B.9020405@gmail.com> In-Reply-To: <4EA3F26B.9020405@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: text/plain; charset="us-ascii" Content-ID: <0165F0FC7CA5BC4E83050958112D2F1A@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] Requesting suboptions in DHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2011 19:21:37 -0000 My reason for preferring option 1 is actually that in general I expect that= the server *knows* in which context a suboption should appear. So if you= put an ORO requesting a suboption into a particular context, you will only= actually get that suboption if the server *knows* that it should go there.= We don't have any spec for how the server *knows* that suboptions should= go here or there. So if we go with option 2, we wind up with a standard = that I don't think can be implemented in a way that will interoperate depen= dably. By going with option 1, we leave the decision up to the server, as is the s= tatus quo, and in general we can expect the right thing to happen. If we = were to go with option 2, I agree with you that drafts would need to be upd= ated, but I think you are underestimating the amount of work that would be = required. Given the rate at which people respond to the business of this = working group on the mailing list, I think it's implausible that such an ef= fort could occur. From Ted.Lemon@nominum.com Sun Oct 23 12:27:47 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD9721F8A71 for ; Sun, 23 Oct 2011 12:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.552 X-Spam-Level: X-Spam-Status: No, score=-106.552 tagged_above=-999 required=5 tests=[AWL=0.046, 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 yNWxaUWDf6BZ for ; Sun, 23 Oct 2011 12:27:46 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id 36EBA21F8888 for ; Sun, 23 Oct 2011 12:27:46 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP; Sun, 23 Oct 2011 12:27:46 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 226B11B80DD for ; Sun, 23 Oct 2011 12:27:45 -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 0F37F190061; Sun, 23 Oct 2011 12:27:45 -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:27:45 -0700 From: Ted Lemon To: VithalPrasad Gaitonde Thread-Topic: [dhcwg] Character Encoding of DNS domain option (option 15) RFC 2132 Thread-Index: AQHMkbBJ0yF2c9y9AE+FE7uiAo4bo5WKxaaA Date: Sun, 23 Oct 2011 19:27:44 +0000 Message-ID: <2B0A1E24-4309-4B1E-874B-E7161C212911@nominum.com> References: In-Reply-To: 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_2B0A1E2443094B1E874BE7161C212911nominumcom_" MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] Character Encoding of DNS domain option (option 15) RFC 2132 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2011 19:27:47 -0000 --_000_2B0A1E2443094B1E874BE7161C212911nominumcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Oct 23, 2011, at 2:19 PM, VithalPrasad Gaitonde wrote: What is the character format to be used for encoding of DNS domain in optio= n 15. Should this be UTF8 or UTF16 or Unicode. I would expect it to be whatever is specified in RFC1034, which appears to = assume plain old ASCII. You could try whatever the IDN documents specify;= the standard is silent on the question, so what works in any given circums= tance will depend on the implementation. More generically, what is the character format to be used for any option va= lue which is of string data type. RFC 2132 seems to be silent on this aspect. Is this documented in any other= standards document. This is because of the age of the drafts: the question of I18N was relative= ly new then. Again, in general, expect this to be implementation-dependen= t. UTF-8 will probably work in cases where it makes sense, but you can't = safely assume that it will. If you are specifying a new option, I would s= uggest specifying UTF-8. --_000_2B0A1E2443094B1E874BE7161C212911nominumcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
On Oct 23, 2011, at 2:19 PM, VithalPrasad Gaitonde wrote:
What is the character format to be used for encoding of DNS domain in = option 15.
Should this be UTF8 or UTF16 or Unicode.

I would expect it to be whatever is specified in RFC1034, which appears to = assume plain old ASCII.   You could try whatever the IDN documents spe= cify; the standard is silent on the question, so what works in any given ci= rcumstance will depend on the implementation.

More generically, what is the character format to= be used for any option value which is of string data type. 
RFC 2132 seems to be silent on this aspect. Is this documented in any = other standards document.

This is because of the age of the drafts: the question of I18N was rel= atively new then.   Again, in general, expect this to be implementatio= n-dependent.   UTF-8 will probably work in cases where it makes sense,= but you can't safely assume that it will.   If you are specifying a new option, I would suggest specifying UTF-= 8.


--_000_2B0A1E2443094B1E874BE7161C212911nominumcom_-- From marc.blanchet@viagenie.ca Sun Oct 23 12:30:18 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBB9821F8B22 for ; Sun, 23 Oct 2011 12:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 I9iAJM-XPsww for ; Sun, 23 Oct 2011 12:30:18 -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 27F5321F8B26 for ; Sun, 23 Oct 2011 12:30:15 -0700 (PDT) Received: from [IPv6:2607:fa48:6e6b:c280:425:ab35:8457:60aa] (unknown [IPv6:2607:fa48:6e6b:c280:425:ab35:8457:60aa]) by jazz.viagenie.ca (Postfix) with ESMTPSA id DBEBF20D2A; Sun, 23 Oct 2011 15:30:14 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Marc Blanchet In-Reply-To: <2B0A1E24-4309-4B1E-874B-E7161C212911@nominum.com> Date: Sun, 23 Oct 2011 15:30:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <38D1A504-9144-4C88-A188-B02BE4F492F0@viagenie.ca> References: <2B0A1E24-4309-4B1E-874B-E7161C212911@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1251.1) Cc: "" Subject: Re: [dhcwg] Character Encoding of DNS domain option (option 15) RFC 2132 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2011 19:30:19 -0000 don't agree about UTF-8. idns are encoded on the wire as normal domain = names, i.e. restricted ascii.=20 Marc. Le 2011-10-23 =E0 15:27, Ted Lemon a =E9crit : > On Oct 23, 2011, at 2:19 PM, VithalPrasad Gaitonde wrote: >> What is the character format to be used for encoding of DNS domain in = option 15. >> Should this be UTF8 or UTF16 or Unicode. >=20 > I would expect it to be whatever is specified in RFC1034, which = appears to assume plain old ASCII. You could try whatever the IDN = documents specify; the standard is silent on the question, so what works = in any given circumstance will depend on the implementation. >=20 >> More generically, what is the character format to be used for any = option value which is of string data type.=20 >> RFC 2132 seems to be silent on this aspect. Is this documented in any = other standards document. >=20 > This is because of the age of the drafts: the question of I18N was = relatively new then. Again, in general, expect this to be = implementation-dependent. UTF-8 will probably work in cases where it = makes sense, but you can't safely assume that it will. If you are = specifying a new option, I would suggest specifying UTF-8. >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From Ted.Lemon@nominum.com Sun Oct 23 12:36:21 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFF1021F8A35 for ; Sun, 23 Oct 2011 12:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.554 X-Spam-Level: X-Spam-Status: No, score=-106.554 tagged_above=-999 required=5 tests=[AWL=0.044, 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 zujk3xOL2waD for ; Sun, 23 Oct 2011 12:36:21 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 2586B21F87D9 for ; Sun, 23 Oct 2011 12:36:21 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP; Sun, 23 Oct 2011 12:36:21 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 37FA21B80DD for ; Sun, 23 Oct 2011 12:36:20 -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 24817190061; Sun, 23 Oct 2011 12:36:20 -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, 23 Oct 2011 12:36:20 -0700 From: Ted Lemon To: Marc Blanchet Thread-Topic: [dhcwg] Character Encoding of DNS domain option (option 15) RFC 2132 Thread-Index: AQHMkbBJ0yF2c9y9AE+FE7uiAo4bo5WKxaaAgAAAsICAAAG3gA== Date: Sun, 23 Oct 2011 19:36:20 +0000 Message-ID: <1DB05243-3779-409A-86FE-F15133BC0C12@nominum.com> References: <2B0A1E24-4309-4B1E-874B-E7161C212911@nominum.com> <38D1A504-9144-4C88-A188-B02BE4F492F0@viagenie.ca> In-Reply-To: <38D1A504-9144-4C88-A188-B02BE4F492F0@viagenie.ca> 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_1DB052433779409A86FEF15133BC0C12nominumcom_" MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] Character Encoding of DNS domain option (option 15) RFC 2132 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2011 19:36:22 -0000 --_000_1DB052433779409A86FEF15133BC0C12nominumcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Oct 23, 2011, at 3:30 PM, Marc Blanchet wrote: don't agree about UTF-8. idns are encoded on the wire as normal domain name= s, i.e. restricted ascii. Clearly you didn't read what I said in the first paragraph. :) As you s= ay, for DNS you can't use UTF-8. --_000_1DB052433779409A86FEF15133BC0C12nominumcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
On Oct 23, 2011, at 3:30 PM, Marc Blanchet wrote:
don't agree about UTF-8. idns are encoded on the wire as normal domain names, i.= e. restricted ascii. 

Clearly you didn't read what I said in the first paragraph.   :) =   As you say, for DNS you can't use UTF-8.

--_000_1DB052433779409A86FEF15133BC0C12nominumcom_-- From marc.blanchet@viagenie.ca Sun Oct 23 12:49:38 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 601EC21F8AC9 for ; Sun, 23 Oct 2011 12:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 CHi2bQTE-pdL for ; Sun, 23 Oct 2011 12:49:38 -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 022B821F8AAA for ; Sun, 23 Oct 2011 12:49:38 -0700 (PDT) Received: from [IPv6:2607:fa48:6e6b:c280:425:ab35:8457:60aa] (unknown [IPv6:2607:fa48:6e6b:c280:425:ab35:8457:60aa]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 72C8920D2A; Sun, 23 Oct 2011 15:49:37 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Marc Blanchet In-Reply-To: <1DB05243-3779-409A-86FE-F15133BC0C12@nominum.com> Date: Sun, 23 Oct 2011 15:49:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2B0A1E24-4309-4B1E-874B-E7161C212911@nominum.com> <38D1A504-9144-4C88-A188-B02BE4F492F0@viagenie.ca> <1DB05243-3779-409A-86FE-F15133BC0C12@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1251.1) Cc: "" Subject: Re: [dhcwg] Character Encoding of DNS domain option (option 15) RFC 2132 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2011 19:49:38 -0000 I read it, but maybe I misunderstood. Anyway, back to the original = question, my point is that the character encoding of DNS domain option = in dhcp must be restricted ascii (and that includes the support of idn). Marc. Le 2011-10-23 =E0 15:36, Ted Lemon a =E9crit : > On Oct 23, 2011, at 3:30 PM, Marc Blanchet wrote: >> don't agree about UTF-8. idns are encoded on the wire as normal = domain names, i.e. restricted ascii.=20 >=20 > Clearly you didn't read what I said in the first paragraph. :) As = you say, for DNS you can't use UTF-8. >=20 From marka@isc.org Sun Oct 23 16:49:46 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@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 16:54:25 -0700 Cc: "" , Keith Moore , "" , "" , "" , Ted Lemon , "" , "" , "" Subject: Re: [dhcwg] [DNSOP] [dnsext] [mif] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@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:20:53 -0700 Cc: "" , "" , Doug Barton , "" , "" , Ted Lemon , "" , "" , "" Subject: Re: [dhcwg] [dnsext] [DNSOP] [mif] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@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:20:50 -0700 Cc: "" , Keith Moore , Matthew Pounsett , "" , "" , "" , Ted Lemon , "" , "" , "" Subject: Re: [dhcwg] [DNSOP] [dnsext] [mif] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@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: [dhcwg] [DNSOP] [dnsext] [mif] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD38411E8090 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 CLGpm2rb0u26 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 32DDD11E8088 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: Mon, 24 Oct 2011 04:05:16 -0700 Cc: mif@ietf.org, matt@conundrum.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 Subject: Re: [dhcwg] [DNSOP] [dnsext] [mif] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@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 04:05:16 -0700 Cc: mif@ietf.org, matt@conundrum.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 Subject: Re: [dhcwg] [DNSOP] [dnsext] [mif] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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 akostur@incognito.com Mon Oct 24 08:20:24 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62C8321F8E8D for ; Mon, 24 Oct 2011 08:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_IMAGE_ONLY_32=1.778, 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 yXrQWwBuHAzO for ; Mon, 24 Oct 2011 08:20:23 -0700 (PDT) Received: from na3sys010aog101.obsmtp.com (na3sys010aog101.obsmtp.com [74.125.245.70]) by ietfa.amsl.com (Postfix) with SMTP id 6357721F8E8F for ; Mon, 24 Oct 2011 08:20:19 -0700 (PDT) Received: from mail-qy0-f174.google.com ([209.85.216.174]) (using TLSv1) by na3sys010aob101.postini.com ([74.125.244.12]) with SMTP; Mon, 24 Oct 2011 08:20:19 PDT Received: by mail-qy0-f174.google.com with SMTP id 4so2323631qyk.19 for ; Mon, 24 Oct 2011 08:20:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.67.66 with SMTP id q2mr1971363qci.118.1319469611922; Mon, 24 Oct 2011 08:20:11 -0700 (PDT) Received: by 10.229.101.201 with HTTP; Mon, 24 Oct 2011 08:20:11 -0700 (PDT) In-Reply-To: References: <4EA3F26B.9020405@gmail.com> Date: Mon, 24 Oct 2011 08:20:11 -0700 Message-ID: From: Andre Kostur To: Ted Lemon Content-Type: multipart/alternative; boundary=0016363b7c1282b39704b00cf5e8 Cc: "" Subject: Re: [dhcwg] Requesting suboptions in DHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 15:20:24 -0000 --0016363b7c1282b39704b00cf5e8 Content-Type: text/plain; charset=ISO-8859-1 Not sure if this is a good example or not, but the PacketCable/CableLabs guys already do stuff like option 2. They have an ORO that's encoded into their vendor-specific data which names other sub-options of the vendor-specific data. See CL-SP-CANN-DHCP-Reg-I07-110623 ( http://www.cablelabs.com/specifications/CL-SP-CANN-DHCP-Reg-I07-110623.pdf) section 5.2.1. On Sun, Oct 23, 2011 at 12:21, Ted Lemon wrote: > My reason for preferring option 1 is actually that in general I expect that > the server *knows* in which context a suboption should appear. So if you > put an ORO requesting a suboption into a particular context, you will only > actually get that suboption if the server *knows* that it should go there. > We don't have any spec for how the server *knows* that suboptions should go > here or there. So if we go with option 2, we wind up with a standard that > I don't think can be implemented in a way that will interoperate dependably. > > By going with option 1, we leave the decision up to the server, as is the > status quo, and in general we can expect the right thing to happen. If we > were to go with option 2, I agree with you that drafts would need to be > updated, but I think you are underestimating the amount of work that would > be required. Given the rate at which people respond to the business of > this working group on the mailing list, I think it's implausible that such > an effort could occur. > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > -- *Andre Kostur* Senior Product Design Engineer *P:* 604-678-2864 *E:* akostur@incognito.com *Toll-Free:* 1-800-877-1856 *F:* 604-678-2864 *VoIP:* sip:864@sip.incognito.com [image: Incognito Software Inc.] --0016363b7c1282b39704b00cf5e8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Not sure if this is a good example or not, but the PacketC= able/CableLabs guys already do stuff like option 2. =A0They have an ORO tha= t's encoded into their vendor-specific data which names other sub-optio= ns of the vendor-specific data. =A0See CL-SP-CANN-DHCP-Reg-I07-110623 (http://www.cablelabs.com/specifications/CL-SP-CANN-DHCP-Reg-I07-110= 623.pdf) section 5.2.1.


On Sun, Oct 23, 2011 at 12:21, Ted = Lemon <Ted.Le= mon@nominum.com> wrote:
My reason for preferring option 1 is actually that in general I expect that= the server *knows* in which context a suboption should appear. =A0 So if y= ou put an ORO requesting a suboption into a particular context, you will on= ly actually get that suboption if the server *knows* that it should go ther= e. =A0 We don't have any spec for how the server *knows* that suboption= s should go here or there. =A0 So if we go with option 2, we wind up with a= standard that I don't think can be implemented in a way that will inte= roperate dependably.

By going with option 1, we leave the decision up to the server, as is the s= tatus quo, and in general we can expect the right thing to happen. =A0 If w= e were to go with option 2, I agree with you that drafts would need to be u= pdated, but I think you are underestimating the amount of work that would b= e required. =A0 Given the rate at which people respond to the business of t= his working group on the mailing list, I think it's implausible that su= ch an effort could occur.

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dhcwg



--
=
Andre= Kostur
Senior Product Design Engineer
P: 604-678-2864
E: akostur@incognito.= com
Toll-Free: 1-800-877-1856

F:= 604-678-2864
VoIP: sip:864@sip.incognito.com

3D"Incognito


--0016363b7c1282b39704b00cf5e8-- From alex@alex.org.uk Mon Oct 24 04:19:26 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@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 08:43:10 -0700 Cc: mif@ietf.org, matt@conundrum.com, dnsop@ietf.org, dnsext@ietf.org, pk@isoc.de, Ted.Lemon@nominum.com, Alex Bligh , dhcwg@ietf.org, denghui02@hotmail.com, brian.e.carpenter@gmail.com Subject: Re: [dhcwg] [DNSOP] [dnsext] [mif] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Alex Bligh List-Id: 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: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@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 08:43:10 -0700 Cc: DHC WG , "dnsop@ietf.org WG" , "" , dnsext List , Alex Bligh Subject: Re: [dhcwg] [dnsext] [DNSOP] [mif] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Alex Bligh List-Id: 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: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@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 08:43:10 -0700 Cc: mif@ietf.org, matt@conundrum.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 Subject: Re: [dhcwg] [DNSOP] [dnsext] [mif] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@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 08:43:10 -0700 Cc: mif@ietf.org, matt@conundrum.com, dnsop@ietf.org, dnsext@ietf.org, pk@isoc.de, Ted.Lemon@nominum.com, Alex Bligh , dhcwg@ietf.org, denghui02@hotmail.com, brian.e.carpenter@gmail.com Subject: Re: [dhcwg] [DNSOP] [dnsext] [mif] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Alex Bligh List-Id: 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: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@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 08:43:10 -0700 Cc: mif@ietf.org, matt@conundrum.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 Subject: Re: [dhcwg] [DNSOP] [dnsext] [mif] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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 internet-drafts@ietf.org Mon Oct 24 09:50:32 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C70BF21F8D43; Mon, 24 Oct 2011 09:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 0Kqphnk2XAuZ; Mon, 24 Oct 2011 09:50:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44E4721F8D31; Mon, 24 Oct 2011 09:50:31 -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: <20111024165031.21695.5842.idtracker@ietfa.amsl.com> Date: Mon, 24 Oct 2011 09:50:31 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-failover-requirements-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 16:50:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Gr= oup of the IETF. Title : DHCPv6 Failover Requirements Author(s) : Tomasz Mrugalski Kim Kinnear Filename : draft-ietf-dhc-dhcpv6-failover-requirements-00.txt Pages : 19 Date : 2011-10-18 The DHCPv6 protocol, defined in [RFC3315] allows for multiple servers to operate on a single network, however it does not define any way to decide which server responds to which client queries. Some sites are interested in running multiple servers in such a way as to provide increased availability in case of server failure. In order for this to work reliably, the cooperating primary and secondary servers must maintain a consistent database of the lease information. [RFC3315] allows for but does not define any redundancy or failover mechanisms. This document outlines requirements for DHCPv6 failover, enumerates related problems, and discusses the proposed scope of work to be conducted. This document does not define a DHCPv6 failover protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-failover-requirem= ents-00.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-dhc-dhcpv6-failover-requireme= nts-00.txt From mayer@gis.net Mon Oct 24 10:19:07 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@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 10:29:58 -0700 Cc: "" , Keith Moore , Matthew Pounsett , "" , "" , "" , Ted Lemon , "" , "" , "" Subject: Re: [dhcwg] [DNSOP] [dnsext] [mif] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mayer@gis.net List-Id: 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 dougb@dougbarton.us Mon Oct 24 13:52:44 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0714B11E80B5 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.173 X-Spam-Level: X-Spam-Status: No, score=-3.173 tagged_above=-999 required=5 tests=[AWL=0.426, 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 73tQ4AdIrzyP 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 F373621F8C3E 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 X-Mailman-Approved-At: Mon, 24 Oct 2011 14:27:13 -0700 Cc: mif@ietf.org, dnsop@ietf.org, dnsext@ietf.org, pk@isoc.de, Alex Bligh , dhcwg@ietf.org Subject: Re: [dhcwg] [dnsext] [DNSOP] [mif] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@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) X-Mailman-Approved-At: Mon, 24 Oct 2011 14:27:13 -0700 Cc: mif@ietf.org, dnsop@ietf.org, dnsext@ietf.org, pk@isoc.de, Alex Bligh , dhcwg@ietf.org Subject: Re: [dhcwg] [dnsext] [DNSOP] [mif] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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 jhutz@cmu.edu Mon Oct 24 15:50:47 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@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 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: [dhcwg] [dnsext] [DNSOP] [mif] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@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 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: [dhcwg] [dnsext] [DNSOP] [mif] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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 moore@network-heretics.com Mon Oct 24 16:30:13 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@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) X-Mailman-Approved-At: Tue, 25 Oct 2011 09:38:40 -0700 Cc: mif@ietf.org, dnsop@ietf.org, Doug Barton , dnsext@ietf.org, pk@isoc.de, Alex Bligh , dhcwg@ietf.org Subject: Re: [dhcwg] [dnsext] [DNSOP] [mif] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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 jhutz@cmu.edu Mon Oct 24 17:31:39 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@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: Tue, 25 Oct 2011 09:38:40 -0700 Cc: "" , Keith Moore , "" , "" , "" , Ted Lemon , "" , "" , "" , jhutz@cmu.edu Subject: Re: [dhcwg] [dnsext] [DNSOP] [mif] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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 dougb@dougbarton.us Mon Oct 24 14:36:22 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C755F11E815C 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 C8Xnu6qolWv3 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 5467011E8115 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 X-Mailman-Approved-At: Tue, 25 Oct 2011 09:38:59 -0700 Cc: mif@ietf.org, dnsop@ietf.org, dnsext@ietf.org, pk@isoc.de, Alex Bligh , dhcwg@ietf.org Subject: Re: [dhcwg] [dnsext] [DNSOP] [mif] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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 Ted.Lemon@nominum.com Tue Oct 25 10:20:41 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@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: [dhcwg] [dnsext] [DNSOP] [mif] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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 Ted.Lemon@nominum.com Tue Oct 25 10:36:06 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 350C221F8880 for ; Tue, 25 Oct 2011 10:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.558 X-Spam-Level: X-Spam-Status: No, score=-106.558 tagged_above=-999 required=5 tests=[AWL=0.040, 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 mnxGxrXVDl-5 for ; Tue, 25 Oct 2011 10:36:05 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id 2344321F85F7 for ; Tue, 25 Oct 2011 10:36:05 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP; Tue, 25 Oct 2011 10:36:05 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 30A2E1B8217 for ; Tue, 25 Oct 2011 10:36:04 -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 2A62F190061; Tue, 25 Oct 2011 10:36:04 -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:36:04 -0700 From: Ted Lemon To: Andre Kostur Thread-Topic: [dhcwg] Requesting suboptions in DHCPv6 Thread-Index: AQHMkXIt/JyO7Plg2UyQYltCfkcNCJWKxGoAgAFO4YCAAULzrg== Date: Tue, 25 Oct 2011 17:36:03 +0000 Message-ID: <111C7AAB-F621-42BF-AF1B-B9B0A204F257@nominum.com> References: <4EA3F26B.9020405@gmail.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_111C7AABF62142BFAF1BB9B0A204F257nominumcom_" MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] Requesting suboptions in DHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 17:36:06 -0000 --_000_111C7AABF62142BFAF1BB9B0A204F257nominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Oct 24, 2011, at 11:20 AM, "Andre Kostur" > wrote: Not sure if this is a good example or not, but the PacketCable/CableLabs gu= ys already do stuff like option 2. They have an ORO that's encoded into th= eir vendor-specific data which names other sub-options of the vendor-specif= ic data. See CL-SP-CANN-DHCP-Reg-I07-110623 (http://www.cablelabs.com/spec= ifications/CL-SP-CANN-DHCP-Reg-I07-110623.pdf) section 5.2.1. That's quite bit different because it's a vendor specific sub option list. --_000_111C7AABF62142BFAF1BB9B0A204F257nominumcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
On Oct 24, 2011, at 11:20 AM, "Andre Kostur" <akostur@incognito.com> wrote:

Not sure if this is a good example or not, but th= e PacketCable/CableLabs guys already do stuff like option 2.  They hav= e an ORO that's encoded into their vendor-specific data which names other s= ub-options of the vendor-specific data.  See CL-SP-CANN-DHCP-Reg-I07-110623 (http://www.cablelabs= .com/specifications/CL-SP-CANN-DHCP-Reg-I07-110623.pdf) section 5.2.1.<= /blockquote>
That's quite bit different because it's a vendor specific sub option l= ist. 
--_000_111C7AABF62142BFAF1BB9B0A204F257nominumcom_-- From dougb@dougbarton.us Tue Oct 25 11:33:36 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1265921F8C41 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.258 X-Spam-Level: X-Spam-Status: No, score=-3.258 tagged_above=-999 required=5 tests=[AWL=0.341, 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 UYcZsTqAry1H 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 0777321F8500 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: [dhcwg] [dnsext] [DNSOP] [mif] 2nd Last Call for MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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 teemu.savolainen@nokia.com Wed Oct 26 00:01:27 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@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: [dhcwg] New rev of MIF DNS server selection document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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 gvithal@gmail.com Thu Oct 27 10:01:36 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60F4921F8B00 for ; Thu, 27 Oct 2011 10:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[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 jLXXPcnvzSMX for ; Thu, 27 Oct 2011 10:01:35 -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 914EF21F84AA for ; Thu, 27 Oct 2011 10:01:35 -0700 (PDT) Received: by eyg24 with SMTP id 24so2895590eyg.31 for ; Thu, 27 Oct 2011 10:01:34 -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; bh=6GUIiDWD97A6eNNOIWkSLvma4PXhZAUaVVUEpQJ9R0E=; b=vmGQrbcqh8QYG9zLRp/7cv/I5FEAG2/KlqAeNvbn//RgXuayaNwPhN6ds3RUSNlE/2 FdTe81zMHApfn201B4ZD0UkfGdn9jcbk3pec24UF4zNgaagpGI6z3cNaz+sgV02U/SAX nEf6GOLMihiUnd9EGhXBo0woTcuy31fuOFSqI= MIME-Version: 1.0 Received: by 10.213.8.71 with SMTP id g7mr854545ebg.27.1319734894360; Thu, 27 Oct 2011 10:01:34 -0700 (PDT) Received: by 10.213.13.2 with HTTP; Thu, 27 Oct 2011 10:01:34 -0700 (PDT) In-Reply-To: References: <2B0A1E24-4309-4B1E-874B-E7161C212911@nominum.com> <38D1A504-9144-4C88-A188-B02BE4F492F0@viagenie.ca> <1DB05243-3779-409A-86FE-F15133BC0C12@nominum.com> Date: Thu, 27 Oct 2011 22:31:34 +0530 Message-ID: From: VithalPrasad Gaitonde To: Marc Blanchet Content-Type: multipart/alternative; boundary=0015174c18f2937a3904b04ab9ae Cc: "" , Ted Lemon Subject: Re: [dhcwg] Character Encoding of DNS domain option (option 15) RFC 2132 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 17:01:36 -0000 --0015174c18f2937a3904b04ab9ae Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am still a bit confused here... To ensure interoperability with standards compliant DHCP clients, what is the character encoding that the server should use...and the converse. Or are we saying that interoperability is broken here as the standard is silent on the issue leaving implementations to take a possibly different approach and thereby be non-interoperable. Thanks, Prasad On Mon, Oct 24, 2011 at 1:19 AM, Marc Blanchet w= rote: > I read it, but maybe I misunderstood. Anyway, back to the original > question, my point is that the character encoding of DNS domain option in > dhcp must be restricted ascii (and that includes the support of idn). > > Marc. > > Le 2011-10-23 =E0 15:36, Ted Lemon a =E9crit : > > > On Oct 23, 2011, at 3:30 PM, Marc Blanchet wrote: > >> don't agree about UTF-8. idns are encoded on the wire as normal domain > names, i.e. restricted ascii. > > > > Clearly you didn't read what I said in the first paragraph. :) As y= ou > say, for DNS you can't use UTF-8. > > > > --0015174c18f2937a3904b04ab9ae Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I am still a bit confused here...
To ensure interoperability= with standards compliant DHCP clients, what is the character encoding that= the server should use...and the converse.
=A0
Or are w= e saying that interoperability is broken here as the standard is silent on = the issue leaving implementations to take a possibly different approach and= thereby be non-interoperable.
=A0
Thanks,
Prasad

=A0
On Mon, Oct 24, 2011 at 1:19 AM, Marc Blanchet <marc.blanchet@via= genie.ca> wrote:
I read it, but maybe I misunderstood. Anyway, = back to the original question, my point is that the character encoding of D= NS domain option in dhcp must be restricted ascii (and that includes the su= pport of idn).

Marc.

Le 2011-10-23 =E0 15:36, Ted Lemon a =E9crit :

> On Oct 23, 2011, at 3:30 PM, Marc Blanchet wrote:
>> don't agree about UTF-8. idns are encoded on the wire as norma= l domain names, i.e. restricted ascii.
>
> Clearly you didn't read what I said in the first paragraph. =A0 :)= =A0 As you say, for DNS you can't use UTF-8.
>


--0015174c18f2937a3904b04ab9ae-- From Ted.Lemon@nominum.com Thu Oct 27 10:15:14 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A46F21F8B8B for ; Thu, 27 Oct 2011 10:15:14 -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 k8MqgkgsPsMz for ; Thu, 27 Oct 2011 10:15:13 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id B42F121F8B9C for ; Thu, 27 Oct 2011 10:15:12 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP; Thu, 27 Oct 2011 10:15:12 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 D86321B810E for ; Thu, 27 Oct 2011 10:15:01 -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 BEA26190052; Thu, 27 Oct 2011 10:15:01 -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 10:15:01 -0700 From: Ted Lemon To: VithalPrasad Gaitonde Thread-Topic: [dhcwg] Character Encoding of DNS domain option (option 15) RFC 2132 Thread-Index: AQHMkbBJ0yF2c9y9AE+FE7uiAo4bo5WKxaaAgAAAsICAAAG3gIAAA7QAgAYaYACAAAPBAA== Date: Thu, 27 Oct 2011 17:15:00 +0000 Message-ID: <506D6E6A-897C-4ADA-8C9B-0826E413E0DA@nominum.com> References: <2B0A1E24-4309-4B1E-874B-E7161C212911@nominum.com> <38D1A504-9144-4C88-A188-B02BE4F492F0@viagenie.ca> <1DB05243-3779-409A-86FE-F15133BC0C12@nominum.com> In-Reply-To: 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_506D6E6A897C4ADA8C9B0826E413E0DAnominumcom_" MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] Character Encoding of DNS domain option (option 15) RFC 2132 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 17:15:14 -0000 --_000_506D6E6A897C4ADA8C9B0826E413E0DAnominumcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Oct 27, 2011, at 1:01 PM, VithalPrasad Gaitonde wrote: Or are we saying that interoperability is broken here as the standard is si= lent on the issue leaving implementations to take a possibly different appr= oach and thereby be non-interoperable. RFC1533 generally says to use NVT ASCII. If you want to go outside of tha= t, you are indeed in uncharted waters, and interoperability is not guarante= ed. --_000_506D6E6A897C4ADA8C9B0826E413E0DAnominumcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <5026BA906A03A844A521EA05FC9F7942@nominum.com> Content-Transfer-Encoding: quoted-printable
On Oct 27, 2011, at 1:01 PM, VithalPrasad Gaitonde wrote:
Or are we saying that interoperability is broken here as the standard is sile= nt on the issue leaving implementations to take a possibly different approa= ch and thereby be non-interoperable.

RFC1533 generally says to use NVT ASCII.   If you want to go outs= ide of that, you are indeed in uncharted waters, and interoperability is no= t guaranteed.

--_000_506D6E6A897C4ADA8C9B0826E413E0DAnominumcom_-- From marc.blanchet@viagenie.ca Thu Oct 27 11:35:21 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF7DF21F8B78 for ; Thu, 27 Oct 2011 11:35:21 -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 rDM6cAlG67yj for ; Thu, 27 Oct 2011 11:35:21 -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 59A0A21F8B70 for ; Thu, 27 Oct 2011 11:35:21 -0700 (PDT) Received: from [172.20.10.2] (unknown [74.198.165.99]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 4A4C321B94; Thu, 27 Oct 2011 14:35:20 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Marc Blanchet In-Reply-To: Date: Thu, 27 Oct 2011 14:35:16 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <179BFEB1-ABB9-45A7-BF9C-CE2F8D4DA09D@viagenie.ca> References: <2B0A1E24-4309-4B1E-874B-E7161C212911@nominum.com> <38D1A504-9144-4C88-A188-B02BE4F492F0@viagenie.ca> <1DB05243-3779-409A-86FE-F15133BC0C12@nominum.com> To: VithalPrasad Gaitonde X-Mailer: Apple Mail (2.1251.1) Cc: "" , Ted Lemon Subject: Re: [dhcwg] Character Encoding of DNS domain option (option 15) RFC 2132 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 18:35:21 -0000 to me, you are just looking into big troubles if you use a character = encoding for DNS names in DHCP that is different than the standardized = character encoding for DNS names everywhere else. so I would stick to = restricted ascii. no utf8. nothing else. Marc. Le 2011-10-27 =E0 13:01, VithalPrasad Gaitonde a =E9crit : > I am still a bit confused here... > To ensure interoperability with standards compliant DHCP clients, what = is the character encoding that the server should use...and the converse. > =20 > Or are we saying that interoperability is broken here as the standard = is silent on the issue leaving implementations to take a possibly = different approach and thereby be non-interoperable. > =20 > Thanks, > Prasad >=20 > =20 > On Mon, Oct 24, 2011 at 1:19 AM, Marc Blanchet = wrote: > I read it, but maybe I misunderstood. Anyway, back to the original = question, my point is that the character encoding of DNS domain option = in dhcp must be restricted ascii (and that includes the support of idn). >=20 > Marc. >=20 > Le 2011-10-23 =E0 15:36, Ted Lemon a =E9crit : >=20 > > On Oct 23, 2011, at 3:30 PM, Marc Blanchet wrote: > >> don't agree about UTF-8. idns are encoded on the wire as normal = domain names, i.e. restricted ascii. > > > > Clearly you didn't read what I said in the first paragraph. :) = As you say, for DNS you can't use UTF-8. > > >=20 >=20 From ravikumar.lrk@gmail.com Thu Oct 27 20:17:36 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE48A1F0C42 for ; Thu, 27 Oct 2011 20:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[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 qEhh3pXyIXEj for ; Thu, 27 Oct 2011 20:17:36 -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 935671F0C52 for ; Thu, 27 Oct 2011 20:17:35 -0700 (PDT) Received: by bkbzu17 with SMTP id zu17so1649376bkb.31 for ; Thu, 27 Oct 2011 20:17:25 -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; bh=IZpads0OGjVjL16q8+lgyjSyL1HZJuBl2tPQRM0b3Jo=; b=c3aV/wGFXHli8/2djG07lJ5nRLQlbT6m1BF/1+0EpiSOBjXYmAC8BOPW02af7479FE vjOA43H7X4MUr/9DpQ963Xem5cynYvv6QyFi+X+evy5v5MidTwyH6HIA25ApHSTAto8E hfWzCetzqzVolDtFDVhg+/YXnU+IrCCgCXmIE= MIME-Version: 1.0 Received: by 10.204.10.81 with SMTP id o17mr540774bko.78.1319771845171; Thu, 27 Oct 2011 20:17:25 -0700 (PDT) Received: by 10.204.51.14 with HTTP; Thu, 27 Oct 2011 20:17:25 -0700 (PDT) In-Reply-To: <179BFEB1-ABB9-45A7-BF9C-CE2F8D4DA09D@viagenie.ca> References: <2B0A1E24-4309-4B1E-874B-E7161C212911@nominum.com> <38D1A504-9144-4C88-A188-B02BE4F492F0@viagenie.ca> <1DB05243-3779-409A-86FE-F15133BC0C12@nominum.com> <179BFEB1-ABB9-45A7-BF9C-CE2F8D4DA09D@viagenie.ca> Date: Fri, 28 Oct 2011 08:47:25 +0530 Message-ID: From: ravi kumar To: Marc Blanchet Content-Type: multipart/alternative; boundary=0015175cd794041b1704b053542e Cc: "" , Ted Lemon Subject: Re: [dhcwg] Character Encoding of DNS domain option (option 15) RFC 2132 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 03:17:36 -0000 --0015175cd794041b1704b053542e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Do ISC DHCP implementations conform to RFC1533 in rergard to character encondings? regards Ravi On Fri, Oct 28, 2011 at 12:05 AM, Marc Blanchet wrote: > to me, you are just looking into big troubles if you use a character > encoding for DNS names in DHCP that is different than the standardized > character encoding for DNS names everywhere else. so I would stick to > restricted ascii. no utf8. nothing else. > > Marc. > > Le 2011-10-27 =E0 13:01, VithalPrasad Gaitonde a =E9crit : > > > I am still a bit confused here... > > To ensure interoperability with standards compliant DHCP clients, what = is > the character encoding that the server should use...and the converse. > > > > Or are we saying that interoperability is broken here as the standard i= s > silent on the issue leaving implementations to take a possibly different > approach and thereby be non-interoperable. > > > > Thanks, > > Prasad > > > > > > On Mon, Oct 24, 2011 at 1:19 AM, Marc Blanchet < > marc.blanchet@viagenie.ca> wrote: > > I read it, but maybe I misunderstood. Anyway, back to the original > question, my point is that the character encoding of DNS domain option in > dhcp must be restricted ascii (and that includes the support of idn). > > > > Marc. > > > > Le 2011-10-23 =E0 15:36, Ted Lemon a =E9crit : > > > > > On Oct 23, 2011, at 3:30 PM, Marc Blanchet wrote: > > >> don't agree about UTF-8. idns are encoded on the wire as normal doma= in > names, i.e. restricted ascii. > > > > > > Clearly you didn't read what I said in the first paragraph. :) As > you say, for DNS you can't use UTF-8. > > > > > > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > --0015175cd794041b1704b053542e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Do ISC DHCP implementations conform to RFC1533 in rergard to character= encondings?
=A0
regards
Ravi
On Fri, Oct 28, 2011 at 12:05 AM, Marc Blanchet <marc.blanchet= @viagenie.ca> wrote:
to me, you are just looking into big troubles = if you use a character encoding for DNS names in DHCP that is different tha= n the standardized character encoding for DNS names everywhere else. so I w= ould stick to restricted ascii. no utf8. nothing else.

Marc.

Le 2011-10-27 =E0 13:01, VithalPrasad Gaitonde a =E9crit :

> I am still a bit confused here...
> To ensure interoperability with standards compliant DHCP clients, what= is the character encoding that the server should use...and the converse. >
> Or are we saying that interoperability is broken here as the standard = is silent on the issue leaving implementations to take a possibly different= approach and thereby be non-interoperable.
>
> Thanks,
> Prasad
>
>
> On Mon, Oct 24, 2011 at 1:19 AM, Marc Blanchet <marc.blanchet@viagenie.ca> wrote:
> I read it, but maybe I misunderstood. Anyway, back to the original que= stion, my point is that the character encoding of DNS domain option in dhcp= must be restricted ascii (and that includes the support of idn).
>
> Marc.
>
> Le 2011-10-23 =E0 15:36, Ted Lemon a =E9crit :
>
> > On Oct 23, 2011, at 3:30 PM, Marc Blanchet wrote:
> >> don't agree about UTF-8. idns are encoded on the wire as = normal domain names, i.e. restricted ascii.
> >
> > Clearly you didn't read what I said in the first paragraph. = =A0 :) =A0 As you say, for DNS you can't use UTF-8.
> >
>
>

_____________________________= __________________
dhcwg mailing list
dhcwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dhcwg

--0015175cd794041b1704b053542e-- From Ted.Lemon@nominum.com Thu Oct 27 22:08:30 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51E4511E8097 for ; Thu, 27 Oct 2011 22:08:30 -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.068, 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 bXRrgssMpnmn for ; Thu, 27 Oct 2011 22:08:29 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 5FBF911E807F for ; Thu, 27 Oct 2011 22:08:29 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP; Thu, 27 Oct 2011 22:08:29 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 9755C1B826D for ; Thu, 27 Oct 2011 22:08:11 -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 A7682190052; Thu, 27 Oct 2011 22:08:08 -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; Thu, 27 Oct 2011 22:08:08 -0700 From: Ted Lemon To: ravi kumar Thread-Topic: [dhcwg] Character Encoding of DNS domain option (option 15) RFC 2132 Thread-Index: AQHMkbBJ0yF2c9y9AE+FE7uiAo4bo5WKxaaAgAAAsICAAAG3gIAAA7QAgAYaYACAABouAIAAkeOA//+pltA= Date: Fri, 28 Oct 2011 05:08:08 +0000 Message-ID: References: <2B0A1E24-4309-4B1E-874B-E7161C212911@nominum.com> <38D1A504-9144-4C88-A188-B02BE4F492F0@viagenie.ca> <1DB05243-3779-409A-86FE-F15133BC0C12@nominum.com> <179BFEB1-ABB9-45A7-BF9C-CE2F8D4DA09D@viagenie.ca>, In-Reply-To: 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: [dhcwg] Character Encoding of DNS domain option (option 15) RFC 2132 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 05:08:30 -0000 On Oct 27, 2011, at 11:17 PM, "ravi kumar" wrote: > Do ISC DHCP implementations conform to RFC1533 in rergard to character en= condings? What would that mean?= From gvithal@gmail.com Fri Oct 28 01:22:46 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D52C721F8ACA for ; Fri, 28 Oct 2011 01:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[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 DAIflxNUdQM3 for ; Fri, 28 Oct 2011 01:22:46 -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 D7BAE21F8AC3 for ; Fri, 28 Oct 2011 01:22:45 -0700 (PDT) Received: by eyg24 with SMTP id 24so3600491eyg.31 for ; Fri, 28 Oct 2011 01:22:45 -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; bh=0WVQRc7Dm7WcyrDENRq2y9BtePj+KqXn9Pit+wtOe9I=; b=xWEW1RKUQss53sB4zZda9XuVyFz7WDpzdPpodEU0gx7cBiuqLRcziYK+9mCIucE/Xt iNRSqfBMNT2ewMsAHW78jVk3m19YgcvPTSN+wetZz77MMxKvtPvCeuWlz8UkrBk5We1r KNjDMSCFhU2VKBV1ox6GHRRJlw46RYwEYt0PQ= MIME-Version: 1.0 Received: by 10.213.27.204 with SMTP id j12mr119474ebc.141.1319790164995; Fri, 28 Oct 2011 01:22:44 -0700 (PDT) Received: by 10.213.13.2 with HTTP; Fri, 28 Oct 2011 01:22:44 -0700 (PDT) In-Reply-To: <179BFEB1-ABB9-45A7-BF9C-CE2F8D4DA09D@viagenie.ca> References: <2B0A1E24-4309-4B1E-874B-E7161C212911@nominum.com> <38D1A504-9144-4C88-A188-B02BE4F492F0@viagenie.ca> <1DB05243-3779-409A-86FE-F15133BC0C12@nominum.com> <179BFEB1-ABB9-45A7-BF9C-CE2F8D4DA09D@viagenie.ca> Date: Fri, 28 Oct 2011 13:52:44 +0530 Message-ID: From: VithalPrasad Gaitonde To: Marc Blanchet Content-Type: multipart/alternative; boundary=000e0cd1e324f6703704b05797b1 Cc: "" , Ted Lemon Subject: Re: [dhcwg] Character Encoding of DNS domain option (option 15) RFC 2132 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 08:22:46 -0000 --000e0cd1e324f6703704b05797b1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks for the responses, Marc, Ted. Does that imply then that in case internationalized domain names, punycode should be used ? Regards, Prasad On Fri, Oct 28, 2011 at 12:05 AM, Marc Blanchet wrote: > to me, you are just looking into big troubles if you use a character > encoding for DNS names in DHCP that is different than the standardized > character encoding for DNS names everywhere else. so I would stick to > restricted ascii. no utf8. nothing else. > > Marc. > > Le 2011-10-27 =E0 13:01, VithalPrasad Gaitonde a =E9crit : > > > I am still a bit confused here... > > To ensure interoperability with standards compliant DHCP clients, what = is > the character encoding that the server should use...and the converse. > > > > Or are we saying that interoperability is broken here as the standard i= s > silent on the issue leaving implementations to take a possibly different > approach and thereby be non-interoperable. > > > > Thanks, > > Prasad > > > > > > On Mon, Oct 24, 2011 at 1:19 AM, Marc Blanchet < > marc.blanchet@viagenie.ca> wrote: > > I read it, but maybe I misunderstood. Anyway, back to the original > question, my point is that the character encoding of DNS domain option in > dhcp must be restricted ascii (and that includes the support of idn). > > > > Marc. > > > > Le 2011-10-23 =E0 15:36, Ted Lemon a =E9crit : > > > > > On Oct 23, 2011, at 3:30 PM, Marc Blanchet wrote: > > >> don't agree about UTF-8. idns are encoded on the wire as normal doma= in > names, i.e. restricted ascii. > > > > > > Clearly you didn't read what I said in the first paragraph. :) As > you say, for DNS you can't use UTF-8. > > > > > > > > > --000e0cd1e324f6703704b05797b1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks for the responses, Marc, Ted.
=A0
Does that= imply then that in case internationalized domain names, punycode should be= used ?
=A0
Regards,
Prasad

On Fri, Oct 28, 2011 at 12:05 AM, Marc Blanchet <marc.blanchet@viagenie.ca> wrote:
to me, you are just looking into big troubles if you use a character encodi= ng for DNS names in DHCP that is different than the standardized character = encoding for DNS names everywhere else. so I would stick to restricted asci= i. no utf8. nothing else.

Marc.

Le 2011-10-27 =E0 13:01, VithalPrasad Gaitonde a =E9crit :

> I am still a bit confused here...
> To ensure interoperability with standards compliant DHCP clients, what= is the character encoding that the server should use...and the converse. >
> Or are we saying that interoperability is broken here as the standard = is silent on the issue leaving implementations to take a possibly different= approach and thereby be non-interoperable.
>
> Thanks,
> Prasad
>
>
> On Mon, Oct 24, 2011 at 1:19 AM, Marc Blanchet <marc.blanchet@viagenie.ca> wrote:
> I read it, but maybe I misunderstood. Anyway, back to the original que= stion, my point is that the character encoding of DNS domain option in dhcp= must be restricted ascii (and that includes the support of idn).
>
> Marc.
>
> Le 2011-10-23 =E0 15:36, Ted Lemon a =E9crit :
>
> > On Oct 23, 2011, at 3:30 PM, Marc Blanchet wrote:
> >> don't agree about UTF-8. idns are encoded on the wire as = normal domain names, i.e. restricted ascii.
> >
> > Clearly you didn't read what I said in the first paragraph. = =A0 :) =A0 As you say, for DNS you can't use UTF-8.
> >
>
>


--000e0cd1e324f6703704b05797b1-- From marc.blanchet@viagenie.ca Fri Oct 28 05:37:06 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB6521F8A7A for ; Fri, 28 Oct 2011 05:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 Ma0+9VcquLVT for ; Fri, 28 Oct 2011 05:36:56 -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 A90E321F8A7B for ; Fri, 28 Oct 2011 05:36:56 -0700 (PDT) Received: from h109.viagenie.ca (h109.viagenie.ca [206.123.31.109]) by jazz.viagenie.ca (Postfix) with ESMTPSA id E9AD321BBB; Fri, 28 Oct 2011 08:36:55 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Marc Blanchet In-Reply-To: Date: Fri, 28 Oct 2011 08:36:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <55D5BCA7-3D6D-4757-861E-F712146463CE@viagenie.ca> References: <2B0A1E24-4309-4B1E-874B-E7161C212911@nominum.com> <38D1A504-9144-4C88-A188-B02BE4F492F0@viagenie.ca> <1DB05243-3779-409A-86FE-F15133BC0C12@nominum.com> <179BFEB1-ABB9-45A7-BF9C-CE2F8D4DA09D@viagenie.ca> To: VithalPrasad Gaitonde X-Mailer: Apple Mail (2.1251.1) Cc: "" , Ted Lemon Subject: Re: [dhcwg] Character Encoding of DNS domain option (option 15) RFC 2132 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 12:37:06 -0000 Le 2011-10-28 =E0 04:22, VithalPrasad Gaitonde a =E9crit : > Thanks for the responses, Marc, Ted. > =20 > Does that imply then that in case internationalized domain names, = punycode should be used ? punycode encoding is used for internationalized domain names. the = punycode encoded idn conforms to the restricted ascii. So from dhcp, = dns, ... point of view, an idn is just a regular domain name. therefore, = the dhcp option should have restricted ascii, whatever the domain name = is a normal one or an idn. Marc. > =20 > Regards, > Prasad >=20 > On Fri, Oct 28, 2011 at 12:05 AM, Marc Blanchet = wrote: > to me, you are just looking into big troubles if you use a character = encoding for DNS names in DHCP that is different than the standardized = character encoding for DNS names everywhere else. so I would stick to = restricted ascii. no utf8. nothing else. >=20 > Marc. >=20 > Le 2011-10-27 =E0 13:01, VithalPrasad Gaitonde a =E9crit : >=20 > > I am still a bit confused here... > > To ensure interoperability with standards compliant DHCP clients, = what is the character encoding that the server should use...and the = converse. > > > > Or are we saying that interoperability is broken here as the = standard is silent on the issue leaving implementations to take a = possibly different approach and thereby be non-interoperable. > > > > Thanks, > > Prasad > > > > > > On Mon, Oct 24, 2011 at 1:19 AM, Marc Blanchet = wrote: > > I read it, but maybe I misunderstood. Anyway, back to the original = question, my point is that the character encoding of DNS domain option = in dhcp must be restricted ascii (and that includes the support of idn). > > > > Marc. > > > > Le 2011-10-23 =E0 15:36, Ted Lemon a =E9crit : > > > > > On Oct 23, 2011, at 3:30 PM, Marc Blanchet wrote: > > >> don't agree about UTF-8. idns are encoded on the wire as normal = domain names, i.e. restricted ascii. > > > > > > Clearly you didn't read what I said in the first paragraph. :) = As you say, for DNS you can't use UTF-8. > > > > > > > >=20 >=20 From denghui02@gmail.com Sat Oct 29 08:22:00 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@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: [dhcwg] Last Call for draft-ietf-mif-dhcpv6-route-option-03 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@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: [dhcwg] Last Call for draft-ietf-mif-dhcpv6-route-option-03 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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 gvithal@gmail.com Mon Oct 31 06:13:42 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E93C21F8B82 for ; Mon, 31 Oct 2011 06:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 CwbDOk8TeJ0z for ; Mon, 31 Oct 2011 06:13:41 -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 C999421F8BAD for ; Mon, 31 Oct 2011 06:13:40 -0700 (PDT) Received: by eyg24 with SMTP id 24so5573240eyg.31 for ; Mon, 31 Oct 2011 06:13:40 -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; bh=E5057U8EHw2pH0nDsfjyDPGeHZ9yDX4b+sfRtpZf080=; b=NdJfaUsHKM28mNxHq6P0EH2qpVdl0NdAHDP1q3FAZy8WfkHtGfAZQ0cYYeNprm5IFH UcPFI36cVaLZocuDMH5MK0m2ZGGeeeXc9b7NMPj/Fr/vrvDzY1ORVLkq5edeiKNxwqLm LNSLZ4wAH71nvCoTVcY1Nwok0i7Gvj4uKJWpQ= MIME-Version: 1.0 Received: by 10.213.16.75 with SMTP id n11mr747938eba.103.1320066819883; Mon, 31 Oct 2011 06:13:39 -0700 (PDT) Received: by 10.213.13.2 with HTTP; Mon, 31 Oct 2011 06:13:39 -0700 (PDT) In-Reply-To: <55D5BCA7-3D6D-4757-861E-F712146463CE@viagenie.ca> References: <2B0A1E24-4309-4B1E-874B-E7161C212911@nominum.com> <38D1A504-9144-4C88-A188-B02BE4F492F0@viagenie.ca> <1DB05243-3779-409A-86FE-F15133BC0C12@nominum.com> <179BFEB1-ABB9-45A7-BF9C-CE2F8D4DA09D@viagenie.ca> <55D5BCA7-3D6D-4757-861E-F712146463CE@viagenie.ca> Date: Mon, 31 Oct 2011 18:43:39 +0530 Message-ID: From: VithalPrasad Gaitonde To: Marc Blanchet Content-Type: multipart/alternative; boundary=0015174c169ee104cd04b098013a Cc: "" , Ted Lemon Subject: Re: [dhcwg] Character Encoding of DNS domain option (option 15) RFC 2132 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 13:13:42 -0000 --0015174c169ee104cd04b098013a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks Marc. Would the same apply to the Domain Name field in option 81 defined in RFC 4702 as well. Prasad On Fri, Oct 28, 2011 at 6:06 PM, Marc Blanchet w= rote: > > Le 2011-10-28 =E0 04:22, VithalPrasad Gaitonde a =E9crit : > > > Thanks for the responses, Marc, Ted. > > > > Does that imply then that in case internationalized domain names, > punycode should be used ? > > punycode encoding is used for internationalized domain names. the punycod= e > encoded idn conforms to the restricted ascii. So from dhcp, dns, ... poin= t > of view, an idn is just a regular domain name. therefore, the dhcp option > should have restricted ascii, whatever the domain name is a normal one or > an idn. > > Marc. > > > > > > Regards, > > Prasad > > > > On Fri, Oct 28, 2011 at 12:05 AM, Marc Blanchet < > marc.blanchet@viagenie.ca> wrote: > > to me, you are just looking into big troubles if you use a character > encoding for DNS names in DHCP that is different than the standardized > character encoding for DNS names everywhere else. so I would stick to > restricted ascii. no utf8. nothing else. > > > > Marc. > > > > Le 2011-10-27 =E0 13:01, VithalPrasad Gaitonde a =E9crit : > > > > > I am still a bit confused here... > > > To ensure interoperability with standards compliant DHCP clients, wha= t > is the character encoding that the server should use...and the converse. > > > > > > Or are we saying that interoperability is broken here as the standard > is silent on the issue leaving implementations to take a possibly differe= nt > approach and thereby be non-interoperable. > > > > > > Thanks, > > > Prasad > > > > > > > > > On Mon, Oct 24, 2011 at 1:19 AM, Marc Blanchet < > marc.blanchet@viagenie.ca> wrote: > > > I read it, but maybe I misunderstood. Anyway, back to the original > question, my point is that the character encoding of DNS domain option in > dhcp must be restricted ascii (and that includes the support of idn). > > > > > > Marc. > > > > > > Le 2011-10-23 =E0 15:36, Ted Lemon a =E9crit : > > > > > > > On Oct 23, 2011, at 3:30 PM, Marc Blanchet wrote: > > > >> don't agree about UTF-8. idns are encoded on the wire as normal > domain names, i.e. restricted ascii. > > > > > > > > Clearly you didn't read what I said in the first paragraph. :) > As you say, for DNS you can't use UTF-8. > > > > > > > > > > > > > > > > --0015174c169ee104cd04b098013a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks Marc. Would the same apply to the Domain Name field in option 8= 1 defined in RFC 4702 as well.
=A0
Prasad

=
On Fri, Oct 28, 2011 at 6:06 PM, Marc Blanchet <= span dir=3D"ltr"><marc.blan= chet@viagenie.ca> wrote:

Le 2011-10-28 =E0 04:22, VithalPrasad Gaitonde a =E9crit :

> Thanks for the responses, Marc, Ted.
>
> Does that imply then that in case internationalized domain names, puny= code should be used ?

punycode encoding is used for internationalized domain names. the pun= ycode encoded idn conforms to the restricted ascii. So from dhcp, dns, ... = point of view, an idn is just a regular domain name. therefore, the dhcp op= tion should have restricted ascii, whatever the domain name is a normal one= or an idn.

Marc.


>
> Regards,
> Prasad
>
> On Fri, Oct 28, 2011 at 12:05 AM, Marc Blanchet <marc.blanchet@viagenie.ca> wrote:
> to me, you are just looking into big troubles if you use a character e= ncoding for DNS names in DHCP that is different than the standardized chara= cter encoding for DNS names everywhere else. so I would stick to restricted= ascii. no utf8. nothing else.
>
> Marc.
>
> Le 2011-10-27 =E0 13:01, VithalPrasad Gaitonde a =E9crit :
>
> > I am still a bit confused here...
> > To ensure interoperability with standards compliant DHCP clients,= what is the character encoding that the server should use...and the conver= se.
> >
> > Or are we saying that interoperability is broken here as the stan= dard is silent on the issue leaving implementations to take a possibly diff= erent approach and thereby be non-interoperable.
> >
> > Thanks,
> > Prasad
> >
> >
> > On Mon, Oct 24, 2011 at 1:19 AM, Marc Blanchet <marc.blanchet@viagenie.ca> wrote:
> > I read it, but maybe I misunderstood. Anyway, back to the origina= l question, my point is that the character encoding of DNS domain option in= dhcp must be restricted ascii (and that includes the support of idn).
> >
> > Marc.
> >
> > Le 2011-10-23 =E0 15:36, Ted Lemon a =E9crit :
> >
> > > On Oct 23, 2011, at 3:30 PM, Marc Blanchet wrote:
> > >> don't agree about UTF-8. idns are encoded on the wir= e as normal domain names, i.e. restricted ascii.
> > >
> > > Clearly you didn't read what I said in the first paragra= ph. =A0 :) =A0 As you say, for DNS you can't use UTF-8.
> > >
> >
> >
>
>


--0015174c169ee104cd04b098013a-- From internet-drafts@ietf.org Mon Oct 31 08:46:13 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3A0F11E80C1; Mon, 31 Oct 2011 08:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 ZXiIWb7Ko56I; Mon, 31 Oct 2011 08:46:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5787511E80B1; Mon, 31 Oct 2011 08:46:08 -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.62 Message-ID: <20111031154608.30820.81827.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 08:46:08 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-redundancy-consider-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 15:46:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Gr= oup of the IETF. Title : DHCPv6 Redundancy Deployment Considerations Author(s) : John Jason Brzozowski Jean-Francois Tremblay Jack Chen Tomasz Mrugalski Filename : draft-ietf-dhc-dhcpv6-redundancy-consider-02.txt Pages : 16 Date : 2011-10-31 This document documents some deployment considerations for those who wishing to use DHCPv6 to support their deployment of IPv6. Specifically, providing semi-redundant DHCPv6 services is discussed in this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-redundancy-consid= er-02.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-dhc-dhcpv6-redundancy-conside= r-02.txt