VeriLAN Selected for Prague
I am please to announce that the IAOC, through the Internet Society, has contracted with VeriLAN Event Services of Portland Oregon (www.verilan.com) to provide NOC services for IETF 68 in Prague. VeriLAN has provided similar services for the IEEE 802, WiMAX Forum, NPF, Intel and others, and has previously delivered services at the Hilton Prague. VeriLAN was one of four bidders responding to an RFP released in December 2006. We look forward to a successful meeting with VeriLAN in the NOC. Ray Pelletier IETF Administrative Director ___ 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. 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
Re: Last Call: draft-ietf-smime-cms-mult-sign (CryptographicMessageSyntax(CMS) MultipleSigner Clarification) to Proposed Standard
Sam, Denis == Denis Pinkas [EMAIL PROTECTED] writes: Denis Sam, Russ == Russ Housley [EMAIL PROTECTED] writes: Russ Denis: I do not consider these to be new comments. You made Russ them during WG Last Call, and there was considerable Russ discussion on the S/MIME WG mail list. In the end, you were Russ unable to gain any support for your position. Why do you Russ feel I need to respond to the same comments again? I tend to agree with Russ. Denis I do not see how it may be possible to reach a consensus if Denis a dialogue is not accepted. Russ is the editor. You said that you have already brought these issues up in the WG. It is no longer Russ's job to engage with you if he does not want to. You previously said: I strongly suggest that you try and build consensus for these two positions separately. I keep trying. Now you say: It is the WG chairs' job to describe the reasoning for why your comments were rejected during the WG discussion and I've asked the chairs to do that. This does not sound to be a way to try to build consensus for these two positions separately. Am I missing something ? Denis ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-smime-cms-mult-sign (CryptographicMessageSyntax(CMS) MultipleSignerClarification) to Proposed Standard
The only person who has really engaged the conversation during the last call period was the draft editor, i.e. Russ Housley (who also happens to be a Security Area Director, but in this case he cannot play this role). So it is one against one and Sam is now the single Security Area Director allowed to make a decision. In general the activity on this mailing list is rather low. Silence on the mailing list is rather difficult to interpret. I do not agree with the interpretation Blake made of this silence: it like making the dead peole talk. I cannot understand why Russ is not wishing to try to find a compromise. In the current situation, I believe it t would be fair to have a straw poll on the mailing list and raise the two topics separately. I do not expect many responses. If you agree, I can draft the text of the two questions and propose it to you (i.e. Sam and the co-chairs). Denis OK, let me back up and explain the events as I see them and try to clarify. And I am certainly welcome to any comments or criticism about what my role is or how I should proceed with this. * My job as WG chair is to make sure that the editor (Russ) has created a draft that incorporates what we consider to be the rough consensus of the working group. * You had some comments on this draft. Some of your comments were incorporated. Some of your comments had zero support from the WG members on the working group mailing list. Clarifications welcome as to exactly who else supported these comments. * WG last call closed over a month after your unincorporated comments were made, which allowed plenty of time for anyone to come forward to support your position or for any interested parties to discuss them. * Because of this lack of interest from anyone but yourself, those comments were considered the rough part of rough consensus and were not incorporated. That is, you had something that wasn't working for you, you explained your concern on the mailing list, and no one else shared that concern. * As WG chair, I believe that this was the right way to proceed, Sean as co-chair was in agreement, and the draft progressed out of the working group. Denis Pinkas wrote: You previously said: I strongly suggest that you try and build consensus for these two positions separately. I keep trying. I believe that Sam's recommendation was to take each issue separately and present them clearly to others in the community, and then try to determine what the consensus is about each issue. That is, start a discussion, and based on the outcome of that discussion see where we stood. This didn't happen. Now you say: It is the WG chairs' job to describe the reasoning for why your comments were rejected during the WG discussion and I've asked the chairs to do that. This does not sound to be a way to try to build consensus for these two positions separately. Am I missing something ? I'm willing to accept criticism here, but it's not my job to build the consensus for you. It's my job to determine if an issue has been raised, and to determine if the community has had enough time to review it, and to make sure that the author has incorporated what I believe the consensus to be. * You raised some issues * No one commented on the issues * You escalated the issues * No one commented on the issues * This indicates to me that these issues are only interesting to you, and not to the WG at large, and thus does not reflect the consensus. I mean, I'm not so bold as to say that people are in active disagreement with your position, but I will say that no one cares enough about it to warrant supporting it. So I'm willing to do whatever is required here to make sure that I'm doing my job right, and to make sure that I'm facilitating the creation of high quality drafts. But as far as whether or not your comments have gotten their due consideration from the working group, I will say emphatically that I think they have. Blake -- Blake Ramsdell | Sendmail, Inc. | http://www.sendmail.com Regards, Denis Pinkas ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-mcwalter-langtag-mib (Language TagMIB)toProposed Standard
Hi, I have a little question about style in one place in the McWalter draft; I suggest you replace This in Section 3, paragraph 3; line 2, with 'the language tag defined here,' 'the language tag defined by MIB,' or something similar: In theory, BCP 47 language tags are of unlimited length. This language tag is of limited length. This apparently refers back to the Abstract: Abstract This MIB module defines a textual convention to represent BCP 47 [RFC4646] language tags. But I am concerned about style here because: It's been a while since a textual convention to represent BCP 47 [RFC4646] language tags was referred to-- and thus it's unclear here what This is referring to in section 3. (when I taught I would not let my students refer to anything outside of the text unless it was very obvious; nor would I let them refer to something more than one paragraph back without specifying it exactly again.) Again my comment is about style not about content! Thanks, C. E. Whitehead [EMAIL PROTECTED] ([EMAIL PROTECTED]) _ Valentines Day -- Shop for gifts that spell L-O-V-E at MSN Shopping http://shopping.msn.com/content/shp/?ctId=8323,ptnrid=37,ptnrdata=24095tcode=wlmtagline ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-mcwalter-langtag-mib (Language Tag MIB) to Proposed Standar
Hi, the document looks o.k. but this is not my area of expertise One question (probably a stupid one, but here goes), What does This language tag refer to? in section 3, Definitions ??: In theory, BCP 47 language tags are of unlimited length. This language tag is of limited length. The analysis of language tag lengths in BCP 47 confirms that this limit will not pose a problem in practice. In particular, this length is greater than the minimum requirements set out in section 4.3.1. --C. E. Whitehead [EMAIL PROTECTED] 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-languages mailing list [EMAIL PROTECTED] http://www.alvestrand.no/mailman/listinfo/ietf-languages _ FREE online classifieds from Windows Live Expo buy and sell with people you know http://clk.atdmt.com/MSN/go/msnnkwex001001msn/direct/01/?href=http://expo.live.com?s_cid=Hotmail_tagline_12/06 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [secdir] Secdir review comments for draft-ietf-pim-bidir-08
Steven == Steven M Bellovin [EMAIL PROTECTED] writes: Steven On Wed, 7 Feb 2007 21:14:35 -0800 Steven Joseph Salowey (jsalowey) [EMAIL PROTECTED] wrote: I would like to understand better why ... no automated key management is specified. Steven Do they cite any of the reasons listed in RFC 4107? No. Bill gave me a heads up about this a while back because I'd indicated I would hold a discuss on the next document to do this. I could not get together the energy to engage with the WG and cause them to design a security architecture for PIM. I at least am planning to abstain on this document because the AD tried to engage and I failed. I don't think it's good technology for this not to have automated key management though. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-heard-rfc4181-update (RFC 4181 Update to Recognize the IETF Trust) to BCP [WAS: Gen-art review of draft-heard-rfc4181-update-00.txt]
Hi Mike, as the review says, they are just nits. If you disagree with them, feel free to ignore them (as long as your AD is also OK with that, of course). Cheers, Gonzalo C. M. Heard wrote: On Tue, 23 Jan 2007, Gonzalo Camarillo wrote: I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. I will do so, and in that spirit I'm posting my response to the IETF list with the subject line changed. My apologies for the delay in replying. Draft: draft-heard-rfc4181-update-00.txt Reviewer: Gonzalo Camarillo [EMAIL PROTECTED] Review Date: 23 January 2006 IETF LC Date: 16 January 2006 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. Comments: The title of the draft could be more explicit. Now it mentions RFC 4181. It could also indicate that it is an update to the Guidelines for Authors and Reviewers of MIB Documents. I disagree with this comment -- I believe that doing as it suggests would make the title unnecessarily long. Note that the Abstract already spells out the full title of RFC 4181. Acronyms (e.g., MIB) should be expanded on their first use. The only places where the acronym MIB is used are in the Abstract and the References, where the title of RFC 4181 is quoted. The acronym is not expanded in that title, and it would be inappropriate to do so in a citation, which is supposed to quote the exact title of the document being cited. Also, I believe that MIB qualifies as an appreviation that is so firmly extablished in IETF usage that its use is very unlikely to cause uncertainty or ambiguity and so is exempt from the usual acronym expansion requirement. Granted that it is not explicitly mentioned in http://www.rfc-editor.org/policy.html#policy.abbrevs, but several recent RFCs using the acronym MIB have appeared without it being expanded anywhere. RFC 4181 and RFC 4663 are examples. The only other acronym I see is IETF, and that one is explicitly mentioned in http://www.rfc-editor.org/policy.html#policy.abbrevs. The draft should be divided into pages, none of which should exceed 58 lines. Unless I'm required to make another revision for other reasons, I'd like to let the RFC Editor take care of that (which they will do anyway) ... my apologies if the lack of pagination has caused any readability problems. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-mcwalter-langtag-mib (Language Tag MIB) to Proposed Standard
Doug Ewell scripsit: Since tags of 1 character are never well-formed, I suggest that the definition: SYNTAX OCTET STRING (SIZE (0..60)) be amended to exclude the 1-character case. I assume that a zero-length tag, while also not defined in RFC 4646, was included in the I-D to allow the special case of no tag. AFAIK, ASN.1 does not allow sizes like (0, 2..60). I wouldn't even bother with this change. -- John Cowan[EMAIL PROTECTED]http://ccil.org/~cowan Rather than making ill-conceived suggestions for improvement based on uninformed guesses about established conventions in a field of study with which familiarity is limited, it is sometimes better to stick to merely observing the usage and listening to the explanations offered, inserting only questions as needed to fill in gaps in understanding. --Peter Constable ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Gen-ART Last Call Review of draft-ietf-avt-hc-over-mpls-protocol-07
Hi, Jerry, This is easier than it should be... slicing down through the stuff we already worked out (if I deleted it, I agree with your plan)... option is the same for both IPCP and IPV6CP. This configuration option MUST be included for ECRTP, CRTP and IPHC PW types and MUST NOT be included for ROHC PW types. Spencer: Is it obvious what the decompressor does if it sees this configuration option for ROHC PW types? It may be - I'm just asking. I'd have the same question elsewhere (in 5.2.2, for example), but will only ask it here. Yes. The corresponding text for the ROHC configuration option is specified in Section 5.2.5. In other sections we specify that the configuration options are only applicable to specific header compression formats, e.g., as in Section 5.2.2 for cRTP. Spencer: there was this theory about testing TCP with kamikaze or Christmas tree packets (you set all the options to 1, whether that makes sense or not, and see what the other guy does). I think I'm asking what SHOULD happen if the decompressor sees a packet like this. I'm wondering if we still worry about things like this... and loss, it is still the protocol of choice in many cases. In these circumstances, it must be implemented and deployed with care. IPHC should use TCP_NODELTA, ECRTP should send absolute values, ROHC should be adapted as discussed in [RFC4224]. An evaluation and simulation of ECRTP and ROHC reordering is given in [REORDER-EVAL]. Spencer (Probably a Nit): It wasn't obvious to me whether these recommendations are sufficient to implement and deploy with care, or whether additional precautions must be taken. Even putting these recommendations in a numbered list immediately after deployed with care would be sufficient, if these recommendations are sufficient. This goes back to a discussion with Allison Mankin RE CRTP issues discussed icw RFC 4446. There was no further list of recommendations out of that discussion, rather, the point is that in packet-lossy environments, for example, CRTP may not work well and ECRTP may perform better. Some folks felt that CRTP should be excluded because of that problem. There were, however, other concerns raised on deploying ECRTP (e.g., CRTP is already widely deployed, plus other reasons). Spencer: would it be appropriate to say implement and deploy with care:, and then put the recommendations in a numbered list? My concern was pretty basic - if I follow these recommendations, do I still have a problem, or am OK? Again, thanks for a quick followup, while I can still remember what I was thinking when I wrote the review :-) Spencer ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Gen-ART Last Call Review of draft-ietf-avt-hc-over-mpls-protocol-07
Hi Spencer, Thanks a lot for the quick reply. Please see below. -Original Message- From: Spencer Dawkins [mailto:[EMAIL PROTECTED] Sent: Thursday, February 08, 2007 12:52 AM To: ASH, GERALD R (JERRY), ATTLABS Cc: ietf@ietf.org; General Area Review Team; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; HAND, JAMES, ATTLABS; Mark Townsley; ext Cullen Jennings; GOODE, B (BUR), ATTLABS; raymond.zhang; [EMAIL PROTECTED] Subject: Re: Gen-ART Last Call Review of draft-ietf-avt-hc-over-mpls-protocol-07 Hi, Jerry, This is easier than it should be... slicing down through the stuff we already worked out (if I deleted it, I agree with your plan)... option is the same for both IPCP and IPV6CP. This configuration option MUST be included for ECRTP, CRTP and IPHC PW types and MUST NOT be included for ROHC PW types. Spencer: Is it obvious what the decompressor does if it sees this configuration option for ROHC PW types? It may be - I'm just asking. I'd have the same question elsewhere (in 5.2.2, for example), but will only ask it here. Yes. The corresponding text for the ROHC configuration option is specified in Section 5.2.5. In other sections we specify that the configuration options are only applicable to specific header compression formats, e.g., as in Section 5.2.2 for cRTP. Spencer: there was this theory about testing TCP with kamikaze or Christmas tree packets (you set all the options to 1, whether that makes sense or not, and see what the other guy does). I think I'm asking what SHOULD happen if the decompressor sees a packet like this. I'm wondering if we still worry about things like this... You make a very good point, error legs of course are critical for whatever erroneous configuration or coding may occur. We can specify something like this in Section 5.2.1 (Configuration Option Format) ... This configuration option MUST be included for ECRTP, CRTP and IPHC PW types and MUST NOT be included for ROHC PW types. A decompressor MUST reject this option (if misconfigured) for ROHC PW types and send an explicit error message to the compressor [RFC3544]. and loss, it is still the protocol of choice in many cases. In these circumstances, it must be implemented and deployed with care. IPHC should use TCP_NODELTA, ECRTP should send absolute values, ROHC should be adapted as discussed in [RFC4224]. An evaluation and simulation of ECRTP and ROHC reordering is given in [REORDER-EVAL]. Spencer (Probably a Nit): It wasn't obvious to me whether these recommendations are sufficient to implement and deploy with care, or whether additional precautions must be taken. Even putting these recommendations in a numbered list immediately after deployed with care would be sufficient, if these recommendations are sufficient. This goes back to a discussion with Allison Mankin RE CRTP issues discussed icw RFC 4446. There was no further list of recommendations out of that discussion, rather, the point is that in packet-lossy environments, for example, CRTP may not work well and ECRTP may perform better. Some folks felt that CRTP should be excluded because of that problem. There were, however, other concerns raised on deploying ECRTP (e.g., CRTP is already widely deployed, plus other reasons). Spencer: would it be appropriate to say implement and deploy with care:, and then put the recommendations in a numbered list? My concern was pretty basic - if I follow these recommendations, do I still have a problem, or am OK? There really isn't any list of 'recommendations' as to how to 'deploy (CRTP) with care' in the case of lossy links and reordering issues, that phrasing should be removed as misleading. Rather, we can further explain the issue with CRTP, as described in [RFC3545]: 5.4 Packet Reordering ...Although CRTP is viewed as having risks for a number PW environments due to reordering and loss, it is still the protocol of choice in many cases. CRTP was designed for reliable point to point links with short delays. It does not perform well over links with high rate of packet loss, packet reordering and long delays. In such cases ECRTP [RFC3545] may be considered to increase robustness to both packet loss and misordering between the compressor and the decompressor. This is achieved by repeating updates and sending of absolute (uncompressed) values in addition to delta values for selected context parameters. IPHC should use ... Thanks again, Regards, Jerry Again, thanks for a quick followup, while I can still remember what I was thinking when I wrote the review :-) Spencer ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Syslog] Re: Last Call: draft-ietf-syslog-protocol (The syslogProtocol) to Proposed Standard
Mark == Mark Andrews [EMAIL PROTECTED] writes: [snip] Similarly if syslogd is using a reliable transport to talk to another syslogd. That too can block which will eventualy lead to blockages to applications / memory exhaustion. *That* is a different beast, not yet discussed. I know that it exists but it is not related to DNS. If it happens, it is really bad and typically results in a complete system hang. There are some situations where a lossy transport is preferable. For example, I have written a syslog/TCP implementation which, if forced to run in single-threaded mode, favours discarding messages over blocking as the later could indeed lead to fatal problems on a typical linux system. The root cause, however, is not reliable syslog per se. The root cause is the implementation. A reliable syslogd actually needs to be implemented with a non-blocking, de-coupled, buffered design. In almost all cases, that means separate receiver threads, a to-be-processed message queue and separate sender threads. Still, you have to decide what to do if the queue size is exhausted. But that scenario is much less likely. In that case, I'd still favour loosing some messages over potentially loosing all AND the system the syslogd runs on. As far as I see it, this is an app-layer issue out of scope for the underlying protocol. The problem, of course, is that syslog is simplex and hop-to-hop, so the original sender will never know that the message was lost. Protocol-wise, I do not see any fix to that except integrating some asynchronous notification mechanism. IMHO, this is outside the scope of syslog. It may be useful to add some hint to implementors pointing to this blocking condition. But I am not sure if it is really justified. Rainer ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-mcwalter-uri-mib (Uniform Resource Identifier (URI) MIB) to Proposed Standard
RFC 3986 contains a (brief) description of security considerations for agents that produce or receive and interpret URIs. I would expect this document to at the very least reference those security considerations more explicitly, and at best to analyze how they apply in particular to URIs used within SNMP. It's not clear whether it makes sense for SNMP URIs to contain, for example, 'data:' URIs or 'urn:' or any of a number of schemes, and I would expect some discussion about the applicability of URIs within a SNMP context. URIs are defined as a sequence of characters, not a sequence of octets. The mapping should be explicit (e.g., 'use US-ASCII') and not implicit. In practice, many systems allow and produce IRIs (RFC 3987) and not URIs, to allow for accents and non-roman scripts. I wonder if it would be more appropriate to define the MIB value as an IRI encoded in UTF-8, for example. Larry -Original Message- From: The IESG [mailto:[EMAIL PROTECTED] Sent: Thursday, February 08, 2007 3:02 PM To: IETF-Announce Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: 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=vie w_iddTag=15468rfc_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: [Ltru] Re: Last Call: draft-mcwalter-langtag-mib (Language Ta g MIB) to Proposed Standard
Hi, Right - ASN.1 doesn't allow discontinuous integer ranges. The DESCRIPTION clause of this textual convention could disallow the length of '1', but it's not important to do, I think. With respect to max length of 60, the public MIBs that I'm aware of often use 63 octets and the rest use a longer max length (except for the admittedly flawed legacy objects in Printer MIB v2, RFC 3805 - I tried to fix them before we published RFC 3805, but got shot down by my co-editors). Cheers, - Ira Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: [EMAIL PROTECTED] -Original Message- From: John Cowan [mailto:[EMAIL PROTECTED] Sent: Saturday, February 10, 2007 1:16 PM To: Doug Ewell Cc: [EMAIL PROTECTED]; LTRU Working Group; ietf@ietf.org Subject: [Ltru] Re: Last Call: draft-mcwalter-langtag-mib (Language Tag MIB) to Proposed Standard Doug Ewell scripsit: Since tags of 1 character are never well-formed, I suggest that the definition: SYNTAX OCTET STRING (SIZE (0..60)) be amended to exclude the 1-character case. I assume that a zero-length tag, while also not defined in RFC 4646, was included in the I-D to allow the special case of no tag. AFAIK, ASN.1 does not allow sizes like (0, 2..60). I wouldn't even bother with this change. -- John Cowan[EMAIL PROTECTED]http://ccil.org/~cowan Rather than making ill-conceived suggestions for improvement based on uninformed guesses about established conventions in a field of study with which familiarity is limited, it is sometimes better to stick to merely observing the usage and listening to the explanations offered, inserting only questions as needed to fill in gaps in understanding. --Peter Constable ___ Ltru mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ltru -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.441 / Virus Database: 268.17.33/678 - Release Date: 2/9/2007 4:06 PM ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Gen-ART Last Call Review of draft-ietf-avt-hc-over-mpls-protocol-07
Hi, Jerry, Definitely headed the right direction. Do the right thing - and thanks. Spencer From: ASH, GERALD R (JERRY), ATTLABS [EMAIL PROTECTED] Hi Spencer, Thanks a lot for the quick reply. Please see below. From: Spencer Dawkins [mailto:[EMAIL PROTECTED] Subject: Re: Gen-ART Last Call Review of draft-ietf-avt-hc-over-mpls-protocol-07 Hi, Jerry, This is easier than it should be... slicing down through the stuff we already worked out (if I deleted it, I agree with your plan)... option is the same for both IPCP and IPV6CP. This configuration option MUST be included for ECRTP, CRTP and IPHC PW types and MUST NOT be included for ROHC PW types. Spencer: Is it obvious what the decompressor does if it sees this configuration option for ROHC PW types? It may be - I'm just asking. I'd have the same question elsewhere (in 5.2.2, for example), but will only ask it here. Yes. The corresponding text for the ROHC configuration option is specified in Section 5.2.5. In other sections we specify that the configuration options are only applicable to specific header compression formats, e.g., as in Section 5.2.2 for cRTP. Spencer: there was this theory about testing TCP with kamikaze or Christmas tree packets (you set all the options to 1, whether that makes sense or not, and see what the other guy does). I think I'm asking what SHOULD happen if the decompressor sees a packet like this. I'm wondering if we still worry about things like this... You make a very good point, error legs of course are critical for whatever erroneous configuration or coding may occur. We can specify something like this in Section 5.2.1 (Configuration Option Format) ... This configuration option MUST be included for ECRTP, CRTP and IPHC PW types and MUST NOT be included for ROHC PW types. A decompressor MUST reject this option (if misconfigured) for ROHC PW types and send an explicit error message to the compressor [RFC3544]. and loss, it is still the protocol of choice in many cases. In these circumstances, it must be implemented and deployed with care. IPHC should use TCP_NODELTA, ECRTP should send absolute values, ROHC should be adapted as discussed in [RFC4224]. An evaluation and simulation of ECRTP and ROHC reordering is given in [REORDER-EVAL]. Spencer (Probably a Nit): It wasn't obvious to me whether these recommendations are sufficient to implement and deploy with care, or whether additional precautions must be taken. Even putting these recommendations in a numbered list immediately after deployed with care would be sufficient, if these recommendations are sufficient. This goes back to a discussion with Allison Mankin RE CRTP issues discussed icw RFC 4446. There was no further list of recommendations out of that discussion, rather, the point is that in packet-lossy environments, for example, CRTP may not work well and ECRTP may perform better. Some folks felt that CRTP should be excluded because of that problem. There were, however, other concerns raised on deploying ECRTP (e.g., CRTP is already widely deployed, plus other reasons). Spencer: would it be appropriate to say implement and deploy with care:, and then put the recommendations in a numbered list? My concern was pretty basic - if I follow these recommendations, do I still have a problem, or am OK? There really isn't any list of 'recommendations' as to how to 'deploy (CRTP) with care' in the case of lossy links and reordering issues, that phrasing should be removed as misleading. Rather, we can further explain the issue with CRTP, as described in [RFC3545]: 5.4 Packet Reordering ...Although CRTP is viewed as having risks for a number PW environments due to reordering and loss, it is still the protocol of choice in many cases. CRTP was designed for reliable point to point links with short delays. It does not perform well over links with high rate of packet loss, packet reordering and long delays. In such cases ECRTP [RFC3545] may be considered to increase robustness to both packet loss and misordering between the compressor and the decompressor. This is achieved by repeating updates and sending of absolute (uncompressed) values in addition to delta values for selected context parameters. IPHC should use ... Thanks again, Regards, Jerry Again, thanks for a quick followup, while I can still remember what I was thinking when I wrote the review :-) Spencer ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Gen-ART Last Call Review of draft-ietf-avt-hc-over-mpls-protocol-07
Hi Spencer, Many thanks for your thorough and constructive review of the draft. Please see responses to your comments below, and please let us know of any further comments or suggestions. Thanks, Regards, Jerry -Original Message- From: Spencer Dawkins [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 07, 2007 12:20 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; HAND, JAMES, ATTLABS; ASH, GERALD R (JERRY), ATTLABS; Mark Townsley; ext Cullen Jennings Cc: ietf@ietf.org; General Area Review Team Subject: Gen-ART Last Call Review of draft-ietf-avt-hc-over-mpls-protocol-07 I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-avt-hc-over-mpls-protocol-07 Reviewer: Spencer Dawkins Review Date: 2007-01-30 IETF LC End Date: 2007-07-07 IESG Telechat date: (not known) Summary: This document is on the right track for publication as Proposed Standard. I had some questions (please see below), but the quality seemed very good (thanks for that). I'd like to see some work on my comments in 5.1, 5.2 (especially 5.2.1), and 5.3. I had some comments on clarity in section 6, but these were more-than-nits-but-not-problems. Thanks! Spencer Comments: 1. Introduction Voice over IP (VoIP) typically uses the encapsulation voice/RTP/UDP/IP. When MPLS labels [RFC3031] are added, this becomes voice/RTP/UDP/IP/MPLS-labels. MPLS VPNs (e.g., [RFC2547]) use label stacking, and in the simplest case of IPv4 the total packet header is at least 48 bytes, while the voice payload is often no more than 30 bytes, for example. When IPv6 is used, the relative size of the header in comparison to the payload is even greater. The interest in header compression (HC) is to exploit the possibility of significantly reducing the overhead through various compression mechanisms, such as with enhanced compressed RTP (ECRTP) [RFC3545] and robust header compression (ROHC) [RFC3095], and also to increase scalability of HC. MPLS is used to route HC packets over an MPLS label switched path (LSP) without compression/decompression cycles at each router. Such an HC over MPLS capability can increase bandwidth efficiency as well as the processing scalability of the maximum number of simultaneous compressed flows that use HC at each router. Goals and requirements for HC over MPLS are discussed in [RFC4247]. The solution put forth in this document using MPLS pseudowire (PW) technology has been designed to address these goals and requirements. Spencer (Nit): I think the last sentence is actually The solution using MPLS pseudowire (PW) technology put forth in this document has been designed to address these goals and requirements. (the solution wasn't actually put forth using MPLS PW technology :-) Agree with your suggested rewording. 2. Contributors Besides the editors listed in Section 12, the following people contributed to the document: Spencer (Nit): I like the use of this section, but it seems odd to have it so far from the acknowledgements section. I'm not sure if IESG has an agreed sense of taste for placement or not. Cullen? In a recent RFC review I saw the RFC editor put the Contributing Authors section right before the Editor's Address section, where both sections were toward the end of the RFC (near the Acknowledgements section). It seems like a good approach IMO. 3. Terminology PSN Tunnel Signaling: Used to set up, maintain, and tear down the underlying PSN tunnel Spencer (Nit): s/Used/A protocol used/ (all of the other definitions look like complete sentences, this one is a fragment) OK. 5.1 MPLS Pseudowire Setup Signaling This specification defines new PW type values to be carried within the FEC object to identify HC PWs for each HC scheme. The PW type is a 15-bit parameter assigned by IANA, as specified in the [RFC4446] registry, and MUST be used to indicate the HC scheme being used on the PW. The following PW type values have been set aside for assignment by IANA: 0x001A ROHC Transport Header-compressed Packets[RFC3095] 0x001B ECRTP Transport Header-compressed Packets [RFC3545] 0x001C IPHC Transport Header-compressed Packets[RFC2507] 0x001D cRTP Transport Header-compressed Packets[RFC2508] Spencer: have been set aside for assignment by IANA, with RFC references, confused me badly here. I read this text as saying that these values were set aside IN [RFC3095], etc, which was wrong. Perhaps IANA is requested to assign the following new PW type values:? The language is based on
Re: Last Call: draft-ietf-smime-cms-mult-sign (CryptographicMessageSyntax(CMS) Multiple Signer Clarification) to Proposed Standard
Sam, Russ == Russ Housley [EMAIL PROTECTED] writes: Russ Denis: I do not consider these to be new comments. You made Russ them during WG Last Call, and there was considerable Russ discussion on the S/MIME WG mail list. In the end, you were Russ unable to gain any support for your position. Why do you Russ feel I need to respond to the same comments again? I tend to agree with Russ. I do not see how it may be possible to reach a consensus if a dialogue is not accepted. There are indeed two different issues: 1 - The document goes beyond specifying how to determine if a message is validly signed by a given signer. The core of the dispute is the following proposed sentence: | When the collection represents more than one signature, the successful | validation of one of signature from each signer ought to be | treated as a successful validation of the signed-data content type. This sentence implicitly states that the document as a whole is well signed when all the signers have signed it !!! It cannot stay like that. The intent was to say the message was validly signed by a given signer, if any of the digital signatures from that signer is valid. The key question is first : How can the CMS engine (*not* the application) determine which digital signatures are from the same signer. Russ said: Further discussion made it clear that the application was going to have to be involved in determining which signatures are associated with the same signer in some cases. However, in the most urgent case we are concerned with RSA with SHA-1 and RSA with SHA-256, the same certificate will be used for both signatures, so the same signer is obvious. The reality is the following: it is easy (but not said anywhere in te document) if the new certificate is using rsaEncryption, but what about if the algorithm changes to id-RSASSA-PSS ? If the application needs to determine which signatures are from the same signer, then it should not be in the CMS specification and good luck for application developpers who are left alone ! I believe that the CMS engine should be instructed to determine which signatures are from the same signer. The second point (and I have not mentionned this argument before) is that saying that the message was validly signed by a given signer, if any of the digital signatures from that signer is valid only works if the algorithms used are *all* considered as secure. A few words in the security considerations section (only 3 lines today) would certainly help to take care of that point. 2 - There is not enough precision in the description of how to validate a signature. In other words, is the current description for signature verification clear enough ? On November 27, Russ said: When CMS was first adopted by the S/MIME WG, we decided to keep the specification as close to the structure of PKCS #7 v1.5 as possible. The idea was to make it easy for one to determine the differences. I see no reason why this discussion ought to change that decision. The description that is in PKCS #7 v1.5 is pretty unclear. It should be improved. Also at the time PKCS #7 v1.5 was written, RSASSA-PSS did not existed and since it identifies both RSA and the hash function, the controls to be made when it is used now need to be defined. In RFC 3852, we have a clear definition of the process to sign data: The process by which signed-data is constructed involves the following steps: 1. For each signer, a message digest, or hash value, is computed on the content with a signer-specific message-digest algorithm. If the signer is signing any information other than the content, the message digest of the content and the other information are digested with the signer's message digest algorithm (see Section 5.4), and the result becomes the message digest. 2. For each signer, the message digest is digitally signed using the signer's private key. 3. For each signer, the signature value and other signer-specific information are collected into a SignerInfo value, as defined in Section 5.3. Certificates and CRLs for each signer, and those not corresponding to any signer, are collected in this step. 4. The message digest algorithms for all the signers and the SignerInfo values for all the signers are collected together with the content into a SignedData value, as defined in Section 5.1. We should have a similar construct for verification, but we don't. The thread initiated in January 2007 by Julien Stern has demonstrated that the current text for signature verification is not clear enough. However, the text has not been clarified to reflect the discussion that took place on the list. I have made a new text proposal on January 26, and no one, including Russ, has ever responded
Re: Last Call: draft-wilde-text-fragment (URI Fragment Identifiers for the text/plain Media Type) to Proposed Standard
On 2/14/07, The IESG [EMAIL PROTECTED] wrote: The IESG has received a request from an individual submitter to consider the following document: - 'URI Fragment Identifiers for the text/plain Media Type ' draft-wilde-text-fragment-06.txt as a Proposed Standard Editorial point: Section 2.2.1 says Character position counting starts with 0, so the character position before the first character of a text/plain MIME entity has the character position 0 but the example in section 5 says http://example.com/text.txt#char=100 This URI identifies the position after the 100th character of the text.txt MIME entity. If character counting starts at 0 I take it that the initial character is the 0th character, thus char=100 is before not after the 100th, right? In fact the spec is perfectly correct according to the normal meaning of 100th but it took me a minute to get that, and I suspect a little clean-up in the example description would be useful. Substantive point: Each of the addressing schemes is easy to understand, but the ways they combine are hard to explain and understand, and I'm unconvinced that being able to identify things like This URI identifies the first line and all occurrences of the regular expression 'searchterm' in the MIME entity. are worth the effort. I'd strongly recommend simplifying the spec by allowing only one scheme, which might turn out to hit a very desirable 80/20 point. -Tim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-mcwalter-langtag-mib (Language Tag MIB) to Proposed Standard
Hi - From: McDonald, Ira [EMAIL PROTECTED] Sent: Feb 11, 2007 4:15 AM To: 'John Cowan' [EMAIL PROTECTED], Doug Ewell [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], LTRU Working Group [EMAIL PROTECTED], ietf@ietf.org Subject: RE: [Ltru] Re: Last Call: draft-mcwalter-langtag-mib (Language Ta g MIB) to Proposed Standard Hi, Right - ASN.1 doesn't allow discontinuous integer ranges. ... No. In a SIZE qualifier, a discontiguous range is perfectly legal ASN.1 There are examples of this in RFC 2579, among others. In this particular case, something like SYNTAX OCTET STRING (SIZE (0 | 2..60)) (replacing 60 with whatever the consensus upper bound should be) would seem appropriate. Randy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
68th IETF - Cutoff Dates Reminder
Registration Cutoff Dates: March 9, Friday - Early-Bird registration and payment cut-off at 12:00 noon ET (17:00 UTC/GMT) March 17, Saturday - Final Pre-Registration and Pre-Payment cut-off at 17:00 ET (21:00 UTC/GMT) You can register for the IETF meeting and social event at: http://www3.ietf.org/meetings/68-IETF.html Internet Draft Cutoff Dates: February 19, Monday - Working Group Chair approval for initial document (Version -00) submissions appreciated by 09:00 ET (14:00 UTC/GMT) 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) Only 32 days left until the Prague IETF Meeting! ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-wilde-text-fragment (URI Fragment Identifiers for the text/plain Media Type) to Proposed Standard
The IESG has received a request from an individual submitter to consider the following document: - 'URI Fragment Identifiers for the text/plain Media Type ' draft-wilde-text-fragment-06.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-14. 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-wilde-text-fragment-06.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=9149rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
