Re: [mpls] Last Call: draft-ietf-mpls-tp-framework (A Framework forMPLS in Transport Networks) to Informational RFC
3.4.1 says The data plane behaviour of MPLS-TP is the same as the best current practise for MPLS. This includes the setting of the S-Bit. Without a reference, or any detail, I think this can only muddy the waters. How do I know that your best practice is my best practice, or his? Tom Petch - Original Message - From: The IESG iesg-secret...@ietf.org To: IETF-Announce ietf-annou...@ietf.org Cc: m...@ietf.org Sent: Wednesday, April 07, 2010 4:33 PM Subject: [mpls] Last Call: draft-ietf-mpls-tp-framework (A Framework forMPLS in Transport Networks) to Informational RFC The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'A Framework for MPLS in Transport Networks ' draft-ietf-mpls-tp-framework-11.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 2010-04-21. 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-ietf-mpls-tp-framework-11.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=18027rf c_flag=0 ___ mpls mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-mpls-tp-framework (A Framework forMPLS in Transport Networks) to Informational RFC
I have reservations about the readiness of this I-D. The technical content looks ok, but the process by which it has been arrived at gives me pause. It is a crucial document for MPLS-TP, perhaps the most important after the requirements ones, like, say, RFC3411 for SNMP. This Last Call is on -11 which shows substantial changes from -10 (eg in S3.4) and, despite assiduously tracking the list, I am unsure where these changes have come from. I do not see them discussed, I do not see any consensus declared for (or against) them nor is there any explanation in the I-D itself. The topics covered include some that have provoked considerable debate, over the past two years, involving hundreds of e-mails, including a sequence where several exceeded one Megabyte in size each. Yet, again, I have not seen any consensus declared on the list on most of these topics. The topics I have in mind include; what is MPLS-TP? Is it a layer network, in the G.805/G.800 sense, a set of such layers or what? (and saying it is a Profile has no meaning until the word 'Profile' has been defined in this context). S3.1 of this I-D, like its predecessor, talks variously of 'MPLS-TP network', MPLS-TP layer network' and 'MPLS-TP server' which I find less than clear. How does MPLS-TP relate to MPLS? My sense is that it is a subset of a superset, a superset because MPLS lacks, eg, adequate OAM, a subset to make it as simple as possible but not simpler. (Again, simply saying 'Profile' is really only tautology. Are features in or out? ECMP, NNI, PHP, multiple QoS? I think that some of these are still being debated as the Working Group Last Call proceeds in parallel with this Last Call. S-bit; how many allowed in the stack; I think that the consensus is one, but then what does it mean, and what happens to the meaning it would have had when there were more than one? MIP; where and how many? It is not that a view could not be formed on some of these issues from reading the I-D, but where does that view come from? Not, as far as I can see, from any IETF WG list. Tom Petch - Original Message - From: The IESG iesg-secret...@ietf.org To: IETF-Announce ietf-annou...@ietf.org Cc: m...@ietf.org Sent: Wednesday, April 07, 2010 4:33 PM Subject: [mpls] Last Call: draft-ietf-mpls-tp-framework (A Framework forMPLS in Transport Networks) to Informational RFC The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'A Framework for MPLS in Transport Networks ' draft-ietf-mpls-tp-framework-11.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 2010-04-21. 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-ietf-mpls-tp-framework-11.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=18027rf c_flag=0 ___ mpls mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Public musing on the nature of IETF membership and employmentstatus
- Original Message - From: Brian E Carpenter brian.e.carpen...@gmail.com To: Melinda Shore sh...@arsc.edu Cc: ietf@ietf.org Sent: Tuesday, April 06, 2010 11:51 PM Subject: Re: Public musing on the nature of IETF membership and employmentstatus On 2010-04-07 05:57, Melinda Shore wrote: On Apr 6, 2010, at 9:56 AM, Andrew Sullivan wrote: I thought we didn't have members? I've always liked to refer to people doing work here as participants for exactly that reason. Right. Or contributors when they contribute and therefore subject themselves to our IPR rules. BTW please look at the paragraph headed Participation at http://www.ietf.org/newcomers.html, which I drafted. Do people agree with that summary? no:-( I think that the information is there but in the wrong order. Were I new, I would probably disconnect after the first paragraph; who cares about the structure (at least at this stage)? Tom Petch Brian ___ 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-ietf-tls-renegotiation (Transport Layer Security(TLS) Renegotiation Indication Extension) to Proposed Standard
Since this last call was issued, there have been a further 340 messages posted to the TLS list about how to tackle this topic, a degree of activity some I-Ds may not see in their entire life cycle. This does suggest to me that consensus may yet to be reached on the best way forward for this topic and as such, the I-D is not yet ready to progess. Tom Petch - Original Message - From: The IESG iesg-secret...@ietf.org To: IETF-Announce ietf-annou...@ietf.org Cc: t...@ietf.org Sent: Monday, November 30, 2009 4:37 PM Subject: Last Call: draft-ietf-tls-renegotiation (Transport Layer Security(TLS) Renegotiation Indication Extension) to Proposed Standard The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Transport Layer Security (TLS) Renegotiation Indication Extension ' draft-ietf-tls-renegotiation-01.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 substantive comments to the ietf@ietf.org mailing lists by 2009-12-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. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-tls-renegotiation-01.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=19412rf c_flag=0 ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport LayerSecurity (TLS) Renegotiation Indication Extension) to Proposed Standard
I think that Stefan sums up the state of play well (after some 1,000 posts to the TLS list with the number still rising steadily). The IETF Last Call was premature, capricious even, given the ongoing debates on the TLS list. Technically, either draft will do but the mrex draft is superior in what I regard as system issues, in the likelihood of being deployed in such a way that it works. Tom Petch - Original Message - From: Stefan Santesson ste...@aaa-sec.com To: David-Sarah Hopwood david-sa...@jacaranda.org; ietf@ietf.org Cc: t...@ietf.org Sent: Tuesday, December 01, 2009 7:31 PM Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport LayerSecurity (TLS) Renegotiation Indication Extension) to Proposed Standard On 09-12-01 12:19 AM, David-Sarah Hopwood david-sa...@jacaranda.org wrote: The IESG wrote: The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Transport Layer Security (TLS) Renegotiation Indication Extension ' draft-ietf-tls-renegotiation-01.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 substantive comments to the ietf@ietf.org mailing lists by 2009-12-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. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-tls-renegotiation-01.txt I believe the decision to take this draft to Last Call was premature, and that further discussion in the WG is necessary before deciding whether to adopt draft-ietf-tls-renegotiation or an alternative. I agree to this. I will support the current draft-ietf-tls-renegotiation-01 if that is choice of direction in the end of this last call. However, the TLS working group has also been working hard to evaluate whether an alternative solution could provide better integration with legacy deployments and provide better security properties. This last call was initiated before the WG members had any real chance to express their choice of direction. For the sake of completeness, the alternative approach was updated and posted today and is available from: http://tools.ietf.org/html/draft-mrex-tls-secure-renegotiation-02 It is my opinion that this draft offers two noticeable advantages over draft-ietf-tls-renegotiation-01 1) By not sending verify data over the wire, this draft allows peers to fail-safe as a result of implementation errors in cases where a corresponding implementation error of draft-ietf-tls-renegotiation-01 leads to a fail-unsafe situation. 2) It offers a solution where servers never have to parse data from TLS extensions. This offers advantages when deploying the fix for legacy implementations. I would support if the choice of draft-mrex-tls-secure-renegotiation-02 as the selected solution to the problem, or an update of draft-ietf-tls-renegotiation-01 which incorporate the updated handshake message hash calculation of draft-mrex-tls-secure-renegotiation-02 as an alternative to sending verify data in the RI extensions. /Stefan ___ 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: Request for community guidance on issue concerning a futuremeeting of the IETF
- Original Message - From: Stephen Farrell stephen.farr...@cs.tcd.ie Sent: Monday, September 21, 2009 2:03 PM I just filled in the form. The main potential issue I would have with such a meeting is whether or not we'd have a normal meeting network with normal Internet access. It was the issue of Internet access that first occurred to me. The agreement talks of things which are within the control of the Client where the Client is the Host of the meeting and so presumably providing Internet access and all that goes with it, including, presumably, what is needed in the way of monitoring to ensure that the Client is able to fulfil their obligations. Tom Petch. If there's anything that'd be different about the meeting network and/or access to the Internet, then I think the IAOC MUST bring that to the community before making any decision. If there's to be nothing different, then I think the IAOC would be wise to be crystal-clear about that. Absent that information, I don't think that the survey is useful and it shouldn't be used as the basis for a positive decision. The reason I think this is important is that we can only speculate about reactions to microphone statements, but we can know in advance about any networking restrictions. If we cannot access the Internet as usual then I would be against such a meeting since it would mean participants could not do their work as usual. I have yet to see a clear statement on the above. If this is not yet resolved, that would also be useful to know, Stephen. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Soliciting Comments: draft-oreirdan-mody-bot-remediation
Jason When I saw the announcement of this I-D, I thought that the asrg Working Group would be well placed to comment on this, since it has already had a lot of discussion about bots and what to do with them:-) You may be familiar with the I-Ds on blacklists that this WG has produced. Tom Petch - Original Message - From: Livingood, Jason jason_living...@cable.comcast.com To: ietf@ietf.org Sent: Tuesday, September 15, 2009 10:59 PM Subject: Soliciting Comments: draft-oreirdan-mody-bot-remediation I¹m looking for direct comments on an updated document, Recommendations for the Remediation of Bots in ISP Networks, available at http://tools.ietf.org/html/draft-oreirdan-mody-bot-remediation-03. I¹m asking here as this doesn¹t really fit neatly into any existing WGs. (Though we¹ll be posting shortly to the SAAG list.) Thanks Jason ___ 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: draft-housley-iesg-rfc3932bis and theoptional/mandatory nature of IESG notes
Original Message - From: John C Klensin john-l...@jck.com Sent: Monday, August 31, 2009 4:33 PM --On Monday, August 31, 2009 16:29 +0300 Jari Arkko jari.ar...@piuha.net wrote: I would like to get some further input from the community on this draft. ... And now back to the input that I wanted to hear. I would like to get a sense from the list whether you prefer (a) that any exceptional IESG note is just a recommendation to the RFC Editor or (b) something that is always applied to the published RFC. Please reply before the next IESG meeting on September 10. Some e-mails on this topic have already been sent in the Last Call thread -- I have seen those and there is no need to resend. a) is my preference. I am not persuaded by references to history, that the RFC Editor function came first - cuckoos do take over nests (not that the IETF is a cuckoo:-) I do think it is a question of checks and balances, that being able to submit and have reviewed an RFC, independently of the views of the current IESG, is a valuable outlet for ideas and not one I want to see compromised. John, below, outlines an appeal mechanism which allows the IESG to take the issue to the IAB should it consider that justified and, assuming you agree that that is possible, then I see no case for anything other than a) Tom Petch Jari, I've said this before, but not during the recent Last Call, so, to get a note on the record... Any IESG note or comment, exceptional or otherwise, has always (always == since the IESG was created and long before it started writing notes) been an recommendation to the RFC Editor. That position is reflected in long-term precedent, in RFC 4844, and in the new RFC Editor Model document. Under the new model, should the RFC Editor decide to not accept a proposed IESG note, the IESG can raise the issue with the RSE and, if necessary, with the IAB, presumably causing a wider community review of the proposed note itself. That level of protection (which goes beyond that historically available) should be both necessary and sufficient for the IESG's purposes. Procedurally, should the IESG wish to change that position, I believe it would require the approval of the IAB (because it changes the RFC Editor role and relationship) and a review of the Headers and Boilerplates document, the RFC Editor Model document, and perhaps some of the statements of work associated with the new RFC Editor contracts and appointments. I have reason to believe that the IAB would insist on community review before granting such approval, so trying to change things in this area at this late date is not consistent with rapid progress and may be inconsistent with having a fully-functional RFC Editor function in place at the beginning of January. More broadly, as the community has discussed extensively, the IESG should not have the right to deprecate or denigrate the contents of any document from another stream without broad community consensus. Nothing in any community-approved IETF procedural document from RFC 2026 forward gives the IESG such authority (or authority for doing much of anything else other than steering/managing) without community approval and consensus. Even the claim in the original version of 3932 that a document has not been reviewed in the IETF is inappropriate unless such review has actually not occurred (whether or not consensus was reached). So I believe that your clarifying change was, in fact, editorial and that it should remain. ... regards, john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Let's be careful with those XML submissions to IANA
Looking at RFC5102 (IPFIXinfo), it, like many RFC, has normative definitions in the body of the document and a non-normative appendix, which, since it brings the definitions together, is easier and so more likely to be used. Indeed, the IANA considerations, s.7, tell IANA to register the non-normative appendix which is fine as long as the two are in step but what happens when they are not? In fact, they do differ slightly. The IANA considerations register URI: urn:ietf:params:xml:ns:ipfix-info-15 XML: See Appendix B for this document. whereas Appendix B says that the name is schema targetNamespace=urn:ietf:params:xml:ns:ipfix-info which is what is in the IANA registry. IANA have used Appendix B and so have got the right answer by doing the 'wrong' thing. (Interestingly the last I-D of this document had, in Appendix B, schema targetNamespace=urn:ietf:params:xml:ns:ipfix-info-10 xmlns:ipfix=urn:ietf:params:xml:ns:ipfix-info-10) What if an error is discovered in the body of the document (I have not looked at it in any detail) and an erratum is raised against it? Does this implicitly request IANA to update the registry? Does it matter whether the erratum is against the appendix or the body of the document? (I think this is called the distributed database problem:-) Tom Petch ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: secdir review of draft-ietf-netconf-partial-lock-09.txt
Stephen As Dan and Bert think and believe, I guess #1. My experience with other technologies is that where enterprise systems are involved, then authorisation is likely to be powerful and comprehensive (and proprietary) but where network and operators are involved, then this is not so. Tom Petch - Original Message - From: Romascanu, Dan (Dan) droma...@avaya.com To: Stephen Hanna sha...@juniper.net; Tom.Petch sisyp...@dial.pipex.com; sec...@ietf.org; ietf@ietf.org; draft-ietf-netconf-partial-l...@tools.ietf.org Sent: Thursday, August 13, 2009 1:10 PM Subject: RE: secdir review of draft-ietf-netconf-partial-lock-09.txt Steve, I believe that the situation is #1 below. Dan -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Stephen Hanna Sent: Thursday, August 13, 2009 1:53 PM To: Tom.Petch; sec...@ietf.org; ietf@ietf.org; draft-ietf-netconf-partial-l...@tools.ietf.org Subject: RE: secdir review of draft-ietf-netconf-partial-lock-09.txt Tom, Thanks for responding to my comments. Allow me to respond. You wrote: As a participant in netconf, I see authorization as one of those topics which the Working Group sees as necessary but cannot be tackled just yet. As RFC4741 says, This document does not specify an authorization scheme, as such a scheme should be tied to a meta-data model or a data model. and as yet, there is no data model; hence, no authorization, not yet, nor, IMHO, for some time to come. This is just the sort of background information that a WG participant would know but that a secdir reviewer would not. Please allow me to ask a clarifying question. You say that there is no authorization yet. I think that could mean several things: 1) Existing NETCONF implementations implement authorization, ensuring that each user gets an appropriate and perhaps different level of access to the database. However, there are no standards for the manner in which authorization is performed or configured. 2) Existing NETCONF implementations require authentication but generally just give complete read-write access to the database to all authenticated users. 3) Existing NETCONF implementations do not require authentication. Anyone with network access has complete, unfettered access to the database and can modify it at will. Could you tell me which of these meanings is most accurate? Of course, it could be a mix of these but I'd like to get your real-world assessment of the state of the NETCONF world. If the answer is 3), we have a serious problem! If the answer is 1) or 2), that's acceptable in my view. Now on to the language in the draft. My comment was relating to this quote from the Security Considerations: Only an authenticated and authorized user can request a partial lock. I'm afraid that this statement is not justified if there is no normative text requiring implementations to comply. I suggest that normative text be added to at least require authentication. With such text, the statement above could be justified. Requiring that levels of authorization be implemented is less important in this application. And standardizing the manner in which authorization is performed or configured (which I think is your concern with respect to the lack of a data model) is really not important at all unless NETCONF customers or vendors decide that it is. Standardizing an authorization policy format is a tremendously challenging task for any protocol and often not necessary. I hope that this helps you address my comments in a reasonable and achievable manner. The intent of secdir comments is not to impose unreasonable requirements. It is to point out issues that might not be evident to someone who is not a security expert. Thanks, Steve -Original Message- From: Tom.Petch [mailto:sisyp...@dial.pipex.com] Sent: Thursday, August 13, 2009 4:00 AM To: Stephen Hanna; sec...@ietf.org; ietf@ietf.org; draft-ietf-netconf-partial-l...@tools.ietf.org Subject: Re: secdir review of draft-ietf-netconf-partial-lock-09.txt - Original Message - From: Stephen Hanna sha...@juniper.net To: i...@ietf.org; sec...@ietf.org; ietf@ietf.org; draft-ietf-netconf-partial-l...@tools.ietf.org Sent: Monday, August 10, 2009 4:28 PM 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. This document defines optional partial-lock and partial-unlock operations to be added to the NETCONF protocol. These operations are used to lock only part of a configuration datastore, allowing multiple management sessions to modify the configuration of a device
Re: secdir review of draft-ietf-netconf-partial-lock-09.txt
- Original Message - From: Stephen Hanna sha...@juniper.net To: i...@ietf.org; sec...@ietf.org; ietf@ietf.org; draft-ietf-netconf-partial-l...@tools.ietf.org Sent: Monday, August 10, 2009 4:28 PM 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. This document defines optional partial-lock and partial-unlock operations to be added to the NETCONF protocol. These operations are used to lock only part of a configuration datastore, allowing multiple management sessions to modify the configuration of a device at a single time. The Security Considerations section of the document highlights the risk that a malicious party might employ partial locks to impede access to a device's configuration. Therefore, it states Only an authenticated and authorized user can request a partial lock. Unfortunately, I cannot find any normative text (MUST) that supports this statement. The NETCONF spec (RFC 4741) says NETCONF connections must be authenticated but this is not clearly normative. Perhaps a NETCONF expert can point to some normative text requiring authentication and authorization for any party requesting a partial lock. If not, I suggest that such normative text be added to the partial-lock specification. As a participant in netconf, I see authorization as one of those topics which the Working Group sees as necessary but cannot be tackled just yet. As RFC4741 says, This document does not specify an authorization scheme, as such a scheme should be tied to a meta-data model or a data model. and as yet, there is no data model; hence, no authorization, not yet, nor, IMHO, for some time to come. In the light of this, I am not sure what adding a normative statement to this I-D would do; delay publication sine die? Tom Petch Another security concern that I have related to the partial-lock operation is that the configuration might become inconsistent if one manager changes one part of a datastore at the same time that another manager changes another part. The resulting inconsistency could have security implications. For example, an organization might have a rule that either the firewall or the intrusion detection features must be enabled on a device. If one manager might lock intrusion detection configuration, check that the firewall is enabled, and then disable intrusion detection. Another manager might lock the firewall configuration, check that intrusion detection is enabled, and then disable the firewall. If those operations were interleaved, they could result in a violation of policy. To address this concern, I suggest that the draft contain a warning that parallel operations are tricky and should be carefully considered. Sometimes, it may be necessary to lock a portion of the datastore that will not be modified, just to ensure the datastore remains consistent and compliant with policy. Of course, a human administrator using a GUI could easily run into this same problem if the human does not have the ability to control configuration locks. The human might look at the firewall configuration to make sure that it's enabled and then switch to another section of the display to disable the intrusion detection function. If the management console only locks the datastore to execute the administrator's request to disable intrusion detection, overlapping operations from another administrator could result in a bad configuration. This problem can arise even without the partial lock operation. Probably the best that can be done here is to include language warning of this sort of problem. Warning human administrators that someone else is also editing the device should help and giving these administrators the ability to easily communicate with each other to coordinate their work would also probably help. Here are a few minor issues: * At the end of section 2.1.1.2, the comma in the last sentence is superfluous. * In section 2.1.1.3 in the sentence Manager A terminates it's session, the apostrophe should be removed. * In section 2.4.1, I think that the sentence that begins with If someone later creates a new interface would be clearer if the second comma was changed to so. * Later in section 2.4.1, the sentence that begins with A NETCONF server MUST should instead start with A NETCONF server that supports partial locks MUST. I think that paragraph should end with all of the overlapping locks are released not all of the locks are released. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org
Re: Last Call: draft-ietf-mpls-tp-requirements (MPLS-TP Requirements)toProposed Standard
- Original Message - From: Adrian Farrel adr...@olddog.co.uk To: Tom.Petch sisyp...@dial.pipex.com Cc: ietf ietf@ietf.org Sent: Tuesday, July 21, 2009 11:36 PM Subject: Re: Last Call: draft-ietf-mpls-tp-requirements (MPLS-TP Requirements)toProposed Standard Hi Tom, a) The security section of this I-D says see[I-D.ietf-mpls-mpls-and-gmpls-security-framework] which is an informative reference. I believe that security should be normative, not informative, even in this, a requirements (as opposed to a protocol) draft. I hear you. Security is fundamental. draft-ietf-mpls-mpls-and-gmpls-security-framework is targetted as an informational RFC because it does not define any protocol mechanisms. It is a catalog of existing protocol security mechanisms and reports the current state of the art. In the light of this, do you believe it is necessary to create a downref from a requirements document to an informational document? Could this be handled by strenghtening the text in the security requirements section? I don't see a good solution to this. I think the text should be strengthened; at present, it seems a little casual, not quite serious enough. The referenced I-D is massive, contains much that I suspect will not be relevant to MPLS-TP and seems an unsatisfactory companion to this I-D. I think that draft-mpls-tp-oam-requirements does a much better job here, and would like to see something similar, highlighting the key threats (and for MPLS-TP, I do not know what they are:-( As luck would have it, a couple of people have just posted draft-fang-mpls-tp-security-framework-00.txt This is in early days, but I think that draft-ietf-mpls-tp-requirements should be able to defer to it for security in the same non-normative way that it defers to draft-mpls-tp-oam-requirements for OAM and draft-mpls-tp-nm-requirements for network management. OK Tom Petch Cheers, Adrian b) The terminology section of this draft overlaps with that in an Informational Reference [I-D.helvoort-mpls-tp-rosetta-stone] A Thesaurus for the Terminology used in MPLS-TP drafts/RFCs and ITU-T's Transport Network Recommendations. (now republished as a Working Group Draft) which will doubtless progress to an RFC but as Informational. I see this as problematic; the two may be in step now but I am doubtful that they will be as and when this last gets amended in the course of its development. The mpls-tp list has seen some vigorous debate already about the meaning of terms (eg associated bidirectional, AIS). Sometimes, the same concept has a different term in IETF versus ITU-T (versus IEEE) while the same term may also be used for a different concept. RFC4397 is the product of a similar, earlier issue and is another potential overlap. The definitions in this I-D may be normative for this I-D but if they diverge from definitions in other I-Ds, we are storing up problems for the future. On balance, I believe that this rosetta-stone should be a Normative Reference, ideally removing the overlapping definitions. You are right, of course, that terminology needs to be consistent. But making a normative reference to the Rosetta Stone draft would put us into a nasty non-publication loop because that draft can't be published until everything else is completely stable, and nothing else can be published with a normative reference to an unpublished I-D. Would it work for the authors to take a long hard look at the terms they have to: 1. make sure they only define terms they really need and cannot defer to the Rosetta Stone 2. ensure the Rosetta Stone is up-to-date and includes pointers out to the initial definitions so that the terms do not get updated in the future? That sounds like a viable solution. My sense is that because this has come first, or at least early on, it has accumulated definitions it does not need. Technically, I fear we will regret not producing the Rosetta Stone first, but politically, I suspect that that is unrealistic and so we have to do as you suggest. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-mpls-tp-requirements (MPLS-TP Requirements)toProposed Standard
- Original Message - From: Adrian Farrel adr...@olddog.co.uk To: Tom.Petch sisyp...@dial.pipex.com Cc: ietf ietf@ietf.org Sent: Monday, July 20, 2009 5:47 PM Subject: Re: Last Call: draft-ietf-mpls-tp-requirements (MPLS-TP Requirements)toProposed Standard Thanks for the input Tom, I see some difficulties with the references in this I-D. a) The security section of this I-D says see[I-D.ietf-mpls-mpls-and-gmpls-security-framework] which is an informative reference. I believe that security should be normative, not informative, even in this, a requirements (as opposed to a protocol) draft. I hear you. Security is fundamental. draft-ietf-mpls-mpls-and-gmpls-security-framework is targetted as an informational RFC because it does not define any protocol mechanisms. It is a catalog of existing protocol security mechanisms and reports the current state of the art. In the light of this, do you believe it is necessary to create a downref from a requirements document to an informational document? Could this be handled by strenghtening the text in the security requirements section? I don't see a good solution to this. I think the text should be strengthened; at present, it seems a little casual, not quite serious enough. The referenced I-D is massive, contains much that I suspect will not be relevant to MPLS-TP and seems an unsatisfactory companion to this I-D. I think that draft-mpls-tp-oam-requirements does a much better job here, and would like to see something similar, highlighting the key threats (and for MPLS-TP, I do not know what they are:-( b) The terminology section of this draft overlaps with that in an Informational Reference [I-D.helvoort-mpls-tp-rosetta-stone] A Thesaurus for the Terminology used in MPLS-TP drafts/RFCs and ITU-T's Transport Network Recommendations. (now republished as a Working Group Draft) which will doubtless progress to an RFC but as Informational. I see this as problematic; the two may be in step now but I am doubtful that they will be as and when this last gets amended in the course of its development. The mpls-tp list has seen some vigorous debate already about the meaning of terms (eg associated bidirectional, AIS). Sometimes, the same concept has a different term in IETF versus ITU-T (versus IEEE) while the same term may also be used for a different concept. RFC4397 is the product of a similar, earlier issue and is another potential overlap. The definitions in this I-D may be normative for this I-D but if they diverge from definitions in other I-Ds, we are storing up problems for the future. On balance, I believe that this rosetta-stone should be a Normative Reference, ideally removing the overlapping definitions. You are right, of course, that terminology needs to be consistent. But making a normative reference to the Rosetta Stone draft would put us into a nasty non-publication loop because that draft can't be published until everything else is completely stable, and nothing else can be published with a normative reference to an unpublished I-D. Would it work for the authors to take a long hard look at the terms they have to: 1. make sure they only define terms they really need and cannot defer to the Rosetta Stone 2. ensure the Rosetta Stone is up-to-date and includes pointers out to the initial definitions so that the terms do not get updated in the future? That sounds like a viable solution. My sense is that because this has come first, or at least early on, it has accumulated definitions it does not need. Technically, I fear we will regret not producing the Rosetta Stone first, but politically, I suspect that that is unrealistic and so we have to do as you suggest. Tom Petch Cheers, Adrian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-mpls-tp-requirements (MPLS-TP Requirements) toProposed Standard
I see some difficulties with the references in this I-D. a) The security section of this I-D says see[I-D.ietf-mpls-mpls-and-gmpls-security-framework] which is an informative reference. I believe that security should be normative, not informative, even in this, a requirements (as opposed to a protocol) draft. b) The terminology section of this draft overlaps with that in an Informational Reference [I-D.helvoort-mpls-tp-rosetta-stone] A Thesaurus for the Terminology used in MPLS-TP drafts/RFCs and ITU-T's Transport Network Recommendations. (now republished as a Working Group Draft) which will doubtless progress to an RFC but as Informational. I see this as problematic; the two may be in step now but I am doubtful that they will be as and when this last gets amended in the course of its development. The mpls-tp list has seen some vigorous debate already about the meaning of terms (eg associated bidirectional, AIS). Sometimes, the same concept has a different term in IETF versus ITU-T (versus IEEE) while the same term may also be used for a different concept. RFC4397 is the product of a similar, earlier issue and is another potential overlap. The definitions in this I-D may be normative for this I-D but if they diverge from definitions in other I-Ds, we are storing up problems for the future. On balance, I believe that this rosetta-stone should be a Normative Reference, ideally removing the overlapping definitions. Tom Petch Original Message - From: The IESG iesg-secret...@ietf.org To: IETF-Announce ietf-annou...@ietf.org Cc: m...@ietf.org Sent: Thursday, July 02, 2009 11:31 PM Subject: Last Call: draft-ietf-mpls-tp-requirements (MPLS-TP Requirements) toProposed Standard The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'MPLS-TP Requirements ' draft-ietf-mpls-tp-requirements-09.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 substantive comments to the ietf@ietf.org mailing lists by 2009-07-16. 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-ietf-mpls-tp-requirements-09.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=18021rf c_flag=0 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for Comments: Uncoordinated Protocol Development Considered Harmful
I think that the conclusion in s.4, that this is the solution to problems of cooperation, will turn out to be rather rose-tinted in years to come. It reminds me of a Professor of Engineering in my student days, who one year, told us how successful his redesign of a road junction was, relieving congestion all round to the benefit of all. A year later, I heard him again, and this time he concluded that after spending vast sums of money, all he had achieved was to lift the traffic jam 25 feet into the air. I track the mpls-tp list and see two very different styles, of process, of commenting, of consensus (know any other IETF lists where 10 successive posts were each about one Megabyte in size?) which tells me that the differences between ITU-T and IETF have just been moved to another forum. The MEAD team and JWT, and the changes to IETF process, as described in draft-andersson-mpls-tp-process, may be a step forward, but there is still a long way to go before there is a mutually agreeable set of standards which must be the acid test of cooperation. Tom Petch - Original Message - From: IAB Chair iab-ch...@ietf.org To: IETF Announcement list ietf-annou...@ietf.org Cc: mmor...@cisco.com; i...@iab.org; stbry...@cisco.com Sent: Thursday, June 11, 2009 12:07 PM Subject: Call for Comments: Uncoordinated Protocol Development Considered Harmful The IAB intends to publish the following document and invites any comments you might have: Uncoordinated Protocol Development Considered Harmful http://tools.ietf.org/html/draft-iab-mpls-tp-uncoord-harmful-00 Abstract This document identifies various types of damage that may occur without formal coordination and joint development on protocols of mutual interest between standards development organizations. The IAB has selected T-MPLS as recent case study to describe hazard to both the MPLS and Internet architecture as a result of uncoordinated adaptation of a protocol. This experience has resulted in a considerable improvement in the relationship between the two organisations. In particular, this was achieved via the establishment of the Joint working team on MPLS-TP which was the first ever joint ITU/IETF group. In addition, the leadership of the two organisations have agreed to improve inter- organizational working practices so as to avoid conflict in future between ITU-T Recommendations and IETF RFCs. Please provide your feedback before June 28, 2009. For the IAB, --Olaf Kolkman IAB Chair ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: LC summary for draft-ietf-opsawg-operations-and-management
+1 Tom Petch - Original Message - From: SM s...@resistor.net To: David Harrington ietf...@comcast.net; IETF Discussion ietf@ietf.org Cc: Romascanu, Dan (Dan) droma...@avaya.com; ops...@ietf.org Sent: Thursday, June 25, 2009 12:35 AM Subject: Re: LC summary for draft-ietf-opsawg-operations-and-management Hi David, At 13:51 23-06-2009, David Harrington wrote: 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] The problem is not about what your document is not prescribing. It is about how it may be used. In Section 1: This document provides guidelines to help protocol designers and working groups consider the operations and management functionality for their new IETF protocol or protocol extension at an earlier phase. In an Informational document, guidelines provide guidance. In a BCP document, it can be read as the IETF community agrees to adopt these guidelines. In Section 1.2: This document does not impose a solution, or imply that a formal data model is needed, or imply that using a specific management protocol is mandatory. The catch is in the following sentence: Any decision to make a Management Considerations section a mandatory publication requirement for IETF documents is the responsibility of the IESG, or specific area directors, or working groups, and this document avoids recommending any mandatory publication requirements. The IESG could come up with such a requirement for the IETF Stream if this document is published as a BCP. In Section 1.3: The IESG policy to require working groups to write a MIB module to provide manageability for new protocols is being replaced by a policy that is more open to using a variety of management protocols and data models designed to achieve different goals. The insistence on BCP could be seen as a way to set the stage for that. At 13:40 24-06-2009, Eric Rosen wrote: Since assigning responsibilities to the IESG is presumably out of scope of this document, why not shorten this sentence to: This document avoids recommending any mandatory publication requirements I suggest a slight change to the proposed sentence: This document does not recommend any mandatory publication requirements I also suggest publishing the document as Informational. Regards, -sm ___ 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: Proposed Revisions to the IETF Trust Legal Provisions (TLP)
- Original Message - From: Marshall Eubanks t...@americafree.tv To: ietf list ietf@ietf.org; IAB IAB i...@iab.org; IESG i...@ietf.org Cc: Trustees trust...@ietf.org Sent: Tuesday, June 23, 2009 7:32 AM Subject: Proposed Revisions to the IETF Trust Legal Provisions (TLP) The IETF Trustees invite your comments on the proposed revisions to the Legal Provisions Relating to IETF Documents (TLP) policy. The proposed revisions are in rtf, pdf and doc formats and located at: http://trustee.ietf.org/policyandprocedures.html under Draft Policies and Procedures for IETF Documents. This is a summary of the proposed revisions: 2.e -- the review period for TLP changes has been changed from 30 to 14 days, which is consistent with the last-call period for other IETF documents 2.f -- this new language describes the conditions under which the IETF Trust will assume licensing and copyright responsibility for IAB, IRTF and Independent Stream submissions, should the managers of those streams request that it do so. 4.a -- the URL for the list of Code Components has been updated 4.c -- clarifies that the BSD License may not be applied to Code Components that come from IETF Documents as to which the Contributor has prohibited the making of derivative works. I like this change because it also makes it clear that even when 6.c.iii clause is included because RFC5378 rights have not been obtained, yet code can still be modified outside the standards process. The TLP currently in force gives my lay mind the impression that that right had been withdrawn and my query about this last February never got answered. So yes, I like it. Tom Petch 4.e -- this new section clarifies the legend requirements for Code Components that are used in software under the BSD License. In short, the user must include the full BSD License text or a shorter pointer to it (which is set forth in Section 6.d) 6 -- the language regarding placement of legends on IETF Documents has been clarified. Placement on the first page is no longer required, and authority for placement of the legends is with the RFC Editor and IESG. 6.a - the words to IETF have been removed, to enable submission to IAB, IRFT and other streams. 6.b -- a new sentence has been added to the legend that must be placed on all IETF Documents, pointing out the BSD License requirements described in 4.e above and emphasizing that code in IETF Documents comes without any warranty, as described in the BSD License. 6.c -- some minor clean-up edits 6.d -- the BSD legend/pointer described in 4.e above 7.a -- correction of capitalization Please accept this message as a formal request by the IETF Trustees for your review and feedback on the proposed revision to the TLP document. The comment period will end on July 20, 2009. I expect the Trustees will decide on whether to adopt this revision shortly after July 20, 2009. Regards, and thanks in advance, Marshall Eubanks IETF Trust Chair ___ 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: Proposed Revisions to the IETF Trust Legal Provisions (TLP)
Original Message - From: Simon Josefsson si...@josefsson.org Sent: Tuesday, June 23, 2009 5:30 PM John C Klensin john-i...@jck.com writes: Assuming that I'm not the only one who sees the recent patterns as problematic I don't think you are alone with that impression. The process you outline (posting preliminary versions in draft-* form) sounds great to me. M ... I think that one thing that the ipr working group got absolutey right was the decision not to try and craft legally suitable wording for intellectual property rights, rather delegating that task. This sounds like a suggestion to restart the ipr wg, perhaps in the hope of getting a different outcome:-) I would however agree with the suggestion that a complicated (to me as a lay person) document should be accompanied by a non-legally binding lay explanation, eg as to why it is thought suitable to cut the review period from 28 to 14 days, or why a reference to the BSD licence should be thought adequate. Tom Petch I suggested it earlier, and the IETF Trust response was at least not negative to the idea. Hopefully it can be implemented. This would also solve the problem of recording the history of document drafts, and making sure documents are readily available via IETF mirrors even if the main site is down or material is removed from it, which is another concern today. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-opsawg-operations-and-management(Guidelinesfor Considering Operations and Management of NewProtocols and ProtocolExtensions) to BCP
- Original Message - From: Adrian Farrel adr...@olddog.co.uk To: ietf@ietf.org Cc: ops...@ietf.org Sent: Thursday, June 04, 2009 11:58 AM In the discussion of IETF consensus of this document and its position as a BCP or otherwise, can I throw into the melting pot draft-ietf-pce-manageability-requirements-06.txt Yes, a clear concise set of steps to follow when writing an I-D. The other comment I would make on the I-D under Last Call is on the first sentence of the abstract, to whit, New protocols or protocol extensions are best designed with due consideration of functionality needed to operate and manage the protocols. True, but not, I think, addressed by this document. There is plenty in this I-D for the I-D editor but little for the protocol designer. The latter might benefit from advice on how to structure elements of the PDUs and the interchange of PDUs; it may be difficult to know whether or not a network is functioning if there is no keepalive. (A comparable discussion surfaced recently on apps-discuss over the best way to encode lengths). I appreciate that this I-D does not set out to give such advice but think that someone reading the abstract might expect it to. Tom Petch This particular I-D was developed within the PCE working group to apply only in that working group. It covers similar topics, but is more focused on ensuring that the protocols that are developed in PCE are manageable. The I-D has rough WG consensus (or did at the time I stopped being chair a few months ago), but is not mandatory to implement within the WG. It is my opinion that those PCE I-Ds that have taken the draft on board have produced better solutions that will be more successfully implemented and deployed. Cheers, Adrian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF 78 Annoucement
- Original Message - From: Ole Jacobsen o...@cisco.com To: Iljitsch van Beijnum iljit...@muada.com Cc: Harald Tveit Alvestrand har...@alvestrand.no; IETF Discussion ietf@ietf.org Sent: Monday, May 25, 2009 6:09 PM Subject: Re: IETF 78 Annoucement I don't know why you think moving the meeting to June will make more facilities available in Europe. July-August is the traditional vacation season and hence off season for conferences. Precisely, and if facilities include travel, which for me as a potential participant they do, then yes, more is available. When last I used Schipol, it was for a July meeting and, for a one hop flight to another European country, I was told to check in three hours beforehand. This was before the security scares, when a one hour check-in would be lengthy. When I asked why so long, I was told never to use Schipol at a weekend in July; holiday season, always a nightmare. And it was; the check-in queue is etched in my brain still. So May, delightful, June, pleasant, July, nightmare. I wonder if that is why RIPE meet in May. Tom Petch The extreme example might be IETF in Paris which one could argue suffered slightly from the fact that Paris was basically closed for vacation at that time, but I am sure it made it easier to get the convention center and hotel and probably cheaper too. And the closed condition didn't seem to cause anyone to starve etc. 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
The following IPR Declarations may be related to this I-D:
Since about March 2009, most if not all, IETF Last Calls have included the text The following IPR Declarations may be related to this I-D: I assume that this is telling us that there are no IPR Declarations relating to this I-D and that if there were, then they would be listed. My question is, is this a change of practice? I have a folk memory that there has always been a requirement for IETF Last Calls to disclose IPR claims but cannot find anything to support this; eg RFC3979 only requires a statement in the published RFC. Tom Petch ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART LC review of draft-ietf-isms-transport-security-model-12
I am surprised not to have seen more formal reviews of the quartet for isms I-Ds whose Last Call has just finished, updating as they do a Standard, while at the same time introducing a Transport subsystem and model, and also introducing a new (to snmp) way of providing Security. I do not know what or how these reviews are triggered but I would have expected a good deal more than this one and the one that appeared as I was drafting this response, a round dozen even. Tom Petch - Original Message - From: Ben Campbell b...@estacado.net To: i...@hardakers.net; dharring...@huawei.com; General Area Review Team gen-...@ietf.org Cc: j.schoenwael...@jacobs-university.de; ietf@ietf.org Sent: Friday, April 10, 2009 10:05 PM Subject: Gen-ART LC review of draft-ietf-isms-transport-security-model-12 snip ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Transport directorate review of Last Call: draft-ietf-isms-tmsm
Allison inline Tom Petch - Original Message - From: Allison Mankin man...@psg.com To: ietf@ietf.org; i...@ietf.org Cc: TSV Dir tsv-...@ietf.org Sent: Thursday, April 16, 2009 8:57 AM Subject: Transport directorate review of Last Call: draft-ietf-isms-tmsm Transport directorate review of Last Call: draft-ietf-isms-tmsm Transport Subsystem for the Simple Network Management Protocol (SNMP) I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-...@ietf.org if you reply to or forward this review. Overall, this document gets a thumbs-up from me. And for extra measure I read over draft-ietf-isms-transport-security-model-12.txt to understqnd its context and found the two very well meshed. I found both of them a very strong base to the in-progress document draft-ietf-isms-secshell-15.txt. A top-level comment/question has to do with the draft's use of the TDomain/TAddress textual convention from RFC 2579, instead of RFC 3419. The revision notes call this out as mid-course choice and I'm sure the working group and the MIB experts have good reasons for it. But is a transport running on, say, TCP-IPv6 going to be appropriate with RFC 2579? In any event, it would be good since this is a transport-focused document if you could add a NOTE about the design choice of TDomain/TAddress. Here's what I'm reading in RFC 3419: Transport endpoints which carry SNMP traffic SHOULD continue to use the definitions from the SNMPv2-TM MIB module where applicable. They SHOULD use the transport domain values defined in this memo for SNMP transports not defined in the SNMPv2-TM MIB module, such as SNMP over UDP over IPv6. Programs that interpret transport domain values should in addition accept all the transport domain values defined in this memo in order to provide interoperability in cases where it is not possible or desirable to distinguish the protocols running over a transport endpoint. Section 2 Though I'm reviewing for the tsv-dir, I can't resist both complimenting and fussing a bit about the paragraph in Section 2 about the individual who considers three approaches to security and ends up hiring a company that can handle all his or her needs comprehensively: The individual therefore achieves the desired security, with no significant effort on his part other than identifying requirements and verifying the quality of service being provided. The discussion is very clear. But with no significant effort...other than identifying requirements is like the small matter of programming. Section 3.2.1 At the mention of multiple transport mappings for SNMP, please give a reference. Section 3.2.1.3 A secure Transport Model will establish an authenticated and possibly encrypted tunnel between the Transport Models of two SNMP engines. After a transport layer tunnel is established, then SNMP messages can be sent through the tunnel from one SNMP engine to the other. Transport Models MAY support sending multiple SNMP messages through the same tunnel. Is the MAY sentence at the end of paragraph necessary? From the standpoint of a transport person, it's hard to envision that an implementor would establish security and tear it down per message, but this MAY is saying that's the default. Later you advise implementations against this. Taking the next two comments together, 3.3.1. No SNMP Sessions The transportDomain and transportAddress identify the transport connection to a remote network node. Elements of the transport address (such as the port number) might be used by an application to send a particular PDU type to a particular transport address. This paragraph describes a heuristic to get around the fact that the transport subsystem does not have access to the pduType. What do pduTypes include? What's a useful example of this hint that makes this reversal worth including? Readability of the two paragraphs before: The Transport Subsystem may support transport sessions. However, the transport subsystem does not have access to the pduType, so cannot select a given transport session for particular types of traffic. Certain parameters of these ASIs might be used to guide the selection of an appropriate transport session to use for a given request by an application. To what does these ASIs refer? This hint isn't very clear either. Transport readers want to know... On the one hand, An SNMP Architecture has no concept of sessions (or connections) nor do these documents introduce it. On the
Re: Repair of Public Mail List Archives Complete
Randy, Suresh Thanks for the info. I do like my Web interface to a mailing list once I am in approximately the right time frame and I know of no such interface to an IETF list archive any more. By contrast, the IRTF archives, such as ICCRG and TMRG are excellent. The nearest such IETF facility is CCAMP but that has less function and uses https:-( with a certificate that my browser rejects. Tom Petch - Original Message - From: Randy Presuhn randy_pres...@mindspring.com To: ietf@ietf.org Sent: Tuesday, March 17, 2009 8:15 PM Subject: Re: Repair of Public Mail List Archives Complete Hi - From: Tom.Petch sisyp...@dial.pipex.com To: Alexa Morris amor...@amsl.com Cc: ietf@ietf.org Sent: Tuesday, March 17, 2009 2:34 AM Subject: Re: Repair of Public Mail List Archives Complete ... But when I really need an archive, to see what was agreed in 2006, I have to get there day by day by painstaking day by tedious day at a time. I can see no other more direct way. The files at ftp://ftp.ietf.org/ietf-mail-archive/ are much better suited for such searches, especially when the time frame is fuzzy. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Repair of Public Mail List Archives Complete
Alexa I noticed the lists were down and would normally have flagged it, as many another organisation knows. I did not do so partly because of the usual problem of where to flag it but more because what is the point? These are not so much archives as current affairs. I can look at what has been posted so far today, or yesterday or last week. But when I really need an archive, to see what was agreed in 2006, I have to get there day by day by painstaking day by tedious day at a time. I can see no other more direct way. Where the ietf does not host the archive, and there are still some, then I get a menu inviting me to start in March 2006, which takes me where I want to be in seconds. So when the ietf archives are down, well, I don't really miss them. Tom Petch - Original Message - From: Alexa Morris amor...@amsl.com To: wgcha...@ietf.org Cc: ietf@ietf.org Sent: Tuesday, March 03, 2009 10:20 PM Subject: Repair of Public Mail List Archives Complete As I mentioned late last week, as a side effect of a recent Mailman upgrade some mail lists with previously public archives had their list configuration reset to private archiving, resulting in inaccessible archives. This archiving issue has now been repaired and the missing archives have been transferred from private to public. All lists with public archives should now have the complete set of messages. As always, please contact me with any questions or concerns. Regards, Alexa --- Alexa Morris / Executive Director / IETF 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 Phone: +1.510.492.4089 / Fax: +1.510.492.4001 Email: amor...@amsl.com Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com http://www.amsl.com/ ___ 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: Abstract on Page 1?
On an allied topic, I notice that a recent I-D - draft-ietf-sidr-arch-06.txt - published March 9, 2009, had a running heading which included 'November 2008'. Paranoid as I am, I immediately link this date to RFC5378 and the time when the IETF Trust introduced the new rules for IPR. Is there a connection orr is there some more innocent explanation as to why the running heading is not March 2009? Tom Petch - Original Message - From: Julian Reschke julian.resc...@gmx.de To: Scott Lawrence scott.lawre...@nortel.com Cc: John C Klensin john-i...@jck.com; ietf@ietf.org Sent: Saturday, March 07, 2009 9:45 AM Subject: Re: Abstract on Page 1? Scott Lawrence wrote: ... This is a trivial change for the generation tools to make - at worst it will make one generation of diffs slightly more difficult (and I'd be happy to trade one generation of poor diffs for this, so for me just don't worry about fixing the diff tools). ... At this point, no change to the boilerplate is trivial anymore. For xml2rfc, we need to - define how to select the new behavior (date? ipr value? rfc number?); if the behavior is not explicitly selected in the source, we need heuristics when to use the old one and when to use the new one (keep in mind that the tools need to be able to generate historic documents as well) - add new test cases - add documentation So, I'm not against another re-organization, but, in this time, PLEASE: - plan it well (think of all consequences for both I-Ds and RFCs) - make the requirements precise and actually implementable (remember: must be on page 1 :-) - give the tool developers sufficient time; optimally let *then* decide when the cutover date should be BR, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-farrel-rtg-common-bnf (Reduced Backus-Naur Form(RBNF) A Syntax Used in Various Protocol Specification toProposed Standard
- Original Message - From: Adrian Farrel adr...@olddog.co.uk To: John C Klensin john-i...@jck.com; Tom.Petch sisyp...@dial.pipex.com; ietf@ietf.org Sent: Thursday, February 05, 2009 9:49 PM Subject: Re: Last Call: draft-farrel-rtg-common-bnf (Reduced Backus-Naur Form(RBNF) A Syntax Used in Various Protocol Specification toProposed Standard Thanks John, It looks to me from your mail that we are in partially violent agreement. Certainly that this form of BNF needs to be documented. Also that the Applicability text I have added will do. We have two open issues: - Use of 2119 language - Standards Track or Informational On the first, I take your point and am uncomfortable about using 2119 for what is not a protocol spec. Experience seems to be, however, it helps readers to understand that a rule is a rule. On the second, I would like to defer to the IESG. I will raise it with the sponsoring AD (Ross) and get them to discuss it when they process the I-D. I agree with John that Standards Track is inappropriate for this I-D (and agree that it does need publishing). I see either Informational or Historic as appropriate and when this leads to Normative downrefs, then again, I see that as appropriate. I think too that there is a third issue, of a better name than RBNF. John clearly showed that this I-D is not reduced. Historic? Deprecated? Limited_applicability? Variant? Simplified? Tom Petch Cheers, Adrian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call for Comments: Proposed work-around to the Pre-5378 Problem
Reading this, and reading it and reading it again, I think we are going backwards more than is desirable where code is concerned. I expect that for some years, the s.6.iii.c clause will be common ie no derivative works outside the Standards process without obtaining an adequate licence. The s.5.c clause then explains this as meaning that the IETF Trust will not grant such rights without obtaining sufficient rights to do so from the person controlling the pre-5378 material. This seems to trump the additional rights granted for code in s.4. Where code is concerned, IETF counsel has stated that RFC3978 already gives us such rights for code, in response to which Simon Joseffson has pointed out clauses which might be construed differently to which counsel has agreed it could be clearer but has not changed his advice (eg IPR WG July 2006). My lay reading of this new text is that it does not give us an exemption for code or if it does, then it does so even more obscurely than RFC3978 does and this I would regard as a retrograde step. It seems to depend on the reading of unless and until it has obtained sufficient rights to do so while the request to clearly identify pre-5378 material is likely to put the wrong attribution on code for which the RFC3978 licence currently applies. My particular concern is MIB modules. Apologies for the to/cc list, most of which will generate bounces, but the legally correct thing to do seems to be to leave it unchanged, at least for a first iteration. Tom Petch - Original Message - From: Ed Juskevicius edj@gmail.com To: ietf@ietf.org; ietf-annou...@ietf.org; wgcha...@ietf.org; i...@iab.org; i...@ietf.org; rfc-edi...@rfc-editor.org Cc: Trustees trust...@ietf.org; Contreras,Jorge jorge.contre...@wilmerhale.com Sent: Friday, February 06, 2009 6:28 AM Subject: Last Call for Comments: Proposed work-around to the Pre-5378 Problem The IETF Trustees met via telechat on February 5th to decide on some proposed revisions to the Legal Provisions Relating to IETF Documents policy, based on comments received from the community in the last two weeks. Please recall this work is being done to provide a work-around for authors having the 'pre-5378 problem'. The telechat was productive. The Trustees reached consensus to do the following: 1) Clarify the copyright text at the beginning of the BSD license in Section 4.1 to read as follows: Copyright (c) insert year IETF Trust and the persons identified as its authors. All rights reserved. 2) Replace the word and by the word or in one place so that the last sentence of Section 6.c.iii becomes: Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 3) Fix some nits with respect to the inappropriate use of square brackets '[' and ']' in two places. The IETF Trust website has been updated with a new version of the draft Legal Provisions Relating to IETF Documents including the changes described in this message. Please look for the documents dated 2009-02-05 at: http://trustee.ietf.org/policyandprocedures.html . If you have any final comments on this, please post them before the end of February 7th. This is the last call for comments. Regards, Ed Juskevicius, on behalf of the IETF Trustees edj@gmail.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC 5378 contributions
- Original Message - From: Theodore Tso ty...@mit.edu To: Tom.Petch sisyp...@dial.pipex.com Cc: Simon Josefsson si...@josefsson.org; ietf@ietf.org Sent: Wednesday, January 21, 2009 3:44 PM Subject: Re: RFC 5378 contributions So I wasn't on the IPR working group, but it seems to me that there are two separable issues. There is the question of *which* license to use for contributions (which might or might not vary based on type of contribution, i.e., text vs. code), To quote Harald quoting Counsel 15 Mar 07 1 - The legal theory the IETF operates under is that people who contribute to the IETF process know they are doing so. 2 - There is no legal requirement for ANY boilerplate to appear in a contribution to the IETF. This includes internet-drafts. so the boiler plate is there ... well, at the behest of the IETF Trust; it is the contents of the Note Wells and the referenced BCP that matter more. and then there is the question of whether we are sticking the entire legal liability and respponsibility onto the I-D editors/authors to guarantee/warant that the entire document can be released under the the new licensing requirements, and that relates quite strongly to the transition issue. and the BCP says By submission of a Contribution, each person actually submitting the Contribution and each named co-Contributor is deemed to have read and understood the rules and requirements set forth in this document. which are (inter alia) to grant derivative rights; and also, With respect to each Contribution, each Contributor represents that, to the best of his or her knowledge and ability: a. The Contribution properly acknowledges all Contributors, including Indirect Contributors. so the way I see it, a Contribution (eg an I-D) should acknowledge all relevant people, ensure all names are there. If that name is of a person within the IETF process, then I think that grant may now be presumed. If not, then it must be sought. Was that second issue discussed by the IPR wg? In terms of Contributions and Contributors, yes; it is Contributions and Contributors that formed the taxa of the IPR WG (eg, 26 Nov 2007, 'issue #1515' and around there, but especially Brian Carpenter's post to 'ISSUE Incoming 5.6'). Editors and authors, well they appeared, but I saw that as something of an aberration. Tom Petch - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-farrel-rtg-common-bnf (Reduced Backus-Naur Form (RBNF) A Syntax Used in Various Protocol Specifications) to Proposed Standard
A) The start of this I-D seems a little coy - 'various protocol specifications' 'several protocols' - and this is reflected in the Abstract and Introduction. Reading between the lines, this seems to have had its genesis in the 'Sub-IP Area' specification; nothing wrong with that, but the coyness seems misplaced. More generally, I think that this I-D cries out for an Applicability Statement. It makes brief reference to RFC5234 but contains no guidance that I can see as to when this standard should be used or when RFC5234 should be. The IETF has a history of producing multiple standards and letting the market decide but I think that we do a better job when we give guidance. B) Coyness again, in its definitions 'The basic building blocks of BNF are rules and operators' but what is a rule? RFC5234 eg says A rule is defined by the following sequence: name = elements crlf and I think that something similar is needed here (or else make RFC5234 a normative reference:-) C) In a similar vein, to me, and perhaps to many in the IETF, it is RFC5234 or its precursors that represent the 'standard' meta-syntactic language. Some comparison of the functionality would be helpful, as an informative Appendix. Is this a proper subset, if not, then where? D) As s.2.4 says. 'Precedence is the main opportunity for confusion in the use of BNF.' I think this should go further. The underlying reason IMO is because the concatenation mechanism, the one with no operator, takes precedence over the alternative operator, and this is counter-intuitive. RFC5234 spells this out ' Use of the alternative operator, freely mixed with concatenations, can be confusing.' and, IPR permitting (I note that this was submitted pre-5378 but any revision would not be:-), I suggest incorporating such text. Tom Petch - Original Message - From: The IESG iesg-secret...@ietf.org To: IETF-Announce ietf-annou...@ietf.org Sent: Tuesday, January 06, 2009 7:56 PM Subject: Last Call: draft-farrel-rtg-common-bnf (Reduced Backus-Naur Form (RBNF) A Syntax Used in Various Protocol Specifications) to Proposed Standard The IESG has received a request from an individual submitter to consider the following document: - 'Reduced Backus-Naur Form (RBNF) A Syntax Used in Various Protocol Specifications ' draft-farrel-rtg-common-bnf-07.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 substantive comments to the ietf@ietf.org mailing lists by 2009-02-03. 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-farrel-rtg-common-bnf-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=17681rf c_flag=0 ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC 5378 contributions
- Original Message - From: Theodore Tso ty...@mit.edu Sent: Friday, January 16, 2009 1:23 AM On Thu, Jan 15, 2009 at 11:50:46AM -0500, Marshall Eubanks wrote: Consider the threat model here. This threat applies ONLY to material that the Trust licenses to third parties (such as, say, the IEEE) for inclusion and modification in their standards. (Just reprinting or translating an RFC is not at issue.) So this licensing to third parties is not automatic; which makes sense in terms of letting the IESG to have a control point before allowing another standards body to take over a standard (or try to take over a standard). Well, no. To me, RFC5378 asks that future Contributions include an unrestricted right to produce derivative works (previously restricted to within the IETF) which right is given to the IETF Trust. RFC5377 guides the IETF Trust as to when this right should be given to third parties but it is the IETF Trust that decides. I see no role for the IESG. We have put our trust in the IETF Trust, to produce legends and to exercise grants; that is what I see us as having signed up to when we endorsed RFC5377. eg s.3 the legal authority for determining and granting users rights to copy material in RFCs and other IETF Contributions rests with the Trustees for the IETF Trust Tom Petch However, that presumably wouldn't be tree for allowing text or code to be used in implementations, open source or otherwise --- I assume that wouldn't require prior permission first, right? If the Trust does NOT license your material to third parties, then there is no infringement, no one with standing to sue, and no risk to authors. It may be necessary for the Trust to state that they will not assume 5378 to be in place for this purpose until there is a replacement. (In that case, if the IEEE or some other body wants to take over an RFC and modify it, they will have to get explicit permission from all authors until there is a replacement for 5378 in place, just as they did before 5378 as put into place.) My understanding is that the Trust is responsible for these licenses, and so they could just (in their best judgement) refuse to issue them without further conditions. So there probably isn't much risk for a standards bodies wanting to take over a MIB, for example, But what about someone using pseudo-code from a RFC where the RFC editor is required to make an assertion that he/she had all of the rights, and the code or pseudo code was contributed by a third party who copied the code from some Microsoft source they had access to while they were a graduate student? Or (and this is my opinion), maybe the authors should only warrant _their work_ as being subject to such licenses, and put the burden on the Trust to obtain any necessary approvals from other parties, only alerting the Trust to the extent they know of such prior authorship. My understanding is that this would require a 5378bis. That I think is the key; each person can only warrant what they themselves have authored. Something that might be worth looking at is the Developer's Certification of Origin, which is how Linux Kernel developers deal with contributions for the Linux Kernel. Anything which gets incoproated into the kernel must have a Signed-off-by, like this: Signed-off-by: Theodore Ts'o ty...@mit.edu What this mean is an explicit assertion of the following: Developer's Certificate of Origin 1.1 By making a contribution to this project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. This would obviously have to be modified for the IETF's purpose, but what's nice about it is that each Linux Kernel Developer is only making assertions about things which he or she has personally has control over, and by using the Signed-off-by chain, it's possible to see the
Re: ANNOUNCEMENT: The IETF Trustees invite your review andcomments on a proposed Work-Around to the Pre-5378 Problem
- Original Message - From: Bill Fenner fen...@fenron.com To: Tom.Petch sisyp...@dial.pipex.com Cc: Russ Housley hous...@vigilsec.com; trust...@ietf.org; ietf@ietf.org Sent: Wednesday, January 14, 2009 7:35 PM Subject: Re: ANNOUNCEMENT: The IETF Trustees invite your review andcomments on a proposed Work-Around to the Pre-5378 Problem On Wed, Jan 14, 2009 at 1:41 AM, Tom.Petch sisyp...@dial.pipex.com wrote: Ed's original announcement also placed significance on 0100 UTC on 16th December appearing to allow a grace period up until then during which 5378 was not in effect, since old boiler plate was acceptable. This is not quite accurate. RFC 5378 became BCP 78 at the time of publication on November 11th; even the old text says This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. So if you published an I-D with those words in it after RFC 5378 was published as BCP 78, then that I-D is subject to the rights, licenses and restrictions contained in RFC 5378. Thanks for the correction. I also had in mind contributions to mailing lists where the Note Well - eg the one sent out to this list on 1 January 2009 - references RFC5378 (or not as is the case in other settings) rather than BCP78. I am unclear whether this is by design or whether it is something that has yet to be brought in line with current thinking. Isn't it complicated? Tom Petch Bill ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC 5378 contributions
- Original Message - From: Andrew Sullivan a...@shinkuro.com To: ietf@ietf.org Sent: Thursday, January 15, 2009 4:52 AM Subject: Re: RFC 5378 contributions On Wed, Jan 14, 2009 at 08:33:35PM -0500, Contreras, Jorge wrote: No, absolutely not.nbsp; Use of pre-5378 materials in the IETF standards process has never been an issue, only use outside the IETF is problematic (ie, allowed under 5378 but not the earlier rules). Why is the actual situation of the use relevant? Because when an I-D is submitted, the submitter is confirming by the boiler plates included in the I-D, that they have gotten the relevant permissions to allow the IETF Trust to exercise the greater powers that RFC5378 gives them. So my take is that any substantial Contribution (as defined) must have the necessary permissions. Post November 9th Contributions of any kind were under the new rules, even if you had yet to be told so. Tom Petch Contribution is defined in section 1a of RFC 5378, and it plainly says that mailing list posting and anything one says at the microphone in any meeting is included in the definition. In section 5.1, RFC 5378 says that, by submitting the Contribution, the Contributor is deemed to have agreed that he/she has obtained the necessary permissions to enter into the agreement allowing the IETF to use the Contribution according to the new rules. So, just because the Contribution doesn't _happen_ to end up in use outside the IETF by virtue of the IETF's actions does not mean that a Contributor doesn't have to obtain the rights to allow such re-use. I believe that the _intent_ of 5378 is as you say, but the way it is written does not seem to restrict it in the way you say it does, at least when I read it as plain English prose. I'm not qualified to say whether there are other relevant legal considerations. Whether there is any practical effect to this state of affairs is quite another matter, too, of course. I find it hard to believe that there'd be a practical consequence; but then, I have found several actual legal decisions of the past to be hard to believe, too. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ 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: ANNOUNCEMENT: The IETF Trustees invite your review and comments on a proposed Work-Around to the Pre-5378 Problem
- Original Message - From: Russ Housley hous...@vigilsec.com To: Tom.Petch sisyp...@dial.pipex.com Sent: Wednesday, January 14, 2009 10:36 PM Correction: RFC 5378 was published on 10 November 2008. http://mailman.rfc-editor.org/pipermail/rfc-dist/2008-November/002142.html Thanks for the correction. I was about to point out that the latest draft licence from the IETF Trust refers in 5c to material published 'before November 10, 2008' but this now makes sense. ( In passing, the reference to November 12th was a mistake on my part; I was looking at Ed's announcement which spoke of the new rules coming in force 'today' and which my e-mail client tells me is November 12th. I should of course have looked at the e-mail headers and seen that he submitted the e-mail so as to generate 'Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C51A28C173; Tue, 11 Nov 2008 15:40:08 -0800 (PST)' which for GMT or places West is November 11th:-( Whatever, November 10th it is. What then is post-5378? Is it material published on or after November 10th? Tom Petch Russ At 11:20 AM 1/14/2009, Russ Housley wrote: Tom: RFC 5378 was published on 11 November 2008, and it went into effect on that date. Pre-5378 material refers to contributions that were made before the BCP went into effect. I do not believe that anyone tracked the posting time at a finer granularity than a day. Russ The At 04:41 AM 1/14/2009, Tom.Petch wrote: Russ I would like greater clarity about the meaning of pre-5378. Ed's original announcement said that the new regime was in effect from 12 November 2008 (no time specified). Ed's revised text uses 'before 10 November 2008' (no time specified). Ed's original announcement also placed significance on 0100 UTC on 16th December appearing to allow a grace period up until then during which 5378 was not in effect, since old boiler plate was acceptable. We appear to have four zones of time (up to 23:59:59 9th Nov, 10th/11th Nov, 12th Nov sometime to 00:00:59 UTC 16th December, thereafter). Please define, in a legally binding manner, pre- and post- 5378. After which, we may need transitional arrangements for people who posted in the middle two time zones, particularly for those who published in the first two weeks of December, thinking that they had a waiver and now find that they may have claimed rights in their Contribution that they will never possess (because it contains old text from earlier Contributions). snip ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: ANNOUNCEMENT: The IETF Trustees invite your review andcomments on a proposed Work-Around to the Pre-5378 Problem
Russ I would like greater clarity about the meaning of pre-5378. Ed's original announcement said that the new regime was in effect from 12 November 2008 (no time specified). Ed's revised text uses 'before 10 November 2008' (no time specified). Ed's original announcement also placed significance on 0100 UTC on 16th December appearing to allow a grace period up until then during which 5378 was not in effect, since old boiler plate was acceptable. We appear to have four zones of time (up to 23:59:59 9th Nov, 10th/11th Nov, 12th Nov sometime to 00:00:59 UTC 16th December, thereafter). Please define, in a legally binding manner, pre- and post- 5378. After which, we may need transitional arrangements for people who posted in the middle two time zones, particularly for those who published in the first two weeks of December, thinking that they had a waiver and now find that they may have claimed rights in their Contribution that they will never possess (because it contains old text from earlier Contributions). (We may even have a fifth time zone, up until the time at which people were informed of the new regime - at least up until the turn of the year, not all our emissions yet carried the new text referring to RFC5378 so anyone new to the IETF could reasonably claim that their Contributions were being made under RFC3978 as modified - but I digress :-(. Tom Petch - Original Message - From: Russ Housley hous...@vigilsec.com To: Doug Ewell d...@ewellic.org Cc: trust...@ietf.org; ietf@ietf.org Sent: Monday, January 12, 2009 10:07 PM Subject: Re: ANNOUNCEMENT: The IETF Trustees invite your review andcomments on a proposed Work-Around to the Pre-5378 Problem Doug: I hope this response answers your pragmatic questions. 1. What do I, as editor of an I-D and previously editor of a related RFC that is not quoted in the current I-D, need to do in order to allow the WG chairs to move my draft forward into IETF Last Call? You can proceed to IETF Last Call now. However, if updates to the I-D are needed you may be faced with a problem depending on your situation. I presume that some or all of the text in the I-D was contributed before 10 Nov 2008. If so, then an update to that I-D requires you or the WG chair to determine if the people that made the contribution are willing to grant the additional rights required by RFC 5378. If so, you are done. If not, you will need some work-around like the one being discussed on this thread. If IETF Last Call or IESG Evaluation brings comments that require an update to the I-D, then you end up with the same situation. If the document is approved without change, then the RFC Editor will ask each of the authors to grant the additional rights required by RFC 5378. If this cannot be done, then the document will sit in the queue until some work-around like the one being discussed on this thread is implemented. 2. What do the co-editors of the WG's other I-D, who were previously also the co-editors of a related RFC that *is* quoted in the current I-D, and at least one of whom has co-authored other RFCs, need to do to allow the WG chairs to move *their* draft forward into IETF Last Call? Our WG has stalled due to the uncertainty surrounding the legal requirements and verbiage. None of us are attorneys, AFAIK, but all of us would like to get our work done. You can proceed to IETF Last Call now. As above, at some point contributors will be asked to grant the additional rights required by RFC 5378. If you can do so, there is no problem. If not, you will need some work-around like the one being discussed on this thread. Russ ___ 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: [73attendees] IsUSA qualified for 2.3ofdraft-palet-ietf-meeting-venue-selection-criteria?
- Original Message - From: Dave CROCKER [EMAIL PROTECTED] Sent: Tuesday, November 18, 2008 9:03 PM Subject: Re: [73attendees] IsUSA qualified for 2.3ofdraft-palet-ietf-meeting-venue-selection-criteria? Surely there is enough choice in venue to permit a global organization like the IETF to select ones that put some effort into being friendly about participation by people from a wider set of countries? I find the USA a friendly country to visit for work. Homeland Security and its predecessors have requirements that I must meet, and these change with time. But I always know what there are (only sometimes lacking a precise date of introduction) so I can be prepared, going right back to B1 and B2 visas. I have never had any surprises when I arrive in Atlanta. And when things go wrong, eg forgetting to hand in the second part of the green card, then the solution is available, eg the web site to contact is in the national press every six months or so. There is no other country in the world where it is so easy to find out what to do, you just need to allow time to let it happen (eg don't have a connecting flight out of Atlanta one hour later). The USA is also incredibly well served by flights making it cheaper for me to travel from Europe to Minneapolis than it is to travel to eg Vienna or Estonia. The USA also shares a language - well, sort of - with that of the I-Ds so there is only one language to learn. Currency? Mmm could do with a weaker dollar right now, but that will change. By contrast, I have found Canada (Toronto) the most unfriendly place to arrive at, with the unexpected checks before I was (eventually) allowed in. Incidentally, what has Malta got going for it, that it should be the location of a Mega-Interim in less than two months time? Could it be the winter sunshine? Tom Petch Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: FTP to HISTORIC? RE: [BEHAVE] Can we have on NAT66 discussion?
Not sure how wide this net is being cast but there has also been draft-ietf-secsh-scp-sftp-ssh-uri draft-ietf-secsh-filexfer-extensions draft-ietf-secsh-filexfer Tom Petch - Original Message - From: SM [EMAIL PROTECTED] To: Hallam-Baker, Phillip [EMAIL PROTECTED] Cc: Behave WG [EMAIL PROTECTED]; ietf@ietf.org Sent: Friday, November 14, 2008 6:51 PM Subject: Re: FTP to HISTORIC? RE: [BEHAVE] Can we have on NAT66 discussion? At 08:43 14-11-2008, Hallam-Baker, Phillip wrote: I propose that we either move FTP to historic or start a revision effort if there is sufficient interest in continuing it as a separate protocol from HTTP. There are a few I-D about FTP that have been submitted: FTP Extension Registry http://www.ietf.org/internet-drafts/draft-klensin-ftp-registry-00.txt FTP Extension for Internationalized Text http://www.ietf.org/internet-drafts/draft-klensin-ftp-typeu-00.txt Streamlined FTP Command Extensions http://www.ietf.org/internet-drafts/draft-peterson-streamlined-ftp-command-exten sions-06.txt FTP EXTENSION ALLOWING IP FORWARDING (NATs) http://www.ietf.org/internet-drafts/draft-rosenau-ftp-single-port-05.txt There were some discussion about one of the above I-Ds in Dublin. Regards, -sm ___ 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: several messages
IETF lists are sometimes criticised for their dominance by purveyors of boxes, by the lack of involvement of those who deploy and depend on those boxes. A striking feature of this Last Call is the (most welcome) contributions by these other communities and the fact that, in this instance, an IETF proposed standard would be most welcome, most helpful, to them. Furthermore, the points made in favour of this I-D seem to me to be fundamentally engineering, whereas those against seem more arcane, more objections on the grounds that the underlying 'purity' of the Internet might be compromised. I tracked the lengthy gestation of this I-D on the asrg list and there too, it struck me that we were engaged in engineering, in producing something that would work and be of immediate benefit (not something I always see on the lists of IETF WG) So, I think that this is a positive and sound response to a major Internet problem and would like to see it approved for the Standards Track. Tom Petch (responding to no message in particular) - Original Message - From: John C Klensin [EMAIL PROTECTED] To: Al Iverson [EMAIL PROTECTED]; ietf@ietf.org Sent: Friday, November 14, 2008 8:50 PM Subject: Re: several messages --On Friday, 14 November, 2008 13:51 -0500 Al Iverson [EMAIL PROTECTED] wrote: ... This strikes me as unrelated to DNSBLs. Am I misunderstanding? How is this DNSBL-specific? Al, and others, While many of us are less opposed to DNSBLs in principle than you or your colleagues may be assuming, we are opposed to creating IETF Standards for anything that interacts with the email environment without a relatively comprehensive understanding (and good documentation) of how the new bits interact with the rest of the system. One of the implications of that is unwillingness to see DNSBL formats standardized without having any protocol or best-practice documents that are being assumed in front of us at the same time. If there are failure cases, we expect to see descriptions of them and analyses of either their consequences or how they might be mitigated. When DNS experts claim that a particular approach is unhealthy for the DNS and give careful explanations for that, advocates of DNSBL standardization need to evaluate those arguments and propose remedies _in the relevant documents_, not just in flaming on the mailing list. When someone asserts that DNSBLs don't cause operational problems with the mail system if they are operated according to best practices, then it is reasonable for the IETF to require that documentation of the relevant best practices be put forward for standardization as part of the same logical package. Moreover, when a DNSBL advocate claims that his ISP organization is using best practices and not having problems or complaints, counterexamples that indicate that they are filtering complaints and/or that the supposed best practices are not sufficient or effective are very much in order. The purpose of IETF-wide review is precisely to bring out these that has implications outside the particular focus of the developers issues and force them to be discussed and resolved before a standards-track document can be approved. Although this one has been, IMO, a little more hostile than necessary (on both sides), anyone who isn't interested in that type of review should not be looking for IETF Standardization. Put differently, some of us who might not be resistant to a collection of documents that made up a DNSBL standard are extremely resistant to getting documents piecemeal and maybe out of the order of logical dependencies and get even more resistant when people try to justify one of the pieces on the basis that all claimed operational problems are someone else's fault and therefore not relevant to the document under discussion. Your opinion may differ, but my personal impression of the rough consensus is that neither this document, nor any of the probably followups, should be approved for the standards-track or BCP until some fairly large set of issues are addressed in a meaningful way. There have been a lot of suggestions about how to do that, most of which I consider constructive, and there may not be consensus about which ones of them are optimal. My own favorite starts with a draft WG charter whose function includes mapping out all of the documents needed to make a complete picture; others may have better (or other) ideas. The next step is probably up to the advocates of this document and, IMO, further attempts to narrow the discussion or dismiss the various concerns without either a charter or one or more new or revised documents are not likely to result in the sort of progress you would like. best wishes, john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list
Fw: not the Gen-ART Review of draft-ietf-forces-mib-07
- Original Message - From: Tom.Petch [EMAIL PROTECTED] To: Spencer Dawkins [EMAIL PROTECTED]; Olaf Kolkman [EMAIL PROTECTED]; John C Klensin [EMAIL PROTECTED] Cc: ietf@ietf.org Sent: Friday, September 05, 2008 9:15 AM Subject: Re: not the Gen-ART Review of draft-ietf-forces-mib-07 - Original Message - From: Spencer Dawkins [EMAIL PROTECTED] To: Tom.Petch [EMAIL PROTECTED]; Olaf Kolkman [EMAIL PROTECTED]; John C Klensin [EMAIL PROTECTED] Cc: ietf@ietf.org Sent: Thursday, September 04, 2008 6:34 PM Subject: Re: not the Gen-ART Review of draft-ietf-forces-mib-07 OK, I waited 24 hours, but... Dave Crocker, Charlie Perkins and I, and Scott Bradner independently, proposed Working Group Snapshots (WGS) in http://www.watersprings.org/pub/id/draft-dawkins-pstmt-twostage-01.txt Stable SnapShots (SSS), in http://www.watersprings.org/pub/id/draft-bradner-ietf-stds-trk-01.txt either of which could be used to express exactly the attribute Tom is suggesting (this I-D has now passed from the WG to the AD, IESG etc. and that suggested enhancements are no longer welcome), and could be used to express other attributes as well (the working group considers this I-D to be stable enough to implement, so we'll have implementation experience and won't be requesting publication of a paper design). Interesting; I had not followed the work on the revision of the standards process and I see that Working Group Snapshot is similar to what I suggested. I was thinking though of the designation being process-driven rather than a decision by the Working Group, that is, the tools system checks the status of the I-D and, once the I-D has been successfully Last Called in the Working Group, and passed on to the next stages, adds a line to the announcement that is generated on the i-d-announce list, to the effect that This Internet Draft is now in . perhaps with a second line saying For more information about the status of Internet Drafts, see http://www.ietf.org . Again, no change required to RFC2026. Tom Petch For extra credit, we could implement these with no 2026/2418 changes, if changing 2026/2418 is as impossible as it looks - neither BCP says we CAN'T do WGS/SSS. Not all the process proposals of the 2003-2005 era were useless, IMO... Spencer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: not the Gen-ART Review of draft-ietf-forces-mib-07
- Original Message - From: Olaf Kolkman [EMAIL PROTECTED] To: John C Klensin [EMAIL PROTECTED] Cc: ietf@ietf.org Sent: Wednesday, September 03, 2008 11:55 AM Subject: Re: Gen-ART Review of draft-ietf-forces-mib-07 I can imagine that the posting of an I-D may cause Pavlovian reactions but maybe there are means by which one can prevent folk to mistake the posting of such I-D as another request for review. I have certainly had that Pavlovian reaction, especially when the new I-D has appeared after a gap of weeks or months and I have forgotten what state the I-D is in. The solution lies in the hands of the document shepherd, to drop a note to the mailing list explaining what the new I-D is for. Some are good at it, getting the e-mail out before the I-D announcement hits the list; others are not. More sophisticatedly, the announcement could flag that this I-D has now passed from the WG to the AD, IESG etc. and that suggested enhancements are no longer welcome. Tom Petch --Olaf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed Experiment: More Meeting Time on Friday for IETF 73
- Original Message - From: Cyrus Daboo [EMAIL PROTECTED] To: Eric Rescorla [EMAIL PROTECTED]; Eliot Lear [EMAIL PROTECTED] Cc: IETF Chair [EMAIL PROTECTED]; ietf@ietf.org; IETF Announcement list [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, July 18, 2008 4:50 PM Subject: Re: Proposed Experiment: More Meeting Time on Friday for IETF 73 --On July 18, 2008 7:20:37 AM -0700 Eric Rescorla [EMAIL PROTECTED] wrote: 2. People's ability to meet tends to expand to fill out the available meeting time. I think this is a key point. Rather than expanding the number of slots why don't we look at using the time we have more efficiently. Some questions to ask include: How much work at a meeting could actually have been done on the mailing list beforehand? A lot of it; too many meetings I have attended consist of presentations on I-Ds which add nothing to that which could have been learnt beforehand by spending an evening reading the I-D. What work do we do at a meeting that can't be easily done via a mailing list? Not much; meetings in person can progress discussions faster provided all the parties are present. e-mail is slug-mail compared to face-to-face discussions, but it does depend on the parties being present. Also, once you get above a dozen or so active participants, you get those queues at the microphone so that the response comes several round trips after the question making the discussions hard to follow. For me, the strongest requirement for meetings in person is for BOFs; for the first one or two of a new working group, when the sap is rising; and for groups that appear moribund (so the IESG can see if the working group should be wound up). Less often, there is a case for one when there is a hot technical issue on which the working group is bogged down between competing proposals (IPv6 comes to mind) Tom Petch. Do we spend too much time with overviews of drafts that really should have been read by all attendees beforehand? Maybe it would be good for the first session on Monday to be an Area Overview session where an overview of all the latest drafts can be presented to give people a broader view of what is going on? Actually I have often felt that the IESG plenary would be a good place for area directors to give status updates/overviews of the work going on in their areas. Are 2 1/2 hour sessions really valuable, or would two shorter sessions be better? -- Cyrus Daboo ___ 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
Yes, I think that this is an excellent idea and should be pursued. I note that this will also give us a URN (RFC3044). Any thoughts on what the URN might in future resolve to? Tom Petch - Original Message - From: Ray Pelletier [EMAIL PROTECTED] To: IETF Discussion ietf@ietf.org; IAOC [EMAIL PROTECTED]; The IESG [EMAIL PROTECTED]; RFC Editor [EMAIL PROTECTED]; IAB [EMAIL PROTECTED]; Working Group Chairs [EMAIL PROTECTED] Sent: Wednesday, May 21, 2008 7:52 PM 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 ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: NETCONF Data Modeling Language (netmod)
- Original Message - From: David Harrington [EMAIL PROTECTED] To: 'Eric Rescorla' [EMAIL PROTECTED]; 'Bert Wijnen - IETF' [EMAIL PROTECTED] Cc: ietf@ietf.org; [EMAIL PROTECTED] Sent: Wednesday, April 23, 2008 5:49 PM Subject: RE: WG Review: NETCONF Data Modeling Language (netmod) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Rescorla I propose that you list (again) your (technical) objections to the the current proposal. Sure. Based on my knowledge of modelling/protocol description languages, the techniques that Rohan described based on RNG and Schematron seemed to me quite adequate to get the job done and the relatively large baggage introduced by defining another language (YANG) which is then translated into them seems wholly unnecessary. I appreciate that some people believe that YANG is more expressive and better suited for this particular purpose, but I didn't see any really convincing arguments of that (I certainly don't find the arguments in F.2 of draft-bjorklund-netconf-yang dispositive). Given what I know of the complexity of designing such languages, and of their ultimate limitations and pitfalls, this seems like a bad technical tradeoff. The people who believe that YANG is more expressive and better suited for this poarticular purpose include contributors to the design of SMIv2, MIB Doctors, members of the NMRG who helped develop the SMING information and data modeling language, contributors to the SMIng WG which worked on developing a proposed SMIv3 to converge the SMIv2 standard and the SPPI data modeling language standard and the NMRG SMING approach, and engineers who have multiple independent implementations of running code for Netconf data modeling. Sounds magnificent but who are these people and where are they? I do track the YANG and NGO mailing lists and what I see there worries me. I see a significant number of questions along the lines; of what does this mean, how can this ever work, how can I do ... and the questions are all very reasonable and need answers - which they mostly get, even if they are somewhat too often along the lines of 'oh dear', or 'more work needed'. But they are the sort of questions I, for all I have done with SMI, ASN.1 and other languages, would not have thought to ask; they come from someone at the sharp end writing code for today's boxes. Yet these questions are almost all coming from just one person with a specific market place, and if he can find so many doubts and queries, how many more are there waiting to be discovered? That one person - hi, Andy! - is doing a magnificent job but for a new language to live up to its billing, we need half a dozen such people, from different parts of OM to find the holes; and I just do not see them, at least not on the YANG and NGO mailing lists. The answers, likewise, mostly come from the same three or so people; again, I am concerned that there are not more, given the claims of yang. This causes me to doubt that we, the IETF, really has the community of interest to undertake such a challenging assignment. Tom Petch Snip /Snip David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ 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-klensin-rfc2821bis: closing the implicit MX issue
- Original Message - From: Paul Smith [EMAIL PROTECTED] To: Henning Schulzrinne [EMAIL PROTECTED] Cc: Douglas Otis [EMAIL PROTECTED]; Tony Hansen [EMAIL PROTECTED]; SMTP Interest Group [EMAIL PROTECTED]; IETF General Discussion Mailing List ietf@ietf.org Sent: Thursday, April 17, 2008 11:48 AM Subject: Re: Last Call: draft-klensin-rfc2821bis: closing the implicit MX issue Henning Schulzrinne wrote: This decision raises a somewhat larger issue, namely whether deferring to implementor desires is always the right thing to do. Compared to implementers, there are many more users and system administrators. For the reasons discussed earlier and alluded to below, they now lose in having poorer error handling and more abuse. I thought standards writers and implementer were supposed to serve end users (and maybe the large number of people having to install and manage things), not the other way around. Maybe this is another instance of the oft-bemoaned absence of operators from the IETF discussion. End users seem to be even more absent, even indirectly. Agreed. I see this as a big step in the wrong direction. No one has given a good reason for doing it other than 'its similar to what happens in IPv4', 'it makes life easier for people with awful internal procedures' and 'it saves us 3 lines of code in our software'. None of those are good enough reasons IMHO, given all the reasons not to do it. It might end up not being a big deal except for mail server administrators at big companies or ISPs, but it *might* be a massive deal, and given the easy change we could make now, I think it's a big opportunity being missed. I agree; this is an opportunity to clean up a obsolescent bodge and we should do just that. Tom Petch ___ 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: IESG Statement on Spam Control on IETF Mailing Lists
- Original Message - From: IESG Secretary [EMAIL PROTECTED] To: IETF Announcement list [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; ietf@ietf.org Sent: Monday, April 14, 2008 5:39 PM Subject: IESG Statement on Spam Control on IETF Mailing Lists The following principles apply to spam control on IETF mailing lists: * IETF mailing lists MUST provide spam control. And what is spam? I have seen this discussed on several occasions on lists whose prime concern is spam and there has been no rough consensus. For example, Phillip Hallam-Baker, on asrg, summed up one discussion well with OK so defining the term spam is off limits to the group because it ends up in definitional flame wars. For me, it is dead obvious that the 397kbyte PowerPoint file I received on an IETF list last week is spam, and I know some IETF moderators who would not have allowed it on to the list; but equally, I am sure that the sender would protest his innocence. If we do not agree what spam is, then the whole of this statement seems to me pointless. Tom Petch * Such spam control SHOULD track accepted practices used on the Internet. * IETF mailing lists MUST provide a mechanism for legitimate technical participants to bypass moderation, challenge-response, or other techniques that would interfere with a prompt technical debate on the mailing list without requiring such participants to receive list traffic. * IETF mailing lists MUST provide a mechanism for legitimate technical participants to determine if an attempt to post was dropped as apparent spam. * The Internet draft editor, RFC editor, IESG secretary, IETF chair and IANA MUST be able to post to IETF mailing lists. The relevant identity information for these roles will be added to any white-list mechanism used by an IETF mailing list. * There MUST be a mechanism to complain that a message was inappropriately blocked. The realization of these principles is expected to change over time. List moderators, working group chairs and area directors are expected to interpret these principles reasonably and within the context of IETF policy and philosophy. This supercedes a previous IESG statement on this topic: http://www.ietf.org/IESG/STATEMENTS/mail-submit-policy.txt That statement contains justification and implementation advice that may be helpful to anyone applying these principles. A separate IESG statement applies to moderation of IETF mailing lists: http://www.ietf.org/IESG/STATEMENTS/moderated-lists.txt ___ 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
Re: draft-duerst-iana-namespace-00.txt
- Original Message - From: Julian Reschke [EMAIL PROTECTED] To: Stephane Bortzmeyer [EMAIL PROTECTED] Cc: Tony Finch [EMAIL PROTECTED]; ietf@ietf.org Sent: Monday, March 03, 2008 5:00 PM Subject: Re: draft-duerst-iana-namespace-00.txt Stephane Bortzmeyer wrote: ... Yes. I suggest (continuing the first paragraph of section 7): On the client side, implementors MUST use the existing solutions to limit the rate of access to the origin server. They include: * ability to use HTTP caching ([RFC 2616], section 13) * local storage of data, together with HTTP headers like If-Modified-Since ([RFC 2616], section 14.25) * XML catalogs ([OASIS 2001]) ... Hm, we are talking about XML namespace names, not DTD URIs. XML processors are not supposed to resolve them, so it seems strange to insert requirements for clients that do so. Welcome as this is, why is this I-D limited to XML namespace names? What about XML Schema names? And is this not an update to RFC3688? Tom Petch BR, Julian ___ 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: draft-duerst-iana-namespace-00.txt
- Original Message - From: Julian Reschke [EMAIL PROTECTED] To: Tom.Petch [EMAIL PROTECTED] Cc: Stephane Bortzmeyer [EMAIL PROTECTED]; ietf ietf@ietf.org Sent: Tuesday, March 04, 2008 6:16 PM Subject: Re: draft-duerst-iana-namespace-00.txt Tom.Petch wrote: Hm, we are talking about XML namespace names, not DTD URIs. XML processors are not supposed to resolve them, so it seems strange to insert requirements for clients that do so. Welcome as this is, why is this I-D limited to XML namespace names? What about XML Schema names? Pardon my ignorance, but what is an XML Schema name? I As defined in RFC3688, which sets up namespaces for XML namespaces XML schema XML rdfschema XML publicid all using the URI scheme urn: Tom Petch And is this not an update to RFC3688? I'd consider it an alternative approach. BR, Julian ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Transition status
- Original Message - From: John C Klensin [EMAIL PROTECTED] To: Dan York [EMAIL PROTECTED]; Michael Thomas [EMAIL PROTECTED] Cc: Bill Fenner [EMAIL PROTECTED]; IETF discussion list ietf@ietf.org Sent: Friday, February 22, 2008 11:05 PM Subject: Re: Transition status (was Re: ISO 3166 mandatory?) --On Friday, 22 February, 2008 15:17 -0500 Dan York [EMAIL PROTECTED] wrote: I'll agree, too. We had some challenges getting the RUCUS mailing list up and running and then getting the web archives of the list up and running but the support folks were great to work with and got things sorted out rapidly. Folks, what I said was How much more of this will it take before you conclude that we have a problem?. That is a question, not an assertion that things are hopelessly snafued (or anything equivalent to that). I even accept Bill's proposed answer of A lot. Like several others, I've been very favorably impressed with how quickly AMS has gotten on top of problems and gotten them resolved once they are identified. I am concerned that insufficient resources were allocated to manage and test for what Bill describes as hundreds of things to manage. Some of that is due to an accident of bad timing that was presumably under no one's control: a cutover of the secretariat and web sites after, as Russ pointed out, registrations for IETF71 had already started. But I do believe that, if we ever recompete secretariat services again, the IAOC at the time should be sure they understand the risks and be sure that adequate investments are made to, at least, avoid repeating the types of problems that have been uncovered this time. That doesn't necessarily imply that we (or AMS) should be doing anything different now --again, I've been very impressed by the diligence with with problems have been addressed and the speed of recovery from them. It does imply that we should not be saying well, these things happen. In particular, it implies that the IAOC needs to be sure that there is institutional memory about things we are learning from this transition (and even from the CRNI-Neustar one) so that we are better prepared for next time. That is all, really. I think that there have been rather more problems in areas that are less in the public view, supporting the more private parts of the operation. But, I see the IAOC as culpable, at least in part, in that there seems to be no, or at least no adequate, specification of just what the system is. John's point about institutional memory is a good one, but to be effective, it has to be coupled with change control, so that all the changes that have taken place since the previous transition - and they seem to me to be numerous - are known and can be passed on to the incoming operators as and when there is a next transition. My sense is of AMS doing a grand job, but finding out after the event that there are a number - perhaps lots - of functions that they were not told about, that run by virtue of scripts tucked away in some dark corner that depend on a non-standard, locally-modified platform. Tom Petch john ___ 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: Last Call: draft-ellermann-news-nntp-uri (The 'news' and 'nntp' URI Schemes) to Proposed Standard
I have read this I-D and believe it should be published as an RFC. The author has a challenging task in that on the one hand, there is a pressing need to provide a replacement for parts of the, by now very ancient, RFC1738 while on the other, the subject matter is a moving target and it will be possible for some time to come to defer publication and then to produce a more up-to-date, perhaps better, version. I think that the author gets the balance right and that this should be published. Perhaps, in a year or two, when the surrounding landscape is more stable, there will be scope for a revision but that it would be wrong to defer publication on account of that possibility. I did not understand the second paragraph of s8.3 at first and believe that this should be made clearer, in line with the explanation that the author provided on the uri.w3.org mailing list. Tom Petch - Original Message - From: The IESG [EMAIL PROTECTED] To: IETF-Announce [EMAIL PROTECTED] Sent: Tuesday, February 19, 2008 2:18 AM Subject: Last Call: draft-ellermann-news-nntp-uri (The 'news' and 'nntp' URI Schemes) to Proposed Standard The IESG has received a request from an individual submitter to consider the following document: - 'The 'news' and 'nntp' URI Schemes ' draft-ellermann-news-nntp-uri-08.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 substantive comments to the ietf@ietf.org mailing lists by 2008-03-17. Exceptionally, comments may be sent to [EMAIL PROTECTED] 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-ellermann-news-nntp-uri-08.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=13153rf c_flag=0 ___ IETF-Announce mailing list [EMAIL PROTECTED] http://www.ietf.org/mailman/listinfo/ietf-announce ___ IETF mailing list IETF@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: Call for Comment: RFC 4693 experiment
Inline Tom Petch - Original Message - From: [EMAIL PROTECTED] To: ietf@ietf.org Cc: [EMAIL PROTECTED] Sent: Monday, January 21, 2008 1:24 PM Subject: RE: Call for Comment: RFC 4693 experiment While there are a couple of IONs whose content I find valuable (such as ad-sponsoring and discuss-criteria), IMHO the same information could be placed in ordinary web pages without losing much -- and perhaps gaining something in the process. Currently, we have similar information scattered over random web pages on ietf.org, random pages in IESG wiki, and the IONs (with different procedures and tools for updating them). tp I agree that the information is scattered and as such is a barrier to people joining in and contributing. I see a parallel with 'Finding Information' where what struck me most was the diversity of response, how many different avenues may or may not bring an answer to the question (and I saw no mention there of the Tao). I think this scatter - grown like Topsy I would call it - is a significant impediment to getting people involved with the IETF. So keep it simple, use the RFC process(es) and the web site (in serious need of redesign), and scrap IONs Tom Petch My reading between the lines interpretation of RFC 4693 Section 5 is that perhaps creating IONs was considered easier than e.g. fixing the procedures and tools for maintaining ordinary ietf.org web pages. (This may well have been correct, BTW -- but perhaps the secretariat transition will bring some new efforts to update www.ietf.org as well?) But looking forward, and considering the question what should be done about IONs, the answer is less clear. If IONs encourage people to clearly document things that are useful to others, then they have some value there. Maybe - and this is just an unsupported hypothesis - folks at IETF are more comfortable (or efficient, or motivated) with writing things that are called documents rather than web pages (even when there's no difference in actual content). And moving the same information to ordinary web pages would probably mean creating some sort of structure (e.g. header for distinguishing draft and approved versions with some kind of standard header) and processes (for e.g. approval). However, how to organize web pages is a topic where I think micromanagement (from e.g. me) would not be very productive. If useful information gets communicated in effective fashion, I'm OK with letting the IESG to choose the tools they use for maintaining things on the web, and don't really mind whether they get called IONs, wikis, or just web pages. Best regards, Pasi -Original Message- From: ext The IESG [mailto:[EMAIL PROTECTED] Sent: 16 January, 2008 21:41 To: IETF Announcement list Cc: ietf@ietf.org; [EMAIL PROTECTED] Subject: Call for Comment: RFC 4693 experiment RFC 4693, Section 4 says: This experiment is expected to run for a period of 12 months, starting from the date of the first ION published using this mechanism. At the end of the period, the IESG should issue a call for comments from the community, asking for people to state their agreement to one of the following statements (or a suitable reformulation thereof): According to http://www.ietf.org/IESG/content/ions/ the first ION was published 12-Jan-2007. This means the experiment ended last Saturday, and it's time for the IESG to issue the call for comments. Please tell us what you think about the experiment. Have IONs been valuable? Should we continue to make use of this mechanism? ___ 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: Should the RFC Editor publish an RFC in less than 2 months?
- Original Message - From: Lixia Zhang [EMAIL PROTECTED] To: Frank Ellermann [EMAIL PROTECTED] Cc: ietf@ietf.org Sent: Sunday, December 02, 2007 8:12 PM Subject: Re: Should the RFC Editor publish an RFC in less than 2 months? snip I'm late getting into this discussion, but also have the advantages of seeing arguments on all side at once :-) it seems to me that the final decision on this issue would be a tradeoff in a multi-dimension space: - how much gain vendors/users may get from publishing an RFC at time=T vs at (T + 2 months) in particular if the publication is tagged with some provisional clause. - how strong is the desire of wanting the published RFCs to be stable (i.e. minimizing the chances of reclassification, with an understanding that we cannot completely eliminate the chance) - As pointed out above, what may be the legal complication, if there is any, in handling appeals against a published RFC, and remedy the situation when an appeal succeeds. I too first thought that the process ought to be optimized for the majority cases. I now realized that the optimization should be based on the weighted percentages: (% of no-appeal cases) X (gains from publishing 2-month earlier) versus (% of appeal cases) X (chance of an appeal succeeded) X (cost from any potential legal complications and remedy) The remedy here may also include the cost to those people who acted on a published RFC in its first 2 months. I agree completely. When I am involved in risk analysis, the really nasty cases are 'probability low, impact high' - will the first nuclear bomb set off a chain reaction which destroys the world? unlikely but somewhat devastating if so. I see the withdrawal of approval by the IESG as risk analysis; whether it happens 10% or 0.1% of the time, whether it happens on account of an appeal or because of some other reason is immaterial if the potential adverse impact is high enough. At the same time, I see the benefits of having the RFC now rather than in February as minimal; early adopters adopt early and are proud to announce in their marketing material that their product conforms to I-D draft-ietf-wg-enhanced-protocol. The date of the arrival of an RFC is irelevant to them. The I-Ds that concern me most are those that may have had little exposure, for which that lack of exposure means that potentially show-stopping issues have yet to emerge. So one compromise would be to allow quicker publication of those I-Ds that have had wide exposure, that have been discussed on an IETF mailing list, so that at IETF Last Call it is feasible to look at the mailing list archive to see what has arison, but keep the 60 day delay for individual submissions, or for I-Ds that do not get an IETF Last Call. Tom Petch so the question to me is really: can we quantify the values of those weight factors? (as an academic I dont have a lot clue here) ps No, in my experience of risk analysis - each participant uses their gut feeling and the chair declares rough consensus. Lixia ___ 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: Should the RFC Editor publish an RFC in less than 2 months?
Original Message - From: Harald Alvestrand [EMAIL PROTECTED] To: ietf@ietf.org Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, November 29, 2007 7:52 AM Subject: Re: Should the RFC Editor publish an RFC in less than 2 months? IETF Chair skrev: Dear IETF Community: Due to a lot of hard work, the RFC Editor is publishing approved Internet-Drafts more quickly. Overall this is just what we want to happen. However, I am concerned that the RFC Editor is might be getting too quick. Anyone can appeal the approval of a document in the two months following the approval. In the past, there was not any danger of the RFC Editor publishing a document before this timer expired, and the only documents that became RFCs in less than 60 days were the ones where the IESG explicitly asked for expedited processing. The recent improvements by the RFC Editor make it likely that all documents will be moving through the publication process in less than two months. My short reply: Bad idea. In my opinion, placing such a hold on documents is a triumph of process over sanity. snip Such a hold is a dumb idea, and we shouldn't do it. Just publish, and if we turn out to have made the wrong decision, make a public statement saying that; one form of public statement is leaving a hole in the RFC Index. I recall a recent occasion when the IESG withdrew its approval, for draft-housley-tls-authz-extns a document that both before and after its approval generated a lot of heat, within and without a WG. Presumably the expedited process would, or at least could, have seen that published as an RFC. With that example in mind, a 60 day hold seems rather a good idea. Tom Petch 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
Re: Last Call: draft-sjdcox-cgi-urn (A URN namespace for the Commission for the Management and Application of Geoscience Information (CGI)) to Informational RFC
This I-D proposes a namespace of CGI. This acronym is already so widely used in the world of IT - just look at this announcement and every one like it for an example - that I think it would be irresponsible of us to define this acronym as the namespace for the Commission for the Management and Application of Geoscience Information (CGI) even if that is the common usage of it in geospatial circles. I note that one of the examples in this I-D uses OGC, presumable from The design of the CGI namespace builds on the experience of the Open Geospatial Consortium (OGC) which has defined the framework of geospatial services within which CGI standards have been developed and that would seem a better choice. Tom Petch - Original Message - From: The IESG [EMAIL PROTECTED] To: IETF-Announce [EMAIL PROTECTED] Sent: Monday, November 12, 2007 11:34 PM Subject: Last Call: draft-sjdcox-cgi-urn (A URN namespace for the Commission for the Management and Application of Geoscience Information (CGI)) to Informational RFC The IESG has received a request from an individual submitter to consider the following document: - 'A URN namespace for the Commission for the Management and Application of Geoscience Information (CGI) ' draft-sjdcox-cgi-urn-00.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 2007-12-10. Exceptionally, comments may be sent to [EMAIL PROTECTED] 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-sjdcox-cgi-urn-00.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=16473rf c_flag=0 ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: FW: I-D Action:draft-narten-ipv6-statement-00.txt
at the bottom Tom Petch - Original Message - From: Thomas Narten [EMAIL PROTECTED] To: Tom.Petch [EMAIL PROTECTED] Cc: ietf@ietf.org Sent: Tuesday, November 13, 2007 8:24 PM Subject: Re: FW: I-D Action:draft-narten-ipv6-statement-00.txt Tom.Petch [EMAIL PROTECTED] writes: I think though that it needs to be relatively short (which I probably have already blown), and high-level, since it's really aimed at higher level than your typical engineer. But the overal message needs to be think really hard about IPv4 exhaustion and what it means to your business, get serious about IPv6, and it's done, so don't wait. Trouble is, I am not convinced that the last statement is true. It is true. The core IPv6 work is done. And has been for a number of years. True, there are still WGs doing work on IPv6-related technologies (or is that technologies that happen to be IPv6-enabled?) But the same is true for IPv4 as well. But the idea that IPv6 is not yet done, and folk should wait for the IETF to finish one more key piece of work before deploying is not true, and that message needs to go out loud and clear. IPv6 is what it is. People may not like it, or wish it also did a number of things that it doesn't, but that is not the same thing as saying that the IETF is still doing key work on IPv6 that needs to complete before it is ready for deployment. Some WGs produce a set of RFC and then say that's it, let's deploy, let's learn and come back in a year or two if we need to. Others, like ipng, seem to have tinkeritis; it is always possible to improve - or at least to change things - so let's go on changing. The name may change - now it's 6man - but the discussions, - DHCP, what aspect of DHCv6 is not stable and ready to deploy? ULA, No apparent consensus to do this. But is it needed to deploy IPv6? A lot of people say absolutely not. (And people seem to forget that RFC4193 covers 90% of what ULAs do.) routing header, The IETF just deprecated an unused feature (due to potential security issues). In the overall scheme of things, that doesn't make IPv6 any more or less ready to deploy. RA They work fine and are part of the long-stable core. Sure, people continue to (and likely will forever) debate adding yet another option. That is is fine and expected. Indeed, that is exactly what people do for DHCPv4 (and other protocols) as well. ND Sure, people propose yet more extensions and features. Do not confuse that with ND is not stable and is still changing. compression, it's more than IPv4(128) - rumble on. I understand the discussions but do not have the relevant experience to judge whether they are material changes or not, and so long as that remains the case, then the number of fresh I-Ds leads me to conclude, it's not done, better wait. If the criteria for a technology being mature and done is how may IDs are being submitted, then a whole lot of IETF technology must be pretty unstable! All that said, work will continue on IPv6 tweaking/revising/etc. in response to deployment experience/feedback. That is exactly as it should be. But that is no different than for any other IETF technology, and it does not mean that the technology is not ready or done. In terms of new work, the only thing I'd like to see is that driven by a clear and compelling need from folk that are seriously trying to deploy IPv6 and can identify a real gap in available standards. I don't doubt there is some work to be done here, but it needs to be driven by a real, concrete need, not just be yet more tinkeritus. Thomas Your reply is all very reasonable but I remain unpersuaded (and I suspect that others will too). Have the discussions on m and o bits really finished? Has the right balance been struck between RA and DHCP(see 6man in September)? Has NATPT got a role to play (current discussions on this list seem to be reopening that one)? To quote Michael Dillon from the 6man list, 'Indeed. I'm not looking for a book at all, but an RFC which summarizes the current state of IPv6 that can be used as an authoritative source to win arguments with people who are still stuck in IPv4 thinking. At this point, I have to trawl through dozens of RFCs looking for this information, or else use one of the books Brian recommended and hope that the fact of his recommendation holds some weight' It's that dozens of RFCs that grabs my attention (and makes me think, how many more?) For me, it's not enough to say 'we are done'; we need to do more, like produce the that ultimate RFC as well (well, ultimate until the experience of deployment demands a change). Tom Petch Thomas ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: FW: I-D Action:draft-narten-ipv6-statement-00.txt
- Original Message - From: Thomas Narten [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: ietf@ietf.org Sent: Monday, November 12, 2007 5:30 PM Subject: Re: FW: I-D Action:draft-narten-ipv6-statement-00.txt A little more background/context that got me here. My original thinking was to do something like what ICANN and the RIRs have done, to bring awareness to the IPv4 situation and call for IPv6 deployment. I think the IETF can say a bit more about why, and the threats to the internet architecture. (This came out of some conversations I had at the recent ICANN meeting). Maybe this could be an IAB statement. Maybe an IETF statement. I'm not sure. But I think it would be useful to have an IETF voice also be heard in the call for deployment. Especially since there are still some going around saying IPv6 is not needed. IPv6 is still not done, so don't deploy yet, etc. Does the IETF think that deploying IPv6 is necessary and in the best interest of the Internet? If so, reiterating that would be good. I think though that it needs to be relatively short (which I probably have already blown), and high-level, since it's really aimed at higher level than your typical engineer. But the overal message needs to be think really hard about IPv4 exhaustion and what it means to your business, get serious about IPv6, and it's done, so don't wait. Trouble is, I am not convinced that the last statement is true. Some WGs produce a set of RFC and then say that's it, let's deploy, let's learn and come back in a year or two if we need to. Others, like ipng, seem to have tinkeritis; it is always possible to improve - or at least to change things - so let's go on changing. The name may change - now it's 6man - but the discussions, - DHCP, ULA, routing header, RA, ND, compression, it's more than IPv4(128) - rumble on. I understand the discussions but do not have the relevant experience to judge whether they are material changes or not, and so long as that remains the case, then the number of fresh I-Ds leads me to conclude, it's not done, better wait. On the other hand, I do understand well that there is a problem looming with ipv4 and that lack of action could turn that into a crisis and drama over which the IETF will have little or no control. Tom Petch snip ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Spammers answering TMDA Queries
Original Message - From: Clint Chaplin [EMAIL PROTECTED] To: ietf@ietf.org Sent: Thursday, October 04, 2007 1:01 AM Subject: Re: Spammers answering TMDA Queries I believe the term is tmda, not tdma. Never mind how it is spelt, what is it? Something to do with e-mail, something associated with spam, something that may or may not affect my ability to participate with the 'IETF' now or in future. But what is it? An explanation for one not familiar with MX and mail list administration would be appreciated. Tom Petch PS no need to explain SPF, DKIM etc, those have been hammered enough on this list. TDMA is a type of cell phone technology. On 10/3/07, Hallam-Baker, Phillip [EMAIL PROTECTED] wrote: I don't see a problem if we eat our own dog food. The use of tdma type tech for mailing list subscriptions has been considered best practice for over a decade. Personal use is nasty, brutish and hopefully short. Allowing unsubscribed persons to post after a tdma authentication is a courtesy, there is no obligation to extend it in the first place. Pooling the tdma responses across multiple ietf mailing lists is a further courtesy. There is more we can do here but no more that we should feel obliged to do - ecept for the fact that we are a standards organization and should eat the dog food. In particular, sign the messages with dkim and deploy spf. Sent from my GoodLink Wireless Handheld (www.good.com) -Original Message- From: Michael Thomas [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 03, 2007 08:23 AM Pacific Standard Time To: Brian E Carpenter Cc: ietf@ietf.org Subject:Re: Spammers answering TMDA Queries Brian E Carpenter wrote: Speaking personally, I think annual reconfirmation is quite reasonable. The message sent to the user should make it clear that it is an annual process. Except... the annual confirmation is probably going to get accidentally deleted by a lot of people because they think it's the monthly notice. If this is a real problem, wouldn't it be better to take it up with the mailman folks since I'd expect that it's not just ietf? I've been working with them on dkim related stuff and they are quite reasonable folks. Maybe they have some ideas on this front. Mike ___ 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 -- Clint (JOATMON) Chaplin Principal Engineer Corporate Standardization (US) SISA ___ 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: XML updates Re: Last Call: draft-ietf-simple-xml-patch-ops (An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors) to Proposed Standard
- Original Message - From: Lisa Dusseault [EMAIL PROTECTED] To: Tom.Petch [EMAIL PROTECTED] Cc: Stephane Bortzmeyer [EMAIL PROTECTED]; ietf ietf@ietf.org Sent: Tuesday, September 18, 2007 9:19 PM Subject: Re: XML updates Re: Last Call: draft-ietf-simple-xml-patch-ops (An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors) to Proposed Standard I would be happy to encourage work on IETF-wide guidance for XML usage (I guess that's what I'm doing now?). The Apps area has an XML directorate and supposedly we have some XML expertise to call on -- sometimes we do XML usage reviews for the other IETF areas. Lisa, I have seen references to the XML directorate before but have not knowingly (in Routing or Ops) seen output from it. What I have in mind, what it might perhaps do, is provide guidance - or to say that there is no clear guidance - in areas such as - Schema language (XSD, RELAX NG, ...) - namespaces (overuse of) - namespace prefix standardisation - element or attribute or text to instantiate an object - object identification (uniqueness, persistence, mutability, multiplicity of .. - using containers to provide scope for vendor extensions - selecting, adding, deleting nodes with XPath, filter expression, X. - tables and table indexing - aggregation of objects for bulk operations - specifying conformance - versioningof object definitions - access control to objects I see WGs struggling with these types of issues (although the WGs themselves may not agree with my perception that it is a struggle) At the back of my mind is the difference between ASN.1 and SMI (as used in MIB modules). Cutting down on the permissible ASN.1 constructs has made MIB modules much less complex than they otherwise would have been (as described in RFC1155, a brilliant piece of work). RFC3470 is good, but I think that there is now a need for something more. Tom Petch ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
XML updates Re: Last Call: draft-ietf-simple-xml-patch-ops (An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors) to Proposed Standard
- Original Message - From: Stephane Bortzmeyer [EMAIL PROTECTED] To: Tom.Petch [EMAIL PROTECTED] Cc: ietf ietf@ietf.org; [EMAIL PROTECTED] Sent: Tuesday, September 18, 2007 4:10 PM Subject: Re: Last Call: draft-ietf-simple-xml-patch-ops (An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors) to Proposed Standard On Tue, Sep 18, 2007 at 02:19:51PM +0200, Tom.Petch [EMAIL PROTECTED] wrote a message of 135 lines which said: I question the use of XPath 1.0, when XPath 2.0 was approved at the start of this year. It seems short-sighted, a bit like choosing IPv4 over IPv6 I strongly disagree. Xpath 2.0 is *much* more complicated than Xpath 1.0. Among free software, there is little implementation (or even plans) of 2.0. Xpath 2.0 is quite controversial. OK, XPath 2.0 looks more attractive to me as a user but I am not familiar with the uptake of XPath 2.0 (and does this make my point that more IETF-wide guidance could be valuable eg, to set another pack of leverets running, XSD v RELAX NG v ...) The comparison with IPv4/v6 is wrong. If you start from scratch, IPv6 is no more complicated than IPv4 (and it is probably the opposite). Xpath 2.0 is always much more difficult to implement (for instance, it requires schemas). This business of updating parts of an XML document seems to be cropping up in a number of places in the IETF with very different solutions. AFAIK, this is the first one to be specified at IETF. Other contenders are: * REX (W3C), which uses DOM events http://www.w3.org/TR/rex/ * Xquery update (W3C) http://www.w3.org/TR/xqupdate/ * XUpdate, which seems completely dead http://xmldb-org.sourceforge.net/xupdate/ * DUL, there was an I-D, A delta format for XML documents, draft-mouat-xml-patch-00.txt, now expired http://sourceforge.net/projects/diffxml Two that are current for me NETCONF, which offers XPath or subtree filtering to update configuration information stored in XML, and ForCES which uses a different approach to configure Network Elements specified via XML; I think I have seen others in the Apps area. I am not saying that these are doing exactly the same, rather that I see the same issues with varying results. Tom Petch ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [saag] Next step on web phishing draft(draft-hartman-webauth-phishing-05.txt)
- Original Message - From: der Mouse [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; ietf@ietf.org; [EMAIL PROTECTED] Sent: Monday, September 10, 2007 4:14 PM Subject: Re: [saag] Next step on web phishing draft(draft-hartman-webauth-phishing-05.txt) I really dislike the use of fishing with creative spelling in a document prepared for an international standards organization. Perhaps unfortunately, that is *the* word for the behaviour in question, at least in English. It was not invented for the draft, and com[ing] up with something [else] would be *less* descriptive and would render the document cryptic to the people who's been working against phishing for years. Perhaps it's a bad word to use in other languages, but that should be addressed by the translator(s) in question, not by mangling the original. Stick the word in quotes which conveys the message that we know that this is not a good piece of terminology, but that we are pragmatic enough to recognise that using it will convey the right meaning to most people. But on the other strand under this Subject:, I am with those who think that the IETF has demonstrated an absence of consensus and that the proposed way forward to try and achieve it by other means in plain wrong. Tom Petch ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: on the value of running code (was Re: Do you want to have more meetings outside US ?)
- Original Message - From: Dave Crocker [EMAIL PROTECTED] To: David Conrad [EMAIL PROTECTED] Cc: ietf@ietf.org Sent: Thursday, August 02, 2007 8:22 PM Subject: Re: on the value of running code (was Re: Do you want to have more meetings outside US ?) David Conrad wrote: I'd offer that the OSI protocol stack was probably significantly more reviewed than the TCP/IP stack. Depends what you mean by more reviewed. More eyes looking at the specs? Probably yes. More critical analysis by senior technical architects? Probably not. At the very least, running code is an empirical proof that an architecture _can_ work. Again, depends upon what one means by running code. Certainly there were early prototypes of OSI modules, and even running products. Clearly, that was not enough. In contrast, the Internet code was deployed and used in a running service, with increasing scale. So the distinction between prototype and production is probably of fundamental importance. (I think that Dave Clark really meant running service when he said running code.) OSI got well beyond the prototype stage. Major manufacturers produced products and I was involved with their implementation. From c.1990 to c.1995 we all knew that, with such a weight of political pressure behind it, OSI was bound to sweep all before it. By 1995, the tide had turned, but it was not the lack of interoperable, production software that did the turning. Tom Petch 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: Application knowledge of transport characteristics (was: Re: Domain Centric Administration)
- Original Message - From: Dave Crocker [EMAIL PROTECTED] To: Ned Freed [EMAIL PROTECTED] Cc: ietf@ietf.org Sent: Tuesday, July 03, 2007 7:08 PM Subject: Application knowledge of transport characteristics (was: Re: Domain Centric Administration) Ned Freed wrote: Keith, while I agree with your general point that applications have no choice but to be aware of lower layer semantics in many if not most cases, this last is not a good example of that. There is really no difficulty running SMTP or any other stream oriented protocol on top of a record-based protocol - all you have to do is ignore the record boundaries and make sure your buffer isn't larger than the maximum record size. ... The converse is not true, however - you cannot simply slap a protocol that depends on record boundaries onto a stream protocol and expect it to work, such as MAIL-11 over TCP (not that anyone in their right mind would use MAIL-11 this way...). I believe this highlights a basic opportunity (need) for the protocol engineering community. Although it applies to any discussion about the relationship between layer n and layer n+1 (or, layer n and layer n-1, if you want to focus on the upper layer...), it seems to come up most often in relation to application/transport discussions: How can we discuss the essential services required of the lower layer, without worrying about the means by which those services are delivered? That is, how do we discuss the what, without discussing the how? Related to that is discussion about lower layer services that supply more than is needed, but still suffice. Your example of record boundaries is useful because TCP's lack of the construct used to cause all sorts of problems and hacks. And perhaps still does. SNMP and syslog work fine over UDP but both have had to introduce a 'hack' to work over TCP (as seen in isms and syslog-tls respectively). netconf, which has never known UDP but would have been well suited to it, also has a 'hack'. But I see the converse too. TLS defines what it needs of a transport layer and TCP provides it (and more); UDP does not so DTLS introduces a shim to add some (but not all) of TCP's features to UDP. If we had a range of transports (perhaps like OSI offered), we could choose the one most suited. We don't, we only have two, so it may become a choice of one with a hack. But then that limited choice may be the reason why the Internet Protocol Suite has become the suite of choice for most:-) Tom Petch Another is in the realm of performance characteristics. The need for predictable inter-packet times for real-time voice or video streams highlight TCP's limitations. I've also noted that applications developed for LAN environments rarely translate well to WAN environments, due to implicit requirements for low latency and high reliability. Conversely, applications designed for WAN environments tend to work fine on LANs. (However I'm told there was quite a debate about whether to tailor TCP to work differently on LANs, when LANs started to get popular; thank goodness uniformity/simplicity arguments won out over local optimization arguments. The few times we've seen transport folks make efforts to solicit requirements or issues comments from the application protocols community, the responses have tended to be more along the lines of criticizing or recommending particular protocol features. It seems that we lack a vocabulary for discussing service needs, without diving into protocol details. Yet upper-layer independence of lower-layer details requires exactly that vocabulary. 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-williams-on-channel-binding (On the Use ofChannel Bindings to Secure Channels) to Proposed Standard
inline Tom Petch - Original Message - From: Jeffrey Hutzelman [EMAIL PROTECTED] To: Randy Presuhn [EMAIL PROTECTED]; ietf [EMAIL PROTECTED] Cc: Jeffrey Hutzelman [EMAIL PROTECTED] Sent: Wednesday, April 11, 2007 9:19 PM Subject: Re: Last Call: draft-williams-on-channel-binding (On the Use ofChannel Bindings to Secure Channels) to Proposed Standard On Wednesday, April 11, 2007 12:09:24 PM -0700 Randy Presuhn [EMAIL PROTECTED] wrote: Hi - From: Tom.Petch [EMAIL PROTECTED] To: ietf [EMAIL PROTECTED] Sent: Wednesday, April 11, 2007 10:43 AM Subject: Re: Last Call: draft-williams-on-channel-binding (On the Use ofChannel Bindings to Secure Channels) to Proposed Standard ... Otherwise those who would benefit from it - isms, netconf, syslog, ... ? - will not understand what they might do. I appreciate that something of this ilk has been around for a while (eg as when Ira McDonald pointed the isms list at draft-puthenkulam-eap-binding-04.txt) but I think that it got no traction because of its impenetrability. ... In the isms WG, we were told that we could not use EAP. http://www1.ietf.org/mail-archive/web/isms/current/msg00464.html That's right; isms is outside of EAP's field of applicability. But draft-williams-on-channel-bindings is not specifically about EAP, but rather about a general class of problems that arises when protected communications channels are established independently of authentication, and an approach and method for solving those problems, particularly within the context of various authentication frameworks. As it turns out, ISMS doesn't need to work about this class of problems because the approach we chose uses SSH, which provides both authentication and a protected channel in an integrated manner. Now, if SSH for some reason wanted to make use of a protected channel provided by TLS or, more likely, IPsec, then it would need to worry about this class of problems, and the solutions might well involve exposing new interfaces to ISMS and other applications built on SSH. But for the moment, that's not really an issue. Jeff I agree that SSH does provide authentication but authentication of what and how strong authentication? I recall concern being expressed that the authentication was of a low level engine when the application required authentication of a higher layer entity; my recollection is of seeing this on several lists. So I think that compound authentication may still be of value to isms, in the future. Tom Petch -- Jeff ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-williams-on-channel-binding (On the Use of Channel Bindings to Secure Channels) to Proposed Standard
I think this a significant I-D which could be, in a few years, be the way in which security is done in the Internet. But I also think it understates its achievements in the Abstract and that it may be inaccessible to those who would use it, those who are not also security experts. The Abstract refers to an approach 'which has various performance benefits'. Rather, I think that is solves a - the? - problem of Internet security, that encryption is easy and authentication is difficult and the mantra of security is that sound authentication must come first. This approach offers a way out of that impasse. But it is not clear that this is the case. I think that to get the benefits of this idea the I-D should have a non-normative section showing how it can be applied to some well understood application, using a well-understood lower secure layer (ie TLS or SSH, not IPsec) showing the outline protocol flow and infrastructure dependencies. Otherwise those who would benefit from it - isms, netconf, syslog, ... ? - will not understand what they might do. I appreciate that something of this ilk has been around for a while (eg as when Ira McDonald pointed the isms list at draft-puthenkulam-eap-binding-04.txt) but I think that it got no traction because of its impenetrability. Tom Petch - Original Message - From: The IESG [EMAIL PROTECTED] To: IETF-Announce ietf-announce@ietf.org Sent: Wednesday, March 14, 2007 4:44 PM Subject: Last Call: draft-williams-on-channel-binding (On the Use of Channel Bindings to Secure Channels) to Proposed Standard The IESG has received a request from an individual submitter to consider the following document: - 'On the Use of Channel Bindings to Secure Channels ' draft-williams-on-channel-binding-01.txt as a Proposed Standard The introduction of this draft implies that the facility being discussed applies only to GSS-API. That is not the case and the rest of the draft is clear on this point; this draft proposes to generalize and clarify a facility that exists today in GSS-API both for GSS-API use and for other authentication frameworks. 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 2007-04-11. Exceptionally, comments may be sent to iesg@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-williams-on-channel-binding-01.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=15078rf c_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-klensin-norm-ref (Handling Normative References for Standards Track Documents) to BCP
- Original Message - From: Sam Hartman [EMAIL PROTECTED] To: Tom.Petch [EMAIL PROTECTED] Cc: ietf ietf@ietf.org Sent: Saturday, February 24, 2007 10:09 PM Subject: Re: Last Call: draft-klensin-norm-ref (Handling Normative References for Standards Track Documents) to BCP My strong preference as an individual is to approve this document as is. I think there's a good split between RFC 3967 and this document. RFC 3967 will cover informational documents; this document will cover standards track. In which case, this should be clear from the Abstract and I do not think that that is currently the case. I suggest replacing This document replaces the hold on normative reference rule will be replaced by a note downward normative reference and move on approach. RFC 3967 is also updated to encourage annotations to be added when that procedure is applied. with This document describes a simpler procedure for downward references to Standards track and BCP documents, namely note and move on. The procedure in RFC3967 still applies for downward references to other classes of document. In both cases, annotations should be added to such References. Tom Petch ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-klensin-norm-ref (Handling Normative References for Standards Track Documents) to BCP
inline Tom Petch - Original Message - From: John C Klensin [EMAIL PROTECTED] To: Sam Hartman [EMAIL PROTECTED]; Tom.Petch [EMAIL PROTECTED] Cc: ietf ietf@ietf.org Sent: Sunday, February 25, 2007 12:00 AM Subject: Re: Last Call: draft-klensin-norm-ref (Handling Normative References for Standards Track Documents) to BCP --On Saturday, February 24, 2007 4:09 PM -0500 Sam Hartman [EMAIL PROTECTED] wrote: Tom == Tom Petch [EMAIL PROTECTED] writes: Tom I have no problem with the underlying idea, in so far as I Tom understand it, but I do not agree that this I-D is the best Tom way to achieve it. Tom I think that my problem is well illustrated by a sentence in Tom the Abstract ' This document replaces the hold on normative Tom reference rule will be replaced by a note downward Tom normative reference and move on approach. ' As may be Tom apparent, this brief - three pages plus boilerplate - I-D, Tom aimed at BCP status, only partly updates or replaces BCP97 Tom (also three pages plus boilerplate) so we will in future have Tom to conflate two documents to understand what is on offer. My strong preference as an individual is to approve this document as is. I think there's a good split between RFC 3967 and this document. RFC 3967 will cover informational documents; this document will cover standards track. I'm not in principle opposed to having one document but I am opposed to the delay it would introduce. Tom, This is very much up to the IESG, but my personal opinion is that we are better off putting this draft through as is and then coming back and revisiting the situation in a year or so, once we have gotten some experience with the combination. My guess -- harking back to the original process experiment theory -- is that some tuning is going to be needed and that there is no point in tangling 3967 up with the tuning process. That assumption is particularly important because Sam's observation of 3967 for informational (and experimental) documents and this for standards-track is what I'm expecting too... but it is an assumption. One can imagine the community responding to a downref under this procedure for a particular document by saying just too dangerous to do it that way; let's use the 3967 procedure in that case. We might be willing to eliminate that possibility once we have some more experience, but I'd think it would be dangerous to do so right now. So, for the present, we have this procedure for standards-track documents when it seems appropriate and 3967 for everything else. In a year or two, if anyone cares, I care:-( I care because I already have a corpus of 47 documents which provide (incomplete) procedures, rules or guidance on how to get something to be an RFC, and regard that as too many, perhaps an order of magnitude so(**). Until RFC3967 is rewritten, or, better still, RFC2026, there will be nothing in RFC3967 to show which parts remain current and, as this I-D stands, there is nothing in the title or abstract to say that either. I have to get into the Introduction before I read This document replaces the long-standing rule for downward references to standards-track documents (including BCPs) that are already published. and even that I had to read several times before I thought I understand it ie that this I-D is about references from any type of document to a Standards Track document. This should be made clear in the Abstract and, I think, in the title eg . Handling Normative References to Standards Track Documents instead of Handling Normative References for Standards Track Documents Tom Petch ** In a well-established mailing list recently, a debate arose over the need to rewrite code if IANA did not allocate the same code point as the editor of the I-D had taken upon themselves to allocate; it would seem an entire WG is unfamiliar with RFC4020; but then again, why should they be? There is an ever increasing number of documents in various categories and only a process geek could hope to know them all (and I would regard process geekery as a pre-requisite for the task of RFC Editor:-). we can fold the two together on the basis of actual experience (or fold both into the long-avoided 2026bis). john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-klensin-norm-ref (Handling Normative References for Standards Track Documents) to BCP
I have no problem with the underlying idea, in so far as I understand it, but I do not agree that this I-D is the best way to achieve it. I think that my problem is well illustrated by a sentence in the Abstract ' This document replaces the hold on normative reference rule will be replaced by a note downward normative reference and move on approach. ' As may be apparent, this brief - three pages plus boilerplate - I-D, aimed at BCP status, only partly updates or replaces BCP97 (also three pages plus boilerplate) so we will in future have to conflate two documents to understand what is on offer. How much simpler it would be for all wishing to use this process if we had just one coherent document, perhaps as long as four pages, covering the whole procedure, perhaps highlighting (for the benefit of those who in future remember that things were once different) what was original BCP97 and what revised BCP97. Tom Petch - Original Message - From: The IESG [EMAIL PROTECTED] To: IETF-Announce ietf-announce@ietf.org Sent: Friday, February 16, 2007 5:02 PM Subject: Last Call: draft-klensin-norm-ref (Handling Normative References for Standards Track Documents) to BCP The IESG has received a request from an individual submitter to consider the following document: - 'Handling Normative References for Standards Track Documents ' draft-klensin-norm-ref-03.txt as a BCP 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 2007-03-16. Exceptionally, comments may be sent to iesg@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-klensin-norm-ref-03.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=14549rf c_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-harrington-text-mib-doc-template (A Template
- Original Message - From: David Harrington [EMAIL PROTECTED] To: 'Tom.Petch' [EMAIL PROTECTED]; 'ietf' ietf@ietf.org Sent: Saturday, February 17, 2007 12:10 AM Subject: RE: Last Call: draft-harrington-text-mib-doc-template (A Template 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. I think that the reference to the web site should be in the I-D/RFC; I had not thought of looking for it there. I think too that we need to make MIB documents easier to produce and so better and that this is along the right lines but that, like RFC4181, it does not quite do it. My thinking is that the editor of such a document wants to see - what they might come up with - how to do it and - why. The how is the XML and belongs on a web site (and could also make a good appendix) but where I most want to change this I-D is the separation of what the end result is from the why, so my proposed appendix would have a section of eg IANA considerations showing the possible end result as submitted to the RFC Editor while the main body has an equivalently numbered section which discusses the rooting of the MIB module in mib-2 or transmission or elsewhere with reference to RFC4181 for the more abstruse ideas.. Ditto other sections. Tom Petch 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: 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
Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC
- Original Message - From: Brian E Carpenter [EMAIL PROTECTED] To: Frank Ellermann [EMAIL PROTECTED] Cc: ietf@ietf.org Sent: Thursday, February 08, 2007 10:12 AM Subject: Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC On 2007-02-08 01:25, Frank Ellermann wrote: John C Klensin wrote: If the IESG intends this document to merely represent the particular procedures they intend to follow within the range of alternatives over which they believe they have discretion, then it should probably be published as an ION Not publishing it at all is an alternative. It would send an unmistakable message to wannabe-authors, that they should use the independent path, unless they're a friend of a friend of an AD. That is a complete mischaracterization. The intent in publishing this (and doing so in parallel with draft-klensin-rfc-independent) is to make it much clearer to authors when they should choose one path and when they should choose another. Brian I agree that that should be the objective but I do not think that the four documents (*) collectively achieve it. The impression created, exaggerating slightly, is that WG submissions matter, individual submissions we have to put up with and independent submissions we would rather not mention. There should be one document that is the starting point for those considering the RFC and IETF processes, one that gives an even-handed treatment of the available routes to varying outcomes, and this is not it. The nearest is draft-klensin-rfc-independent-05.txt and that is where I would point anyone. We may then want separate process documents helping people down their chosen path and draft-iesg-sponsoring-guidelines (assuming that it is accurate, I am not well placed to judge) would fulfil that secondary role. Nor is this new. I have been active here for over five years (and yes I read the website and Tao before starting) but it was only in 2005 that I realised that 'independent' and 'individual' were two different things, and it is John Klensin that I have to thank for making me aware of it. Nothing the IAB or IESG had produced in the previous five years had brought out the distinction. Likewise, it took several years to understand that the phrase 'RFC Editor' carries overtones way beyond the task of editing something on its way to being an RFC. Nothing wrong with giving the phrase a special meaning, but it should be explained in more places. Tom Petch (*) on reflection, I think that there are more like 14 documents in this problem space. Brian ___ 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: draft-ietf-syslog-protocol: Reliable delivery considered harmful.
inline Tom Petch - Original Message - From: Harald Tveit Alvestrand [EMAIL PROTECTED] To: David W. Hankins [EMAIL PROTECTED]; ietf@ietf.org Sent: Sunday, February 04, 2007 9:43 PM Subject: Re: draft-ietf-syslog-protocol: Reliable delivery considered harmful. Daring to rush in without having read the documents it seems to me that somewhere one needs a NOTE, something along the lines of: NOTE: In some situations, for instance when a destination disk is full or damaged, a syslog facility may be unable to process all messages, despite the message transport being reliable. In such a case, it is reasonable for the logger of a message to have the option of either not logging more messages or ceasing its own operation. This document does not specify which option to take. Or words to that effect. Harald Harald It might be worth reading the I-D:-) I am not clear which piece of text in the I-D provoked the original comment. I do not see the I-D recommending reliable transport, with all the problems that have been identified with that. Rather, under security, the I-D points out that with an unreliable transport, losing critical messages may adversely impact operation. It then goes on to say It may be desirable to use a transport with guaranteed delivery to mitigate congestion. It may also be desirable to include rate-limiting features in syslog senders. This can reduce potential congestion problems when message bursts happen. I find it hard to square this with the original statement that 'draft-ietf-syslog-protocol-19.txt recommends using a reliable protocol' If we were to put in a comment about reliable transports introducing problems with blocking, then I think that that should be in an I-D which specifies a reliable transport, eg the soon to be completed one on TLS (there are no plans for one with TCP). Tom Petch --On 2. februar 2007 09:59 -0800 David W. Hankins [EMAIL PROTECTED] wrote: On Fri, Feb 02, 2007 at 08:31:49AM +0100, Stephane Bortzmeyer wrote: Wether it is a bug or a feature depends on your requirments. On some high-security environments, people prefer to suspend the service rather than not being able to log it. (Otherwise, an attacker could easily attempt many attacks, fill in the hard disk and then perform the real attack unlogged). I'd just like to point out that you're choosing one bug over another. A DOS in preference to lack of observance of events. In my opinion, that's a bad selection, but it's your selection to make. That kind of preference, that kind of choice, is a good thing to have, but it would be unwise to apply to the general case a systematic selection of DOS over observation. -- David W. Hankins If you don't do it right the first time, Software Engineer you'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins ___ 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: Tracking resolution of DISCUSSes
Who is shepherd for an individual submission? Tom Petch - Original Message - From: Jeffrey Hutzelman [EMAIL PROTECTED] To: Sam Hartman [EMAIL PROTECTED]; Henrik Levkowetz [EMAIL PROTECTED] Cc: Frank Ellermann [EMAIL PROTECTED]; ietf@ietf.org; Jeffrey Hutzelman [EMAIL PROTECTED] Sent: Wednesday, January 17, 2007 3:31 AM Subject: Re: Tracking resolution of DISCUSSes On Friday, January 12, 2007 04:04:08 PM -0500 Sam Hartman [EMAIL PROTECTED] wrote: Let me ask a silly question here: Why do we want to distinguish proto shepherds from chairs? I at least hope all my WGs will produce documents. That means most of my chairs will be proto shepherds. Does the difference matter? I guess that depends on how much you want to depend on access controls vs people not doing things they're not supposed to. I believe the process admits the occasional shepherd who is not a chair or AD; if nothing else, I could imagine a chair who steps down but continues to shepherd his documents which are already partway through the process. Certainly not every chair will shepherd every document produced by his WG. So, a WG chair has certain rights with respect to documents in his WG. And a shepherd has certain rights with respect to documents he shepherds. The question is, is the difference great enough that we can't simply give all of those people the same powers, at least with respect to any given WG? Note that even if we just give all the shepherding powers to chairs, we still may need the concept of a shepherd who is not a chair, because I presume the tracker will inherit its idea of who is chair of what from other sources. It may be desirable, both here and in other cases, to be able to give someone some of the bits that go along with a role without actually publishing their name as a point of contact. Having that ability encourages people to delegate authorization instead of giving away their credentials. -- Jeff ___ 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: Identifying mailing list for discussion(Re: Tracking resolution of DISCUSSes)
inline Tom Petch - Original Message - From: Henning Schulzrinne [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: lconroy [EMAIL PROTECTED]; ietf@ietf.org Sent: Tuesday, January 16, 2007 6:36 PM Subject: Re: Identifying mailing list for discussion(Re: Tracking resolution of DISCUSSes) The table of mappings constitutes an on-going administrative challenge. Also as noted, not all I-Ds are tied to working groups. But every draft should be able to fit into one of the IETF areas; Not sure about the should but the really is that they do not. One close to my heart is URI which belongs in every area which has a protocol:-) The practicality is that it is hosted outside the IETF and a recent post there, relating to a very worthy piece of work, asked how to get this to be an RFC. Such questions show that we are not doing as well as we SHOULD. all areas have, as far as I know, area-wide mailing lists. At least for TSV, the list has often been used as a catch-all for things that didn't quite fit elsewhere. Setting up a mailing list for each personal draft, with unclear 'note well' rules and archiving status, seems counterproductive. 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Fwd: The IESG Approved the Expansion of the AS Number Registry
From: Henk Uijterwaal [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: ietf@ietf.org Sent: Wednesday, November 29, 2006 2:30 PM Subject: Re: Fwd: The IESG Approved the Expansion of the AS Number Registry snip There is: Canonical Textual Representation of 4-byte AS Numbers draft-michaelson-4byte-as-representation-02 describing the format of ASN32 and RPSL extensions for 32 bit AS Numbers draft-uijterwaal-rpsl-4byteas-ext-01.txt describing what has to be changed in RPSL based tools for ASN32. For the latter draft, there is no good place in the IETF right now, but I do welcome comments. Henk Henk draft-michaelson-4byte-as-representation-02 was last called on the idr list so that is where I think that draft-uijterwaal-rpsl-4byteas-ext-01.txt should be discussed However, draft-michaelson-4byte-as-representation-02 did come in for criticism (some relayed from NANOG), with perhaps not enough consensus for it to go forward. Its current status is 'Awaiting writeup' (by AD). Alternatively, there are some fine RIPE lists where this could be raised:-) Tom Petch -- Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The NetherlandsThe NetherlandsMobile: +31.6.55861746 -- # Lawyer: Now sir, I'm sure you are an intelligent and honest man-- # Witness: Thank you. If I weren't under oath, I'd return the compliment. ___ 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: 'Progressive Posting Rights Supsensions' to BCP (draft-carpenter-rescind-3683)
- Original Message - From: The IESG [EMAIL PROTECTED] To: IETF-Announce ietf-announce@ietf.org Sent: Saturday, October 21, 2006 12:29 AM Subject: Last Call: 'Progressive Posting Rights Supsensions' to BCP (draft-carpenter-rescind-3683) The IESG has received a request from an individual submitter to consider the following document: - 'Progressive Posting Rights Supsensions ' draft-carpenter-rescind-3683-03.txt as a BCP This document abolishes the existing form of indefinite Posting Rights Action and restores the previous option of finite posting rights suspensions authorized by an Area Director. It obsoletes RFC 3683 and updates RFC 2418 and RFC 3934. Publication of this document will classify RFC 3683 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 iesg@ietf.org or ietf@ietf.org mailing lists by 2006-11-17. During IESG evaluation, an AD raised the concern that the consensus shown during the last call of this document might not be strong enough to justify approval. In order to determine the strength of the consensus, the IESG asks the community to focus on the following questions in last call responses: 1) Do you support the proposal in section 2 of the draft to restore the AD and IESG's ability to suspend posting rights for longer than 30 days and to approve alternative methods of mailing list control as originally documented in RFC 2418? Not as it is documented in this I-D; the wording is not careful enough - eg RFC2418 spells out that direct communication should be off list; RFC3934 may have removed this but it should reinstated to improve clarity. 2) Do you support the proposal in section 3 to rescind RFC 3683? No; RFC3683 does not remove or modify the toolkit available, it adds a new one. The bald statement that the present IESG have found it 'troublesome and contentious in practice' is inadequate to justify its repeal. 3) Do you have any concerns about approving one part of the draft without approving the other? Yes, most definitely. 4) Do you have any other comments on the document? Rather than patch RFC2418, that RFC should be reissued; this is a key process for the IETF and we should not have to try and work out from multiple RFC what the current state is. Tom Petch The file can be obtained via http://www.ietf.org/internet-drafts/draft-carpenter-rescind-3683-03.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Proceeding CDs
CDs of Proceedings always seemed like an excellent idea but: - sometimes they never arrived - I cannot ever recall them arriving in good time, that is closer to the time of the meeting they relate to than to that of the next meeting. Tom Petch - Original Message - From: IETF Administrative Director [EMAIL PROTECTED] To: ietf@ietf.org Sent: Wednesday, October 04, 2006 12:35 AM Subject: Proceeding CDs The IAOC is preparing the 2007 budget and would like feedback on whether or not to continue producing the IETF meeting CDs of the Proceedings. It has been suggested as a way of employing limited Secretariat labor more productively that the IAOC discontinue production of the Proceedings on CDs and, instead, make the files available collectively on the web site for each meeting in a zip file for downloading. Is there strong rationale for maintaining production of the CDs? Ray Pelletier IAD ___ 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: Novell IETF bag
- Original Message - From: Ned Freed [EMAIL PROTECTED] To: Philip Matthews [EMAIL PROTECTED] Cc: IETF Discussion ietf@ietf.org Sent: Saturday, July 29, 2006 4:25 PM Subject: Re: Novell IETF bag After four and a half years of solid use, one of the fasteners on the strap of my Novell IETF bag (from IETF 52) has finally given out. Since I am otherwise in love with this bag, I am trying to find a replacement strap. Does anyone happen to know who manufactured this bag and/or where one might find a replacement strap? And is there an equivalent bag available for general purchase when my bag finally bites the dust? I would also like to know where to get an equivalent. I use mine every day and sooner or later it is going to fall apart. PS. Kudos to the person at Novell responsible for giving out these bags at IETF 52. I have never worked for Novell, but with such a solid and feature-rich bag, I have no problems walking around with a bag with Novell written all over it. Yep, without doubt one of the best giveways we've ever had. Fascinating. I too got a Novell bag and it was so bulky and heavy that I considered leaving it in the hotel room. I eventually managed to squeeze it into my luggage without exceeding the weight limit and, once gotten home, left it to gather dust - after all the hassle, I could not bring myself to throw it away. But since an ocean separates us, I don't think that my idle specimen can be of much service to you. Now were the IETF to meet in London, Tom Petch Ned ___ 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: RFC Editor RFP Review Request
inline Tom Petch - Original Message - From: Tony Hansen [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; ietf@ietf.org; iesg@ietf.org Sent: Wednesday, July 19, 2006 4:07 PM Subject: Re: RFC Editor RFP Review Request I use ftp all the time to access the RFCs. I use direct web URLs all the time to access the RFCs. I *occasionally* use rfc-editor.org's web interface. I agree with Henrik. I used to use ftp all the time to access the RFCs but then it stopped working about two months ago and messages on this list, from others as well as me, and to the relevant e-mail address have had no effect. So I think that ftp MUST be in the RFP. It is a technology that has proved its worth and even if and when son of http comes along and provides us with a different way of access, ftp will still have a role. Tom Petch Tony Hansen [EMAIL PROTECTED] Henrik Levkowetz wrote: It may be that the level of detail specification should be less than what it is now, overall; but with the current specification level I felt it is a clear omission to not specify *any* access to the documents except through a search facility. I feel that direct ftp/http/rsync access is actually more important than the search facility specified in the proposed SOW, which is why I commented on this. ___ 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 IPv6 platform configuration
FTP over IPv4 stopped working for me about four weeks ago. Like you, I get 'failed to establish connection' immediately. I flagged it as a problem and have had no response. I can access shadow sites ok Tom Petch - Original Message - From: Ken Raeburn [EMAIL PROTECTED] To: ietf Mailing List ietf@ietf.org Cc: [EMAIL PROTECTED] Sent: Wednesday, July 05, 2006 3:55 PM Subject: Re: IETF IPv6 platform configuration On Jun 11, 2006, at 20:00, IETF Secretariat wrote: All, As you’re all aware, on 06/06/06 NSS successfully launched IPv6 services for IETF Web, Mail, and FTP. Has anyone had FTP work for them when not in passive mode since this configuration change was made? My site's got a clunky old ftp-based mirror script in use which at first glance doesn't seem to know anything about passive mode, and it hasn't fetched any new RFCs since a month ago. Running ftp directly (over ipv4, from a couple of machines, one of which has no ipv6 configuration and no recent software changes) doesn't work either, commands like LIST get back failed to establish connection immediately. I'm probably going to throw away the mirror script anyway and switch to rsync, but I'm still curious to know whether this is some weird problem with our configuration (maybe a surprise related to the ipv6 changes?), or an intentional (but unannounced?) or unintentional configuration change in ftp support at the server side Ken ___ 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: are we willing to do change how we do discussions in IETF? (was: moving from hosts to sponsors)
- Original Message - From: Keith Moore moore@cs.utk.edu To: Robert Sayre [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; ietf@ietf.org Sent: Tuesday, June 27, 2006 1:38 AM Subject: Re: are we willing to do change how we do discussions in IETF? (was: moving from hosts to sponsors) I'm much more interested in trying to figure out how to get WGs to stay on track in the first place and to accept useful clue from elsewhere. I maintain that no process will accomplish that. The only way to get a WG to accept a clue is to demonstrate that their output is irrelevant by concrete example. no process can ensure that WGs stay on track, but we can certainly do better than what we have now. I think that the single change most likely to keep WGs on track is to ensure that they do not have a single dominant participant, eg one who is both chair and author of key I-Ds. The WGs I see most at risk of going round in circles and/or producing output that falls short of what is needed are ones such. Some time ago, I did hear an IESG member talk of this in such a way as to make me think that this was an understood problem, but nothing seems to have changed in the two or so years since then. And, of course, I believe that there is more to good engineering than just engineering eg the right processes. Tom Petch. Keith ___ 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: Image attachments to ASCII RFCs (was: Re: Last Call: 'ProposedExperiment: Normative Format in Addition to ASCII Text' toExperimental RFC (draft-ash-alt-formats))
inline Tom Petch - Original Message - From: Iljitsch van Beijnum [EMAIL PROTECTED] To: John C Klensin [EMAIL PROTECTED] Cc: IETF-Discussion Discussion ietf@ietf.org Sent: Tuesday, June 20, 2006 12:18 AM Subject: Re: Image attachments to ASCII RFCs (was: Re: Last Call: 'ProposedExperiment: Normative Format in Addition to ASCII Text' toExperimental RFC (draft-ash-alt-formats)) On 19-jun-2006, at 20:09, John C Klensin wrote: (2) If I prepare an RFC draft using some mechanism which produces a document in form X, where X might include snip Two prominent problems associated with the ASCII format are that it doesn't really support formulas and figures. I was intrigued with the earlier Unicode examples, so I decided to do some checking of my own with regard to unicode art for figures. Have a look at: http://www.muada.com/drafts/utf8-art.txt http://www.muada.com/drafts/utf16-art.txt I think this is closer to what an RFC with Unicode line art would look like than trying to present an example in email. For me, the UTF-8 encoding isn't immediately decoded properly by my browser, but the UTF-16 version is. I also can't get this displayed properly on the command line on my Mac. Still, it's not _too_ hard to have the Unicode characters displayed properly. I agree in principle that adding a selected subset of Unicode would address the most pressing issues. But, for whatever reason, I get gibberish on both the URLs you give. By contrast, the figure embedded in an e-mail earlier displayed perfectly (until it got mangled when included in a reply). This suggests to me that the world is not quite ready for Unicode yet (I am using vanilla Windows software, as most of the world does:-(. Tom Petch The Unicode line art looks a lot better than ASCII-only line art, but it shares many of the same limitations, such as only (reasonably) being able to display rectangular shapes and horizontal/vertical lines. There are some exceptions such as the ability to use rounded corners, but true round shapes or even usable diagonal lines don't seem to be supported. This also means that it should be generally possible to convert from Unicode to ASCII-only line drawings without much loss of information. There has been some talk about specifying a font for displaying Unicode, but on my Mac at least, that doesn't seem to be necessary. An important issue with different fonts is the difference in character width for different characters, but the line art characters are mostly the same width so this isn't an issue. However, the width of the space character can vary, but there's probably a fixed width space in the table somewhere. Also, it looks like there is only a single glyph for these types of characters that is shared between fonts. I.e., whether I use Courier or Times, the line drawing characters look the same. It does seem to me that looking into Unicode for better formula and drawing support makes a lot of sense. This allows us to make better looking RFCs without radically changing the way RFCs are published. However, I think we probably want to change the process for other reasons. I think it would be very useful to have the source of an RFC available with style tagging and so on in order to more easily derive future work. It's probably also a good idea to have blessed PDFs or some similar format for pretty printing, especially for the RFCs that contain formulas and drawings. And we may want to make those formulas and drawings available as simple bitmap images so they can be easily viewed on systems with limited capabilities. But with all of that in place, it's probably a good idea to keep having the ASCII version of RFCs be the normative version. Anyway, that's my $0.02 Canadian on this subject. ___ 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: 'Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations' to Proposed Standard
Randy I would suggest some wording if I knew what was intended but as yet, I don't:-(. I suspect that Bill's description - use the next available integer in sequence - may be what is intended but, for me, that is not the sense of the words. Off list:-(, I did get a different interpretation - from one who was involved in the earlier discussion of monotonic - that any index value would do as long as the order of the entries in the table matched the order of the hops. So I still think that there is a minor ambiguity here Tom Petch - Original Message - From: Randy Presuhn [EMAIL PROTECTED] To: Bill Fenner [EMAIL PROTECTED]; [EMAIL PROTECTED]; Tom.Petch [EMAIL PROTECTED]; Bill Strahm [EMAIL PROTECTED]; iesg iesg@ietf.org; ietf ietf@ietf.org Cc: Disman disman@ietf.org Sent: Tuesday, February 28, 2006 10:16 PM Subject: Re: Last Call: 'Definitions of Managed Objects for Remote Ping,Traceroute, and Lookup Operations' to Proposed Standard Hi - If the document gives a false impression that the values of traceRouteHopsHopIndex could be interpreted as hop numbers, an editorial change to dispel that notion would make sense. (Likewise, if consecutive integers starting at one was the intent, and is what current implementations actually do, then we should say so.) I can see how the last two sentences of the last paragraph of the DESCRIPTION might lead to such a reading. Does someone have some replacement text they'd like to propose to make things clearer? Randy, disman chair - Original Message - From: Bill Fenner [EMAIL PROTECTED] To: [EMAIL PROTECTED]; Tom.Petch [EMAIL PROTECTED]; Bill Strahm [EMAIL PROTECTED]; iesg iesg@ietf.org; ietf ietf@ietf.org Sent: Monday, February 27, 2006 10:48 PM Subject: Re: Last Call: 'Definitions of Managed Objects for Remote Ping,Traceroute, and Lookup Operations' to Proposed Standard Juergen, I assumed, from reading in traceRouteHopsHopIndex about the behavior when a path changes, that the only safe thing for a manager to do is to read the hops from the table and render them to the user in order of increasing traceRouteHopsHopIndex but without necessarily showing the traceRouteHopsHopIndex to the user -- that it was perfectly reasonable for hops 1,2,3,4 of a 4-hop path to be numbered 1,8,12,35 (assuming that they started 1,2,3,4 but there were lots of path changes during the test). I think some people are assuming that the intention was that the values should be 1,2,3,4 (i.e., HopIndex == hop number) and that's why they're asking for a different definition. Perhaps the right direction could be to clarify that there is no connection between the value of HopIndex and traceroute hop, other than the ordering. Bill ___ 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: 'Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations' to Proposed Standard
- Original Message -
From: Bill Strahm [EMAIL PROTECTED]
To: Robert Elz [EMAIL PROTECTED]
Cc: iesg iesg@ietf.org; ietf ietf@ietf.org
Sent: Monday, February 27, 2006 12:48 AM
Subject: Re: Last Call: 'Definitions of Managed Objects for Remote Ping,
Traceroute, and Lookup Operations' to Proposed Standard
Robert Elz wrote:
I cannot see why there's a debate going on here. If someone, anyone,
can read a spec, and, in good faith, point out a possible ambiguity in
the text, before the doc is finalised, and if fixing it to avoid the problem
is easy, what possible justification can there be for not adding a few
words to clarify things, and make sure that confusion does not happen?
Whenever someone points out a problem like this, the response should be
something like OK, if we write it like ... does that make it clear? or
perhaps What would you suggest as clearer wording? but never It is
clear enough as it is as the latter is already demonstrated to be false.
My mother can't read internet drafts either. Should we change our
language so that my mother can read and comprehend them.
It is assumed that there is a baseline knowledge when we write drafts...
If you don't know how MIBs work in general - there are a LOT of problems
that you have to sort out before you can provide technical feedback to
the community. Someone who is practiced in the art of
reading/writting/implementing MIBs isn't going to have a problem with
strictly monotonically increasing Indexes - knowing what that means, and
how to implement it and test the implementation for correctness.
Somone who has been watching a rant on the list recently invovling the
work monotonically increasing, MIGHT see the word and get confused. I
am not to worried about that - the document really isn't for their eyes
anyway (I'm not about to comment on various security drafts either -
should they be simplified so I can understand them, I hope I am expected
to put in the work so that I understand them instead)
Certainly it is possible to explain the wording on the list, and convince
the objector that very careful understanding of the context makes the
intent clear - but that does nothing for the next person who comes along
and makes the same interpretation mistake (perhaps without even
realising the possibility for ambiguity, but simply interpreting the text
a different way).
Bill
My own mathematical background taught me that monotonic increasing was always
equal or greater than (as opposed to strictly increasing), so Yaakov Stein's
post (on 'monotonic increasing') opened my eyes somewhat:-) but also left me
thinking, more strongly than before, that monotonic is not a good word to use in
RFC when there is a simpler substitute available (eg strictly increasing, if
that is what is meant).
In this case, I am familiar with MIBs and so know that the index must be unique,
ie that the combination of
INDEX { traceRouteCtlOwnerIndex, traceRouteCtlTestName, traceRouteHopsHopIndex}
must be unique within that table, of the results of traceroute tests on a per
hop basis.
Here my impression is that the traceRouteHopsHopIndex be a numbered integer
sequence, 'MUST start at 1' and then going 2,3,4,5,6 ... and monotonic is
intending to convey this (but this is not a sense of monotonic that anyone came
up with in the recent thread).
Alternatively, if a hop, eg 3, does not respond, then is the intention that that
the entries go 1,2,4,5,6?
I don't know, and calling the sequence monotonic confuses me. Juergen sees the
meaning of the words as unambiguous. I don't - hence my post.
Tom Petch
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations' to Proposed Standard
I find the following unclear and would like to see it spelt out in detail traceRouteHopsHopIndex snip MUST start at 1 and increase monotonically. Recent discussions on the ietf main list identified two meanings for 'monotonically' - a sequence where each value is greater than or equal to its predecessor, or a sequence where each value is strictly greater than its predecessor - and I am unsure whether this means either or neither. Tom Petch - Original Message - From: The IESG [EMAIL PROTECTED] To: IETF-Announce ietf-announce@ietf.org Cc: disman@ietf.org Sent: Thursday, February 23, 2006 9:21 PM Subject: Last Call: 'Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations' to Proposed Standard The IESG has received a request from the Distributed Management WG to consider the following document: - 'Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations ' draft-ietf-disman-remops-mib-v2-09.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-03-09. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-disman-remops-mib-v2-09.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: 'monotonic increasing'
- Original Message - From: Frank Ellermann [EMAIL PROTECTED] To: ietf@ietf.org Sent: Tuesday, February 21, 2006 3:57 PM Subject: Re: 'monotonic increasing' Marshall Eubanks wrote: a RFC-2119 type RFC to define mathematical terms ? Maybe more like some glossaries (Internet, security, I18N, ...), informational RFCs. But I think that's unnecessary. There are online math. dictionaries, authors can provide references for unlear terms, or say what they mean. Otherwise this thread is unlikely to do much to change the situation. It highlights why clear terms in RFC are good, defined by reference or inline. In some groups saying 'header' instead of 'header field', 'byte' instead of 'octet', or 'charset' instead of IIRC 'encoded character repertoire' is enough to start a thread. And 'monotonic increasing' instead of 'strictly (monotonic) increasing' is apparently a similar issue. Bye, Frank What I see from this thread is that there are two common interpretations to the phrase 'monotonic increasing', either a sequence in which each number is greater than or equal to its predecessor, or one in which each number is strictly greater than its predecessor, with the former meaning having somewhat the greater support (at least amongst those with access to text books): which, of itself, makes it a risky term to use in a specification. I still think that it is sometimes used in RFC and I-D in a third sense, of a sequence of integers increasing by one each time, not a meaning anyone has supported. But only the editor can know what is really intended. So, the next time I see it used, perhaps in a Last Call of a pkix, kink or secsh I-D, I will seek further clarification. Tom Petch ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: 'monotonic increasing'
- Original Message - From: Yaakov Stein [EMAIL PROTECTED] To: Tom.Petch [EMAIL PROTECTED]; Elwyn Davies [EMAIL PROTECTED] Cc: ietf ietf@ietf.org Sent: Sunday, February 19, 2006 7:10 AM Subject: RE: 'monotonic increasing' Actually, even mathematicians don't agree on the wording here. In analysis we commonly talk about monotonic functions, which can be either monotonically increasing ( x = y = f(x) = f(y) ) or monotonically decreasing ( x = y = f(x) = f(y) ). Since analysis deals with continuous entities, the distinction of nondecreasing vs. increasing is usually not important, and thus not worried about. However physicists tend to make the distinction by saying nondecreasing. In dealing with sequences, the distinction is almost universally made between nondecreasing ( x_n = x_n+1) and increasing (x_n x_n+1) although the European school prefers stressing the difference by using the word strictly instead. To make things more confusing, in order theory (where you would expect the wording to be the tightest) the wording used is monotone (for increasing) and antitone (for decreasing). Of course there the distinction between nondecreasing and increasing is not important since the description is of a (partial) order relation, and if that relation includes equality as a special case than you get one variety, while if not you get the other. Y(J)S Beautiful (as mathematics always is). But just to be clear, if you saw a reference to 'monotonic increasing' in an American journal, say of applied mathematics, would you be sure you understood what was meant? And if so, would that be S_i+1 = S_i U+2200 i or S_i+1 S_i U+2200 i? Tom Petch ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
'monotonic increasing'
The phrase 'monotonic increasing' seems to be a Humpty-Dumpty one, used with a different sense within RFC to that which I see defined elsewhere; and this could lead to a reduction in security. Elsewhere - dictionaries, encyclopaedia, text books - I see it defined so that when applied to a sequence of numbers, then each number is not less than its predecessor, so that 1 1 1 1 1 1 1 1 1 1 1 1 2 3 5 8 13 1 2.71828 3.14159 4.18 42 are all monotonic increasing sequences whereas 1 2 3 4 5 6 7 9 8 10 is not. Within RFC, mostly those related to security or network management, the context of its use implies, in addition, one or more of a) each number in the sequence is different (as in number used once) b) each number is an integer c) each number is one greater than its predecessor (as in message sequencing) . Most likely, an implementation that conforms to the rest of the world definition would interwork with one that conforms to the RFC one, but with some loss of security, since numbers that are intended to be used only once could be reused. Q1) Can anyone point me to an authoritative source that endorses the RFC usage? Q2) Even so, since the rest of the world usage seems to be so widely defined, should we change our terminology, eg specifying seqences to be strictly increasing when that is what is needed? Tom Petch ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: 'monotonic increasing'
Elwyn To be more concrete, I have some 1800 RFC readily available and find monotonic in 54 of them from RFC677 (1975) to RFC4303. Plucking a few at random, RFC3412 (SNMP) suggests that monotonic increasing would avoid reuse while RFC2406 (IPsec) suggests monotonic increasing can be used in the context of replay attacks. (I accept that in the latter, as in many cases, understanding the context, the whole document or set of RFC, does imply that the sequence should be strictly increasing). RFC2679 (IPPM) is more mathematical in its approach, where I would expect the term to be informed by its use in mathematical textbooks, but it appears not to be Tom Petch - Original Message - From: Elwyn Davies [EMAIL PROTECTED] To: Tom.Petch [EMAIL PROTECTED] Cc: ietf ietf@ietf.org Sent: Friday, February 17, 2006 8:19 PM Subject: Re: 'monotonic increasing' Hi. Tom.Petch wrote: The phrase 'monotonic increasing' seems to be a Humpty-Dumpty one, used with a different sense within RFC to that which I see defined elsewhere; and this could lead to a reduction in security. Elsewhere - dictionaries, encyclopaedia, text books - I see it defined so that when applied to a sequence of numbers, then each number is not less than its predecessor, so that 1 1 1 1 1 1 1 1 1 1 1 1 2 3 5 8 13 1 2.71828 3.14159 4.18 42 are all monotonic increasing sequences whereas 1 2 3 4 5 6 7 9 8 10 is not. On the definition of monotonic increasing: I just checked my memory with my copy of Apostol (Mathematical Analysis, vintage 1968 or so) and monotonic increasing implies element (n+1) greater than or equal to element n for all n. 'Strictly monotonic increasing' implies greater than. On line http://www-history.mcs.st-and.ac.uk/~john/analysis/Lectures/L8.html confirms this. Within RFC, mostly those related to security or network management, the context of its use implies, in addition, one or more of a) each number in the sequence is different (as in number used once) b) each number is an integer c) each number is one greater than its predecessor (as in message sequencing) . Most likely, an implementation that conforms to the rest of the world definition would interwork with one that conforms to the RFC one, but with some loss of security, since numbers that are intended to be used only once could be reused. Q1) Can anyone point me to an authoritative source that endorses the RFC usage? Q2) Even so, since the rest of the world usage seems to be so widely defined, should we change our terminology, eg specifying seqences to be strictly increasing when that is what is needed? I just did a full text search of all the RFCs using the zvon repository which covers up to RFC3999. the fragment 'monotonic' (including 'monotonically') appears in RFCs 1323, 1379, 1644, 1889, 2326, 2681, 3571 and 3550. All these cases (either about timestamps or TCP sequence numbers) appear to use monotonically increasing in line with the mathematical definition although it is possible that a couple of them (e.g., RFC3571, s4) ought to use strictly monotonic, although the usage is clear from the additional words. In many cases the phraseology is explicitly used because the sequence (of tiimestamps used, for example) does not have every possible integer represented. Do you have a concrete example of your problem? Regards, Elwyn 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: 'monotonic increasing'
I agree that there is no clear cut case where security will be compromised, but as long as RFC eg RFC1510 (kerberos) tie the concept of nonce to a monotonic increasing sequence, I think the risk is there and could easily be avoided if we started using the term 'strictly increasing' instead. Of the RFC I have looked at, RFC3412 (SNMP) is probably the one I would most question, since it suggests that a monotonically increasing integer will avoid a reuse of outstanding values; for me, this is a clear case of 'strictly increasing'. Tom Petch - Original Message - From: Elwyn Davies [EMAIL PROTECTED] To: Tom.Petch [EMAIL PROTECTED] Cc: ietf ietf@ietf.org Sent: Friday, February 17, 2006 9:50 PM Subject: Re: 'monotonic increasing' Hmm! I don't think I see your problem with any of the usages in the RFCs mentioned. In all cases monotonically is used to express that the sequence is non-decreasing which is in line both with the mathematical definition and the Merriam-Webster online dictionary #2 sense. In some of the cases the sequence required is actually strictly monotonically increasing but the other words make this clear, and since strictly monotonic sequences are also monotonic, it is not wrong. The only one where there could be (IMO) a soupçon of doubt is RFC2679 where it isn't absolutely clear whether or not T in the (n+1)-th pair needs to be strictly greater than T in the nth pair, and I suspect it doesn't matter in this case - it certainly wouldn't break interoperability. Regards, Elwyn Tom.Petch wrote: Elwyn To be more concrete, I have some 1800 RFC readily available and find monotonic in 54 of them from RFC677 (1975) to RFC4303. Plucking a few at random, RFC3412 (SNMP) suggests that monotonic increasing would avoid reuse while RFC2406 (IPsec) suggests monotonic increasing can be used in the context of replay attacks. (I accept that in the latter, as in many cases, understanding the context, the whole document or set of RFC, does imply that the sequence should be strictly increasing). RFC2679 (IPPM) is more mathematical in its approach, where I would expect the term to be informed by its use in mathematical textbooks, but it appears not to be Tom Petch - Original Message - From: Elwyn Davies [EMAIL PROTECTED] To: Tom.Petch [EMAIL PROTECTED] Cc: ietf ietf@ietf.org Sent: Friday, February 17, 2006 8:19 PM Subject: Re: 'monotonic increasing' Hi. Tom.Petch wrote: The phrase 'monotonic increasing' seems to be a Humpty-Dumpty one, used with a different sense within RFC to that which I see defined elsewhere; and this could lead to a reduction in security. Elsewhere - dictionaries, encyclopaedia, text books - I see it defined so that when applied to a sequence of numbers, then each number is not less than its predecessor, so that 1 1 1 1 1 1 1 1 1 1 1 1 2 3 5 8 13 1 2.71828 3.14159 4.18 42 are all monotonic increasing sequences whereas 1 2 3 4 5 6 7 9 8 10 is not. On the definition of monotonic increasing: I just checked my memory with my copy of Apostol (Mathematical Analysis, vintage 1968 or so) and monotonic increasing implies element (n+1) greater than or equal to element n for all n. 'Strictly monotonic increasing' implies greater than. On line http://www-history.mcs.st-and.ac.uk/~john/analysis/Lectures/L8.html confirms this. Within RFC, mostly those related to security or network management, the context of its use implies, in addition, one or more of a) each number in the sequence is different (as in number used once) b) each number is an integer c) each number is one greater than its predecessor (as in message sequencing) . Most likely, an implementation that conforms to the rest of the world definition would interwork with one that conforms to the RFC one, but with some loss of security, since numbers that are intended to be used only once could be reused. Q1) Can anyone point me to an authoritative source that endorses the RFC usage? Q2) Even so, since the rest of the world usage seems to be so widely defined, should we change our terminology, eg specifying seqences to be strictly increasing when that is what is needed? I just did a full text search of all the RFCs using the zvon repository which covers up to RFC3999. the fragment 'monotonic' (including 'monotonically') appears in RFCs 1323, 1379, 1644, 1889, 2326, 2681, 3571 and 3550. All these cases (either about timestamps or TCP sequence numbers) appear to use monotonically increasing in line with the mathematical definition although it is possible that a couple of them (e.g., RFC3571, s4) ought to use strictly monotonic, although the usage is clear from the additional words. In many cases the phraseology is explicitly used because the sequence (of tiimestamps used, for example) does not have every
Re: IETF65 hotel location
- Original Message - From: Bob Braden [EMAIL PROTECTED] To: ietf@ietf.org Cc: [EMAIL PROTECTED] Sent: Monday, January 30, 2006 6:16 PM Subject: Re: IETF65 hotel location I don't understand why this discussion keeps going on and on, much less why it started in the first place. Folks, surely we have more important issues of Internet technology to talk about, rather than jaw-boning about a task that we have delegated to a competant organization. That organization has in general done an excellent job over the past many years, and I for one am confident they will continue. They are sensitive to input, but they get the job done. Site selection and contracting requires a difficult balancing act to perform, between the ideal and the real. As far as I can see, they do a much better job of than the IETF could possibly hope for. I am thankful for their dedication and expertise. Let's stop spending our resources micro-managing the Secretariat, and deal with the problems that we are supposed to be solving. Bob Braden Bob (tongue only partly in cheek) I wonder if you have the same feelings about virus'; after all, no rational person would be fooled into doing what the spammers want and so sending virus' on their way - yet they do propagate. Trouble is, humans are not always rational, scientific, technological, engineering beings. They also have a dark side, one which repays study and the findings of which are collected in the sometimes under-rated discipline of psychology. Any experienced meeting chair will know that there are times when a meeting has a mind of its own and gets its teeth into some irrelevant topic. Such a chair will also know that it needs a very forceful personality to stop this; better usually to let the fire burn for a while, and then intervene to get things back on track, as the flames die down. But the chair will also know that this behaviour is a symptom, a displacement of some other issue that it is worth trying to identify and deal with. In face-to-face meetings, it is possible to look for physical clues in the people, to cast back over what happened just beforehand and maybe get some insight. On mailing lists, this is much more difficult but sometimes still possible. So while I see the frustration that you, Bert and others express, these times are for me a chance to reflect on what lies at the bottom of the behaviour and what I could do about it. No clues on this occasion but perhaps one day I will study the archives and see enough to produce an I-D on it. Tom Petch ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
ABNF Re: Troubles with UTF-8
You say that a Unicode code point can be represented by %xABCD but that is not spelt out in ABNF [RFC4234]. And when it refers to 'one printable character' as '%x20-7E' I get the impressions that coded character sets like Unicode, with more than 256 code points, do not fall within its remit. I have yet to see any use of this in an I-D or RFC. I did post a question about this to this list on 24th December and the lack of response reinforces my view that this is uncharted territory. Tom Petch - Original Message - From: James Seng [EMAIL PROTECTED] To: Tom.Petch [EMAIL PROTECTED] Cc: ietf ietf@ietf.org Sent: Wednesday, January 04, 2006 6:50 AM Subject: Re: Troubles with UTF-8 On 12/23/05, Tom.Petch [EMAIL PROTECTED] wrote: A) Character set. UTF-8 implicitly specifies the use of Unicode/IS10646 which contains 97,000 - and rising - characters. Some (proposed) standards limit themselves to ..007F, which is not at all international, others to -00FF, essentially Latin-1, which suits many Western languages but is not truly international. Is 97,000 really appropriate or should there be a defined subset? Why should there be a subset? You really really dont want to go into a debate of which script is more important then the other. B) Code point. Many standards are defined in ABNF [RFC4234] which allows code points to be specified as, eg, %b00010011 %d13 or %x0D none of which are terribly Unicode-like (U+000D). The result is standards that use one notation in the ABNF and a different one in the body of the document; should ABNF allow something closer to Unicode (as XML has done with #000D;)? Following RFC4234, Unicode code point U+ABCD will just be represented as %xABCD. I do not see the problem you mention or am I missing something? snip http://www.unicode.org/charts/ -James Seng ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Alternative formats for IDs
I have always thought that ASCII had much to commend it - ease of use, compactness, open standard - which outweighed its limited functionality. But while we debate this, have events already overtaken us? I was surprised to find, when reading draft-fu-nsis-qos-nslp-statemachine-02.txt repeated statements to the effect that if you want to see what this looks like, look at the .pdf version. It would seem that the system is giving tacit support to .pdf (although I am cannot readily see just where the .pdf version is filed:-( What will anyone say when this I-D reaches last call? Tom Petch - Original Message - From: Mr. James W. Laferriere [EMAIL PROTECTED] To: ietf maillist ietf@ietf.org Sent: Monday, January 02, 2006 5:14 PM Subject: RE: Alternative formats for IDs Hello All , On Mon, 2 Jan 2006, David B Harrington wrote: Lets go ahead and ask then - Does anyone else think that IETF should allow documents which format/structure is not publicly known as one of the ways to distribute IETF specifications? Not me (or not I, whichever) David Harrington [EMAIL PROTECTED] I have to concur , No I do not want any document structure that does not have a COMPLETELY publicly documented specification as an IETF should allow document format . JimL -- +--+ | James W. Laferriere | SystemTechniques | Give me VMS | | NetworkEngineer | 3542 Broken Yoke Dr. | Give me Linux | | [EMAIL PROTECTED] | Billings , MT. 59105 | only on AXP | +--+ ___ 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: Troubles with UTF-8
- Original Message - From: Randy Presuhn [EMAIL PROTECTED] To: ietf ietf@ietf.org Sent: Wednesday, December 28, 2005 9:46 PM Subject: Re: Troubles with UTF-8 From: Tom.Petch [EMAIL PROTECTED] To: Julian Reschke [EMAIL PROTECTED] Cc: ietf ietf@ietf.org Sent: Wednesday, December 28, 2005 8:06 AM Subject: Re: Troubles with UTF-8 ... I agree, for XML, but my main concern is with UTF-8 encoded strings, where FormFeed is a legal character, encoded as it would be in ASCII. I was using the 'illegal syntax' to float an alternative approach, like using %xC1 - which is illegal in UTF-8 - to delimit a UTF-8 string, but as I say, that idea does not seem to have caught on within the IETF. ... I think the use of explicitly encoded length, rather than special terminator or deliminator sequences, is simpler to code and debug, as well as being more robust in avoiding buffer overflow problems, etc. This is especially true given the variable-length encoding inherent in UTF-8, as well as the open-ended way that combining marks follow, rather than precede the characters to which they apply. (I think this was the state that Masataka Ohta was referring to.) Reserving NUL as a special terminator is a C library-ism. I think that history has shown that the use of this kind of mechanism, rather than explicitly tracking the string's length, was a mistake. Randy I agree with you for 'binary' protocols, intended for machine consumption (OSPF, SNMP), where the string is usually wrapped up in a binary-encoded TLV; but not for character ones, intended for humans, in +-printable characters, with positional or keyword parameters (LDAP[RFC2254], SDP[RFC2327], SASL OTP[RFC2444] or MIME) where a numeric length, in ASCII characters, would look a little odd to me. I always saw NUL as an **IX-ism more than a C-ism, and so of wider use, could be wrong on that. Tom Petch ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Troubles with UTF-8
- Original Message - From: Ned Freed [EMAIL PROTECTED] To: Frank Ellermann [EMAIL PROTECTED] Cc: ietf@ietf.org Sent: Monday, December 26, 2005 7:56 PM Subject: Re: Troubles with UTF-8 Ned Freed wrote: (Unicode lacks a no-op, a meaningless octet, one that could be added or removed without causing any change to the meaning of the text). NBSP is used for this purpose. My proposal u+FFFE was nonsense, I wanted u+FEFF. The latter is zero width nbsp (aka BOM), did you also mean this beast ? Yes. Not a no-op in some cases wrt hyphenation and composition, so it's probably not what Tom wants. It's close enough. Thanks for that - as close as I am going to get:-) Tom Petch Ned ___ 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: Troubles with UTF-8
- Original Message - From: Ned Freed [EMAIL PROTECTED] To: TomPetch [EMAIL PROTECTED] Cc: Ned Freed [EMAIL PROTECTED]; ietf ietf@ietf.org Sent: Sunday, December 25, 2005 12:35 AM Subject: Re: Troubles with UTF-8 Presented with a comparable problem where XML is in use, one WG has chosen to use an illegal XML sequence as a terminator so what I was fishing for is if there were any parallels with UTF-8, which has many illegal sequences of octets and so it would be easy to choose one as a terminator. Using a construct that's syntactically illegal at a higher protocol level is one thing - I still wouldn't do it, but it is arguagly OK. Using a sequence of octets that's not allowed by the underlying charset, OTOH, is a really bad idea. For one thing, various agents do perform syntax checks on charset data, so this is bound to cause major problems. And for another, such sequences are going to be specific to a particular character encoding scheme, which will make agents that transcode from, say, UTF-8 to UTF-16 pretty unhappy. If Unicode data needs to be self-terminated I strongly recommend using NUL to do it. Ned The Unicode data I am thinking of may have come from an upper layer protocol and needs to be passed transparently (as with an error or hello message, identity even); it may or may not already be NUL-terminated (ever had that security foul-up where some userid/password are entered/stored NUL-terminated and some are not?) - hence I see the need to terminate the string in some other way, or to escape or in some other way transfer encode (parts of) the string. I looked at existing RFC, found many different approaches, all viable but none that really said to me 'this is good engineering, this is best practice'. Hence, floating the issue to see if there were any better ones out there. I think not, which is of itself worth knowing. Tom Petch ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Troubles with UTF-8
- Original Message - From: Harald Tveit Alvestrand [EMAIL PROTECTED] To: Tom.Petch [EMAIL PROTECTED]; Ned Freed [EMAIL PROTECTED] Cc: ietf ietf@ietf.org Sent: Wednesday, December 28, 2005 1:30 PM Subject: Re: Troubles with UTF-8 --On onsdag, desember 28, 2005 10:09:05 +0100 Tom.Petch [EMAIL PROTECTED] wrote: The Unicode data I am thinking of may have come from an upper layer protocol and needs to be passed transparently (as with an error or hello message, identity even); it may or may not already be NUL-terminated (ever had that security foul-up where some userid/password are entered/stored NUL-terminated and some are not?) - hence I see the need to terminate the string in some other way, or to escape or in some other way transfer encode (parts of) the string. I looked at existing RFC, found many different approaches, all viable but none that really said to me 'this is good engineering, this is best practice'. Hence, floating the issue to see if there were any better ones out there. I think not, which is of itself worth knowing. There are many strong opinions around proper treatment of XML and of text, and it would be a shame to ask for advice now, reach a seemingly reasonable conclusion, and then encounter violent objections at IETF Last Call. (the WG that went for illegal syntax as terminator SHOULD have caused such a reaction, IMHO; I guess the people who care missed it) The 'illegal syntax' is not yet an RFC but is in draft-ietf-netconf-ssh-05.txt which says As the previous example illustrates, a special character sequence, , MUST be sent by both the client and the server after each XML document in the NETCONF exchange. This character sequence cannot legally appear in an XML document, so it can be unambigiously used to indentify the end of the current document, allowing resynchronization of the NETCONF exchange in the event of an XML syntax or parsing error. For me, that is ok; the 'illegal syntax' is part of the transport syntax not part of the XML syntax and so is not illegal, if you follow me:-) The differing treatments of NUL I see in UTF-8 strings, out of many such RFC, are RFC3748 [EAP] only the portion of the field prior to the null is displayed, MUST NOT be null terminated RFC2444 [SASL] terminated by a NUL (0) octet RFC2869 [RADIUS] MUST be able to deal with embedded nulls RFC3315 [DHCP] MUST NOT be null-terminated. and, just to be different, RFC2595 [TLS+IMAP] authorization identity followed by a US-ASCII NUL followed by the authentication identity followed by a US-ASCII NUL character followed by the clear-text password [this also subsets UTF-8] RFC3413 [SNMP tag] Delimiter characters are defined to be one of the following characters: - space character (0x20), TAB character (0x09), carriage return character (0x0D), line feed character (0x0A) All doubtless with good reason for being the way they are but it does cover the spectrum. As I said above, I quite like 'illegal syntax' and so would happily terminate UTF-8 (and it is UTF-8 that IETF has mandated, not UTF-nnn) with %xC1 - but I see that that will not find favour. Tom Petch ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Troubles with UTF-8
- Original Message - From: Julian Reschke [EMAIL PROTECTED] To: Tom.Petch [EMAIL PROTECTED] Cc: ietf ietf@ietf.org Sent: Wednesday, December 28, 2005 4:16 PM Subject: Re: Troubles with UTF-8 Tom.Petch wrote: - Original Message - From: Harald Tveit Alvestrand [EMAIL PROTECTED] To: Tom.Petch [EMAIL PROTECTED]; Ned Freed [EMAIL PROTECTED] Cc: ietf ietf@ietf.org Sent: Wednesday, December 28, 2005 1:30 PM Subject: Re: Troubles with UTF-8 --On onsdag, desember 28, 2005 10:09:05 +0100 Tom.Petch [EMAIL PROTECTED] wrote: The Unicode data I am thinking of may have come from an upper layer protocol and needs to be passed transparently (as with an error or hello message, identity even); it may or may not already be NUL-terminated (ever had that security foul-up where some userid/password are entered/stored NUL-terminated and some are not?) - hence I see the need to terminate the string in some other way, or to escape or in some other way transfer encode (parts of) the string. I looked at existing RFC, found many different approaches, all viable but none that really said to me 'this is good engineering, this is best practice'. Hence, floating the issue to see if there were any better ones out there. I think not, which is of itself worth knowing. There are many strong opinions around proper treatment of XML and of text, and it would be a shame to ask for advice now, reach a seemingly reasonable conclusion, and then encounter violent objections at IETF Last Call. The 'illegal syntax' is not yet an RFC but is in draft-ietf-netconf-ssh-05.txt which says As the previous example illustrates, a special character sequence, , MUST be sent by both the client and the server after each XML document in the NETCONF exchange. This character sequence cannot legally appear in an XML document, so it can be unambigiously used to indentify the end of the current document, allowing resynchronization of the NETCONF exchange in the event of an XML syntax or parsing error. For me, that is ok; the 'illegal syntax' is part of the transport syntax not part of the XML syntax and so is not illegal, if you follow me:-) ... Why don't you use an illegal *character* instead, such as Formfeed? That's certainly easier to parse... Best regards, Julian I agree, for XML, but my main concern is with UTF-8 encoded strings, where FormFeed is a legal character, encoded as it would be in ASCII. I was using the 'illegal syntax' to float an alternative approach, like using %xC1 - which is illegal in UTF-8 - to delimit a UTF-8 string, but as I say, that idea does not seem to have caught on within the IETF. Tom Petch ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
ABNF Re: Troubles with UTF-8
Dave Is this an ok use of RFC4234? Reading it, I am not clear whether U+FEFF should be specified as %xFE %xFF or whether %xFFEF is ok? And what is the ABNF for any possible ISO 10646 character, all 97000 of them? Tom Petch - Original Message - From: Ned Freed [EMAIL PROTECTED] To: TomPetch [EMAIL PROTECTED] Cc: ietf ietf@ietf.org Sent: Friday, December 23, 2005 7:13 PM Subject: Re: Troubles with UTF-8 snip B) Code point. Many standards are defined in ABNF [RFC4234] which allows code points to be specified as, eg, %b00010011 %d13 or %x0D none of which are terribly Unicode-like (U+000D). The result is standards that use one notation in the ABNF and a different one in the body of the document; should ABNF allow something closer to Unicode (as XML has done with #000D;)? ABNF is charset-independent, mapping onto non-negative integers, not characters. Nothing prevents a specification from saying that a given ABNF grammar specifies a series of Unicode characters represented in UTF-8 and using %xFEFF or whatever in the grammar itself. snip ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Troubles with UTF-8
From: Ned Freed [EMAIL PROTECTED] To: TomPetch [EMAIL PROTECTED] Cc: ietf ietf@ietf.org Sent: Friday, December 23, 2005 7:13 PM Subject: Re: Troubles with UTF-8 snip (Unicode lacks a no-op, a meaningless octet, one that could be added or removed without causing any change to the meaning of the text). NBSP is used for this purpose. Thank you for that; it is not something I have seen documented before. Other protocols use a terminating sequence. NUL is widely used in *ix; some protocols specify that NUL must terminate the text, some specify that it must not, one at least specifies that embedded NUL means that text after a NUL must not be displayed (interesting for security). Since UTF-8 encompasses so much, there is no natural terminating sequence. This simply isn't true. NUL is present in Unicode and is commonly used as a terminator. Not sure which bit isn't true. I agree NUL is present in Unicode and agree that some protocols use it as a terminator and prohibit its use in the text. But some allow it in the text in which case another form of termination is needed or else the NUL must be escaped/encoded. Presented with a comparable problem where XML is in use, one WG has chosen to use an illegal XML sequence as a terminator so what I was fishing for is if there were any parallels with UTF-8, which has many illegal sequences of octets and so it would be easy to choose one as a terminator. Tom Petch Ned. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Troubles with UTF-8
The IETF mandates the use of UTF-8 for text [RFC2277] as part of internationalisation. When writing an RFC, this raises a number of issues. A) Character set. UTF-8 implicitly specifies the use of Unicode/IS10646 which contains 97,000 - and rising - characters. Some (proposed) standards limit themselves to ..007F, which is not at all international, others to -00FF, essentially Latin-1, which suits many Western languages but is not truly international. Is 97,000 really appropriate or should there be a defined subset? B) Code point. Many standards are defined in ABNF [RFC4234] which allows code points to be specified as, eg, %b00010011 %d13 or %x0D none of which are terribly Unicode-like (U+000D). The result is standards that use one notation in the ABNF and a different one in the body of the document; should ABNF allow something closer to Unicode (as XML has done with #000D;)? C) Length. Text is often variable in length so the length must be determined. This may be implicit from the underlying protocol or explicit as in a TLV. The latter is troublesome if the protocol passes through an application gateway which wants to normalise the encoding so as to improve security and wants to convert UTF to its shortest form with corresponding length changes (Unicode lacks a no-op, a meaningless octet, one that could be added or removed without causing any change to the meaning of the text). Other protocols use a terminating sequence. NUL is widely used in *ix; some protocols specify that NUL must terminate the text, some specify that it must not, one at least specifies that embedded NUL means that text after a NUL must not be displayed (interesting for security). Since UTF-8 encompasses so much, there is no natural terminating sequence. D) Transparency. An issue linked to C), protocols may have reserved characters, used to parse the data, which must not then appear in text. Some protocols prohibit these characters (or at least the single octet encoding of them), others have a transfer syntax, such as base64, quoted-printable, %xx or an escape character ( \ %). We could do with a standard syntax. E) Accessibility. The character encoding is specified in UTF-8 [RFC3629] which is readily accessible (of course:-) but to use it properly needs reference to IS10646, which is not. I would like to check the correct name of eg hyphen-minus (Hyphen-minus, Hyphen-Minus, ???) and in the absence of IS10646 am unable to do so. Overall, my perception is that we have the political statement - UTF-8 will be used - but have not yet worked out all the engineering ramifications. Tom Petch Tom Petch ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Accessibility was Re: Troubles with UTF-8
- Original Message - From: Frank Ellermann [EMAIL PROTECTED] To: ietf@ietf.org Sent: Friday, December 23, 2005 2:57 PM Subject: Re: Troubles with UTF-8 I would like to check the correct name of eg hyphen-minus (Hyphen-minus, Hyphen-Minus, ???) and in the absence of IS10646 am unable to do so. Maybe get the latest Unicode 4.1.0 data file (almost one MB): http://www.unicode.org/Public/UNIDATA/UnicodeData.txt For SASLPREP / NAMEPREP you would take Unicode version 3.2, and for a beta test of Unicode 5.0 take the beta data. Bye, Frank I do not think such a reference is stable enough. The earlier references in RFC to Unicode cited the books published by Addison-Wesley; now the later ones mostly cite ISO 10646. I am looking for a readily (cheaply) available list of Unicode character names and code points, as in RFC1345. ___ 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
