Re: Community Input Sought on SOWs for RFC Production Center and RFC Publisher
Hi, A few nits regrading MIB module checking... On 8/16/13 4:16 PM, Sandy Ginoza sgin...@amsl.com wrote: 2) In the following, we suggest that ASN.1 (and particularly MIBs and MIB-related details) be updated to reflect MIBs. Although MIB modules are written using a subset of ASN.1, the RPC does not check all ASN.1, we only check MIBs. This change will reflect what is done in practice. If the intent is to actually require the RPC to check all ASN.1, please let us know and we will discuss checking tools with the RSE and IAD. Current: 1.3. Validation of formal languages The RPC should validate the syntax of sections of documents containing formal languages. In particular ASN.1 (and particularly MIBs and MIB-related details), YANG, ABNF, and XML should be verified using one or more tools as approved by the RSE. S/MIBs/MIB modules/ MIB Modules are written using version 2 of the SMI standard, a formal language which is an IETF-standardized adapted subset of ASN.1-1988. So MIB validation might be more accurately called SMI validation or SMIv2 validation (but SMIv3 could be done at some future date.) So s/ASN.1/SMI/ or s/ASN.1/SMIv2/ ASN.1 has moved on since the 1988 subset used for SMI. There are tools to validate against the more current ASN.1 standard. I'm not sure how much current ASN.1 is used in IETF documents, but if it is, then you might want to validate it. I think there is very little current ASN.1 usage in IETF documents. -- David Harrington ietf...@comcast.net +1-603-828-1401
Thoughts from a past experimental Nomcom selection for TSV Area Director
, and expanded the number of requests for document reviews. We considered this change important to try to cultivate more candidates for future Nomcom considerations. To a degree, increasing the directorate size helped train a new generation (goal#3), and it helped get more documents reviewed (goal#2) since we now had a larger active pool to share the review burden. I still found the directorate not very responsive, but that's volunteerism. I think the TSV area lost out on steering advice (goal #1) by discontinuing the dinners, since many chose not to attend the lunch work sessions. I see that Wes and Martin re-established the dinners. That's a good thing. Hope this helps, David Harrington dbharring...@comcast.net +1-603-828-1401
Re: [OPSAWG] Basic ietf process question ...
+1 -- David Harrington ietf...@comcast.net +1-603-828-1401 On 8/2/12 12:59 PM, Romascanu, Dan (Dan) droma...@avaya.com wrote: Hi, The OPSAWG/OPSAREA open meeting this afternoon has an item on the agenda concerning the revision of RFC1052 and discussing a new architecture for management protocols. My personal take is that no one protocol, or one data modeling language can match the operational requirements to configure and manage the wide and wider range of hosts, routers and other network devices that are used to implement IP networks and protocols. We should be talking nowadays about a toolset rather than one tool that fits all. However, this is a discussion that just starts. Regards, Dan -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Robert Raszuk Sent: Thursday, August 02, 2012 7:25 PM Cc: ietf@ietf.org Subject: Basic ietf process question ... All, IETF documents have number of mandatory sections .. IANA Actions, Security Considerations, Refs, etc ... Does anyone have a good reason why any new protocol definition or enhancement does not have a build in mandatory XML schema section which would allow to actually use such standards based enhancement in vendor agnostic way ? There is a lot of talk about reinventing APIs, building network wide OS platform, delivering SDNs (whatever it means at any point of time for one) ... but how about we start with something very basic yet IMHO necessary to slowly begin thinking of network as one plane. I understand that historically we had/still have SNMP however I have never seen this being mandatory section of any standards track document. Usually SNMP comes 5 years behind (if at all) making it obsolete by design. NETCONF is great and very flexible communication channel for provisioning. However it is sufficient to just look at number of ops lists to see that those who tried to use it quickly abandoned their efforts due to complete lack of XML schema from each vendor they happen to use or complete mismatch of vendor to vendor XML interpretation. And while perhaps this is obvious I do not think that any new single effort will address this. This has to be an atomic and integral part of each WG's document. Looking forward for insightful comments ... Best, R. ___ OPSAWG mailing list ops...@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [BEHAVE] Fwd: Re: Martin Stiemerling's Discuss on draft-ietf-behave-lsn-requirements-08: (with DISCUSS and COMMENT)
Hi, (I restricted this response to behave wg, since that is where lsn-requirements is chartered, not pcp wg; I added ietf@ietf.org since this is about a DISCUSS relating to ietf consensus). I think we should mandate something if interoperability will break if it is not done. But if the port-control aspect can be achieved using proprietary protocols with no impact on cgn operations, then a specific protocol should not be mandated. -- REQUIREMENTS for COMPLIANCE -- I frequently refer to the logic in the Strong Security BCP (RFC3365), which makes a distinction between what MUST be implemented in a compliant implementation, and what SHOULD be used by operators for interoperability between network elements. If an operator wants to set up a lsn-requirements-compliant CGN in a multi-vendor environment, will it be problematic if vendor A uses A-style port control, vendor B uses B-style port control, vendor C uses PCP, vendor D uses MIDCOM-MIB, and vendor E uses Diameter NAT control? If so, then there would seem to be justification to specify that **to be compliant to the IETF lsn-requirements standard/BCP/InformationalRFC recommendation** PCP MUST be implemented, so it is AVAILABLE if an operator chooses to use it. If implementers don't implement it in product, it won't be there for operators to use to achieve interoperability. Of course, a similar argument might justify also requiring implementation of Diameter NAT control and the MIDCOM-MIB. Do we want to require one specific standard as THE solution required to be compliant to this lsn-requirements standard, or do we want to provide a toolkit of multiple must-implement standards plus advice about how to combine them, and a deployer gets to choose which to use together, or do we want to specify a toolkit of implementation-optional standards that might be available and a deployer needs to figure out how to make the available options work together? Requiring PCP for compliance does not mean a vendor is required to implement PCP, any more than a vendor is required to implement BGP, but if a vendor claims to be BGP compliant, then there are aspects of BGP, or other standards that BGP relies upon being present, that MUST be there. If an implementer wants to claim compliance to the NAT-MIB, they MUST also implement ifIndex (and presumably SNMP to access the MIB). If a vendor claims to be compliant to the lsn-requirements standard (or BCP or Informational RFC) then they MUST implement those aspects that are required for compliance. Now, in the security world, where security is a system-wide process, if using multiple algorithms can create hard-to-detect security holes, there is strong justification for REQUIRING specific protocols be used across devices/vendors to avoid introducing such holes into the system. And, in the security world, there is a whole community of attackers looking for those holes so they can take advantage of such weaknesses in the overall security system. If CGN interoperability is not significantly impacted by having multiple types of port forwarding or other middlebox algorithms rather than a single algorithm, other than extra work for operators, then we probably should not REQUIRE, but simply RECOMMEND a standards-based solution such as PCP. We should NOT require it just because we want to see vendors use our protocols; that is a market-driven decision to be made by vendors based on customer demand. -- David Harrington Internet Engineering Task Force (IETF) ietf...@comcast.net +1-603-828-1401 On 7/19/12 8:51 AM, Simon Perreault simon.perrea...@viagenie.ca wrote: Behaviers, PCPers, During IESG review of draft-ietf-behave-lsn-requirements, a DISCUSS was filed regarding the PCP requirement. Details below. I think this DISCUSS needs to be discussed. So please discuss. Please reply to beh...@ietf.org. Thanks, Simon Message original Sujet: Re: Martin Stiemerling's Discuss on draft-ietf-behave-lsn-requirements-08: (with DISCUSS and COMMENT) Date : Thu, 19 Jul 2012 10:46:42 +0200 De : Martin Stiemerling martin.stiemerl...@neclab.eu Pour : Simon Perreault simon.perrea...@viagenie.ca Copie à : The IESG i...@ietf.org, behave-cha...@tools.ietf.org, draft-ietf-behave-lsn-requireme...@tools.ietf.org Hi Simon, all, On 07/17/2012 11:11 PM, Simon Perreault wrote: Le 2012-07-17 16:42, Martin Stiemerling a écrit : Each and every CGN MUST have PCP and MUST follow the constraints. I'll fix the text in a later revision. Can we mandate a specific protocol to be used for this or can we only mandate that such a type of protocol is being used? I don't see the IETF in the position to mandate this type of protocol for CGNs. There are other protocols out there which might be suitable. Note that I am co-author of some, but this isn't the reason for the question. I do not get any reward if I promote these protocols. It is more: do we need to constrain CGN deployments to a protocol (PCP) which is developed right now
draft-ietf-behave-lsn-requirements - BCP, STD, AS, or Informational?
-- BCP or not? -- As previously-responsible AD for behave, I have had serious concerns about this document being published as a BCP. In another email, I discussed whether PCP should be required to be compliant to this BCP. I think the IETF needs to decide whether lsn-requirements is something to be compliant to. The title and BCP status seem rather misleading, in my opinion. Following RFC3365, MUST is for implementers; SHOULD is for deployers. If we want to require vendors to implement specific features in a manner COMPLIANT to this specification, then this really should be a standard, not a BCP. If we want to standardize implementation behaviors, then I think this should be an explicit standard, not some other type of RFC that will implicitly be a standard but with possibly less scrutiny than an explicit standard would generate. A BCP often carries similar weight to a standard, and I question whether some of these requirements are best CURRENT practice, especially if PCP is a MUST. It might be best DESIRED practice, or best RECOMMENDED practice, but I doubt some of these requirements are best CURRENT practice. If we simply want to document what some existing deployments are doing, then I think an Applicability statement or an Informational RFC might be more appropriate than a BCP. I think this should be a BCP only if there is a strong consensus that this is the way deployments SHOULD be done, based on actual deployment experience by a variety of operators using current implementations - that would represent best CURRENT practices. -- David Harrington Internet Engineering Task Force (IETF) ietf...@comcast.net +1-603-828-1401 On 7/19/12 8:51 AM, Simon Perreault simon.perrea...@viagenie.ca wrote: Behaviers, PCPers, During IESG review of draft-ietf-behave-lsn-requirements, a DISCUSS was filed regarding the PCP requirement. Details below. I think this DISCUSS needs to be discussed. So please discuss. Please reply to beh...@ietf.org. Thanks, Simon Message original Sujet: Re: Martin Stiemerling's Discuss on draft-ietf-behave-lsn-requirements-08: (with DISCUSS and COMMENT) Date : Thu, 19 Jul 2012 10:46:42 +0200 De : Martin Stiemerling martin.stiemerl...@neclab.eu Pour : Simon Perreault simon.perrea...@viagenie.ca Copie à : The IESG i...@ietf.org, behave-cha...@tools.ietf.org, draft-ietf-behave-lsn-requireme...@tools.ietf.org Hi Simon, all, On 07/17/2012 11:11 PM, Simon Perreault wrote: Le 2012-07-17 16:42, Martin Stiemerling a écrit : Each and every CGN MUST have PCP and MUST follow the constraints. I'll fix the text in a later revision. Can we mandate a specific protocol to be used for this or can we only mandate that such a type of protocol is being used? I don't see the IETF in the position to mandate this type of protocol for CGNs. There are other protocols out there which might be suitable. Note that I am co-author of some, but this isn't the reason for the question. I do not get any reward if I promote these protocols. It is more: do we need to constrain CGN deployments to a protocol (PCP) which is developed right now, or are we open to existing or future protocols, or whatever folks deploying this deem right? I would propose to change REQ-9 to : REQ-9: A CGN MUST include a middlebox control protocol that allows manipulation of CGN bindings with the following contstraints list items A and B REQ-9a: If PCP is used these contstraints MUST be applied in addition to contraints A and B: list items C and D That was discussed in IETF 81 (Québec). Here's the extract from the minutes: Stuart Cheshire: ietf has one port forwarding protocol, which is PCP, so we should require it by name There are multiple middlebox control protocols published by the IETF (standards track and experimental) and I have not seen any call for consensus on what **the** IETF's middlebox control is, neither I have seen any RFC that states this. I do not see that an individual can declare IETF consensus based on his own opinion. Dave Thaler: I agree. PCP doc is in final stages. Again, an opinion of an individual. Nothing wrong about it, but it does not state IETF consensus. There was consensus from the WG. In consequence, the text was changed from this (-02): A CGN SHOULD support a port forwarding protocol such as the Port Control Protocol [I-D.ietf-pcp-base]. to this (-03): A CGN SHOULD include a Port Control Protocol server [I-D.ietf-pcp-base]. (That requirement later became a MUST, but that's orthogonal to what protocol we require.) I do not see that the IETF can mandate what protocols are being used to control a device. The market will decide! For instance, the is no MUST required that routers implement BGP. It is good to do this, but if one decides to go for IS-IS (or whatever) that is just fine. Another example, there is also no MUST requirement that routers
Re: [BEHAVE] [pcp] Fwd: Re: Martin Stiemerling's Discuss on draft-ietf-behave-lsn-requirements-08: (with DISCUSS and COMMENT)
On 7/19/12 9:02 AM, Sam Hartman hartm...@painless-security.com wrote: I think that behave-lsn-requirements is far more useful if it names a specific protocol by name. By endorcing one of our middlebox protocols, we encourage interoperability. If we don't pick a protocol by name, we don't really promote interoperability. It's not useful if your CGN does midcom and my client does PCP and I'm your customer. The assumption behind LSN-requirements is that the CGN and the CPE are not controlled/purchased/whatever by the same entity. So, mandating a specific protocol seems desirable. The IETF could mandate a specific protocol to try to ensure interoperability, but doing this takes the decision out of the responsibility of the deployer to choose the best solution for the deployment environment, and out of the responsibility of the vendor to best meet their customers' demands. Some vendors already support an SNMP-based environment, and a CGN-NAT-MIB might best meet their needs. Some vendors might support a Netconf environment and desire a Netconf-based configuration solution. Some vendors already use AAA widely to control their environment, and Diameter NAT control might be preferable. Some vendors might be implementing the (not yet IETF-approved) PCP standard, and would prefer that solution. I think that the behave WG is the right place to make that decision. The IETF as a whole should be able to second guess behave, but we should need a fairly high bar for doing so. I think that **within IETF**, behave wg might have the right expertise to make this decision (technical comparison of middlebox protocols by protocol designers). Of course, no current WG has much input from proponents of the original MIDCOM WG strategy, and most Diameter proponents are not very active in behave wg. And behave DOES have an overlap between the PCP developers and behave solutions. So behave WG might be rather biased toward a specific solution (not that the bias is necessarily bad, but the bias should be recognized). Of course, if CGN is only an ipv4 exit strategy, as is asserted, then sunset4 would seem the appropriate choice, so we have one consistent ipv4 exit strategy. We already recognize that different wgs are developing ipv4 exit strategies that conflict; that's why a sunset4 wg has been approved. And if CGN **is** only for ipv4-sunsetting, a this IETF recommendation becomes obsolete on such-and-such a date might be appropriate for lsn-requirements. The right expertise might be in the sunset4 wg, which might have increased operator input about a complete ipv4/ipv6 transition deployment strategy rather than middlebox protocol design comparisons by middlebox protocol designers. While I would love to see consensus for a good interoperable solution, and would support ***A*** standard that says to be compliant to THIS specification, use THIS middlebox proposal, I hesitate to say this is the ONLY middlebox standard that is recommended or usable within IETF standards - especially if that only recommended part has little or no actual field experience to back up the RECOMMENDED, and little or no documentation has been done of the suitability/useability in various environments of the existing IETF standards that would become NOT RECOMMENDED. I think the right place to make the decision about which midcom solution should be used in a particular environment is in the market. My cable provider lets me purchase/control my cable router (to a degree), but only certain routers are supported. I can choose which cable router offers the additional functionality/control I want for my environment. My provider has input to the decision, and so do I (to a limited extent). Of course, to a limited extent, I can also choose a different provider or get less support from my provider. The claim that PCP is the IETF's only protocol in this space does seem a little bit on the wishful thinking side of things. So, I could understand if the IESG wanted to ask behave to spend a little more time on the question. +1 (or ask sunset4 to spend a little more time on the question). David Harrington ietf...@comcast.net +1-603-828-1401
Re: [BEHAVE] WG Review: Recharter of Behavior Engineering for Hindrance Avoidance (behave)
Hi Cullen, I would assume the MIB module would be written in a way to be IP version agnostic. But I'm not sure the NAT technologies are version agnostic. And I'm not sure that the current NAT-MIB can support the version-agnostic addressing textual conventions (I haven't looked yet). I have similar expectations regarding ipfix IEs. -- David Harrington Internet Engineering Task Force (IETF) ietf...@comcast.net +1-603-828-1401 On 5/25/12 6:30 PM, Cullen Jennings flu...@iii.ca wrote: WIll the IPFIX and MIB work also be usable by v4 to v4 NATs? On May 15, 2012, at 11:53 AM, IESG Secretary wrote: A modified charter has been submitted for the Behavior Engineering for Hindrance Avoidance (behave) working group in the Transport Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (i...@ietf.org) by Tuesday, May 22, 2012. Behavior Engineering for Hindrance Avoidance (behave) - Current Status: Active Last updated: 2012-05-10 Chairs: Dan Wing dw...@cisco.com Dave Thaler dtha...@microsoft.com Transport Area Directors: Wesley Eddy w...@mti-systems.com Martin Stiemerling martin.stiemerl...@neclab.eu Transport Area Advisor: Wesley Eddy w...@mti-systems.com Mailing Lists: General Discussion: beh...@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/behave Archive:http://www.ietf.org/mail-archive/web/behave Description of Working Group The working group creates documents to enable IPv4/IPv4 and IPv6/IPv4 NATs to function in as deterministic a fashion as possible. To support deployments where communicating hosts require using different address families (IPv4 or IPv6), address family translation is needed to establish communication. In BEHAVE's specification work on this topic it will coordinate with the V6ops WG on requirements and operational considerations. An IPv4 network or an IPv6 network in the descriptions below refer to a network with a clearly identifiable administrative domain (e.g., an enterprise campus network, a mobile operator's cellular network, a residential subscriber network, etc.). It will also be that network that deploys the necessary equipment for translation. BEHAVE will finish four scenarios: (1) An IPv6 network to IPv4 Internet, (2) an IPv6 Internet to an IPv4 network, (3) an IPv6 network to an IPv4 network, and (4) an IPv4 network to an IPv6 network. Specifically, BEHAVE will update the NAT MIB (RFC 4008) to be consistent with the management aspects of its IPv6/IPv4 NAT solutions, and specify IPFIX information elements to meet logging requirements, reusing existing elements, if possible. In addition, when a NAT (such as a NAT64 in the An IPv6 network to IPv4 Internet scenario) serves multiple subscribers, inter-subscriber fairness issues arise. As such, BEHAVE will complete its work on Carrier Grade NAT requirements for such scenarios, and update the NAT MIB as needed to meet such requirements. BEHAVE will not, however, standardize IPv4-specific behavioral mechanisms. The following scenarios remain in scope for discussion, but will not be solved by BEHAVE: * An IPv4 network to IPv6 Internet, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv4 host towards an IPv6 host. The translator function is intended to service a specific IPv4 network using either public or private IPv4 address space. * IPv4 Internet to an IPv6 network, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv4 host towards an IPv6 host. The translator function is intended to service a specific IPv6 network where selected IPv6 hosts and services are to be reachable. This group will also provide reviews of any work by the MBoneD WG on multicast translation, including control traffic (IGMP and MLD), Single Source Multicast (SSM) and Any Source Multicast (ASM). If the WG deems it necessary, BEHAVE will revise RFCs previously published by BEHAVE. Goals and Milestones Done Submit BCP that defines unicast UDP behavioral requirements for NATs to IESG Done Submit a BCP that defines TCP behavioral requirements for NATs to IESG Done Submit a BCP that defines ICMP behavioral requirements for NATs to IESG Done Submit informational that discusses current NAT traversal techniques used by applications Done Submit BCP that defines multicast UDP Done Submit revision of RFC 3489 to IESG behavioral requirements for NATs to IESG Done Submit informational document for rfc3489bis test vectors Done Submit experimental document that describes how an application can determine the type of NAT
Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)
Point taken. -- David Harrington Director, Transport Area Internet Engineering Task Force (IETF) ietf...@comcast.net +1-603-828-1401 On 2/22/12 12:31 PM, Paul Hoffman paul.hoff...@vpnc.org wrote: The earnest calls for better authentication on this thread appear to ignore the fact that the very things that are being requested were put out of scope for the websec WG in their charter. I hope that no one things that a WG in the Applications Area will be better equipped to come up with a better authentication mechanism than one in the Security Area. Asking the HTTPheads to guess what the securityheads might want is not a good way to design HTTP 2.0. Proposal: leave the httpbis WG charter as-is and re-charter the websec WG to consider what is needed in the HTTP authentication model. Later, recharter the websec WG to, you know, actually do the security work for authentication. --Paul Hoffman ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)
Hi, Having been involved in adding security after-the-fact to SNMP, and to Syslog, and adding authorization after-the-fact to netconf, I know it is extremely difficult to add security later. I strongly believe that if http is going to be redesigned enough to justify a 2.0 label, then security should be part of its design from the start. Therefore I think that security should be addressed as part of the http 2.0 effort, not after the fact. I can understand the concerns about doing both at the same time increasing the risk to both, and that serializing the work might reduce the risk. So I suggest you COULD design the web security standard first, and then design HTTP 2.0 to take the updated web security standards into consideration. Web security will be easier if it doesn't need to somehow fit into an HTTP 2.0 that didn't consider a viable security approach up-front. -- David Harrington Director, Transport Area Internet Engineering Task Force (IETF) ietf...@comcast.net +1-603-828-1401 On 2/21/12 6:01 PM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: On 02/21/2012 10:55 PM, Mark Nottingham wrote: Stephen, The approach we're advocating for this WG is to solicit well-formed proposals, select one and develop it. If there isn't one for HTTP authentication, how are you advocating we proceed? I'm not thinking now in terms of advocating a specific proposal for how to proceed. Right now, I'm interested in what others reviewing the draft charter think about this topic. That's the point of having this discussion in the open like this. (So maybe I should shut up for a while:-) S Regards, On 22/02/2012, at 9:53 AM, Stephen Farrell wrote: On 02/21/2012 10:40 PM, Mark Nottingham wrote: On 22/02/2012, at 9:19 AM, Stephen Farrell wrote: So as in my initial mail the 1st question here is, what does modern mean in this draft charter? E.g. does it mean same as the current framework with different bits or something else? If so, what? As discussed off-list, I'd be happy to drop this phrase from *this* charter, in anticipation of it being worked out in discussions about the *next* one. Well, I think the phrase does need to be replaced by something else all right. I'm reluctant to omit mention of security entirely of course and do want to know what's gonna be done for authentication in a putative HTTP/2.0. Like I said, I'm pretty skeptical that any significant change to security properties will be achievable at that next charter stage. And then should it include adding some new options or MTI auth schemes as part of HTTP/2.0 or even looking at that? (I think it ought to include trying for that personally, even if there is a higher-than-usual risk of failure.) Based on past experience, I think the risk is very high, and we don't need to pile any more risk onto this particular project. Based on past experience the milestones for this will be wildly optimistic and it'll really take five years so at the end of 2017 we'll be right where we are in terms of HTTP authentication for all of which time HTTP authentication will be the next thing to do. (Ok, I'm exaggerating a bit there.) I think both experiences are valid. Also, most of the discussions about authentication and associated problems on the Web are *not* exclusive to HTTP or even protocol artefacts; they include concerns like UI and human factors, integration into hypertext, etc. As such, what we really need is a whole of stack focus on Web authentication; shoving it into this particular WG will, IMO, lead to a predictable failure. It is true that many sites don't use HTTP authentication for UI reasons. I don't think it follows that doing nothing is the right approach. (Well, one could argue to remove all user authentication from HTTP I guess - is that one of the proposals?) Cheers, S. -- Mark Nottingham http://www.mnot.net/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
TSVDIR review request - draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat
Hi, This review did not get copied to IESG or IETF lists. David Harrington Director, IETF Transport Area ietf...@comcast.net (preferred for ietf) dbharring...@huaweisymantec.com +1 603 828 1401 (cell) -Original Message- From: Woundy, Richard [mailto:richard_wou...@cable.comcast.com] Sent: Wednesday, June 22, 2011 6:45 PM To: David Harrington; 'Transport Directorate' Cc: draft-ietf-v6ops-ipv6-multihoming-without-ipv6...@tools.ietf.org; Woundy, Richard Subject: RE: tsvdir review request - draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat Can you do a tsvdir review of draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat? Here are my high level comments on this internet draft. - The document covers host and gateway requirements, but omits any service provider requirements (eg DHCPv6 option support). - The security considerations are weak (eg evil policy) and should be more detailed. - The source address selection drafts are dead or expired, which does not provide confidence that anyone is working on one of the key solutions advocated by this draft. - Someone should review the entire document for English grammar, especially section 1. But if these issues were resolved, this would be a good draft that solves important IPv6 deployment issues. Detailed comments. Section 1. NAT based multihoming is easily deployable and already deployed technique. an already deployed technique The same situation that depends on NAT technique may be brought to the IPv6 world. Maybe should say The same situations that require the NAT technique to be used in the IPv4 world may be applicable to the IPv6 world? Whenever a host or small network (which does not meet minimum IPv6 allocation criteria) is connected to multiple upstream networks IPv6 address is assigned by each respective service provider... an IPv6 address is assigned resulting in hosts with more than one active IPv6 addresses. one active IPv6 address As each service provided is allocated... service provider So, the goals for IPv6 multihoming definced in [RFC3582] do not exactly match the goals of us. defined in and match the goals of this document If multiple routers exist on a single link the host must appropriately select next-hop for each connected network. must select the appropriate next-hop it is conceivable that the packets that have inappropriate source address... have an inappropriate source address A DNS query sent to an arbitrary upstream resolver may result in incorrect or poisoned responses Add a period to the end of the sentence. A possible consequence of assigning a host multiple identical-scoped addresses... identically-scoped Section 3.3. making it essential for the host to correctly resolve these three criteria before sourcing the first packet. resolve these three items... Section 4.2. This section is entitled Policy providing, which feels like a very awkward term. Have you considered Policy distribution or something similar? I think there may be a few missing requirements for providing mechanisms. For one, administrators of different networks seem to need to control policies (and nodes' behaviors) independently of other administrators. For another, administrators must control only nodes that are part of their own networks. Section 5. General comment. This draft puts requirements on the host (O/S), home gateway and ISP. Any one missing piece will break this solution. This all-or-broken approach makes this solution unlikely to be successful for some time because we can't have an incremental approach. That said, if we have all the pieces, this should work. Section 5.1. Scenario 1: Host needs to support the solution for this problem Scenario 2: Host needs to support the solution for this problem Missing periods. Also note that the service providers (ie ISP and enterprise / VPN) must also support this solution (ietf-6man-addr-select-opt). Section 5.2. Scenario 1: Host needs to support the solution for this problem Scenario 2: GW rtr needs to support the solution for this problem Scenario 3: Host needs to support the solution for this problem Missing periods. Also note that the service providers (ie ISP and enterprise / VPN) must also support this solution (ietf-mif-dhcpv6-router-option). Section 5.3. [I-D.ietf-mif-dns-server-selection] proposes a solution for DNS server selection policy providing solution with a DHCPv6 option. Perhaps it would be simpler to say [I-D.ietf-mif-dns-server-selection] proposes a solution for distributing DNS server selection policy using a DHCPv6 option. Scenario 1: Host needs to support the solution for this problem Scenario 2: GW rtr needs to support the solution for this problem Scenario 3: Host needs to support the solution for this problem Missing periods. Also note that the service providers (ie ISP and enterprise / VPN) must also support this solution (ietf-mif-dns-server-selection). Section 6.1. the staticness of the assumed target network
RE: IESG position on NAT traversal and IPv4/IPv6
Hi Hadriel, I believe I'm the AD you are referring to. I made the comments as a technical contributor, but also said that my opinion was informed by discussions within the IESG. I think your characterization of my comments is a bit incorrect: In one of the working group meetings this past week, when the group was discussing a NAT traversal solution for their new protocol, an A-D suggested they not spend much time on NAT traversal. He/she indicated the IESG was discouraging NAT traversal mechanisms for new protocols, in order to foster demand for IPv6 instead. The A-D further noted that we really want it to run over IPv6 more than we want it to run over IPv4. After being asked for clarification he/she said that if you build something that will encourage people to stay on IPv4 longer, when you send it into the IESG you will get pushback. I never said the IESG is discouraging NAT traversal mechanisms for new protocols, The slide being shown differentiated the application from the NAT traversal mechanism. If your core protocol (ppsp tracker) ONLY works with a NAT'd transport (which the slides could be interpreted to mean), I believe you will get pushback. My advice at the mic was to build the solution in such a way that it is transport agile. I explicitly made the parallel with the security requirement for algorithm agility. The application aspects of the solution should not be dependent on a NAT-specific transport solution. I said (feel free to check the session recording, (ch3-fri-am 1:25), which is where I got the following text from): I want to make sure you do not spend a tremendous amount of time designing something that works for all kinds of NATs, because our goal is to get rid of NATs [said with a grin]. It's not everybody's goal obviously. The IESG wants to see the migration to IPv6 completed, and one of the things that we are seriously pushing back on is anything that will help you keep NATs around longer so you can keep IPv4 around longer, because we believe that's a bad solution to the runout of IPv4 addressing. We recognize that right now you need to deal with IPv4 networks, so therefore you have to deal with this, but don't build a lot of assumptions into your core protocol because we really want it to run over IPv6 more than we want it to run over IPv4. and later we're trying to get people to go to IPv6. If you are building something that will encourage people to stay on IPv4 even longer, when you send this into the IESG you will get pushback. Maybe my language was not as well considered as it should have been, but it is my understanding that IETF consensus is to have the industry transition from IPv4 to IPv6. If your core protocol ONLY works with an IPv4 NAT'd transport, I believe you will get pushback. The solution should also be able to work in other environments, such as an un-NAT'd IPv6 environment. David Harrington On Mon, Nov 15, 2010 at 12:19 AM, Hadriel Kaplan hkap...@acmepacket.com wrote: Hi, In one of the working group meetings this past week, when the group was discussing a NAT traversal solution for their new protocol, an A-D suggested they not spend much time on NAT traversal. He/she indicated the IESG was discouraging NAT traversal mechanisms for new protocols, in order to foster demand for IPv6 instead. The A-D further noted that we really want it to run over IPv6 more than we want it to run over IPv4. After being asked for clarification he/she said that if you build something that will encourage people to stay on IPv4 longer, when you send it into the IESG you will get pushback. I am not going to name the WG nor A-D, because I'd rather encourage A-D's to speak their mind, and it doesn't matter who it was. Also, anyone can make a mistake or be mis-interpreted, and perhaps that's all this was. (We don't read written prepared statements at the mic, after all :) What I'd like to know is the IESG's position with respect to protocols trying to make themselves work around NATs in IPv4. I'd like to know if the IESG will push back on new protocols if they attempt to work around NATs. I would also like to understand the IESG's position with respect to IPv6 and whether protocols should not attempt to make themselves work around potential IPv6 NATs; and more importantly to handle the possibility that the firewall-type policies which NATs have by nature, may continue to be used in IPv6 on purpose even if addresses/ports don't get mapped. I appreciate the workload you are always under, but I think it's important for us outside the IESG to know. If this is not the right medium/process for asking such questions, my apologies... and please let me know the right way. :) Thanks, -hadriel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Proposed WG and BOF Scheduling Experiment
Hi, part of the justification is to have the BOF early in the week so people can discuss it during the week. dbh -Original Message- From: iesg-boun...@ietf.org [mailto:iesg-boun...@ietf.org] On Behalf Of Richard L. Barnes Sent: Monday, November 08, 2010 10:29 AM To: ietf@ietf.org Cc: wgcha...@ietf.org; The IESG Subject: Re: Proposed WG and BOF Scheduling Experiment If we put the BOFs on Friday afternoon instead, wouldn't that make the attendance numbers an even stronger gauge of interest? On 11/8/10 10:26 AM, The IESG wrote: The IESG is seriously considering a WG and BOF scheduling experiment. The goal of the experiment is to provide WG agenda sooner and also provide more time to craft BOF proposals. The proposed experiment includes three parts. First, schedule all BOFs for Monday afternoon. Second, schedule WGs before we know which BOFs will be held. Finally, provide an additional four weeks to deliver BOF proposal to ADs. Please let us know whether you support this experiment. Discussion is welcome on the mail list and the plenary on Wednesday evening. On behalf of the IESG, Russ Housley ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
SECDIR and OPSDIR review of draft-ietf-dhc-vpn-option-11
the potential conflicts abd resolutions are covered adequately. 13. section 5.1 what does if the relay agent is unable to honor the server requirement mean? This could be made less ambiguous. 14. section 5.1The DHCP server MUST NOT place VSS information in an outgoing packet if the relay agent or DHCP client is unprepared to properly interpret the VSS information. This seems ambiguous. How will the server know if the other entities can properly interpret the VSS information? s/send in/insert/ 15. section 4 says The DHCP client, in this scenario, does not know the VPN on which it resides. section 6 saysA DHCPv4 or DHCPv6 client will employ the VSS option to communicate VSS information to their respective servers. This information MUST be included in every message concerning any IP address on a different VPN than the global or default VPN. these statements seem to conflict regarding the client's knowledge. 16. section 6:Clients should be aware that some DHCP servers will return a VSS option with different values than that which was sent in. In addition, a client may receive a response from a DHCP server with a VSS option when none was sent in by the Client. So should subsequent messages from the client use the original VSS information or the server-returned or relay-returned VSS info? Can a return message contain multiple VSS options? If I read the document correctly, multiple relays can add their own VSS options, and a server typically copies all the options. If a client is expected to include the VSS option information in subsequent messages, does it include multiple VSS options? The second paragraph of 6 says that is not allowed. David Harrington dbharring...@comcast.net ietf...@comcast.net dharring...@huawei.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Request for community guidance on issue concerning afuture meeting of the IETF
Hi, Here are my impressions regarding the areas of concern you raise. (1) The law and associated hotel rule Marshall quoted could be violated by what may appear to IETF participants as technical discussion. For example, the manipulation/censorship of Internet traffic by or under orders of the Chinese government is well known. If this were to be mentioned or discussed during the IETF, perhaps in the context of encryption, tunneling, web proxy, DNS, or some other technical area, we could run be violating the law and hence the rule. I have worked for a subsidirary of Huawei, and now work for HuaWeiSymantec (a joint venture startup) and visit Beijing once or twice a year. I don't know if the venues under consideration are in Beijing, but I assume that is fairly likely. These opinions are my own and do not in any way represent the opinions of Huawei or HuaweiSymantec. I have personal concerns about censorship and manipulation of Internet traffic. I don't have anything to hide, and do not regularly post views I expect the Chinese government might find offensive, so it does not impact me directly, but it does impact me indirectly. I had some difficulty reaching some web sites, although they were mostly news websites that might discuss politically-sensitive topical issues. I do not remember having difficulty reaching any websites critical to my IETF work. The HQ of HuaweiSymantec is in Hong Kong, and my boss who lives there tells me that HK is not subject to the censorship on the China mainland. So maybe meeting in Hong Kong would allow us to meet in China, without the censorship. (But I personally found HK very expensive compared to mainland China) I doubt the Chinese government, or the hotel, is likely to interfere in our technical discussions. Some lively plenary discussions about government-regulation impact on Internet technologies, such as the net neutrality discussion in the Washington meeting and the encryption regulations discussion we had in Danvers, might make our Chinese participants and our host uncomfortable. I would be a bit cautious about political discussions in public venues outside the official meeting, e.g., over dinner or in bar BOFs. Bush-bashing and other disrepect for our leaders is considered great sport in Western countries; In China, for cultural reasons based on a very long history going back at least to Confucious, this type of disrespect for one's leaders is apparently considered very poor manners. I am pretty sure that disrespect for their leaders would be very very poor manners. The locals are much more likely to consider you a barbarian than to want to engage in such discussions of their leaders. (2) This is a very personal concern, but my experience with China is that it is among the worst places to try and avoid tobacco smoke. I have not found avoiding smoke in China much worse than in Europe. I find it much easier to avoid smoke in US cities. (3) Similarly to (2), my experience in Bejing has been that the air is exceptionally polluted. Hence, I'd be concerned for those IETF members who would find this makes participation difficult. Auto emission pollution in Beijing is a real problem. If you have any respiratory problems, I recommend you avoid heavy-traffic areas of Beijing. This problem is mostly an outdoor problem, not an indoor problem. You can mitigate the pollution by wearing surgical masks when outside (which is fairly common in Beijing). I assume the air handling systems in a conference center and major international hotels would mitigate this while indoors. I think the level of poluution in Beijing is a valid concern when evaluating venues. David Harrington dbharring...@comcast.net ietf...@comcast.net dharring...@huawei.com -- Randall Gellens Opinions are personal;facts are suspect;I speak for myself only -- Randomly selected tag: --- The solution to a problem changes the nature of the problem. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: IPv6 standard?
Hi, As part of declaring IPv6 a full standard, would we also declare IPv4 obsolete or Historic? dbh -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Iljitsch van Beijnum Sent: Friday, September 11, 2009 11:25 AM To: IETF Discussion Subject: IPv6 standard? Hi, It occurs to me that a small but potentially meaningful thing that the IETF could do to push IPv6 adoption is move RFC 2460 from draft standard to standard. Iljitsch ___ 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-reschke-rfc2731bis (RFC 2731 is Obsolete) toInformational RFC
Hi, I find the title irritating. I had to go open the draft to know what it was obsoleting. Reading the abstract, I find that the draft proposes declaring RFC2731 Historic (not Obsolete) So the title is actually misleading. But wait. According to the heading, if approved, this draft will obsolete RFC2731. Which are we doing Historic, or Obsolete? (can you do both simultaneously?) In actuality, what this draft is doing is transferring responsibility for further development of the Encoding Dublin Core Metadata in HTML to Dublin Core Metadata Initiative. Neither RFC2731 nor this draft make it clear whether RFC2731 was a snapshot of work that was done by the Dublin Core Metadata Initiative and simply published as an Informational draft to inform the IETF, or whether RFC2731 was contributed to the IETF with the intent of developing an IETF standard (and subsequently failed). There is almost no discussion of why RFC2731 is being declared obsolete/Historic and why further development has moved to the Dublin Core Metadata Initiative. I had occasion to coordinate the transfer of responsibility from the IETF to IEEE for some work, and had to spend significant effort working through the copyright issues and the migration issues (RFC4663). The work being transferred in RFC4663 is an IETF standard, whereas RFC2731 is only Informational, so that could make a lot of difference, but there is simply no discussion at all of copyright issues and migration issues. And the reasons why RFC2731 is not still considered valid (just an earlier version), or why this step to declare the RFC Historic is being done are extremely light. Is it to prevent it being used because this old version and the updated work cannot coexist? or do we just not like this one any more? Is it because the effort to standardize failed? (Did the Initiative want to keep editorial control, and when they found out they couldn't if it was standard, they took their ball and went home? Is this draft to provide a pointer to the Initiative because providing this pointer in an RFC sort of implies that IETF endorses the Initiative as the SDO for setting a standard(?) for this metadata? (I notice there are Editorial notes to remove some text; are all mentions of the Initiative being removed? I couldn't tell the scope of the Editorial note. It might be better to see an updated version that has been cleaned up, so there are no misunderstandings about what should be in the published RFC.) RFC2731 contains perl code. They are published with this text that appears to be a license: They may be taken and freely adapted for local organizational needs, research proposals, venture capital bids, etc. If RFC2731 is obsoleted, does this in any way affect the license and the legal rights of implementers of RFC2731? This is not discussed. I find this draft not very satisfying because it simply ignores so much. In security considerations sections, it is acceptable to say hey, we considered this and reached the conclusion that authentication and authorization and other security features are not needed. It is not considered acceptable to simply omit any discussion of the security considerations. I don't want new boilerplates, but there are a bunch of issues related to this document that are simply not discussed. I think this document should include (very small) sections that reflect that copyright issues have been considered; that authors rights in RFC2731 have been considered; that migration issues for implementers of RFC2731 have been considered; that licensing issues for the contained code have been considered. None of this has been documented, so a reader cannot know whether these have been considered and not documented, or simply overlooked. I do not think this document is ready for publication as an RFC. David Harrington dbharring...@comcast.net ietf...@comcast.net dharring...@huawei.com -Original Message- From: ietf-announce-boun...@ietf.org [mailto:ietf-announce-boun...@ietf.org] On Behalf Of The IESG Sent: Wednesday, September 09, 2009 9:31 AM To: IETF-Announce Subject: Last Call: draft-reschke-rfc2731bis (RFC 2731 is Obsolete) toInformational RFC The IESG has received a request from an individual submitter to consider the following document: - 'RFC 2731 is Obsolete ' draft-reschke-rfc2731bis-02.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 2009-10-07. 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 file can be obtained via http://www.ietf.org/internet-drafts/draft-reschke-rfc2731bis-02.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=vie w_iddTag=18624rfc_flag=0
RE: One Day Pass Proposal was Re: One Day Pass for newcomers
Looks good to me. I have concerns about #6, since it is fairly common that we run light on food during the reception. And if there are limits on the reception, then I think it reaosnable to favor those who paid for the full week. But I can support the experiment. Will One Day Pass first-timers be invited to the First-Time Attendees reception as well? dbh -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Ray Pelletier Sent: Monday, August 24, 2009 2:37 PM To: Doug Barton Cc: John C Klensin; 'IETF-Discussion' Subject: One Day Pass Proposal was Re: One Day Pass for newcomers All; Let me offer a suggestion for which we would like to receive quick and constructive feedback so that the opening of the IETF 76 registration will not be delayed. One Day Pass Program A person may purchase a One Day Pass to attend any one day of the IETF Meeting for $200. Benefits of the One Day Pass: 1. Attend all sessions during any one day of the Meeting, and partake of the food and beverage during the breaks that day 2. Day can be selected during online registration, but can be changed onsite without penalty 3. Payments may be made onsite without a late fee 4. Pass can be upgraded to a full Meeting Registration, however, late fee may apply if initial Pass payment not made before Early Bird deadline (Note: Intended to discourage gaming the system) 5. Attend Sunday Tutorials at no additional charge 6. Attend Sunday Welcome Reception at no additional charge 7. Attend Wednesday and Thursday Plenaries at no additional charge 8. Purchase a ticket 4 - 5 PM on Tuesday to attend the Host's Tuesday evening Social, if tickets are available Ray IAD On Aug 23, 2009, at 9:47 PM, Doug Barton wrote: John C Klensin wrote: --On Sunday, August 23, 2009 14:18 -0700 Doug Barton do...@dougbarton.us wrote: ... So, if someone doesn't get at least a day pass, I'd be happier if we charged a nominal (even if only $10 - $20) fee for registration for the tutorial than just open the doors. I disagree here. I think that opening the newcomer's session and (if the host is agreeable) the reception on Sunday to all comers would have way more benefits than costs. Of course we would have to capitalize on all those fresh bodies by having registration open and suitable promotional materials for both full and one-day registration prominently (yet tastefully) displayed. Doug, I think that the ability for active participants in the IETF to get into the reception and even eat is fairly important, probably more important than encouraging first-timers and visitors. I hope that you would agree with that, even though we would both prefer to have no restrictions in that regard. I definitely agree that if I pay for IETF I want my shot at the dried out chicken wings, yes. :) FWIW I'm not trying to minimize your concerns, which I think are valid. I simply think that reasonable minds can differ on the cost/benefit analysis. What caused my suggestion for a nominal fee and some sort of preregistration (which that fee would imply) was a vision of the IETF meeting in a location with nearby college campuses and the possibility of signs (possibly put up by third parties) advertising the reception and noting free food and, depending on the location and sponsor free beer. I leave the rest to your imagination. Well, you seem to have a darker view of human nature than I do, and that's saying something. There are ways to solve both problems I think, such as setting aside the first 30 minutes for paid participants and opening the doors wide after that. In any case I don't want to overengineer the social events. I personally think that we should use the golden rule. Whoever pays the gold for the event gets to make the rules. Regardless of where we come out on the socials I think it would be good to have some kind of consensus on opening the newcomer session and the plenaries, at minimum to those who pay for day passes (and IMO for all comers). There's only a little over 2 months till Hiroshima, so it would be nice to have a settled policy on this soon-ish so that people can make their plans appropriately. Doug ___ 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: meta-issues on charter discussions (was: Re: WG Review: Recharter ofInternationalized Domain Names inApplications, Revised (idnabis))
Hi, Personally, I would like to see deltas kept for updated charters, especially the milestone information, so we can go back and find out how timely a WG has achieved its completed objectives. When I try to determine whether participating in a WG seems justified, one thing I want to know is whether that WG if effective. Not being able to see when a milestone was supposed to be completed versus when it was completed makes that harder to determine. And when a re-charter causes the old milestones to disappear, we are throwing away useful information. dbh -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Spencer Dawkins Sent: Wednesday, August 19, 2009 1:40 PM To: i...@ietf.org Cc: ietf@ietf.org Subject: meta-issues on charter discussions (was: Re: WG Review: Recharter ofInternationalized Domain Names inApplications, Revised (idnabis)) Dear IESG, I can't think of ANYONE who wouldn't be better off if we published deltas for WG charter revisions when we ask for comments. We can each trivially produce our own deltas, but if you want feedback from the community, providing deltas is likely to get more (and more helpful) feedback. If the approach taken also accommodated the kind of charter thrashing where Robert could distribute two revisions of SIP-CLF before IETF 75, distribute three revisions to the proposed charter three times during IETF 75 based on hallway and meeting room discussions, and send out a here's where the proposed charter is e-mail (with a trail showing how we got there) after IETF 75, that would be even better. Robert is good and has SIP-CLF charter revisions under source code control, but it would be superb if all of the proposed revisions were under source code control at the same location. Much like we now do for Internet-Drafts... :D IMO, of course. Thanks, Spencer Looking at this recharter, the immediate question I had was what has actually changed in the charter? so I can figure out if I care. I gather there is one very small change. But you'd have to be a WG insider to know this. Also, reading through the charter, it reads like it was written a year and a half ago (which it was), and parts of the text in the charter are OBE, so just reading the charter as is gives a misleading picture of where things currently stand. I guess I'm raising a bit of a meta point here that this recharter announcement is not very helpful to the general community, which seems bad. And if the charter needs to be updated, it really should be updated to reflect the current state of play. In particular: - it is not easy to figure out what has actually changed relative the current charter (this could have been handled by a short note providing context as part of the announcement). - it includes actions of the form will do that I believe have already been done. (e.g., there are 6 WG documents, not 4 as the charter suggests, the design team is presumably no longer driving this, as the documents are fully WG ones now, and the WG is not doing an extended review of the DT output, etc.) Now, I suspect that it was decided to minimize the amount of work needed to recharter and thus just update the one or two important sentences in the charter, and I sympathize with that desire. But I would also hope we could at least update it so that the average IETF reader (or anyone interested in IDNs for that matter) could read the charter and understand the current state of play. I don't think it would take a lot of effort to update it, and I'm not calling for any subtantive changes. They should all be editorial, so additional changes should not be controversial. IESG Secretary iesg-secret...@ietf.org writes: Goals and Milestones: Apr 2008 WG formation May 2008 Decision on form and structure of the WG document set Sep 2008 WG Last Call on WG document set Nov 2008 IETF Last Call on WG document set Oops! Thomas ___ 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: One Day Guest Pass
Hi, We are running multiple experiments. One is automated registration. One is RFID. Another is charging for subsets of attendance. Maybe we should have an RFID reader/recorder at the door to each session, and to send bills to people based on what they actually attend (plus a base fee). Attendees could get their RFID badge, attend whatever they want during the week, we record their attendance using RFID, and then bill them afterwards for the sessions they actually attended. This approach might also cut down on people using sessions to just read email and power their computers; the terminal room might become more popular. I suggest the automated registration allow people to specify the sessions they are interested in when they register, which would help scheduling match rooms to expected attendees, and help avoid timing conflicts. The registration process should identify ADs and chairs and editors, whose conflicts are more important than regular attendees. When chairs decide what presentations will be given, maybe they could update the registration to identify presenters, so that could also be used for conflict resolution. These could of course be features in v2.0. Can we RFID-tag the cookies so we can charge according to how many one eats? ;-) dbh -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Ole Jacobsen Sent: Wednesday, August 19, 2009 5:03 PM To: Ross Finlayson Cc: ietf@ietf.org Subject: Re: One Day Guest Pass Ross, It's an experiment, as Alexa stated. Experience from RIPE tend to suggest that the OVERALL attendance goes up as a result of the availability of day passes. We don't yet know if this applies to the IETF. Yes, we want to encourage people to stay for the whole week for all the reasons you cite, but the economic- and time-related reality tells us that this isn't always possible. As John Klensin pointed out, this leaves us with three options: * Make day-passes available * Let people sneak in * Accept that some people will not attend who would attend if we gave them the one-day option. It is quite possible that a one-day pass option would cause people to pay for one day and stay for the whole week, particularly since we're not known for having armed guards and badge checkers, but I don't get the sense that there are many people in this community who would want to cheat in that way. The cookies etc do have a cost associated with them after all, and I think this is generally understood. But the experiment will hopefully tell us this as well. So, we're aiming to find out if this is indeed a good idea. There are some local reasons to try this in Japan where bosses typically don't allow their staff to stay away from the office for more than a day for events like this (unless they are fully onboard with what the IETF is or does). You might consider such one-day visitors as IETF tourists, but it might very well help us gain new attendees in the long run. Again, the experiment could tell us that too. Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: o...@cisco.com URL: http://www.cisco.com/ipj On Wed, 19 Aug 2009, Ross Finlayson wrote: I'm not convinced that this new One Day Guest Pass is even a good idea at all. Do we no longer want to encourage participants to be familiar with activities beyond their primary working group? Do we not want to encourage participants to attend the plenaries (to help familiarize them with the IETF process), in addition to their primary working group meeting? If the Secretariat feels that attendance is suffering because of the price of the full meeting registration fee, then perhaps a better solution is to drop the price of that fee. Ross. ___ 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
One Day Pass and the Socail
Hi, Some social events have attendance limits. Are day-pass holders allowed to attend the social? Do full-week registrants get preference for social tickets? dbh ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
One Day Pass for newcomers
If part of the purpose of the one-day pass is to let new attendees understand how the IETF works, why don't we make attendance in the newcomers' tutorial free - no paid attendance required, just registration (for planning purposes). I would rather have newcomers learn from the newcomers' training than from attending (and trying to participate in) sessions on a one day pass, with no newcomers' training. dbh ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
LC summary for draft-ietf-opsawg-operations-and-management
Hi, Here is a summary of Last Call comments: 1) Cullen Jennings told chairs to pay attention; [dbh: no action required.] 2) Henning Schulzrinne concerned about slowing approvals, and applying to new protocols and extensions. [dbh: added text about the different needs for new protocols and extensions] 3) Bernard Aboba concerned that IETF should focus on making successful protocols, and Management Considerations may be an unnecessary requirement. [dbh: this document went to great lengths to say that it was NOT prescribing a Management Considerations requirement. sigh] Management support is seldom a show-stopper. Wants differentiation of need with new protocol versus existing protocols. [dbh: added text about the different needs for new protocols and extensions] 4) IANA - no problem [dbh: no action required.] 5) Miguel Garcia - GEN-ART + editorial [dbh: all comments fixed] 6) Sam Hartman - objects to BCP * It does not reflect practices across significant areas of the IETF interoperable mgmt not required for all protocols document focuses on networking devices; document should be scoped. [dbh: removed primary goal] [dbh: I added some text to Designing for OPS and Management in the Introduction that talks about the traditional approach of using MIB modules for networking devices, and that emerging technologies have caused a change to IETF technologies and atrategy, and management requirements.] * It does not provide clear, actionable guidelines normative requirements vs might want to consider [dbh: added text about when appropriate, a data model might be used.] * It is not sufficiently clear to be understood outside the OM area. fails to make distinctions (ops vs mgmt; config vs other mgmt) document organization and discussions jumbled. [dbh: removed the use of operations model. It is unclear what the model part refers to. Changed text to discuss operations, and deployment, etc.] [dbh: I moved the counter discussion, which was probably the most jarring context change. I modified a few other places, but some specific suggestions for changes might be helpful. YMMV] [dbh: I removed discussions of data and control planes, and tried to make the discussion general enough to also include services.] 7) Eliot Lear - Informational, not BCP section 3.2 needs more applicability discussion [dbh: I added some text to Designing for OPS and Management in the Introduction that talks about the traditional approach of using MIB modules for networking devices, and that emerging technologies have caused a change to IETF technologies and atrategy, and management requirements.] [dbh: changed primary gola from interoperability to the primary goal is the ability to roll out new useful functions and services in a way in which they can be managed in a scalable manner, where one has understood the network impact (as part of total cost of operations) for that service.] 8) SM - does not scale well for BCP [dbh: no action required.] 9) Sam (in discussion with Dan) - this document does not indicate that a WG can decide no management is fine. [dbh: section 4.2 is very clear on that point] 10) Eliot Lear - need applicability scope needs to be be smaller document [dbh: not something I think we can accomplish without a rewrite and consensus on whether to keep each detail. WG consensus was to not do a rewrite at this time.] 11) Eric Rosen - opposes BCP status [dbh: no action required.] 12) Randy Presuhn - Thinks document is important; prefers Informational to BCP. [dbh: no action required.] 13) Joel Halpern - discussion on OPS guidelines versus requirement [dbh: no action required.] 14) Andy Bierman - discussion of OPS guidelines versus requirement [dbh: no action required.] 15) Tom Petch - Thinks abstract should be changed. I do not understand his point well enough to take action, and, as he points out, the document says it is not trying to solve the problem he raises. [dbh: no action taken.] draft-ietf-opsawg-operations-and-management-08 has been posted. David Harrington dbharring...@comcast.net ietf...@comcast.net dharring...@huawei.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: opsdir review of draft-green-secsh-ecc-08
Hi Douglas, For the most part, I really like the new security considerations section in 09. I found it far more enlightening (and even interesting). Thanks. I usually look for security considerations in a form that points out the threats and how they are mitigated (or can be mitigated by configuration decisions). I do not insist on this form; but I think it makes it easier for people to understand. For the most part, your new section does this well. You may be more detailed than is necessary in the security considerations. I am not quite sure who the target audience is for this draft - SSH operators/users or crypto developers implementing support for this cipher suite. probably both. Your discussion is probably way more detailed than needed for most operators and users and programmers, but possibly right for crypto implementers. Paragraph 3 in the security considerations discusses prime, and characteristic 2, and composite. I don't know what these mean, except the prime (which I assume is the mathematical prime). I can live with not understanding these terms, but I am not sure of the implications of the last sentence. All of the RECOMMENDED curves of characteristic 2 in section 10 have prime m. As I read this paragraph, am I correct in believing that the next to last sentence states the threat (susceptible to attack by the Weil descent), and the last sentence says the prime m mitigates that attack? If so, it would help to append to the last sentence , which helps to protect against such attack. or something similar. For operators deploying this in today's networks, I am pretty sure the discussion of quantum computers is not really relevant, but it is interesting ;-) No complaint; just an observation. In paragraph 6, I think the As such, is unnecessary (and I found it slightly distracting that it was there, because unnecessary introductory phrases are a pet peeve for me). I found paragraph 10 hard to understand. strong security at the security levels indicated seems a bit convoluted. Is there a better way to express what you mean? When you say in this section, are you referring to the security considerations section? -- Manageability We are actively working to decide what should be said in documents about manageability. Adrian's draft was a good place to start. The opsawg has a draft on operations and management (by me) that might have some additional guidelines that hopefully would be helpful. For the most part, I am happy with the new management considerations, and think they are sufficient to satisfy my review comments. I have some additional questions that you might consider discussing, and a few minor edits. section 8 looks good. In section 8.1, I think this would be better expressed as Implementers should allow administrators to disable some curves, including some REQUIRED or RECOMMENDED curves, to meet local security policy. The initial setup and installation presumably will be done using normal SSH config methods. Are there any ECC-specific parameters that must be configured? Are there specific parameters that should not be disclosed in a config file? Are there defaults that would be useful to help ensure interoperability (or have you already discussed all the necessary defaults when you discuss specific ciphers? For administartively-configurable parameters, are there any that must be preserved across reboots? others that do not? section 8.2 looks good. Is ECC computationally expensive? Could that impact SSH performance, for example? Are there any fault or threshold conditions for ECC processing? If they occur, is this something the operator should be informed of, e.g. via syslog, or are all ECC fault and threshold conditions already dealt with within the SSH fault and threshold handling mechanisms? ECC is susceptible to certain types of attacks. Can an implementation detect such attacks (without significant computational impact)? Are there anomalous patterns that can be discerned? If so, would it be useful to have a counter in the system's management interface to count specific anomalies, so an operator or an IDS could monitor the counter(s) and raise an alarm if the system might be under attack? Good job, Thanks. -Original Message- From: Douglas Stebila [mailto:doug...@stebila.ca] Sent: Thursday, June 11, 2009 7:57 AM To: ietf...@comcast.net Subject: Re: opsdir review of draft-green-secsh-ecc-08 Hi David, Thanks for the extensive review. I am attaching a proposed revision of the draft to address your concerns about the manageability considerations and security considerations sections. The security considerations section has been substantially rewritten to, I hope, provide a more self-contained analysis of the security issues at play when using elliptic curve cryptography. I was unable to find many examples of manageability considerations sections (I worked off of draft-ietf-pce-manageability-requirements-06) and do not really know
FW: [secdir] secdir review of draft-dusseault-impl-reports-02
Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document describes updates to existing processes for implementation and interoperability reports, and provides recommendations about the level of detail required. The document is about IETF standards process, is well written, and introduces no new security concerns. David Harrington dbharring...@comcast.net ietf...@comcast.net dharring...@huawei.com ___ secdir mailing list sec...@ietf.org https://www.ietf.org/mailman/listinfo/secdir ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your review andcomments on a proposed Work-Around to the Pre-5378 Problem
From my perspective, the best approach involves keeping the general case simple. I concur. I think we should continue to use the RFC3978 rules as the default, and to allow WGs to choose to assign, or not, the new rights on new documents. I was author of 4663, and I coordinated the whole effort to transfer the rights to the Bridge MIB documents from IETF to IEEE. I can state that getting permission from the authors and their companies was not onerous, but I would not want to do that for documents that were not being transferred. I will observe that the requirement we met for RFC4663 was to get permission from the authors of the current drafts, and the authors of the previous revisions, and their companies. We did not try to determine the complete list of people who contributed to the works as WG members. I think THAT task would have been so onerous that I would have argued against doing the transfer, and told IEEE persons to just come work in the IETF instead. In actuality, for RFC4663, the IEEE lawyers got the permissions. I just helped by identifying the authors and their companies. I suggest the right way to handle this in the future is to let the copying organization go get the permissions and assume any related risk. To make that easier, I would not have a problem with a WG deciding to include the right to copy. But then the question becomes is rough consensus adequate? or must it be unamimous? If it has to be unanimous, then we apparently would need a membership and voting system, so we know who has a say, and whether they have voted or not. I have been an editor of IETF documents for years, and have never tried to document where every contribution came from, or tried to track the legal permissions granted by each contributor for their text. If I am expected to assume legal risk for asserting that all rights have been granted for text in documents being transferred or being copied into other documents, for all contributors to a WG document, then I would gladly give up editing. I really do not like the changes this new boilerplate forces onto the IETF process. I would rather continue to use RFC2026/3978 rules. David Harrington dbharring...@comcast.net ietf...@comcast.net dharring...@huawei.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Proposed Experiment: More Meeting Time on Friday for IETF 73
Hi, I support this experiment. Why short sessions? Why not longer sessions? In my experience, Friday sessions are invaluable for having working sessions rather than status sessions, and Friday sessions have been preferred in some WGs as a way to get real f2f time for engineering. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of IETF Chair Sent: Thursday, July 17, 2008 5:33 PM To: IETF Announcement list Cc: ietf@ietf.org; [EMAIL PROTECTED] Subject: Proposed Experiment: More Meeting Time on Friday for IETF 73 The IESG is considering an experiment for IETF 73 in Minneapolis, and we would like community comments before we proceed. Face-to-face meeting time is very precious, especially with about 120 IETF WGs competing for meeting slots. Several WGs are not able to get as much meeting time as they need to progress their work. As an experiment, we are considering adding two Friday afternoon one-hour meeting slots. The proposed Friday schedule would be: 0900-1130 Morning Session I 1130-1300 Break 1300-1400 Afternoon Session I 1415-1515 Afternoon Session II Please share your thoughts about this proposed experiment. The proposed experiment will be discussed on the IETF Didcussion mail list (ietf@ietf.org). ___ 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: ISSN for RFC Series under Consideration
Hi, The Trust has analyzed the advantages, and you included the advantages in your post. Has the Trust also analyzed any potential disadvantages? Can you tell us those as well? David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ray Pelletier Sent: Wednesday, May 21, 2008 1:52 PM To: IETF Discussion; IAOC; The IESG; RFC Editor; IAB; Working Group Chairs Subject: ISSN for RFC Series under Consideration The IETF Trust is considering applying to the U.S. Library of Congress to obtain an International Standard Serial Number (ISSN) for the RFC Series and would like community input to inform its decision. The Trust may take up this matter on June 11th. An ISSN is applied to serials - print or non-print publications issued in parts. A serial is expected to continue indefinitely. Serials include magazines, newspapers, annuals, journals, proceedings, transactions of societies, and monographic series. Other SDOs, such as the IEEE, have obtained ISSNs for their publications. A single ISSN uniquely identifies a title regardless of language or country in which published, without the burden of a complex bibliographic description. The ISSN itself has no significance other than the unique identification of a serial. The Trust believes there are advantages to indentifying the RFC Series with an ISSN. Among them, 1. Make reference to the series compact and globally unique; 2. Make the series, and individual RFCs, easier to reference in some contexts; 3. Results in accurate citing of serials by scholars, researchers, abstracters, and librarians; 4. ISSN registrations are maintained in an international data base and are made available in the ISSN Register online According to the Library of Congress, www.loc.gov/issn/, for serials available only in online versions, the ISSN should appear on the title screen or home page and/or in the masthead or other areas where information about publisher, frequency, subscribing, copyright, etc. is given. There is no cost associated with obtaining ISSNs. Ray Pelletier IAD Trustee ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: WG Review: NETCONF Data Modeling Language (netmod)
official minutes for that discussion. I personally arrived about 45 minutes late to the meeting. There were representatives from most of the constituencies that had prepared concrete proposals. They had already agreed to a strawman approach starting with YANG as a human-friendly DML with a mapping to one of the XML schema langauges for machine-readability. (This was consistent with the mood of the OPS Area open meeting the day before.) It was decided to have the rcdml design team, plus the new Netconf chairs, develop a proposed charter. The discussions of the charter proposal were held on the rcdml mailing list, whose archives can be found at http://www.partain.se/mailman/listinfo/rcdml. This mailing list had respresentatives from each of the constituencies that prepared proposals for the beauty contest. The design team posted the proposed charter to the NGO mailing list for review http://www.ietf.org/mail-archive/web/ngo/current/msg00745.html. The design team proposal is of course no better than any other proposal, so it was posted to NGO for further community discussion. Apr08: The IESG secretary announced a WG review for Netconf Data Modeling Language to the IETF mailing list. I hope this is helpful. Let me kniw if I can help further. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Rescorla Sent: Tuesday, April 22, 2008 5:18 PM To: Bert Wijnen - IETF Cc: [EMAIL PROTECTED]; ietf@ietf.org Subject: Re: WG Review: NETCONF Data Modeling Language (netmod) At Tue, 22 Apr 2008 23:10:53 +0200, Bert Wijnen - IETF wrote: W.r.t. All this is great stuff, but it all happened after the BOF, so you can't reasonably claim that it represents BOF consensus. And since BOFs are our primary mechanism for open, cross area assessment for WG formation, I don't think it's accurate to suggest that this is anywhere as near as open as actually having the discussion in the BOF and gettting consensus, nor is it a substitute for that. I do not think that forming a WG MANDATES a BOF. Several WGs have been formed (in the past) without a BOF. So pls do not depict a story as if a BOF is the only way how we reach consensus in IETF on teh question of forming a WG or not. Yes, but when you have a BOF which doesn't come to consensus on a technical direction, which is then shortly followed by a proposed charter which *does* specify a technical direction, I think that's a somewhat different story. -Ekr ___ 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: WG Review: NETCONF Data Modeling Language (netmod)
together at the OPS Open area meeting and at the OPS/IESG breakout meetings to discuss a way forward, and the various constituencies reached agreement that YANG provoded a reasonable human-friendly language, and a translation to either XSD or RNG would meet the needs for a machine-friendly language suitable for XML-based tools. Consensus of these constituencies was that RNG + Schematron (i.e., DSDL) provided better capabilities for validation of the network management specific requirements than XSD alone or RNG alone. The consensus of the these constituencies was also that YANG was more human-friendly then either XSD or RNG or DSDL. So constituencies of the broader community have been very active in establishing the proposed direction, in crafting the proposed charter, and have committed to working on the documents identified in the proposed charter. Since the topic is not new, where have they been and why have they not developed their own group consensus? This topic is not new, and constituencies of the broader community have been active in establishing the proposed direction, and the proposed charter, and have committed to working on the documents identified in the proposed charter. Rather than perspectives where are the technical concerns that Bert asked about? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: WG Review: NETCONF Data Modeling Language (netmod)
with different goals, like building SMI atop ASN.1, when the standards are likely to grow in different directions than what we need for IETF NM data model standardization purposes. Unfortunately, you did not attend the many sessions over the past few years as the NM community did comparisons of the suitability of SMIv2, SPPI, SMING, XSD, RNG, YANG and others for purposes of configurastion data modeling. But the community that has attended such discussions of the suitability of different languages for the task at hand has reached rough consensus and developed multiple implementations of running code for this proposed direction forward. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Proposed IESG Statement Regarding RFC Errata for IETF Sream RFCs
Hi, I read this document. On a quick read, this seemed very reasonable. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of The IESG Sent: Wednesday, April 16, 2008 8:17 AM To: IETF Announcement list Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Proposed IESG Statement Regarding RFC Errata for IETF Sream RFCs The IESG is considering the following statement to guide the handling of RFC Errata for IETF Stream RFCs. Your review and comment on this policy is encouraged. Russ Housley on Behalf of the IESG - - - - - - - - - - - - Proposed IESG Statement Regarding RFC Errata for IETF Sream RFCs These are strong guidelines and not immutable rules. Common sense and good judgment should be used by the IESG to decide what is the right thing to do. Errata are meant to fix bugs in the specification and should not be used to change what the community meant when it approved the RFC. These guidelines only apply to errata on RFCs in the IETF stream. They apply to new errata and not errata that had already been approved. After an erratum is reported, a report will be sent to the authors and Area Directors (ADs) of the WG in which it originated. If the WG has closed or the document was not associated with a WG, then the report will be sent to the ADs for the Area most closely associated to the subject matter. The ADs for the area will review it, either themselves or by delegating, and classify it as falling under one of the following states: o Approved - The errata is appropriate under the criteria below and should be available to implementors or people deploying the RFC. o Rejected - The errata is in error, or proposes a change to the RFC that is clearly inappropriate to do with an errata. In the latter case, if the change is to be considered for future updates of the document, it should be proposed using other channels than errata, such as a WG mailing list. o Archived - The errata is not a necessary update to the RFC. However, any future update of the document should consider this errata, and determine whether it is correct and merits including in the update. Guidelines for review are: 1. Only errors that could cause implementation or deployment problems or significant confusion should be Approved. 2. Things that are clearly wrong but could not cause an implementation or deployment problem should be Archived. 3. Errata on obsolete RFCs should treated the same as errata on non-obsolete RFC where there is strong evidence that some people are still making use of the related technology. 4. Trivial grammar corrections should be Archived. 5. Ugly typos that are clearly bogus typos but would not cause any confusions to implementation or deployments should be Archived. 6. Changes which are simply stylistic issues or simply make things read better should be Archived. 7. Changes that modified the working of a protocol to something that might be different from the intended consensus when the document was approved should be either Archived or Rejected. Deciding between these two depends on judgment. Changes that are clearly modifications to the intended consensus, or are of major importance, should be Rejected. In unclear situations, small changes can be Archived. 8. Changes that modify the working of a process, such as changing an IANA registration procedure, to something that might be different from the intended consensus when the document was approved should be Archived. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RE: Proposed IESG Statement Regarding RFC Errata for IETF Sream RFCs
Hi, I read this document. On a quick read, this seemed very reasonable. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of The IESG Sent: Wednesday, April 16, 2008 8:17 AM To: IETF Announcement list Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Proposed IESG Statement Regarding RFC Errata for IETF Sream RFCs The IESG is considering the following statement to guide the handling of RFC Errata for IETF Stream RFCs. Your review and comment on this policy is encouraged. Russ Housley on Behalf of the IESG - - - - - - - - - - - - Proposed IESG Statement Regarding RFC Errata for IETF Sream RFCs These are strong guidelines and not immutable rules. Common sense and good judgment should be used by the IESG to decide what is the right thing to do. Errata are meant to fix bugs in the specification and should not be used to change what the community meant when it approved the RFC. These guidelines only apply to errata on RFCs in the IETF stream. They apply to new errata and not errata that had already been approved. After an erratum is reported, a report will be sent to the authors and Area Directors (ADs) of the WG in which it originated. If the WG has closed or the document was not associated with a WG, then the report will be sent to the ADs for the Area most closely associated to the subject matter. The ADs for the area will review it, either themselves or by delegating, and classify it as falling under one of the following states: o Approved - The errata is appropriate under the criteria below and should be available to implementors or people deploying the RFC. o Rejected - The errata is in error, or proposes a change to the RFC that is clearly inappropriate to do with an errata. In the latter case, if the change is to be considered for future updates of the document, it should be proposed using other channels than errata, such as a WG mailing list. o Archived - The errata is not a necessary update to the RFC. However, any future update of the document should consider this errata, and determine whether it is correct and merits including in the update. Guidelines for review are: 1. Only errors that could cause implementation or deployment problems or significant confusion should be Approved. 2. Things that are clearly wrong but could not cause an implementation or deployment problem should be Archived. 3. Errata on obsolete RFCs should treated the same as errata on non-obsolete RFC where there is strong evidence that some people are still making use of the related technology. 4. Trivial grammar corrections should be Archived. 5. Ugly typos that are clearly bogus typos but would not cause any confusions to implementation or deployments should be Archived. 6. Changes which are simply stylistic issues or simply make things read better should be Archived. 7. Changes that modified the working of a protocol to something that might be different from the intended consensus when the document was approved should be either Archived or Rejected. Deciding between these two depends on judgment. Changes that are clearly modifications to the intended consensus, or are of major importance, should be Rejected. In unclear situations, small changes can be Archived. 8. Changes that modify the working of a process, such as changing an IANA registration procedure, to something that might be different from the intended consensus when the document was approved should be Archived. ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/ietf-announce ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
secdir review of draft-snell-atompub-bidi-06, part II
Hi, I did a secdir review of this document to alert the SEC ADs to any new security considerations. Something I did not add to my review was a non-security concern. Why was the secdir asked to review this non-WG document? Or, more accurately, why is this topic not being handled as a WG item? I think this is something the SEC ADs should be considering as well. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
secdir review of draft-snell-atompub-bidi-06
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. draft-snell-atompub-bidi-06 is a very short document and adds an experimental attribute to the atom syndication format to indicate whether text should be presented left-to-right or right-to-left. This experimental approach would replace the current direction guessing heuristic approach. I see nothing that leads me to believe there is any additional security consideration that is not already discussed in the security considerations of RFC4287 The Atom Syndication Protocol. RFC4287 considers the HTML/XHTML content, URIs, IRIs, Spoofing, and encryption and digital signatures. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Samuel Weiler Sent: Friday, April 11, 2008 6:49 PM To: [EMAIL PROTECTED] Subject: [secdir] Assignments for April 18th Two new reviewers enter the rotation this week: Richard Barnes and Sam Hartman. We've moved the review instructions and related resources (e.g. the list of reviewers) to a wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview The mailing list may be moving from mit.edu to the IETF's servers within the next week. Stay tuned. Paul Hoffman is next in the rotation. -- Sam For telechat 2008-04-24 Lakshminath DondetiT draft-ietf-mipshop-4140bis-02 Susan Thomson T draft-funk-eap-ttls-v0-04 Last calls and special requests: Rob Austein draft-klensin-rfc2821bis-09 Rob Austein draft-ietf-rmt-bb-norm-revised-04 Richard Barnesdraft-ietf-lemonade-msgevent-05 Uri Blumenthaldraft-ietf-smime-sha2-04 Pat Cain draft-ietf-rserpool-threats-09 Ran Canetti draft-ietf-rserpool-asap-19 Ran Canetti draft-ietf-rserpool-common-param-16 Ran Canetti draft-ietf-rserpool-enrp-19 Ran Canetti draft-ietf-rserpool-policies-08 Lakshminath Dondeti draft-irtf-nmrg-snmp-measure-04 Donald Eastlake draft-ietf-mpls-ldp-capabilities-02 Shawn Emery draft-ietf-mpls-ldp-interarea-03 Stephen Farrell draft-ietf-mpls-upstream-label-04 Tobias Gondrom draft-ietf-mpls-multicast-encaps-07 Phillip Hallam-Baker draft-ietf-krb-wg-anon-05 Phillip Hallam-Baker draft-ietf-mpls-number-0-bw-te-lsps-09 Steve Hanna draft-ietf-tsvwg-rsvp-user-error-spec-06 David Harrington draft-snell-atompub-bidi-06 Sam Hartman draft-resnick-2822upd-06 Tero Kivinen draft-ietf-softwire-mesh-framework-04 Tero Kivinen draft-ietf-softwire-encaps-safi-00 Tero Kivinen draft-ietf-softwire-encaps-ipsec-00 Tero Kivinen draft-ietf-softwire-v4nlri-v6nh-00 Julien Laganier draft-ietf-softwire-mesh-framework-04 Julien Laganier draft-ietf-softwire-encaps-safi-00 Julien Laganier draft-ietf-softwire-encaps-ipsec-00 Julien Laganier draft-ietf-softwire-v4nlri-v6nh-00 Catherine Meadows draft-ietf-speechsc-mrcpv2-15 Sandy Murphy draft-vanelburg-sipping-served-user-04 Sandy Murphy draft-ietf-l1vpn-bgp-auto-discovery-04 Vidya Narayanan draft-ietf-nfsv4-nfsdirect-07 Vidya Narayanan draft-ietf-enum-experiences-09 Vidya Narayanan draft-ietf-l1vpn-ospf-auto-discovery-05 Blake Ramsdelldraft-ietf-ospf-rfc2370bis-02 Stefan Santesson draft-iijima-netconf-soap-implementation-06 Stefan Santesson draft-ietf-pim-lasthop-threats-03 Juergen Schoenwaelder draft-freed-sieve-environment-05 Susan Thomson draft-carpenter-rfc2026-changes-02 Sam Weilerdraft-ietf-pim-bsr-mib-04 Nico Williams draft-ietf-l1vpn-basic-mode-04 Kurt Zeilenga draft-daboo-imap-annotatemore-12 Larry Zhu draft-hautakorpi-sipping-uri-list-handling-refused-03 Glen Zorn draft-ietf-iptel-tel-reg-05 ___ secdir mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/secdir ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Online blue sheets, was: Re: Scheduling unpleasantness
Hi, I think asking attendees during registration which sessions they intend to attend and building a conflict matrix would be the simplest approach. Of course, attendee conflicts matter less than ADs, chairs, and presenter conflicts. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Iljitsch van Beijnum Sent: Tuesday, March 25, 2008 9:22 AM To: Harald Tveit Alvestrand Cc: IETF Discussion Subject: Online blue sheets, was: Re: Scheduling unpleasantness On 25 mrt 2008, at 4:58, Harald Tveit Alvestrand wrote: The WG scheduling tool has 3 lists of groups to avoid conflicts with, 1st, 2nd and 3rd priority. I don't know if these are visible to anyone but the requesting WG Chair, but they're listed on the confirmation notice from the tool; I've made it a practice to copy them to the WG I schedule, and modify the list according to comments. So I'd ask: Were the meetings you had problems with listed in each others' conflicts list? - If not, it's a problem at the data input level. - If yes, it's a problem at the conflicts resolutions level. I don't know, I haven't seen these lists. Apparently the scheduling situation wasn't (much) worse for most others. In my case, I had huge overlap on monday and tuesday and then pretty much nothing of interest happened on wednesday and thursday. Although it's useful to have wg chair input on scheduling issues, I don't think that's sufficient. What we need is to see which wgs have overlapping constituencies. We actually do have this data already, in the form of the blue sheets. But obviously it's not usable in its current, analog form. So I'm offering to build an online version of the blue sheets so in the future, it will be easy to determine which wgs attract the same people and overlap can be avoided more effectively. ___ 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 72 -- Dublin!
I think the complaints would simply be slurred more, and we might have to worry about lynch mobs (which would remind me of the reasonableness of this discussion so far). dbh -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Crocker Sent: Thursday, February 07, 2008 1:25 AM To: David Kessens Cc: 'IAOC'; IAB; 'IETF Discussion'; Richard Shockey Subject: Re: IETF 72 -- Dublin! David Kessens wrote: PS anyways, maybe the local/Dublin restaurant scene is really not what we should be looking for in Ireland: should we not care more about the local brews ? Open taps in each meeting room might, indeed, eliminate any complaints about the venue. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
RE: Experimental makes sense for tls-authz
-Original Message- From: Joel M. Halpern [mailto:[EMAIL PROTECTED] Sent: Friday, October 26, 2007 12:16 PM To: ietf@ietf.org Subject: Experimental makes sense for tls-authz Given the current email activity on this issue, I want to echo Randy's support. We have published encumbered experimental and informational documents on many occasions. I can see no reason not to do so in this case. Given that it appears that experimental publication is sufficient for the registration needs that go with this document, I strongly support publication. Yours, Joel M. Halpern +1 David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: A priori IPR choices [Re: Third LastCall:draft-housley-tls-authz-extns]
-Original Message- From: Lawrence Rosen [mailto:[EMAIL PROTECTED] Sent: Sunday, October 21, 2007 10:16 AM To: ietf@ietf.org Subject: RE: A priori IPR choices [Re: Third LastCall:draft-housley-tls-authz-extns] [...] Everyone expects IETF to take reasonable steps, consistent with its fundamental technical mission, to de-mine the patent landscape so that anyone can implement our worldwide specifications in products of all types. I don't presume to speak for everyone. I expect the IETF to take reasonable steps to de-mine the patent landscape related to our own policies, so that anyone can implement our worldwide specifications in products of all types. I expect those reasonable steps to include IPR disclosure by participants in the process, and where IPR has been disclosed, the IETF should discuss the tradeoffs and make a decision about whether IPR-encumbrance is acceptable. I do NOT expect those reasonable steps to include declaring that all companies contributing to a standard must give away associated IPR for free, to suit the open source community. I think it is an unreasonable demand from the open source community, and it is the licensing terms of open source implementations that place limitations on implementing our worldwide specifications in products of all types. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
secid review of draft-ietf-ipv6-deprecate-rh0-01
Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. - The purpose of draft-ietf-ipv6-deprecate-rh0-01 is to deprecate a feature of IPv6 which has been shown to have undesirable security implications. In particular, RH0 provides a mechanism for traffic amplification, which might be used as a denial-of-service attack. As such, the whole document is a security consideration. The vulnerability appears well-documented, and the guidelines for handling the deprecated RH0 are clear. I have a few comments 1) RH0 really is something we do not want to see used, right? Should this RH be obsoleted rather than deprecated? 2) Per BCP61, MUST is for implementers, and SHOULD is for users/deployers. There is a MUST NOT in section 4.2 that is a deployment decision, so this should be a SHOULD NOT. At the same time, there is a must in section 4.2 that is an implementation requirement, so this should be a MUST. 3) Section three uses must where MUST would seem appropriate. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
draft-shirey-secgloss-v2-08.txt
Hi, The issue was raised during ISMS WGLC that there is a difference between our use of the word authenticate and the glossary in RFC2828. Since ISMS extends SNMPv3, ISMS is using terminology consistent with the SNMPv3 standard, which reflects English usage. I think re-defining the word authenticate is not a good idea. I think it will not help the IETF write clear and unambiguous specifications to redefine words for IETF usage that are already clearly defined in English. if we want new keywords, then the IETF should invent new terms, not redefine existing terms. I encourage the security community to provide an informational glossary. I recommend that if a document author wants to use terminology consistent with RFC2828bis, they should state that, and list the specific RFC28282bis-consistent terms used in their document in a Terminology section. But I do not think the glossary terms should be required usage in the IETF, and if a document does use the RFC2828(bis) definitions, then I think it would be a bad idea to simply claim consistency with RFC2828bis. It will be tremendously hard to verify that every word or phrase covered in RFC2828(bis) is used correctly in the document claiming consistency with RFC2828(bis). It is already hard to verify that MUST/SHOULD/MAY are used correctly per RFC2119, and RFC2828bis has 300 pages of definitions, re-definitions, and phrases. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Working Group Last Call: syslog-sign-22
Hi, This message officially starts the Syslog Working Group Last Call for the following document: Signed syslog Messages (draft-ietf-syslog-sign-22.txt) http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-22.txt The Working Group Last Call for these documents will end August 9. This is a four-week WGLC designed to accommodate those who are busy dealing with commitments surrounding IETF69. To help get these document reviewed throughly, we are seeking volunteers to review the documents for the following special reviews: 1) Spelling and grammar, 2) boilerplates and reference review, 3) security review The chairs want to see a minimum number of content reviews before we submit the documents to the IESG. If you review the document and it looks fine, please post a statement that you have reviewed and found the document acceptable. Obviously, it if does not look acceptable please identify your objections, preferably with suggested text that would make it acceptable. Thanks, David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] co-chair, Syslog WG ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Warning - risk of duty free stuff being confiscated on the wayto Prague
Maybe they should sell the liquor in small transparent baggies. dbh -Original Message- From: Mark Andrews [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 14, 2007 7:40 PM To: [EMAIL PROTECTED] Cc: IETF discussion list Subject: Re: Warning - risk of duty free stuff being confiscated on the wayto Prague Eric Burger wrote: Guys - This is true (or, supposed to be true) in ALL countries. You go between two sterile environments, and ALL the rules get reset. This isn't a Europe thing, a U.S. thing, or a foobar thing. It's the way airport security works. Sure. But while folk like us probably ought to think of the issuebefore we buy something in Duty Free -- because, after all, we *always* forsee the full range of interaction effects, when making changes to complex systems -- it's not reasonable to expect average travellers to. No warnings. Nothing. At least the last time I bought duty free alcohol, Febuary, the staff warned me before I completed the transaction that I would not get it through security. I luckily have the option of purchasing it when I leaving and picking it up just before immigration and customs. The pre-departure price is also less than the pre-arrival price. Mark They get inside a security perimeter and think they are safe to buy the liquids they could not take through the perimeter. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ 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: Prague
Hi, I travelled to Prague after the Vienna IETF in 2003. It's a city; you need to take city precautions. There are signs of poverty, mostly outside the city center. I was surprised when I arrived (by train) by people aggressively trying to rent me a room in their house, and by taxi drivers who grab your bag and try to lead you to their taxi. Things might have changed by now, or not. I accepted a room in a private home from a person at the airport, 45 minutes by train outside of Prague, where people are striving to make enough to join the middle class. My landlord was a doctor, who found it more profitable to rent rooms in his house than practice medicine. Most IETFers will be better off financially, and will show it, so we become obvious targets. In three weeks of travelling through the Czech Republic and Slovakia, with no reservations and usually renting a room (a zimmer) in private houses, I met many wonderful people and never had a problem. I travelled alone at night usually. I was probably lucky, since I did not take many precautions that are simply common sense. Prague is a wonderful tourist spot with good food, good bier, quality shopping, lots of culture, and many interesting things to see. I rate it as one of my favorite cities in Europe. So I agree that Prague is very survivable. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -Original Message- From: Dave Crocker [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 07, 2007 12:03 PM To: IETF Discussion Subject: Re: Prague Edward Lewis wrote: I will attest to Prague being survivable. I have been there once already and suffered no ill effects and was not robbed. I.e., don't panic. ... At 14:52 -0500 3/6/07...: ... Under the entry for taxis from the airport they say Warning: Prague's taxi drivers ... When the IETF started having the meetings outside the U.S., there seemed to be two basic reasons. One was to adjust the burden of attendee travel, with a slight shift towards more fairness for attendees from outside the U.S. The other was to have our presence in the locale serve to encourage improvements to the local infrastructure. The former is obviously still valid. By and large, the latter hasn't been for a number of years. So it really is not reasonable for us to go to places that have poor Internet services, except that I'm one of those folk who think that having to go through a meeting venue learning curve for installing and debugging the net makes our meeting more fragile than it should be. But even that issue has gotten far less risky around the world, even for first-time IETF presence. But it occurs to me that there is an additional benefit that has been lurking, and I think it just surfaced: We kind folk from the U.S. tend to have very little understanding of what is normal elsewhere in the world. Even those of us with real travel experience often are so sheltered in those trips, or narrow in our venues, we have no serious basis for appreciating what to worry about, and what to merely be cautious about. A month before the Paris IETF, I was in Paris, at the same convention center, and had my wallet stolen as I was leaving the Metro. First such experience. Very traumatizing. But I'm hard-pressed to view Paris as more dangerous than any large U.S. city. And Amsterdam has public signs warning of pick-pockets. Should we avoid it, too? My Paris trauma came at the end of a fabulous day, and although during IETF week, I had a bit of a tremor when I had to use the same metro station, it was, still, the same, wonderful Paris of the travel books. Frankly, I have the same worries about Prague as John. I have read the same sorts of cautions that he has and must admit that seeing such cautions show up in a Frommer's is pretty unusual. So, I fully intend to be on guard. (And I am staying at a place that will require serious use of the transit system.) But, then, that's the lesson: Some places are seriously dangerous. We should stay away from them. Some merely warrant caution. And most places that American's worry about are no worse than most cities in the U.S. Just different. Yes, it can be a challenge to find credible ways to distinguish between the two, but it's clear that the otherwise review of published reports is not sufficient. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ 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: Last Call: draft-harrington-text-mib-doc-template (A Template
Hi, Yup. Trying to figure out how to publish this in an internet-draft has been challenging to say the least. (publishing the xml2rfc template in an xml2rfc document is even more challenging!) The template, in both text and xml2rfc format, has been available on the OPS website since July. Thanks for the suggestion of using an appendix; I'll consider that possibility. dbh -Original Message- From: Tom.Petch [mailto:[EMAIL PROTECTED] Sent: Friday, February 16, 2007 8:14 AM To: ietf Subject: Re: Last Call: draft-harrington-text-mib-doc-template (A Template I think that the idea behind this draft is a good one but that the choice of technology is wrong. The template should be on a web site available for download and that the way to get it there is the same as is used eg to get SMI TCs on to a website, namely publish it as an appendix to an RFC, so the body of the RFC is a proper RFC, formatted as usual, with the usual genuine comments to the RFC Editor, IANA etc and the appendix is then labelled 'do not touch' as far as RFC Editor, IANA etc are concerned and provides the material which will be loaded on to the website. The Appendix would benefit from a convention so show that the sections therein are at a second level, eg a marking or escape character before each section head, which is removed when the Appendix is placed on to the web site. The current approach of interleaving what will appear in the template, comments thereon and the normal RFC material is likely to confuse all who come after. Tom Petch ___ 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: ietf-moms
Is there any IPR that needs to be disclosed related to such a list? dbh -Original Message- From: Harald Tveit Alvestrand [mailto:[EMAIL PROTECTED] Sent: Friday, February 02, 2007 10:55 AM To: Steven M. Bellovin; Dave Cridland Cc: Dave Aronson; IETF-Discussion Subject: Re: ietf-moms --On 2. februar 2007 10:06 + Steven M. Bellovin [EMAIL PROTECTED] wrote: And think of the Security Considerations section. (And do we need IANA considerations, too?) For this subject, there is absolutely no way to avoid an internationalization considerations section - and of course the scalability considerations section needs to be *extensive*! Harald (seriously: Just Do It!) ___ 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: netwrk stuff
Why not start everything at Experimental, and if it gains market success then it moves to Full. dbh -Original Message- From: Nelson, David [mailto:[EMAIL PROTECTED] Sent: Friday, July 21, 2006 10:03 AM To: IETF Discussion Subject: RE: netwrk stuff Dave Crocker writes... The key point is having a status that is determined by market penetration, rather than technical details. Proposed is for the technical work. Full is for market success. That sounds reasonable. By way of providing some incentive, I suggest that Proposed have a limit, such as 3 or 5 years (and, yes, we can quibble about that, too.) If the work cannot gain sufficient adoption by the end of that time, it has failed and warrants moving to Historic. I think that may be too harsh, if there has been some adoption in the market but less than sufficient adoption (however we define that). Perhaps moving to Informational would be more appropriate, in those cases. Regards, Dave Nelson ___ 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
Minutes and jabber logs
Hi, I would not like to see raw jabber logs included as part of the minutes. The signal-to-noise ratio is way too low in many meetings. Jabber logs written by a scribe do not do a good job representing the body language and the nuances of speech that may be important to really understand what a person said. I would also be concerned that there are side-discussions in jabber that are not relayed to the whole room; including those side conversations as a reflection of what was said in the meeting is simply misleading. It is the chair's job to provide a summary of the meeting for the mailing list to see what was discussed and decided. I do not think the chair should be allowed to evade this responsibility by simply posting a quick summary and the raw jabber logs to the mailing list as the official minutes. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -Original Message- From: Spencer Dawkins [mailto:[EMAIL PROTECTED] Sent: Monday, July 17, 2006 11:18 AM To: ietf@ietf.org Subject: Re: Meetings in other regions That said, and given the difficulties of balancing competing priorities in site location, it seems reasonable to me to make a decent, good-faith effort without getting overly bogged down in where should we meet? discussions, and really try to get the remote participation thing nailed down a little better. The ratio of good to bad remote meeting input has improved a lot over the past year or so but there are still too many working groups without a Jabber scribe in the room (which prevents remote listeners from providing inputs), etc. OK, this is only a thought, and I'm out of the process improvement business anyway, but I've been seeing a consistent improvement in the quality of jabber logs for at least two years, and I'm wondering if there are working groups who would be willing to try minutes = chair summary plus jabber logs for a few IETFs (without what we usually think of as detailed minutes), and see if this is actually workable. I'm a many-time repeat offender as WG note-taker, and am watching my notes look more and more like a jabber log with only one jabberer; the advantages of jabber (in my experience) are - it's nice for the note-taker to be able to participate in the meeting - as an extreme case, in the SIPPING Ad Hoc on Friday, Gonzalo and Mary handed me the mike about twenty times, but very litte of what I said appeared in the notes, and it's worse when someone is already talking when I stop talking. That's typical in my experience. With Jabber, people can type until I get back to my seat. - It's really nice when I misquote, or mis-attribute, something that was said and another jabberer corrects it right away. This is SO much better than the WG chair having to listen to the audio stream to check my notes after some number of days has elapsed (and sometimes all the chair can tell from the audio is that I got it wrong, without knowing what right would have been). - and, obviously, this works better for remote participants (what's the alternative - send e-mail to the list?) Now that all this stuff is on the IETF website, it should be more enduring than if the jabber rooms and logs were hosted somewhere else. Of course, Jabber has to work; our wireless network has been pretty solid the last couple of meetings, but even so, if you offer a Jabber scribe an Ethernet connection and guaranteed power at the front of the room, that would be pretty compelling for me, most IETFs. Thanks, Spencer ___ 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: Comments on draft-carpenter-newtrk-questions-00.txt
Hi, I believe the rule was applied to the Entity MIB and the RMONMIB work, IIRC. dbh -Original Message- From: Henning Schulzrinne [mailto:[EMAIL PROTECTED] Sent: Thursday, July 13, 2006 9:02 AM To: Joel M. Halpern Cc: ietf@ietf.org Subject: Re: Comments on draft-carpenter-newtrk-questions-00.txt Has this been exercised in the past, say, 5 years? At least for widely-implemented protocols, such as SIP, there is no reasonable way to say there is only one implementation that does X, as there is no plausible way to catalog all such implementations. Most of the implementors don't show up at IETF meetings and implementations are written by dozens of small start-ups, open source systems and other non-traditional sources. This provision actually discourages any DS effort: the danger is that you can't find an implementation that does use a certain feature, you deprecate it and then find that there was some SDO or implementor somewhere that actually did find this extremely useful. That just makes everyone look silly. On Jul 13, 2006, at 7:29 AM, Joel M. Halpern wrote: there is one useful aspect of our DS contortions. When we do the work, we actually figure out which features turn out not to be used, and get them out of the spec. OSPF had ToS routing in its PS specification. It turned out that there was only one implementation. So when the protocol was ready to advance, that feature was removed. Knowing that the feature was not being used proved very helpful to us later. Yours, Joel At 02:45 AM 7/13/2006, Eliot Lear wrote: Fred Baker wrote: I would like to believe that a well documented interoperability test constitutes DS qualification; the current DS qualification sets the bar somewhat higher than that, and I note that few documents actually achieve that, even though we can daily see implementations interoperating in the field at PS. Some data to Fred's point: By RFC, not by STD (obviously): Status 1999200020012002200320042005 - PS 102 119 71 105 103 131 169 DRAFT 6 6 2 4 7 7 3 STD 3(*)2 0 8* 3 0 1 (*) 3 in 1999 were SMIv2 6 in 2002 were SNMP. These are rough based on 10 minutes of scripting I did back in March. I believe there are two reasons for the huge gap between PS and DRAFT: - it's difficult to get there (interop requirements, picking out uncommonly used features, etc) - nobody wants or needs to do the work (what GM in her right mind would want her experts working on something that neither generates new features nor fixes product bugs) If Iljitsch's proposal is that the IESG makes a call based perhaps on somebody's request with some modest effort to demonstrate that a spec is ready for the next step, I think that actually would be a fine two-step approach. Eliot ___ 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 ___ 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: Last Call: 'Proposed Experiment: Normative Format in AdditiontoASCII Text' to Experimental RFC (draft-ash-alt-formats)
Hi, I agree equations should be written in ASCII pseudocode so it is easier to convert it to code. Pretty pictures, provided for the mathematicians, can be done as non-normative additions to the spec. Diagrams can be done as non-normative additions to the spec, which may help people think through various aspects of the design, but the spec should contain a normative ascii representation of the logic, and/or pseudocode, so people can actually implement the spec. If it is too difficult for the authors to convert from the complex diagram to an ascii text or ascii art representation of the logic, then maybe this is not a good choice for a spec. Even though I have been inconvenienced by having to develop ascii art, and spell out difficlut logic in text, I am not convinced we actually **need** normative pictures or equations. To quote from draft-ash-alt-formats-02.txt, in many, many, previous discussions on the IETF meiling lists trying to justify the need for additional normative formats, quite thoughtful, extended, and detailed discussion on the IETF discussion list resulted in no change. Apparently, a large number of readers of and contributors to the IETF discussion list are also unconvinced such a change is needed. Experience with other SDOs' publication processes does not make me want to adopt them for the IETF - just the opposite. Having been a MIB Doctor for IEEE 802.1, I needed to deal with the fact I could not extract portions of the normative PDF files to include in my comments. The 802.1 WG produced ASCII versions of the MIB specifications so we IETFers could access them more easily, and the existing MIB processing tools could work with the specs more easily, but often the non-normative ascii version was not kept up-to-date with the PDF version by the authors. This made it difficult to do IETF-style reviews on a timely basis, to automate the syntax validation of the specification, or to use the normative PDF as input to tools that generated code from the MIB specification. The PDF definitely got in the way of providing industry reviews, generating valid specifications, and implementing the specs. But this last call is about a specific document proposing a specific experiment. I think a proposed experiment that fixes diagram issue and fixes equations issue really would need to prove there is a need for normative diagrams and equations to produce an IETF technology specification. That is, it would need to prove it is not possible to specify a particular technology using pseudocode, ascii text, and ascii diagrams. I think the only thing such an experiment would be likely to prove is that the proposed technology that requires complex graphics and equations to describe the involved logic is really not ready to be specified in an IETF specificiation. I think that proving complex diagrams and equations MIGHT be used with implementable specs, and may help understanding of the design, is not adequate; we already have the ability to include non-normative diagrams and equations to aid understanding. I don't think the proposed experiment as designed is useful. I do not see consensus on the IETF discussion list that the problems to be solved are actually problems to be solved. I do not feel the particular criteria chosen to determine experiment success are appropriate to IETF documents. Could PDF and other formats produce documents that are clearer, easier for authors to write, and easier to read? Sure. And if the difference is adequate, the authors should consider providing non-normative PDF to improve clarity, and ease of writing and reading. But that doesn't prove it should be normative. But the job of the IETF is not to publish pretty documents that are easy to write and read; it is to produce specifications of useful implementable standards for use in the Internet on a timely basis. I do not see those listed as particular criteria for measuring effectiveness. The criteria seem to miss the whole point of our working on standards. I do not believe it would be a worthwhile use of community resources to run this experiment as designed. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -Original Message- From: Iljitsch van Beijnum [mailto:[EMAIL PROTECTED] Sent: Sunday, June 25, 2006 4:16 PM To: Stephen Sprunk Cc: IETF-Discussion Discussion Subject: Re: Last Call: 'Proposed Experiment: Normative Format in AdditiontoASCII Text' to Experimental RFC (draft-ash-alt-formats) On 25-jun-2006, at 21:55, Stephen Sprunk wrote: IMHO, this would be a very good rule; the IETF is supposedly about running code, and complex equations that the average programmer cannot understand without digging up a college math book are unimplementable in the real world. Pseudocode is far, far more valuable than pretty equations. I agree one hundred percent. (Or 100%.) IMHO, a direct result of the above is that any math that cannot be described adequately
RE: [Fwd: Re: Last Call: 'Proposed Experiment: Normative Format in Additionto ASCII Text' to Experimental RFC (draft-ash-alt-formats)]
So, since most programming languages work in ascii, what you are saying is that this pretty diagram would be quite difficult to convert to a lot of words in ascii, which may or may not be correct. So why do we want to make such diagrams the normative specification rather than using something like pseudocode, which is much easier to convert to a programming language? And we should consider that if we need to convert from a non-normative pretty diagram to pseudocode or code, that would presumably be more easily done by the specification authors who have a profound understanding of the design, than for a reader not involved in working on the design. I fully agree that, for the reasons you give, using such pretty diagrams as normative would generally be a problem. David Harrington[EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] From: Stewart Bryant [mailto:[EMAIL PROTECTED] Sent: Sunday, June 25, 2006 4:42 PMTo: [EMAIL PROTECTED]; [EMAIL PROTECTED]; ietf@ietf.orgSubject: [Fwd: Re: Last Call: 'Proposed Experiment: Normative Format in Additionto ASCII Text' to Experimental RFC (draft-ash-alt-formats)] As an example, this .gif extracted from the Y.1711 OAM protocolwould be quite difficult in ASCII. It would take a lot of wordsto describe, which many people would then have to transcribe tosome sort of timing diagram - which then may or may not be correct.For those that cannot see the GIF it's figure 9This is a timing diagram which is a problem that few folks have so far mentioned.- Stewart !--[if !vml]--!--[if !vml]--!--[endif]-- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Acknowledgements section in a RFC (Was: Last Call: 'Matching of Language Tags' to BCP (draft-ietf-ltru-matching)
Hi, In transferring responsibility for the Bridge MIBs to IEEE 802, we learned that the IETF has certain copyrights to documents that have been submitted to the IETF for IETF purposes. All other rights remain with the authors, and the IEEE had to contact the authors to get permission to do non-IETF things with the documents. The IETF has no authority to transfer the authors' rights to other organizations/persons for non-IETF purposes. So it is not important for IETF purposes for the IETF to define requirements about listing authors and contributors to IETF documents. It may be important to the authors and contributors and to others who want to ask those authors for permissions to do non-IETF things, or if the IETF decides it needs the rights to transfer rights to others for non-IETF purposes. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -Original Message- From: John C Klensin [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 07, 2006 1:53 PM To: Gray, Eric; Spencer Dawkins Cc: ietf@ietf.org Subject: RE: Acknowledgements section in a RFC (Was: Last Call: 'Matching of Language Tags' to BCP (draft-ietf-ltru-matching) --On Wednesday, 07 June, 2006 12:33 -0400 Gray, Eric [EMAIL PROTECTED] wrote: Spencer, This opens up yet another can of worms. Suppose that everybody who makes a comment on a draft (substantive, or otherwise) has to be listed and every one listed is bound by BCPs relating to IPR, copyright, etc. in RFC content. They are so bound... read the Note Well. Whether they should be so listed is a separate issue. What happens if someone - perhaps having suggested that a word was misspelled - would prefer not to be bound by the BCPs (or perhaps is not permitted to be so bound)? Can they request to be left out? If they do, can an editor leave them out? Too bad. If they participate in the IETF at the level of either attending meetings or saying anything, they are stuck. While there are guidelines now (see Bob Braden's note) and guidelines can always be further tuned, I think we need to give some discretion to document editors about who should be listed --at least until and unless we have a clear definition of, e.g., WG membership. It occasionally happens now that a draft departs from the original direction that some of the contributors wanted it to go, and - slightly less often - those that disagree with the outcome ask to be de-listed. There are good and reasonable reasons to allow this - especially as there may be very strong reactions from a particular employer that is seen as advocating something they do not intend to do. In such cases, these early contributors provided much of the content - even if the over-all outcome is not in line with their intentions. So, again, would we be able to omit their names? I have often dealt with that issue in acknowledgements by being very explicit that all contributors may not agree with the conclusions reached as a consequence of their suggestions (or with their suggestions included). An even more extreme case exists than the ones that you mention: someone raises an issue and preference and the document is ultimately clarified to reflect exactly the opposite preference. In some of these cases, the document would not have addressed the topic at all had the issue not been raised. The person who raised the issue may still have made a contribution significant enough to justify acknowledgement but may have always been in violent disagreement with the conclusion reached by the IETF process about how to deal with it. The underlying problem here is not unique to the IETF. And people who don't want to contribute or be bound by the rules should avoid participation -- there isn't any whoops, I don't like the results so the rules should retroactively not apply to me and the fact that I participated at all should be erased option. Having such an option with regard to rule-conforming would result in chaos. Again, the Note Well is very clear about this (and there is a parallel discussion going in circles, perhaps parallel ones, in the IPR WG). john ___ 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: Best practice for data encoding?
Hi The security problems identified in http://www.cert.org/advisories/CA-2002-03.html Multiple Vulnerabilities in Many Implementations of the Simple Network Management Protocol (SNMP) are not caused by the protocol choice to use ASN.1, but by vendors incorrectly implementing the protocol (which was made worse by vendors using toolkits that had the problems). If Multiple Vulnerabilities in Implementations were used to condemn the encoding methods of protocols that have been incorrectly implemented, then we would have to condemn an awful lot of IETF protocols as being very (security) bug prone: CERT Advisory CA-2003-26 Multiple Vulnerabilities in SSL/TLS Implementations US-CERT Vulnerability Note VU#459371 Multiple IPsec implementations do not adequately validate CERTR Advisory CA-2001-18 Multiple Vulnerabilities in Several Implementations of the Lightweight Directory Access Protocol (LDAP) CERT Advisory CA-2002-36 Multiple Vulnerabilities in SSH Implementations CERTR Advisory CA-2003-06 Multiple vulnerabilities in implementations of the Session Initiation Protocol (SIP) Vulnerability Note VU#428230 Multiple vulnerabilities in S/MIME implementations Vulnerability Note VU#955777 Multiple vulnerabilities in DNS implementations Vulnerability Note VU#226364 Multiple vulnerabilities in Internet Key Exchange (IKE) version 1 implementations CERTR Advisory CA-2002-06 Vulnerabilities in Various Implementations of the RADIUS Protocol CERTR Advisory CA-2000-06 Multiple Buffer Overflows in Kerberos Authenticated Services Vulnerability Note VU#836088 Multiple vendors' email content/virus scanners do not adequately check message/partial MIME entities David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -Original Message- From: Steven M. Bellovin [mailto:[EMAIL PROTECTED] Sent: Monday, June 05, 2006 7:10 PM To: Randy Presuhn Cc: ietf@ietf.org Subject: Re: Best practice for data encoding? On Mon, 5 Jun 2006 16:06:28 -0700, Randy Presuhn [EMAIL PROTECTED] wrote: Hi - From: Iljitsch van Beijnum [EMAIL PROTECTED] To: IETF Discussion ietf@ietf.org Sent: Monday, June 05, 2006 2:43 PM Subject: Best practice for data encoding? ... Then there is the ASN.1 route, but as we can see with SNMP, this also requires lots of code and is very (security) bug prone. ... Having worked on SNMP toolkits for a long time, I'd have to strenuously disagree. In my experience, the ASN.1/BER-related code is a rather small portion of an SNMP protocol engine. The code related to the SNMP protocol's quirks, such as Get-Next/Bulk processing and the mangling of index values into object identifiers (which is far removed from how ASN.1 intended object identifiers to be used) require much more code and complexity. Yah -- measure first, then optimize. I'm curious, too, about the claim that this has resulted in security problems. Could someone elaborate? See http://www.cert.org/advisories/CA-2002-03.html --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ 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: Best practice for data encoding?
I agree that complexity breeds bug-prone implementations. I wasn't around then; did anybody push back on SNMPv1 as being too complex? http://www.cert.org/advisories/CA-2002-03.html is mainly about SNMPv1 implementations. ;-) dbh -Original Message- From: Steven M. Bellovin [mailto:[EMAIL PROTECTED] Sent: Monday, June 05, 2006 8:21 PM To: David Harrington Cc: [EMAIL PROTECTED]; ietf@ietf.org Subject: Re: Best practice for data encoding? On Mon, 5 Jun 2006 20:07:24 -0400, David Harrington [EMAIL PROTECTED] wrote: Hi The security problems identified in http://www.cert.org/advisories/CA-2002-03.html Multiple Vulnerabilities in Many Implementations of the Simple Network Management Protocol (SNMP) are not caused by the protocol choice to use ASN.1, but by vendors incorrectly implementing the protocol (which was made worse by vendors using toolkits that had the problems). If Multiple Vulnerabilities in Implementations were used to condemn the encoding methods of protocols that have been incorrectly implemented, then we would have to condemn an awful lot of IETF protocols as being very (security) bug prone: Works for me More precisely -- when something is sufficiently complex, it's inherently bug-prone. That is indeed a good reason to push back on a design. The question to ask is whether the *problem* is inherently complex -- when the complexity of the solution significanlty exceeds the inherent complexity of the problem, you've probably made a mistake. When the problem itself is sufficiently complex, it's fair to ask if it should be solved. Remember point (3) of RFC 1925. I'll note that a number of the protocols you cite were indeed criticized *during the design process* as too complex. The objectors were overruled. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: RFC Author Count and IPR
If I remember correctly, we only limit the number of suthors on the first page of the document. It is perfectly acceptable to list a longer set of names inside the document in an contributors section. I also have concerns about who should be listed as an author and have copyrights when a work is developed by a WG. The demand to do things with IETF documents beyond IETF standards work seems to be growing, so it will be an increasingly difficult problem if we do not identify all the people who contributed significant portions of a document (where significant is of course open to debate). dbh -Original Message- From: Sam Hartman [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 24, 2006 2:06 PM To: Russ Housley Cc: rfc-editor@rfc-editor.org; ietf@ietf.org; techspec@ietf.org; ipr-wg@ietf.org Subject: Re: RFC Author Count and IPR Russ == Russ Housley [EMAIL PROTECTED] writes: Russ I am concerned that the current RFC Editor practice that Russ limits the number of authors is in conflict with the IETF Russ IPR policies. The RFC Editor currently limits the author Russ count to five people. Recent IPR WG discussions make it Russ clear to me that authors retain significant copyright. [There is this concept in US copyright law called a joint work. I'm ignoring that concept for the moment basically because I don't understand how it applies to either software or text developed using an open process. As far as I can tell, no one else understands it either. Please be aware that this may be a huge gap in my advice.] So, here we have a conflicting definitions problem. The author of a work retains the copyright interest. That's true if if I'm listed as an author or not. If I write text and do not assign the copyright to someone, I retain copyright interest in that text. So the sixth person still owns the copyright interest in the text they write even if they are not listed. That means if you have unlisted authors who have contributed significant chunks of text, you still need to get their clearance to do anything interesting with that text. ___ 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: An absolutely fantastic wireless IETF
I'd like to second that. Great job! dbh -Original Message- From: Harald Alvestrand [mailto:[EMAIL PROTECTED] Sent: Thursday, March 23, 2006 9:58 PM To: ietf@ietf.org Subject: An absolutely fantastic wireless IETF Just wanted to state what's obvious to all of us by now: This time the wireless WORKED, and Just Went On Working. That hasn't happened for a while. THANK YOU! Harald ___ 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
