Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC
Frank, Not publishing it at all is an alternative. And this is what we should do, if the community feels that way. However ... 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. I personally feel fairly strongly that the individual submission option is very useful for the IETF community -- along with the usual WG submissions and the independent submissions via the RFC Editor. The reasons are described in the draft, but relate to situations where non-WG proposals are useful to the IETF community and require IETF and IESG review. By the way, the draft explicitly states that being friends with an AD is NOT a reason for a draft to be sponsored. From what I can see this is also the process that we follow. If not, please complain! Jari ___ 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
Thanks for your note John. Let me also emphasize the need for these two drafts to be synchronized. Last calling draft-iesg at this time was made in part because we wanted to get the two in sync. I think we are more or less in sync but the remaining input should come from the community. As for the list to use for discussion -- sending mail to the iesg list only would indeed be one way. The discussion list we are on right now seems more suited, no? Thanks again for raising these questions. Jari John C Klensin kirjoitti: Hi. I will get to substance in a separate note, and hope others will also. In the interim, two procedural remarks... (1) This document and draft-klensin-rfc-independent-05.txt describe two pieces of the how a document that does not originate in a WG may be reviewed and published space. Each contains some text that suggests that some documents are better handled via the other path. The IAB has made a request for input on the independent document and now we have a Last Call on this one. As editor of the rfc-independent document, I am awaiting instructions from the IAB as to what, if anything, to do next, but suspect that the recommendation below would be better applied to -06 rather than -05 of that document. I strongly encourage members of the community to review the two documents side by side to ensure that everyone is satisfied that they are consistent and that any questions about the overall non-WG submission space is adequately covered by one or the other of them. I also ask, and hope others will join me in asking, that the IESG and IAB take explicit responsibility for coordinating and ensuring consistency between these two documents (and, if necessary, with draft-iab-rfc-editor). If they are not consistent enough that actions based on them are predictable, I fear we can look forward to some difficulties. It might even be useful for the two groups to coordinate titles sufficiently that someone looking for information will easily understand that the two describe somewhat parallel paths and ways in which those paths may or may not be alternatives to each other. (2) This document is not the product of a working group or of extended open discussion in the community. Version -00 was posted around the time of the San Diego meeting and received very little public discussion. The current version was posted at the beginning of this month; there has been little discussion of it either (at least on public lists -- as the Acknowledgements suggest, I've had some input into it via private discussions). The document does not even indicate a mailing list on which it can be discussed. One presumes that comments could have been sent to the IESG by those who happened to read the I-Ds, but that is a one-way communications path. 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 an Informational RFC. If they intend it to be definitive information for the community, especially information that they expect to reference as to why something is or is not possible or whether procedures are being followed, a two-week Last Call is, IMO, inappropriate and inconsistent with the spirit of the provisions in RFC 2026. john --On Wednesday, 07 February, 2007 10:20 -0500 The IESG [EMAIL PROTECTED] wrote: The IESG has received a request from the Internet Engineering Steering Group (iesg) to consider the following document: - 'Guidance on Area Director Sponsoring of Documents ' draft-iesg-sponsoring-guidelines-01.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-02-21. 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. ___ 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-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 ___ 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
John, On 2007-02-08 00:02, John C Klensin wrote: Hi. I will get to substance in a separate note, and hope others will also. In the interim, two procedural remarks... (1) This document and draft-klensin-rfc-independent-05.txt describe two pieces of the how a document that does not originate in a WG may be reviewed and published space. Each contains some text that suggests that some documents are better handled via the other path. The IAB has made a request for input on the independent document and now we have a Last Call on this one. As editor of the rfc-independent document, I am awaiting instructions from the IAB as to what, if anything, to do next, but suspect that the recommendation below would be better applied to -06 rather than -05 of that document. I strongly encourage members of the community to review the two documents side by side to ensure that everyone is satisfied that they are consistent and that any questions about the overall non-WG submission space is adequately covered by one or the other of them. Exactly right. These documents (and draft-iab-rfc-editor) need to interlock and that is why they are open for review at the same time. I also ask, and hope others will join me in asking, that the IESG and IAB take explicit responsibility for coordinating and ensuring consistency between these two documents (and, if necessary, with draft-iab-rfc-editor). If they are not consistent enough that actions based on them are predictable, I fear we can look forward to some difficulties. It might even be useful for the two groups to coordinate titles sufficiently that someone looking for information will easily understand that the two describe somewhat parallel paths and ways in which those paths may or may not be alternatives to each other. That is the intention; and we can indeed look at the titles in that light. (2) This document is not the product of a working group or of extended open discussion in the community. Version -00 was posted around the time of the San Diego meeting and received very little public discussion. The current version was posted at the beginning of this month; there has been little discussion of it either (at least on public lists -- as the Acknowledgements suggest, I've had some input into it via private discussions). The document does not even indicate a mailing list on which it can be discussed. One presumes that comments could have been sent to the IESG by those who happened to read the I-Ds, but that is a one-way communications path. Well, the Last Call message suggested this list. And with one rather small difference, the draft only attempts to describe current practice. [The difference is that it calls for a publication request to be sent to a single AD and not to the IESG as a whole.] 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 an Informational RFC. We discussed this and reached the opposite conclusion, mainly because of the point you raise above: consistency with two other documents that will definitely be RFCs. But it was a close decision. If they intend it to be definitive information for the community, especially information that they expect to reference as to why something is or is not possible or whether procedures are being followed, a two-week Last Call is, IMO, inappropriate and inconsistent with the spirit of the provisions in RFC 2026. If we believed it modified or did violence to 2026, it would need to be a BCP itself with a whole other style of review. But since its intent is much milder, a normal LC seemed enough. Brian ___ 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
--On Thursday, 08 February, 2007 03:34 -0500 Jari Arkko [EMAIL PROTECTED] wrote: Thanks for your note John. Let me also emphasize the need for these two drafts to be synchronized. Last calling draft-iesg at this time was made in part because we wanted to get the two in sync. I think we are more or less in sync but the remaining input should come from the community. As for the list to use for discussion -- sending mail to the iesg list only would indeed be one way. The discussion list we are on right now seems more suited, no? Sure. But my point in that area was obviously not clear. Prior to the announcement of the Last Call, there was no indication to the community that this document should be considered and discussed, much less where. There is no working group charter, no history of open discussion, and so on. And _that_ calls for a four-week Last Call, not two weeks. regards, john ___ 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
John, Sure. But my point in that area was obviously not clear. Prior to the announcement of the Last Call, there was no indication to the community that this document should be considered and discussed, much less where. Right. We weren't ready for a very wide discussion with the earlier revision, it had too many obvious problems. I hope the right discussion forum is now clear. There is no working group charter, no history of open discussion, and so on. And _that_ calls for a four-week Last Call, not two weeks. But its Informational. My read of RFC 2026 says that the 4 week case applies to Standards Track only. In any case, if it turns out that we get too little feedback or there's significant controversy, I'm sure Brian will consider what that means for successful end of the last call... Jari ___ 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
John, On 2007-02-08 13:16, John C Klensin wrote: --On Thursday, 08 February, 2007 03:34 -0500 Jari Arkko [EMAIL PROTECTED] wrote: Thanks for your note John. Let me also emphasize the need for these two drafts to be synchronized. Last calling draft-iesg at this time was made in part because we wanted to get the two in sync. I think we are more or less in sync but the remaining input should come from the community. As for the list to use for discussion -- sending mail to the iesg list only would indeed be one way. The discussion list we are on right now seems more suited, no? Sure. But my point in that area was obviously not clear. Prior to the announcement of the Last Call, there was no indication to the community that this document should be considered and discussed, much less where. There is no working group charter, no history of open discussion, and so on. And _that_ calls for a four-week Last Call, not two weeks. The rules require a 4 week last call for non-WG standards actions, which this isn't, so the tracker automatically generated a 2 week last call. But I assure you that discussion will not be truncated arbitrarily as a result (i.e. I do not intend to rush this onto the IESG agenda for Feb. 22). Brian ___ 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
But its Informational. My read of RFC 2026 says that the 4 week case applies to Standards Track only. rfc 2026 says what must be done in some cases - it does not say what can not be done in the cases it does not cover - specifically, RFC 2026 in no way would block a 4-week last call for an informational RFC - note that RFC 2026 does not require any last call for informationals fwiw - I agree with John - this doc warents a longer last call because it does impact how part of the IETF process will work and the draft did not get vetted in a normal working group process Scott ___ 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
Scott, rfc 2026 says what must be done in some cases - it does not say what can not be done in the cases it does not cover - specifically, RFC 2026 in no way would block a 4-week last call for an informational RFC - note that RFC 2026 does not require any last call for informationals Right, I didn't mean to imply there was an upper limit. Its always a judgment call. fwiw - I agree with John - this doc warents a longer last call because it does impact how part of the IETF process will work and the draft did not get vetted in a normal working group process That's a fair statement. I believe Brian just told us that he's not in a rush, so he's not cutting the discussion off too early. But its his call if he officially changes the last call period. Jari ___ 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
On 2007-02-08 14:05, Scott O. Bradner wrote: But its Informational. My read of RFC 2026 says that the 4 week case applies to Standards Track only. rfc 2026 says what must be done in some cases - it does not say what can not be done in the cases it does not cover - specifically, RFC 2026 in no way would block a 4-week last call for an informational RFC - note that RFC 2026 does not require any last call for informationals fwiw - I agree with John - this doc warents a longer last call because it does impact how part of the IETF process will work and the draft did not get vetted in a normal working group process As I said, this won't be rushed through. Let's see if there are any comments of substance though. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-syslog-protocol: Reliabledeliveryconsidered harmful.
I agree with Tom that the draft - at least IMHO - does not promote or strongly encourage reliable logging. I also agree with the observation that reliable - and blocking - logging can cause harm to a system. However, I do not think that this is anything that the protocol can do something against. It is not the protocol that causes harm. If we say if we support a reliable syslog protocol, we can block the system and thus the protocol is harmful, we can also say if we deliver mail messages via a reliable protocol (SMTP), we can use up all system ressources (e.g. fill the disk), so SMTP is harmful. My point is that we must differentiate between the protocol and its implementations. A reliable syslog protocol offers the foundation on which a reliable syslog implementation can be build. It is the task of the application designer to take care of the operating environment specifics while implementing the protocol. A good design for Unix will probably take into consideration that a blocking syslogd does not do any good and leave options to the operator to discard messages when needed (and probably have turned them on by default). Even in such a situation, however, a reliable syslog protocol has advantages. We can not accidently loose messages. The application must actively discard them. Which in turn means the application *knows* that messages have been discarded. It can convey that information to the other syslog applications it is talking to. In contrast, by using UDP messages get dropped and nobody knows. To prove my point, my open source syslog pet rsyslog has implemented active message discarding in case it would need to block (at least in single-thread mode, with multiple threads discarding occurs only after the queue space is used up). This was implemented because there is a real-world need for it. But this is application design, not protocol design. Think about it: how can an IETF document specify what a syslogd should do if its sending queue is filled up? How could we word this so that it becomes part of an on-the-wire protocol? Rainer -Original Message- From: Tom.Petch [mailto:[EMAIL PROTECTED] Sent: Monday, February 05, 2007 8:06 AM To: Harald Tveit Alvestrand; ietf Subject: Re: draft-ietf-syslog-protocol: Reliable deliveryconsidered 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
Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC
John == John C Klensin [EMAIL PROTECTED] writes: John --On Thursday, 08 February, 2007 03:34 -0500 Jari Arkko John [EMAIL PROTECTED] wrote: Thanks for your note John. Let me also emphasize the need for these two drafts to be synchronized. Last calling draft-iesg at this time was made in part because we wanted to get the two in sync. I think we are more or less in sync but the remaining input should come from the community. As for the list to use for discussion -- sending mail to the iesg list only would indeed be one way. The discussion list we are on right now seems more suited, no? John Sure. But my point in that area was obviously not clear. John Prior to the announcement of the Last Call, there was no That sort of depends on what's going on here. Is Jari's draft an internal procedure of the IESG sent out for community review because the IESG believes it has an obligation to seek input on its procedures and to document them? If so, then a two week last call seems fine? Alternatively, is this an IETF community process document that will bind the IESG in the future unless it is updated by the community? If so, then it should be a BCP and a four week last call. My understanding was that RFC 2026 was normative here (although it says basically nothing) and that the IESG was documenting its procedures. If the community believes that this topic is important enough that it should be a community decision not an IESG decision, that seems entirely fine to me. But then this should not be an informational document. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Review of draft-ietf-syslog-transport-udp-08
I've reviewed this document as part of the transport directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Feel free to forward to any appropriate forum. Summary: This document could go into more detail with respect to transport behavior. In places the wording could be improved. Section 1 The IPv4 version of this transport mapping is REQUIRED for all syslog protocol implementations on devices supporting IPv4. The IPv6 version of this transport mapping is REQUIRED for all syslog protocol implementations on IPv6-only devices. So we are saying that a syslog implementation on a dual-stack host isn't even recommended to support IPv6? This would imply that a dual-stack implementation may not be able to send syslog messages if it has IPv6 connectivity, but not IPv4. This doesn't make sense to me. Section 3.2 IPv4 syslog receivers MUST be able to receive datagrams with message size up to and including 480 octets. IPv6 syslog receivers MUST be able to receive datagrams with message size up to and including 1180 octets. All syslog receivers SHOULD be able to receive datagrams with messages size of at least 2048 octets. If I read this literally, it seems to imply that IPv4 receivers must be able to receive datagrams with a message size of 0 to 480 octets, and should be able to receive messages greater than 2048 octets, and IPv6 receivers must be able to receive datagrams with a message size of 0 to 1180 octets, and should be able to receive messages greater than 2048 octets. What about IPv4 messages from 480 to 2047 octets, or IPv6 messages from 1181 to 2047 octets? Are we saying that reception of these messages sizes is optional?? The above restrictions and recommendations establish a baseline for interoperability. The minimum required message size support was determined based on the minimum MTU size that internet hosts are required to support: 576 octets for IPv4 [3] and 1280 octets for IPv6 [4]. Datagrams that fall within these limits have the greatest chance of being delivered because they do not require fragmentation. One could interpret this to mean that datagrams between 576 and 1280 octets have the greatest chance of delivery, which isn't what you mean. You might say Datagrams that conform to these limits... When network MTU is not known in advance and cannot be reliably determined using path MTU discovery [7], the safest assumption is to restrict messages to 480 octets for IPv4 and 1180 octets for IPv6. There are issues with syslog usage of classical path MTU discovery, since ICMP Packet Too Big messages may not be delivered or processed for some reason. Since syslog doesn't support acknowledgement, it can't determine when packets are lost, making it difficult to implement alternatives such as draft-ietf-pmtud-method. You might talk a bit more about these implications. Section 4 This section discusses reliability issues inherent in UDP that implementers and users MUST be aware of. What implementation obligations does the MUST imply? I'm unclear what an implementer is supposed to do. Section 4.1 In some circumstances the sender can receive an ICMP error message or other indication of a transmission problem. If the sender receives a reasonable indication that a datagram has been lost, it MAY retransmit the datagram. This paragraph seems too vague. Are we suggesting that the implementer may retransmit in response to any ICMP error message? Also, are there any recommendations with respect to retransmission timers or failover behavior? Section 4.2 However, checksums do not guarantee corruption detection, and this transport mapping does not provide for message retransmission when a corrupt message is detected. It might be clearer to say that there is no acknowledgement mechanism, given the potential for retransmission described in Section 4.1. A special case of corruption is corruption introduced by the UDP implementation itself. For example, several earlier UDP implementations defaulted to a buffer size of less than 65535 octets and truncated larger payloads upon receipt [8]. By following the message size recommendations specified in this document, application developers can significantly reduce the risk of this type of error. This probably would better fit in Section 3.2. Section 4.3 The UDP does not provide for congestion control. Any network host or router can discard UDP packets when it is overloaded, and can optionally provide an ICMP error to indicate this. Are you referring to Source Quench here? I think you need to talk about syslog's response to potential congestion indications in more detail. Section 4.1 raises the possibility of retransmission, which without backoff
Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC
Jari Arkko wrote: please complain! That was the complaint, the draft is from an IESG POV, and it explains how to deal with confused authors claiming that a single bit is enough to count to three or similar cases. But it doesn't address the POV of authors who want to get an evaluation of their I-D. The first step is clear, figure out the area, if that's unclear ask the General AD. After that if the area has a catchall crackpot WG try to get a review there, at some point in time ask the Chair(s) to adopt the I-D. Is that still correct ? If the area has no catchall crackpot WG try to get reviews on a related IETF or other list, at some point in time ask one of the ADs. If that AD agrees to support it there will be a Last Call or not - depending on the intended status, or the decision of that AD to last call it anyway. But what if the AD doesn't like it ? Not all drafts try to introduce ternary bits. Apparently ADs are forced to vote [Yes] (at least initially) if they sponsor a document. What if they don't like it, but the authors still insist on an evaluation ? Can they appeal then ? What if the AD does not like it personally, but admits that it's not as bad as the famous ternary bits ? Frank ___ 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
--On Thursday, 08 February, 2007 10:19 -0500 Sam Hartman [EMAIL PROTECTED] wrote: John Sure. But my point in that area was obviously not clear. John Prior to the announcement of the Last Call, there was no That sort of depends on what's going on here. Is Jari's draft an internal procedure of the IESG sent out for community review because the IESG believes it has an obligation to seek input on its procedures and to document them? If so, then a two week last call seems fine? Alternatively, is this an IETF community process document that will bind the IESG in the future unless it is updated by the community? If so, then it should be a BCP and a four week last call. My understanding was that RFC 2026 was normative here (although it says basically nothing) and that the IESG was documenting its procedures. If the community believes that this topic is important enough that it should be a community decision not an IESG decision, that seems entirely fine to me. But then this should not be an informational document. Sam, I think we pretty much agree, and that is why my initial note wasn't much more aggressive. But it raises the issue that others have raised: if this meets the criteria for IETF documenting its procedures and, as you have described it above, informational, then why not publish it as an ION given that series was designed for just those sorts of things?Please take that as a question, not a position, but it is a very serious one. More generally, and independent of this particular document, it seems to me that, with IONs in the mix, publishing something that is informational about IESG procedures requires some explanation. Procedural BCPs do not, IONs do not, but informational documents of this variety have now become sort of an odd case. And, IMO, if something that could reasonably be published as an ION is proposed for publication as an Info RFC instead, then that ought to imply a decision that serious community discussion is in order, not just comments on a collection of IESG decisions. Put differently, I think the existence of IONs implicitly raises the bar on Info publication of procedural docs, especially ones that are just IESG statements of IESG procedures. I think that is essentially the same question that Spencer and others have raised. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on AreaDirector Sponsoring of Documents) to Informational RFC
Hi, Sam, I agree with your note. FWIW, and speaking only for the confused on the list, - I understand why something should be a BCP (community consensus for a process that doesn't change every year or so), - I understand why something should be an ION (IESG consensus with appropriate input from the community for a procedure that is likely to change from time to time), and - I'm lost about why we would continue to publish Informational process RFCs (ignoring any existing pipeline of process documents remaining to be published as RFCs). Spencer From: Sam Hartman [EMAIL PROTECTED] John == John C Klensin [EMAIL PROTECTED] writes: John --On Thursday, 08 February, 2007 03:34 -0500 Jari Arkko John [EMAIL PROTECTED] wrote: Thanks for your note John. Let me also emphasize the need for these two drafts to be synchronized. Last calling draft-iesg at this time was made in part because we wanted to get the two in sync. I think we are more or less in sync but the remaining input should come from the community. As for the list to use for discussion -- sending mail to the iesg list only would indeed be one way. The discussion list we are on right now seems more suited, no? John Sure. But my point in that area was obviously not clear. John Prior to the announcement of the Last Call, there was no That sort of depends on what's going on here. Is Jari's draft an internal procedure of the IESG sent out for community review because the IESG believes it has an obligation to seek input on its procedures and to document them? If so, then a two week last call seems fine? Alternatively, is this an IETF community process document that will bind the IESG in the future unless it is updated by the community? If so, then it should be a BCP and a four week last call. My understanding was that RFC 2026 was normative here (although it says basically nothing) and that the IESG was documenting its procedures. If the community believes that this topic is important enough that it should be a community decision not an IESG decision, that seems entirely fine to me. But then this should not be an informational document. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-syslog-protocol: Reliabledeliveryconsidered harmful.
On Thu, Feb 08, 2007 at 02:32:00PM +0100, Rainer Gerhards wrote: I also agree with the observation that reliable - and blocking - logging can cause harm to a system. However, I do not think that this is anything that the protocol can do something against. It is not the protocol that causes harm. If we say if we support a reliable syslog protocol, we can block the system and thus the protocol is harmful, we can also say if we deliver mail messages via a reliable protocol (SMTP), we can use up all system ressources (e.g. fill the disk), so SMTP is harmful. RFC2821 (SMTP) defines a queueing behaviour and that servers should retry transmission for some reasonable number of times at intervals as specified in section 4.5.4. should there be problems at the reliable transmission layer. It seems your example does what the syslog draft does not, so I'm not sure what your point really is. My point is that we must differentiate between the protocol and its implementations. A reliable syslog protocol offers the foundation on which a reliable syslog implementation can be build. It is the task of the application designer to take care of the operating environment specifics while implementing the protocol. A good design for Unix will probably take into consideration that a blocking syslogd does not do any good and leave options to the operator to discard messages when needed (and probably have turned them on by default). Even in such a You must differentiate between the protocol and implementation, but not to the extent of denying the implementor guidance on how to proceed in a way that will promote the health of the protocol. The wholesale promotion of reliable transport without the disclaimer that the protocol-level process probably wants to enter into discarding behaviour in effect promotes the unhealthy condition. My hope is that a simple acknowledgement of this evidently common implementation mistake would substantially increase the quality of syslog implementations that are updated for it. design. Think about it: how can an IETF document specify what a syslogd should do if its sending queue is filled up? How could we word this so that it becomes part of an on-the-wire protocol? If you were going to update syslog so that it might be transported over a reliable channel, then I think the only right answer is to define how the protocol-level process, independent of which reliable transport is selected, deals with congestion or failure. Barring that, there are many duct tape approaches. Updating the security section to weigh the cons of denial of service against the pros of reliable delivery. Adding a glossary entry for reasonably reliable, and using such terms instead of the absolute reliable as is currently in place. Numerous others. -- David W. HankinsIf 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 pgpCs7DtX1Fl6.pgp Description: PGP signature ___ 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
Hi Frank, That was the complaint, the draft is from an IESG POV, and it explains how to deal with confused authors claiming that a single bit is enough to count to three or similar cases. I would be happy to sponsor a ternary bit draft, but only on April 1 :-) But it doesn't address the POV of authors who want to get an evaluation of their I-D. The first step is clear, figure out the area, if that's unclear ask the General AD. Right. After that if the area has a catchall crackpot WG try to get a review there, at some point in time ask the Chair(s) to adopt the I-D. Is that still correct ? If the area has no catchall crackpot WG try to get reviews on a related IETF or other list, at some point in time ask one of the ADs. Right. But the draft says relatively little about this, because there are different situations. Some areas have a general purpose area working group with chairs and an ability to produce documents just like any other WG. Other areas (like INT) have only a discussion forum that is not intended for detailed protocol development. In the latter case the ADs are likely to get more individual submission proposals. And the authors may not even be the active parties. ADs may and sometimes do solicit specifications for some purpose, such as fixing a bug or updating an aging crypto algorithm. If that AD agrees to support it there will be a Last Call or not - depending on the intended status, or the decision of that AD to last call it anyway. Right. But what if the AD doesn't like it ? Not all drafts try to introduce ternary bits. Apparently ADs are forced to vote [Yes] (at least initially) if they sponsor a document. What if they don't like it, but the authors still insist on an evaluation ? Can they appeal then ? What if the AD does not like it personally, but admits that it's not as bad as the famous ternary bits ? As with regular WG submissions, the document has to pass the responsible AD's review. Otherwise it goes back to the WG or the authors. ADs can always decline to sponsor a given document, based on usefulness to the community, expertise, etc. There is no guarantee that all suggestions will be taken on. Appeals procedures apply just like they do for other contributions. Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Revised I-D: draft-ietf-mipshop-cga-cba-03.txt
Hello folks, we updated draft-ietf-mipshop-cga-cba according to the comments and suggestions that Eric Gray posted on the IETF Discussion mailing list during IETF Last Call. Here is a change log (not including purely editorial items): o Reference to RFC 3972 (Cryptographically Generated Addresses) is now normative. o More detailed IANA considerations. o Fixed reference to BCP 14, RFC 2119, so that Nit Checker does no longer complain. o Clarified in Section 3.1 that CGAs do not require a public-key infrastructure, even though they make use of public-key cryptography. o Included intended status (Proposed Standard) at beginning of document. You can access the revised draft version as well as a diff against the previous version 02 at: http://doc.tm.uka.de/2007/draft-ietf-mipshop-cga-cba-03.txt http://doc.tm.uka.de/2007/draft-ietf-mipshop-cga-cba-02to03.html Best regards, - Christian -- Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH) www.tm.uka.de/~chvogt/pubkey/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Important: Remember to use latest boilerplate in drafts
Hi, With the submission deadlines before the Prague meeting coming up, please remember that all drafts need to use the latest boilerplate text (see below for details). February 26, Monday - Internet Draft Cut-off for initial document (-00) submission by 09:00 ET (14:00 UTC/GMT) March 5, Monday - Internet Draft final submission cut-off by 09:00 ET (14:00 UTC/GMT) Thanks Brian Carpenter Original Message Subject: Internet-Draft Boilerplate Reminder Date: Mon, 15 Jan 2007 11:51:16 -0500 From: IETF Secretariat [EMAIL PROTECTED] To: IETF Announcement list ietf-announce@ietf.org CC: iesg@ietf.org This message is to remind you that as of February 1, 2007 the IETF Secretariat will no longer accept Internet-Drafts with the old (i.e. pre RFC 4748) boilerplate. For your convenience, below is the text of the message that was sent to the IETF Announcement List by the IETF Chair on October 26, 2006 with Subject: Update to Internet Draft and RFC Boilerplate. The IETF Secretariat. -- A small update to BCP 78 was recently approved by the IESG as RFC 4748, to update the boilerplate (i.e., standard legal text) in RFCs and Internet-Drafts to recognize the IETF Trust as a rights holder, instead of ISOC. The actual boilerplate changes are given below this message. Starting as soon as reasonably possible, all authors of Internet-Drafts are requested to use the new boilerplate. The RFC Editor will in any case be inserting it in all RFCs issued from 2006-11-01. (The rights held by ISOC in older RFCs will be administratively transferred to the IETF Trust.) The public ID Nits checker already accepts I-Ds with old or new boilerplate. The Secretariat has started accepting I-Ds with old or new boilerplate. XML2RFC version 1.32 will generate the new boilerplate. Users of I-D templates are requested to update them appropriately. http://www.ietf.org/ID-Checklist.html and http://www.ietf.org/ietf/1id-guidelines.html are being updated. Starting December, the public ID Nits checker will issue warnings for old boilerplate. Starting February 2007, the Secretariat will refuse the old boilerplate in Internet-Drafts. We are sorry for the inconvenience, but this change cannot be avoided. IETF Chair IETF Secretariat TOOLS Team Copyright Notice (required for all IETF Documents) (Normally placed at the end of the IETF Document.) NOTE: by convention, the first line of the copyright statement is usually placed near the beginning of each document. This must also be updated. OLD Copyright (C) The Internet Society (year). 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. NEW Copyright (C) The IETF Trust (year). 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. Disclaimer (required in all IETF Documents) (Normally placed at the end of the IETF Document after the copyright notice.) OLD This document and the information contained herein are provided on an AS IS basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. NEW This document and the information contained herein are provided on an AS IS basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Exceptions In MIB modules, PIB modules and similar material commonly extracted from IETF Documents, except for material that is being placed under IANA maintenance, the following abbreviated notice shall be included in the body of the material that will be extracted in lieu of the notices otherwise required by Section 5: OLD Copyright (C) The Internet Society year. This version of this MIB module is part of RFC ; see the RFC itself for full legal notices. NEW Copyright (C) The IETF Trust year. This version of this MIB module is part of RFC ; see the RFC itself for full legal notices. When the MIB or PIB module is the initial version of
Last Call: draft-mcwalter-langtag-mib (Language Tag MIB) to Proposed Standard
The IESG has received a request from an individual submitter to consider the following document: - 'Language Tag MIB ' draft-mcwalter-langtag-mib-01.txt as a Proposed Standard The 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-08. 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-mcwalter-langtag-mib-01.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=15469rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-mcwalter-uri-mib (Uniform Resource Identifier (URI) MIB) to Proposed Standard
The IESG has received a request from an individual submitter to consider the following document: - 'Uniform Resource Identifier (URI) MIB ' draft-mcwalter-uri-mib-02.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 2007-03-08. 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-mcwalter-uri-mib-02.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=15468rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4793 on The EAP Protected One-Time Password Protocol (EAP-POTP)
A new Request for Comments is now available in online RFC libraries. RFC 4793 Title: The EAP Protected One-Time Password Protocol (EAP-POTP) Author: M. Nystroem Status: Informational Date: February 2007 Mailbox:[EMAIL PROTECTED] Pages: 82 Characters: 172575 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-nystrom-eap-potp-07.txt URL:http://www.rfc-editor.org/rfc/rfc4793.txt This document describes a general Extensible Authentication Protocol (EAP) method suitable for use with One-Time Password (OTP) tokens, and offers particular advantages for tokens with direct electronic interfaces to their associated clients. The method can be used to provide unilateral or mutual authentication, and key material, in protocols utilizing EAP, such as PPP, IEEE 802.1X, and Internet Key Exchange Protocol Version 2 (IKEv2). This memo provides information for the Internet community. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
