Re: [conex] Last Call: draft-ietf-conex-concepts-uses-04.txt (ConEx Concepts and Use Cases) to Informational RFC
Hi, Bob's email specifically said specifications and mechanisms would be likely to be tagged with the IPR. This particular document is neither a specification nor a mechanism as it describes the use cases for conex. When the drafts describing the conex spec are sent to the IESG, the IPR claim will be propely pointed out. I hope this clarifies the issue. Regards, marcelo El 29/03/12 18:11, Christopher Morrow escribió: On Thu, Mar 29, 2012 at 10:10 AM, The IESGiesg-secret...@ietf.org wrote: The IESG has received a request from the Congestion Exposure WG (conex) to consider the following document: - 'ConEx Concepts and Use Cases' draft-ietf-conex-concepts-uses-04.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 2012-04-12. 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. Abstract This document provides the entry point to the set of documentation about the Congestion Exposure (ConEx) protocol. It explains the motivation for including a ConEx marking at the IP layer: to expose information about congestion to network nodes. Although such information may have a number of uses, this document focuses on how the information communicated by the ConEx marking can serve as the basis for significantly more efficient and effective traffic management than what exists on the Internet today. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-conex-concepts-uses/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-conex-concepts-uses/ballot/ No IPR declarations have been submitted directly on this I-D. Didn't Mr Briscoe just email that there was a BT IPR claim against this ID, related to re-ECN work he did/does for BT? ___ conex mailing list co...@ietf.org https://www.ietf.org/mailman/listinfo/conex ___ conex mailing list co...@ietf.org https://www.ietf.org/mailman/listinfo/conex
Re: [BEHAVE] Last Call: draft-ietf-behave-v6v4-xlate-stateful (Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers) to Proposed Standard
Hi Pekka, thanks for the review I think i have addressed most of the comments, but i have some follow ups. See replies below. El 03/06/10 11:06, Pekka Savola escribió: On Tue, 1 Jun 2010, The IESG wrote: - 'Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers ' draft-ietf-behave-v6v4-xlate-stateful-11.txt as a Proposed Standard I've reviewed draft-ietf-behave-v6v4-xlate-stateful-11 for ops-dir. I believe the document is ready for publication, but there are a couple of areas where minor clarifications could improve the document. As a general comment, spec has good detail (esp S 3.5) on how to handle TCP, UDP and ICMP query traffic, but I did not find similar detail on how ICMP errors sent in response to such traffic would affect packet processing, state tables, etc. The thing is that NAT64 only translated ICMP errors back and forth when it can but does not change its internal state in any way based on the errors. In other words, ICMP errors received do not affect the NAT64 state. I have made that explicit in the intor of the session handling section. I have also reworded the other sections to explicitly address the ICMP error handling. It would be great if e.g. TCPM WG reviewed Section 3.5.2, especially its state table and said it's OK. There could be a number of unthought-of cornercases. From OM perspective, the specification appears to be sufficiently operable and configurable in IPv6-IPv4 translation. IPv4-IPv6 translation requires manually configured or unspecified bindings. Operationally this is not going to be sufficiently as the management interface is unspecified and e.g. MIB module or other configuration methods do not exist and are not in Behave WG charter. But this issue should not delay the publication of this document and rather should be tackled later, if needed. ok The default TCP maximum session lifetime is 2 hours (from RFC5382). I personally believe this is too small for long-lived sessions. not sure if there is much we can do about this. We are relying on the consensus achieved in RFC5382, not sure how possible is to change that at this point. some detailed comments: --- This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. [...] .. which material is potentially covered by this? While the non-WG version was available prior to Nov 10, 2008, the authors should be able to say so. It would be better if this disclaimer could be removed. License info is also an older version (from id-nits checker). ok, i think we can do that In S 3.4: If the incoming packet is an IPv6 packet that contains a protocol other than TCP, UDP or ICMPv6 in the last Next Header, then the packet SHOULD be discarded and, if the security policy permits, the NAT64 SHOULD send an ICMPv6 Destination Unreachable error message with Code 3 (Destination Unreachable) to the source address of the received packet. NOTE: This behaviour may be updated by future documents that define how other protocols such as SCTP or DCCP are processed by NAT64. .. I suppose this assumes the packet is unicast, as NAT64 is an unicast-only specification. Nonetheless I'd suggest that somewhere (probably earlier in the spec) you'd explicitly say about one sentence on multicast; it's currently not mentioned at all. E.g. A NAT64 device MUST ignore any translation or actions when IPv4 or IPv6 destination address is a multicast or the limited broadcast address (255.255.255.255). (maybe with more precise definition what to do instead.) I have added a sentence that states that multicast is out of the scope of this specification. I would rather not to define what to do with multicast packets in this spec, so that if a multicast translator is defined, as proposed by stig, then we don't need to update this spec, makes sense? The same applies but more strongly to the following IPv4 paragraph. More strongly because IPv4 spec does not allow generating ICMPv4's in response to multicast packets while in ICMPv6 this is acceptable under certain conditions. right, i have added a sentence in the beginning of the document that states that multicast traffic is out of the scope of the spec, so i think this would address this as well NB: I see that IPv6 destination address is covered under 2nd paragraph of S 3.5 but a more explicit mention might be worthwhile. In S 3.5.1: * The STE destination IPv4 transport is set to (Z(Y'),y), y being the same port as the STE destination IPv6 transport address and Z(Y') being algorithmically generated from the IPv6 destination address (i.e. Y') using the reverse algorithm as specified in Section 3.5.4. .. S 3.5.2 can hardly be said to specify any algorithm, but it certainly doesn't even mention the reverse algorithm (however trivial it
Re: [BEHAVE] Last Call: draft-ietf-behave-v6v4-xlate-stateful (Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers) to Proposed Standard
Thanks for the review. I will address the comments and come back to you. Regards, marcelo El 03/06/10 11:06, Pekka Savola escribió: On Tue, 1 Jun 2010, The IESG wrote: - 'Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers ' draft-ietf-behave-v6v4-xlate-stateful-11.txt as a Proposed Standard I've reviewed draft-ietf-behave-v6v4-xlate-stateful-11 for ops-dir. I believe the document is ready for publication, but there are a couple of areas where minor clarifications could improve the document. As a general comment, spec has good detail (esp S 3.5) on how to handle TCP, UDP and ICMP query traffic, but I did not find similar detail on how ICMP errors sent in response to such traffic would affect packet processing, state tables, etc. It would be great if e.g. TCPM WG reviewed Section 3.5.2, especially its state table and said it's OK. There could be a number of unthought-of cornercases. From OM perspective, the specification appears to be sufficiently operable and configurable in IPv6-IPv4 translation. IPv4-IPv6 translation requires manually configured or unspecified bindings. Operationally this is not going to be sufficiently as the management interface is unspecified and e.g. MIB module or other configuration methods do not exist and are not in Behave WG charter. But this issue should not delay the publication of this document and rather should be tackled later, if needed. The default TCP maximum session lifetime is 2 hours (from RFC5382). I personally believe this is too small for long-lived sessions. some detailed comments: --- This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. [...] .. which material is potentially covered by this? While the non-WG version was available prior to Nov 10, 2008, the authors should be able to say so. It would be better if this disclaimer could be removed. License info is also an older version (from id-nits checker). In S 3.4: If the incoming packet is an IPv6 packet that contains a protocol other than TCP, UDP or ICMPv6 in the last Next Header, then the packet SHOULD be discarded and, if the security policy permits, the NAT64 SHOULD send an ICMPv6 Destination Unreachable error message with Code 3 (Destination Unreachable) to the source address of the received packet. NOTE: This behaviour may be updated by future documents that define how other protocols such as SCTP or DCCP are processed by NAT64. .. I suppose this assumes the packet is unicast, as NAT64 is an unicast-only specification. Nonetheless I'd suggest that somewhere (probably earlier in the spec) you'd explicitly say about one sentence on multicast; it's currently not mentioned at all. E.g. A NAT64 device MUST ignore any translation or actions when IPv4 or IPv6 destination address is a multicast or the limited broadcast address (255.255.255.255). (maybe with more precise definition what to do instead.) The same applies but more strongly to the following IPv4 paragraph. More strongly because IPv4 spec does not allow generating ICMPv4's in response to multicast packets while in ICMPv6 this is acceptable under certain conditions. NB: I see that IPv6 destination address is covered under 2nd paragraph of S 3.5 but a more explicit mention might be worthwhile. In S 3.5.1: * The STE destination IPv4 transport is set to (Z(Y'),y), y being the same port as the STE destination IPv6 transport address and Z(Y') being algorithmically generated from the IPv6 destination address (i.e. Y') using the reverse algorithm as specified in Section 3.5.4. .. S 3.5.2 can hardly be said to specify any algorithm, but it certainly doesn't even mention the reverse algorithm (however trivial it might be). In S 3.5.2: V4 SYN RCV: An IPv4 packet containing a TCP SYN was received by the NAT64, implying that a TCP connection is being initiated from the IPv4 side. The NAT64 is now waiting for a matching IPv6 packet containing the TCP SYN in the opposite direction. ... A TCP segment with the SYN flag set that is received through the IPv6 interface is called a V6 SYN, similarly, V4 SYN, V4 FIN, V6 FIN, V6 FIN + V4 FIN, V6 RST and V4 RST. .. this is somewhat confusing because you appear to be using V4 SYN RCV to mean only SYN flag set (due to being initiated from ...) while V4 SYN later means SYN [and possibly ACK] flag set. The same applies to V6 of course. Maybe reword? Maybe being initiated from.. and this distinction is not even necessary, because you don't have it on V4 FIN RCV side either? (Though when creating sessions, the semantics differ slightly depending on the initiator.) V4 FIN RCV, V6 FIN RCV and V4 FIN + V6 FIN are listed in the state diagram without RCV keyword, and this should be corrected. I'm also a bit hesitant
Re: RFC 3484 Section 6 Rule 9
Well, longest prefix match is kind of useful in some scenarios i think. Imagine a site that is multihomed to two ISPs and has two PA address blocks. Now, longest prefix match ensures that when a node of the multihomed site wants to contact any other customer of its own isps, it does perform the correct source address selection and that is likely to be critical for the communication to work, especially if the isps are doing ingress filtering (i am assuming that the intra site routing of the multihomed site will preffer the route through the ISP that owns the prefix contained in the destiantion address) Even though this is one case and the problem is more general, i tend to think that this is an importnat case and things would break more if this rule didn't exist Regards, marcelo Mark Andrews escribió: This rule should not exist for IPv4 or IPv6. Longest match does not make a good sorting critera for destination address selection. In fact it has the opposite effect by concentrating traffic on particular address rather than spreading load. I received a request today asking us to break up DNS RRsets as a workaround to the rule.Can we please get a errata entry for RFC 3484 stating that this rule needs to be ignored. Mark ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC 3484 Section 6 Rule 9
Mark Andrews escribió: Well, longest prefix match is kind of useful in some scenarios i think. Imagine a site that is multihomed to two ISPs and has two PA address blocks. Now, longest prefix match ensures that when a node of the multihomed site wants to contact any other customer of its own isps, it does perform the correct source address selection and that is likely to be critical for the communication to work, especially if the isps are doing ingress filtering (i am assuming that the intra site routing of the multihomed site will preffer the route through the ISP that owns the prefix contained in the destiantion address) Even though this is one case and the problem is more general, i tend to think that this is an importnat case and things would break more if this rule didn't exist Regards, marcelo Section 6 Rule 9 is DESTINATION address selection. so, are you suggesting to keep rule 8 of source address selection (longest prefix match) and remove rule 9 of destiantion address selection (longest prefix match)? btw, an analysis of some multihomed scenarios and the impact of longest prefix match can be found at http://www.ietf.org/internet-drafts/draft-ietf-v6ops-addr-select-ps-06.txt. From the draft, it is possible to see that it helps, but not that much and it is probably worth having better support. But i am not sure we should simply remvoe it with an errata. IMHO, we should actually solve this problem and provide a solution for multiprefixed sites regards, marcelo It provides absolutely no help when attempting to distingish a multi-homed destination that is not with your current ISP. It also won't help once your current ISP has more than one prefix. It doesn't help with PI clients connected to your current ISP. It biases what should be a random selection. There is no science that says a /30 match is better than a /28 or a /8 match. If one really wants to have directly connected clients of your ISP match then get a appropriate feed of prefixes and use it to build appropriate tables. We have the technology to distribute sets of prefixes. Just don't attempt to have longest match do the just because it can't do it except for PA address and even then only when your ISP has a single prefix. For any other senario it is biased garbage. Mark Andrews escribió: This rule should not exist for IPv4 or IPv6. Longest match does not make a good sorting critera for destination address selection. In fact it has the opposite effect by concentrating traffic on particular address rather than spreading load. I received a request today asking us to break up DNS RRsets as a workaround to the rule.Can we please get a errata entry for RFC 3484 stating that this rule needs to be ignored. Mark ___ 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: Pointer to the Rules for Normative References?
this is defined in [RFC3967 i think that a standrard track document can point out to a BCP and this is not considered a downward reference Philip Matthews escribió: Can someone point me to the rules for when a document is allowed to normatively reference another document? I am seen them before, but cannot find them right now. In particular, I am wondering if a standards-track RFC is allowed to normatively reference a BCP? - Philip ___ 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: Gen-ART Last Call review of draft-ietf-shim6-hba-04
Hi Spencer thanks for the quick reply i see your point and it is indeed the receiver. i have already submitted a newer version. I will address these changes in the next version Regards, marcelo El 23/12/2007, a las 1:24, Spencer Dawkins escribió: Hi, Marcelo, I think we're good on everything except one semi-nit - and I'm good on the DAD text I questioned, because I didn't have the context about not performing DAD as a DoS mitigation (just to be explicit about that). In the remaining text below, I think I was actually asking who verifies - if it's the receiver, I might suggest s/we may need to verify/the receiver may need to verify/, etc. Thanks, and thanks for a quick reply (while I could remember writing the review!) Spencer - Original Message - From: marcelo bagnulo braun [EMAIL PROTECTED] To: Spencer Dawkins [EMAIL PROTECTED] Cc: Kurt Lindqvist [EMAIL PROTECTED]; Geoff Huston [EMAIL PROTECTED]; Jari Arkko [EMAIL PROTECTED]; ietf@ietf.org; General Area Review Team [EMAIL PROTECTED] Sent: Saturday, December 22, 2007 12:53 PM Subject: Re: Gen-ART Last Call review of draft-ietf-shim6-hba-04 Hi Spencer, thanks for the review see comments below... El 24/11/2007, a las 3:59, Spencer Dawkins escribió: For multihoming applications, it is also relevant to verify if a given HBA address belongs to a certain HBA set. An HBA set is identified by a CGA Parameter Data structure that contains a Multi- Prefix Extension. So, it is then needed to verify if an HBA belongs Spencer: needed to verify appears twice in two sentences, and I don't understand what it means. I'm guessing this is saying something like needed to verify, but I'm really in the weeds here (I'm not sure who is doing the verification, either - I can guess, but I can't figure that out from the text) ok, i have changes it is needed to verify bu we need to verify, resulting in the following text: For multihoming applications, it is also relevant to verify if a given HBA address belongs to a certain HBA set. An HBA set is identified by a CGA Parameter Data structure that contains a Multi- Prefix Extension. So, we need to verify if a given HBA belongs to the HBA set defined by a CGA Parameter Data Structure. It should be noted that we may need to verify if an HBA belongs to the HBA set defined by the CGA Parameter Data Structure of another HBA of the set ___ 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: Gen-ART Last Call review of draft-ietf-shim6-hba-04
Hi Spencer, thanks for the review see comments below... El 24/11/2007, a las 3:59, Spencer Dawkins escribió: Hi, Marcelo, I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-shim6-hba-04 Reviewer: Spencer Dawkins Review Date: IETF LC End Date: 2007-11-23 Summary: This document is on the right track, but in some places is just not clear enough for publication yet. I'll call Russ's attention to my comments about Perform duplicate address detection if required and in the security considerations section (both below). Almost everything else is (nit)s. Comments: Abstract This memo describes a mechanism to provide a secure binding between the multiple addresses with different prefixes available to a host within a multihomed site. The main idea is that information about the multiple prefixes is included within the addresses themselves. This is achieved by generating the interface identifiers of the addresses of a host as hashes of the available prefixes and a random number. Then, the multiple addresses are generated by prepending the different prefixes to the generated interface identifiers. The result is a set of addresses, called Hash Based Addresses (HBAs), that are inherently bound. Spencer (nit): s/bound/bound to a host/? they are bound to each other, os i have put that i.e. that are inherently bound to each other 3.3. Motivations for the HBA design Fourth, performance considerations as described in [17] motivated the usage of a hash based approach as oposed to a public key based approach based on pure Cryptographic Generated Addresses (CGA), in order to avoid imposing the performance of public key operations for every communication in multihomed environments. The HBA appraoch Spencer (nit): s/appraoch/approach/ ok presented in this document presents a cheaper alternative that is attractive to many common usage cases. Note that the HBA approach and the CGA approaches are not mutually exclusive and that it is possible to generate addresses that are both CGA and HBA providing Spencer (nit): both CGA and HBA is correct but difficult to parse. Suggest that are both valid CGA and HBA addresses for ease of comprehension. the benefits of both approaches if needed. done 4. Cryptographic Generated Addresses (CGA) compatibility considerations First, the current Secure Neighbor Discovery specification [3] uses the CGAs defined in [2] to prove address ownership. If HBAs are not compatible with CGAs, then nodes using HBAs for multihoming wouldn't be able to do Secure Neighbor Discovery using the same addresses (at Spencer (nit): s/Discovery/Discovery (SeND)/ ok least the parts of SeND that require CGAs). This would imply that nodes would have to choose between security (from SeND) and fault tolerance (from shim6). In addition to SeND, there are other Spencer (nit): shim6 has not been introduced previously in this document - need at least a reference here, and probably need to spell shim6 out at least once. ok i have substituted shim6 by and fault tolerance (from IPv6 multihoming support provided by the Shim6 protocol xref target=shimproto /) protocols that are considering to benefit from the advantages offered by the CGA scheme, such as mobility support protocols [13]. Those protocols would also become incompatible with HBAs if HBAs are not Spencer (nit): difficult to parse - suggest something like Those protocols could not be used with HBAs if HBAs are not compatible with CGAs. ok compatible with CGAs. Even though a CGA compatible approach is adopted, it should be noted that HBAs and CGAs are different concepts. In particular, the CGA is inherently bound to a public key, while a HBA is inherently bound to a prefix set. This means that a public key is not strictly required Spencer (nit): why strictly? the context seems to say not required, no adverb needed... unless you mean a public key is not required to generate an HBA? right i used the strcilty, because even if it is not needed, you can use it, resulting in hybrid HBA/CGA addresses, but i can also remove it from the sentence and the sense it is ok too. I have removed the strcitly from next version of the draft to generate an HBA. Because of that, we define three different types of addresses: - HBA-only addresses: These addresses are bound to a prefix set but they are not bound to a public key. Because CGA compatibility, Spencer (nit): I can't parse Because CGA compatibility. Is the sentence saying Because HBAs are compatible with CGA, ...? right the CGA Parameter Data Structure will be used for their
MEXT interim meeting, February 7-8, 2008
MEXT interim meeting DATE: 7,8 feb 2008 Location: University Carlos III de Madrid Escuela Politecnica Superior Av. Universidad 30 28911 - Leganes Madrid, SPAIN Goal of the meeting: The focus of the meeting would be the nemo ro work and other considerations for nemo global deployment. We will provide more information about the location accomodation and agenda shortly ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
SeND CGA Extensions BOF
Hi, we have proposed a BOF on SeND and CGA extensions for the Chicago IETF. I attach the proposed charter below. There is a mailing list created for the discussion (https://www1.ietf.org/mailman/listinfo/cga-ext) If you have comments about the proposed work, it would be appreciated. Thanks, marcelo Proposed charter for SeND CGA Extensions BOF Secure Neighbour Discovery (SeND) protocol as defined in RFC 3971 provides the security mechanisms to protecting the different functions performed by the Neighbour Discovery (ND) protocol, including the discovery of other nodes on the link and their link-layer addresses, router discovery and reachability detection for the paths to active neighbors. However, current SeND specification lacks of support for ND Proxies as defined in RFC 4389. The SeND protocol relies on the usage of Cryptographically GEnerated Addresses (CGAs) to provide some of these functions, in particular to provide IPv6 address ownership proof to the other nodes on the link and authenticate node related information of the ND protocol. CGAs are defined in RFC 3972 which has been recently updated by RFC 4581 to define the CGA extension format and by RFC-to-be draft-bagnulo-multiple-hash-cga-03.txt to support multiple hash functions. While CGAs were originally defined for the SeND protocol, they have proved to be a useful security tool in other environments too, and its usage has been proposed to secure other protocols such as the Shim6 multihoming protocol and the Mobile IPv6 protocol. As the CGAs become more widely used for different purposes, it is necessary to produce some extensions to support such new usages. The objective of this working group is to define extensions related to both to the SeND protocol and to the CGAs. The following are charter items for the working group: - Extensions to the SeND protocol to support Neighbour Discovery Proxies: SeND protocol as currently defined in RFC 3971 lacks of support for ND Proxies defined in RFC 4389. Extensions to the SeND protocol will be defined in order to provide equivalent SeND security capabilities to ND Proxies. - Extensions to the IKEv2 protocol to create IPSec SAs associated to the CGA key. Because of their cryptographic nature, CGAs are inherently bound to the key pair that was used for their generation. This is used in existent protocols for proving address ownership. However, it would be possible also to use this cryptographic material to create a security association between peers. The key benefit of such approach is that it allows the creation of a security association that is cryptographically bound to the IP address of the end points without dependence on a common trust anchor point, eg. PKI. Such approach would provide additional protection compared to the opportunistic approaches. The proposed work will produce an analysis of this type of solution and the required extensions to CGAs and to the IKEv2 protocol in order to be able to create IPSec SA using the CGAs keys. - DHCP support for CGAs. An analysis of possible approaches to allow the usage of the DHCP protocol to assign CGAs will be produced. The output of the analysis will be an informational document describing the recommended approaches that will be provided as an input to the DHC working group where the actual DHCP extensions needed for the recommended approaches will be defined. - Define a CGA extension to support other public key algorithms: As currently defined, CGAs can only use RSA keys in the CGA Parameter Data Structure. An extension to update the CGA specification in order to multiple public key cryptographic algorithm support will be defined. Related drafts: draft-kempf-mobopts-ringsig-ndproxy-01.txt draft-laganier-ike-ipv6-cga-01.txt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Fostering reviews (was Re: are we willing to do change how we do discussions in IETF?)
El 26/06/2006, a las 9:56, Dave Crocker escribió: marcelo bagnulo braun wrote: I don't know about narrow community, but I agree that good reviews are essential. ... In my opinion, if the IETF could make it worth someone's while in one way or another to do a thorough review, that would help a lot. I very much agree with this I think this is the way to improve quality there have been some initiatives for this, see http://www.watersprings.org/pub/id/draft-handley-doc-market-00.txt but i guess it didn't progress... we should try to figure out some mechanisms to foster reviews... do you have any ideas? The first effort was the SIRS project, that was declared a failure after only 4 months (most of which were during the summer) in spite of recruiting a substantial list of highly experienced participants. The second was a working group that took a year to develop a scheme that was essentially identical to sirs, but did a nice job of dissipating community energy for the effort. too bad... perhaps we should try another effort in this area... but we should wait for the summer to end this time... The incentive that something like SIRS offered was classification as a senior contributor. This was neither a small point nor a small benefit (IMO). what was the benefit of becoming a senior contributor? Thanks, marcelo d/ ___ 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: Fostering reviews (was Re: are we willing to do change how we do discussions in IETF?)
El 26/06/2006, a las 10:49, Dave Crocker escribió: marcelo bagnulo braun wrote: The incentive that something like SIRS offered was classification as a senior contributor. This was neither a small point nor a small benefit (IMO). what was the benefit of becoming a senior contributor? Idealistic answer: The personal satisfaction of meaningful contribution. (There is a rumor that active IETF participants are highly motivated by this goal. So, the incentive is provide explicit satisfaction of it beyond their narrow areas of primary activity.) Selfish: Public recognition. (Good for both one's ego and potentially one's employment status.) ok, may make sense how would this differ from the technical advisor title? Regards, marcelo d/ ps. The ideal and the selfish are complementary and not at all negative, IMO. But, then, I believe all idealism is driven by a form of self-satisfaction... ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Fostering reviews (was Re: are we willing to do change how we do discussions in IETF?)
El 26/06/2006, a las 12:03, Dave Crocker escribió: The incentive that something like SIRS offered was classification as a senior contributor. This was neither a small point nor a small benefit (IMO). what was the benefit of becoming a senior contributor? ... how would this differ from the technical advisor title? In my model, the advisor is an on-going mentor. They are an active participant in the working group. Reviewers are not (necessarily) participants. There is an obvious -- and probably quite appropriate -- view that a reviewer MUST NOT be a participant, lest their review be too distorted by having too much context. isn't there already some general area reviewers that perform this type of function? I thought there were In both cases, I would think that neither has any sort of veto. Rather, they must sway by convincing rather than dictating. This applies both to the decision-making by the wg and decision-making by the IESG (about the wg output.) what do you think about these more aggresive forms of looking for feedback, like to one in Handley Rescorla draft? maybe they could be tested wihtout enforcing them, but leaving the results public (i.e. a web page publishing the amount of credits that each participant has, so that the general public can see who does reviews and who doesn't...) (as oposed to enforcing it by not allowing submitting new draft if the person does not have enough credits...) Regards, marcelo d/ ___ 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
Fostering reviews (was Re: are we willing to do change how we do discussions in IETF?)
Hi Iljitsch, I don't know about narrow community, but I agree that good reviews are essential. Reviewing is hard, especially with long documents / complex specifications (unfortunately it still seems some RFC writers are paid by the word) and also when there are many dependencies. And there's essentially nothing in it for the reviewer, so only people who are very much in favor or very much against something bother, with the former probably not being in the best position to uncover hidden problems. In my opinion, if the IETF could make it worth someone's while in one way or another to do a thorough review, that would help a lot. I very much agree with this I think this is the way to improve quality there have been some initiatives for this, see http://www.watersprings.org/pub/id/draft-handley-doc-market-00.txt but i guess it didn't progress... we should try to figure out some mechanisms to foster reviews... do you have any ideas? Regards, marcelo ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
Hi Andrew, And people wonder why NATs proliferate... much of the world has no option but to live with them. This is a direct result of policy discouraging IPv4 address allocation. sorry for asking, but what policy are you referring to? RIR policy? Can you point out any RIRs policy that prevents from getting one public IPv4 address per machine connected to the Internet? What do you think that needs to be changed in the v4 allocation policy? Or are you talking about business model of the ISPs? (which doesn't seem to me to be related with policies, but just business...) Thanks, marcelo Andrew ___ 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
