Re: Can the RIRs bypass the IETF and do their own thing?
On 2007-05-11 23:32, JORDI PALET MARTINEZ wrote: I've already indicated this in previous occasions, but may be not in ppml ... We are proceeding in parallel, with the ID and the PDP at the same time. Nothing in the PDP precludes doing so. The RIRs don't depend on IETF at all, they can define global policies for things that the IETF failed to complete if that's the case. IANA can be instructed the same by the RIRs (which a global policy) than by the IETF itself with an RFC. Not quite. The RIRs have authority delegated to them by IANA, and IANA operates under the terms of its MoU and SLA with the IETF. So the RIRs' scope is to set and implement policy within their delegated authority, which itself has to be within the terms of the IANA MoU and SLA. In this case, I would check out section 4.3 of RFC 2860, especially the clause (b) in the second paragraph. It's clear to me that centrally- allocated ULAs are in IETF scope under that clause. That being said, there's no conceivable problem with a draft being developed by any set of people that want to do so, and the RIR people are obviously strongly motivated to do so in this case. (Personally, I see little need for it, since the existing pseudo-random ULAs are good enough for any practical purpose, but that is a discussion we can have in the IETF once there is a draft to discuss.) Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Can the RIRs bypass the IETF and do their own thing?
On 2007-05-11 16:14, Fred Baker wrote: ... One technical question I would ask. What does a Central Authority and IANA Assignment have to do with a Local address of any type? It seems in context that the major issue is an address prefix that is not advertised to neighboring ISPs and can be generally configured to be refused if offered by a neighboring ISP, in the same way that an RFC 1918 address is not advertised and is generally refused between IPv4 networks. In any draft on this topic, regardless of where it is discussed, if central assignment is in view, the reason for having such assignment should be clearly stated. Fred, the point is that ULAs should be unambiguous, so that if they happen to meet (e.g. via a VPN, or following a merge of two previously separate networks) there is no collision. Currently ULAs include a pseudo-random prefix, which leaves open a theoretical possibility of collision. Centrally-allocated ULAs would not have this issue. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Can the RIRs bypass the IETF and do their own thing?
Thus spake Brian E Carpenter [EMAIL PROTECTED] Fred, the point is that ULAs should be unambiguous, so that if they happen to meet (e.g. via a VPN, or following a merge of two previously separate networks) there is no collision. Currently ULAs include a pseudo-random prefix, which leaves open a theoretical possibility of collision. Centrally-allocated ULAs would not have this issue. The chance is negligible until you have a number of organizations interconnecting that approaches the AS count on the public Internet. Those who are uncomfortable with those odds can get PIv6 space. ULA Central does not solve any problems that the existing tools already solve, and it creates new problems of its own. S Stephen Sprunk Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do. K5SSS --Isaac Asimov ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [ppml] Can the RIRs bypass the IETF and do their own thing?
Thus spake Stephen Sprunk [EMAIL PROTECTED] ULA Central does not solve any problems that the existing tools already solve, and it creates new problems of its own. That should be don't already solve. S Stephen Sprunk Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do. K5SSS --Isaac Asimov ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [address-policy-wg] Re: Can the RIRs bypass the IETF and do their own thing?
On 2007-05-14 16:08, Shane Kerr wrote: Brian, On Mon, May 14, 2007 at 01:34:31PM +0200, Brian E Carpenter wrote: On 2007-05-11 23:32, JORDI PALET MARTINEZ wrote: The RIRs don't depend on IETF at all, they can define global policies for things that the IETF failed to complete if that's the case. IANA can be instructed the same by the RIRs (which a global policy) than by the IETF itself with an RFC. Not quite. The RIRs have authority delegated to them by IANA, and IANA operates under the terms of its MoU and SLA with the IETF. So the RIRs' scope is to set and implement policy within their delegated authority, which itself has to be within the terms of the IANA MoU and SLA. The RIRs authority comes from their communities, not from IANA. That's what bottom-up means. We're both right. It works because there is a wide consensus to both listen to the community and respect the mechanisms in place. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [address-policy-wg] Re: Can the RIRs bypass the IETF and do their own thing?
Brian, On Mon, May 14, 2007 at 01:34:31PM +0200, Brian E Carpenter wrote: On 2007-05-11 23:32, JORDI PALET MARTINEZ wrote: The RIRs don't depend on IETF at all, they can define global policies for things that the IETF failed to complete if that's the case. IANA can be instructed the same by the RIRs (which a global policy) than by the IETF itself with an RFC. Not quite. The RIRs have authority delegated to them by IANA, and IANA operates under the terms of its MoU and SLA with the IETF. So the RIRs' scope is to set and implement policy within their delegated authority, which itself has to be within the terms of the IANA MoU and SLA. The RIRs authority comes from their communities, not from IANA. That's what bottom-up means. Many industries need a neutral organisation to do business. Airlines have a system to handle reservations. Many industries use the ISO to set standards (paint colour, carpet thickness, and so on). Universities have accreditation bodies to insure a certain quality of education. And so on. The ISPs of the world need someone to handle resource allocation. The RIRs do that. They also do a bunch of other stuff. Really, the RIRs' scope is whatever their communities think it should be. If the RIRs decide to allocate numbers from dead:beef::/32 based on lunar tides, then the IETF and IANA and ICANN can complain about it all day long, but it's not their decision to make. Of course they can participate in the policy making process like everyone else. :) -- Shane ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-taylor-megaco-obsol3525 (Reclassification of RFC 3525 to Historic) to Historic
The intended status of the draft itself is Informational rather than Historic, surely? The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Reclassification of RFC 3525 to Historic ' draft-taylor-megaco-obsol3525-01.txt as a Historic 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 2007-06-08. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-taylor-megaco-obsol3525-01.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=15996rfc_flag=0 ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Use of LWSP in ABNF -- consensus call
The IESG reviewed http://www.ietf.org/internet-drafts/draft-crocker- rfc4234bis-00.txt for publication as Internet Standard and would like to know if there is consensus to recommend against the use of LWSP in future specifications, as it has caused problems recently in DKIM and could cause problems in other places. Some discussion on this point already: - http://www1.ietf.org/mail-archive/web/ietf/current/msg46048.html - http://www1.ietf.org/mail-archive/web/discuss/current/msg00463.html - http://mipassoc.org/pipermail/ietf-dkim/2007q1/007295.html - https://datatracker.ietf.org/public/pidtracker.cgi? command=view_commentid=66440 (in this tracker comment, Chris Newman recommended to remove LWSP, but for backward-compatibility it's probably better to keep it and recommend against use) Thanks for your input, Lisa Dusseault ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Use of LWSP in ABNF -- consensus call
Lisa Dusseault wrote: The IESG reviewed http://www.ietf.org/internet-drafts/draft-crocker-rfc4234bis-00.txt for publication as Internet Standard and would like to know if there is consensus to recommend against the use of LWSP in future specifications, as it has caused problems recently in DKIM and could cause problems in other places. Some discussion on this point already: - http://www1.ietf.org/mail-archive/web/ietf/current/msg46048.html - http://www1.ietf.org/mail-archive/web/discuss/current/msg00463.html - http://mipassoc.org/pipermail/ietf-dkim/2007q1/007295.html - https://datatracker.ietf.org/public/pidtracker.cgi?command=view_commentid=66440 (in this tracker comment, Chris Newman recommended to remove LWSP, but for backward-compatibility it's probably better to keep it and recommend against use) I agree that LWSP can be problematic. As the LWSP rule only appears in appendix B, the best approach IMHO would be to either leave it in, and have a warning explaining the potential problems close to it, or remove it. The latter sounds simpler, but could cause spec writers that use ABNF to just copy the LWSP rule from RFC4234, ignoring the potential issues with it. The proposed solution to warn about it in the front matter doesn't seem to be a good idea due to locality reasons. If there are reasons to avoud LWSP, they should be stated close to the definition. If this means we need a new revision of the spec, and last-call it again, so be it. No reason to hurry. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Use of LWSP in ABNF -- consensus call
Lisa Dusseault wrote: The IESG reviewed http://www.ietf.org/internet-drafts/draft-crocker-rfc4234bis-00.txt for publication as Internet Standard and would like to know if there is consensus to recommend against the use of LWSP in future specifications, Lisa, Process: 1 This issue was initially raised in the IESG by Chris Newman, who changed his Discuss, with a statement that he recommended inserting a comment, along the lines that others are also recommending. Unless I've misread the record, all other votes on advancing ABNF from Draft to Full are positive or neutral,. except for your own Discuss. Is this correct? 2. The ABNF is a candidate for moving from Draft to Full. Will removing a rule (that is already in use?) or otherwise changing the semantics of the specification, at this point, still permit the document to advance? I had the impression that moving to Full was based on some serious beliefs about a specification's being quite stable. Making this kind of change, this late in the game, would seem to run counter to that. as it has caused problems recently in DKIM and could cause problems in other places. Semantics: Could cause problems in other places... The DKIM hiccup was the first one I'd heard about. By contrast, linear-white-space was defined in RFC733, in 1977, with RFC822 retaining that definition. It is defined in those places as essentially the same as LWSP in the current ABNF Draft Standard specification. This seems to be one LWSP problem in 30 years. Is this really a sufficient basis for changing the semantics of something that has been stable and widely used for 10-30 years (depending upon how you count)? Are we reasonably comfortable that making the change will not create new and different problems, such as for other uses of ABNF? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Use of LWSP in ABNF -- consensus call
On May 14, 2007, at 3:55 PM, Dave Crocker wrote: Lisa Dusseault wrote: The IESG reviewed http://www.ietf.org/internet-drafts/draft- crocker-rfc4234bis-00.txt for publication as Internet Standard and would like to know if there is consensus to recommend against the use of LWSP in future specifications, 1 This issue was initially raised in the IESG by Chris Newman, who changed his Discuss, with a statement that he recommended inserting a comment, along the lines that others are also recommending. Unless I've misread the record, all other votes on advancing ABNF from Draft to Full are positive or neutral,. except for your own Discuss. Is this correct? The issue was initially raised by Frank Ellerman or by various in the DKIM WG depending on how you look at it -- Frank explicitly suggested possible changes to the draft, in his posting to the IETF list. You're right about the voting situation but here's the background: I took on the DISCUSS myself as a placeholder for an issue that the IESG had consensus to investigate further (consensus to investigate what the consensus is). I could have asked somebody else to hold the DISCUSS but this seemed most convenient as long as the rest of the IESG trusted me to investigate. 2. The ABNF is a candidate for moving from Draft to Full. Will removing a rule (that is already in use?) or otherwise changing the semantics of the specification, at this point, still permit the document to advance? I had the impression that moving to Full was based on some serious beliefs about a specification's being quite stable. Making this kind of change, this late in the game, would seem to run counter to that. Moving to Internet Standard is indeed something we do carefully, and of course that means investigating proposed changes to make sure they're appropriate, and setting a high bar for accepting them. I believe that's what we're doing here, investigating carefully. I share your concerns about removing rules that are already in use -- that would generally be a bad thing. However I'm interested in the consensus around whether a warning or a deprecation statement would be a good thing. Thanks, Lisa ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Use of LWSP in ABNF -- consensus call
Lisa Dusseault wrote: I share your concerns about removing rules that are already in use -- that would generally be a bad thing. However I'm interested in the consensus around whether a warning or a deprecation statement would be a good thing. LWSP has a valid meaning and use, and its being misapplied somewhere doesn't make that meaning and usage invalid. I could see a note being added. However, anything more than that is totally inappropriate. Tony Hansen [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-radext-fixes (Common RADIUS Implementation Issues and Suggested Fixes) to Proposed Standard
The IESG has received a request from the RADIUS EXTensions WG (radext) to consider the following document: - 'Common RADIUS Implementation Issues and Suggested Fixes ' draft-ietf-radext-fixes-03.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 [EMAIL PROTECTED] mailing lists by 2007-05-28. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-radext-fixes-03.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=15576rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-dhc-dhcpv6-leasequery (DHCPv6 Leasequery) to Proposed Standard
The IESG has received a request from the Dynamic Host Configuration WG (dhc) to consider the following document: - 'DHCPv6 Leasequery ' draft-ietf-dhc-dhcpv6-leasequery-00.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 [EMAIL PROTECTED] mailing lists by 2007-05-28. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-leasequery-00.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=15876rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-hip-applications (Using the Host Identity Protocol with Legacy Applications) to Experimental RFC
The IESG has received a request from the Host Identity Protocol WG (hip) to consider the following document: - 'Using the Host Identity Protocol with Legacy Applications ' draft-ietf-hip-applications-01.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 [EMAIL PROTECTED] mailing lists by 2007-05-28. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-hip-applications-01.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=15488rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-hip-dns (Host Identity Protocol (HIP) Domain Name System (DNS) Extensions) to Experimental RFC
The IESG has received a request from the Host Identity Protocol WG (hip) to consider the following document: - 'Host Identity Protocol (HIP) Domain Name System (DNS) Extensions ' draft-ietf-hip-dns-09.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 [EMAIL PROTECTED] mailing lists by 2007-05-28. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-hip-dns-09.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=12489rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-dhc-dhcpv6-ero (DHCPv6 Relay Agent Echo Request Option) to Proposed Standard
The IESG has received a request from the Dynamic Host Configuration WG (dhc) to consider the following document: - 'DHCPv6 Relay Agent Echo Request Option ' draft-ietf-dhc-dhcpv6-ero-01.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 [EMAIL PROTECTED] mailing lists by 2007-05-28. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-ero-01.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=15436rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'IMAP ANNOTATE Extension' to Experimental RFC
The IESG has approved the following document: - 'IMAP ANNOTATE Extension ' draft-ietf-imapext-annotate-16.txt as an Experimental RFC This document is the product of the Internet Message Access Protocol Extension Working Group. The IESG contact persons are Lisa Dusseault and Chris Newman. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate-16.txt Technical Summary The ANNOTATE extension to the Internet Message Access Protocol permits clients and servers to maintain meta data for messages, or individual message parts, stored in a mailbox on the server. For example, this can be used to attach comments and other useful information to a message. It is also possible to attach annotations to specific parts of a message, so that, for example, they could be marked as seen or important, or a comment added. Working Group Summary The IMAPEXT WG did a lot of good and careful work on this document. Very responsibly, the WG considered at the end whether this was actually going to be implemented. Although several client developers indicated a strong need for annotation functionality, few server developers were willing to commit to implementation (and deployment might be even worse). Thus, the WG reluctantly concluded to publish this as Experimental, hoping that some implementation experience will lead to a better understanding of what it takes to convince server implementors to do this functionality, along with what it takes to implement it robustly and in a decently performant fashion. Protocol Quality The IMAPEXT WG did as much work for this document as would be expected for a Proposed Standard, including Last Calls and several individual reviews. Lisa Dusseault reviewed this document for the IESG. Note to RFC Editor Please add the following paragraph to the abstract. NEW: Note that this document was the product of a WG which had good consensus on how to approach the problem. Nevertheless, the WG felt it did not have enough information on implementation and deployment hurdles to meet all the requirements of a Proposed Standard. The IETF solicits implementations and implementation reports in order to make further progress. Please add the following sub-section to section 7. NEW: 7.4 Capability registration This document registers ANNOTATE-EXPERIMENT-1 as an IMAPEXT capability in http://www.iana.org/assignments/imap4-capabilities. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
