Gen-ART LC review of draft-ietf-mpls-tp-rosetta-stone-12
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-mpls-tp-rosetta-stone-12 Reviewer: Roni Even Review Date:2013-10-12 IETF LC End Date: 2013-10-16 IESG Telechat date: Summary: This draft is ready for publication as an Informational RFC. Major issues: Minor issues: Nits/editorial comments:
Re: Gen-ART LC review of draft-ietf-mpls-tp-rosetta-stone-12
The draft does not list ITU in abbreviation, there are many terminology not clear but more general definition. I prefer specific defining. Also many times refers to references to define without mentioning what was that definition, is that defined only in ITU and IETF cannot define its technology, or is it agreeing on a joint definition so IETF is just following ITU in some terms. AB On Sunday, October 13, 2013, Roni Even wrote: 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-mpls-tp-rosetta-stone-12 Reviewer: Roni Even Review Date:2013–10–12 IETF LC End Date: 2013-10–16 IESG Telechat date: ** ** Summary: This draft is ready for publication as an Informational RFC. ** ** ** ** Major issues: Minor issues: ** ** Nits/editorial comments: ** ** ** **
Re: Gen-ART LC review of draft-ietf-mpls-tp-rosetta-stone-12
AB, ITU and ITU-T are both in http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt listed as one of the well-known acronyms we can use without expanding it; all the specific definition you need :) ! /Loa On 2013-10-13 17:39, Abdussalam Baryun wrote: The draft does not list ITU in abbreviation, there are many terminology not clear but more general definition. I prefer specific defining. Also many times refers to references to define without mentioning what was that definition, is that defined only in ITU and IETF cannot define its technology, or is it agreeing on a joint definition so IETF is just following ITU in some terms. AB On Sunday, October 13, 2013, Roni Even wrote: 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-mpls-tp-rosetta-stone-12 Reviewer: Roni Even Review Date:2013–10–12 IETF LC End Date: 2013-10–16 IESG Telechat date: __ __ Summary: This draft is ready for publication as an Informational RFC. __ __ __ __ Major issues: Minor issues: __ __ Nits/editorial comments: __ __ __ __ -- Loa Anderssonemail: l...@mail01.huawei.com Senior MPLS Expert l...@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64
Re: Last Call: Adding a fragment identifier to the text/csv media type(see draft-hausenblas-csv-fragment-06.txt)
I find the security considerations in this registration rather weak. What might have sufficed in 2005 seems to me inadequate for 2013. I would expect a clearer statement of what are or are not considered threats or attacks and what mitigations there then are for them. Tom Petch - Original Message - From: The IESG i...@ietf.org To: IETF Announcement List ietf-annou...@ietf.org Cc: i...@iana.org Sent: Thursday, October 10, 2013 7:50 PM The IESG has received a request to update the IANA registration of the text/csv media type, adding an optional fragment identifier. The request comes from a document in the Independent stream, and the IESG is the change controller for the text/csv media type. 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 2013-10-24. 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 document making the request can be obtained via http://datatracker.ietf.org/doc/draft-hausenblas-csv-fragment/
RE: Gen-ART LC review of draft-ietf-mpls-tp-rosetta-stone-12
Hi, I am having sever difficulty parsing all of the information from your comment. And currently cannot see anything actionable by the authors. The draft does not list ITU in abbreviation, Loa has answered why this is not necessary. there are many terminology not clear but more general definition. I prefer specific defining. This comment gives us nothing to go on! Which terminology do you find not clear but is a more general definition? And why is this a problem? You cannot expect the authors to fix or even discuss something if you do not show them what you are talking about. Also many times refers to references to define without mentioning what was that definition, What do you mean? Can you give an example and say how you think it should be? is that defined only in ITU and IETF cannot define its technology, or is it agreeing on a joint definition so IETF is just following ITU in some terms. *This* document is seeking IETF consensus. If that consensus is reached all definitions will be IETF definitions. If those definitions originate in ITU-T documents, they are also ITU-T definitions. If ITU-T documents make normative reference to IETF documents that contain definitions, those definitions are ITU-T definitions. Maybe I have missed the point of your comment. Adrian
Re: WG Review: IPv6 Maintenance (6man)
At 09:38 11-10-2013, The IESG wrote: The IPv6 Maintenance (6man) working group in the Internet Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for [snip] Jul 2014 - Advance IPv6 core specifications to Internet standard Which RFCs does the above refer to? Is the milestone about delivering the work item(s) to the IESG? Regards, -sm
Re: Gen-ART LC review of draft-ietf-mpls-tp-rosetta-stone-12
Yes, my comment meant that it is a reply to the review message that there may be not clear definition from other participant point of view. Sorry my review is still not complete, I will send it. Do you mean my reply is not right, if I like to give a short comment before my full review. AB On Sunday, October 13, 2013, Adrian Farrel wrote: Hi, I am having sever difficulty parsing all of the information from your comment. And currently cannot see anything actionable by the authors. The draft does not list ITU in abbreviation, Loa has answered why this is not necessary. You mean that IETF agrees to do that as per a RFC passed or community awareness. there are many terminology not clear but more general definition. I prefer specific defining. This comment gives us nothing to go on! Which terminology do you find not clear but is a more general definition? And why is this a problem? You cannot expect the authors to fix or even discuss something if you do not show them what you are talking about. I am talking about the draft in overall, I will do my review if time is available. Also many times refers to references to define without mentioning what was that definition, What do you mean? Can you give an example and say how you think it should be? Will be shown in a full review message, this was a comment message, but thanks for your advise is that defined only in ITU and IETF cannot define its technology, or is it agreeing on a joint definition so IETF is just following ITU in some terms. *This* document is seeking IETF consensus. If that consensus is reached all definitions will be IETF definitions. If those definitions originate in ITU-T documents, they are also ITU-T definitions. If ITU-T documents make normative reference to IETF documents that contain definitions, those definitions are ITU-T definitions. Maybe I have missed the point of your comment. The point is why do we need other organisation definitions, or why did the author use those definitions, my point is any definition should relate to internet technology not references of other org, we may use other definitions for ours. Adrian
Re: Improving the ISOC Fellowship programme to attract people from under-represented regions into the IETF
The DT I am discussing has no clear problem to solve, the appointment is
not clear, I have been asking for a WG but only DT was done. The DT has no
milestones and no clear objectives, is it a DT or a WG. We don't need the
DT to adopt or agree on any real draft effort submitted, it is the
community that adopt or disagrees the output of any DT.
AB
On Saturday, October 12, 2013, Melinda Shore wrote:
On Oct 12, 2013 6:51 AM, Adrian Farrel
adr...@olddog.co.ukjavascript:_e({}, 'cvml', 'adr...@olddog.co.uk');
wrote:
I don't understand your assertion that there is no procedure in the IETF
to
support the existence of a Design Team.
I'd be sorry to see this discussion dragged down a procedural rathole.
Melinda
Re: Gen-ART LC review of draft-ietf-mpls-tp-rosetta-stone-12
On Oct 13, 2013, at 7:32 AM, Abdussalam Baryun abdussalambar...@gmail.com wrote: Yes, my comment meant that it is a reply to the review message that there may be not clear definition from other participant point of view. Sorry my review is still not complete, I will send it. Do you mean my reply is not right, if I like to give a short comment before my full review. AB On Sunday, October 13, 2013, Adrian Farrel wrote: Hi, I am having sever difficulty parsing all of the information from your comment. And currently cannot see anything actionable by the authors. The draft does not list ITU in abbreviation, Loa has answered why this is not necessary. You mean that IETF agrees to do that as per a RFC passed or community awareness. there are many terminology not clear but more general definition. I prefer specific defining. This comment gives us nothing to go on! Which terminology do you find not clear but is a more general definition? And why is this a problem? You cannot expect the authors to fix or even discuss something if you do not show them what you are talking about. I am talking about the draft in overall, I will do my review if time is available. Insubstantial comments during the last call by someone who claims to have not reviewed the document are rather condescending. If you were the author what would you do with this feedback? Expectations of collegiality require a certain respect for common purpose, and the purpose of the last call is to surface remaining issues of substance, test for consensus and move on. (2418 section 8) Also many times refers to references to define without mentioning what was that definition, What do you mean? Can you give an example and say how you think it should be? Will be shown in a full review message, this was a comment message, but thanks for your advise is that defined only in ITU and IETF cannot define its technology, or is it agreeing on a joint definition so IETF is just following ITU in some terms. *This* document is seeking IETF consensus. If that consensus is reached all definitions will be IETF definitions. If those definitions originate in ITU-T documents, they are also ITU-T definitions. If ITU-T documents make normative reference to IETF documents that contain definitions, those definitions are ITU-T definitions. Maybe I have missed the point of your comment. The point is why do we need other organisation definitions, or why did the author use those definitions, my point is any definition should relate to internet technology not references of other org, we may use other definitions for ours. Adrian signature.asc Description: Message signed with OpenPGP using GPGMail
Terms and Conditions May Apply
I know we don't normally do movie plugs on this list, but anyone who's planning to attend the technical plenary in Vancouver could do worse than watch Terms and Conditions May Apply. It covers both commercial and governmental invasions of privacy, and how they are interlinked. http://www.imdb.com/title/tt2084953/ or http://tacma.net/ (but you might not want to click on the 'I agree' button until you've seen the movie...) Brian
Gen-ART LC review of draft-ietf-mpls-tp-rosetta-stone-12
A comment can be a discussion/opinion for the draft that is at the IETF level, I did review but not completed writing the output. However, my comment may influenced comments today at WG level (usually the draft passed such review of WG LC) which did not send there comments to the IETF list, but the authors are gaining so far. I prefer that all comments should be at the IETF list after the IETF LC to give chance for discussion if needed (as a community DISCUSS position). AB On Sunday, October 13, 2013, joel jaeggli wrote: On Oct 13, 2013, at 7:32 AM, Abdussalam Baryun abdussalambar...@gmail.com wrote: Yes, my comment meant that it is a reply to the review message that there may be not clear definition from other participant point of view. Sorry my review is still not complete, I will send it. Do you mean my reply is not right, if I like to give a short comment before my full review. AB On Sunday, October 13, 2013, Adrian Farrel wrote: Hi, I am having sever difficulty parsing all of the information from your comment. And currently cannot see anything actionable by the authors. The draft does not list ITU in abbreviation, Loa has answered why this is not necessary. You mean that IETF agrees to do that as per a RFC passed or community awareness. there are many terminology not clear but more general definition. I prefer specific defining. This comment gives us nothing to go on! Which terminology do you find not clear but is a more general definition? And why is this a problem? You cannot expect the authors to fix or even discuss something if you do not show them what you are talking about. I am talking about the draft in overall, I will do my review if time is available. Insubstantial comments during the last call by someone who claims to have not reviewed the document are rather condescending. If you were the author what would you do with this feedback? Expectations of collegiality require a certain respect for common purpose, and the purpose of the last call is to surface remaining issues of substance, test for consensus and move on. (2418 section 8) Also many times refers to references to define without mentioning what was that definition, What do you mean? Can you give an example and say how you think it should be? Will be shown in a full review message, this was a comment message, but thanks for your advise is that defined only in ITU and IETF cannot define its technology, or is it agreeing on a joint definition so IETF is just following ITU in some terms. *This* document is seeking IETF consensus. If that consensus is reached all definitions will be IETF definitions. If those definitions originate in ITU-T documents, they are also ITU-T definitions. If ITU-T documents make normative reference to IETF documents that contain definitions, those definitions are ITU-T definitions. Maybe I have missed the point of your comment. The point is why do we need other organisation definitions, or why did the author use those definitions, my point is any definition should relate to internet technology not references of other org, we may use other definitions for ours. Adrian
Re: Gen-ART LC review of draft-ietf-mpls-tp-rosetta-stone-12
AB, You wrote: but the authors are gaining so far. That may be your opinion. But it is absolutely not my opinion. As the author of this draft I have worked four years to address all the comments received, and improve the quality of the document. So you had four years to review and comment. Yet you wait until four days before the deadline set by IESG to announce that you have substantial comments. I am now completely lost, and have lost too. /Huub. -- * 请记住，你是独一无二的，就像其他每一个人一样
RE: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard
SM, Are you suggesting that we don't address the problem because the code is too complex to touch? Ron -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of SM Sent: Sunday, October 13, 2013 1:00 AM To: ietf@ietf.org Subject: Re: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard At 11:55 02-10-2013, The IESG wrote: The IESG has received a request from the IPv6 Maintenance WG (6man) to consider the following document: - 'Implications of Oversized IPv6 Header Chains' draft-ietf-6man-oversized-header-chain-08.txt as 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 This document intends to update the IPv6 specification. I looked into some code (host) which would be affected by the RFC 2119 requirement in Section 5. The code is complex as it is. I am not sure whether the requirement can be implemented without too much difficulty. I have not looked into the code which processes inbound packets. Regards, -sm
Re: Terms and Conditions May Apply
Yo Brian! On Mon, 14 Oct 2013 08:16:10 +1300 Brian E Carpenter brian.e.carpen...@gmail.com wrote: I know we don't normally do movie plugs on this list, but anyone who's planning to attend the technical plenary in Vancouver could do worse than watch Terms and Conditions May Apply. +1. I just saw it at the Bend Film Festival. Good overview of the state of privacy in the USA, pre-Snowden. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701 g...@rellim.com Tel:+1(541)382-8588 signature.asc Description: PGP signature
Re: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard
Templin, Fred L mailto:fred.l.temp...@boeing.com 11 October 2013 17:33 Hi Ray, -Original Message- From: Ray Hunter [mailto:v6...@globis.net] Sent: Friday, October 11, 2013 12:49 AM To: Templin, Fred L; brian.e.carpen...@gmail.com Cc: ietf@ietf.org; 6man Mailing List Subject: Re: RE: Last Call: draft-ietf-6man-oversized-header-chain- 08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard Templin, Fred L wrote: Hi Brian, Responding in a slightly re-arranged order: The problem is that you are asserting that middleboxes that a tunnel passes through are expected to examine the complete header chain of the encapsulated packet even if the encapsulated packet is a fragment. Yes, but change are expected to to should be able to. I personally don't see this going anywhere. Unless you specifically define what is a tunnel and you specifically define a maximum depth of nesting. The term Upper-Layer Protocol (ULP) is also itself a vague term IMHO since the value of the IPv6 next header is taken from the same code space as the ULP header values, and there's no specific marker or header length field in IPv6 that explicitly marks a point as This is the end of the IPv6 header chain in all circumstances: stop header parsing here. Ok, there's a bunch of current code-points that are today considered as valid ULP's or next-header values, but that is neither time invariant nor exhaustive, so solving this issue via a registry means there will always be middlebox code in the wild that lags any updates. These middleboxes won't be able to differentiate between an unknown ULP, and an unknown IPv6 next-header. That potentially makes a default pass or drop decision awkward. If it's so important to be able to differentiate between what is an ULP and what is a next header, and we can't reliably do that today, maybe that's a fundamental flaw in IPv6 that should be addressed. I think that's an unreasonable expectation. A reasonable expectation is that middleboxes should identify the encapsulated packet as a payload that they cannot analyse, and let it go (unless they have a policy setting to drop tunnelled packets, which is a different discussion). But why? If headers beyond the first IPv6 encapsulation header are available in the clear, the middlebox should be able to parse them if it wants to. Wireshark already does exactly that - it keeps on parsing beyond the first encapsulation header up to and including the true ULP header. And, if Wireshark can do it, so can any other middlebox that believes security would be improved by continuing to parse the entire chain - whether or not there is a standard saying it must not do so. Because it leaves open the possibility for an attacker to apply the obfuscation we seek to limit. Parsing the additional headers beyond the first encapsulation header provides defense-in-depth. Perimeter middleboxes can then weed out the bad stuff without either allowing the bad stuff to penetrate more deeply into the organization or dropping good stuff that should be allowed through. There's also a myriad of tunneling technology out there. Again, what is an ULP? Where do you stop parsing? The middlebox stops parsing when it decides it has seen enough. Which AFAIK is undefined in practical terms. Especially in the presence of jumbo payload extension headers or fragments. So are you saying the current draft has no value? With Wireshark at least, it blasts right through encapsulating IP headers and continues up to and including the ultimate TCP/UDP/ICMP etc. header inserted by the original host. I like wireshark. But how would that parsing model work in a live network without maintaining state between frames (and leaving your middlebox open to DoS or other resource depletion abuse)? IMHO ultimate TCP/UDP/ICMP etc. is not defined. The IETF does not define standard protocol stacks as a totality. HTTP over TCP over IPv6 over L2TP over GRE over PPTP VPN over IPv6 over IPv6 is not illegal. So this would seem to require far tighter specs on packet formats than the IETF would ever publish (and rightly so). The goal is to give the middlebox enough information so that it can parse as deeply into the headers as it wants to. If that is the goal then we probably need to deprecate IPv6 fragmentation as well as a whole bunch of tunnel / encryption protocols IMHO, and specify that the entire packet has to fit in a single frame. Which I feel is unrealistic. Is GRE a tunnel or an ULP? (GRE can run over almost anything) Is SSH an ULP or a tunnel? (port tunneling) Is Teredo a tunnel or is it an ULP (UDP) or both? GRE/ LT2P over HTTP anyone? The notion of perimeter is moveable in the presence of such tunnels. We will want for middleboxes at outer perimeters to be able to parse as many headers as they want to before releasing the packet to middleboxes at inner perimenters. Otherwise, bad stuff can get past
