Re: US DoD and IPv6
Dave CROCKER wrote: 1. Adopt an IPv6 as Steve Deering originally designed it[1]: A basic upgrade to the IPv4 header, with more address bits, an extensibility mechanisms for adding fields later, and removal of some bits that weren't needed. That is an option because, with port restricted IP, we have enough time for the transition. That is, there is no reason to insist on deploying IPv6 with 16B addresses when SIP with 8B address will do. However, original SIP is unnecessarily combined with Steve's other proposals and is still too complex. For example, considering that his favorite PMTUD does not really work elegantly to detect increase of PMTU, minimum MTU should be increased without PMTUD or reserved header field should be used to record the current PMTU to be modified at each hop. His favorite multicast should be purely optional because broadcast is a lot simpler. Flow ID for his favorite RSVP is unnecessary, because QoS capable L2s have its own label. There may be other simplifications possible. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
IETF web site down for IPv6?
Not having any luck connecting - seems to be an issue near the server: $ traceroute6 www.ietf.org traceroute6 to www.ietf.org (2001:1890:1112:1::20) from 2001:630:d0:f103:216:cbff:fe8b:752e, 64 hops max, 12 byte packets 1 2001:630:d0:f103::2 0.529 ms 0.299 ms 0.321 ms 2 zaphod.6core.ecs.soton.ac.uk 0.283 ms 0.514 ms 0.177 ms 3 ford.6core.ecs.soton.ac.uk 0.564 ms 0.452 ms 0.491 ms 4 2001:630:c1:100::1 0.912 ms 0.970 ms 0.755 ms 5 2001:630:c1:18::a 0.758 ms 0.645 ms 1.550 ms 6 so2-1-0.lond-sbr1.ja.net 3.664 ms 3.601 ms 3.594 ms 7 as0.lond-sbr4.ja.net 3.878 ms 3.995 ms 3.894 ms 8 ix-5-0-0.core4.ldn-london.ipv6.as6453.net 4.093 ms 4.256 ms 4.308 ms 9 if-14-0-0.1874.mcore3.l78-london.ipv6.as6453.net 5.056 ms 5.872 ms 12.121 ms 10 pos7-0.mcore4.njy-newark.ipv6.as6453.net 76.873 ms 77.426 ms 76.838 ms 11 if-12-0.mcore3.njy-newark.ipv6.as6453.net 93.370 ms 104.308 ms 115.081 ms 12 if-9-0-0.906.core3.nto-newyork.ipv6.as6453.net 77.124 ms 77.282 ms 77.030 ms 13 2001:1890:1fff:10a:192:205:35:13 78.233 ms 77.740 ms 77.825 ms 14 * * * 15 * * * Same for others? Hopefully this mail will fall back to IPv4 transport if required. Tim ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: can we please postpone the ipv6 post-mortem?
Le 8 oct. 2010 à 19:02, james woodyatt a écrit : everyone-- IPv6 may have been born with a developmental disability, but we're not dealing with a corpse yet. The patient is still alive, getting better, and with a bit of love and proper care, might yet grow up to make better and brighter music than IPv4. Maybe I'm being overly sentimental and using anthropomorphism inappropriately here, but really folks -- isn't it a bit unseemly to be arguing over how we went so wrong with IPv6-- 100% agreement It's time to use all what already works. It's also time to complete what already works with pieces that miss to quickly extend IPv6 use to more configurations. and how we could do ever so much better the *next* time we get to reinvent the Internet if we avoid all the killing mistakes we made in bringing IPv6 up-- while there are, today, more people than ever before taking what are perceived to be enormous risks actually making the v4-v6 transition start to happen? It should be largely advertised that, v4-v6 transition HAS started (fortunately, not everybody is lagging behind): - Since 2008, many users whose service providers offer IPv6 automatically access Google servers in IPv6. - For the still numerous applications that are reachable only in IPv4, they didn't lose any IPv4 connectivity. - No NATs being traversed in IPv6, Google applications that use many parallel TCP connections have no risk, for these users, to encounter any port shortage in any traversed NAT. Kind regards, RD -- james woodyatt j...@apple.com member of technical staff, communications engineering ___ 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: can we please postpone the ipv6 post-mortem?
Le 8 oct. 2010 à 19:06, Phillip Hallam-Baker a écrit : What if the key to IPv6 deployment is the realization that IPv6 can only be deployed after we have solved the IPv4 address exhaustion problem? IPv6 HAS ALREADY BEEN deployed where there was absolutely no address exhaustion problem. RFC 5569, at least its introduction, is useful reference material in this respect, to be read or re-read. The key is IMHO to keep things as simple as they can be in each particular context. Regards, RD On Fri, Oct 8, 2010 at 1:02 PM, james woodyatt j...@apple.com wrote: everyone-- IPv6 may have been born with a developmental disability, but we're not dealing with a corpse yet. The patient is still alive, getting better, and with a bit of love and proper care, might yet grow up to make better and brighter music than IPv4. Maybe I'm being overly sentimental and using anthropomorphism inappropriately here, but really folks-- isn't it a bit unseemly to be arguing over how we went so wrong with IPv6-- and how we could do ever so much better the *next* time we get to reinvent the Internet if we avoid all the killing mistakes we made in bringing IPv6 up-- while there are, today, more people than ever before taking what are perceived to be enormous risks actually making the v4-v6 transition start to happen? -- james woodyatt j...@apple.com member of technical staff, communications engineering ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Website: http://hallambaker.com/ ___ 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: US DoD and IPv6
On 10/10/2010 2:51 PM, Steve Crocker wrote: A compatible solution would have been better, but I don't think IPv4... -- were designed in a way that permitted a compatible extension. Oh? Perhaps: 1. Adopt an IPv6 as Steve Deering originally designed it[1]: A basic upgrade to the IPv4 header, with more address bits, an extensibility mechanisms for adding fields later, and removal of some bits that weren't needed. 2. Define the IPv6 address space as the IPv4 address space, with all zeroes for the higher bits. (In other words, defer more interesting schemes until later.) 3. Design header translation devices to map between the two formats. 4. Start fielding these implementations. (That could have started by 1994 or so.) The gateways between v4 and v6 would initially be notably for having almost no work to do and of not losing any information. In particular, barely qualifies as a dual stack. With this approach, incompatibility between v4 and v6 would only occur when additional addresses, beyond v4's limitations, start to be assigned. We must deal with the current reality and make it work, but historical considerations need to factor in the ambitions that dominated during the many years of design. The community got ambitious in a fashion that smacked of the overreaching that is often called second system syndrome (although counting the Arpanet, this was really a third system...) d/ [1] http://tools.ietf.org/html/draft-deering-sip-00 -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
On 10/10/2010 3:44 PM, Steve Crocker wrote: Mebbe. I confess I didn't study the details of the competing proposals at the time because I was confident the people who were heavily involved surely had things under control. Alas... Along with the imposition of ASN.1's complexities as the MIB format, for compatibility between the competing network management protocols (SNMP and CMOT), IPv6 was an early demonstration of the problems that accrue from treating technical design as a political process, trying to accommodate too many factions. Such accommodations seem to rarely provide the long-term benefit that is intended, but instead consistently add complexity and limitations. Politicized technical processes rarely allow good folk to adequately have things in control. (I'm sure that your experiences on the ICANN Board and its SSAC have not disclosed this unexpected fact of life to you yet, so I thought it worth pointing out.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: can we please postpone the ipv6 post-mortem?
Le 9 oct. 2010 à 02:50, Fred Baker a écrit : That's not limited to Germany. Would that dtag.de would use 172.16/12 rather than 10/8 or 192.168/16, as the latter two seem to find their way into so many home configurations. Having the same prefix on each side of the residential NAT could be a real pain... With my understanding of how NATs work, I don't see why. Could you elaborate? Regards, RD Kind regards Peter -- Peter and Karin Dambier Cesidian Root - Radice Cesidiana Rimbacher Strasse 16 D-69509 Moerlenbach-Bonsweiher +49(6209)795-816 (Telekom) +49(6252)750-308 (VoIP: sipgate.de) mail: pe...@peter-dambier.de http://www.peter-dambier.de/ http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ ULA= fd80:4ce1:c66a::/48 ___ 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: can we please postpone the ipv6 post-mortem?
-- isn't it a bit unseemly to be arguing over how we went so wrong with IPv6-- 100% agreement It's time to use all what already works. That is, use IPv4 with or without port restrictions. It's also time to complete what already works with pieces that miss to quickly extend IPv6 use to more configurations. See above. It should be largely advertised that, v4-v6 transition HAS started (fortunately, not everybody is lagging behind): It has been starting for these 15 years. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF web site down for IPv6?
Hello IETF Community... Just a reminder that, if you have a problem you want solved, you'll get much faster action by sending email to the secretariat. You will get many MORE responses if you send to this list... but while I've been informed that that is often much more therapeutic, it may not be the actually desired outcome. Thanks Ray and Marshall for forwarding this to us. For others, our contact information is at http://www.ietf.org/secretariat.html (or just look for that CONTACT link on the left side bar of any www.ietf.org web page) if you ever need it. Please direct problem reports to us so we can more quickly respond, rather than to various lists, whenever possible. (And just by way of follow-up, we are currently seeing many IPV6 connections to the servers and lists, so everything appears to be functioning perfectly for most other IPV6 users. We will follow our established procedures for handling this report, following up with both ISPs until the problem is resolved.) Glen Glen Barney IT Director AMS (IETF Secretariat) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: can we please postpone the ipv6 post-mortem?
Le 9 oct. 2010 à 02:23, Brian E Carpenter a écrit : The transition model in 1995 was based on the assumption that vendors and ISPs would support dual stack globally well *before* IPv4 exhaustion. The fact that this did not happen is the problem. Agreed. Yet, the IETF has been IMHO, and to some extent still is, too slow to clarify the difference between DUAL-STACK SERVICE and DUAL-STACK ROUTING. In the absence of IPv6 service to hosts, generalized IPv4 address sharing will lead to port shortage, and will PROGRESSIVELY lead to intermittent and random connectivity breakages (the worse kind). With native IPv6 addresses offered to hosts (i.e. with THE IPv6 service), port shortages are completely avoided for all e2e IPv6 connections. (Besides, the danger of port shortages for the residual IPv4 traffic is consequently mitigated on paths that support the IPv6 service). Consequently, what users urgently need is DUAL-STACK HOSTS, with all the useful ways for their ISPs to assign them native IPv6 addresses (i.e. to offer IPv6 service). On the other hand, dual-stack routing isn't urgent, and may even, for some ISP, never need to be deployed. (They can first tunnel IPv6 across IPv4, and later directly move to residual IPv4 across IPv6-only). Regards, RD Brian ___ 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: US DoD and IPv6
Without getting into the question of whether your suggestion would have helped anything in terms of transition and interoperability, it shares one major flaw with the path we did adopt. There is no incentive to spend resources to get there. No matter how elegant it is technically, without a benefit for deployment there is no way to get past very small scale deployment (some folks will deploy anything to see if it has value, but most won't.) That is one of the main stumbling blocks that Noel reported publicly for getting Nimrod off the ground separately from the IPv6 effort. The operators who had to deploy it did not gain anything. As long as our path is one of minimal change, we were inherently locked in to a behavioral set that matched Ipv4. that is what SIP proposed. That is what IPv6 gave us. For any proposal to work, there has to be a benefit to folks to use it. Even before it is ubiquitous. As far as I can tell, we ignored that question during the 1993-1999 period when we should have been working on it. We also get ourselves into a mind set of we need an answer now. There is no time to do technically hard work. That was a bad call. 5 extra years spend=t serously working on what the needs were, what the deployments could be, and what the technology could look like, might have given us a better path. (No, there is no guarantee. We could have blown it anyway.) Yours, Joel M. Halpern On 10/10/2010 6:41 PM, Dave CROCKER wrote: On 10/10/2010 2:51 PM, Steve Crocker wrote: A compatible solution would have been better, but I don't think IPv4... -- were designed in a way that permitted a compatible extension. Oh? Perhaps: 1. Adopt an IPv6 as Steve Deering originally designed it[1]: A basic upgrade to the IPv4 header, with more address bits, an extensibility mechanisms for adding fields later, and removal of some bits that weren't needed. 2. Define the IPv6 address space as the IPv4 address space, with all zeroes for the higher bits. (In other words, defer more interesting schemes until later.) 3. Design header translation devices to map between the two formats. 4. Start fielding these implementations. (That could have started by 1994 or so.) The gateways between v4 and v6 would initially be notably for having almost no work to do and of not losing any information. In particular, barely qualifies as a dual stack. With this approach, incompatibility between v4 and v6 would only occur when additional addresses, beyond v4's limitations, start to be assigned. We must deal with the current reality and make it work, but historical considerations need to factor in the ambitions that dominated during the many years of design. The community got ambitious in a fashion that smacked of the overreaching that is often called second system syndrome (although counting the Arpanet, this was really a third system...) d/ [1] http://tools.ietf.org/html/draft-deering-sip-00 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: can we please postpone the ipv6 post-mortem?
Le 9 oct. 2010 à 04:47, Martin Rex a écrit : Fred Baker wrote: On Oct 8, 2010, at 3:42 PM, Martin Rex wrote: Huh? Hardly anyone support IPv6 these days. Well, the hardly anyone seems to include all Windows, Macosx, 50% of windows is on WindowsXP where IPv6 is off by default. On home networks, DHCP on 192.168.x.x is the norm in Germany, and when the DSL-router doesn't give out IPv6 addresses, it doesn't matter whether your Windows7, Mac OS-X, Linux or FreeBSD could use it -- it simply will not get it. That's precisely the configuration for which Brian Carpenter, Sheng Jiang, and myself, propose 6a44 (a stateless and simple approach to offer native IPv6 across NAT44 CPEs). The more it is understood that it can accelerate ubiquitous IPv6 availability in hosts, the more chances there are of having it quickly in vendor OSes. Regards, RD Linux, and Freebsd-based products, and routers from any vendor you care to name. Western Digital MyBook World 2 runs Linux and is IPv4-only A very popular and very commonly used family of home DSL routers in Germany (Fritz) runs Linux and is IPv4-only -- only the two newest models have sufficient resources and a beta-firmware with IPv6 for download. My DVB-S Receiver runs Linux and is IPv4 only. But hardly anyone includes Canon printers like the one sitting next to me, all products from Sony that have a network interface (think Blue-Ray players, PS2, PS3, ...), *MY* brand-new Sony LED-LCD-TV has a RJ45 FastEthernet port and is IPv4-only Yes, CPEs are a problem right now. Look for that to change. Admittedly, I'm IPv4-only myself. I now little more about IPv6 than that it uses an 128-bit address field and visualized with hex-quads and colons instead of dotted decimal. When I recently heard about dual-stack connectivity issues and proposed app-level workarounds, I really started wondering whether the existing worlds-apart approach of v4/v6 is part of the problem rather than part of the solution. A suggestion that an app should use two threads, look up the seperate IPv4 and IPv6 address of the target and start two seperate parallel connect()s for v4 and v6, my high expectations about IPv6 were unexpectedly floored. Seperate Addressing and seperate routing for IPv4 and IPv6 doesn't seem right. There should be a single transparent addressing and routing scheme and a smooth migration. Migration from PSTN to VoIP worked much better conceptually. And it is up to the network to decide which intermediate links use which technology, it doesn't (and shouldn't) matter to the end nodes. Would it really be so difficult to upgrade large parts of the backbone to v6-only traffic and v6-only node addresses while retaining the ability to route ipv4 datagrams across? For a migration, it might also help not having to select either v4 or v6 at the end node, but instead run with both addresses on each datagram, something like a reduced (96-x)IPng address space _plus_ a traditional IPv4 address to compose a single 128-bit address and let the network and network stack figure out whether new addressing works. i.e. each network interface with only a single address (IPv4, IPng or composite IPv5+IPng) rather than two seperate addresses IPv4 and IPv6. -Martin ___ 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: US DoD and IPv6
On 10/11/2010 8:25 AM, Joel M. Halpern wrote: Without getting into the question of whether your suggestion would have helped anything in terms of transition and interoperability, it shares one major flaw with the path we did adopt. There is no incentive to spend resources to get there. Indeed, it has been remarkable how poor the sales pitch has been to resource-poor operations that are expected to adopt this, even after all this time. The only counter I will make -- and it is not an attempt to contradict your point -- is that the adoption barrier for the scheme I described is minuscule, when compared with the full, incompatible, dual-stack scheme that we've pursued. Most of the software could be shared between v4 and the simplified v6 I described, and initially most of the operations procedures could be shared. And router products could have been enhanced to include the translation pretty easily. Again, none of this contradicts the lack of an attractive value proposition for adopters. But it could have made incremental adoption much cheaper and simpler and could have started it much sooner. As long as our path is one of minimal change, we were inherently locked in to a behavioral set that matched Ipv4. that is what SIP proposed. That is what IPv6 gave us. The current IPv6 is not minimal change. It is an entirely incompatible dual stack model. That really is fundamentally different from what I described, which was actually a clean upgrade to the existing system and would have remained entirely compatible with it, semantically, when initially deployed. For any proposal to work, there has to be a benefit to folks to use it. Even before it is ubiquitous. As far as I can tell, we ignored that question during the 1993-1999 period when we should have been working on it. Yup. The motivating requirement was address space, but address space is not functional enhancement, in terms of marketing to adopters. Fixing address space, for most folk, would have been an overhead expense. We also get ourselves into a mind set of we need an answer now. There is no time to do technically hard work. That was a bad call. 5 extra years spend=t serously working on what the needs were, what the deployments could be, and what the technology could look like, might have given us a better path. (No, there is no guarantee. We could have blown it anyway.) Probably not. If we were going to be blown away, there turned out to be plenty of time for that to have developed. One could argue that those likely to pursue that path of innovation were discouraged from it, but I think it more likely that the spiffy, mind-blowing enhancement is still eluding folk. So we are left with the ideal alternative of an unrealized, unspecified, superior choice, versus the concrete, flawed path we went down. The former always looks better, since it is not constrained by the real world. FWIW, when work seriously began, in the early/mid 90s, we were already turning down legitimate requests, such as from the electricity folks (EPRI). Instead we chose to focus on global exhaustion rather than individual denial. That was the real mistake. There really was urgency back then and we convinced ourselves there wasn't. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
IESG Statement on Document Shepherds
This statement provides guidance from the IESG on selection of a Document Shepherd for documents from IETF working groups and documents from individuals. RFC 4858 defines the role of the Document Shepherd for documents from IETF working groups, and it also says: The Document Shepherd is usually a chair of the working group that has produced the document. In consultation with the Responsible Area Director, the chairs may instead decide to appoint the working group secretary as the responsible Document Shepherd. Experience has shown that a successful Document Shepherd need not be the working group chair or secretary. In fact, the IESG encourages the working group chair to select an active working group participant that has strong understanding of the document content, is familiar with the document history, and is familiar with the IETF standards process. The Document Shepherd of a working group document should not be an author or editor of the document. Not all individual submissions have a Document Shepherd other than an author or editor of the document. When there is one, the Document Shepherd is selected by the Responsible Area Director in consultation with the document authors or editors. The Document Shepherd prepares a publication request write-up. The template for the write-up can be found here: For working group documents: http://www.ietf.org/iesg/template/doc-writeup.html For individual documents: http://www.ietf.org/iesg/template/individual-doc-writeup.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART LC Review of draft-zeilenga-ldap-dontusecopy-08
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-zeilenga-ldap-dontusecopy-08 Reviewer: Ben Campbell Review Date: 2010-10-11 IETF LC End Date: 2010-10-11 IESG Telechat date: (if known) Summary: This draft is almost ready to be published as a proposed standard, but I have some comments that should be considered first. Major issues: None Minor issues: -- General: (Let me preface my general comments with the admission that I am not an LDAP expert. Since this is a Gen-ART review, I'm approaching this as a generalist. If the answer is something like Ben, if you new anything about LDAP this would all be obvious to you, that will not offend me in any way.) I'd like to see more explanation of the problem this needs to be solved. I assume that there is concern that copied or cached data may not be up to date, or otherwise not be authoritative. Some comments to that effect, along with reasoning for why this may happen in the first place would be helpful. A quick scan of 4511 and 4512 didn't turn up much about this, other than some passing references that some servers may shadow or cache dats from other servers., and not to accept modification requests against cached or shadowed data. Is there any other specification about LDAP cacheing, maintaining cache freshness, etc? I get a gut feeling that this extension effectively patches a hole in an implied delegation model for LDAP, but I don't find much in the way of explicit specification for that in the referenced docs (Maybe I should be looking at X.500 specs?). I'm not saying that this document should be burdened with a formal specification of the LDAP delegation model. But I think a little more context would be helpful. I'd also like to see some more guidance on when it's reasonable to use this extension. For example, wouldn't a client always want an authoritative answer to an interrogation? Why wouldn't it use this extension all the time? Does it hurt anything if it does? -- section 3, 2nd paragraph: I think this paragraph might be better restated normatively. -- section 4: The security consideration comments seem to be about caching in general. Does this extension make things any better or worse? RFC4510 has nothing to say about security beyond referring the reader to the security considerations in the technical specs. Nits/editorial comments: -- General There seems to be inconsistent use of the terms copy, shadow, cache, original , and master between this draft and RFC 4510 and 4512. Maybe adding these terms to the terminology sections would help. -- Section 1, paragraph 3: Please expand DN on first use. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-dime-rfc3588bis-25.txt (Diameter Base Protocol) to Proposed Standard
The IESG has received a request from the Diameter Maintenance and Extensions WG (dime) to consider the following document: - 'Diameter Base Protocol' draft-ietf-dime-rfc3588bis-25.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 2010-10-25. 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 https://datatracker.ietf.org/doc/draft-ietf-dime-rfc3588bis/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dime-rfc3588bis/ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-dime-rfc3588bis-25.txt (Diameter Base Protocol) to Proposed Standard
The IESG has received a request from the Diameter Maintenance and Extensions WG (dime) to consider the following document: - 'Diameter Base Protocol' draft-ietf-dime-rfc3588bis-25.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 2010-10-25. 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 https://datatracker.ietf.org/doc/draft-ietf-dime-rfc3588bis/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dime-rfc3588bis/ No IPR declarations were found that appear related to this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
IESG Statement on Document Shepherds
This statement provides guidance from the IESG on selection of a Document Shepherd for documents from IETF working groups and documents from individuals. RFC 4858 defines the role of the Document Shepherd for documents from IETF working groups, and it also says: The Document Shepherd is usually a chair of the working group that has produced the document. In consultation with the Responsible Area Director, the chairs may instead decide to appoint the working group secretary as the responsible Document Shepherd. Experience has shown that a successful Document Shepherd need not be the working group chair or secretary. In fact, the IESG encourages the working group chair to select an active working group participant that has strong understanding of the document content, is familiar with the document history, and is familiar with the IETF standards process. The Document Shepherd of a working group document should not be an author or editor of the document. Not all individual submissions have a Document Shepherd other than an author or editor of the document. When there is one, the Document Shepherd is selected by the Responsible Area Director in consultation with the document authors or editors. The Document Shepherd prepares a publication request write-up. The template for the write-up can be found here: For working group documents: http://www.ietf.org/iesg/template/doc-writeup.html For individual documents: http://www.ietf.org/iesg/template/individual-doc-writeup.html ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Re: Informational RFC to be: draft-livingood-web-notification-09.txt
The IESG has no problem with the publication of 'Comcast's Web Notification System Design' draft-livingood-web-notification-09.txt as an Informational RFC. The IESG would also like the RFC-Editor to review the comments in the datatracker (https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=19102rfc_flag=0) 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. The IESG contact person is Peter Saint-Andre. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-livingood-web-notification-09.txt The process for such documents is described at http://www.rfc-editor.org/indsubs.html. Thank you, The IESG Secretary RFC Editor Note The IESG has concluded that there is no conflict between this document and IETF work. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-geopriv-rfc3825bis-12.txt (Dynamic Host Configuration Protocol Options for Coordinate-based Location Configuration Information) to Proposed Standard
The IESG has received a request from the Geographic Location/Privacy WG (geopriv) to consider the following document: - 'Dynamic Host Configuration Protocol Options for Coordinate-based Location Configuration Information' draft-ietf-geopriv-rfc3825bis-12.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 2010-10-25. 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 https://datatracker.ietf.org/doc/draft-ietf-geopriv-rfc3825bis/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-geopriv-rfc3825bis/ No IPR declarations were found that appear related to this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
