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: Gen-ART review of draft-ietf-avtext-client-to-mixer-audio-level-05.txt
Emil Ivov wrote: Hey Alexey, Hi Emil, On 27 sept. 2011, at 00:24, Alexey Melnikov alexey.melni...@isode.com mailto:alexey.melni...@isode.com wrote: Jonathan Lennox wrote: Hi, Alexey -- thank you for the Gen-ART review. Hi Jonathan, Alexey Melnikov writes: Question: are the two encoding of the audio level indication option specified in the document really necessary? Do you mean the one-byte vs. two-byte forms of the header extension (Figure 1 vs. Figure 2)? These are the two forms of the generic header extensions defined by RFC 5285. I understood that. Does RFC 5285 require that both forms should be allowed? It doesn't explicitly say so but it It actually does, yes. Here's what it says: A stream MUST contain only one-byte or two-byte headers: they MUST NOT be mixed within a stream. Audio level headers can find themselves in streams that also have other, longer extensions, which do require the two-byte header. The above lines mandate that in such cases they all use the two-byte header. Ok, this is good enough for me. Thanks for explaining. In the same regard, although probably a bit less likely, nothing prevents having another sixteen header extensions in a stream that also has levels. In that case we'd need to switch to two-byte headers in order to be able to fit all the IDs. Cheers, Emil --sent from my mobile In general, it would be good to avoid multiple representations of the same thing. The actual payload (one byte containing the V and level bits) is identical in the two cases; the only difference is the container. We can add some text clarifying this point if you think it would be helpful. Nits/editorial comments: s/relys/relies ??? Thanks, will fix. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Need help tracking down problem accessing IETF Subversionrepository on Mac OS X
--- Original Message - From: Yoav Nir y...@checkpoint.com To: Paul Hoffman paul.hoff...@vpnc.org Cc: Stuart Cheshire chesh...@apple.com; IETF-Discussion list ietf@ietf.org Sent: Monday, September 26, 2011 10:11 PM On Sep 26, 2011, at 5:25 AM, Paul Hoffman wrote: On Sep 25, 2011, at 7:20 PM, Stuart Cheshire wrote: % svn info https://svn.tools.ietf.org/svn/wg/hybi svn: OPTIONS of 'https://svn.tools.ietf.org/svn/wg/hybi': SSL negotiation failed: SSL error code -1/1/336032856 (https://svn.tools.ietf.org) If you're on a Mac, can you please try this command for me and let me know if it works for you or gives the 336032856 error? Happens to everyone with a Mac. Someone else will chime in before we Californians wake up tomorrow saying what the problem is. Speculation on a different list was that this is a mismatch between SSL library versions with some interaction with the new TLS renegotiation fix, but I haven't seen substantiation. I guess you're awake by now, but here goes. I'm attaching a tcpdump capture. The client sends a SNI extension with the name svn.tools.ietf.org. For some reason the server does not recognize the name. This is particularly puzzling because the CommonName in the server certificate is *.tools.ietf.org, which is usually considered a match. The server tp Unfortunately, we now also have RFC6125 which encourages people to o Move away from including and checking strings that look like domain names in the subject's Common Name. in a slightly different, but closely related, context. It seems unlikely that this advice is having an impact so soon, but it is another source of potential confusion. Tom Petch sends a warning-level unrecognized name alert, and the client breaks the connection. Here's what RFC 6066 has to say on the subject: If the server understood the ClientHello extension but does not recognize the server name, the server SHOULD take one of two actions: either abort the handshake by sending a fatal-level unrecognized_name(112) alert or continue the handshake. It is NOT RECOMMENDED to send a warning-level unrecognized_name(112) alert, because the client's behavior in response to warning-level alerts is unpredictable. Unpredictable indeed. Anyway, the server is wrong to send the alert on two counts: the name does match, and the warning-level alert violates a NOT RECOMMENDED/ OTOH, the client should not abort on a warning level alert. My opinion: it's the server that is more wrong. Yoav ___ 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: Need help tracking down problem accessing IETF Subversion
On 9/27/11 12:45 AM, Martin Rex m...@sap.com wrote: So there seem to be two problems: - The server (svn.tools.ietf.org) does not seem to be sufficiently aware of the server names that it is servicing. If it takes more than a server configuration file change to make it aware of that additional hostname, then there is a software bug in the WebServer (or the TLS-implementation used by the web server). Pretty embarrassing that one of Yngve's extensions-intolerant servers would have a domain name ending in .ietf.org. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 240/4 unreservation (was RE: Last Call: draft-weil-shared-transition-space-request-03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC)
On 27 Sep 2011, at 5:45 , Christian Huitema wrote: if an address space is somehow set aside, we have no mechanism to enforce that only ISP use it. So we have to assume it will be used by whoever feels like it. How is that different from the current situation? Is there a reason why potential users of 240/4 will refrain from that use because it's called class E but not if it's called ISP private? And who cares anyway? If people feel it's a good idea to use addresses in the 240/4 block, more power to them. That saves more usable addresses for other uses. It is also important to avoid mistakes during the transition period from IPv4 to IPv6. I understand that many actors are anxious and waiting for some kind of fix. This is a common scenario for making substantial mistakes... Agree. We have to make absolutely sure that all the hacks that are going to be implemented to stretch IPv4 don't find their way into the IPv6 world. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-pim-port-08.txt (A Reliable TransportMechanism for PIM) to Experimental RFC
The choice of service name for this transport seems unfortunate; having a port number registry with a service in it called 'port' may be witty but seems like a source of future confusion. I notice that IANA currently have a service name of 'pim-port' which seems a better idea and one that I think that this I-D should adopt. Tom Petch - Original Message - From: The IESG iesg-secret...@ietf.org To: IETF-Announce ietf-annou...@ietf.org Cc: p...@ietf.org Sent: Monday, September 26, 2011 9:40 PM Subject: Last Call: draft-ietf-pim-port-08.txt (A Reliable TransportMechanism for PIM) to Experimental RFC The IESG has received a request from the Protocol Independent Multicast WG (pim) to consider the following document: - 'A Reliable Transport Mechanism for PIM' draft-ietf-pim-port-08.txt as an Experimental 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 2011-10-10. 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 This document defines a reliable transport mechanism for the PIM protocol for transmission of Join/Prune messages. This eliminates the need for periodic Join/Prune message transmission and processing. The reliable transport mechanism can use either TCP or SCTP as the transport protocol. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pim-port/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pim-port/ No IPR declarations have been submitted directly on this I-D. ___ 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: [BEHAVE] Last Call: draft-ietf-behave-v4v6-bih-06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard
-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. 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 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
RE: [BEHAVE] Last Call: draft-ietf-behave-v4v6-bih-06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard
-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). -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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Need help tracking down problem accessing IETF Subversion
On 9/27/11 12:45 AM, Martin Rex m...@sap.com wrote: - The server (svn.tools.ietf.org) does not seem to be sufficiently aware of the server names that it is servicing. If it takes more than a server configuration file change to make it aware of that additional hostname, then there is a software bug in the WebServer (or the TLS-implementation used by the web server). The server seems to be Apache 2.2.20 (see below). Usually but not always the underlying implementation is OpenSSL. I wouldn't think they are likely to be so buggy. 2-54-182-251:tmp ynir$ wget --no-check-certificate -d -v https://svn.tools.ietf.org/svn/wg/hybi/ Setting --verbose (verbose) to 1 DEBUG output created by Wget 1.13.4 on darwin10.8.0. URI encoding = `US-ASCII' --2011-09-27 17:09:19-- https://svn.tools.ietf.org/svn/wg/hybi/ Resolving svn.tools.ietf.org (svn.tools.ietf.org)... 208.66.40.242 Caching svn.tools.ietf.org = 208.66.40.242 Connecting to svn.tools.ietf.org (svn.tools.ietf.org)|208.66.40.242|:443... connected. Created socket 5. Releasing 0x00010042c6b0 (new refcount 1). WARNING: The certificate of `svn.tools.ietf.org' is not trusted. WARNING: The certificate of `svn.tools.ietf.org' hasn't got a known issuer. ---request begin--- GET /svn/wg/hybi/ HTTP/1.1 User-Agent: Wget/1.13.4 (darwin10.8.0) Accept: */* Host: svn.tools.ietf.org Connection: Keep-Alive ---request end--- HTTP request sent, awaiting response... ---response begin--- HTTP/1.1 200 OK Date: Tue, 27 Sep 2011 14:09:22 GMT Server: Apache/2.2.20 (Debian) Last-Modified: Fri, 23 Sep 2011 19:13:05 GMT ETag: W/137// Accept-Ranges: bytes Content-Length: 286 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/html; charset=UTF-8 ---response end--- 200 OK Registered socket 5 for persistent reuse. URI content encoding = `UTF-8' Length: 286 [text/html] Saving to: `index.html' 100%[== ] 286 --.-K/s in 0s 2011-09-27 17:09:26 (1.66 MB/s) - `index.html' saved [286/286] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: 240/4 unreservation (was RE: Last Call: draft-weil-shared-transition-space-request-03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC)
From: ietf-boun...@ietf.org On Behalf Of Iljitsch van Beijnum And who cares anyway? If people feel it's a good idea to use addresses in the 240/4 block, more power to them. That saves more usable addresses for other uses. WEG] The problem is that people really can't today, because vendors mostly do not want to implement something for general consumption that is deliberately out of compliance with one or more RFCs. My point in asking the question was that I'm not sure that we need to define what use cases it can/should be used for as much as we simply need to unreserve it and provide some guidance about risks. IMO, the question tree on determining what (if any) course of action to take is something like this: 1) should it be unreserved for *any* reason, or are we just going to stick with the 5735 status quo (Future use)? 2) should it be made into more global unicast space in all or in part? 3) should it be simply unreserved as non-global space with a few caveats about limitations, and leave the use cases to the consenting adults considering its use? 4) should it have a designated use(s) to the exclusion of all not explicitly defined? For #1, My view is that there's no good reason to maintain the reservation, because then essentially no one can use it, and the likelihood of someone coming up with a use for it that justifies holding it in reserve for future use continues to drop. So it's more a question of how we might use the space, and the justification for doing any one of several things. I don't agree that the burden of proof should favor doing nothing. For #2, We know that it is not trivial to get it working for this purpose due to the critical mass of support required. But in some cases where there is tight control over equipment and networks, and a community of interest that routinely communicates between one another across a portion of the Internet, perhaps it's possible. I'm thinking that this makes more sense as a means to buy us time to get IPv6 deployments completed if CGN ends up being bad and the demand for global IPv4 space gets high enough that any tradeoffs associated with using this space as global unicast are deemed acceptable. It may be that we carve the space up so that some of it is tentatively reserved for global unicast, but not released to IANA until some later point to give folks time to fix things. I agree that this one has a lot of risk that it ends up simply prolonging IPv4 without aiding the transition to IPv6. For #3, it's mainly about the caveats to its use - it may not be supported by legacy equipment, we have to carve out 255.255.255.255 (or perhaps something between 255/8 and 255.255.255/24) for broadcast, it MUST NOT show up in the global routing table, etc For #4 - I'm not sure we can come up with enough designated uses at the outset to not have to continue evaluating new ones all of the time and end up needing a WG just to keep up with the discussion. So far, we've heard about its use within a mobile provider in place of RFC1918 as Mobile UE addresses behind a CGN that's already in place today. The folks wanting a shared CGN address pool have already turned down 240/4 because of the limited support within the legacy home router CPE gear. What other potential uses are there? 1918 space in enterprises where all of 1918 is already in use (eg mergers, extranets, etc)? I think Iljitsch's point is a good one - why do we care how people use it? As long as we can give them some guidance about how *not* to use it in order to avoid breakage, I think we're doing our jobs. Wes George 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. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Need help tracking down problem accessing IETF Subversion repository on Mac OS X
Hi, Yoav's tcpdump analysis, together with Martin's observations, helped me find the problem at the server end. I've changed the config now (addding a missing 'NameVirtualHost *:443' to Apache's config), and Stuart's example now works for me on OS X Snow Leopard and Lion: svn info https://svn.tools.ietf.org/svn/wg/hybi (The box running Lion isn't happy with the certificate, though, even if all other means of verification I have tells me it's OK.) Thanks and best regards, Henrik On 2011-09-26 22:11 Yoav Nir said: The client sends a SNI extension with the name svn.tools.ietf.org. For some reason the server does not recognize the name. This is particularly puzzling because the CommonName in the server certificate is *.tools.ietf.org, which is usually considered a match. The server sends a warning-level unrecognized name alert, and the client breaks the connection. ___ 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
-Original Message- From: teemu.savolai...@nokia.com [mailto:teemu.savolai...@nokia.com] Sent: Tuesday, September 27, 2011 7:24 AM 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 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). Good point, but still in my eyes that does not count as too significant factor, as it is impossible to have a generic ALG and I've understood ALGs in CPEs are not very much desired? Yes, it is impossible to build a successful 'generic' ALG which fixes up all protocols. ALGs need to be specific to each application they're trying to 'fix'. So.. then.. is this sentence really still the IETF recommendation in the current state of affairs: -- IETF recommends using dual-stack or tunneling based solutions for IPv6 transition and specifically recommends against deployments utilizing double protocol translation. -- -d ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Gen-ART review of draft-ietf-avtext-client-to-mixer-audio-level-05.txt
Hi, Alexey -- thank you for the Gen-ART review. Alexey Melnikov writes: Question: are the two encoding of the audio level indication option specified in the document really necessary? Do you mean the one-byte vs. two-byte forms of the header extension (Figure 1 vs. Figure 2)? These are the two forms of the generic header extensions defined by RFC 5285. The actual payload (one byte containing the V and level bits) is identical in the two cases; the only difference is the container. We can add some text clarifying this point if you think it would be helpful. Nits/editorial comments: s/relys/relies ??? Thanks, will fix. -- Jonathan Lennox jonat...@vidyo.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART review of draft-ietf-avtext-client-to-mixer-audio-level-05.txt
Hey Alexey, On 27 sept. 2011, at 00:24, Alexey Melnikov alexey.melni...@isode.com wrote: Jonathan Lennox wrote: Hi, Alexey -- thank you for the Gen-ART review. Hi Jonathan, Alexey Melnikov writes: Question: are the two encoding of the audio level indication option specified in the document really necessary? Do you mean the one-byte vs. two-byte forms of the header extension (Figure 1 vs. Figure 2)? These are the two forms of the generic header extensions defined by RFC 5285. I understood that. Does RFC 5285 require that both forms should be allowed? It doesn't explicitly say so but it It actually does, yes. Here's what it says: A stream MUST contain only one-byte or two-byte headers: they MUST NOT be mixed within a stream. Audio level headers can find themselves in streams that also have other, longer extensions, which do require the two-byte header. The above lines mandate that in such cases they all use the two-byte header. In the same regard, although probably a bit less likely, nothing prevents having another sixteen header extensions in a stream that also has levels. In that case we'd need to switch to two-byte headers in order to be able to fit all the IDs. Cheers, Emil --sent from my mobile In general, it would be good to avoid multiple representations of the same thing. The actual payload (one byte containing the V and level bits) is identical in the two cases; the only difference is the container. We can add some text clarifying this point if you think it would be helpful. Nits/editorial comments: s/relys/relies ??? Thanks, will fix. ___ 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
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? 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 smime.p7s Description: S/MIME cryptographic signature ___ 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
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). Good point, but still in my eyes that does not count as too significant factor, as it is impossible to have a generic ALG and I've understood ALGs in CPEs are not very much desired? So.. then.. is this sentence really still the IETF recommendation in the current state of affairs: -- IETF recommends using dual-stack or tunneling based solutions for IPv6 transition and specifically recommends against deployments utilizing double protocol translation. -- Teemu smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAOC: delegating ex-officio responsibility
--On Monday, September 26, 2011 13:15 -0700 Bob Hinden bob.hin...@gmail.com wrote: John, I don't see how you took what I said and then interpreted it as suggesting that I was saying proposing an absolute dictatorship. You do have a good imagination :-) I didn't take your proposal that way at all. I was only trying to point out that maximizing organization efficiency -- or minimizing the risks of organizational problems-- may not be a very good success criterion. Also, I have been proposing some other ways of solving the I* overload problems as you suggested, except that I don't think the solution to the I* overload problem is in the IASA. There, we may just disagree. I can't speak for anyone else, but, if I have to make a decision about making one of the IESG, IAB, or IASA a less efficient in the interest of reducing load on critical and non-substitutable people, I'd be inclined to point to the IASA first. FWIW, I don't think that having the IASA bear all of the burden is right either -- I also want to look for changes that would reduce the IAB-caused and IESG-related loads. For example, I favor both letting the IAB choose who represents it on the IASA _and_ the Program model that implies, among other things, that the IAB Chair doesn't have to have first-hold involvement in everything. Interesting it is exactly the assumption that the IAB Chair will have first hand involvement in everything that the IAB does that is cited an example of why it is necessary to have the IAB Chair on the IASA. So, if the IAB succeeds in reducing the load on the IAB Chair in that way, the argument for forcing the IAB Chair to serve on the IAOC and Trust is reduced as well. I'd also like to see mechanisms explored within the IESG to reduce the load on the IETF Chair. To the extent to which being General Area AD adds significant work, I'd be happy to see that turned into a real area and handed off to someone else. I'm not even sure that it is critical that the IETF Chair take a lead (and voting) technical role in the IESG; perhaps the community should reevaluate the required skill set and determine whether that responsibility (which, of course, includes responsibility for document reviews, etc.) is really an optimal use of time and skills or whether we should eliminate it and look for a different balance of skills. I'm not recommending that -- I can see large disadvantages as well as advantages -- but I think it is within the range of options the community should understand and consider. If we (the community) are going to solve the I* overload problem, it would be good to have some actual data on how the I* chairs spend their time. It would be good to have a better understanding of the problem before proposing solutions. Yes. And a better understanding of how all sorts of people spend their time, if it could actually be obtained, would be helpful for all sorts of purposes (e.g,, I'm sure Nomcoms would love to know for priority-setting purposes in candidate selection)). But, having sat in one of those seats and had an up-close view of how several others have handled them, I think one of the things you would find is that each person who does those jobs sorts things out, and prioritizes them, a little bit differently (maybe a lot differently). From that perspective, the observation that we've got the current IETF Chair and the current and immediate past IAB Chairs, supporting this change ought to send a relatively strong message... unless, again, efficiency of the IASA is more important than efficiency of the IAB or IESG (and I want to stress that I don't think you have said that... if it just my inference about whether some of your arguments lead if carried to their logical conclusion). john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAOC: delegating ex-officio responsibility
On 2011-09-28 08:03, John C Klensin wrote: snip ... Interesting it is exactly the assumption that the IAB Chair will have first hand involvement in everything that the IAB does that is cited an example of why it is necessary to have the IAB Chair on the IASA. So, if the IAB succeeds in reducing the load on the IAB Chair in that way, the argument for forcing the IAB Chair to serve on the IAOC and Trust is reduced as well. I agree, and of course this goes with my bias against the IAB becoming the I Administration B, which imnsho is a slippery slope that we are already on. I'd also like to see mechanisms explored within the IESG to reduce the load on the IETF Chair. I agree with this phrasing. If Russ isn't too busy (joke), an update of draft-carpenter-ietf-chair-tasks might be of interest, especially http://tools.ietf.org/html/draft-carpenter-ietf-chair-tasks-00#section-5 To the extent to which being General Area AD adds significant work, I'd be happy to see that turned into a real area and handed off to someone else. I'm not even sure that it is critical that the IETF Chair take a lead (and voting) technical role in the IESG; Indeed. In the above draft I also distinguished the IETF Chair role from the IESG Chair role, and whether they can be split is worth a discussion. perhaps the community should reevaluate the required skill set and determine whether that responsibility (which, of course, includes responsibility for document reviews, etc.) is really an optimal use of time and skills or whether we should eliminate it and look for a different balance of skills. I'm not recommending that -- I can see large disadvantages as well as advantages -- but I think it is within the range of options the community should understand and consider. If we (the community) are going to solve the I* overload problem, it would be good to have some actual data on how the I* chairs spend their time. It would be good to have a better understanding of the problem before proposing solutions. Yes. And a better understanding of how all sorts of people spend their time, if it could actually be obtained, would be helpful for all sorts of purposes (e.g,, I'm sure Nomcoms would love to know for priority-setting purposes in candidate selection)). But, having sat in one of those seats and had an up-close view of how several others have handled them, I think one of the things you would find is that each person who does those jobs sorts things out, and prioritizes them, a little bit differently (maybe a lot differently). From that perspective, the observation that we've got the current IETF Chair and the current and immediate past IAB Chairs, supporting this change ought to send a relatively strong message... And to be clear, I (still the previous IETF Chair) think that some such change is needed, which is exactly why I wrote the above draft in 2006. Perhaps the difference is that I see the IAOC/Trust role as very hard to separate from the IETF Chair role - but more easily separable from the IESG Chair role. unless, again, efficiency of the IASA is more important than efficiency of the IAB or IESG (and I want to stress that I don't think you have said that... if it just my inference about whether some of your arguments lead if carried to their logical conclusion). I think we need all three to be equally efficient; before IASA existed, we had burning administrative problems. I wouldn't like to have to rank the importance of the three. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-pim-port-08.txt (A Reliable TransportMechanism for PIM) to Experimental RFC
Hi, all, The IANA considerations in this doc are in error and need updating as follows. I agree that PORT is a poor acronym choice, FWIW. Joe 11. IANA Considerations This specification makes use of a TCP port number and a SCTP port number for the use of PIM-Over-Reliable-Transport that has been allocated by IANA. It also makes use of IANA PIM Hello Options allocations that should be made permanent. The current IANA allocation is called pim-port, not PIM-Over-Reliable-Transport. The long name (description) is PIM over Reliable-Transport, but that's not the authoritative name of the service - also, IANA does assignments (as per RFC 6335); this section should read as follows. This specification makes use of a TCP port number and a SCTP port number for the use of pim-port service that has been assigned by IANA. It also makes use of IANA PIM Hello Options assignments that should be made permanent. 11.1. PORT Port Number IANA has assigned a port number that is used as a destination port for PORT TCP and SCTP transports. The assigned number is 8471. References to this document should be added to the Service Name and Transport Protocol Port Number Registry. This should read: IANA has already assigned a port number that is used as a destination port for pim-port TCP and SCTP transports. The assigned number is 8471. References to this document should be added to the Service Name and Transport Protocol Port Number Registry for pim-port. On 9/27/2011 1:46 AM, t.petch wrote: The choice of service name for this transport seems unfortunate; having a port number registry with a service in it called 'port' may be witty but seems like a source of future confusion. I notice that IANA currently have a service name of 'pim-port' which seems a better idea and one that I think that this I-D should adopt. Tom Petch - Original Message - From: The IESGiesg-secret...@ietf.org To: IETF-Announceietf-annou...@ietf.org Cc:p...@ietf.org Sent: Monday, September 26, 2011 9:40 PM Subject: Last Call:draft-ietf-pim-port-08.txt (A Reliable TransportMechanism for PIM) to Experimental RFC The IESG has received a request from the Protocol Independent Multicast WG (pim) to consider the following document: - 'A Reliable Transport Mechanism for PIM' draft-ietf-pim-port-08.txt as an Experimental 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 2011-10-10. 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 This document defines a reliable transport mechanism for the PIM protocol for transmission of Join/Prune messages. This eliminates the need for periodic Join/Prune message transmission and processing. The reliable transport mechanism can use either TCP or SCTP as the transport protocol. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pim-port/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pim-port/ No IPR declarations have been submitted directly on this I-D. ___ 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
Please see attached review. I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-sprecher-mpls-tp-oam-considerations-01.txt Reviewer: Brian Carpenter Review Date: 2011-09-28 IETF LC End Date: 2011-10-24 IESG Telechat date: 2011-11-03 Summary: In good shape, some changes suggested. Comments: - 1. As this is a document of quite general interest, I'm sending this Gen-ART review to the main IETF list too. 2. I strongly support the publication of this document, although I do have some suggested changes mentioned below. Open issues: Please define Transport as used in this document. People immersed in ITU-T thinking understand that this is not layer 4, but the usage is very confusing to many IETF people. This document is intended to explain why it would be unwise to standardize multiple solutions for MPLS-TP OAM, and to show how the existence of multiple solutions would complicate MPLS-TP development and deployment making networks more expensive to build, less stable, and more costly to operate. Good... but then I suggest that Section 3 and Section 6 both need a closing sub-section that summarizes the way in which they justify more expensive to build, less stable, and more costly to operate. Also, I found that Sections 4 and 5 get in the way of the flow of the argument - did you consider making them into Appendices? 3.4. The Complexity Sausage ... However, when we drive OAM complexity out of one network element at the cost of increased complexity at a peer network element we loose out economically and, more importantly, we loose out in terms of the reliability of this important network functionality. I don't understand how this argues the case for having only one solution. It seems quite orthogonal. The following paragraph is a powerful and relevant argument, but quite different and nothing to do with sausage: ...due to the need to ensure compatibility of an inter- working function between the two solutions (in order to achieve end-to-end OAM) we create a situation where neither of two disjoint protocol developments is able to make technical advances. 3.5. Inter-Working is Expensive and Has Deployment Issues ... The IETF has, with good reason, a history of strongly opposing proposals to inter-work protocols. This sentence reads like a religious statement, so I would delete it. The preceding arguments are already very strong, and Section 4 makes the same point in an objective fashion. 3.7. Migration Issues Deployment of a technology that is subsequently replaced or obsoleted often leads to the need to migrate from one technology to another. Such a situation might arise if an operator deploys one of the two OAM protocol solutions and discovers that it needs to move to use the other one. Suggested addition here: A specific case would be when two operators merge their networks, but are using different OAM solutions. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Need help tracking down problem accessing IETF Subversion repository on Mac OS X
On 27 Sep 2011, at 7:32, Henrik Levkowetz wrote: Hi, Yoav's tcpdump analysis, together with Martin's observations, helped me find the problem at the server end. I've changed the config now (addding a missing 'NameVirtualHost *:443' to Apache's config), and Stuart's example now works for me on OS X Snow Leopard and Lion: svn info https://svn.tools.ietf.org/svn/wg/hybi Great. Thanks for fixing this. Stuart Cheshire chesh...@apple.com * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [payload] [Payload] Last Call: draft-ietf-payload-rfc3189bis-02.txt (RTP Payload Format for DV (IEC 61834) Video)) to Proposed Standard
Hi, Roni and Qin Thank you for your comments! I'll correspond these issues and update the draft soon. Best regards, Kazuhiro 2011/9/27 Qin Wu bill...@huawei.com: Hi, Roni: Thank for your replies. Your proposed changes look good to me. I would like to see the remaining minor issues are addressed by authors. Regards! -Qin - Original Message - From: Roni Even To: 'Qin Wu' ; ietf@ietf.org Cc: payl...@ietf.org ; 'Kazuhiro Mishima' ; i...@riken.jp ; 'Stephen Casner' Sent: Tuesday, September 27, 2011 2:53 AM Subject: RE: [payload] [Payload] Last Call: draft-ietf-payload-rfc3189bis-02.txt (RTP Payload Format for DV (IEC 61834) Video)) to Proposed Standard Hi Qin, Thanks for the review see inline Roni From: payload-boun...@ietf.org [mailto:payload-boun...@ietf.org] On Behalf Of Qin Wu Sent: Tuesday, September 20, 2011 9:16 AM To: ietf@ietf.org Cc: payl...@ietf.org Subject: Re: [payload] [Payload] Last Call: draft-ietf-payload-rfc3189bis-02.txt (RTP Payload Format for DV (IEC 61834) Video)) to Proposed Standard Hi, I have just read this document and have some minor comments, hope it is not late to be taken into account. 1. Section 1: [Qin]: It looks this version extends RFC3189 to support some new features. However I can not see any dependency to RFC3189 in the introduction section until I read the last section in this document, is it more straigtforward and clear to merge the section 7,8 to the introduction section and clarify how this document is different from RFC3189. Roni: This document does not extend but obsolete RFC3189, so it should not reference it. As for the difference from RFC3189 I think it is better to have a separate section. [Qin]: Yes, I recheck this document, you are right, this document is intending to replace the old feature with new feature, e.g., abandon using SMPTE 306M, replace with SMPTE314M. Therefore I agree with your justification. 2. Section 3.1.1 3.1.1. Media Type Registration for DV Video Type name: video Subtype name: DV Required parameters: encode: type of DV format. Permissible values for encode are SD-VCR/525-60, SD-VCR/625-50, HD-VCR/1125-60, HD-VCR/1250-50, SDL-VCR/525-60, SDL-VCR/625-50, 314M-25/525-60, 314M-25/625-50, 314M-50/525-60, 314M-50/625-50, 370M/1080-60i, 370M/1080-50i, 370M/720-60p, 370M/720-50p, 306M/525-60 (for backward compatibility), and 306M/625-50 (for backward compatibility). [Qin]: In section 7, you claim you have removed SMPTE 306M, since it is covered by SMPTE 314M format. However in section 3.1.2, the value for SMPTE 306M is still kept in the encode list. So the question is where do you remove SMPTE 306M in this document? Why SMPTE 306M in the media type registration is still kept? Does this conflict with what you said in the section 7? The same comment applies in any place of this document where SMPTE 306M is still kept. Roni: Maybe change the first bullet of section 7 Removed SMPTE 306M, since it is covered by SMPTE 314M format To support for SMPTE 306M is only for backward interoperability, since it is covered by SMPTE 314M format [Qin]: Yes, make sense to me. 3. Section 3.1.1 Optional parameters: audio: whether the DV stream includes audio data or not. Permissible values for audio are bundled and none. Defaults to none. Encoding considerations: DV video can be transmitted with RTP as specified in RFC (This document). Other transport methods are not specified. Security considerations: See Section 4 of RFC (This document). Interoperability considerations: NONE [Qin]: Is it real that there is no interoperability consideration since Interoperability with Previous Implementations is discussed in the section 8 of this document? Roni: Good, add a reference to section 8 of this RFC [Qin]: Your proposal Looks good to me. 4. Section 3.2.1 Note that the examples in RFC3189 (older version of this document) provides incorrect SDP a=fmtp attribute usage. [Qin]: I believe it is not appropriate to spell this note out when this document is published but you may put it as errata or in the section 7. Roni: good point. Maybe discuss it in section 8, since this may be an interoperability issue [Qin]: Good suggestion since a=fmtp:format format-specific parameters should not be used in this document, instead, the format-specific parameter is incorporated into a = fmtp: payload type encode=DV-video encoding;audio ... Also not that the syntax a=fmtp:payload type encode=DV-video encoding audio=audio bundled Does not have ; before the audio while the examples have, I think that ;
Protocol Action: 'RPL Objective Function Zero' to Proposed Standard (draft-ietf-roll-of0-20.txt)
The IESG has approved the following document: - 'RPL Objective Function Zero' (draft-ietf-roll-of0-20.txt) as a Proposed Standard This document is the product of the Routing Over Low power and Lossy networks Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-roll-of0/ Technical Summary The Routing Protocol for Low Power and Lossy Networks (RPL) was designed as a generic core protocol that is agnostic to metrics and that is adapted to a given problem using Objective Functions (OF). This separation of Objective Functions from the core protocol specification allows RPL to adapt to meet the different optimization criteria required by the wide range of use cases. RPL forms Destination Oriented Directed Acyclic Graphs (DODAGs) within instances of the protocol. Each instance is associated with a specialized Objective Function. A DODAG is periodically reconstructed in a new Version to enable a global reoptimization of the graph. An Objective Function selects the DODAG Version that a device joins within an instance, and a number of neighbor routers within that DODAG Version as parents or feasible successors. The OF generates the Rank of the device, that represents an abstract distance to the root within the DODAG. In turn, the Rank is used by RPL to avoid loops and verify forward progression towards a destination. This document defines Objective Function 0 (OF0) which operates on parameters that are obtained from provisionning, from the RPL DODAG Configuration option, and from the RPL DIO base container. OF0 is designed as a default OF that will allow interoperation between implementations in a wide spectrum of use cases. Working Group Summary No discontent. There has been some confusion about the WG process because of the large number of revisions since the first WG last call. Here is the timeline: 01/05New revision -05 02/22WG last call on -05 03/13On-list discussions of changes 03/13New revision -06 03/13New revision -07 03/14WG last call on -07 03/16,, On-list discussions 03/30New revision -08 04/05New revision -09 04/11Comment on list 04/11New revision -10 04/21Comment on list 05/05Notice to list about changes 05/05New revision -11 05/08WG chair review posted to list 05/10Comment on list 05/17Notice to list about changes 05/17New revision -12 05/18.. On-list discussion 05/24Publication request 06/01AD review posted to list 06/11AD review :: Revised I-D needed 06/17New revision -13 06/20New revision -14 06/20IETF Last Call 07/04IETF Last Call ends 07/08New revision -15 07/16Ballot issued 08/09IESG Discusses 08/09.. On-list discussions 08/11IESG telechat Thus: all changes as a result of comments made on the list. Plenty of explanation to the list about what was changing and why. A further poll of the WG will be carried out after changes to address IESG Discusses Document Quality The OF0 has been extensively discussed and reviewed by key contributors of the Working Group. There are believed to be two implementations. Personnel JP Vasseur (jvass...@cisco.com) is the Document Shepherd. Adrian Farrel (adr...@olddog.co.uk) is the Responsible AD. RFC Editor Note Section 4.2.1 OLD 2. An implementation SHOULD validate a router prior to selecting it as preferred as discussed in Section 3. The validation involves layer 2 connectivity to the router, layer 3 connectivity offered by the router, and may involve other factors such as policies. In most cases, a router that does not succeed the validation process cannot be further considered for selection as preferred parent. In any case a router that succeeded that validation process SHOULD be preferred. NEW 2. Prior to selecting a router as the preferred parent, an implementation SHOULD validate the connectivity and suitability of the router as discussed in Section 3. This validation involves checking the layer 2 connectivity to the router, the layer 3 connectivity offered by the router, and may involve examination of other factors such as locally or globally configured policies. In most cases, a router that does not succeed the validation process cannot be further considered for selection as preferred parent. In any case a router that succeeded that validation process SHOULD be preferred over one that does not succeed. END ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Using the Generic Associated Channel Label for Pseudowire in MPLS-TP' to Proposed Standard (draft-ietf-pwe3-mpls-tp-gal-in-pw-01.txt)
The IESG has approved the following document: - 'Using the Generic Associated Channel Label for Pseudowire in MPLS-TP' (draft-ietf-pwe3-mpls-tp-gal-in-pw-01.txt) as a Proposed Standard This document is the product of the Pseudowire Emulation Edge to Edge Working Group. The IESG contact persons are Stewart Bryant and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-pwe3-mpls-tp-gal-in-pw/ Technical Summary This document describes the requirements for using the Generic Associated Channel Label (GAL) in Pseudowires (PWs) in MPLS-TP networks, and provides an update to the description of GAL usage in RFC5586 by removing the restriction that is imposed on using GAL for PWs especially in MPLS-TP environments. This is required to allow PWs that do not use a PW control word to be used in MPLS-TP and for them to use the full range of MPLS-TP OAM supported by the G-ACh. This document is a product of the PWE3 working group. This document is STANDARDS TRACK. Working Group Summary There is consensus in the working group for this change to RFC5586. Document Quality There are no concerns with document quality. Personnel Matthew Bocci (matthew.bo...@alcatel-lucent.com) is the Document Shepherd for this document. Stewart Bryant (stbry...@cisco.com) is the Responsible Area Director RFC Editor Note In abstract s/[RFC5586]/RFC5586/ Section 1 s/associated control channel/Associated Channel/ (per RFC 5085) s/generalizes this for use in the/generalizes this for use as the/ s/but places restrictions on GAL usage with PWs. /but prohibits GAL usage with PWs./ In section 3 OLD [RFC3985] architectures appropriate NEW [RFC3985] architectures as appropriate END s/but not for PWs using an MPLS-TP PSN./ but not for PWs in an MPLS-TP network./ ... and at the very bottom of section 3 OLD is replaced by: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MAY be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit set to 1). However, in other MPLS environments, this document places no restrictions on where the GAL may appear within the label stack. NEW is replaced by: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MAY be used with PWs. The presence of a GAL indicates that an ACH immediately follows the MPLS label stack. END ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Re: Informational RFC to be: draft-irtf-asrg-bcp-blacklists-10.txt
The IESG has no problem with the publication of 'Overview of Email DNSBL Best Practise' draft-irtf-asrg-bcp-blacklists-10.txt as an Informational RFC. The IESG wants to make the IRSG aware of its concern that there is a potential for confusion between the IETF Best Current Practice (BCP) series and the use of the term Best Practise in the title and the abstract as well as the use of the acronym BCP in the page header of each page and in sections 1.2 and 3.6. Anything that the IRSG can do to avoid this confusion would be appreciated. The IESG would also like the IRSG to review the comments in the datatracker (http://datatracker.ietf.org/doc/draft-irtf-asrg-bcp-blacklists/) related to this document and determine whether or not they merit incorporation into the document. Comments may exist in both the ballot and the comment log. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-irtf-asrg-bcp-blacklists/ The process for such documents is described at http://www.rfc-editor.org/indsubs.html Thank you, The IESG Secretary Technical Summary The rise of spam and other anti-social behavior on the Internet has led to the creation of shared DNS-based lists (DNSBLs) of IP addresses or domain names intended to help guide email filtering. This memo summarizes guidelines of accepted best practise for the management of public DNSBLs by their operators as well as for the proper use of such lists by mail server administrators (DNSBL users), and it provides useful background for both parties. It is not intended to advise on the utility or efficacy of particular DNSBLs or the DNSBL concept in general, nor to assist end users with questions about spam. Working Group Summary This document is a product of the Anti-Spam Research Group and represents the consensus of that group. Document Quality This document is a research publication of the IRTF. Personnel Pete Resnick presn...@qualcomm.com is the responsible Area Director. IESG Note The IESG has concluded that this work is related to IETF work done in the MARF WG and the as-yet-unchartered REPUTE BOF, but this relationship does not prevent publishing. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Re: Informational RFC to be: draft-tripathi-roll-rpl-simulation-07.txt
The IESG has no problem with the publication of 'Performance Evaluation of Routing Protocol for Low Power and Lossy Networks (RPL)' draft-tripathi-roll-rpl-simulation-07.txt as an Informational RFC. The IESG would also like the RFC-Editor to review the comments in the datatracker (http://datatracker.ietf.org/doc/draft-tripathi-roll-rpl-simulation/) related to this document and determine whether or not they merit incorporation into the document. Comments may exist in both the ballot and the comment log. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-tripathi-roll-rpl-simulation/ The process for such documents is described at http://www.rfc-editor.org/indsubs.html Thank you, The IESG Secretary Technical Summary This document presents a performance evaluation of the Routing Protocol for Low power and Lossy Networks (RPL) for a small outdoor deployment of sensor nodes and for a large scale smart meter network. Detailed simulations are carried out to produce several routing performance metrics using these real-life deployment scenarios. Working Group Summary This document is submitted on the Independent Stream The IESG will want to note that this document was discussed over six revisions on the ROLL WG mailing list. During that time a number of suggestions were made, and the draft was updated accordingly. It should be noted that, while most of the comments raised in the working group were addressed, some concerns about the methodology remain unanswered. The working group expressed interest in having a document that covered simulation results, but could not decide what would go in that document. Additionally, the authors of this document felt that they wished to document and describe their simulation and did not have the resources to take on other simulations with different methodologies as suggested by the working group. For these reasons they have brought the I-D forward on the Independent Stream rather than through the WG or with AD sponsorship. The existence of this document in no way precludes the WG from producing its own document describing simulations, and does not prevent other authors from describing their own simulations and presenting them for publication. All authors of RPL simulation reports are encouraged to share them for open discussion on the ROLL mailing list. Document Quality The document has been reviewed by Craig Partridge on behalf of the ISE. The authors updated the document after his review. As noted above, the document has been updated after several reviews in the ROLL WG. This is an Informational document and not subject to implementation. - - - - - - RFC Editor Note The IESG has concluded that this work is related to IETF work done in the ROLL, IPPM, and BMWG working groups, but this relationship does not prevent publishing. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-ccamp-wson-impairments-07.txt (A Framework for the Control of Wavelength Switched Optical Networks (WSON) with Impairments) to Informational RFC
The IESG has received a request from the Common Control and Measurement Plane WG (ccamp) to consider the following document: - 'A Framework for the Control of Wavelength Switched Optical Networks (WSON) with Impairments' draft-ietf-ccamp-wson-impairments-07.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 2011-10-11. 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 As an optical signal progresses along its path it may be altered by the various physical processes in the optical fibers and devices it encounters. When such alterations result in signal degradation, these processes are usually referred to as impairments. These physical characteristics may be important constraints to consider when using a GMPLS control plane to support path setup and maintenance in wavelength switched optical networks. This document provides a framework for applying GMPLS protocols and the PCE architecture to support Impairment Aware Routing and Wavelength Assignment (IA-RWA) in wavelength switched optical networks. This document does not define optical data plane aspects; impairment parameters, measurement of, or assessment and qualification of a route, but rather it describes the architectural and information components for protocol solutions. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ccamp-wson-impairments/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ccamp-wson-impairments/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Review: Reputation Services (repute)
A new IETF working group has been proposed in the Applications Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (i...@ietf.org) by Tuesday, October 4, 2011. Reputation Services (repute) - Status: Proposed Working Group Last Updated: 2011-09-13 Chair(s): TBD Applications Area Director(s): Pete Resnick (presn...@qualcomm.com) Peter Saint-Andre (stpe...@stpeter.im) Applications Area Advisor: Pete Resnick (presn...@qualcomm.co) Mailing Lists: General Discussion: rep...@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/repute Archive:http://www.ietf.org/mail-archive/web/repute/ Description of Working Group: In the open Internet, making a meaningful choice about the handling of content requires an assessment of its safety or trustworthiness. This is based on a trust metric for the owner (identity) of an identifier associated with the content, to distinguish (likely) good actors from bad actors. The generic term for such information is reputation. This working group will develop mechanisms for reputation reporting by independent services. One mechanism will be for a basic assessment of trustworthiness. Another will provide a range of attribute/value data that is used as input to such an assessment. Each service determines the attributes it reports. Various mechanisms have been developed for associating a verified identifier with email content, such as with SPF (RFC4408) and DKIM (RFC4871). An existing reputation query mechanism is Vouch-by-Reference (RFC5518). It provides a simple Boolean response concerning a domain name used for email. The current working group effort will expand upon this, to support additional applications -- such as Web pages and hosts -- and a wider range of reporting information. Given the recent adoption of domain name verification for email, by SPF and DKIM, the most obvious initial use case for reputation is for email. Inbound email filters that perform message authentication can obtain a verified domain name and then consult a reputation service provider to make a determination (perhaps also based on other factors) of whether or not the content is desirable and take appropriate action with respect to delivery, routing or rejection. Another possible use case is identity-based evaluation of web content using technologies such as the DKIM-derived DOSETA (work in progress). This working group will produce specifications for: * the detailed requirements for reporting * an end-to-end system architecture in which reporting occurs * the mechanisms and formats for reporting Two mechanisms are under consideration: * simple -- a reputation is expressed in a simple manner, via records in the DNS (see draft-kucherawy-reputation-query-dns) * extended -- a response can contain more complex information useful to an assessor, reported over HTTP using an encoding such as XML or JSON (see draft-kucherawy-reputation-query-http) The syntactic and semantic aspects of mechanisms and formats will be designed to be application-independent and portable (i.e., reputation provider-independent). By distinguishing reporting information (format) from reporting mechanism (channel), the specifications will permit adaptation to support reporting through additional channels. Limited application-specific tailoring will be provided for email, to demonstrate the approach, which can be applied for supportting additional applications. The design and specification will also permit adaptation to support reporting through additional transport channels. Items that are specifically out of scope for this work: * Specific actions to be taken in response to a reputation reply. It is up to assessors (i.e., the consumers of reputation data) to determine this. Non-normative illustrations, however, can be included to demonstrate possible uses of reputation data in a particular context. * Selection of what data might be valid as the subject of a reputation query. It is up to reputation service providers and assessors to select which qualities of a body of data might be useful input to reputation evaluation. * Concerns about methods of verifying domain names that are used for email reputation. A verified domain name is a starting point for this work; the means by which it was obtained and the meaning of the name or its verification are matters for discussion elsewhere. * Algorithms to be applied to aggregated feedback in order to compute reputations. These are part of a back-end system, usually proprietary, and not appropriate for specification as part of a query/reply framework and
