Input about possible reclassification of COPS-PR and SPPI to Historic
The OPSAWG discusses a proposal to reclassify COPS-PR and SPPI to Historic, based on an I-D authored by Juergen Schoenwaelder - http://www.ietf.org/id/draft-schoenw-opsawg-copspr-historic-01.txt . Any input about implementation and deployments of COPS-PR, SPPI and PIB modules should be sent to ops...@ietf.org. Dan ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Application referrals - GROBJ
(Please send replies to gr...@ietf.org) Today's applications usually exchange an IP address and a TCP (or UDP) port for referrals. While this works in a wide variety of situations, it has been shown insufficient with more complex networks that consist of different address realms (due to IPv4 NATs and IPv6 ULAs), different address families (IPv4 and IPv6) and new transport protocols (such as SCTP). Some applications have pursued their own mechanisms to extend their referral mechanism (e.g., draft-ietf-mmusic-ice). It is important to provide guidance to applications and network devices so that referrals can work between two applications. Such guidance is important today, and will be more important as networks become more complex with common deployments of host and network multi-homing, tunnels, VPNs, and address family translators. The mailing list GROBJ has been created to discuss Generic Referral Objects (GRO) for application referrals. Interested parties can join the mailing list at https://www.ietf.org/mailman/listinfo/grobj Draft: http://tools.ietf.org/html/draft-carpenter-behave-referral-object BoF proposal: http://www.cs.auckland.ac.nz/~brian/GROBJ-BOF.txt -d ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer
-Original Message- From: Simon Josefsson [mailto:si...@josefsson.org] Sent: Tuesday, September 29, 2009 10:20 PM To: Joseph Salowey (jsalowey) Cc: Michael D'Errico; martin@sap.com; ietf@ietf.org; t...@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer Joseph Salowey (jsalowey) jsalo...@cisco.com writes: It seems that this is really up to the application. Both server names are authenticated under the same session. It seems an application server may require them to be the same or allow them to be different. I would agree if the draft wouldn't prevent clients from requesting a different server name at the application layer: negotiated in the application protocol. If the server_name is established in the TLS session handshake, the client SHOULD NOT attempt to request a different server name at the application layer. At least that is how I read it. [Joe] Good point, however I still think it is application protocol that needs to enforce the matching if it cares. Perhaps we can add some text that states Since it is possible for a client to present a different server_name in the application protocol, application server implementators should take this into account and take appropriate action to avoid introducing security vulnerabilities if the names do not match. Peter's text also included the possibility of server name change during a renegotiation handshake, do you think we should include this consideration here as well? /Simon -Original Message- From: tls-boun...@ietf.org [mailto:tls-boun...@ietf.org] On Behalf Of Michael D'Errico Sent: Tuesday, September 29, 2009 4:48 PM To: martin@sap.com Cc: si...@josefsson.org; ietf@ietf.org; t...@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer I do not see why you consider this a vulnerability in the _server_! Because a malicious client could theoretically establish a secure connection using one server domain and then ask for pages from a different domain. If the server does not check for this, it could potentially leak sensitive information. You're barking up the wrong tree. If the client did not use TLS, the server wouldn't even know that. You must be talking about a particular server implementation that has this shortcomings. There is nothing inherent in TLS that prevents a server from knowing when it is used. Your library and/ or use of that library is the problem. It is inappropriate to assume that virtual hosting provides seperation of content and draw a conclusion that, when accesses via HTTPS, will provide a secure seperation of content instead. I'm not assuming anything; I have written a TLS library and an HTTP server that provides the separation of content that you deny is possible. If the lack of such a server-side check is a problem for your server, then your server problably has a severe design flaw in its session management. I never said my server suffered from this problem And I'm curious: why do you call matching the commonName weak? Because in the vast majority of situatins it is the last step in a long row of flawed assumptions. OK, so you are complaining about the entirety of e-commerce on the web. Do you have any proposed solutions to these problems? Mike Security is only as strong as its weakest link. The authentication process based on a DNSName involves a number of very weak authentications. DNS domain names are not very genuine, and it is very non-obvious which domain names are used by the business or peer someone is looking for and which are used by others (different businesses with the same name, cybersquatters or attackers). Most HTTPS-URLs opened by Web Browsers are served through plaintext HTTP pages. Then most Browser PKIs come with a hundred or more trusted CAs preconfigured, and browsers trust them equally. Whether or how secure the authentication is that the CA performs before issuing a certificate is another flawed assumption that weakens the rfc-2818 server endpoint authentication. A final flaw that is still present in most browsers is the lack of memory. Not memorizing the certificate that a server presented on the last contact perpetuates the weakness of the original authentication. Personally, I think that deriving a server endpoint identifier from a network address is the most flawed assumption of all. That is like asserting that if someone opens on a random door on which you knock, and shows you an ID card with the correct street address -- then he must be a GOOD guy. -Martin ___ TLS mailing list t...@ietf.org
Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/30/09 10:45 AM, Joseph Salowey (jsalowey) wrote: -Original Message- From: Simon Josefsson [mailto:si...@josefsson.org] Sent: Tuesday, September 29, 2009 10:20 PM To: Joseph Salowey (jsalowey) Cc: Michael D'Errico; martin@sap.com; ietf@ietf.org; t...@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer Joseph Salowey (jsalowey) jsalo...@cisco.com writes: It seems that this is really up to the application. Both server names are authenticated under the same session. It seems an application server may require them to be the same or allow them to be different. I would agree if the draft wouldn't prevent clients from requesting a different server name at the application layer: negotiated in the application protocol. If the server_name is established in the TLS session handshake, the client SHOULD NOT attempt to request a different server name at the application layer. At least that is how I read it. [Joe] Good point, however I still think it is application protocol that needs to enforce the matching if it cares. Perhaps we can add some text that states Since it is possible for a client to present a different server_name in the application protocol, application server implementators should take this into account and take appropriate action to avoid introducing security vulnerabilities if the names do not match. I think that text is helpful. Overall, however, I wonder if this is something that truly belongs in rfc4366bis or if it is more appropriate to define a set of best practices for application protocols that use TLS. A group of folks in the Apps Area has started to do that here: http://tools.ietf.org/html/draft-saintandre-tls-server-id-check It can't hurt to place a brief warning in the core TLS spec, though. Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrDjI4ACgkQNL8k5A2w/vxLJwCgq4KOjJg17NEY0YpvNG2AL2yu 9HYAn3mYXXYY68hQmh+mJ8NxIsZ5XRMa =GdPy -END PGP SIGNATURE- ___ 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
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: 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 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
RE: [DISCUSS + Gen-ART] Review of draft-ietf-mext-binding-revocation-10
Hello All, We have submitted a new revision (13) of the Binding Revocation draft which addresses all comments including Ben and Ralph outstanding ones. In summary, we did the following: 1. After some discussion, we removed the Acknowledge (A) bit but maintained the same logic. 2. We also simplified the structure of the document to eliminate duplication and moved all common text under The Initiator and Responder sections. 3. For simplification, added new terminology: Initiator and Responder. 4. Defined a new Error Code Proxy Binding Revocation NOT Supported to allow the mobile node to reject a BRI with the (P) bit is set. Please take a look and let us know if you still have any comments or you are satisfied with the way your comments have been addressed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-binding-revocation-1 3.txt Many thanks in advance! Regards, Ahmad -Original Message- From: Muhanna, Ahmad (RICH1:2H10) Sent: Wednesday, September 16, 2009 5:34 PM To: 'Ben Campbell' Cc: Khalil, Mohamed (RICH2:2S20); sgund...@cisco.com; pyeg...@juniper.net; General Area Review Team; ietf@ietf.org; Jari Arkko; marc...@it.uc3m.es; Laganier, Julien Subject: RE: Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10 Hi Ben, Not at all. I just thought that would work better for you. But, I am okay with keeping the text and adding the note. Regards, Ahmad -Original Message- From: Ben Campbell [mailto:b...@estacado.net] Sent: Wednesday, September 16, 2009 5:32 PM To: Muhanna, Ahmad (RICH1:2H10) Cc: Khalil, Mohamed (RICH2:2S20); sgund...@cisco.com; pyeg...@juniper.net; General Area Review Team; ietf@ietf.org; Jari Arkko; marc...@it.uc3m.es; Laganier, Julien Subject: Re: Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10 Hi Ahmad, I guess that's okay since the removed text talks about behavior under an error condition anyway, so I won't object further if you do it this way. But I actually prefer the old text with the warning about retransmissions. My concern is, the proposal below simply leaves the case of A being set but having no matching binding undefined. I think that makes implementors even more likely to decide not to send a BRA in that case. Is the warning about retransmissions causing concern? On Sep 16, 2009, at 5:19 PM, Ahmad Muhanna wrote: Hello Ben, Thinking about this a little more, I think that you also would accept if we remove the text causing grief all together:) In other words, what about if we reword the text as below: OLD TEXT: = o If the Acknowledge (A) bit is set in the Binding Revocation Indication and its Binding Update List contains an entry for the IP address in the Type 2 routing header, the mobile node MUST send a Binding Revocation Acknowledgement. However, in all other cases when the Acknowledge (A) bit is set in the BRI, the mobile node SHOULD sends a Binding Revocation Acknowledgement, the mobile node MUST do so according to Section 10.2. NEW TEXT: = o If the Acknowledge (A) bit is set in the Binding Revocation Indication and its Binding Update List contains an entry for the IP address in the Type 2 routing header, the mobile node MUST send a Binding Revocation Acknowledgement. This way we do not need to add the clarification note. What do you think? Please let me know and many thanks again! Regards, Ahmad -Original Message- From: Muhanna, Ahmad (RICH1:2H10) Sent: Monday, September 14, 2009 2:06 PM To: 'Ben Campbell' Cc: Khalil, Mohamed (RICH2:2S20); sgund...@cisco.com; pyeg...@juniper.net; General Area Review Team; ietf@ietf.org; Jari Arkko; marc...@it.uc3m.es; Laganier, Julien Subject: RE: Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10 Hi Ben, I am fine with your proposed text. Many thanks for your review and comments. Regards, Ahmad -Original Message- From: Ben Campbell [mailto:b...@estacado.net] Sent: Monday, September 14, 2009 2:02 PM To: Muhanna, Ahmad (RICH1:2H10) Cc: Khalil, Mohamed (RICH2:2S20); sgund...@cisco.com; pyeg...@juniper.net; General Area Review Team; ietf@ietf.org; Jari Arkko; marc...@it.uc3m.es; Laganier, Julien Subject: Re: Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10 Hi Ahmad, Please see inline for my suggested text for the retransmission issue. Otherwise, I agree this closes the open issues. Thanks! Ben. On Sep 12, 2009, at 3:23 AM, Ahmad Muhanna wrote: Hi Ben, Hopefully we can close on all of the open issues. Please see inline. Regards, Ahmad
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: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer
Michael D'Errico wrote: I do not see why you consider this a vulnerability in the _server_! Because a malicious client could theoretically establish a secure connection using one server domain and then ask for pages from a different domain. If the server does not check for this, it could potentially leak sensitive information. You're barking up the wrong tree. If the client did not use TLS, the server wouldn't even know that. It is inappropriate to assume that virtual hosting provides seperation of content and draw a conclusion that, when accesses via HTTPS, will provide a secure seperation of content instead. If the lack of such a server-side check is a problem for your server, then your server problably has a severe design flaw in its session management. And I'm curious: why do you call matching the commonName weak? Because in the vast majority of situatins it is the last step in a long row of flawed assumptions. Security is only as strong as its weakest link. The authentication process based on a DNSName involves a number of very weak authentications. DNS domain names are not very genuine, and it is very non-obvious which domain names are used by the business or peer someone is looking for and which are used by others (different businesses with the same name, cybersquatters or attackers). Most HTTPS-URLs opened by Web Browsers are served through plaintext HTTP pages. Then most Browser PKIs come with a hundred or more trusted CAs preconfigured, and browsers trust them equally. Whether or how secure the authentication is that the CA performs before issuing a certificate is another flawed assumption that weakens the rfc-2818 server endpoint authentication. A final flaw that is still present in most browsers is the lack of memory. Not memorizing the certificate that a server presented on the last contact perpetuates the weakness of the original authentication. Personally, I think that deriving a server endpoint identifier from a network address is the most flawed assumption of all. That is like asserting that if someone opens on a random door on which you knock, and shows you an ID card with the correct street address -- then he must be a GOOD guy. -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer
I do not see why you consider this a vulnerability in the _server_! Because a malicious client could theoretically establish a secure connection using one server domain and then ask for pages from a different domain. If the server does not check for this, it could potentially leak sensitive information. You're barking up the wrong tree. If the client did not use TLS, the server wouldn't even know that. You must be talking about a particular server implementation that has this shortcomings. There is nothing inherent in TLS that prevents a server from knowing when it is used. Your library and/ or use of that library is the problem. It is inappropriate to assume that virtual hosting provides seperation of content and draw a conclusion that, when accesses via HTTPS, will provide a secure seperation of content instead. I'm not assuming anything; I have written a TLS library and an HTTP server that provides the separation of content that you deny is possible. If the lack of such a server-side check is a problem for your server, then your server problably has a severe design flaw in its session management. I never said my server suffered from this problem And I'm curious: why do you call matching the commonName weak? Because in the vast majority of situatins it is the last step in a long row of flawed assumptions. OK, so you are complaining about the entirety of e-commerce on the web. Do you have any proposed solutions to these problems? Mike Security is only as strong as its weakest link. The authentication process based on a DNSName involves a number of very weak authentications. DNS domain names are not very genuine, and it is very non-obvious which domain names are used by the business or peer someone is looking for and which are used by others (different businesses with the same name, cybersquatters or attackers). Most HTTPS-URLs opened by Web Browsers are served through plaintext HTTP pages. Then most Browser PKIs come with a hundred or more trusted CAs preconfigured, and browsers trust them equally. Whether or how secure the authentication is that the CA performs before issuing a certificate is another flawed assumption that weakens the rfc-2818 server endpoint authentication. A final flaw that is still present in most browsers is the lack of memory. Not memorizing the certificate that a server presented on the last contact perpetuates the weakness of the original authentication. Personally, I think that deriving a server endpoint identifier from a network address is the most flawed assumption of all. That is like asserting that if someone opens on a random door on which you knock, and shows you an ID card with the correct street address -- then he must be a GOOD guy. -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer
I think this text is helpful and does belong to RFC 4366bis. TLS is a tool. This is a piece of information how to avoid a pitfall when using this tool. Which does not preclude from writing a lengthier document - a guide for application developers. On 9/30/09 12:51 , Peter Saint-Andre stpe...@stpeter.im wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/30/09 10:45 AM, Joseph Salowey (jsalowey) wrote: -Original Message- From: Simon Josefsson [mailto:si...@josefsson.org] Sent: Tuesday, September 29, 2009 10:20 PM To: Joseph Salowey (jsalowey) Cc: Michael D'Errico; martin@sap.com; ietf@ietf.org; t...@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer Joseph Salowey (jsalowey) jsalo...@cisco.com writes: It seems that this is really up to the application. Both server names are authenticated under the same session. It seems an application server may require them to be the same or allow them to be different. I would agree if the draft wouldn't prevent clients from requesting a different server name at the application layer: negotiated in the application protocol. If the server_name is established in the TLS session handshake, the client SHOULD NOT attempt to request a different server name at the application layer. At least that is how I read it. [Joe] Good point, however I still think it is application protocol that needs to enforce the matching if it cares. Perhaps we can add some text that states Since it is possible for a client to present a different server_name in the application protocol, application server implementators should take this into account and take appropriate action to avoid introducing security vulnerabilities if the names do not match. I think that text is helpful. Overall, however, I wonder if this is something that truly belongs in rfc4366bis or if it is more appropriate to define a set of best practices for application protocols that use TLS. A group of folks in the Apps Area has started to do that here: http://tools.ietf.org/html/draft-saintandre-tls-server-id-check It can't hurt to place a brief warning in the core TLS spec, though. Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrDjI4ACgkQNL8k5A2w/vxLJwCgq4KOjJg17NEY0YpvNG2AL2yu 9HYAn3mYXXYY68hQmh+mJ8NxIsZ5XRMa =GdPy -END PGP SIGNATURE- ___ TLS mailing list t...@ietf.org https://www.ietf.org/mailman/listinfo/tls -- Regards, Uri u...@ll.mit.edu Disclaimer ___ 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
Hui Deng's statement (below) is the most important I have read on the issue of a meeting in China. Re-read the Tao. The IETF is about building, developing, contributing to an Internet available to all. It is people, not governments. If you, personally, are afraid of China, I recommend you go there and hold out your hand. I cannot think of a more excellent challenge to the IETF at this time than to meet in China, and meet 1,000 new friends. And to make 1,000 new friends for the IETF and for the continuation of a cooperative, open development of the Internet. Gene Gaines On Wed, Sep 30, 2009 at 11:17 AM, Hui Deng denghu...@hotmail.com wrote: 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 -- check out the rest of the Windows Live™. More than mail–Windows Live™ goes way beyond your inbox. More than messageshttp://www.microsoft.com/windows/windowslive/ ___ 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: Last Call: draft-weiler-rsync-uri (The rsync URI Scheme) to Informational RFC
Just out of curiousity, why is this registering it as provisional, rather than permanent scheme? Also, I didn't see any discussion about this on uri-review. This may be because it dropped during my recent mailbox moves, but if it hasn't been seen there it might be a reasonable idea. Support for a permanent registration might even emerge there. regards, Ted On Wed, Sep 30, 2009 at 7:31 AM, The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from an individual submitter to consider the following document: - 'The rsync URI Scheme ' draft-weiler-rsync-uri-01.txt as an Informational RFC 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 2009-10-28. 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. The file can be obtained via http://www.ietf.org/internet-drafts/draft-weiler-rsync-uri-01.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=18880rfc_flag=0 ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weiler-rsync-uri (The rsync URI Scheme) to Informational RFC
Ted: Just out of curiousity, why is this registering it as provisional, rather than permanent scheme? There is not a rsync protocol specification and URI scheme. The protocol is widely deployed. In fact the IETF depends on it everyday. This document is intended to provide a citable specification for the URL scheme, but not the protocol. Without the protocol specification, provisional seemed like the best choice based on RFC 4395. Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weiler-rsync-uri (The rsync URI Scheme) to Informational RFC
Russ, I think the point is that the IESG should probably refer the doc to the uri-review team to look for any red flags. Mistakes in URI specs are common (speaking has one that has made some). Eliot On 9/30/09 9:51 PM, Russ Housley wrote: Ted: Just out of curiousity, why is this registering it as provisional, rather than permanent scheme? There is not a rsync protocol specification and URI scheme. The protocol is widely deployed. In fact the IETF depends on it everyday. This document is intended to provide a citable specification for the URL scheme, but not the protocol. Without the protocol specification, provisional seemed like the best choice based on RFC 4395. Russ ___ 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: Last Call: draft-weiler-rsync-uri (The rsync URI Scheme) to Informational RFC
On Wed, Sep 30, 2009 at 12:51 PM, Russ Housley hous...@vigilsec.com wrote: Ted: Just out of curiousity, why is this registering it as provisional, rather than permanent scheme? There is not a rsync protocol specification and URI scheme. The protocol is widely deployed. In fact the IETF depends on it everyday. This document is intended to provide a citable specification for the URL scheme, but not the protocol. Without the protocol specification, provisional seemed like the best choice based on RFC 4395. Fair enough; thanks for the explanation. I think adding something to the IANA considerations documenting that logic couldn't hurt, e.g: A provisional registration is being sought as there is no citable rsync protocol specification at this time, despite its widespread deployment. regards, Ted Hardie ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-housley-iesg-rfc3932bis-10.txt
FWIW, this version resolves my remaining objection. Thanks Brian On 2009-10-01 11:45, internet-dra...@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IESG Procedures for Handling of Independent and IRTF Stream Submissions Author(s) : H. Alvestrand, R. Housley Filename: draft-housley-iesg-rfc3932bis-10.txt Pages : 9 Date: 2009-9-30 This document describes the procedures used by the IESG for handling documents submitted for RFC publication on the Independent and IRTF streams. This document updates procedures described in RFC 2026 and RFC 3710. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-housley-iesg-rfc3932bis-10.txt ___ 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: Last Call: draft-weiler-rsync-uri (The rsync URI Scheme) to Informational RFC
At 4:41 PM -0700 9/30/09, Ted Hardie wrote: Fair enough; thanks for the explanation. I think adding something to the IANA considerations documenting that logic couldn't hurt, e.g: A provisional registration is being sought as there is no citable rsync protocol specification at this time, despite its widespread deployment. +1 --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-ospf-af-alt (Support of address families in OSPFv3) to Proposed Standard
The IESG has received a request from the Open Shortest Path First IGP WG (ospf) to consider the following document: - 'Support of address families in OSPFv3 ' draft-ietf-ospf-af-alt-08.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 i...@ietf.org mailing lists by 2009-10-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. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ospf-af-alt-08.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=11690rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-ospf-te-node-addr (Advertising a Router's Local Addresses in OSPF TE Extensions) to Proposed Standard
The IESG has received a request from the Open Shortest Path First IGP WG (ospf) to consider the following document: - 'Advertising a Router's Local Addresses in OSPF TE Extensions ' draft-ietf-ospf-te-node-addr-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 i...@ietf.org mailing lists by 2009-10-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. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ospf-te-node-addr-06.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=11748rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-weiler-rsync-uri (The rsync URI Scheme) to Informational RFC
The IESG has received a request from an individual submitter to consider the following document: - 'The rsync URI Scheme ' draft-weiler-rsync-uri-01.txt as an Informational RFC 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 i...@ietf.org mailing lists by 2009-10-28. 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. The file can be obtained via http://www.ietf.org/internet-drafts/draft-weiler-rsync-uri-01.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=18880rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-mmusic-connectivity-precon (Connectivity Preconditions for Session Description Protocol Media Streams) to Proposed Standard
The IESG has received a request from the Multiparty Multimedia Session Control WG (mmusic) to consider the following document: - 'Connectivity Preconditions for Session Description Protocol Media Streams ' draft-ietf-mmusic-connectivity-precon-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 i...@ietf.org mailing lists by 2009-10-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. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mmusic-connectivity-precon-06.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=13114rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Baseline Encoding and Transport of Pre-Congestion Information' to Proposed Standard
The IESG has approved the following document: - 'Baseline Encoding and Transport of Pre-Congestion Information ' draft-ietf-pcn-baseline-encoding-07.txt as a Proposed Standard This document is the product of the Congestion and Pre-Congestion Notification Working Group. The IESG contact persons are Lars Eggert and Magnus Westerlund. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-baseline-encoding-07.txt Technical Summary This document specifies a baseline encoding for pre-congestion notification states in a PCN domain. The baseline encoding assumes that the ECN bits in the IP header can be used to encode two PCN states (Not-marked, PCN-marked) for packets belonging to certain Diffserv behavior aggregates. The PCN-compatible Diffserv codepoints are not specified, and are assumed to be configurable on a domain basis. It is assumed that normal ECN behavior is not available for packets within these behavior aggregates; however, the encoding allows packets in these behavior aggregates to be marked as Not-PCN. The proposed alternative semantics of the ECN bits is consistent with the rules specified in RFC 4774. Working Group Summary The proposed encoding is the product of substantial discussion within group. Personnel The document shepherd was Steven Blake (sbl...@extremenetworks.com). Lars Eggert (lars.egg...@nokia.com) reviewed the document for the IESG. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
76th IETF - Social Event
Social Event Where: Grand Prince Hotel Hiroshima When: Tuesday, November 10, 2009 Host: WIDE The Social Event will be held at the Grand Prince Hotel Hiroshima (http://www.princehotels.com/en/hiroshima/) overlooking the Seto Inland Sea. Social Event Registration is available on the IETF76 meeting site (http://www.ietf.org/meetings/76/) at a fee of 40 USD/person. Children and spouses are welcome. Participants are limited to 600 due to venue space restrictions. As such we recommend you register in advance. Transportation will be provided by bus from the ANA. Return transportation will be provided by bus from the Prince to the ANA and other IETF overflow hotels. The Social will introduce you to the cuisine, culture and hospitality of the Hiroshima area giving you an opportunity to experience making okonomiyaki (a Japanese savoury pancake containing a variety of ingredients), tasting sake from the famous Saikyo Sake Breweries (http://saijosake.com/), participating in a traditional tea ceremony and experiencing performances of several traditional Japanese performers from the local area. Note: You must be registered for IETF 76 to purchase a Social Ticket. Only 39 days until the Hiroshima IETF! Online registration for the IETF meeting is at: http://www.ietf.org/meetings/76/ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Data Structure for the Security Suitability of Cryptographic Algorithms (DSSC)' to Proposed Standard
The IESG has approved the following document: - 'Data Structure for the Security Suitability of Cryptographic Algorithms (DSSC) ' draft-ietf-ltans-dssc-12.txt as a Proposed Standard This document is the product of the Long-Term Archive and Notary Services Working Group. The IESG contact persons are Tim Polk and Pasi Eronen. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltans-dssc-12.txt Technical Summary Since cryptographic algorithms can become weak over the years, it is necessary to evaluate their security suitability. When signing or verifying data, or when encrypting or decrypting data, these evaluations must be considered. This document specifies a data structure that enables an automated analysis of the security suitability of a given cryptographic algorithm at a given point of time which may be in the past, at the present time or in the future. Working Group Summary This document is a product of the ltans working group. There was little controversy regarding this draft. There were some structural changes to the schema following an earlier working group last call but no significant comments recently. Document Quality There is one known current implementation. The implementation is part of the long-term archiving solution ArchiSoft (http://www.sit.fraunhofer.de/EN/forschungsbereich/tad/archisoft.jsp). There was another implementation of an earlier version: https://demo.pkipreserver.com/index.html. This may be updated and released as part of a related open source library: http://www.pkiframework.com/. Plans of other vendors to implement the specification are not known. There were no reviewers, Media Types or other expert reviews. Personnel Carl Wallace cwall...@cygnacom.com is the Document Shepherd for this document. The Responsible Area Director is Tim Polk. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5637 on Authentication, Authorization, and Accounting (AAA) Goals for Mobile IPv6
A new Request for Comments is now available in online RFC libraries. RFC 5637 Title: Authentication, Authorization, and Accounting (AAA) Goals for Mobile IPv6 Author: G. Giaretta, I. Guardini, E. Demaria, J. Bournelle, R. Lopez Status: Informational Date: September 2009 Mailbox:gera...@qualcomm.com, ivano.guard...@telecomitalia.it, elena.dema...@telecomitalia.it, julien.bourne...@gmail.com, r...@dif.um.es Pages: 11 Characters: 23409 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-mext-aaa-ha-goals-01.txt URL:http://www.rfc-editor.org/rfc/rfc5637.txt In commercial and enterprise deployments, Mobile IPv6 can be a service offered by a Mobility Services Provider (MSP). In this case, all protocol operations may need to be explicitly authorized and traced, requiring the interaction between Mobile IPv6 and the AAA infrastructure. Integrating the Authentication, Authorization, and Accounting (AAA) infrastructure (e.g., Network Access Server and AAA server) also offers a solution component for Mobile IPv6 bootstrapping. This document describes various scenarios where a AAA interface for Mobile IPv6 is required. Additionally, it lists design goals and requirements for such an interface. This memo provides information for the Internet community. This document is a product of the Mobility EXTensions for IPv6 Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5650 on Definitions of Managed Objects for Very High Speed Digital Subscriber Line 2 (VDSL2)
A new Request for Comments is now available in online RFC libraries. RFC 5650 Title: Definitions of Managed Objects for Very High Speed Digital Subscriber Line 2 (VDSL2) Author: M. Morgenstern, S. Baillie, U. Bonollo Status: Standards Track Date: September 2009 Mailbox:moti.morgenst...@ecitele.com, scott.bail...@nec.com.au, umberto.bono...@nec.com.au Pages: 218 Characters: 434687 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-adslmib-vdsl2-07.txt URL:http://www.rfc-editor.org/rfc/rfc5650.txt This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing parameters of the Very High Speed Digital Subscriber Line 2 (VDSL2) interface type, which are also applicable for managing Asymmetric Digital Subscriber Line (ADSL), ADSL2, and ADSL2+ interfaces. [STANDARDS TRACK] This document is a product of the ADSL MIB Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5689 on Extended MKCOL for Web Distributed Authoring and Versioning (WebDAV)
A new Request for Comments is now available in online RFC libraries. RFC 5689 Title: Extended MKCOL for Web Distributed Authoring and Versioning (WebDAV) Author: C. Daboo Status: Standards Track Date: September 2009 Mailbox:cy...@daboo.name Pages: 12 Characters: 19838 Updates:RFC4791, RFC4918 I-D Tag:draft-ietf-vcarddav-webdav-mkcol-06.txt URL:http://www.rfc-editor.org/rfc/rfc5689.txt This specification extends the Web Distributed Authoring and Versioning (WebDAV) MKCOL (Make Collection) method to allow collections of arbitrary resourcetype to be created and to allow properties to be set at the same time. [STANDARDS TRACK] This document is a product of the vCard and CardDAV Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
BCP 9, RFC 5657 on Guidance on Interoperation and Implementation Reports for Advancement to Draft Standard
A new Request for Comments is now available in online RFC libraries. BCP 9 RFC 5657 Title: Guidance on Interoperation and Implementation Reports for Advancement to Draft Standard Author: L. Dusseault, R. Sparks Status: Best Current Practice Date: September 2009 Mailbox:lisa.dussea...@gmail.com, r...@nostrum.com Pages: 12 Characters: 29327 Updates:RFC2026 See Also: BCP0009 I-D Tag:draft-dusseault-impl-reports-04.txt URL:http://www.rfc-editor.org/rfc/rfc5657.txt Advancing a protocol to Draft Standard requires documentation of the interoperation and implementation of the protocol. Historic reports have varied widely in form and level of content and there is little guidance available to new report preparers. This document updates the existing processes and provides more detail on what is appropriate in an interoperability and implementation report. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. BCP: This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
