Re: Regarding call Chinese names
Hi Arturo, diffcult for us, english speaking people other than western, Section 4 has been moved. thanks for your comments, -Hui 2013/7/11 Arturo Servin arturo.ser...@gmail.com Great document, I really liked. Same as SM I would suggest change western for something else. And I would also suggest to move section 4 before explaining the titles. I guess the reading would be much easier. Regards, as On 7/10/13 9:55 PM, S Moonesamy wrote: Hi Deng Hui, At 17:04 10-07-2013, Hui Deng wrote: We submitted two drafts to help people here to correctly call chinese people names: http://tools.ietf.org/html/draft-deng-call-chinese-names-00 http://tools.ietf.org/html/draft-zcao-chinese-pronounce-00 I would like to thank you and your co-author on taking the initiative to write the drafts. I don't know whether I am western or not. :-) In Section 3 of draft-deng-call-chinese-names-00: 'Two generic titles that have similar meanings to Mr. and Ms./Mrs. are Xian1sheng1 and Nv3Shi4.' (1,2,3,4 in this section will be explained in next section) There are digits in two words in the above. I suggest making the comment about the numbers clearer by mentioning that the digits are intentional and they are used to denote the tone. Regards, S. Moonesamy
Re: Regarding call Chinese names
will mention this and candidate ways in the next version. thanks, -Hui 2013/7/11 Simon Perreault simon.perrea...@viagenie.ca Le 2013-07-11 02:04, Hui Deng a écrit : We submitted two drafts to help people here to correctly call chinese people names: http://tools.ietf.org/html/draft-deng-call-chinese-names-00 http://tools.ietf.org/html/draft-zcao-chinese-pronounce-00 Very cool! Thanks for writing this! I have a question: I think I've seen Chinese names written in both orders. That is, sometimes Hui Deng will be written Deng Hui. Am I right? Does this happen often? What is the most common order? Is there a way to guess what order a name is written in? Sometimes it's not easy for non-Sinophones to know which part is the given name and which part is the family name. Thanks, Simon
Re: Regarding call Chinese names
revised to for english speaking people who care thanks -Hui 2013/7/11 Ted Lemon ted.le...@nominum.com On Jul 11, 2013, at 8:14 AM, Hui Deng denghu...@gmail.com wrote: I personally feel that this is maybe one of not easier part for western people to do in today IETF. and chinese's names sound maybe more diffcult than other eastern languages. I think these documents are useful for IETFers who care, and possibly for others. Pinyin transliteration is not safely pronounceable without help. It's true that many European languages are hard for speakers of other languages to pronounce also, and I would not personally object to more helpful documents of this type for other languages. I think that what would motivate this would be author interest—that's what we usually let drive volunteer translations of IETF messages into other languages, for example. E.g., there are numerous translations for the Tao; these are done on a volunteer basis, so if you don't see one for your language, and this bothers you, the onus is on you to solve it.
Re: Regarding call Chinese names
Right, it seems most email addresses are the correct order as far as my email deng...@chinamobile.com denghu...@gmail.com denghu...@hotmail.com -Hui 2013/7/11 Ted Lemon ted.le...@nominum.com On Jul 11, 2013, at 9:58 AM, Simon Perreault simon.perrea...@viagenie.ca wrote: Is there a way to guess what order a name is written in? Sometimes it's not easy for non-Sinophones to know which part is the given name and which part is the family name. It's usually in the Chinese order in the email address.
Re: Regarding call Chinese names
Hi Stephen, all caps should be included, thanks for your pointint out. for your 85% is one syllable, I guess that normally has two characters for family name, then they will have two syllables? thanks, -Hui 2013/7/11 Stephen Sprunk step...@sprunk.org On 11-Jul-13 08:58, Simon Perreault wrote: I have a question: I think I've seen Chinese names written in both orders. That is, sometimes Hui Deng will be written Deng Hui. Am I right? Does this happen often? What is the most common order? Is there a way to guess what order a name is written in? Sometimes it's not easy for non-Sinophones to know which part is the given name and which part is the family name. It is more common for the given name to come first when written in Pinyin, following the rule for other languages written in Latin characters, but exceptions are frequent enough that one can't rely on it. A useful and growing convention is to write the family name in all caps. Using the above example, if Deng were the family name, you might see: Hui DENG or DENG Hui whereas if Hui were the family name, you might see: Deng HUI or HUI Deng Also, most family names have a single syllable; all of the top 100 are, which accounts for 85% of the population of China. So, if exactly one of the names has multiple syllables, it is reasonably safe to assume that is the given name, absent a more definitive clue. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking
Re: Regarding call Chinese names
I guess XML draft doesn't support Lǎobǎn thanks for your remindness. -Hui 2013/7/11 Stephen Sprunk step...@sprunk.org On 10-Jul-13 19:04, Hui Deng wrote: We submitted two drafts to help people here to correctly call chinese people names: http://tools.ietf.org/html/draft-deng-call-chinese-names-00 http://tools.ietf.org/html/draft-zcao-chinese-pronounce-00 While first name and last name may be useful for many Western readers, they tend to produce confusing statements like put his/her Last name first, and first name last. I would prefer the order-neutral terms given name and family name, which results in the more sensible put his/her family name first and given name last. Also, the section on tones (which BTW belongs in the pronunciation document, not the names document) is a good example of how allowing UTF-8, rather than just US-ASCII, would be useful. Lao3ban3 (Wade-Giles) requires memorizing what the various tone numbers mean, whereas Lǎobǎn (Pinyin) provides a visual representation of the proper tone, which will be more accessible to most readers. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking
Re: Regarding call Chinese names
Hi Ted, I did explain them in the 1st paragraph about minorities (not mentioned that they could have two kids in mainland) anyway, I will revise the title by adding Chinese Han people, hope that will be ok -Hui 2013/7/11 Ted Hardie ted.i...@gmail.com Howdy, Thanks for your efforts. I would suggest, however, that you re-title your drafts so that Chinese is restricted to the populations which use pinyin and have standardized on what English speakers call Mandarin (���Z or 普通��, depending on your background). Those who use romanizations based on other dialects, in line with their familial pronunciation, would otherwise be treated as not Chinese. regards, Ted Hardie On Wed, Jul 10, 2013 at 5:04 PM, Hui Deng denghu...@gmail.com wrote: Hello all We submitted two drafts to help people here to correctly call chinese people names: http://tools.ietf.org/html/draft-deng-call-chinese-names-00 http://tools.ietf.org/html/draft-zcao-chinese-pronounce-00 Feel free to let us know if you have any other issues? Best regards, -Hui Deng
Re: Regarding call Chinese names
I guess that George is your given name. Wes is your family name. Hope I am not wrong.:) -Hui 2013/7/11 George, Wes wesley.geo...@twcable.com From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Melinda Shore I agree that this is probably not appropriate for publication as an RFC but it would certainly be useful to find someplace for it in the wiki. The chairs wiki might be an option but I think it's of broader interest and use. Melinda [WEG] I think writing language documentation isn't really a good use of IETF resources, even at an individual level, because neither the problem nor the knowledge necessary to address it is specific to the IETF, nor is the problem limited to Mandarin participants. As others have noted, this is just one of many languages represented by IETFers that we'd have to treat similarly. Further, an I-D is not a particularly useful format in which to present the info. Raw text in the form of $phoneme as in $English_word may not always be helpful, especially to nonnative English speakers who now have to work through two layers of pronunciation. Being able to click on a button to hear sample pronunciations, especially in the case of words where tones matter, is very helpful. So if pronunciation guides end up in the Wiki or the Tao or some other yet to be written Diversity and Cultural guide hosted within IETF, I think it's more useful to simply reference things already extant instead of generating our own. Those representing the language in question could certainly help us to source and vet the information, but that's much quicker and more efficient than writing it themselves. Protocol reuse, hurray! :-) e.g. http://mandarin.about.com/od/pronunciation/a/How-To-Pronounce-Mandarin-Chinese.htm http://en.wikibooks.org/wiki/Japanese/Pronunciation http://en.wikipedia.org/wiki/Swedish_phonology To be clear, I'm not saying that this doesn't expose a real problem, and the draft certainly drew attention to it, but I also don't think that more documentation will solve it, especially since the information is already readily available in more accessible formats. I think what you'll find is that there are two types of folks (in IETF and generally) - those who see an attempt at proper pronunciation and cultural awareness as important and worth making extra effort to learn proactively, and those who believe that if it's an issue, the person on the receiving end will correct them when they get it wrong (and hopefully not repeat the mistake). Not making a value judgment on either, merely an observation. Thanks Wes George PS: guess which one is my given name and which my surname? Even native English speakers aren't immune from name confusion. :-) Anything below this line has been added by my company's mail server, I have no control over it. - This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
Re: Regarding call Chinese names
Hi S. Moonesamy, Thanks a lot, we will add that explaination you suggested in the next version. Best regards, -Hui 2013/7/11 S Moonesamy sm+i...@elandsys.com Hi Deng Hui, At 17:04 10-07-2013, Hui Deng wrote: We submitted two drafts to help people here to correctly call chinese people names: http://tools.ietf.org/html/**draft-deng-call-chinese-names-**00http://tools.ietf.org/html/draft-deng-call-chinese-names-00 http://tools.ietf.org/html/**draft-zcao-chinese-pronounce-**00http://tools.ietf.org/html/draft-zcao-chinese-pronounce-00 I would like to thank you and your co-author on taking the initiative to write the drafts. I don't know whether I am western or not. :-) In Section 3 of draft-deng-call-chinese-names-**00: 'Two generic titles that have similar meanings to Mr. and Ms./Mrs. are Xian1sheng1 and Nv3Shi4.' (1,2,3,4 in this section will be explained in next section) There are digits in two words in the above. I suggest making the comment about the numbers clearer by mentioning that the digits are intentional and they are used to denote the tone. Regards, S. Moonesamy
Re: Regarding call Chinese names
Good catch, thansk a lot -Hui 2013/7/11 Will Liu (Shucheng) liushuch...@huawei.com A typo in draft-deng-call-chinese-names-00: “Jiao4shao4” should be “ Jiao4shou4”. ** ** Cheers, Shucheng LIU (Will) ** ** *From:* ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] *On Behalf Of *Hui Deng *Sent:* Thursday, July 11, 2013 8:05 AM *To:* IETF Discussion *Subject:* Regarding call Chinese names ** ** Hello all We submitted two drafts to help people here to correctly call chinese people names: http://tools.ietf.org/html/draft-deng-call-chinese-names-00 http://tools.ietf.org/html/draft-zcao-chinese-pronounce-00 Feel free to let us know if you have any other issues? Best regards, -Hui Deng
Re: Regarding call Chinese names
Hi Mikael, I will change informational to no-purpose, not require IETF to publish it. what we do is just want to help people who would like to follow it. I personally feel that this is maybe one of not easier part for western people to do in today IETF. and chinese's names sound maybe more diffcult than other eastern languages. Best regards, -Hui 2013/7/11 Mikael Abrahamsson swm...@swm.pp.se On Thu, 11 Jul 2013, Zhongxin (Victor) wrote: BRAVO, techies not speaking Chinese would no longer mispronounce “Huawei” as the name of some U.S state. I have asked Huawei staff how it's pronounced and I think I get it fairly right. People who hasn't, might get confused because when I use that pronounciation it's not the prevelant pronounciation. About your example, there are plenty of places in the US with french origins, and in US english, these are pronounced differently than in french. What's correct? Perhaps if Huawei would call itself Whow-wei in latin characters more people would get it right, if this is a really sensitive issue. Linux has similar issue, Linus Torvalds native language is swedish, but he's also a native finnish speaker: http://danielmiessler.com/**blog/dont-ever-argue-again-** about-the-pronunciation-of-**linuxhttp://danielmiessler.com/blog/dont-ever-argue-again-about-the-pronunciation-of-linux How many english speakers pronounce Linux correctly? Linus' first name? In what language? Do native chinese get it right? Is it really worth spending time debating it? My name is pronounced differently in english and in swedish, just like Linus' name is. I don't get upset when people get it wrong. Btw, it's pronounced Mii-ka-el in swedish (where the ii is a long version of the initial sound in industry). So while I read with interest the documents presented in the original post in this thread, I don't expect to understand and remember all of what's in them. Are these documents intended to be published as informational RFCs (it says intended status: informational)? Are we intending to have one for each 'major' language in the world? Where is the cutoff for 'major' status of a language? Should the IETF really publish documents about human languages that doesn't really have anything to do with Internet Engineering? -- Mikael Abrahamssonemail: swm...@swm.pp.se
Excuse me for not able to reply shortly
Hi all I am still in the vocation this two weeks out of Beijing with family, quite diffcult to response in time, will try to update the drafts before the deadline. Cao Zhen will help to reply some of the suggestions. By the way, surname is Deng given name is Hui Thank you all for the disucssion I really don't know whether IETF should recommend Deng Hui or Hui Deng anyway, Best regards, Deng Hui
Regarding call Chinese names
Hello all We submitted two drafts to help people here to correctly call chinese people names: http://tools.ietf.org/html/draft-deng-call-chinese-names-00 http://tools.ietf.org/html/draft-zcao-chinese-pronounce-00 Feel free to let us know if you have any other issues? Best regards, -Hui Deng
OMA IETF MIF API Workshop - Room info
OMA IETF MIF API Workshop Time: Tuesday: 18:10-20:00 Location: room 212/213 1) Program 1.1) OMA OpenCMAPI activity (Thierry Berisot, OMA) 1.2) IETF MIF API Design (Ted Lemon, IETF) 1.3) IETF API related consideration (TBD) 1.4) OMA API Program (Liliana Dinale, OMA) 1.5) Vendor's today implementation (Maybe) 1.6) Next step between IETF and OMA (Thierry, Margaret, and Hui) 2) Purpose 2.1) From IETF, this workshop would help to explain the API related topic, and clarify what is recommended and not recommended to do and standardized, if possible, either publish a information document or adding word into the current MIF api draft about how to use those MIF API for Internet developer. and some current practices information how today smart terminal is doing. 2.2) From OMA perspective, to socialize OMA’s published specifications and current ongoing standards activities in the area of APIs. To make sure that the standards landscape for APIs is coordinated and harmonized. To solicit feedback about OMA’s specification for Authorization4APIs, which is built on IETF OAuth as well as OpenCMAPI. 3) Outcomes: 3.1) Future work about how to use those MIF API in an IETF information document or inside current MIF API documentfor Internet developers. 3.2) Outcomes OMA: Improved understanding of each others’ activities, and a coordinated approach going forward 3.3) Better mutual understanding of the work of both organizations, and how to cooperate in the future.
OMA IETF MIF API Workshop
OMA IETF MIF API Workshop Time: Tuesday: 18:10-20:00 Location: TBD 1) Program 1.1) OMA OpenCMAPI activity (Thierry) 1.2) IETF MIF API Design (Ted Lemon) 1.3) IETF API related work (TBD) 1.4) OMA API Program (OMA Member) 1.5) Vendor's today implementation (Maybe) 1.6) Next step between IETF and OMA (Thierry and Hui) 2) Purpose 2.1) From IETF, this workshop would help to explain the API related topic, and clarify what is recommended and not recommended to do and standardized, if possible, either publish a information document or adding word into the current MIF api draft about how to use those MIF API for Internet developer. and some current practices information how today smart terminal is doing. 2.2) From OMA perspective, to socialize OMA’s published specifications and current ongoing standards activities in the area of APIs. To make sure that the standards landscape for APIs is coordinated and harmonized. To solicit feedback about OMA’s specification for Authorization4APIs, which is built on IETF OAuth as well as OpenCMAPI. 3) Outcomes: 3.1) Future work about how to use those MIF API in an IETF information document or inside current MIF API documentfor Internet developers. 3.2) Outcomes OMA: Improved understanding of each others’ activities, and a coordinated approach going forward 3.3) Better mutual understanding of the work of both organizations, and how to cooperate in the future.
Re: [BEHAVE] Last Call: draft-ietf-behave-v4v6-bih-06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard
Best is no ALG. Worse is one ALG. Even worse is two ALGs. -d OK, I have see that there is two solutions for just one ALG. -Hui ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Last Call: draft-ietf-behave-v4v6-bih-06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard
inline please, +1 ... since the alternative is that apps that require ipv4 sockets and pass ipv4 literals are stranded on ipv6 only networks. Running code on the n900 shows that nat464 provides real user and network benefit Can you run an FTP server on the BIH host, and have it do active mode transfers and passive mode transfers? I admit that isn't terribly important (nobody much loves FTP any more), but if the BIH host doesn't know its public mapping and can't create one, we lose that class of applications that listen on a port. Losing that class of applications may, or may not, be important. Many of those applications do STUN or STUN-/ICE-like things for their own NAT traversal (e.g., Skype). But some don't and work properly without a hole punched (e.g., BitTorrent). PCP can make all of this work, if it's integrated into BIH and the NAT64. -d You are jumping into another discussion how to reach from outside, There has other way to do it ,not just BIH+NAT64. Hui ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Last Call: draft-ietf-behave-v4v6-bih-06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard
Hi Dan, Inline please, 2011/9/27 Dan Wing dw...@cisco.com -Original Message- From: Hui Deng [mailto:denghu...@gmail.com] Sent: Monday, September 26, 2011 11:01 PM To: Dan Wing Cc: teemu.savolai...@nokia.com; satoru.matsush...@gmail.com; ietf@ietf.org; softwi...@ietf.org; beh...@ietf.org Subject: Re: [BEHAVE] Last Call: draft-ietf-behave-v4v6-bih-06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard Hi Dan inline please, I believe the objection is against non-deterministic translation, rather than stateful versus stateless. By non-deterministic, I mean that the subscriber's equipment (e.g., CPE) cannot determine the mapping it will have on the Internet. A+P mechanisms are Could you help be more elaboration on CPE can't determine the ampping? It can't determine the public IP address and port of a mapping on the NAT64 (CGN), and it can't create a mapping on the NAT64 (CGN) -- because the CGN is going to make a dynamic mapping when it sees a UDP, TCP, or ICMP packet from the subscriber. I don't see it matters deterministic (including 4rd, Dual-IVI, and draft-ymbk-aplus-p). By the way, I would say you are missing one early draft: http://tools.ietf.org/html/draft-murakami-softwire-4v6-translation-00 which is align with 4rd about 4v6 translation which has been contributed by major operators which is also align with NAT64 deployment. Sorry. -d -Hui A stateful CGN, as commonly deployed, is not deterministic. However -- and this is my point in this email -- a stateful CGN can be configured and deployed so that it deterministically maps traffic. That is, it can function very much like A+P/4rd/Dual- IVI so that port N from subscriber A is always mapped to public port Z on IPv4 address Y. We could have the CPE know about that fixed mapping using the same DHCP options that A+P/4rd/ Dual-IVI would use, or use PCP, or use some other protocol. -d I would assume softwires follows these same IETF guidelines and therefore is now focusing solely on stateless approaches(?). If the IETF opinion has changed so that also stateful double translation solutions are now ok for IETF, then that should perhaps be reflected in this document as well. Unfortunately, I did not have chance to go to softwires interim, but please let us know if the discussions there impact also the quoted recommendation. Best regards, Teemu -Original Message- From: behave-boun...@ietf.org [mailto:behave- boun...@ietf.org] On Behalf Of ext Satoru Matsushima Sent: 13. syyskuuta 2011 06:51 To: ietf@ietf.org Cc: beh...@ietf.org; Satoru Matsushima Subject: Re: [BEHAVE] Last Call: draft-ietf-behave-v4v6-bih- 06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard The introduction in the draft says: IETF recommends using dual-stack or tunneling based solutions for IPv6 transition and specifically recommends against deployments utilizing double protocol translation. Use of BIH together with a NAT64 is NOT RECOMMENDED [RFC6180]. This statement makes a strong obstacle when we develop stateless solution with translation in softwires wg. I think that it is still remained a room to make decision whether removing the statement or remaining it. The discussion which we'll have in the softwires interim meeting would be helpful to decide it. Best regards, --satoru On 2011/08/31, at 22:53, The IESG wrote: The IESG has received a request from the Behavior Engineering for Hindrance Avoidance WG (behave) to consider the following document: - 'Dual Stack Hosts Using Bump-in-the-Host (BIH)' draft-ietf-behave-v4v6-bih-06.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-09-14. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Bump-In-the-Host (BIH) is a host-based IPv4 to IPv6
Re: [BEHAVE] Last Call: draft-ietf-behave-v4v6-bih-06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard
inline please, 2011/9/27 Dan Wing dw...@cisco.com -Original Message- From: teemu.savolai...@nokia.com [mailto:teemu.savolai...@nokia.com] Sent: Monday, September 26, 2011 11:14 PM To: dw...@cisco.com; satoru.matsush...@gmail.com; ietf@ietf.org Cc: softwi...@ietf.org; beh...@ietf.org Subject: RE: [BEHAVE] Last Call: draft-ietf-behave-v4v6-bih-06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard I believe the objection is against non-deterministic translation, rather than stateful versus stateless. By non-deterministic, I mean that the subscriber's equipment (e.g., CPE) cannot determine the mapping it will have on the Internet. A+P mechanisms are deterministic (including 4rd, Dual-IVI, and draft-ymbk-aplus-p). A stateful CGN, as commonly deployed, is not deterministic. I don't understand why that is significant enough factor for IETF to (not) recommend some double translation variants. I mean does existing applications work better if double translation is done in deterministic manner? Yes, it allows the CPE to implement an ALG -- if an application needs an ALG (e.g., active-mode FTP). Are you saying distrbiuted ALG is much better than centralized ALG? -Hui -d One reasoning against double translation has been that it breaks some class of applications. Is it now so that some forms of double translation do not break applications while some others do? Teemu ___ Behave mailing list beh...@ietf.org https://www.ietf.org/mailman/listinfo/behave ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Last Call: draft-ietf-behave-v4v6-bih-06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard
Hi Dan inline please, I believe the objection is against non-deterministic translation, rather than stateful versus stateless. By non-deterministic, I mean that the subscriber's equipment (e.g., CPE) cannot determine the mapping it will have on the Internet. A+P mechanisms are Could you help be more elaboration on CPE can't determine the ampping? deterministic (including 4rd, Dual-IVI, and draft-ymbk-aplus-p). By the way, I would say you are missing one early draft: http://tools.ietf.org/html/draft-murakami-softwire-4v6-translation-00 which is align with 4rd about 4v6 translation which has been contributed by major operators which is also align with NAT64 deployment. -Hui A stateful CGN, as commonly deployed, is not deterministic. However -- and this is my point in this email -- a stateful CGN can be configured and deployed so that it deterministically maps traffic. That is, it can function very much like A+P/4rd/Dual-IVI so that port N from subscriber A is always mapped to public port Z on IPv4 address Y. We could have the CPE know about that fixed mapping using the same DHCP options that A+P/4rd/ Dual-IVI would use, or use PCP, or use some other protocol. -d I would assume softwires follows these same IETF guidelines and therefore is now focusing solely on stateless approaches(?). If the IETF opinion has changed so that also stateful double translation solutions are now ok for IETF, then that should perhaps be reflected in this document as well. Unfortunately, I did not have chance to go to softwires interim, but please let us know if the discussions there impact also the quoted recommendation. Best regards, Teemu -Original Message- From: behave-boun...@ietf.org [mailto:behave-boun...@ietf.org] On Behalf Of ext Satoru Matsushima Sent: 13. syyskuuta 2011 06:51 To: ietf@ietf.org Cc: beh...@ietf.org; Satoru Matsushima Subject: Re: [BEHAVE] Last Call: draft-ietf-behave-v4v6-bih-06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard The introduction in the draft says: IETF recommends using dual-stack or tunneling based solutions for IPv6 transition and specifically recommends against deployments utilizing double protocol translation. Use of BIH together with a NAT64 is NOT RECOMMENDED [RFC6180]. This statement makes a strong obstacle when we develop stateless solution with translation in softwires wg. I think that it is still remained a room to make decision whether removing the statement or remaining it. The discussion which we'll have in the softwires interim meeting would be helpful to decide it. Best regards, --satoru On 2011/08/31, at 22:53, The IESG wrote: The IESG has received a request from the Behavior Engineering for Hindrance Avoidance WG (behave) to consider the following document: - 'Dual Stack Hosts Using Bump-in-the-Host (BIH)' draft-ietf-behave-v4v6-bih-06.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-09-14. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Bump-In-the-Host (BIH) is a host-based IPv4 to IPv6 protocol translation mechanism that allows a class of IPv4-only applications that work through NATs to communicate with IPv6-only peers. The host on which applications are running may be connected to IPv6-only or dual-stack access networks. BIH hides IPv6 and makes the IPv4- only applications think they are talking with IPv4 peers by local synthesis of IPv4 addresses. This draft obsoletes RFC 2767 and RFC 3338. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-behave-v4v6-bih/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-behave-v4v6-bih/ No IPR declarations have been submitted directly on this I-D. ___ Behave mailing list beh...@ietf.org https://www.ietf.org/mailman/listinfo/behave ___ Behave mailing list beh...@ietf.org https://www.ietf.org/mailman/listinfo/behave ___ Behave mailing list beh...@ietf.org https://www.ietf.org/mailman/listinfo/behave ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] [Softwires] Last Call:draft-ietf-behave-v4v6-bih-06.txt (Dual Stack Hosts UsingBump-in-the-Host (BIH)) to Proposed Standard
May I know what's the reason to against stateful other than stateless? -Hui 2011/9/26 Rajiv Asati (rajiva) raj...@cisco.com tunneling). It may be that the recommendation is specifically against *stateful* double translation That may be reasonable. And the document may reflect that. IETF recommends using dual-stack or tunneling based solutions for IPv6 transition and specifically recommends against deployments utilizing double protocol translation. Use of BIH together with a NAT64 is NOT RECOMMENDED [RFC6180]. One could suggest rephrasing that para with something like this - This document doesn't recommend using BIH together with NAT64 [RFC6180]. Of course, the adoption of this or any solution (e.g dual-stack and/or any solution that eases the path to IPv6 (and accommodate residual IPv4)) would be subjected to the overall cost-effectiveness, as determined by operators per their environments/constraints. Cheers, Rajiv -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of teemu.savolai...@nokia.com Sent: Monday, September 26, 2011 11:20 AM To: satoru.matsush...@gmail.com; ietf@ietf.org Cc: softwi...@ietf.org; beh...@ietf.org Subject: Re: [Softwires] [BEHAVE] Last Call:draft-ietf-behave-v4v6-bih- 06.txt (Dual Stack Hosts UsingBump-in-the-Host (BIH)) to Proposed Standard Please note that this statement was included after quite long and heated discussion in behave WG and because it came clear that IETF recommendation is against double protocol translation (in favor of dual-stack and tunneling). It may be that the recommendation is specifically against *stateful* double translation (although that was not said aloud, if I recall correctly). I would assume softwires follows these same IETF guidelines and therefore is now focusing solely on stateless approaches(?). If the IETF opinion has changed so that also stateful double translation solutions are now ok for IETF, then that should perhaps be reflected in this document as well. Unfortunately, I did not have chance to go to softwires interim, but please let us know if the discussions there impact also the quoted recommendation. Best regards, Teemu -Original Message- From: behave-boun...@ietf.org [mailto:behave-boun...@ietf.org] On Behalf Of ext Satoru Matsushima Sent: 13. syyskuuta 2011 06:51 To: ietf@ietf.org Cc: beh...@ietf.org; Satoru Matsushima Subject: Re: [BEHAVE] Last Call: draft-ietf-behave-v4v6-bih-06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard The introduction in the draft says: IETF recommends using dual-stack or tunneling based solutions for IPv6 transition and specifically recommends against deployments utilizing double protocol translation. Use of BIH together with a NAT64 is NOT RECOMMENDED [RFC6180]. This statement makes a strong obstacle when we develop stateless solution with translation in softwires wg. I think that it is still remained a room to make decision whether removing the statement or remaining it. The discussion which we'll have in the softwires interim meeting would be helpful to decide it. Best regards, --satoru On 2011/08/31, at 22:53, The IESG wrote: The IESG has received a request from the Behavior Engineering for Hindrance Avoidance WG (behave) to consider the following document: - 'Dual Stack Hosts Using Bump-in-the-Host (BIH)' draft-ietf-behave-v4v6-bih-06.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-09-14. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Bump-In-the-Host (BIH) is a host-based IPv4 to IPv6 protocol translation mechanism that allows a class of IPv4-only applications that work through NATs to communicate with IPv6-only peers. The host on which applications are running may be connected to IPv6-only or dual-stack access networks. BIH hides IPv6 and makes the IPv4-only applications think they are talking with IPv4 peers by local synthesis of IPv4 addresses. This draft obsoletes RFC 2767 and RFC 3338. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-behave-v4v6-bih/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-behave-v4v6-bih/ No IPR declarations have been submitted directly on this I-D. ___ Behave mailing list
Re: Beijing hotel Nikko close to Shangri-La?
could anyone copy the map to me ? this website is not reachable for me. I have been there several days before, the direct road is only for bike, I have observed there for a while and it seems nobody walking beside the major road. For pedestian, you may have to cross several over-road bridges which have stairs up and down. then you could get to shangri-la hotel finally. -Hui 2010/10/26 Huub van Helvoort hhelvo...@huawei.com Hi Alex, You wrote: Thank you for guidance, I've put Shangri-La and Nikko on a google map: http://ow.ly/2ZpEh I hope they're correct. They are correct if you pick the plan view the satelite view has a horizontal offset of about 500 meters. Regards, Huub. -- Always remember that you are unique...just like everyone else... ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: cell sim card recommendations
Yes, you could only get sim card other than rent a a new phone. let me try to classify 3 operators 1) China Mobile: 2G: GSM/GPRS/EDGE, 3G: TDSCDMA 2) China Unicom: 2G: GSM/GPRS/EDGE, 3G:WCDMA 3) China Telcom: 2G: CDMA, 3G:CDMA 2000 1XEVDO If you would like to get 3G capability, I would recommend to use China Unicom. but anyway, China Mobile has the best coverage nation wide. For buying a sim card inside the downtown, it must be very cheaper, Normally in Beijing, you could buy prepaid sim card say 100RMB, the cost will be 0.5 rmb per minutes, it will differently from each opeartors. you may easily found them in newspaper selling both which should be very near the hotel. it may cost 50RMB, I have no idea. -Hui 2010/10/27 Dave CROCKER d...@dcrocker.net Nihao, The Beijing event info includes a reference to getting a sim card at the airport: http://www.ietf79.cn/show.php?contentid=46 Some references I've seen elsewhere on the net suggest perhaps getting a China Mobile card in town at a store. (For example, much cheaper.) What none of these provide is enough detail to know what specific services will come with the card and at what price. Predictably, I'm particularly interested in 3G data mode. (Life in Barcelona was made vastly more comfortable by a second-tier provider's 100MB/day service at 3 EU/day. I'm hoping there is a similar option in Beijing that is convenient to obtain.) Suggestions? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Local Beijing people response - RE: Request for community guidance on issue concerning a future meeting of the IETF
Dave, Thanks for your clarification, now I understand this has converged to a more contract language issue. At this stage, I may not be able to help on the detail languages since I guess the hoster or IAOC already have been deeply involved in it. Anyhow, I apprecaite that you make everybody more clear on it, thanks. Lastly, I think that everybody have to self-censor about what he does. Thanks for the discussion -Hui 2009/10/2 Dave CROCKER d...@dcrocker.net: Hui, Hui Deng wrote: 1) I personally have attended several standardization meetings such as 3GPP and 3GPP2 in China, Many of us have attended meetings in China and we have found them productive and enjoyable. However all of those other groups conduct their business in a way that is significantly different from the unruly style of the IETF. 3) IETF is doing technical stuff, I don't see why we need to be involved in political stuff. This has been explained repeatedly. First, there is legitimate technical work in the IETF that touches topics which are explicitly prohibited by the contract language. Second, the style of IETF discussions often includes individual comments which are likely to violate the contract. This unruly speech is a consequence of a core principle in the open style of IETF work. 4) China is one of the major member of United Nations, anyhow, come here and see Hui, this really has little to do with China. Rather, the problem is with contract language that I believe we would never accept for any other venue. The only reason we have a debate about this because we are so /eager/ to have an IETF meeting in China! Some folk say that we should ignore the language in the draft contract, because it will not be enforced, except under extreme circumstances. First, it is never appropriate for people signing a contract to assume that it won't be enforced, especially when they cannot really know the exact conditions that will cause it to be enforced. (The term fiduciary responsibility covers this.) Second, these assurances are coming from people who cannot speak for the hotel or the government. Hence, they are merely guessing. Let's be specific: Should the contents of the Group's activities, visual or audio presentations at the conference,or printed materials used at the conference (which are within the control of the Client) contain Note how extensive this is. We are required to control material and speech by everyone, yet the IETF has never really controlled the material or speech of /anyone/. any defamation against the Government of the People's Republic Defamation is really a rather vague word, especially among most of us do not know how it is actually used in China. (Let's be fair. I suspect most of us do not know how it is used as a legal term in the US, or any other country...) So we need to be afraid of violating this, without really knowing what is permitted and what is prohibited. of China, or show any disrespect to the Chinese culture, or Disrespect is an even more vague term and it is coupled with culture which could mean anything having to do with the country's government, history or population, and could even cover reference to Chinese people anywhere in the world. Worse, comments made in the IETF are often disrespectful. We wish they weren't, but again, this is a consequence of how the IETF conducts its business. So the IETF really is being required to make guarantees that change its basic style of operation. violates any laws of the People's Republic of China or feature Language that says that we won't violate the host country's laws is, of course, not necessary -- the laws are the laws and anyone violating them has a problem, no matter whether it is referenced in the contract -- but it probably doesn't hurt to include it. Or rather, the only reason to include it is to set the stage for the financial consequences, specified later... any topics regarding human rights or religion without prior approval from the Government of the People's Republic of China, As has been noted by several folks, the IETF does work that necessarily requires discussing topics that are relevant to human rights. And again, we also have the problem of trying to restrict spontaneous comments that might violate these conditions; yet we have never done that. the Hotel reserves the right to terminate the event on the spot and/or ask the person(s) who initiates or participates in any or all of the above action to leave the hotel premises immediately. This gives the Hotel complete freedom to shut the meeting down according to its own interpretation of conditions that are extremely vague. That's not a reasonable contract condition for us to agree to. (Here's where fiduciary responsibility becomes the real focus, when making an agreement.) The Client will support and assist the Hotel with the necessary
RE: Request for community guidance on issue concerning a future meeting of the IETF
Does this survey still work?, I failed to do anything over there. -Hui From: t...@americafree.tv To: ietf-annou...@ietf.org; ietf@ietf.org; wgcha...@ietf.org Subject: Request for community guidance on issue concerning a future meeting of the IETF Date: Fri, 18 Sep 2009 11:42:00 -0400 CC: i...@ietf.org; irtf-ch...@irtf.org Greetings; We have received numerous suggestions and requests for an IETF meeting in China and the IAOC has been working on a potential China meeting for several years. We are now close to making a decision on a potential upcoming meeting in China. However, the following issue has arisen and we would appreciate your feedback. The Chinese government has imposed a rule on all conferences held since 2008 regarding political speech. A fundamental law in China requires that one not criticize the government. Practically, this has reference to public political statements or protest marches, which are not the IETF's custom. The government, which is a party to the issue, requires that people who attend conferences in China (the IETF being but one example) not engage in political speech during their tour in China. We consider this to be acceptable, on the basis that the IETF intends to abide by the laws of whatever nations it visits and we don't believe that this impacts our ability to do technical work. The rule is implemented in the Hotel agreement and reads (note that the Client would be the Host, and the Group would be the IETF) : Should the contents of the Group's activities, visual or audio presentations at the conference,or printed materials used at the conference (which are within the control of the Client) contain any defamation against the Government of the People's Republic of China, or show any disrespect to the Chinese culture, or violates any laws of the People's Republic of China or feature any topics regarding human rights or religion without prior approval from the Government of the People's Republic of China, the Hotel reserves the right to terminate the event on the spot and/or ask the person(s) who initiates or participates in any or all of the above action to leave the hotel premises immediately. The Client will support and assist the Hotel with the necessary actions to handle such situations. Should there be any financial loss incurred to the Hotel or damage caused to the Hotel's reputation as a result of any or all of the above acts, the Hotel will claim compensation from the Client. What does this condition mean ? The hotel staff would have, in theory, the legal right to shut down the meeting and ask the offending participants to leave the property immediately. While we do not foresee a situation where such action would take place, we feel that it is proper to disclose these conditions to the community. The members of the IAOC, speaking as individuals, do not like this condition as a matter of principle. The IAOC does believe that this condition would not prevent the IETF from conducting its business. We note that the Vancouver/Quebec survey conducted earlier this year asked for people to suggest venues in Asia; an overwhelming majority (94%) of those who mentioned China were in favor of having a meeting there. We are therefore asking for input from the community by two means - by commenting on the IETF discussion list, and also by completing a very short survey on people's intentions to travel to China, or not, subject to these conditions. This survey can be found here : https://www.surveymonkey.com/s.aspx?sm=h4DUkRUOdG_2bVLqioPcYYHw_3d_3d All responses received by October 1, 2009 at 9:00 AM EDT (1300 UTC) will be considered by the IAOC in making its decision. We appreciate the assistance of the community in providing us with data that will help us to make an informed decision. Regards Marshall Eubanks (acting for the IAOC) _ Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! http://spaces.live.com/spacesapi.aspx?wx_action=createwx_url=/friends.aspxmkt=en-us___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Local Beijing people response - RE: Request for community guidance on issue concerning a future meeting of the IETF
excuse me for previous sending wrong email. Hello, all I have to say something before the deadline of this survey. To be honest, I am not the hoster, but live in Beijing, China for the long time, and would like to clarify several different concerns about China and Beijing. 1) I personally have attended several standardization meetings such as 3GPP and 3GPP2 in China, they have been discussed for example lots of security or privacy stuff such as in 3GPP SA3, I haven't see any problem. 2) Olympic game has been here, most of people think that it was a sucess. 3) IETF is doing technical stuff, I don't see why we need to be involved in political stuff. 4) China is one of the major member of United Nations, anyhow, come here and see what she really looks like, other than imagine remotely is a better way to do it. Thanks for your consideration. -Hui From: dean.wil...@softarmor.com To: dcroc...@bbiw.net Subject: Re: Request for community guidance on issue concerning a future meeting of the IETF Date: Tue, 29 Sep 2009 18:09:04 -0500 CC: i...@ietf.org; wgcha...@ietf.org; ietf@ietf.org On Sep 28, 2009, at 8:07 PM, Dave CROCKER wrote: Folks, A number of people have indicated that they believe the draft contract language is standard, and required by the government. It occurs to me that we should try to obtain copies of the exact language used for meetings by other groups like ours. If indeed the language is identical, that probably means something useful. If our draft language is different, that also probably means something useful. Does anyone have access to copies of agreements for other meetings? As the IETF's liaison manager to OMA, and a former member of the OMA board of directors, I checked with OMA's management team, providing them the proposed text from our contract. They have held several large meetings as well as smaller interop events in China in the past. Their general manager does not recall having signed anything as unforgiving as the proposed contract, and suggested that we try to negotiate the terms, especially the financial damages clause, and that we attempt to restrict the right to terminate to just the affected session, not the entire multi-working-group IETF meeting. Clearly the government has the power to terminate whatever they want whenever they want, but OMA management seemed to think that the proposed contract was more generous to the venue than government rules might require. OMA management did caution us to be careful about visas and be prepared for some of our attendees to show up with missing or wrong visas and need help at the time of arrival, and that we may have visa difficulty with attendees from Taiwan. They also had some trouble with equipment in customs, including power supplies and WiFi base stations. Apparently some equipment was disassembled by customs inspectors and required in the field repair with solder and scavenged parts, so we should be prepared to re-assemble things that weren't meant to come apart. Their technical support firm is based in France and ended up shipping some equipment in and out via the French embassy due to transport difficulties. OMA management did note that they consider their meetings in China to have been very successful, and that they had and expected no difficulty with their technical discussions falling afoul of local regulations. OMA, as has been previously pointed out, has considered DRM specification a central piece of their specification family in the past, and encountered no difficulties talking about DRM in China. -- Dean _ More than messages–check out the rest of the Windows Live™. http://www.microsoft.com/windows/windowslive/___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request for community guidance on issue concerning a future meeting of the IETF
Thanks Ray, Now I remember that I forget I have done that once already. that will be fine for me. Regards, -Hui 2009/10/1 Ray Pelletier rpellet...@isoc.org: On Sep 30, 2009, at 10:41 AM, Hui Deng wrote: Does this survey still work?, I failed to do anything over there. Yes it does. What problems did you experience? We have had one other complain of Java problems, but he had an old Browser. Otherwise 343 have completed the survey successfully. Ray -Hui From: ...@americafree.tv To: ietf-annou...@ietf.org; i...@ietf.org; wgcha...@ietf.org Subject: Request for community guidance on issue concerning a future meeting of the IETF Date: Fri, 18 Sep 2009 11:42:00 -0400 CC: i...@ietf.org; irtf-ch...@irtf.org Greetings; We have received numerous suggestions and requests for an IETF meeting in China and the IAOC has been working on a potential China meeting for several years. We are now close to making a decision on a potential upcoming meeting in China. However, the following issue has arisen and we would appreciate your feedback. The Chinese government has imposed a rule on all conferences held since 2008 regarding political speech. A fundamental law in China requires that one not criticize the government. Practically, this has reference to public political statements or pr otest marches, which are not the IETF's custom. The government, which is a party to the issue, requires that people who attend conferences in China (the IETF being but one example) not engage in political speech during their tour in China. We consider this to be acceptable, on the basis that the IETF intends to abide by the laws of whatever nations it visits and we don't believe that this impacts our ability to do technical work. The rule is implemented in the Hotel agreement and reads (note that the Client would be the Host, and the Group would be the IETF) : Should the contents of the Group's activities, visual or audio presentations at the conference,or printed materials used at the conference (which are within the control of the Client) contain any defamation against the Government of the People's Republic of China, or show any disrespec t to the Chinese culture, or violates any laws of the People's Republic of China or feature any topics regarding human rights or religion without prior approval from the Government of the People's Republic of China, the Hotel reserves the right to terminate the event on the spot and/or ask the person(s) who initiates or participates in any or all of the above action to leave the hotel premises immediately. The Client will support and assist the Hotel with the necessary actions to handle such situations. Should there be any financial loss incurred to the Hotel or damage caused to the Hotel's reputation as a result of any or all of the above acts, the Hotel will claim compensation from the Client. What does this condition mean ? The hotel staff would have, in theory, the legal right to shut down the meeting and ask the offending participants to lea ve the property immediately. While we do not foresee a situation where such action would take place, we feel that it is proper to disclose these conditions to the community. The members of the IAOC, speaking as individuals, do not like this condition as a matter of principle. The IAOC does believe that this condition would not prevent the IETF from conducting its business. We note that the Vancouver/Quebec survey conducted earlier this year asked for people to suggest venues in Asia; an overwhelming majority (94%) of those who mentioned China were in favor of having a meeting there. We are therefore asking for input from the community by two means - by commenting on the IETF discussion list, and also by completing a very short survey on people's intentions to travel to China, or not, subject to these conditions. This survey can be found here : https://www.surveymonkey.com/s.aspx?sm=h4DUkRUOdG_2bVLqioPcYYHw_3d_3d All responses received by October 1, 2009 at 9:00 AM EDT (1300 UTC) will be considered by the IAOC in making its decision. We appreciate the assistance of the community in providing us with data that will help us to make an informed decision. Regards Marshall Eubanks (acting for the IAOC) Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! Try it! ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [IPsec] Fwd: Last Call: draft-ietf-ipsecme-ikev2-resumption (IKEv2 Session Resumption) to Proposed Standard
Comments inline, thanks 2009/9/3 Tero Kivinen kivi...@iki.fi: Yaron Sheffer writes: [YS] I see the merits of extending IKE_SA_INIT to support resumption, and in fact an early version of our work did exactly that. But the working group gave us a clear direction to use a separate exchange, and this is where we disagree: I believe we did have a strong WG consensus that the implementation benefits of having a separate exchange (i.e. not overloading even more the non-trivial IKE_SA_INIT exchange) outweigh the benefits of the alternative. I agree on that (both to the WG having consensus and also that using separate exchange is better). [Hui] I don't think so. IMO, in the list, the comparison of extended IKE_SA_INIT exchange and IKE_SESSION_RESUME still did not have a consensus yet. It was a ballot in the mailing list in the begining, and it is quite clear more people opposing sepaparate exchange, we could do one more round ballot if needed. I know that how a client detects the need for resumption is out of the scope of this draft. But, there is the possibility that IPsec client may be continuously deceived and believe the fail of IPsec gateway. It may continuously present the ticket and update the ticket. In this sense, IMHO, this draft should take care of this case. [YS] If I understand the scenario correctly, it is similar to an attacker repeatedly sending notifications to an IKE client, making it believe that the IKE exchange has failed and needs to be reinitiated. This attack against plain-vanilla IKE would be much more CPU-intensive to the client and to the (real) gateway, compared to repeated session resumption. Even when you factor in the cost of generating a new ticket. Moreover, the regular IKEv2 anti-DOS cookie mechanism is supported by IKE_SESSION_RESUME as well. Regardless what notifications or ICMP messages you send to any of the IKE end points that MUST NOT cause them to consider IKE SA failed. It MUST conclude that the other endpoind has failed only when repeated attemtps to contact it have gone unanswered for timeout period or when a cryptographically protected INITIAL_CONTACT notification is received on a different IKE SA to the same authenticated identity. (RFC 4306 section 2.4) Notifications and ICMP messages may trigger other end to send empty INFORMATIONAL message to check whether the other end is alive or not and only if that times out then the other end is considered dead. This means this kind of attack is not possible with notifications and ICMP. On the other hand I do agree with Peny that, as resumption draft makes it out of scope for this draft, how a client detects the need of resumption, we might need more text explaining this attack. I.e. we might need to add text to security considerations which says that the client implementations should not trust any untrusted source when they are trying to detect whether the resumption is needed. [Hui] I also agree with Peny and Tero. Although way of detecting failure of gateways is out of the scope of current charter, WG draft should at least handle the issues incurred by mis-judgement of client. thanks -Hui ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [mif] WG Review: Multiple InterFaces (mif)
Hi, Ted, Excuse me for late reply, thanks for the discussion. The reason why I said before is that currently there are limtied ISP providing ICE support for open applications, anyhow, P2P made a smart way to reach it. For what I know application which need ICE like IMS is normally go to independent APN. That could be guaranteed since it is kind of application binding APN. Today most mobile application binding with APN(kind of interface like) or could be on-demand select for user. I guess Marc raised similar consideration which allow application to call such interface API, then it can run depending on different connection's characteristic. Please kind help to provide your text regarding this application scenario, it will be helpful for MIF PS could include those. I will re-read the spec which you recommend and to know the potential needs. thanks again -Hui 2009/4/24 Ted Hardie har...@qualcomm.com: At 6:30 AM -0700 4/23/09, Hui Deng wrote: For what I know at the moment service provider deployment experience, ICE like solution has been deployed by a dedicate close network, this is not interact with MIF space we talked here, mif are resolve general issue with host connections, in that scenario, application is isolated. thanks. -Hui. Forgive me, Hui, but it is not clear to me whether you think the application is isolated in situations where ICE is in use, or whether it is isolated in the work for which MIF might be chartered. If your point is that not all applications have a signalling-path mechanism for trading candidates using SDP, that is certainly true. What is truly scary is that this makes applications which can use ICE better off than the common case, despite ICE's complexity. I hope, after reading the full ICE spec and recognizing that there are *still* cases where it does not work to establish connectivity, you will see the scope of the problem. Interfaces/network attachments may have different reachability characteristics (e.g. be part of different address realms or otherwise have substantially different access to parts of the network). There are classes of application which will want to make interface choices based on those characteristics. There are many other characteristics which may play into interface choices (do I already have a data channel on interface X, and need to acquire it on interface y?), and I do not want to minimize those, power savings being a big deal in my day job choices for this type of thing. But the applications' needs here can't be subordinate to those, or the whole point of the link--you know, traffic across it--is lost. Just my personal opinion, despite the mention of a day job, regards, Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [mif] WG Review: Multiple InterFaces (mif)
Christian, I agree with what you said here, MIF should tackle this thoroughly. I just wondering whether any ISP provider ICE service for open applications? maybe my limited knowledge. Regards, -Hui 2009/4/24 Christian Vogt christian.v...@ericsson.com: On Apr 23, 2009, Hui Deng wrote: For what I know at the moment service provider deployment experience, ICE like solution has been deployed by a dedicate close network, this is not interact with MIF space we talked here, mif are resolve general issue with host connections, in that scenario, application is isolated. Hui - If the to-be MIF working group is to tackle the issue of address selection, then doing so thoroughly would require to also look into NAT traversal, and this includes ICE. ICE specifies address selection rules for a large group of applications. - Christian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [mif] WG Review: Multiple InterFaces (mif)
For what I know at the moment service provider deployment experience, ICE like solution has been deployed by a dedicate close network, this is not interact with MIF space we talked here, mif are resolve general issue with host connections, in that scenario, application is isolated. thanks. -Hui. 2009/4/23 Ted Hardie har...@qualcomm.com: At 7:29 AM -0700 4/22/09, Margaret Wasserman wrote: (1) As I pointed out in my previous message to Christian, address selection is not (today) a transport-layer or application-layer function in most cases. Given that this is currently an Internet-layer function, I think it makes sense to analyze the issues with address selection (as part of the whole address/interface/router selection process) in an Internet Area group. If we find that one of the problems we have is that the Internet layer doesn't have the right information to make these decisions, then possibly some follow-on work might need to be chartered elsewhere. So this may be simply one of those cases where address selection does not fit your model, but at what layer would you describe the ICE spec as working? Clearly, one aim in ICE is to provide a signalling-path mechanism for flow endpoint selection, which certainly relates to the question of address/interface selection. There is an old saw that my work is a cross-layer optimization; yours is a layer violation, and that guy's is a hideous hack. However we have arrived here, it seems at least reasonable to say that we currently have this work muddled across a variety of layers. If we can focus it and solve it at a single layer, the architecture gets easier and the protocol smog clear a bit. But I seem to be hearing that tackling the big problem is ocean-boiling; what I am not clear on is whether the end result of piece work shifts the pain or actually reduces the smog. Perhaps it is just me; this is not stuff I am following in any depth. But the impression I'm getting from following the thread is that there is some disagreement about how to structure the work to make sure it really does reduce pain, rather than just shift it around. regards, Ted Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [mif] WG Review: Multiple InterFaces (mif)
This type of implementation is not transparent to application, kind of binding everything together, what mif is trying to do is to avoid it. thanks -Hui 2009/4/23 Christian Huitema huit...@windows.microsoft.com: (2) There is no way that these decisions can be made solely at the transport or application layer, because source (and to a lesser degree destination) address selection is tightly tied to the first-hop forwarding decision. The outbound interface, source address and default router all have to be selected in a coordinate process, to avoid sending traffic that will be discarded on the outbound path, due to router filters. Actually, applications can to do that today, using the socket API, if the stack implements the strong host model. The application just needs to bind the socket to a specific IP address. Doing that ensures that packets sourced by the application will use the specified address, will go out through the interface corresponding to that address, and will use the default gateway associated with that interface. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [mif] WG Review: Multiple InterFaces (mif)
Hi, Marc, Normally, host vendors normally really do not like to open this interface, but anyhow it is more solution oriented, let's discuss it after. -Hui 2009/4/23 Marc Blanchet marc.blanc...@viagenie.ca: Christian's suggestion is one way. not sure it is complete. but I don't agree with you (Deng): i.e. I think this suggestion is in scope of MIF wg. Maybe the outcome of the wg is a best practice document that tells application developers how to write good applications in context of MIF, where one practice is what Christian wrote, for example. Marc. Hui Deng a écrit : This type of implementation is not transparent to application, kind of binding everything together, what mif is trying to do is to avoid it. thanks -Hui 2009/4/23 Christian Huitema huit...@windows.microsoft.com: (2) There is no way that these decisions can be made solely at the transport or application layer, because source (and to a lesser degree destination) address selection is tightly tied to the first-hop forwarding decision. The outbound interface, source address and default router all have to be selected in a coordinate process, to avoid sending traffic that will be discarded on the outbound path, due to router filters. Actually, applications can to do that today, using the socket API, if the stack implements the strong host model. The application just needs to bind the socket to a specific IP address. Doing that ensures that packets sourced by the application will use the specified address, will go out through the interface corresponding to that address, and will use the default gateway associated with that interface. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ mif mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mif -- = IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN news service: http://reeves.viagenie.ca ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [mif] WG Review: Multiple InterFaces (mif)
Agree. -Hui 2009/4/23 Giyeong Son g...@rim.com: I think we may need to understand what are the real problems that people/organizations (i.e. carriers, ISPs and vendors and users) have been currently struggling with in terms of simultaneous use of multiple networks. I think, Ralph seems to have clearly brought applicable practical use cases and/or criteria. So, with the use cases it might be worth to clarify if MIF will address and provide some recommendation for (at least) BCP which can answer to those use cases. If MIF does not (instead, only addresses partially, such as conflicting configurations and/or others), there may need other working group for focusing on BCP for the end-to-end practice of simultaneous use of multiple networks/interfaces. I believe that there is no working groups currently where can provide this kind of recommendation. They may be also willing to address partially from their perspective, similar with MIF if MIF want to tackle the problem partially. I think that we already know that simultaneous use of multiple networks is very crucial issue in various aspects by various organizations. Most of current carriers/ISPs/mobile device (including laptop) manufactures seems to be willing to hear about efficient, reliable and best common practice to handle the problem. Giyeong -Original Message- From: mif-boun...@ietf.org [mailto:mif-boun...@ietf.org] On Behalf Of Ralph Droms Sent: April 23, 2009 12:08 AM To: Christian Vogt Cc: mif; Margaret Wasserman; Sam Hartman; Scott Brim; David W. Hankins; Keith Moore; Hui Deng; IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) Christian - I think address selection is part but not all of the problem. I would be happy to see a summary of current practice in dealing with simultaneous attachment to multiple networks. How does an iPhone decide between its WiFi and dell interfaces? How does an RG that can reach multiple next hop routers on its WAN interface select which router to forward to? How does a laptop choose between its WiFi and wired interfaces? - Ralph On Apr 22, 2009, at 7:03 PM 4/22/09, Christian Vogt wrote: On Apr 22, 2009, Margaret Wasserman wrote: This topic, address selection, is not currently handled by applications. In many cases, it is handled entirely by the stack (through ordering of the destination ddresses in DNS replies and source address selection in the IP stack), and in other cases the application chooses a destination address with the stack choosing a source address. There are certain cases (sometimes in solutions to the problems that we are discussing here) where applications do choose both the destination and sourece address, but they are not common. Margaret - From a system perspective, you are certainly right: Applications typically do get help from the operating system in selecting their addresses. From an OSI layering perspective, though, address selection still is performed at application layer. In fact, if an application wants to do a complete job, especially a peer-to-peer application, it needs to select both source and destination address itself, possibly after running STUN, TURN, or ICE. My main point, though, was that we are talking about two orthogonal issues -- conflicting configuration and address selection. This holds independently of the fact that an application may let the operating system accomplish part or all of address selection. Whether we take this to mean that both issues should be tackled in the same working group is a different story. I personally don't see the orthogonality of the two issues as a reason not to tackle both issues in the same working group. We just ought to be aware that the issues are separate, and the charter should describe them as such. This said, there might be work-load- or work-scope-specific reasons that suggest splitting the work into separate working groups, like those brought up by Lars, Sam, and Scott. Those arguments should be discussed as well. - Christian ___ mif mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mif ___ mif mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mif - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients
Re: WG Review: Multiple InterFaces (mif)
If you are saying multiple address for multiple interface, that's fine. but if you are talking multiple address for single interface, could you help to point out any IPv4 scenario except VPN, MIF is targeting at least half billion of subscribers who have this real problem, The problems you raised here is valuable to resolve, but MIF at the early stage may only solve some simple and easy to solve work, thanks -Hui I'm saying there is a set of problems that exist if there are multiple addresses associated with a host for any reason. This could be multiple addresses on a single interface (including aliases and multiple v6 prefixes advertised on the network segment), multiple addresses because there are multiple active interfaces, multiple addresses because the host supports both v4 and v6, multiple addresses because the host has some sort of tunnel endpoint (which might be IPvX in IPvY, or an IPsec tunnel, or mobileIP), multiple addresses because the host is behind a NAT (any kind of NAT, including a v4/v6 NAT), and so on. And among those problem areas are: address selection (which differs depending on the needs of the app, and the configuration of the network to which the host is attached), referrals, sorting out policy conflicts, sorting out non-policy related configuration, security, etc. Keith Are you saying multiple addresses on one interface of the host? thanks -Hui 2009/4/21 Keith Moore mo...@network-heretics.com: Jari Arkko wrote: There has been some discussion on whether the key issue is merging configuration from multiple sources (the DHCP view), multiple interfaces (the original view), multiple default routers (the routing view), multiple addresses (the IP layer view), multiple administrative domains (the operational view), and so on. I would like to make the point that there is no single, perfect answer. Its easy to find examples where the key issues above do not capture everything that we want to capture (see, e.g., George's response to Keith). Its really about the combination of these issues. And I think that is the way it should be. The charter text that I sent out yesterday attempts to explain what the problem space is without prejudicing ourselves to a view from just one perspective (except perhaps through the group's acronym). I think the rest is work on the problem statement, and we should let the group write that. The IESG telechat where this could be approved is two days away. Does someone have a big problem with the charter as written, serious enough to warrant a change? 1. I really think that the emphasis on attachment to multiple networks is too narrow, as this is far from the only source of the problem. As long as the WG is just trying to understand the problem and identify existing solutions, it seems appropriate to broaden the scope to consider the more general problem of multiple addresses per host. 2. I also think that, when considering the effect on applications, it needs to be explicitly pointed out that p2p and distributed apps need to be considered separately from client-server apps that many people regard as representative. More generally I think that various kinds of effects need to be considered (i.e. not just the effects on applications) and it would be very helpful if the charter could lists some examples of these as illustrations of the breadth of scope. That would minimize the potential for the WG to start off with many participants thinking _the_ problem is X when the actual problem is much broader and hopefully get the WG in the mode where it tries to enumerate the various problems and impacts rather than to try to nail down _which_ problem it is and ignore the others. 3. I am a bit concerned by the charter's mentioning of BCP documents as a possible output from the WG. I thought I had seen language in the charter text saying that the group should write a BCP, but either I was mistaken or that language has since been removed. But there's still a BCP mentioned as a deliverable in the milestones. My concern is that the WG will take this as license to try to define best current practice, which I think is somewhat of a conflict of interest with trying to identify the problem - especially given the broad scope. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00
You are right money is more operation related not technical side. However, I believe that this is also one of the most important factors and popularly has been used for determining an interface with an (access) network among multiple active interfaces automatically and dynamically. And, the mechanism to adopt or apply like this network characteristic into the routing policy on the network environment of simultaneous use of multiple interfaces may be deeply related with technical side regarding simultaneous use of multiple interfaces though. == such network characteristic could become a generic routing element which do decide whether to use this routing or interface or not, but IETF not necessraily mention it is Money or else. and also if it is not flat rate based, I guess that host will be not so suffcient intelligent to lead the routing based on the price like pennys or dollars. For instance, for a dual-mode device at home with WiFi and IP over cellular available (e.g. CDMA, GPRS/EDGE, etc), combination of various network characteristics in it would be the major factors to determine either WiFi or cellular for packet transmission. My point here is how to present those factors into the routing policy in order to determine a suitable interface with the type of *DATA or PACKET* for the transmission would be one of the important technical side to be discussed in terms of simultaneous use of multiple interfaces. == Reply same as the above However, according to Hui, it seems to be out of MIF scope described in the charter. BTW, again regarding MIF scope, I am wondering if we have already gone through a scenario for simultaneous use of multiple active interfaces based on a network environment with necessary associated network entities (from enabling attachment of multiple access networks to processing a packet transmission over the access networks from the link layer up to the transport layer) in order to identify the MIF scope (presented in the charter). If it has been already done or everyone understands clearly in terms of the MIF scope, it is OK. Otherwise, it would be good to practice it in order to clarify the MIF scope in the charter. == Current charter says best current practice, and problems tatement, those work will be done after the re-charter. thanks -Hui Giyeong -Original Message- From: Hui Deng [mailto:denghu...@gmail.com] Sent: April 19, 2009 11:40 AM To: Giyeong Son Cc: Ted Lemon; Ralph Droms; mif; ietf@ietf.org; gen-...@ietf.org; dhc WG; black_da...@emc.com; Bernie Volz Subject: Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 Hi, Giyeong, At least those are not in the current charter scope. but Ted gave a one potential solution on one problem. Regarding to Money et al, I think IETF is not going to talk about it. which is more operational recommendation. Operation could recommend the benchmark to let the user to select what he favoriate by human language other than technical language. thanks -HUi 2009/4/15 Giyeong Son g...@rim.com: I think Ted pointed out very interesting but crucial problems if I understood correctly. So, I'd like to confirm what Ted indicated and emphasized: 1. How to dynamically/automatically/efficiently enable and manage multiple active interfaces on a host? 2. How to utilize multiple active interfaces on a host? 2. What are the efficient (or cost-effective) routing decision policy? Is it least cost routing policy? Or other? If it is least cost routing policy, what are the costs? Are they money to use the connection (e.g. WiFi vs. cellular), time to spend for the transmission, reliability of the transmission, etc? If those are what Ted indicated, I am also interested in asking if the above things are in scope of MIF. Based on my experience in terms of simultaneous use of multiple interfaces, the aboves are the most critical and interesting issues in practice in order to utilize the network environment of simultaneous use of multiple interfaces reliably and efficiently. Giyeong -Original Message- From: mif-boun...@ietf.org [mailto:mif-boun...@ietf.org] On Behalf Of Ted Lemon Sent: April 14, 2009 5:48 PM To: Ralph Droms Cc: mif; ietf@ietf.org; black_da...@emc.com; dhc WG; gen-...@ietf.org; Bernie Volz Subject: Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 On Apr 14, 2009, at 3:31 AM, Ralph Droms wrote: Now, I admit I'm describing a hypothetical and abstract scenario. I don't have a specific example of a situation in which a host might make decisions - either in the stack or in an application or ??? - about outbound traffic based on knowledge of how that traffic would be forwarded by the RG. That's right. But I think it's not an accident that this is a hypothetical scenario. In reality, a scenario like this has been likely ever since wireless and wired network interfaces became standard
Re: WG Review: Multiple InterFaces (mif)
Hi, Jari, What I suggest is like the below: Connections to Multiple Networks (mif) Last Modified: 2009-04-20 Current Status: Proposed Working Group Chair(s): TBD thanks -Hui 2009/4/21 Jari Arkko jari.ar...@piuha.net: Hui, I'm not sure if I understood your comment about the WG name correctly. We cannot change it at this stage easily. So lets just keep it as is. Please find below the full charter proposal, with the suggested changes folded in from you and others. Jari Multiple InterFaces (mif) Last Modified: 2009-04-20 Current Status: Proposed Working Group Chair(s): TBD Internet Area Director(s): Ralph Droms rdr...@cisco.com Jari Arkko jari.ar...@piuha.net Internet Area Advisor: TBD Mailing Lists: General Discussion: m...@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mif Archive: http://www.ietf.org/mail-archive/web/mif Description of Working Group: Many hosts have the ability to attach to multiple networks simultaneously. This can happen over multiple physical network interfaces, a combination of physical and virtual interfaces (VPNs or tunnels), or even through multiple default routers being on the same link. For instance, current laptops and smartphones typically have multiple access network interfaces. A host attached to multiple networks has to make decisions about default router selection, address selection, DNS server selection, choice of interface for packet transmission, and the treatment of configuration information received from the various networks. Some configuration objects are global to the node, some are local to the interface, and some are related to a particular prefix. Various issues arise when multiple configuration objects that are global to the node are received on different interfaces. At best, decisions about these matters have an efficiency effect. At worst, they have more significant effects such as security impacts, or even lead to communication not being possible at all. A number of operating systems have implemented various techniques to deal with attachments to multiple networks. Some devices employ only one interface at a time and some allow per-host configuration of preferences between the interfaces but still use just one at a time. Other systems allow per-application preferences or implement sophisticated policy managers that can be configured by users or controlled externally. The purpose of the MIF working group is to describe the issues of attaching to multiple networks on hosts, document existing practice, and make recommendations about best current practice. The WG shall employ and refer to existing IETF work in this area, including, for instance, strong/weak models (RFC 1122), address selection (RFC 3484), DHCP mechanisms, Router Advertisement mechanisms, and DNS recommendations. The focus of the working group should be on documenting the system level effects to host IP stacks and identification of gaps between the existing IETF recommendations and existing practice. The working group shall address both IPv4 and IPv6 as well as stateless and stateful configuration. Network discovery and selection on lower layers as defined by RFC 5113 is out of scope. Also, the group shall not develop new protocol or policy mechanisms; recommendations and gap analysis from the group are solely based on existing solutions. The group shall not assume any software beyond basic IP protocol support on its peers or in network nodes. No work will be done to enable traffic flows to move from one interface to another. The group recognizes existing work on mechanisms that require peer or network support for moving traffic flows such as RFC 5206, RFC 4980 and the use of multiple care-of addresses in Mobile IPv6. This group does not work on or impact such mechanisms. Once the group has completed its work items, the IETF can make an informed decision about rechartering the working group to define new mechanisms or asking other, specialized working groups (such as DHC or 6MAN) to deal with specific issues. Milestones: May 2009 WG chartered July 2009 Initial draft on problem statement adopted by the WG September 2009 Initial draft on existing practices adopted by the WG Jan 2010 Initial best current practices draft adopted by the WG March 2010 Problem statement draft submitted to the IESG for publication as an Informational RFC July 2010 Existing practices draft submitted to the IESG for publication as an Informational RFC September 2010 Best current practices draft submitted to the IESG for publication as a BCP October 2010 Recharter or close ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: Multiple InterFaces (mif)
Are you saying multiple addresses on one interface of the host? thanks -Hui 2009/4/21 Keith Moore mo...@network-heretics.com: Jari Arkko wrote: There has been some discussion on whether the key issue is merging configuration from multiple sources (the DHCP view), multiple interfaces (the original view), multiple default routers (the routing view), multiple addresses (the IP layer view), multiple administrative domains (the operational view), and so on. I would like to make the point that there is no single, perfect answer. Its easy to find examples where the key issues above do not capture everything that we want to capture (see, e.g., George's response to Keith). Its really about the combination of these issues. And I think that is the way it should be. The charter text that I sent out yesterday attempts to explain what the problem space is without prejudicing ourselves to a view from just one perspective (except perhaps through the group's acronym). I think the rest is work on the problem statement, and we should let the group write that. The IESG telechat where this could be approved is two days away. Does someone have a big problem with the charter as written, serious enough to warrant a change? 1. I really think that the emphasis on attachment to multiple networks is too narrow, as this is far from the only source of the problem. As long as the WG is just trying to understand the problem and identify existing solutions, it seems appropriate to broaden the scope to consider the more general problem of multiple addresses per host. 2. I also think that, when considering the effect on applications, it needs to be explicitly pointed out that p2p and distributed apps need to be considered separately from client-server apps that many people regard as representative. More generally I think that various kinds of effects need to be considered (i.e. not just the effects on applications) and it would be very helpful if the charter could lists some examples of these as illustrations of the breadth of scope. That would minimize the potential for the WG to start off with many participants thinking _the_ problem is X when the actual problem is much broader and hopefully get the WG in the mode where it tries to enumerate the various problems and impacts rather than to try to nail down _which_ problem it is and ignore the others. 3. I am a bit concerned by the charter's mentioning of BCP documents as a possible output from the WG. I thought I had seen language in the charter text saying that the group should write a BCP, but either I was mistaken or that language has since been removed. But there's still a BCP mentioned as a deliverable in the milestones. My concern is that the WG will take this as license to try to define best current practice, which I think is somewhat of a conflict of interest with trying to identify the problem - especially given the broad scope. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [dhcwg] [mif] Gen-ART review of draft-ietf-dhc-container-00
some level of generic network characteristics benefit for the user. one example could be that routing metric may need to be updated to align with various kind of access technologies. -Hui 2009/4/17 Giyeong Son g...@rim.com: Again as I mentioned, in order to prepare or build an efficient routing policy and to select an efficient connection/interface, it would be necessary to identify, classify and/or prioritize underlying network characteristics or information of the attached networks. In addition, as many network characteristics which are essential to be used for simultaneous use of multiple interfaces are not generic forms (e.g. SSID only for 802.11), these network characteristics may require a mechanism to make them be associated with generic (formed) elements used for routing policy preparation and routing decision. Therefore, if MIF can provide an efficient guideline or mechanism for associating, it would be really amazing. I believe, the current IP network related protocols and standardized technologies may not be enough to support that on multiple interface network environment. I think each vendor, carrier, service provider and/or technology, which utilizes or supports simultaneous use of multiple connections/interfaces, may have their own proprietary mechanism in terms of gathering of network characteristics of each interface/access network technology (e.g. WiFi, GPRS, CDMA, Bluetooth, etc.), their mapping mechanism with generic formed elements, routing policy and decision mechanisms with different IP based service networks owned by different service providers or different IP network enabling core networks owned by different carriers. So, the problem Ted and Ralph are addressing seems to be just one of issues (but only for WiFi network environments) in terms of network characteristic that may be necessary to be considered during selection of an efficient connection/interface from multiple candidates. Giyeong -Original Message- From: Ralph Droms [mailto:rdr...@cisco.com] Sent: April 16, 2009 1:32 PM To: Ted Lemon Cc: Giyeong Son; Hui Deng; dhc WG; gen-...@ietf.org; mif; ietf@ietf.org; black_da...@emc.com Subject: Re: [dhcwg] [mif] Gen-ART review of draft-ietf-dhc-container-00 Yup ... there is currently no way to provide authenticated, meaningful identification of the network(s) to which a host is attached. Without that identification, it's pretty hard to write any reasonable policies. - Ralph On Apr 16, 2009, at 1:26 PM 4/16/09, Ted Lemon wrote: On 2009/4/13 Ralph Droms rdr...@cisco.com wrote: For example, would a host process information received from a Starbucks network over its 802.11 interface differently from information received a home network over the 802.11 interface? It's even more fun than that. How do we reliably know that we are at Starbucks, and not at home? The SSID? That's not an authenticated token. Currently Windows makes security decisions based on the SSID. You could call this the best answer they could come up with for a problem with no good answers. Or you could say that it instills the user with a false sense of security. Either way, it's not something I'd be comfortable seeing in a protocol spec, so if the client is in fact to make decisions as you've suggested, we'd need a secure way of doing this. I don't know enough about WPA Enterprise to know if there's a bidirectional authentication going on there - from the UI perspective it looks like it's one-way. - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [dhcwg] Gen-ART review of draft-ietf-dhc-container-00
And you talked about Stuart Cheshire described a couple of IETFs ago, Could you help to point out the link? Sadly, I don't have it, but I suspect Stuart does, and I'm pretty sure he's reading this. Thanks, let's see whether he is going to talk here. The gist of what he was saying is that if you have an IPv4 address that looks okay, and an IPv6 address that looks okay, you can't assume that they *are* okay, because there may be no route to the global internet on either your IPv4 or your IPv6 link. So you must attempt to use both addresses, not just one, and you must do it at the same time. Whichever one answers first, you take. It means that the new IP model will try host's multiple connections each time as you suggested as well. If you prefer either IPv4 or IPv6, and the transport you preferred happens to be the one that was broken, a smart user will disable the one you've preferred. That user will then advise his or her friends, for example, that IPv6 creates instability, so you should disable it. This impedes deployment. The unattended multiple interface situation is quite similar. I think the attended case (a laptop with two or more network interfaces) is actually better handled through user intervention, because the user has knowledge of the physical situation that would be difficult to communicate to the computer. But in the unattended case, you can get into the same sort of wrong learning situation, where a smart but naive user who debugs a network problem winds up learning a workaround that would impede interoperability if everybody did it. Interesting thoughing, workaround will impede deployment. Thanks -Hui ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00
I guess routable in mif mostly talking about there exist at least two routing entry,(it doesn't matter whether it is the default router) and both of them support one specific destination. In that case, at least one routing entry will not work, it means not routable. -Hui 2009/4/15 Giyeong Son g...@rim.com: I agree on Hui's and Ralpha's thoughts. There may be a necessary or worthy study that identifies and classifies what kind of information or network characteristics of/from the interfaces are necessary and helpful in order to judge active and valid routable interfaces for the destination (I am not sure the meaning and scope of routable with a destination in terms of MIF though) and determine an efficient/best one among them for the destination endpoint for the moment. Giyeong -Original Message- From: mif-boun...@ietf.org [mailto:mif-boun...@ietf.org] On Behalf Of Hui Deng Sent: April 13, 2009 11:24 AM To: Ralph Droms Cc: mif; ietf@ietf.org; gen-...@ietf.org; black_da...@emc.com; dhc WG Subject: Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 Hi, Ralph, I agree what you said here, Scott raised the possible issue how to differentiate the source. One instant thinking about the two different 802.11 interface is that the principal source policy selection will not be able to tell the diffference, we could allow high level policy to recommend how to handle it, give a example, we may prioritize some wifi apn policy, and make others as just a category of normal wifi. Anyhow, those thing need to be further studied based on the current practice. Thanks for the discussion. -Hui 2009/4/13 Ralph Droms rdr...@cisco.com: Hui - I think there is an issue for hosts with multiple interfaces triggered by Scott's comments about the container option: even if a host is physically aware that it has multiple interfaces, how does it take the characteristics of the networks behind those interfaces into account when it merges information? For example, would a host process information received from a Starbucks network over its 802.11 interface differently from information received a home network over the 802.11 interface? - Ralph On Apr 12, 2009, at 2:34 AM 4/12/09, Hui Deng wrote: Hi, Scott, Based on the current MIF charter proposal, it consider only host. http://www.ietf.org/mail-archive/web/mif/current/msg00367.html I am wondering whether RG is a kind of host? Anyhow, this discussion benefit MIF for the future consideration how to identify the source. Many thanks -Hui 2009/4/11 Scott Brim s...@employees.org: Excerpts from Ralph Droms on Fri, Apr 10, 2009 03:25:49PM -0400: Scott raises an interesting point about identifying the source of options when delivered to clients. BTW, Scott - what is DHS? Sorry, DHCP server The usual case - almost the only case today - is that there is a single upstream service provider and a single source of DHCP options to be passed along to the client. In this scenario, there's no need to pass along any information identifying the source of the options. To allow for a multihomed subscriber network, I can imagine adding a tag that would be passed along with the options so the subscriber client can identify the source of each option. But, what would the client do with that information? How would the client interpret it? What is the syntax and semantics of the tagging? Taken a step farther, sourcing information might be required even if there is no intermediate RG and the contained option is not in use. How does a device with multiple interfaces make policy decisions about information received on those multiple interfaces (which is pretty much the question Scott asks about the container option)? - Ralph Well put. It all comes down to where information is going to be merged. The case where a single RG client connected to multiple SP servers is essentially already covered by MIF/6man, they just need to document it. If the information is merged at the RG server, then the RG server should somehow know which interface which DHCP information came from. If all of the information is transparently passed to the consumer device, then it needs the tags as well. I don't know how the information could be usefully tagged -- the SP server's IP address doesn't sound like a good idea. The WG should decide if tagging should be included in the container syntax or added later (but documented now as needing study). I'm CCing MIF in case people there aren't on the ietf list. Thanks ... Scott On Apr 7, 2009, at 2:25 PM 4/7/09, Scott Brim wrote: I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-dhc-container
Re: [dhcwg] Gen-ART review of draft-ietf-dhc-container-00
Hi, Ted, Excuse me for my late comment, I try to catch this thread. For the case of the device has two interfaces which originate query. Your suggestion looks quite interesting: try every plausible way. I guess this is interesting topic in MIF future work. And you talked about Stuart Cheshire described a couple of IETFs ago, Could you help to point out the link? many thanks -Hui 2009/4/15 Ted Lemon ted.le...@nominum.com: On Apr 14, 2009, at 3:31 AM, Ralph Droms wrote: Now, I admit I'm describing a hypothetical and abstract scenario. I don't have a specific example of a situation in which a host might make decisions - either in the stack or in an application or ??? - about outbound traffic based on knowledge of how that traffic would be forwarded by the RG. That's right. But I think it's not an accident that this is a hypothetical scenario. In reality, a scenario like this has been likely ever since wireless and wired network interfaces became standard on laptops. And yet we don't have any real-life examples of problems that this has caused, which need solving. To me, that seems like an indication that this is not a real operational problem. That is, that the answer if two DHCP servers send the same client conflicting information on two different interfaces, that is a misconfiguration, and should be solved by correcting the misconfiguration is, in practice, the correct answer. If it were not, we would be hearing about concrete, real-world scenarios of the type you describe, not about hypothetical ones. I don't mean to minimize this issue - if in fact there is some future real-world scenario where this would be a serious problem, it would be good if we could anticipate it. It might be profitable to consider analogies. For instance, right now I have IPv6 set up at home. Because IPv6 isn't deployed at all in Tucson, the way I have this working is by tunneling. Since there are two tunnel brokers offering service for people like me, and I am a bit adventurous, I have two tunnels. Right now, every IPv6 packet I ever transmit goes out one of those tunnels, with the exception of packets destined for a specific net, for which I have defined a static route. First of all, this scenario works just fine. Both tunnels are configured as a default route - it just happens that Linux's route selection process always chooses the first one. This algorithm would work poorly if one interface were preferable to the other, but since both are equivalent it's not a problem. Second, though, why do I have a default route configured? It's because I'm talking to a node on that network that will only answer if I use the source address of one of the tunnels; and will ignore any packets I send it with the other source address. So in the case where there was a problem, I manually configured a workaround. How could we automatically solve this problem? Simple: any time we are initiating communication with a device on the network, and do not know that the communication is going to work, we simultaneously start the communication in every plausible way. So suppose that there are two records corresponding to the machine I want to talk to, and I have two global IP addresses. I'm going to send four syn packets. The first syn-ack I get back is the one I'm actually going to use - I'll send RST packets to the other three. This is analogous to the solution Stuart Cheshire described a couple of IETFs ago to the problem of IPv6 causing connectivity problems instead of expanding connectivity opportunities - you can't prefer one solution over the other, because you have no basis for doing so, so you have to try all possible solutions and choose the one that works best. My only extension, if it is one, is that I've added the source address to the matrix - I'm not sure Stuart mentioned that. Now, how does this extend when we go to DHCP? Suppose I have DNS resolver configurations from two DHCP servers. I try both in parallel. I can winnow it down a bit: since I received the DNS server information from one DHCP server on one interface, and the DNS server information from the other DHCP server on a different interface, I only have to try to query the DNS server using the source addresses of the interface on which that DNS server's configuration information was received. But how do I do that if the device that has two interfaces is not the device originating the query, as is the case with the container option? I think the answer is that I can't. There is no heuristic that I can define that will always make the right choice, because the device receiving the container options has to make the choice for the client. In DHCPv6, we could at least give the client a hint about what to do as follows: Suppose that I am dual-homed. I ask for, and get, a container option on both outward-facing interfaces. I also wind up configuring one
Re: WG Review: Multiple InterFaces (mif)
Hi, Jari and all It will be good to include that scenario, that scenario already exist and haven't been covered by other working group at the moment. Starting from changeing the working group full name looks like a feasible way. please check comments inline started with == 2009/4/18 Jari Arkko jari.ar...@piuha.net: I wanted to bring up a comment that was raised during the IESG and IAB discussions about this charter by Adrian and others. When the work started, it was clearly about multiple interfaces. Upon closer inspection, we have realized that the overall problem is somewhat larger. Problems that occur with multiple interfaces also occur even with one interface, when you have a number of default routers on the same link. The current charter text reflects this in some parts of the text, e.g., Many hosts have the ability to connect to multiple networks simultaneously. This can happen over multiple physical network interfaces, a combination of physical and virtual interfaces (VPNs or tunnels), or even through multiple default routers being on the same link. == resolving the issue of multiple default routers in multiple interfaces doesn't really solve the issue of multiple default routers in one single interface. However, it was pointed out that the text is not consistent. Other parts still talk about multiple interfaces, e.g., A number of operating systems have implemented various techniques to deal with multiple interfaces. Some devices employ only one interface at a time and some allow per-host configuration of preferences between the interfaces but still use just one at a time. Other systems allow per-application preferences or implement sophisticated policy managers that can be configured by users or controlled externally. The purpose of the MIF working group is to describe the issues surrounding the use of multiple interfaces on hosts, document existing practice, and make recommendations about best current practice. This has created some confusion with regards to what really is in scope. Are hosts with multiple physical interfaces in scope (obviously yes)? Are hosts with multiple virtual or physical interfaces in scope (yes)? Are hosts with one interface but multiple connections to different networks in scope (I think they should be)? Are we only talking about multiple interfaces or connections when they are to different administrative domains (I do not think it really matters, even in one domain the parameters can be different)? == I agree that hosts with one interface but multiple connections to different networks in scope. This has been the scenarios of many mobile network. I also agree that not necessarily mention whether it is the same or different administrative domains. I would like to solicit suggestions on how to modify the text to be fully aligned. Note: we need to keep the name of the group the same, as it something that is already familiar to people, not to mention the fact that the IETF database system does not allow an acronym change very easily. Would it be enough to change s/multiple interfaces/connections to multiple networks/ in the second quoted text excerpt? == changing the full name is the good way. then charter could be modified correspondense. The purpose of the MIF working group is to describe the issues of connecting to multiple networks on hosts, document existing practice, and make recommendations about best current practice. Thanks, -Hui Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [dhcwg] Gen-ART review of draft-ietf-dhc-container-00
Hi, Ralph, I agree what you said here, Scott raised the possible issue how to differentiate the source. One instant thinking about the two different 802.11 interface is that the principal source policy selection will not be able to tell the diffference, we could allow high level policy to recommend how to handle it, give a example, we may prioritize some wifi apn policy, and make others as just a category of normal wifi. Anyhow, those thing need to be further studied based on the current practice. Thanks for the discussion. -Hui 2009/4/13 Ralph Droms rdr...@cisco.com: Hui - I think there is an issue for hosts with multiple interfaces triggered by Scott's comments about the container option: even if a host is physically aware that it has multiple interfaces, how does it take the characteristics of the networks behind those interfaces into account when it merges information? For example, would a host process information received from a Starbucks network over its 802.11 interface differently from information received a home network over the 802.11 interface? - Ralph On Apr 12, 2009, at 2:34 AM 4/12/09, Hui Deng wrote: Hi, Scott, Based on the current MIF charter proposal, it consider only host. http://www.ietf.org/mail-archive/web/mif/current/msg00367.html I am wondering whether RG is a kind of host? Anyhow, this discussion benefit MIF for the future consideration how to identify the source. Many thanks -Hui 2009/4/11 Scott Brim s...@employees.org: Excerpts from Ralph Droms on Fri, Apr 10, 2009 03:25:49PM -0400: Scott raises an interesting point about identifying the source of options when delivered to clients. BTW, Scott - what is DHS? Sorry, DHCP server The usual case - almost the only case today - is that there is a single upstream service provider and a single source of DHCP options to be passed along to the client. In this scenario, there's no need to pass along any information identifying the source of the options. To allow for a multihomed subscriber network, I can imagine adding a tag that would be passed along with the options so the subscriber client can identify the source of each option. But, what would the client do with that information? How would the client interpret it? What is the syntax and semantics of the tagging? Taken a step farther, sourcing information might be required even if there is no intermediate RG and the contained option is not in use. How does a device with multiple interfaces make policy decisions about information received on those multiple interfaces (which is pretty much the question Scott asks about the container option)? - Ralph Well put. It all comes down to where information is going to be merged. The case where a single RG client connected to multiple SP servers is essentially already covered by MIF/6man, they just need to document it. If the information is merged at the RG server, then the RG server should somehow know which interface which DHCP information came from. If all of the information is transparently passed to the consumer device, then it needs the tags as well. I don't know how the information could be usefully tagged -- the SP server's IP address doesn't sound like a good idea. The WG should decide if tagging should be included in the container syntax or added later (but documented now as needing study). I'm CCing MIF in case people there aren't on the ietf list. Thanks ... Scott On Apr 7, 2009, at 2:25 PM 4/7/09, Scott Brim wrote: I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-dhc-container-00 Reviewer: Scott Brim Review Date: 7 April 2009 IESG Telechat date: 14 April 2009 Summary: This draft is on the right track but has open issues. Comments: More significant: I am concerned about multiple interface scenarios as are being discussed in MIF and 6MAN, where either the RG is multiply connected or the end device is. For a discussion of the sort of problems that lead to this concern, see (for example) notes from the MIF BOF at IETF74. - There must be a way to associate options with a particular upstream DHS they were obtained from, when the container is passed to the RG server and perhaps to the end device. This source information may or may not be in the container itself -- that's up to the WG to decide. If it is decided that the source information will not be part of the container syntax, at least the fact that it is necessary should be documented for people who ultimately do specify how container options are passed. - The SP server may have its ideas of how a consumer device should be configured, but it is not appropriate to say
Re: [dhcwg] Gen-ART review of draft-ietf-dhc-container-00
Hi, Scott, Based on the current MIF charter proposal, it consider only host. http://www.ietf.org/mail-archive/web/mif/current/msg00367.html I am wondering whether RG is a kind of host? Anyhow, this discussion benefit MIF for the future consideration how to identify the source. Many thanks -Hui 2009/4/11 Scott Brim s...@employees.org: Excerpts from Ralph Droms on Fri, Apr 10, 2009 03:25:49PM -0400: Scott raises an interesting point about identifying the source of options when delivered to clients. BTW, Scott - what is DHS? Sorry, DHCP server The usual case - almost the only case today - is that there is a single upstream service provider and a single source of DHCP options to be passed along to the client. In this scenario, there's no need to pass along any information identifying the source of the options. To allow for a multihomed subscriber network, I can imagine adding a tag that would be passed along with the options so the subscriber client can identify the source of each option. But, what would the client do with that information? How would the client interpret it? What is the syntax and semantics of the tagging? Taken a step farther, sourcing information might be required even if there is no intermediate RG and the contained option is not in use. How does a device with multiple interfaces make policy decisions about information received on those multiple interfaces (which is pretty much the question Scott asks about the container option)? - Ralph Well put. It all comes down to where information is going to be merged. The case where a single RG client connected to multiple SP servers is essentially already covered by MIF/6man, they just need to document it. If the information is merged at the RG server, then the RG server should somehow know which interface which DHCP information came from. If all of the information is transparently passed to the consumer device, then it needs the tags as well. I don't know how the information could be usefully tagged -- the SP server's IP address doesn't sound like a good idea. The WG should decide if tagging should be included in the container syntax or added later (but documented now as needing study). I'm CCing MIF in case people there aren't on the ietf list. Thanks ... Scott On Apr 7, 2009, at 2:25 PM 4/7/09, Scott Brim wrote: I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-dhc-container-00 Reviewer: Scott Brim Review Date: 7 April 2009 IESG Telechat date: 14 April 2009 Summary: This draft is on the right track but has open issues. Comments: More significant: I am concerned about multiple interface scenarios as are being discussed in MIF and 6MAN, where either the RG is multiply connected or the end device is. For a discussion of the sort of problems that lead to this concern, see (for example) notes from the MIF BOF at IETF74. - There must be a way to associate options with a particular upstream DHS they were obtained from, when the container is passed to the RG server and perhaps to the end device. This source information may or may not be in the container itself -- that's up to the WG to decide. If it is decided that the source information will not be part of the container syntax, at least the fact that it is necessary should be documented for people who ultimately do specify how container options are passed. - The SP server may have its ideas of how a consumer device should be configured, but it is not appropriate to say that the SP server MUST be able to control which DHCP options are transmitted to the consumer device. The RG server may need to make decisions about information from multiple DHCP servers. Perhaps you could say that the SP server MUST be able to provide information to the RG server. Less significant: 5.1 and 5.2 Alignment between the v4 and v6 descriptions would be better. The v4 description has code in the diagram and says that code is OPTION_CONTAINER_V4. The v6 description has OPTION_CONTAINER_V6 in the diagram and says that option-code is OPTION_CONTAINER_V6. ___ dhcwg mailing list dh...@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNS/IP
May I chime in, I feel identity type is a good idea. But if you map DNS to other identity, how network socket connection could work in that case/ thanks for your consideration -Hui 2009/1/12 Toni Stoev i...@tonistoev.info On Monday 12 January 2009 00:51:24 TSG sent: Toni Stoev wrote: Hi, DNS job When a connection to a network node is to be initiated its DNS name is resolved to an IP address which shows the location of the node on the network. So network nodes are findable by name even if their locations change. I think you are backwards... The nodes are still reachable if they change their physical location or the assigned networks addresses temporarily mapped too those names by DNS or DHCP. Findable, not reachable, even just identifiable, is what is essential for the naming system DNS. The job of the DNS is to identify a node by its name. Another job is to maintain information about node's current location so a new connection can be started at any time. Hmm... I think the job of DNS is to map the 'text based system names' to a network address that the routing infrastructure and features can create a set of pathways for that data to reach said system. The job of the Domain Name System, not routing or delivery system, is to map names to identity. Furthermore, identity mapped to may be of entire routing domains, aggregating nodes. Why should DNS be bothered with connectivity and/or topology status? There must be a distinct mechanism to handle mapping of node identity to network location. GeoPriv would have you believe that another Still network location is disticnt from geographic. I suggest that there be a networking asset, an address type, that represents network identity of nodes. And addresses of that type be resolved to by DNS name queries and be mapping to unicast network addresses. This way DNS shall be unburdened of connectivity, routing and reachability issues related to named nodes. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
The Internet architecture - pointer to MIF (Multiple Interfaces) discussion
Hello,all We have setup an mailing list to discuss the host which would like to use multiple interfaces. several issues has been identified based on problem statement. http://www.ietf.org/internet-drafts/draft-blanchet-mif-problem-statement-00.txt Please be awared that it is different from multihoming (site with multiple interfaces). Please feel free to join our discussion over there, https://www.ietf.org/mailman/listinfo/mif thanks -Hui ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
