Re: WG Review: Recharter of Internet Emergency Preparedness (ieprep)
On Wed, 1 Nov 2006, Sam Hartman wrote: I don't believe the new charter of ieprep working group belongs in the IETF. I understand why we chartered it here, and I believe that by doing as much work as we have done so far in the IETF, we have done something useful. We've described the broad problem and have helped to explain how it fits in the Internet context. That was an important thing for us to do. I think I'll agree with Sam. Having looked at the output of the WG, it already seems to include a couple of useful framework documents and about 4 requirements documents. This should already provide sufficient information how to continue the work. What isn't clear to me is what's the deployment level of these frameworks and various mechanisms. We seem to have spent at least ~4 years on this. Overprovisioning and intra-domain TE seems to have been a popular approach, but apart from that, where has this been deployed and how? Maybe we should let ITU, vendors, and/or deploying organizations to apply the existing techniques and frameworks, let this rest for 5 years and then come back to look if there is something more to be said on the subject. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Recharter of Internet Emergency Preparedness (ieprep)
Excerpts from Sam Hartman on Wed, Nov 01, 2006 04:34:20PM -0500: [I could not find the ITU's liaison to the IETF. Scott, if such exists, I'd appreciate you forwarding this to them.] The ITU-T's liaison from SG13 to the IETF is Hui-Lan Lu. CCed. FYI SG13 is about to send something to the IETF asking for help on technical issues in emergency telecommunications. I'll ask them to expedite it but you shouldn't expect it before the middle of next week. swb Hi. I'm speaking here as an individual. I'd like to build consensus for my position both within the IESG and within the community, but I realize that if I fail to build that consensus, I cannot make this objection as a single IESG member. I don't believe the new charter of ieprep working group belongs in the IETF. I understand why we chartered it here, and I believe that by doing as much work as we have done so far in the IETF, we have done something useful. We've described the broad problem and have helped to explain how it fits in the Internet context. That was an important thing for us to do. However the work that remains belongs somewhere else--probably the ITU-T. I propose that we work with ITU to see if they are interested in the work and if so, use this as an opportunity to foster cooperation with work going to the ITU. In order for the proposed charter to be successful, the working group will need to go far outside the IETF's normal technical mandate and venture into the space of network design to come up with requirements documents. The technical aspects of this problem are only one of the things going into successful requirements. Based on my limited knowledge I believe that the ITU is in a better position than the IETF to specify requirements and mechanisms for national and government telecommunications networks. I think we should let them do their job just as we ask them to let us do our job and to design the technical protocols that are increasingly being used on those networks. Naturally, the IETF should make any necessary modifications to IETF protocols to implement IEPREP work regardless of where it takes place. The main argument I've heard throughout the existence of ieprep for why it needed to happen in the IETF is that if it happens elsewhere, they'll do something we don't like or do it wrong. Perhaps that was once a valid argument. However, I think we have enough of the details of technical approaches that we find appropriate documented that we can give sufficient input to another body on what approaches work on the Internet. I would assume we'd ask people working in this space to take a look at the existing ieprep output, RFC 4542, RFC 4411, draft-ietf-tsvwg-vpn-signal-preemption and other appropriate documents. I think that given this input another group could understand what works well on the internet and could work both on requirements related to the technology as well as the overall system architecture so we end up with deployable solutions at national and governmental levels. In addition, I believe that since the first part of the ieprep work happened here, we would be in a good position to work with whatever standards body did the work to scope the charter to favor technologies that would work well on the Internet. Thanks for your consideration, --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
FW: [Hubmib] Last Call: 'Managed Objects of EPON' to Proposed Standard (draft-ietf-hubmib-efm-epon-mib)
1. I find the security considerations section to be incomplete. What is missing is a description of the security risks encountered by the malicious or accidental mis-configuration of the read-write objects that are listed. For example ' Changing dot3MpcpAdminState state can lead to disabling the Multi-point control protocol on the respective interface leading to the interruption of service of the users connected to the respective EPON interface'. 2. Parts of the document and especially the DESCRIPTION clauses of the MIB objects need to undergo a serious English syntax checking. Although we can assume that the RFC Editor will anyway perform its editorial duties it would be better to have a native English speaker go through this process in advance, rather than having too consistent changes made in final RFC Editor controlled phases. Dan -Original Message- From: The IESG [mailto:[EMAIL PROTECTED] Sent: Thursday, October 19, 2006 11:02 PM To: IETF-Announce Cc: hubmib@ietf.org Subject: [Hubmib] Last Call: 'Managed Objects of EPON' to Proposed Standard (draft-ietf-hubmib-efm-epon-mib) The IESG has received a request from the Ethernet Interfaces and Hub MIB WG to consider the following document: - 'Managed Objects of EPON ' draft-ietf-hubmib-efm-epon-mib-05.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 any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-11-02. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-hubmib-efm-epon-mib-05.tx t ___ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Encouraging nominations for IETF Chair
This is to let the community know that I am *not* available for another term as IETF Chair. This was not a quick decision, and it's due to a combination of professional and personal circumstances. Also, I will soon complete a total of ten years in the IAB and IESG combined, and I believe that is as long as is appropriate for any one individual to serve. I strongly encourage the community to help the Nominating Committee by nominating good candidates. You only have another two weeks to do so. Please see http://www.ietf.org/nomcom/index.html and in particular https://datatracker.ietf.org/public/show_nomcom_message.cgi?id=1033 By the way, it's been a pleasure and an honour, and I do intend to keep working hard until next March. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Scary technology
On Wed, Nov 01, 2006 at 12:10:16AM -0800, Fred Baker wrote: if routing protocols aren't scary enough for you... http://money.cnn.com/popups/2006/fortune/scary_tech/index.html Unexpected failure modes led to the early withdrawal of IPv5 -- Tim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
re: WG Review: Recharter of Internet Emergency Preparedness (ieprep)
Sam,One of the objectives of the work produced by IEPREP was to lay down the ground work and put together a baseline set of requirements to start with when considering solutions. Our intention was that the baseline then becomes a starting point where more specific requirements can be put forth. Outside of this, solutions were definitely out of scope.My understanding is that there are others that now wish to present some more specific requirements and potential solutions that do not fall into the scope of other working groups. So the proposed re-charter looks to be a natural extension to what has been done.Interestingly enough, the work that you mention below in your original posting...snip"I would assume we'd ask people working in this space totake a look at the existing ieprep output, RFC 4542, RFC 4411,draft-ietf-tsvwg-vpn-signal-preemption and other appropriatedocuments."... rfc-4542, rfc-4411, and draft -ietf-tsvwg-vpn-signal-preemption (along with some other related work) has actually not been done in IEPREP because the group was not allowed to consider solutions. Instead, some of the work has been pushed to TSVWG, to the groans and sometimes confusion of some of the participants of that group, who wondered what the subject of prioritization had to do with TSVWG. Part of the revised charter is meant to remove this obstacle.Also, as Scott Brimm has mentioned, there is a proposed liaison from the ITU to work with the IETF, with one of the working groups of interest being IEPREP. It would seem odd to close down the group and punt the subject to them when they are approaching "us" for assistance If IEPREP is closed, does that mean the subject gets pushed over to TSVWG?-ken___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Recharter of Internet Emergency Preparedness (ieprep)
At 12:41 PM 11/2/2006 +0200, Pekka Savola wrote: On Wed, 1 Nov 2006, Sam Hartman wrote: I don't believe the new charter of ieprep working group belongs in the IETF. I understand why we chartered it here, and I believe that by doing as much work as we have done so far in the IETF, we have done something useful. We've described the broad problem and have helped to explain how it fits in the Internet context. That was an important thing for us to do. I think I'll agree with Sam. I do not agree with Sam Having looked at the output of the WG, it already seems to include a couple of useful framework documents and about 4 requirements documents. the framework RFCs are for within a single public domain. The other RFCs are requirements based. There is no architecture guidelines docs or peering guidelines or the like. This is because the charter of the past didn't allow such work. This new charter was supposed to allow such work AND investigate if protocol mods were needed to accomplish those arch and peering guideline efforts. This should already provide sufficient information how to continue the work. continue the work where? by who? by another SDO? Why? What isn't clear to me is what's the deployment level of these frameworks and various mechanisms. there are no various mechanisms defined, there are only framework and requirements. Little can be accomplished with just that IMO. We seem to have spent at least ~4 years on this. with both hands tied behind our backs, typing with with toes (so to speak). Overprovisioning and intra-domain TE seems to have been a popular approach, in which IEPREP doc was Overprovisioning and intra-domain TE discussed? but apart from that, where has this been deployed and how? Maybe we should let ITU, vendors, and/or deploying organizations to apply the existing techniques What techniques have been defined? I believe folks are assuming IEPREP has accomplished more than it was allowed to accomplish to date, and they ought to walk before they are allowed to run. A framework doesn't allow IEPREP to even walk. IEPREP was so constrained RFC 4542 had to be driven through another WG (TSVWG) because it wasn't allowed in IEPREP. Strike that, it would be allowed, but it would still be an individual ID because the charter wouldn't allow it to be a WG item even today. SPeaking of RFC4542, it was a INFO instead of a BCP because of the IESG, which didn't want an explanation of more than a dozen EXISTING mechanisms and techniques to be considered a BCP (isn't that by definition a BCP explaining how to put together a series of standards track RFCs?). and frameworks, let this rest for 5 years and then come back to look if there is something more to be said on the subject. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Recharter of Internet Emergency Preparedness (ieprep)
James == James M Polk [EMAIL PROTECTED] writes: James At 12:41 PM 11/2/2006 +0200, Pekka Savola wrote: On Wed, 1 Nov 2006, Sam Hartman wrote: I don't believe the new charter of ieprep working group belongs in the IETF. I understand why we chartered it here, and I believe that by doing as much work as we have done so far in the IETF, we have done something useful. We've described the broad problem and have helped to explain how it fits in the Internet context. That was an important thing for us to do. I think I'll agree with Sam. James I do not agree with Sam Having looked at the output of the WG, it already seems to include a couple of useful framework documents and about 4 requirements documents. James the framework RFCs are for within a single public domain. James The other RFCs are requirements based. James There is no architecture guidelines docs or peering James guidelines or the like. Why does that belong in the IETF? RFC 2418 gives a good set of things to consider for determining whether work belongs in the IETF. I will try to write up a guideline by guideline analysis of this work, although when I briefly examine the guidelines my continuing reaction is that the work probably does not belong in the IETF. If you have time to write up such an analysis I'd be interested in what you come up with. This should already provide sufficient information how to continue the work. James continue the work where? by who? by another SDO? Why? My proposal is ITU-T--probably SG 13, although I don't understand ITU internals enough to know for sure that's the right place. Obviously, this assumes they want to do the work. To propose concrete action, I think the IETF should draft a liaison statement for action to the ITU asking for them to comment on whether they see any current conflicts and on whether there are parts of this work they would be interested in picking up. Such liaisons are not uncommon when appropriate; we had such an exchange with IEEE when the trill working group was formed. If the ITU says that they're not interested in these aspects of the work, and no one else makes an alternative proposal, then I would not object to the work being chartered in the IETF. However if the ITU would be interested in working on this problem space (or especially is already work on this problem space), we need to carefully ask ourselves why each aspect of the work being done in the IETF belongs here. --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Recharter of Internet Emergency Preparedness (ieprep)
ken == ken carlberg [EMAIL PROTECTED] writes: ken Sam, One of the objectives of the work produced by IEPREP was ken to lay down the ground work and put together a baseline set ken of requirements to start with when considering solutions. ken Our intention was that the baseline then becomes a starting ken point where more specific requirements can be put forth. ken Outside of this, solutions were definitely out of scope. ken My understanding is that there are others that now wish to ken present some more specific requirements and potential ken solutions that do not fall into the scope of other working ken groups. So the proposed re-charter looks to be a natural ken extension to what has been done. ken Interestingly enough, the work that you mention below in your ken original posting... ken ... rfc-4542, rfc-4411, and draft ken -ietf-tsvwg-vpn-signal-preemption (along with some other ken related work) has actually not been done in IEPREP because ken the group was not allowed to consider solutions. Instead, ken some of the work has been pushed to TSVWG, to the groans and ken sometimes confusion of some of the participants of that ken group, who wondered what the subject of prioritization had to ken do with TSVWG. Part I think the work you cite belongs in tsvwg. AT least 4542 and vpn-signaling-preemption. ken of the revised charter is meant to ken remove this obstacle. Which work would be permitted under the revised charter that is currently udone elsewhere? I may have more concerns about the revised charter than I thought I did. ken Also, as Scott Brimm has mentioned, there is a proposed ken liaison from the ITU to work with the IETF, with one of the ken working groups of interest being IEPREP. It would seem ken odd to close down the group and punt the subject to them when ken they are approaching us for assistance If IEPREP is ken closed, does that mean the subject gets pushed over to TSVWG? that rather depends on what question they're asking, now doesn't it? IF they're asking for enhancements to RSVP to deal with some ETS issues, then yes, I'd hope the work would be done in tsvwg. That way, ETS requirements can be balanced against other requirements. If they want to change SIP, I'd hope that it would go through sipping and eventually sip. If they want us to do non-protocol work closer to 4542, then perhaps we need a WG to do it in. --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Recharter of Internet Emergency Preparedness (ieprep)
ken Interestingly enough, the work that you mention below in your ken original posting... ken ... rfc-4542, rfc-4411, and draft ken -ietf-tsvwg-vpn-signal-preemption (along with some other ken related work) has actually not been done in IEPREP because ken the group was not allowed to consider solutions. Instead, ken some of the work has been pushed to TSVWG, to the groans and ken sometimes confusion of some of the participants of that ken group, who wondered what the subject of prioritization had to ken do with TSVWG. Part I think the work you cite belongs in tsvwg. AT least 4542 and vpn-signaling-preemption. I mentioned the above as examples, not as a case-by-case examination of what should or should not be in IEPREP. But along those lines, rfc-4542 (titled Implementing an Emergency Telecommunications Service), where ETS was first established in IEPREP and the draft deals with priority and preemption, seems odd to me to be in TSVWG. But if you feel differently, then we agree to disagree. ken of the revised charter is meant to ken remove this obstacle. Which work would be permitted under the revised charter that is currently udone elsewhere? I may have more concerns about the revised charter than I thought I did. I am not speaking of any specific work other than what has been discussed in the proposed re-charter. to consider otherwise is to go beyond what I stated. ken Also, as Scott Brimm has mentioned, there is a proposed ken liaison from the ITU to work with the IETF, with one of the ken working groups of interest being IEPREP. It would seem ken odd to close down the group and punt the subject to them when ken they are approaching us for assistance If IEPREP is ken closed, does that mean the subject gets pushed over to TSVWG? that rather depends on what question they're asking, now doesn't it? IF they're asking for enhancements to RSVP to deal with some ETS issues, then yes, I'd hope the work would be done in tsvwg. That way, ETS requirements can be balanced against other requirements. If they want to change SIP, I'd hope that it would go through sipping and eventually sip. we will have to wait to see what they request. all I stated was that they were coming to us and that it was odd to close down a group they were interested in working with. Anticipating hypotheticals are not useful because they can put us down a rat hole that may or may not have substance. -ken ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Recharter of Internet Emergency Preparedness (ieprep)
On Thu, 2 Nov 2006, James M. Polk wrote: Having looked at the output of the WG, it already seems to include a couple of useful framework documents and about 4 requirements documents. the framework RFCs are for within a single public domain. The other RFCs are requirements based. There is no architecture guidelines docs or peering guidelines or the like. I guess by 'architecture guidelines' you refer to inter-domain guidelines as the framework RFCs already seem to deal at least to some extent with a single domain. If you don't, you may mean something that operators would use. It's not clear if one-size-fits-all guidelines could be made, or if this would be right place to try to seek it. Is there already sufficient experience of getting multi-domain work? AFAICS, this hasn't generally been considered an easily solvable problem at an operational level. Peering guidelines likely don't belong to the IETF, or has there been successful precendent for that kind of work in the past? (I could say some examples, but I don't think those were very succesful, and those were from OPS area) Even if this work was in the scope of IETF, at least these two seem more like subjects to be pursued in the OpsMgmt area. This should already provide sufficient information how to continue the work. continue the work where? by who? by another SDO? Why? Other SDOs if they're willing. Organizations that actually want to deploy this stuff (if those exist in sufficient degree). Vendors who want to push for this stuff. That is to say -- is there enough deployment (and understanding what works and is deployable and what isn't) to justify more IETF work on the subject _right now_ ? Overprovisioning and intra-domain TE seems to have been a popular approach, in which IEPREP doc was Overprovisioning and intra-domain TE discussed? draft-ietf-ieprep-domain-frame-07.txt, RFC4190, RFC43745 to name a few. but apart from that, where has this been deployed and how? Maybe we should let ITU, vendors, and/or deploying organizations to apply the existing techniques What techniques have been defined? The framework documents talk a lot about certain kinds of DSCP PHBs, mappings between PSTN and VoIP, a particular end-to-end priority field, MPLS-like traffic engineering, access-controls to prevent DoSing priority treatment, active queue management techniques, drop priority techniques, etc. -- this already seems to be a significant toolbox. It is not clear to me to what extent these have been used and do the job set out for IEPREP. And if not, is the lack of use due to people solving the problem in other ways (or not at all) rather than the lack of mechanisms? -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
hokeyp and MIP6 slots are colliding
Any chance to move one of hokeyp and MIP6 to a different slot so they are not colliding?? Thanks, Madjid ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Weekly posting summary for ietf@ietf.org
Total of 51 messages in the last 7 days. script run at: Fri Nov 3 00:03:02 EST 2006 Messages | Bytes| Who +--++--+ 7.84% |4 | 6.32% |17922 | [EMAIL PROTECTED] 5.88% |3 | 5.62% |15958 | [EMAIL PROTECTED] 5.88% |3 | 5.13% |14540 | [EMAIL PROTECTED] 3.92% |2 | 5.48% |15533 | [EMAIL PROTECTED] 3.92% |2 | 5.25% |14890 | [EMAIL PROTECTED] 3.92% |2 | 4.39% |12466 | [EMAIL PROTECTED] 3.92% |2 | 4.37% |12384 | [EMAIL PROTECTED] 3.92% |2 | 4.29% |12174 | [EMAIL PROTECTED] 3.92% |2 | 4.05% |11502 | [EMAIL PROTECTED] 3.92% |2 | 3.95% |11218 | [EMAIL PROTECTED] 3.92% |2 | 3.57% |10125 | [EMAIL PROTECTED] 3.92% |2 | 3.51% | 9958 | [EMAIL PROTECTED] 3.92% |2 | 3.43% | 9728 | [EMAIL PROTECTED] 3.92% |2 | 3.26% | 9257 | [EMAIL PROTECTED] 3.92% |2 | 3.13% | 8887 | [EMAIL PROTECTED] 3.92% |2 | 3.08% | 8744 | [EMAIL PROTECTED] 1.96% |1 | 2.99% | 8479 | [EMAIL PROTECTED] 1.96% |1 | 2.91% | 8246 | [EMAIL PROTECTED] 1.96% |1 | 2.82% | 8000 | [EMAIL PROTECTED] 1.96% |1 | 2.59% | 7337 | [EMAIL PROTECTED] 1.96% |1 | 2.42% | 6866 | [EMAIL PROTECTED] 1.96% |1 | 2.23% | 6314 | [EMAIL PROTECTED] 1.96% |1 | 2.14% | 6071 | [EMAIL PROTECTED] 1.96% |1 | 2.06% | 5842 | [EMAIL PROTECTED] 1.96% |1 | 1.71% | 4854 | [EMAIL PROTECTED] 1.96% |1 | 1.70% | 4810 | [EMAIL PROTECTED] 1.96% |1 | 1.67% | 4727 | [EMAIL PROTECTED] 1.96% |1 | 1.59% | 4520 | [EMAIL PROTECTED] 1.96% |1 | 1.58% | 4487 | [EMAIL PROTECTED] 1.96% |1 | 1.44% | 4074 | [EMAIL PROTECTED] 1.96% |1 | 1.34% | 3792 | [EMAIL PROTECTED] +--++--+ 100.00% | 51 |100.00% | 283705 | Total ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Announcement of timeline for IAOC position selected by the IAB
The IAB is announcing its timeline for the appointment of a member of the IETF Administrative Oversight Committee (IAOC), as described in BCP 101 (RFC 4071) and in BCP 113 (RFC 4333). The IESG and the IAB each select one person for a two-year IAOC term in alternate years. This year, the IAB will select one person for a term ending in spring 2009. The IAB will issue a call for nominations on the ietf-announce@ietf.org list on November 17 with an open nomination period running until December 22. The names of all people who declare themselves willing to serve will be made public on the ietf-announce@ietf.org list after the end of the solicitation period (December 22). The IAB expects to announce its selection on January 29 (prior to the expected date at which the Nomcom will select its IAOC nominee). Leslie Daigle, Chair, IAB. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
