Re: Last Call: draft-ietf-opsec-ip-options-filtering-05.txt (Recommendations on filtering of IPv4 packets containing IPv4 options) to Best Current Practice
On Mon, 16 Sep 2013, The IESG wrote: The IESG has received a request from the Operational Security Capabilities for IP Network Infrastructure WG (opsec) to consider the following document: - 'Recommendations on filtering of IPv4 packets containing IPv4 options.' draft-ietf-opsec-ip-options-filtering-05.txt as Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-09-30. I would like to see the following issues addressed before this document is approved for publication. I have suggested specific replacement text in most cases, but I recognize that there are other ways to address the concerns that I raise. Sections 4.3 (LSRR) and 4.4 (SSRR): OLD: 4.3.5. Advice Routers, security gateways, and firewalls SHOULD implement an option- specific configuration knob whether packets with this option are dropped, packets with this IP option are forwarded as if they did not contain this IP option, or packets with this option are processed and forwarded as per [RFC0791]. The default setting for this knob SHOULD be drop, and the default setting MUST be documented. NEW: 4.3.5. Advice Routers, security gateways, and firewalls SHOULD implement an option- specific configuration knob whether packets with this option are dropped or whether packets with this option are processed and forwarded as per [RFC0791]. The default setting for this knob SHOULD be drop, and the default setting MUST be documented. The same change should be applied to 4.4.5. Rationale: pretending that the option is not present will result in violation of the semantics of the option. More specifically, if a node is specified in the dettination address of the IPv4 header ignores an unexpired source route option, then it will consume a packet that is actually addressed to another node. Section 4.6 (Stream ID): Editorial: OLD: However, as stated by Section 3.2.1.8 of RFC 1122 [RFC1122] and Section 4.2.2.1 of RFC 1812 [RFC1812], this option is obsolete. Therefore, it must be ignored by the processing systems. See also Section 5. NEW: However, as stated by Section 3.2.1.8 of RFC 1122 [RFC1122] and Section 4.2.2.1 of RFC 1812 [RFC1812], this option is obsolete. Therefore, it must be ignored by the processing systems. Rationale: Section 5 is the IANA Considerations section. RFC 6814 requested IANA to mark this option as obsolete, and that has been done. No change is needed to Section 5 as it does not request any actions from IANA. Misuse of RFC 2119 language: Section 4.6.3, Threats, says: No specific security issues are known for this IPv4 option. while Section 4.6.5, Advice, says: Routers, security gateways, and firewalls SHOULD drop IP packets containing a Stream Identifier option. Note that RFC 2119, Section 6 says: Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions). For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. The document does not identify any interoperability problems or potential harm that would be mitigated by dropping packets with this option. The SHOULD in Section 4.6.5 is therefore unjustified. Possible fixes: either provide a valid justification for the SHOULD, change it to a MAY, or specify that the Stream ID option SHOULD be treated in the same manner as an unknown option, i.e., as specified in Section 4.23.4. My vote would be for the latter; possible replacement text along those lines is as follows: NEW: 4.6.5. Advice Routers, security gateways, and firewalls SHOULD process IP packets containing this option in the same manner as those containing unknown options (see Section 4.23.4). Section 4.7: The Internet Timestamp option has similar uses as the Record Route option, and should be treated similarly. Specifically: OLD: 4.7.1. Uses This option provides a means for recording the time at which each system processed this datagram. NEW: 4.7.1. Uses This option provides a means for recording the time at which each system (or a specified set of systems) processed this datagram, and may optionally record the addresses of the systems providing the timestamps. OLD: 4.7.4. Operational and Interoperability Impact if Blocked None. 4.7.5. Advice Routers, security gateways, and firewalls SHOULD drop IP packets containing an Internet Timestamp option. NEW: 4.7.4. Operational and Interoperability Impact if Blocked Network troubleshooting techniques that may employ the Internet Timestamp option (such as ping with the
Re: I'm struggling with 2219 language again
On Mon, 7 Jan 2013, ned+i...@mauve.mrochek.com wrote: I'll also note that RFC 1123 most certainly does use the term compliant in regards to capitalized terms it defines, and if nitpicking on this point becames an issue I have zero problem replacing references to RFC 2119 with references to RFC 1123 in the future. +1. There is similar language in RFC 1122 and RFC 1812. From the standpoint of making the requirements clear for an implementor, I think that these three specifications were among the best the IETF ever produced. //cmh
Re: [Int-area] Apps Directorate Review of draft-ietf-intarea-ipv4-id-update-05
On Sat, 2 Jun 2012, Joe Touch wrote: Hi, Eliot, On Jun 2, 2012, at 6:00 AM, Eliot Lear wrote: Document: draft-ietf-intarea-ipv4-id-update-05 Title: Updated Specification of the IPv4 ID Field Reviewer: Eliot Lear Review Date: 2 June 2012 IETF Last Call Date: 31 May 2012 Summary: This draft is quite well written, and is very nearly ready for publication. This draft is well written, and from the applications perspective represents an important step to improving performance and error reduction. It uses a new requirements call-out style that I would class as experimental, but not bad. It is worth people reading this draft and deciding if they agree with Joe's approach. FWIW, I thought it was helpful. Major issues: None (Yay!). Minor issues: Section 4 needs to be reconciled a bit with Section 6.1. Specifically: The IPv4 ID field can be useful for other purposes. And IPv4 ID field MUST NOT be used for purposes other than fragmentation and reassembly. My suggestion is to drop the above sentence from Section 4. The two are not contradictory - the ID can be useful, but generating it correctly is prohibitive and typically not done. After re-reading the text I agree with Eliot that it is confusing. Dropping the sentence in Section 4 would be fine. Another possibility would be to reword it along the following lines: Other uses have been envisioned for the IPv4 ID field. In Section 6.1: Datagram de-duplication can be accomplished using hash-based duplicate detection for cases where the ID field is absent. Under what circumstances would the ID field be absent? Replace absent with known not unique. Better, I think, would be not known to be unique. Sources of non-atomic IPv4 datagrams using strong integrity checks MAY reuse the ID within MSL values smaller than is typical. Is the issue really the source using strong integrity checks or the destination in this context? What is typical? The onus is on the source (of non-atomic datagrams) - if it includes strong integrity checks (that are presumably validated by the receiver), it then has more flexibility in its generation of the iD values. Nit: Shouldn't Sections 3, 4, and 5, really be Sections 2.1, 2.2, and 2.3? Not subsections of 2, but perhaps 3, 3.1, 3.2? That would be fine but I'm also OK with leaving the document the way it is (especially if it would get it into the publication queue faster). //cmh
Re: Last Call: draft-ietf-intarea-ipv4-id-update-05.txt (Updated Specification of the IPv4 ID Field) to Proposed Standard
On Sat, 2 Jun 2012, Masataka Ohta wrote: Existing routers, which was relying on ID uniqueness of atomic packets, are now broken when they fragment the atomic packets. Such routers were always broken. An atomic packet has DF=0 and any router fragmenting such a packet was and is non-compliant with the relevant specifications (RFCs 791, 1122, 1812). //cmh
Re: [Int-area] Apps Directorate Review of draft-ietf-intarea-ipv4-id-update-05
On Sun, 3 Jun 2012, Glen Zorn wrote: On Sat, 2012-06-02 at 21:21 -0700, C. M. Heard wrote: ... In Section 6.1: Datagram de-duplication can be accomplished using hash-based duplicate detection for cases where the ID field is absent. Under what circumstances would the ID field be absent? Replace absent with known not unique. Better, I think, would be not known to be unique. Except that the two are not semantically equivalent. Indeed. That was why I suggested the change. //cmh
Re: Last Call: draft-ietf-intarea-ipv4-id-update-05.txt (Updated Specification of the IPv4 ID Field) to Proposed Standard
On Thu, 31 May 2012, The IESG wrote: The IESG has received a request from the Internet Area Working Group WG (intarea) to consider the following document: - 'Updated Specification of the IPv4 ID Field' draft-ietf-intarea-ipv4-id-update-05.txt as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-06-14. 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. I commented on the previous version of this draft during WG last call (as a WG non-member) and supported its publication then. I have looked over the changes in the present version and continue to support its publication. I believe that it addresses an operational deficiency in current IPv4 specifications and largely codifies existing pactice. My one reservation is that I do not think it is strictly necessary to ban re-use of the IPv4 ID value in retransmitted non-atomic IPv4 datagrams. On the other hand, the evidence available to me suggests that existing implementations overwhelmingly comply with this ban anyway, so it does not seem to do any harm. Regards, C. M. Heard
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On Wed, 1 Feb 2012, Brian E Carpenter wrote: On 2012-02-01 08:14, Pete Resnick wrote: On 1/31/12 11:59 AM, George, Wes wrote: From: Noel Chiappa [mailto:j...@mercury.lcs.mit.edu] Is that wise? I thought (IIRC, and maybe I'm spacing) the whole reason for allocating this space was that 1918 space _couldn't_ easily be used for CGN because there were too many conflicting usages. [WEG] yes, but the general sense I got from the ensuing discussion was that no one expects anyone to actually adhere to that advice (ie MUST NOT be used as substitute for 1918 space), and as soon as the space is released, it'll be cats and dogs living together, mass hysteria... because everyone and their cousin will start using it as 1918-bis anyway, no matter whether the IETF wags their fingers at them or not. I have no doubt that this space will be (mis)used as additional private ambiguous address space. But IMHO the text should make it clear that this is the wrong way to use it and give the reasons why - basically the same information as in the new text, but stated exactly the other way round. For example Shared Address Space is IPv4 address space designated for Service Provider use with the purpose of facilitating CGN deployment. Shared Address Space is not intended to be used as additional [RFC1918] space, because either or both of the following issues might arise: o Shared Address Space could also be used on the Service Provider side of the CPE, with overlapping subnet or host addresses. o Some CPE routers behave incorrectly when using the same address block on both the internal and external interfaces. Speaking as one of the bozos^h^h^h^h^h ADs whose comments (and suggested text) ended the document up here, let me suggest the slightly less pessimistic view from Wes's, and the reason that I think this *shouldn't* specifically update 1918: This *is* a special use address block that is akin to 1918. It is non-routable address space, just like 1918. But unlike 1918, this block is defined as might be used by your ISP on your outside interface. So, people using it inside their networks (which, I agree with Wes, will happen, and like everything else on the net, will be done stupidly by some) have been told that this is *not* private use space and that they use it at their own risk and their CGN service might stop working if they use it in a way not described in this document. But I'd hate for us to allocate space to CGNs only when it's obvious that this can be used for a whole class of these sorts of things, and can be used by other people who build sane equipment that understands shared addresses can appear on two different interfaces. These aren't private addresses a la 1918, they're shared, so it's not an addition to that space. Let's properly document what it is we're doing, giving people fair warnings. Exactly, hence my suggested text above. +1 //cmh ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
On Mon, 5 Dec 2011, Randy Bush wrote: The assumption in my question is that if the legacy (broken?) gear in question all uses 10/8 *and* we publish a document that declares a particular (presently unused by said gear) block of 1918 address space is henceforth off limits to use in equipment that can't translate when addresses are identical on the outside and the inside, then the use of that 1918 address space might be safe for CGNs to use. might require a cpe change. about the same change as for the cpe to recognize new/10 as non-public. Maybe I'm missing something, but why would CPE need to recognize a new /10 CGN block as non-public? Isn't the whole idea to leave the CPE unchanged and get the CGN boxes (and the rest of the core network infrastructure) to recognize the /10 CGN block as non-routeable? //cmh ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
I've followed the discussion, both on the OPSAWG list and on the IETF list, and I have to say that I agree with the comments below by Henning Schulzrinne and Bernard Aboba. One question, though, that I wish to address to the authors of draft-weil-shared-transition-space-request and perhaps others: why would not an allocation from 240/4 (the former Class E address space) work for CGN space? I'm well aware that it would be very difficult to use this as ordinary IPv4 address space because of the long history of treating it as a Martian address range. It seems to me, however, that this would NOT be an issue for CGN boxes -- those being new equipment, the software can be upgraded to treat this address range differently than it traditionally has been. It would be more difficult for CPE equipment to use -- especially stuff that's already deployed -- but that's actually an ADVANTAGE since such devices are not supposed to use CGN space. And an allocation from 240/4 would not use up scarce global IPv4 space, which is one of the main objections I've been hearing to this allocation. So ... to the authors of draft-weil-shared-transition-space-request and other advocates of this allocation : please tell us whether an allocation from 240/4 would work for CGN space, and if not, why not. To the IESG: please require the authors and/or other advocates of the propsed allocation to answer the above question before approving the allocation request. If they agree that it will do, approve an allocation from that space. If they provide a cogent argument as to why 240/4 won't work, then I advise (reluctantly) approving the allocation from the remaining IPv4 global space. Thanks for listening. //cmh On Sat, 3 Dec 2011, Bernard Aboba wrote: The same thought occurred to me. A very large enterprise will not utilize this /10 on a whim; they'd talk to their ISP first. A consumer is unlikely to modify the settings of their home router, except if they download malware that does it for them :) and a consumer router vendor has such a low margin that the last thing they want is to utilize this forbidden /10, generating thousands of tech support calls they can't afford to answer. On Dec 3, 2011, at 20:54, Henning Schulzrinne h...@cs.columbia.edu wrote: Almost all residential customers will use a standard home router; as long as that home router does not make the new space available to customers, it will not be used. Almost all residential users get their home NAT box either from the ISP (who obviously won't ship such a box) or from one of a handful of retail consumer equipment vendors, who won't suddenly switch from RFC 1918 addresses, either (because they don't want to get the support calls). I don't think your consumer ISP will have much sympathy if you call them up and tell them that you decided to use 128.59.x.x internally, reconfigured the gateway and can no longer get to Columbia University. This is an economics issue: If one big corporate customer with a too-creative sysadmin calls up after finding this new address space, this can be dealt with. (Indeed, that large corporate customer probably has non-1918 outward-facing addresses to begin with and will keep them, so they are the least likely target of CGNs.) If 10,000 consumer customers call up because their Intertubes aren't working, the ISP has a problem. Thus, I'm having a hard time believing in the theory that the new space will be immediately appropriated for consumer ISPs. By whom, exactly, and on what scale and with what motivation? Henning On Dec 3, 2011, at 8:36 PM, Noel Chiappa wrote: From: Doug Barton do...@dougbarton.us This argument has been raised before, but IMO the value is exactly zero. The fact that you have a finger to wag at someone doesn't make the costs of dealing with the conflict any smaller. Perhaps. But I don't know the ISPs' business as well as they do. So I'd like to hear their views on this point. (They may well have considered this point before deciding to ask for CGN space, and decided the space was still enough use to be worth it.) Noel ___ 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
draft-ietf-v6ops-6to4-advisory dependency on draft-ietf-v6ops-6to4-to-historic
Greetings, I note that draft-ietf-v6ops-6to4-advisory-02, now approved for publication and in the RFC Editor's queue, has a minor dependency on draft-ietf-v6ops-6to4-to-historic, specifically at the end of Section 1 (bottom of p. 3): A companion document [I-D.ietf-v6ops-6to4-to-historic] proposes to reclassify 6to4 as Historic. However, this will not remove the millions of existing hosts and customer premises equipments that implement 6to4. Hence, the advice in this document remains necessary. That may need to be changed (e.g., in AUTH48), depending on the outcome of the pending appeal against draft-ietf-v6ops-6to4-to-historic. //cmh On Tue, 5 Jul 2011, Ronald Bonica wrote: Noel, I didn't say that I was going to push draft-ietf-v6ops-6to4-to-historic through without running the process. I said that draft-ietf-v6ops-6to4-to-historic has made it all the way past IESG approval. There is an appeal on the table (at the WG level) questioning whether draft-ietf-v6ops-6to4-to-historic ever had WG consensus. We will run the appeal process. If the WG chairs cannot justify WG consensus, draft-ietf-v6ops-6to4-to-historic stops dead in its tracks. If they can justify WG consensus, the appellant can escalate the appeal to the IESG (and to the IAB after that). If the appeal succeeds at any level, draft-ietf-v6ops-6to4-to-historic is not published. Ron -Original Message- From: Noel Chiappa [mailto:j...@mercury.lcs.mit.edu] Sent: Tuesday, July 05, 2011 10:44 AM To: ietf@ietf.org; v6...@ietf.org Cc: j...@mercury.lcs.mit.edu Subject: RE: draft-ietf-v6ops-6to4-to-historic From: Ronald Bonica rbon...@juniper.net I think that I get it. There is no IETF consensus regarding the compromise proposed below. ... But there is no rough consensus to do that either. That is the claim of an appeal on the table. Let's run the appeal process and figure out whether that claim is valid. Sorry, this makes no sense. You can't go ahead with draft-ietf-v6ops-6to4-to-historic if there is no basic consensus in the IETF as a whole to do so - and your previous declaration (on Saturday) basically accepted that there was no such basic consensus (otherwise why withdraw the ID). So now there is going to be a reversal, and the document is going to go ahead - i.e. you must now be taking the position that there _is_ basic consensus in the IETF (without which you could not proceed the ID). The effect of this sort of thing on the reputation of I* should be obvious to all. Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: SHOULD vs MUST case sensitivity
On Fri, 27 Jun 2008, Dave Crocker wrote: Eric Gray wrote: (By the way, I hope folks are clear that IETF use of these words as normative does not depend upon the case that is used?) This is NOT true. These terms are explicitly defined in all capital letters to make it possible to distinguish when they are being used as normative and when they are not. Sorry, no. Please re-read rfc 2219. Specifically: These words are often capitalized. The key word is often which means not always which means not required. That quote is taken out of context. Here is the full text: In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document: The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in RFC 2119. I read this to mean that the words are often capitalized in many (pre-RFC 2119) documents. I also read the following two statements to mean that the words will be capitalized when following the guidelnes in RFC 2119. The common usage in the IETF is to capitalize the words when used with the meanings in Sections 1-5 of RFC 2119 and to use then in lower case when ordinary English usage is meant. RFC 2119 itself follows this usage (see, e.g., Section 6, Guidance in the use of these Imperatives). //cmh ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART review of draft-cheshire-ipv4-acd-05.txt
On Fri, 16 Nov 2007, Spencer Dawkins wrote: address of the interface sending the packet. The 'sender IP address' field MUST be set to all zeroes, to avoid polluting ARP caches in other hosts on the same link in the case where the address turns out to be already in use by another host. The 'target hardware address' field is ignored and SHOULD be set to all zeroes. The 'target IP Spencer: why is this SHOULD, and not MUST? I'm not asking for a change, I'm asking for a clue. I'm suspecting the answer is some really old implementations may not do this, and that would be fine if you said it - just being clear that the SHOULD isn't a license for new implementations to say I'm special. This shouldn't even be a SHOULD because it is not required for interoperability. It certainly can't be a MUST, as it conflicts with a suggestion in the original ARP specificaion (RFC 826). Here is what RFC 826 has to say about how an ARP implementation sets the target hardware address in an ARP request that it is about to broadcast: | It does not set ar$tha to anything in particular, | because it is this value that it is trying to determine. It | could set ar$tha to the broadcast address for the hardware (all | ones in the case of the 10Mbit Ethernet) if that makes it | convenient for some aspect of the implementation. In other words, the target hardware address does not matter and can be set to any value. I am aware of implementations that follow the suggestion (which would be a MAY in 2119 parlance) to set ar$tha to the broadcast address when broadcasting an ARP request. Here is the guidance from Section 6 or RFC 2119 on the use of imperatives such as should: | Imperatives of the type defined in this memo must be used with care | and sparingly. In particular, they MUST only be used where it is | actually required for interoperation or to limit behavior which has | potential for causing harm (e.g., limiting retransmisssions) For | example, they must not be used to try to impose a particular method | on implementors where the method is not required for | interoperability. I do not see how the above SHOULD enhances interoperability or limits the potential for causing harm. Insofar as draft-cheshire-ipv4-acd-05.txt claims not to modify any protocol rules, its insistence that ar$tha should be set to zero in ARP request packets certainly looks odd to me. While I am at it, I also have an issue with the draft's Section 4, Historical Note. The first sentence reads: A widely-known, but ineffective, duplicate address detection technique called Gratuitous ARP is found in many deployed systems [Ste94]. This sentence seems to claim that the intended purpose of Gratuitous ARP was to perform duplicate address detection. That was not the case. Its purpose was to flush stale entries out of ARP caches when a station's IP address (or Ethernet address) changed. See, e.g., RFC 2002 and references therein. Mike Heard ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-heard-rfc4181-update (RFC 4181 Update to Recognize the IETF Trust) to BCP [WAS: Gen-art review of draft-heard-rfc4181-update-00.txt]
On Tue, 23 Jan 2007, Gonzalo Camarillo wrote: I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. I will do so, and in that spirit I'm posting my response to the IETF list with the subject line changed. My apologies for the delay in replying. Draft: draft-heard-rfc4181-update-00.txt Reviewer: Gonzalo Camarillo [EMAIL PROTECTED] Review Date: 23 January 2006 IETF LC Date: 16 January 2006 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. Comments: The title of the draft could be more explicit. Now it mentions RFC 4181. It could also indicate that it is an update to the Guidelines for Authors and Reviewers of MIB Documents. I disagree with this comment -- I believe that doing as it suggests would make the title unnecessarily long. Note that the Abstract already spells out the full title of RFC 4181. Acronyms (e.g., MIB) should be expanded on their first use. The only places where the acronym MIB is used are in the Abstract and the References, where the title of RFC 4181 is quoted. The acronym is not expanded in that title, and it would be inappropriate to do so in a citation, which is supposed to quote the exact title of the document being cited. Also, I believe that MIB qualifies as an appreviation that is so firmly extablished in IETF usage that its use is very unlikely to cause uncertainty or ambiguity and so is exempt from the usual acronym expansion requirement. Granted that it is not explicitly mentioned in http://www.rfc-editor.org/policy.html#policy.abbrevs, but several recent RFCs using the acronym MIB have appeared without it being expanded anywhere. RFC 4181 and RFC 4663 are examples. The only other acronym I see is IETF, and that one is explicitly mentioned in http://www.rfc-editor.org/policy.html#policy.abbrevs. The draft should be divided into pages, none of which should exceed 58 lines. Unless I'm required to make another revision for other reasons, I'd like to let the RFC Editor take care of that (which they will do anyway) ... my apologies if the lack of pagination has caused any readability problems. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-mcwalter-uri-mib (Uniform Resource Identifier (URI) MIB) to Proposed Standard
Sam Hartman wrote: The title of this document is very confusing and should be revised to include the string textual convention. Seeing this last call announcement I was very puzzled why anyone thought it would be a good idea to hae a MIB for monitoring and managing all the URIs on a managed system. I was gratified to find that this is not what the document was about. I strongly agree with the above comments. For the title I would recommend: Textual Conventions for Representing Uniform Resource Identifiers (URIs) In the same vein, I would recommend URI-TC-MIB for the module name and uriTcMIB for the descriptor representing the MODULE-IDENTITY value. Note that these recommendations are consistent with the (non-binding) advice in Appendix C of RFC 4181 (the MIB review guidelines). //cmh ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-mcwalter-langtag-mib (Language Tag MIB) to Proposed Standard
On Thu, 8 Feb 2007, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Language Tag MIB ' draft-mcwalter-langtag-mib-01.txt as a Proposed Standard The title seems to suggest that the document defines managed objects for managing language tags, which is not the case. In order to prevent confusion, I would recommend that the title be changed to: A Textual Convention for Representing Language Tags In the same vein, I would recommend LANGTAG-TC-MIB for the module name and langTagTcMIB for the descriptor representing the MODULE-IDENTITY value. Note that these recommendations are consistent with the (non-binding) advice in Appendix C of RFC 4181 (the MIB review guidelines). //cmh ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: FW: Last Call: draft-heard-rfc4181-update (RFC 4181 Update to Recognize the IETF Trust) to BCP
On Sat, 27 Jan 2007, Frank Ellermann wrote: C. M. Heard wrote: The draft is intended to do the same thing for RFC 4181 that RFC 4748 did for RFC 3978. Comments, if any, should be directed to ietf@ietf.org. Now that you ask, your patches are straight forward, so why not simply apply them and publish a complete new 4181bis ? Patchwork RFCs are IMO ugly. RFC 4748 was a special case, it was urgent, there was a competing 3978bis draft, and the IPR WG intends to update RFC 3978 anyway, soon. A somewhat radical proposal: If your patch is approved you could transform it into a complete 4181bis in AUTH48, and let that obsolete 4181. Or is the 4181 situation exacly as for 4748 + 3978 ? The situation for RFC 4181 is like this: new copyright language will be required in IETF MIB documents as of the beginning of next month, so we need to get an update out ASAP. The original plan was to issue a complete 4181bis, but the person who has volunteered to take over the editing duties is busy with other things, so I proposed the patch as an interim solution. (Note that we don't have xml source for this document, so the first job for the new editor is creating it ... not a trivial task.) My hope and expectation is that there will be a complete 4181bis in the not too distant future. Your patch might be incomplete, chapter 3.7, appendix A, and the normative references mention 3978 instead of 3978 + 4748. Especially appendix A point 7 should now point to RFC 4748. That's something that I hoped could wait for a complete 4181bis. //cmh ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
draft-carpenter-rfc2026-critique-02.txt (was: As Promised, an attempt at 2026bis)
On Tue, 3 Oct 2006, Brian E Carpenter wrote: Quite seriously - am I to conclude from the absence of comments on that draft that everyone agrees that it correctly describes current practice? If so, I'll look for an AD to sponsor it. I've read the document a couple of times, and it appears to me to be reasonably accurate. On Tue, 3 Oct 2006, Eliot Lear wrote: However, you have missed the forest from the trees. The fundamental description of how we behave as an organization is lost in a section by section critique. It would have been better for you to update RFC 2026 with an appendix explaining the changes and why they are necessary to reflect reality. Oh wait. I've done (or at least begun) that. I, too, would prefer to see an update to 2026 that brings it into conformance to current practice. However, Eliot's draft goes well beyond that by proposing substantive changes to current practice, and those proposed changes seem to be quite controversial. In the absence of an update proposal that has community consensus, I think it would be useful to have a description of how 2026 diverges from current practice. So I would encourage Brian to attempt to publish draft-carpenter-rfc2026-critique-02.txt as an information RFC. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: As Promised, an attempt at 2026bis
On Wed, 27 Sep 2006, Eliot Lear wrote: Please find in draft-lear-ietf-rfc2026bis-00.txt a preliminary revision of, well, RFC 2026. It contains the following changes: 1. A new two step process for standardization where the second step is optional. In other words, you get an STD # at the first step. This is a bit of compromise position. The idea is to reflect reality of the existing ONE STEP process but allow that some might wish to indicate that a standard is indeed more mature. 2. A suggested mapping from PS/DS/IS is included. 3. A request is made for appropriate relabelling. 4. There is no mandatory timeline for the IESG to reconsider standards on that first step, but they may do so in a manner of their choosing after the two year mark. I could get behind this proposal. However, for me the key parts are that you get a STD number upon entry to the standards track and that advancement is encouraged but optional. Indeed, I would be just as happy with a proposal that did this but retained PS/DS/IS, since that would be sufficient to bring the process document into alignment with current practice. On Thu, 28 Sep 2006, Ned Freed wrote: [John Klensin wrote:] While I agree with that, I suggest that we are in something of a conundrum. Right now, 2026 is badly out of date in a number of areas. It reflects procedures and modes that we no longer follow, only a fraction of which are addressed by Eliot's draft. There is general community understanding and acceptance that we are operating, not by the letter of 2026, but by the combination of 2026 and a certain amount of, largely undocumented, oral tradition (I expect to hear from the usual suspects on that assertion, but it is the way it is). To make things worse, we have some BCPs that effectively amend 2026 but that are not referenced in Eliot's draft -- I've pointed out some of them to him, which I assume will be fixed, but may have missed others. If that's indeed the case, the first order of business needs to be to document current practice. I see no chance of making forward progress on actual changes without first having a consensus as to what our current state is. Brian Carpenter has written draft-carpenter-rfc2026-critique-02.txt which does exactly that, and he has repeatedly solicited comments on it. If you think that it would be helpful to have it published as an informational RFC before undertaking to make normative changes to our standards procedures, please say so. On Thu, 28 Sep 2006, John C Klensin wrote: The current practice version of the three-step standards process would be, IMO, to leave the three steps there (we clearly have them and use them, even if not often) but either remove the periodic review and timeout provisions or replace them with some words that indicate that regular review and advancement/demotion still reflect community desire but that, in practice, we never do it. Speaking personally, I could live with either of those as a description of current status, even though they seem contradictory, so I see some hope of getting agreement on some very careful wording. As I noted above, I would be OK with an update to 2026 that did just that and nothing else. It would be a big improvement on the current situation. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: what happened to newtrk?
On Tue, 5 Sep 2006, Eliot Lear wrote: Numerous proposals were made within the working group. The ISD proposal seemed to be the one that had the most support. However, this proposal ran into stiff opposition within the IESG and was effectively killed. We can argue until the cows come home as to whether or not the ISD proposal was ready for prime time. However, the end result was that we had a working group chartered to do a specific task, do the task, and then have the work rejected. From my perspective as an outsider, I have to say that I was extremely disappointed that the WG spent the bulk of its time on the creation of a new series of short IESG-approved IETF documents to describe and define IETF technology standards rather than concentrating on redefining the standards track. What I would like to know is what we could have done to prevent this from happening. Was the newtrk charter not sufficiently narrow to accomplish a task for which there was community consensus? Having just re-read the charter, I would have to say so. I think we would have been better served if the WG had been given the much less ambitious task of producing an update of RFC 2026 that describes what we actually do. Eventually, as I wrote in a previous note, we must circle back and actually fix the standards process to reflect reality. But how that is to be done remains to me an open question. Well, one possibility might be to charter a design team or WG to do just that -- i.e., to take the term Best Current Practice at face value and produce of a standards process BCP that actually documents current practice. //cmh ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: My notes on draft-carpenter-newtrk-questions-00.txt
On Wed, 12 Jul 2006, Eric Rosen wrote: The focus on document relationships rather than on simplifying the standards track is what (well, is one of the things) that sent newtrk off into the weeds. I completely agree. Frankly, I don't care if someone on a desert island cannot figure out from the RFCs alone how to implement some protocol. I just don't see that as a problem we have to solve. Anyway, implementing a protocol requires so much more knowledge than can be obtained from the RFCs that no amount of messing with the document strategy is going to have any impact on the ability of our castaway to become a successful implementer. Very well said. As I said in my message of 18 June, my advice would be to make a relatively minor set of clarifications to BCP 9 (RFC 2026) and move on. It would also be OK for newtrk to refocus on its original charter of simplifying the standards track. But I would be very dismayed to see it focus on document relationships. Mike Heard ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-carpenter-newtrk-questions-00.txt]
[ follow-ups to IETF discussion list please] Of the three possible ways forward suggested by this draft, I think that the only one that's likely to get done is this one: 1. Agree that, apart from day to day efforts to improve efficiency, the problems with the existing standards track are not serious enough to justify the effort needed to make substantial changes. Conclude that [RFC3774] exaggerated the problem and we only need to make a relatively minor set of clarifications to BCP 9 [RFC2026]. I say this because the newtrk WG has already tried to do the other two things that were suggested (focusing on document relationships and reworking the standards track) and failed. The deafening silence on the WG mailing list suggests to me that the energy has run out of this WG and it should be closed. I believe that two modifications (not clarifications) to RFC 2026 would suffice: - drop the expectation that a document will necessarily ever advance, and drop the requirement for periodic reviews of documents at PS or DS; - drop the no normative downrefs rule. This last should be done with an absolute minimum of fuss and with no imposition of requirements to put special notes in the documents about downrefs. If we can't agree on that, then I would settle for just the first modification. That would at least get our documented procedures more in line with the reality that we practice. Mike Heard ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Location Types Registry' to Proposed Standard
On Mon, 16 Jan 2006, The IESG wrote: The IESG has received a request from the Geographic Location/Privacy WG to consider the following document: - 'Location Types Registry ' draft-ietf-geopriv-location-types-registry-03.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-01-30. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-geopriv-location-types-registry-03.txt What I would like to know is how a document that creates a registry can be considered for Proposed Standard, as opposed to BCP. A Proposed Standard is supposed to be something that can be advanced on the standards track. How on Earth does one have multiple interoperable genetically unrelated implementations of a registry? //cmh P.S. Yes I know we do this all the time but that does not mean that it makes sense! ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF Last Call under RFC 3683 concerning Dean Anderson
On Wed, 12 Oct 2005, Dean Anderson wrote: I just checked the archives, and I see no original message on this topic. Who initiated this Last Call? The quoted message below from David Kessens does not seem to appear in the IETF archive on October 7th. It appeared on the IETF Announce list (as is customary). See http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg01645.html for the archive entry. FWIW, now that I see RFC 3683 in action I have to say that I have severe misgivings about it. //cmh ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Question about the normative nature of IETF RFCs
JFC (Jefsey) Morfin wrote: Interestingly, Transpac, the French X.25/Minitel network (by then the largest data network in the world, so acting as a kind of reference) published a test machine (probably around 1982?) everyone could use to verify his conformance to the (stringent) network requirments. At the Den Hague ISIS Club (1984?) the Dutch PTTs proposed to extend that pratice to the whole International Network, standardising the running test program concept (for OSI, DECNET, IBM/SNA, Swift, Sita, etc.. then supported protocols). . This was further discussed within the CEPT (European Public Operators Club) for OSI services, but I did not heard of any decision or CCITT (ITU-T) proposition. This kind of standardisation by the running test was a standard question when discussing a new root name interconect. But I do not think it was used by any other OSI operators ? The concept is however appealing: to add a test running code to an RFC, as a way to document, check and enforce its standard? My experience with this sort of thing was pretty negative. I worked on an X.25 DTE implementation in the early 1980s, and we had to get it certified by a US government agency in order to be allowed on one of the government networks. The certification code appeared to have had been written by a junior engineer, and it required behaviour that was inconsistent with the written standards and would have caused significant interoperability problems. So we did what everyone else did: we submitted hacked code for the certification test, got the certification paper, and then deployed our original code (which was compliant with the standard and was known to interoperate with the equipment we had to talk to). My hazy recollection of the Transpac certification tests is that their test machine actually did a relatively good job, but that they did not require certification to connect to their network. IIRC they didn't believe that non-conforming behaviour from a DTE would harm the network ... if it failed to interoperate, it the customer/vendor would be motivated to fix it. //cmh ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [EMAIL PROTECTED]: Mismanagement of the DNSOP list]
On Tue, 27 Sep 2005, Nick Staff wrote: John- Could you please specify the RFC that details the procedure for when an AD requests that the IESG remove someone's posting privileges from the IETF list (the RFC other 3683 of course). If there isn't one then I'd have to ask that you refrain from making wildly unsupported claims as they are disruptive to the process. Thanks, Nick Apparently you missed this in John's message (which you quoted in its entirety, with garbled formatting): RFC2418 allows a WG chair and the ADs to also take measures if someone is disrupting WG progress (sect 3.2). ] ] As with face-to-face sessions occasionally one or more individuals ] may engage in behavior on a mailing list which disrupts the WG's ] progress. In these cases the Chair should attempt to discourage the ] behavior by communication directly with the offending individual ] rather than on the open mailing list. If the behavior persists then ] the Chair must involve the Area Director in the issue. As a last ] resort and after explicit warnings, the Area Director, with the ] approval of the IESG, may request that the mailing list maintainer ] block the ability of the offending individual to post to the mailing ] list. Look on the second paragraph on Page 13. //cmh ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF Process Evolution
On Fri, 16 Sep 2005, Ted Hardie wrote: At 1:39 PM -0500 9/16/05, Spencer Dawkins wrote: While it seems plausible that we could use the same mechanism for protocol design and for process evolution, my understanding of the Problem working group's efforts and the subsequent newtrk/icar/proto/mpowr (and yes, there were others) efforts is that this approach simply does not work. Spencer, simply does not work is good rhetoric, but it doesn't fit all the facts. Groups like NomCom and IPR have taken on tasks and done them, with community discussion of their charters and with community discussion as their documents went through the process. They are process change groups, and they work. From my perspective I would have to say that the preponderance of the evidence supports Spencer's position. My reaction to your initial response to Brian's message proposing yet another WG was oh, and it will be as successful as newtrk. Of course I could have added icar or sirs or the others that Spencer mentioned. And it's funny that you metion IPR as a success ... it seems to me that a lot of energy was spent to get very little, and in may ways it was a step backward (e.g., non-IETF folks now have to go to document authors to get permission to use a MIB etract or program fragment). For sure, the IPR effort has resulted in a delay of at least 18 months (with the clock still ticking) in getting the MIB review guidelines doc published (and I suspect, but cannot prove, that it is largely responsible for the long delay in getting rfc2223bis published). Even granting that nomcom has been a success -- I don't know the evidence in that case one way or another -- I'd have to say that the overall record for process change WGs has been very poor. In any case I would like to go on record as strongly supporting Brian's initiative. Given the lack of progress in newtrk and the like I think it's the only hope of moving forward. Mike Heard ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Recharter of Integrated Security Model for SNMP (isms)
On Wed, 7 Sep 2005, The IESG wrote: A modified charter has been submitted for the Integrated Security Model for SNMP (isms) working group in the Security Area of the IETF. ... In order to leverage the authentication information already accessible at managed devices, the new security model will use the SSH protocol for message protection, and RADIUS for AAA-provisioned user authentication and authorization. However, the integration of a transport mapping security model into the SNMPv3 architecture should be defined such that it is open to support potential alternative transport mappings to protocols such as BEEP and TLS. The new security model must not modify any other aspects of SNMPv3 protocol as defined in STD 62 (e.g., it must not create new PDU types). If (as I have gathered from the discussion over the past few days) the last sentence quoted above means that it is out of scope for the working group to even consider solutions that allow agents and managers to work on either side of firewalls or NATs, then I think that the charter is drawn too narrowly and should be revised. Indeed, I think that it should be an explicit goal (if not a requirement) for the solution to work even when one of the parties (agent or manager) is unable to accept incoming TCP connections. That issue will have to be addressed eventually, and it is better for implementors to go through the churn once rather than twice. Mike Heard P.S. Note that I am using the words agent and manager in the traditional sense, i.e., to mean notification originator + command responder and notification receiver + command generator respectively. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Is it necessary to go through Standards Track to Get to Historic? (WAS: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02)
On Sun, 28 Aug 2005, Bruce Lilly wrote: The Historic category of published RFCs can be used for documents which specify a protocol or technology which is known to be harmful to the Internet. However, RFC 2026 appears to have no provision for getting to Historic except via the Standards Track [...] What makes you say that? It sure isn't what I read from RFC 2026. It says this in Section 4.2.4: A specification that has been superseded by a more recent specification or is for any other reason considered to be obsolete is assigned to the Historic level. (Purists have suggested that the word should be Historical; however, at this point the use of Historic is historical.) Seems to me that the proviso is for any other reason considered to be obsolete could reasonably be construed to cover the initial publication of an obsolete specification. It's certainly true that the most common way to get to Historic is to start on the standards track and then get retired, but I see nothing in RFC 2026 that says (or even implies) that this is the only way. //cmh ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Is it necessary to go through Standards Track to Get to Historic?
On Sun, 28 Aug 2005, Bruce Lilly wrote: The only specific procedures for getting to Historic in 2026 are in sections 6.2 and 6.3 and involve getting to Historic from the Standards Track. Note that section 4.2.3 gives procedures for Informational and Experimental RFCs, but that the only specific procedures for Historic are in sections 6.2 and 6.3. RFC 2026 sets the rules for Internet standardization, i.e., it is authoritative with respect to the handling of standards or BCPs. So it's fair to conclude that the procedures in sections 6.2 and 6.3 are the only way for a standards-track document to get to Historic. However, RFC 2026 does not set the rules for non-standards track documents, as it explicitly says in Section 2.1. It is therefore incorrect to conclude from a lack of explicit mention of a mechanism in RFC 2026 that it is impermissible to publish an obsolete specification Historic without going through the standards track. There is a precedent, by the way: RFC 2341. Note that it postdates RFC 2026. //cmh ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-narten-iana-considerations-rfc2434bis-02.txt
On Fri, 15 Jul 2005, Brian E Carpenter wrote: Scott Bradner wrote: Sam Hartman wrote: would it be reasonable to just say that we are going to always last call IETF review documents? Personally I'd approve of this option unless people think it is too restrictive. works for me (assuming that you include non-IETF documents when you say IETF review documents) In which case, what you last call is not the document itself but what the IETF intends to say about it, and do about the related IANA action. That being so, I think we now have running code proof that this is what the community wants. To make sure I understand what is being said here, is the proposal that a Last Call would be required for the policies labelled IETF Review and IESG Approval? That seems reasonable to me. And if a last call requirement is added, I don't think there is a reaon any more to change the name to IETF Review from IETF Consensus. I would be less supportive of a proposal to require Last Call in connection with the Specification Required and RFC Required assignment policies. That seems too heavyweight. However, I do think that it would be reasonable to require that the supporting documents be reviewed by a designated expert to verify that it they are sufficiently clear to make possible interoperability between independent implementations. //cmh ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
On Mon, 11 Jul 2005, Paul Hoffman wrote: At 8:15 PM +0200 7/11/05, Brian E Carpenter wrote: Paul Hoffman wrote: At 5:15 PM +0200 7/6/05, Brian E Carpenter wrote: RFC 2434 doesn't discuss null IANA sections at all. RFC2434bis does discuss them, and we will need to form consensus about whether the RFC Editor is required to retain them, as we discuss RFC2434bis. I don't see any discussion of the RFC Editor retaining null IANA sections in RFC2434bis, which is good. It is a completely silly idea. An RFC should contain useful, long-lasting information. The fact that a particular document didn't require IANA action is not useful unless it is surprising, and if it is surprising, the section should not be null. I respectfully disagree. I think that someone implementing or deploying a given specification may well wonder whether any IANA-assigned values are relevant, and the absence of a null section in an RFC doesn't help with that. But neither does a section that says there are no new values registered. The presence of a null section only says this document didn't cause any new registrations by its publication. A section that says here are the IANA registries that are relevant to this document would be useful to that implementer. We have never tried that, and I suspect it would take a lot of energy and thinking to do so. When this issue came up in the context of review guidelines for MIB documents, the MIB Doctors attempted to craft recommendations that would achieve precisely this. The results are in Section 3.5 of draft-ietf-ops-mib-review-guidelines-04.txt, which is now in the RFC Editor's queue awaiting publication as a BCP. Maybe this can serve as a running code template of what to do in other cases. On Tue, 12 Jul 2005, Thomas Narten wrote: All implementation-necessary constants should be in the RFC. That is a given. But they typically already will be even if the IANA considerations is effectively: This document makes no new IANA registrations. (i.e., when publishing an revised/updated Proposed Standard) I'm somewhat torn on how much to leave in the final RFC, especially if a statement (like the above) seems to contain little information. For the record, I am strongly opposed to such statements remaining in published RFCs, and it will be noted that the text in Section 3.5.3 of draft-ietf-ops-mib-review-guidelines-04.txt specifically recomments that such statements be included in drafts as editor's notes that are to be removed upon publication. However, the guidelines also recommend that text describing the IANA-registered values used (with the names of the registries where they reside) remain in the final published document. Continuing to quote from Thomas Narten's message of Tue, 12 Jul 2005: But from experience, I'll point out that anyone that has ever tried to reconstruct the history for a particular registry by looking at RFCs knows this can be extremely challenging. Including explicit notes that say seemingly little can speed up this process. Unfortunately, even with good IANA web pages, its sometimes necessary to go back through the RFC trail to figure out what is really going on. One question of this nature did arise in the first practical application of the recommendations in Section 3.5.3 of draft-ietf-ops-mib-review-guidelines-04.txt, viz.: % The IANA has reviewed the following Internet-Draft which is in % Last Call: draft-ietf-adslmib-gshdslbis-10.txt, and has the % following with regards to the publication of this document: % % We understand this document to not request any NEW IANA Action. % Should the reference for transmission number 48 for % hdsl2ShdslMIB be changed to become this document or should the % reference remain [RFC3276]? After some discussion the policy that the MIB Doctors recommended that the original reference be retained (i.e., no change to current practice). The reasoning was that this is less work for the IANA than making an update, and if the registries consistently point to the the document responsible for the _initial_ assignment, one can always work through the chain of RFC updates if there is a need to reconstruct the history (this assumes of course that the RFCs state what parameters they use and in which registries they can be found). Mike Heard ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC 2434 term IESG approval
On Fri, 8 Jul 2005, Robert Elz wrote: The relevant part is from section 2, basicly all of page 5 of the doc. ... Everything between is about documentation requirements, just read them ... ... New assignments must be approved by the IESG, but there is no requirement that the request be documented in an RFC (though the IESG has discretion to request documents or other supporting materials ... This does not say that the _only_ criterion that can be used by the IESG as a condition for approval of the assignment is that there be adequate documentation. Nor, in my opinion, does anything in the rest of the document imply that. ps: I believe this is my last word on this topic. Mine too. //cmh ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
On Thu, 7 Jul 2005, Brian E Carpenter wrote: RFC 2434 doesn't discuss null IANA sections at all. Right. The requirement for null IANA Considerations sections first appeared in the May 2004 version of http://www.ietf.org/ID-Checklist.html, without prior notice to the community. RFC2434bis does discuss them, and we will need to form consensus about whether the RFC Editor is required to retain them, as we discuss RFC2434bis. Which we need to do fairly soon. In what venue will this discussion take place? While I can understand the value (to the IANA) of a null IANA Considerations section in an Internet Draft, I'm strongly opposed to having them appear in published documents. Mike Heard ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC 2434 term IESG approval
On Thu, 7 Jul 2005, Robert Elze wrote: The question is what the words in 2434 (to which 2780 refers) actually mean. To me, and apparently to some others, it is clear that 2434 is all about what amount of documentation is required to get IANA to register an option, and who gets to judge that documentation. There's no suggestion in 2434 that anything else should be subject to scrutiny. Read the whole doc, not just the two sentences that directly apply in isolation. I have read the whole doc, and I am unable to understand how you (and those others) come to that conclusion _based on the words that are actually in the document_. Would it be unreasonable to ask that you point to some text in the document to support your claim? Or lacking that, to point to some publically archived discussion (e.g. last call comments) that support your position? Mike Heard ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
http://www.ietf.org/WG-WEB-Mail.html
I see that http://www.ietf.org/WG-WEB-Mail.html, which used to point to HTML working group mailing list archives, now points instead to the stuff on the WG charter pages, which consist mostly of text-based FTP archives, and in may cases the links are broken. I know that there were a lot of broken links on the old page, but IMHO this one is much worse. Can we please have the old page back? Mike Heard ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Internal WG Review: Recharter of ADSL MIB (adslmib)
Regarding the following: On Tue, 19 Aug 2003, IESG-Secretary wrote: A new charter for the ADSL MIB (adslmib) in the Operations and Management Area of the IETF is being considered. The draft charter is provided below for your review and comment. The IETF Secretariat ADSL MIB (adslmib) - + lines with a + sign are new text - lines with a - sign will be removed from charter Description of Working Group: [ ... ] - In addition, the group will continue to work on the promotion of the - ADSLMIB, the ADSL Extension MIB, and the HDSL2/SHDSL MIB through the - IETF standards process. I'm curious as to why this is being removed. The WG charter currently lists three RFCs, all at Proposed standard: Definitions of Managed Objects for the ADSL Lines (RFC 2662, August 1999) Definitions of Managed Objects for HDSL2 and SHDSL Lines (RFC 3276, May 2002) Definitions of Extension Managed Objects for Asymmetric Digital Subscriber Lines (RFC 3440, December 2002) Does it mean that the WG will no longer attempt to advance these specifications to Draft Standard? Mike Heard
Re: Address Allocation via Symmetric Amplification of Light
On Wed, 9 Jul 2003, NM Research wrote: P(t) - photons transmitted P(r) - photons received Symmetric Amplification of Light : P(t)P(r) whereby polarity of each and every photon received is equivalent to the polarity of the photon it has been amplified from - while maintaining wavelength and frequency characteristics of the photon transmitted ( the photon it has been amplified from ). The importance of such a system is to sustain results obtained from quantum computing or routing from filters in a system in optical format, allowing for their redirecting to different system memory addresses ( to be received after filteration / confirmation by a photocell ). This thing does not let itself be done. An amplifier with the properties that you specify has to be linear (to maintain the wavelength and frequency characteristics), and the quantum machanical processes through which it must operate will result in an additive Gaussian noise component with a _minimum_ power spectral density of (G-1) h nu per polarization, where G is the power gain, h is Planck's constant, and nu is the frequency. This spoils the sorts of entangled states used in quantum computing. If you wish to discuss this further let's take it off-line, as it is not topical for the IETF list. //cmh
Re: Last Call: Instructions to Request for Comments (RFC) Authors to BCP
On Sun, 16 Mar 2003, Pekka Savola wrote:
2.10 IANA Considerations
[ ... ]
== so, IANA considerations is not needed if you're just requesting a few
values from existing namespaces? It would seem to make sense to have a
section anyway (at least in the I-D's if not necessarily RFC's). In some
namespaces, there are some subsets of a namespace (example: different option
values in IPv6 hop-by-hop/destination options header), so specifying the
requested values somewhere might be useful.
== same in 4.11
I believe that draft-rfc-editor-rfc2223bis-04.txt is just
reiterating what is required by RFC 2434. The current policy
for I-Ds is, however, much as you suggest; see
http://www.ietf.org/ID-nits.html and specifically this part:
* IANA considerations
* Required if IANA has to create a new registry or modify rules for
an existing registry.
* Required if the document requires IANA to assign or update values
in an IANA registry before RFC publication. Note that for the
assignment of just an OID for a MIB or PIB Module, no IANA
Considerations section is required; it is sufficient to request
such via a MIB/SMI or PIB/SPPI comment line,
aka: ::= { mib-2 xxx } -- xxx to be assigned by IANA
* See RFC 2434, and also RFC 2780 in some cases.
If this policy is to be captured in the Instructions to Request for
Comments (RFC) Authors document [do we really need to have _that_
acronym expanded? :) ] it should be noted that the wording that goes
in the RFC should not discuss a request for an assignment (as an I-D
usually does) but an should instead discuss the actual assignment. This
has been done in recently-published RFCs, but inappropriate language has
slipped through in the past (see RFC 2493 for an example).
//cmh
Re: DHCP query/reply using IP directed-broadcast address
Ramkumar Sankar wrote: RS is there any server implementation that replies to client requests using the RS 'subnet directed-broadcast' rather than the limited ip broadcast (i.e all RS 1s)? ... Joe Touch replied: JT What would be the utility in doing so, e.g., given the fact that they're JT no more likely to traverse a router than all-1's (see rfc2644)? That's actually not true ... forwarding of limited broadcasts is categorically forbidden, while forwarding of network-directed broadcasts is permitted but must default to OFF unless specifically allowed. That said, there are other problems with using a network-directed broadcast with DHCP (or BOOTP), namely that a client that does not yet have a subnet mask configured cannot tell the difference between a network-directed broadcast address and a unicast address that happens to have a string of 1's at the tail end. A network-directed broadcast, however, will be sent as a link level broadcast when it arrives at the destination subnet, and according to RFC 1122 Section 3.3.6 should be discarded: A host SHOULD silently discard a datagram that is received via a link-layer broadcast (see Section 2.4) but does not specify an IP multicast or broadcast destination address. Fortunately, DHCP servers do not in general transmit replies to clients to a broadcast address (see the discussion of the BROADCAST flag in RFC 2131 for exceptions) and when they do it's always to a client on an attached subnet (a BOOTP relay agent to speak to clients on a remote subnet). So there is never any reason for a DHCP server to use a network-directed broadcast in preference to all-1s. //cmh
Re: ARPOP_REQUEST with spoofed IP address (joe, turn it off!)
On Sat, 20 Jul 2002, Lars Eggert wrote: Jun-ichiro itojun Hagino wrote: I looked through RFC826 and it seems that the operation performed by Lars was a Bad Thing. RFC826 input processing explicitly suggests us to update ARP cache entry without checking arp operation type. therefore, it is unsafe to transmit ARP_REQUEST with spoofed IP source address - it will overwrite ARP entries of neighbors. I re-read it, too, and you are of course right. It's sad though how easy a DoS attack can be - as easy as mistyping the IP address of your machine. It might be worthwhile to investigate if 826 should be updated. Someone at IETF mentioned that Linux explicitly violates 826 and does not update the local cache based on the contents of spoofed packets, and thus seems more resilient than the BSDs (against this particular bug). How does one tell, in principle, that the source IP address (ar$spa) in an ARP packet is in fact spoofed? //cmh
SNMPv1 and SNMPv2c to HISTORIC
Folks who scan only the titles of last call announcements might want to note that the the actions proposed below will not only elevate SNMPv3 to Standard but will also reclassify SNMPv1 and SNMPv2c as Historic. //cmh -- Forwarded message -- Date: Thu, 17 Jan 2002 09:51:52 -0500 From: The IESG [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: IETF-Announce: ; Cc: [EMAIL PROTECTED] Subject: Last Call: An Architecture for Describing SNMP Management Frameworks to Standard The IESG has received a request from the SNMP Version 3 Working Group to consider publication of the following Internet-Drafts as Standards: o An Architecture for Describing SNMP Management Frameworks draft-ietf-snmpv3-arch-v2-02.txt as a Standard. o Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) draft-ietf-snmpv3-mpd-v2-02.txt o SNMP Applications draft-ietf-snmpv3-appl-v3-01.txt o User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) draft-ietf-snmpv3-usm-v2-rfc2574bis-01.txt o View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP) draft-ietf-snmpv3-vacm-v2-01.txt These are editorial updates to RFCs 2571-2575 respectfully. As part of this action, RFC1157 (A Simple Network Management Protocol (SNMP)) and RFC1901 (Introduction to Community-based SNMPv2) will be reclassified as Historic. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by January 31, 2002. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-snmpv3-arch-v2-02.txt http://www.ietf.org/internet-drafts/draft-ietf-snmpv3-mpd-v2-02.txt http://www.ietf.org/internet-drafts/draft-ietf-snmpv3-appl-v3-01.txt http://www.ietf.org/internet-drafts/draft-ietf-snmpv3-usm-v2-rfc2574bis-01.txt http://www.ietf.org/internet-drafts/draft-ietf-snmpv3-vacm-v2-01.txt
Re: Last Call: Remote Network Monitoring Management InformationBase for High Capacity Networks to Proposed Standard
that the hostTopNHighCapacityTable and nlMatrixTopNHighCapacityTable reside in the HC-RMON-MIB. Second, the DataSource and addressMapSource DESCRIPTION clauses in the revised RMON2-MIB should refer to [RFC2863] rather than [17] as the source of the definition of ifIndex. Mike -- C. M. Heard [EMAIL PROTECTED]
Web archive for IETF list off-line
Hello, The web archive for this list has not been updated since February 6th, and e-mails to [EMAIL PROTECTED] have brought no response ... who is it that should be informed? //cmh
Re: interception proxies
On Wed, 12 Apr 2000, Dick St.Peters wrote: Quoted from RFC791, the IP specification, in the section on loose source routing, page 19 [emphasis added]: If the address in destination address field has been reached and the pointer is not greater than the length, the next address in the source route replaces the address in the destination address field, and the recorded route address REPLACES THE SOURCE ADDRESS just used, and pointer is increased by four. The recorded route address is the internet module's own internet address as known in the environment into which this datagram is being forwarded. An end-to-end-inviolate source address is not a required part of the IP spec. The authors of the standard had the vision to foresee that rewriting the source address might be desireable under some circumstances. They were off target about when this might be used, but they designed a protocol flexible enough to encompass things they could not foresee. I think you have misunderstood what the RFC intended to say. The "source address" being replaced is the entry in the LSRR option that is being written into the destination field, not the source address in the IP header, which is supposed to remain constant throughout its journey. Anyway, a source route option was intended to be something that the originating host puts into the datagram, and so the destination address rewriting that does happen is being done by explicit request of the originating host. That's quite different from what an interception proxy does, isn't it? C. M. Heard [EMAIL PROTECTED]
Re: IP mapping into SONET/SDH
On Sat, 4 Mar 2000, Harpreet Chohan wrote: Does anybody know of any stds for direct IP mapping into a SONET/SDH payload (SPE) ? Thanks in advance. That question probably should be addressed to T1X1.5, which is the ANSI-accredited subcommittee with the charter to define SONET payload mappings. As far as I am aware, there is nothing currently standardized nor any ongoing work regarding a direct mapping of IP. I believe that the closest thing now standardized is the HDLC-over-SONET mapping that is used for PPP over SONET (see RFC 2615) and frame relay over SONET. There was some recent work on defining an Ethernet-over-SONET mapping, but I don't know its status. For further information check the T1X1.5 file archive on the committee T1 web site at http://www.t1.org/. Mike
