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
How does the IETF put a big red warning sign on a document produced by another standards body? http://tools.ietf.org/html/draft-bhh-mpls-tp-oam-y1731-07. Actual coloring of course is impossible. NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: size of the XML of IANA ports
Joe When I access it, I see a 3.08Mbyte .xml file in temporary storage. Interestingly, the text variant is still 2.7Mbyte. My access time is variable. When I first used the xml file, the access time was always in minutes, time to make a coffee, come back and continue waiting. Now it is variable. On a good day, I get a page I can scroll in 35 second, other times it is over 2 minutes. I don't see any reason why and my network and PC have not changed that I know of. I am on Windows and Internet Explorer. Interestingly, if I download a .pdf, I can track the download by looking at the size in temporary storage; I can do the same with the .txt, but not with the .xml, not sure what it means, perhaps that the processing is concurrent with the download, and that only the end result gets written to disk. The disk file is .xml and not .htm(l). Tom Petch Tom Petch - Original Message - From: Joe Touch to...@isi.edu To: Simon Perreault simon.perrea...@viagenie.ca Cc: ietf@ietf.org Sent: Wednesday, October 12, 2011 7:44 PM Subject: Re: size of the XML of IANA ports On 10/12/2011 10:28 AM, Simon Perreault wrote: As Julian said, what's slow is the browser rendering the HTML. More precisely, it's two things: 1. HTML parsing, especially in Safari 2. table layout rendering. Emperically: opening the file from disk = 30 seconds downloading the file from the net = 33 seconds I.e., they're both part of the problem. Joe ___ 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
Gen-ART Last Call review of draft-ietf-cuss-sip-uui-reqs-06
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-ietf-cuss-sip-uui-reqs-06 Reviewer: Ben Campbell Review Date: 2011-10-12 IETF LC End Date: 2011-10-13 Summary: This draft is almost ready for publication as an informational RFC. I have a few minor questions and comments that may be worth addressing first. Major issues: None Minor issues: -- section 1, 2nd paragraph, last sentence: In particular, this mechanism creates no requirements on intermediaries such as proxies. What about SBCs, B2BUAs, etc? -- REQ-4: … any other form of redirection of the request. Any other form seems a pretty strong statement. What about a b2bua doing weird stuff? -- REQ-8: If the UAS does not understand the UUI mechanism, the request will fail. Based on the routing requirement, shouldn't that say that if the request cannot be routed to a UAS that understands the UUI mechanism, the request will fail? -- REQ-12: What degree of certainty is required here? (i.e. strong identity?) If implied by the SIP dialog, does that impact expectations on what sort of authn must happen at the SIP layer? -- REQ 13: I'm not sure I understand how this interacts with the ability for intermediaries to remove UUI. Should this be detectable by the endpoints? Or is that ability limited to the hop-by-hop case, or require no integrity protection? Nits/editorial comments: -- section 4, 2nd paragraph: The UUI mechanisim should support both of these approaches Should that be a numbered requirement? You've got requirements to support e2e and hop-by-hop, but no requirement that mentions SIP layer vs application layer. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: meeting slots
I understand Dave's concern, but I think it would be valuable to make it easy to see what has been requested. Any changes to the conflict list would still have to come through the chairs, encouraging that distributed work model. I've entered this as an idea that someone might pick up for work at a codesprint: http://trac.tools.ietf.org/tools/ietfdb/ticket/710 RjS On Oct 12, 2011, at 8:53 PM, John C Klensin wrote: --On Wednesday, October 12, 2011 11:11 -0700 Dave CROCKER d...@dcrocker.net wrote: On 10/12/2011 10:27 AM, Margaret Wasserman wrote: I was not picturing everyone adding their own conflicts. However, I thought this might help us avoid some of the issues we've had in the past, where obvious group-level conflicts are omitted, and meetings have to be rescheduled at the last moments. I'll suggest a more distributed model: Chairs circulate among their wg, the conflicts they believe should be avoided. When that discussion settles down, the chairs submit their set to ietf staff. IETF staff and ietf main list are thereby spared the effort, but each set gets review beyond the chairs. Of course, some WGs / Chairs have been doing this, or variations on it. for some years now. I'd venture that it works better in some WGs than others... much like many other things. john ___ 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: size of the XML of IANA ports
On 10/13/11 03:41 , t.petch wrote: Joe When I access it, I see a 3.08Mbyte .xml file in temporary storage. Interestingly, the text variant is still 2.7Mbyte. My access time is variable. When I first used the xml file, the access time was always in minutes, time to make a coffee, come back and continue waiting. Now it is variable. On a good day, I get a page I can scroll in 35 second, other times it is over 2 minutes. I don't see any reason why and my network and PC have not changed that I know of. I am on Windows and Internet Explorer. Interestingly, if I download a .pdf, I can track the download by looking at the size in temporary storage; I can do the same with the .txt, but not with the .xml, not sure what it means, perhaps that the processing is concurrent with the download, and that only the end result gets written to disk. The disk file is .xml and not .htm(l). no mystery... What's been downloaded is the data, what's being saved is what the browser renders using the DTD. you're downloading structured data totalling some 15000 records and the browser is rendering it in a conveniently human readable form. Tom Petch Tom Petch - Original Message - From: Joe Touch to...@isi.edu To: Simon Perreault simon.perrea...@viagenie.ca Cc: ietf@ietf.org Sent: Wednesday, October 12, 2011 7:44 PM Subject: Re: size of the XML of IANA ports On 10/12/2011 10:28 AM, Simon Perreault wrote: As Julian said, what's slow is the browser rendering the HTML. More precisely, it's two things: 1. HTML parsing, especially in Safari 2. table layout rendering. Emperically: opening the file from disk = 30 seconds downloading the file from the net = 33 seconds I.e., they're both part of the problem. Joe ___ 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: size of the XML of IANA ports
Hi, all, Again, thanks for the suggestions. I'll work with IANA to see if we can make things a bit more useful. Joe On 10/13/2011 12:28 PM, Joel jaeggli wrote: On 10/13/11 03:41 , t.petch wrote: Joe When I access it, I see a 3.08Mbyte .xml file in temporary storage. Interestingly, the text variant is still 2.7Mbyte. My access time is variable. When I first used the xml file, the access time was always in minutes, time to make a coffee, come back and continue waiting. Now it is variable. On a good day, I get a page I can scroll in 35 second, other times it is over 2 minutes. I don't see any reason why and my network and PC have not changed that I know of. I am on Windows and Internet Explorer. Interestingly, if I download a .pdf, I can track the download by looking at the size in temporary storage; I can do the same with the .txt, but not with the .xml, not sure what it means, perhaps that the processing is concurrent with the download, and that only the end result gets written to disk. The disk file is .xml and not .htm(l). no mystery... What's been downloaded is the data, what's being saved is what the browser renders using the DTD. you're downloading structured data totalling some 15000 records and the browser is rendering it in a conveniently human readable form. Tom Petch Tom Petch - Original Message - From: Joe Touchto...@isi.edu To: Simon Perreaultsimon.perrea...@viagenie.ca Cc:ietf@ietf.org Sent: Wednesday, October 12, 2011 7:44 PM Subject: Re: size of the XML of IANA ports On 10/12/2011 10:28 AM, Simon Perreault wrote: As Julian said, what's slow is the browser rendering the HTML. More precisely, it's two things: 1. HTML parsing, especially in Safari 2. table layout rendering. Emperically: opening the file from disk = 30 seconds downloading the file from the net = 33 seconds I.e., they're both part of the problem. Joe ___ 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: [IETF] Re: watersprings.org archive of expired Internet Drafts
On Oct 7, 2011, at 5:36 AM, t.petch daedu...@btconnect.com wrote: I had been waiting a while for a quiet moment on the list to express my regret at the passing of Watersprings - R.I.P. Well, you will probably be glad to hear that it is in the process of being resurrected. It was down to save power after the tragic tsunami in Japan. Noritoshi is updating scripts to run under Linux, so it is not fully up / up to date... W Apart from I-D announcements that made to a WG list I track, then watersprings was my primary source for all I-D, simply because the web site was so good, probably as close to perfection as I will ever see. No thousands of .gif to spend ages downloading, no Megabytes of XML that take half an hour to process, no https that locks up the workstation more often than not, no need for a user manual to explain how to do what; just a simple, self-evident interface, as simple as it could be but no simpler (a paragon of engineering design) taking me to exactly what I needed, almost every time (no irtf, but I learnt to live with that). watersprings, you are sorely missed. Tom Petch - Original Message - From: Dan Wing dw...@cisco.com To: 'Tony Finch' d...@dotat.at; ietf@ietf.org Sent: Friday, September 30, 2011 6:58 PM Subject: [IETF] RE: watersprings.org archive of expired Internet Drafts -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Tony Finch Sent: Friday, September 30, 2011 7:34 AM To: ietf@ietf.org Subject: watersprings.org archive of expired Internet Drafts I have been using the watersprings.org archive of internet drafts http://www.watersprings.org/pub/id/ to obtain copies of drafts that are no longer available from http://www.ietf.org/internet-drafts/ However the domain watersprings.org has disappeared. Does anyone know what has happened to it and/or if it is likely to come back, or if there are alternative archives elsewhere? http://tools.ietf.org/html/DRAFTNAME works very well, and has everything near as I can tell. It also does partial matches on DRAFTNAME, so you can do http://tools.ietf.org/id/draft-*behave* to see everything with behave in the name. The HTML-ized version shows the history, provides clickable diff's, shows if it turned into an RFC, clickable Errata, Obsoleted By:, and so on. -d ___ 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: Last Call: draft-salter-rfc5430bis-01.txt (Suite B Profile for Transport Layer Security (TLS)) to Informational RFC
Nikos: The IESG has received a request from an individual submitter to consider the following document: - 'Suite B Profile for Transport Layer Security (TLS)' draft-salter-rfc5430bis-01.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-10-31. 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. A comment on this draft is that it might be misleading on the security levels it claims. It mentions: The Fact Sheet on Suite B Cryptography requires key establishment and authentication algorithms based on Elliptic Curve Cryptography and encryption using AES [AES]. Suite B algorithms are defined to support two minimum levels of security: 128 and 192 bits. However the (D)TLS Finished message is protected by a 96-bit MAC, thus an attacker that can break a 96-bit MAC can manipulate the TLS handshake in any way he desires (TLS version rollback, removal of extensions and possibly more). IMO this disqualifies the proposed ciphersuites from claiming more than 96-bits of security. It is important to distinguish between off-line and on-line attacks. It is common (though perhaps not universal) to rate the strength of cryptography in terms of resistance to off-line attack, and that is what Suite B minimum levels of security express. However, there is no commonly agreed metric for strength against on-line attacks. In practice, resistance to on-line attack can be pragmatically stronger than resistance to off-line attack, while appearing to be mathematically weaker. In TLS, there is no off-line attack against the MAC in the finished message. To test a trial guess, the attacker must present it to the intended recipient on-line. The protocol only allows one chance to get the finished message right. If the message does not verify, there is a fatal error, the connection is terminated and all cryptographic keys for the connection are discarded. To be secure, the probability of success has to be low enough to be operationally impractical, as opposed to being low enough to be technologically infeasible. One could argue that a 32-bit or 64-bit MAC would be plenty generous for security; however, RFC 5246 already specifies that the MAC be no shorter than 96 bits. That is more than enough to be suitable with ANY metric for on-line cryptographic strength, not just 128 or 192 bits needed for Suite B. Thanks for the review, Margaret Salter Russ Housley ___ 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
Below are my comments on this draft, these are in addition to the comments that I have provided previously. I also support the comments that propose the deletion of sections 4, 5 and 6. I have numbered my comments (1-12) to simplify identification for those who wish to respond. I do not support approval of this draft in its current form. Regards, Malcolm 1) Two encapsulations for PW OAM The draft provides the Reasons for Selecting a Single Solution for MPLS-TP OAM. However, two different encapsulations have been defined for OAM messages in the MPLS-TP PW. One uses just the ACh the other uses both the GAL and ACh. These two encapsulations must be identified and rationalized in the context of selecting a single solution. Particular attention should be paid to the text from RFC5317 quoted in section 1.1 “…the architecture allows for a single OAM technology for LSPs, PWs…” 2) Quote from RFC5317 Section 1.1 includes the following: [RFC5317] includes the analysis that it is technically feasible that the existing MPLS architecture can be extended to meet the requirements of a Transport profile, and that the architecture allows for a single OAM technology for LSPs, PWs, and a deeply nested network. The context of this quote from slide 113 should be clarified; slide 12 states of RFC 5317 states: This presentation is a collection of assumptions, discussion points and decisions that the combined group has had during the months of March and April, 2008 This represents the agreed upon starting point for the technical analysis of the T-MPLS requirements from the ITU-T and the MPLS architecture to meet those requirements Proposal: Insert the following text before the quoted text: [RFC 5317] provides a collection of assumptions, discussion points and decisions that the JWT has had during the months of March and April, 2008. This represents the agreed upon starting point for the technical analysis of the T-MPLS requirements from the ITU-T and the MPLS architecture to meet those requirements. Included in this analysis is the statement that it is technically feasible that the existing MPLS architecture can be extended to meet the requirements of a Transport profile, and that the architecture allows for a single OAM technology for LSPs, PWs, and a deeply nested network. 3) Section 1.2 The Development of a Parallel MPLS-TP OAM Solution The section should be deleted or rewritten since it includes a number of assertions that have not been substantiated and are not supported by a significant number of participants. 4) Consistent with existing MPLS OAM Section 3.3 states: Given this intention for compatibility, it follows that the MPLS-TP OAM protocols should be consistent with the existing, deployed MPLS OAM This statement requires further clarification and justification since: a) The existing MPLS OAM tools use an IP encapsulation, the MPLS-TP OAM tools use a GAL/ACh encapsulation; and: b) The only existing deployed OAM tools were BFD and LSP Ping, all the other OAM tools are new so it is difficult to understand the concept of compatible. 5) MPLS as a Convergence Technology Section 3.2 includes the statement: “When we arrive at our destination of TCP/IP/MPLS running directly over fiber, the operators will use MPLS OAM tools to make this work.” This statement is technically incorrect; MPLS must be encapsulated in a L2 and L1 protocol before it can be transmitted over a physical media. Further I have seen no evidence that network operator will use MPLS to maintain the optical network infrastructure e.g. amplifiers, WDM couplers etc. The section is based on the assumption that the network will rapidly converge to being just IP/MPLS. This is not a universally accepted view. Section 3.2 should be deleted. 6) Section 3.3 End to end OAM I agree that end to end OAM is important for maintaining a service. However, we also need OAM to maintain the transport infrastructure that is independent of the services (or even the presence of a service). Section 3.3 also states: This is a design paradigm that has guided the IETF in the development of its exiting network layer connectivity OAM protocols. For each network layer protocol there is only one ping, trace route, or fast connectivity protocol, and amongst these there is a common design approach. This is not correct the IETF have defined multiple protocols for PWs. Section 3.3 should be deleted or rewritten 7) Section 3.5 Interworking I agree that interworking adds complexity and should be avoided. However this section includes a large amount of general considerations that are not relevant to MPLS-TP OAM for example: Universal deployment of both OAM protocols … introduces additional testing requirements to ensure there are no conflicts when both protocols are run on a common platform. The use of the ACh to distinguish between protocols avoids the possibility of
Weekly posting summary for ietf@ietf.org
Total of 98 messages in the last 7 days. script run at: Fri Oct 14 00:53:02 EDT 2011 Messages | Bytes| Who +--++--+ 4.08% |4 | 9.50% |74596 | malcolm.be...@zte.com.cn 5.10% |5 | 4.94% |38766 | daedu...@btconnect.com 4.08% |4 | 3.77% |29598 | rcal...@juniper.net 4.08% |4 | 3.72% |29233 | rolf.win...@neclab.eu 4.08% |4 | 3.60% |28237 | joe...@bogus.com 4.08% |4 | 3.46% |27142 | huubatw...@gmail.com 4.08% |4 | 2.90% |22731 | to...@isi.edu 2.04% |2 | 4.66% |36547 | sven...@cisco.com 3.06% |3 | 2.63% |20665 | hous...@vigilsec.com 2.04% |2 | 3.62% |28443 | go...@erg.abdn.ac.uk 3.06% |3 | 2.53% |19882 | m...@sandelman.ca 3.06% |3 | 2.19% |17154 | adr...@olddog.co.uk 2.04% |2 | 2.14% |16797 | feng.f.hu...@alcatel-sbell.com.cn 2.04% |2 | 1.89% |14844 | b...@nostrum.com 1.02% |1 | 2.87% |22551 | nurit.sprec...@nsn.com 2.04% |2 | 1.84% |14413 | war...@kumari.net 2.04% |2 | 1.73% |13582 | hannes.tschofe...@gmx.net 2.04% |2 | 1.68% |13176 | evniki...@gmail.com 2.04% |2 | 1.62% |12707 | elw...@dial.pipex.com 2.04% |2 | 1.61% |12637 | john-i...@jck.com 2.04% |2 | 1.52% |11962 | jdr...@juniper.net 2.04% |2 | 1.51% |11890 | m...@lilacglade.org 2.04% |2 | 1.51% |11832 | d...@dcrocker.net 2.04% |2 | 1.48% |11591 | julian.resc...@gmx.de 2.04% |2 | 1.35% |10611 | ra...@psg.com 2.04% |2 | 1.33% |10437 | simon.perrea...@viagenie.ca 1.02% |1 | 1.81% |14194 | miezan...@gmail.com 1.02% |1 | 1.76% |13788 | ma.yu...@zte.com.cn 1.02% |1 | 1.44% |11289 | lmart...@cisco.com 1.02% |1 | 1.40% |10993 | david.bl...@emc.com 1.02% |1 | 1.35% |10595 | c.don...@cablelabs.com 1.02% |1 | 1.26% | 9911 | alexander.vainsht...@ecitele.com 1.02% |1 | 1.22% | 9581 | nar...@us.ibm.com 1.02% |1 | 1.18% | 9238 | yaacov.weingar...@nsn.com 1.02% |1 | 1.14% | 8919 | cyril.marga...@nsn.com 1.02% |1 | 1.04% | 8152 | david.i.al...@ericsson.com 1.02% |1 | 0.98% | 7671 | ned+i...@mauve.mrochek.com 1.02% |1 | 0.96% | 7550 | jeanmichel.com...@gmail.com 1.02% |1 | 0.95% | 7470 | l...@pi.nu 1.02% |1 | 0.91% | 7156 | hmdmhdfmhdjmzdtjmzdtzktdkzt...@gmail.com 1.02% |1 | 0.89% | 6949 | pat...@frobbit.se 1.02% |1 | 0.85% | 6655 | rjspa...@nostrum.com 1.02% |1 | 0.79% | 6198 | stephen.farr...@cs.tcd.ie 1.02% |1 | 0.78% | 6113 | nomcom-ch...@ietf.org 1.02% |1 | 0.77% | 6072 | f...@cisco.com 1.02% |1 | 0.76% | 5928 | m...@sap.com 1.02% |1 | 0.73% | 5752 | bortzme...@nic.fr 1.02% |1 | 0.73% | 5747 | brian.e.carpen...@gmail.com 1.02% |1 | 0.71% | 5564 | neil.2.harri...@bt.com 1.02% |1 | 0.70% | 5502 | agma...@gmail.com 1.02% |1 | 0.70% | 5471 | do...@dougbarton.us 1.02% |1 | 0.67% | 5251 | tnad...@lucidvision.com 1.02% |1 | 0.67% | 5249 | k...@bbn.com 1.02% |1 | 0.65% | 5090 | jo...@iecc.com 1.02% |1 | 0.62% | 4858 | ma...@isc.org +--++--+ 100.00% | 98 |100.00% | 784930 | Total ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
