Gen-ART LC review of draft-harkins-brainpool-ike-groups-04
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-harkins-brainpool-ike-groups-04 Reviewer: Roni Even Review Date:2013-2-13 IETF LC End Date: 2013-2-28 IESG Telechat date: Summary: This draft is ready for publication as an Informational RFC. Major issues: Minor issues: Nits/editorial comments:
Re: History of protocol discussion or process in WG
Hi Eliot, At 03:38 05-02-2013, Eliot Lear wrote: What I would like not to have happen is that we spend any time bickering over who said what, especially if it detracts from the business of developing excellent standards. I think your point, Dave, about Yes. synthesis being left to historians is a good one, and I might go farther, and say that the whole endeavor should be. But having at least a record from individauls about what *they* said or meant is, I suppose, not unreasonable. I post the draft of the minutes to the mailing list. There have been cases where what was meant came out differently in writing. The person suggested text to clarify that. The working group did not object. The minutes were added to the record (proceedings). Regards, -sm
Comments on draft-eastlake-additional-xmlsec-uris-07.txt
Hi, In http://www.ietf.org/id/draft-eastlake-additional-xmlsec-uris-08.txt the References have to be checked and updated. For example, the document has a normative reference to http://www.w3.org/TR/2002/WD-xptr-20020816/ which is a Superceded work-in-progress that's over 10 years old. Also, it references RFC Errata, Errata ID 191, RFC 4051 without linking the errata item, and does so normatively even though the document as a whole would Obsolete RFC 4051. Just to illustrate, I did not review them all myself. The Abstract does not english. I don't think it's a good idea to have the Acknowledgements precede even the Introduction as an exception while most other documents put it near the end. The XCANON reference does not work, xml-enc-c14n-20020718 is perhaps meant to be xml-exc-c14n-20020718 (enc vs exc). I've not checked other references. The document makes reference to Canonical XML 1.0 without referencing, e.g. http://www.w3.org/TR/C14N-issues/ (and RFC 3076 does not seem to have any Errata filed to hint at the problems with it). I'm not sure that's a problem, but it might be better to mention the problems with Canonical XML 1.0 in some form. regards, -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: Remote Participation Services
Hi, some time ago I proposed an experiment associated with moderation in the presence of both remote and local participants (point 2.7 below): http://ietf83.conf.meetecho.com/index.php/UMPIRE_Project You can find the related IETF mail announcement here: http://www.ietf.org/mail-archive/web/vmeet/current/msg00394.html Just for the logs. Cheers, Simon Il giorno 05/feb/2013, alle ore 17:04, IETF Chair ha scritto: Please see the attached report on the current status of remote participation in the IETF meeting. Please notice at the end a call for potential experiments to explore ways that we can improve remote participation. Russ Housley IETF Chair Bob Hinden IAOC Chair = = = = = = = = = Status of Remote Participation Services in the IETF Today Russ Housley 1 February 2013 1. Introduction For more than a decade, the IETF has tried to make it easier for remote attendees to participate in regular and interim face-to-face meetings. At the same time, some IETF Working Groups (WGs) have started to conduct virtual interim meetings. The IETF's current remote participation system (RPS) consists of a outbound real-time audio stream for each session carried to remote attendees over HTTP, textual multi-user chat carried over XMPP (commonly called Jabber), and posting of slides prior to the WG session so that they can be downloaded from the IETF web site. WebEx and Meetecho are experimentally supported, offering outbound real-time audio stream synchronized to the slides for the remote participant. Meetecho displays the Jabber Room on the screen with slides, and it can also be used to replay the audio and slides from a recording. Some WGs also employ ad-hoc tools, such as Skype for two-way audio and video conferencing and Etherpad for shared document editing. 2. Regular and Interim IETF Meetings Today, it is easy to remotely observe IETF sessions, but it is very difficult to participate in discussions. However, several tools are used to accommodate remote participants. To the greatest extent possible, these tools rely on IETF or other open standards, and they embrace both IPv4 and IPv6 without network address translation. 2.1. Audio Anyone can use a web browser to receive real-time audio of the IETF meeting sessions. The URLs for the audio are announced in advance, and the audio recording becomes part of the session proceedings. It is quite difficult for a remote participant to have their voice heard in the session. The WebEx and Meetecho systems can accommodate this with advance setup and testing. However, allowing arbitrary remote participants to speak does not work well. Connecting to the audio system in the meeting facility is quite problematic. Further, a WG Chair would need sophisticated controls to maintain order if arbitrary remote participants were able to speak at any time. While WebEx and Meetecho provide some participation management features, but integration with in-room participation is needed. 2.2. Video In the 1990s as part of the multicast experiment, multicast video was made available, but this experiment has ended without evolving into a production service. As part of a separate experiment, some sessions use Meetecho to make video available to anyone with a web browser. WG Chairs must request this coverage. When Meetecho is used, the URLs are announced in advance, and the recording becomes part of the session proceedings. 2.3. Multi-User Chat Multi-user chat (MUC) is used both as a remote participation tool as well as a communication tool for local attendees, to raise and resolve issues without intruding on the presentation. Each WG has a Jabber Room for Multi-User Chat, which employs the XMPP Standards Foundation (XSF) XEP-045 specification. These Jabber Rooms can can be used at any time, not just during the IETF meetings. During the session, remote participants that are listening to the audio are able to ask questions by typing them in the Jabber Room, and then someone in the physical room reads the question at the mic. This is called MUC-to-Mic Relay. The Jabber Room log becomes part of the session proceedings. 2.4. Slide Sharing Anyone can use a web browser to fetch the session slides. WG Chairs are responsible for posting the slides prior to the session, and the slides (in PDF format) become part of the session proceedings. When Meetecho is used, the audio or video is presented in a synchronized fashion along with the jabber room and slides. 2.5. Remote Presenter When a presenter cannot attend, someone else usually presents their slides. Some WG Chairs have tried remote presentations using WebEx and Meetecho. Neither system is ideal, and the audio can include squeals and
Re: Remote Participation Services
For the question at the end, I'd like to suggest that making an effort to normalize some of the use of the tools that we have would be most helpful. It's not just a technology problem. IETF == IETF Chair ch...@ietf.org writes: IETF 2.4. Slide Sharing IETFAnyone can use a web browser to fetch the session slides. IETF WG Chairs are responsible for posting the slides prior to the IETF session, and the slides (in PDF format) become part of the IETF session proceedings. Slides are regularly late, and regularly not in PDF format. They get updated at the last minute, so slide numbers fail. I think that this presents too rosy a picture of getting slides. IETF 2.6. Shared Text Document Editing IETFIn some sessions, there is an attempt to edit a text IETF document with input from the local and remote attendees. This IETF is most often done for minutes and proposed WG charter I wish we would do this more often, particularly for HUMs -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works pgp5MJxATgSpt.pgp Description: PGP signature
答复: Gen-ART review of draft-ietf-ccamp-lmp-behavior-negotiation-10
Hi Richard, Thanks for the review of this draft! Section 2.1. Would be helpful to either include the old formats and/or say explicitly what is changing. Added the original format of Config, ConfigAck and ConfigNack messages which are defined in RFC4204. Section 2.2. Nodes which support - nodes that support Ordering of CONFIG objects - ... With different C-type values Updated the text as suggested. Section 3.1.MBZ. Might help to clarify that this means that the number of bits MUST be a multiple of 32. (I got a little confused between bits and bytes here.) OLD: The remaining bits in the flags field MUST be set to zero (0). The number of bits present is based on the Length field of the LMP object header and MUST include enough bits so the Length field MUST be at least 8, and MUST be a multiple of 4. NEW: The remaining bits in the flags field MUST be set to zero (0). The number of bits present is based on the Length field of the LMP object header and MUST include enough bits so the Length field MUST be at least 8, and the number of bits MUST be a multiple of 32. Section 4. Likely Is it possible for a 4204-compliant implementation to not do one of these? If so then remove likely. If not, then why happens on the exceptional case? There is no other exception, so I just removed the word likely. I will hold the new version until I get the further instruction from my document shepherd or AD. Best regards, Dan -邮件原件- 发件人: Richard Barnes [mailto:rbar...@bbn.com] 发送时间: 2013年2月4日 3:14 收件人: ietf@ietf.org; The IESG 抄送: draft-ietf-ccamp-lmp-behavior-negotiat...@tools.ietf.org; gen-...@ietf.org 主题: Gen-ART review of draft-ietf-ccamp-lmp-behavior-negotiation-10 I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please seehttp://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-ccamp-lmp-behavior-negotiation-10 Reviewer: Richard Barnes Review Date: 2013-02-02 IETF LC End Date: 2012-01-21 IESG Telechat date: 2012-02-07 Summary: Ready, with a couple of minor questions / clarifications. Comment: Overall, this document seems very clear and readable. Thanks! The one concern I have is over the use of likely in the discussion of backward compatibility; I would like to see more precise language there. Section 2.1. Would be helpful to either include the old formats and/or say explicitly what is changing. Section 2.2. Nodes which support - nodes that support Ordering of CONFIG objects - ... With different C-type values Section 3.1.MBZ. Might help to clarify that this means that the number of bits MUST be a multiple of 32. (I got a little confused between bits and bytes here.) Section 4. Likely Is it possible for a 4204-compliant implementation to not do one of these? If so then remove likely. If not, then why happens on the exceptional case?
Gen-ART review of draft-ietf-pwe3-mpls-eth-oam-iwk-07
The -07 version of this draft addresses all of the nits noted in the Gen-ART review of the -06 version. This draft is ready for publication as a Proposed Standard RFC. Thanks, --David From: Black, David Sent: Monday, August 20, 2012 9:58 PM To: dinmo...@hotmail.com; nabil.n.bi...@verizon.com; saja...@cisco.com; gen-...@ietf.org Cc: Black, David; p...@ietf.org; ietf@ietf.org Subject: Gen-ART review of draft-ietf-pwe3-mpls-eth-oam-iwk-06 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-pwe3-mpls-eth-oam-iwk-06 Reviewer: David L. Black Review Date: August 20, 2012 IETF LC End Date: August 20, 2012 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. This draft covers defect behavior for Ethernet pseudowires, including defect state mapping and PE defect reporting behavior. The draft is generally in good shape. I found a few minor nits. 1) The draft uses a lot of acronyms - while each acronym appears to be expanded on first use, an additional section near the start of the draft listing all of them would be helpful. 2) There's a typo in the first paragraph of section 2: covers the following Ethernet OAM (Opertaions, Administration and Opertaions - Operations. 3) The following normative reference is incomplete - please add additional information that will enable a reader to locate the referenced document: [MEF16] Ethernet Local Management Interface, MEF16, January 2006. 4) idnits 2.12.13 did not like the pagination: == The page length should not exceed 58 lines per page, but there was 22 longer pages, the longest (page 1) being 61 lines Thanks, --David David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 david.bl...@emc.commailto:david.bl...@emc.comMobile: +1 (978) 394-7754
答复: 答复: Gen-ART review of draft-ietf-ccamp-lmp-behavior-negotiation-10
Ok, the old formats of Config/ConfigAck/ConfigNack are not necessary to be repeated in this draft. I will clean the text. Thanks, Dan 发件人: Richard Barnes [mailto:r...@ipv.sx] 发送时间: 2013年2月5日 23:09 收件人: Lou Berger 抄送: Lidan (Dan); Richard Barnes; draft-ietf-ccamp-lmp-behavior-negotiat...@tools.ietf.org; gen-...@ietf.org; ietf@ietf.org; The IESG 主题: Re: 答复: Gen-ART review of draft-ietf-ccamp-lmp-behavior-negotiation-10 Hey Lou, That text looks fine to me! --Richard On Tue, Feb 5, 2013 at 9:24 AM, Lou Berger lber...@labn.netmailto:lber...@labn.net wrote: Dan/Richard, On 2/4/2013 10:05 PM, Lidan (Dan) wrote: Hi Richard, Thanks for the review of this draft! Section 2.1. Would be helpful to either include the old formats and/or say explicitly what is changing. Added the original format of Config, ConfigAck and ConfigNack messages which are defined in RFC4204. I personally think it's a mistake to repeat definitions in non-bis RFCs. I think this increases the possibility of mistakes and confusion (e.g., when the text isn't copied properly or when the original document is replaced). My original thought was to propose text to follow Richard's suggestion of explicitly saying what has changed, but I see such text is there at the start of section 2: LMP Config, ConfigNack and ConfigAck messages are modified by this document to allow for the inclusion of multiple CONFIG objects. The Config and ConfigNack messages were only defined to carry one CONFIG object in [RFC4204]. The ConfigAck message, which was defined without carrying any CONFIG objects in [RFC4204], is modified to enable explicit identification of negotiated configuration parameters. The inclusion of CONFIG objects in ConfigAck messages is triggered by the use of the BehaviorConfig object (defined below) in a received Config message. Richard, Is this text sufficient? Alternatively, this text can be moved to immediately proceed the BNF. Much thanks Lou (document co-author)
Re: [mpls] Last Call: draft-ietf-mpls-tp-security-framework-07.txt (MPLS-TP Security Framework) to Informational RFC
Hi Barry, Thank you very much for your review and detailed comments/suggestions, and thanks for your discussion. I uploaded the new version that addressed all your comments, as well as Dan's Gen-ART review comments, and acknowledged your help. http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-security-framework-0 8.txt Please see in-line. -Original Message- From: Barry Leiba barryle...@computer.org Date: Monday, February 4, 2013 5:00 AM To: draft-ietf-mpls-tp-security-framework@tools.ietf.org draft-ietf-mpls-tp-security-framework@tools.ietf.org Cc: m...@ietf.org m...@ietf.org, IETF discussion list ietf@ietf.org Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-security-framework-07.txt (MPLS-TP Security Framework) to Informational RFC The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'MPLS-TP Security Framework' draft-ietf-mpls-tp-security-framework-07.txt as Informational RFC Some Last Call comments in advance of IESG Evaluation: -- Abstract -- This document is built on RFC5920 MPLS and GMPLS MPLS and GMPLS security framework Bit of a stuttering typo there. [luyuan] Fixed. -- General -- There are lots of abbreviations throughout here that aren't expanded. You do send us to documentation (the last paragraph of Section 1), so I wonder how much we should expect every one to be expanded on first use. But I see OAM, GMPLS, PWE3, PE (with and without S- and T-), GAL, G-ACh, BFD, DoS, LSP. [luyuan] We initially had terminology section, it was taken out during the last call discussion. Based on the comments from you and Dan for Gen-ART, I added the term section back with a new list of terms that are relevant to this document. On the other hand, I'm not sure we want to clutter things up with a lot of expansions that anyone who reads the document will already know. So I'll just leave this as a passing comment. -- Sections 2.1 and 2.2 -- It's a small point, but the diagrams for security reference models 1(b), 2(a), 2(b), and 2(c) aren't labelled exactly as the text states. The bad ones are 2(a) and (b), where the diagrams have SPE1 and the text has S-PE. In the others, it's just a question of a - in the text and none in the diagram. As I say, it's a small point, but I'd prefer it if the text and the diagrams matched exactly; removing the dashes in the text seems easiest (and fixing the 1 in the text for the two S-PE cases). [luyuan] Fixed all. -- Section 3 -- This section discuss various network security threats which are to MPLS-TP and may endanger MPLS-TP networks. Is this missing the word new somewhere? (And make it discusses, while you're fixing that. We'll let the RFC Editor do the which-that change; they need something to do.) [luyuan] Fixed. New text: This section discusses various network security threats that are unique to MPLS-TP and may endanger MPLS-TP networks. A successful attack on a particular MPLS-TP network or on a SP's MPLS-TP infrastructure may cause one or more adverse effects. Yes, that would sort of be the definition of a successful attack, I should think. (You might consider deleting this paragraph.) [luyuan] Removed. - GAL or BFD label manipulation, which includes insertion of false labels, messages modification, deletion, or replay. To make the list clearer, I suggest this: NEW - GAL or BFD label manipulation, which includes insertion of false labels and modification, deletion, or replay of messages. END [luyuan] Used suggested text. - DoS attack through in-band OAM G-ACh/GAL and BFD messages. You mean *excessive*, unproductive messages, of course. Is there a good way to say this that can help someone detect when these messages become a DoS attack, or otherwise give some more information? (Maybe there isn't...) [luyuan] New text: DoS attack through in-band OAM by generating excessive G-ACh/GAL and BFD messages which consume significant bandwidth and potentially cause congestion. When a NMS is used for LSP setup, the attacks to NMS can cause the above effect as well. Although this is not unique to MPLS-TP, but MPLS-TP network can be particularly venerable as static provisioning through NMS is a commonly used model. Vulnerable, not venerable. But I don't understand why the fact that static provisioning through NMS causes any greater vulnerability than otherwise. Can you expand on that a bit? [luyuan] New text: When a NMS is used for LSP setup, the attacks to NMS can cause the above effect as well. Although this is not unique to MPLS-TP, MPLS-TP network can be particularly vulnerable to NMS attack due to the fact that static provisioning through NMS is a commonly used model. In the static provisioning model, a compromised NMS can potentially be comparable to a comprised control plane plus a comprised management plane in the dynamic controlled network model. Observation (including
Re: Remote Participation Services
Hi Abdussalam, At 18:14 05-02-2013, Abdussalam Baryun wrote: In the previous ietf meeting in July, I have submitted an I-D in one WG but had no chance to present my participation remotely, as you mention in 2.5. I would like the solution and that I will be able to present remotely. I asked the WG if someone can present for me but only WG darfts are done the way mentioned in 2.5, Please amend the [1] to include that there is difference process in IETF participation remotely for WG I-Ds and Individual I-Ds, I read a review written by Allison Mankin [1]. I doubt that anyone can get a review of that quality in an IETF meeting. It was mentioned previously on this mailing list that meetings were about discussing issues and not about presenting I-Ds. If I have a chance to present my I-D either in person or remotely, what's do the people in the room gain from it? Regards, -sm 1. http://www.ietf.org/mail-archive/web/ietf/current/msg76903.html
Re: Remote Participation Services
On 2/5/13 8:04 AM, IETF Chair wrote: Please see the attached report on the current status of remote participation in the IETF meeting. Please notice at the end a call for potential experiments to explore ways that we can improve remote participation. Thank(s) for doing the summary, I believe understanding what is currently done and what has been done in the past is an important point for dicussion to jump off from. An important consideration imho when the services were volunteer supported (as meetecho still is) is that they were relatively scalable relative to some previous iterations. audio streaming for all meeting(s) in parallel can be run by one person who has other responsibilities and little involvement from inroom participants. bidrectional conferencing typically involves more effort. 2.2. Video In the 1990s as part of the multicast experiment, multicast video was made available, but this experiment has ended without evolving into a production service. The service was offered really in two phases, one in which bidirectional workstation concerning tools were used on both ends vic/vat/sdr/wd and bidirectional participation was possible. (archives were in rtp format) and a phase through approximately the end of 2004 where streams were sourced in one direction. in either case the potential audience was limited by the availability of ip multicast at a location. expired version of the draft covering that time was: http://www.watersprings.org/pub/id/draft-jaeggli-ietftv-ng-01.txt As part of a separate experiment, some sessions use Meetecho to make video available to anyone with a web browser. WG Chairs must request this coverage. When Meetecho is used, the URLs are announced in advance, and the recording becomes part of the session proceedings.
Re: [mpls] Last Call: draft-ietf-mpls-tp-security-framework-07.txt (MPLS-TP Security Framework) to Informational RFC
Thank you very much for your review and detailed comments/suggestions, and thanks for your discussion. I uploaded the new version that addressed all your comments, as well as Dan's Gen-ART review comments, and acknowledged your help. Thanks for the reply, Luyuan. I'm happy with all the resolutions. Barry
Re: Comments on draft-eastlake-additional-xmlsec-uris-07.txt
Hi Bjoern, Thanks for your review and comments. See below. On Wed, Feb 6, 2013 at 6:40 AM, Bjoern Hoehrmann derhoe...@gmx.net wrote: Hi, In http://www.ietf.org/id/draft-eastlake-additional-xmlsec-uris-08.txt the References have to be checked and updated. For example, the document has a normative reference to http://www.w3.org/TR/2002/WD-xptr-20020816/ which is a Superceded work-in-progress that's over 10 years old. Also, Well, the reference is to the most recent document with the title XML Pointer Language (XPointer). After that it seems to have fissioned into a few different documents The only more recent XPointer things are only from 2003 and seem to be XPointer element() Scheme, XPointer Framework, and XPointer xmlns() Scheme. What do you think this reference should point to? it references RFC Errata, Errata ID 191, RFC 4051 without linking the errata item, and does so normatively even though the document as a whole I'm not sure exactly what you mean here. The errata does appear in the references as [Errata191] - RFC Errata, Errata ID 191, RFC 4051, http://www.rfc- editor.org I have been told by an Area Director that this it the format that the RFC Editor likes. You can certainly find the Errata starting with that link and by just linking to the main ref-editor.org web page, it does not constrain the other structure of that web site. would Obsolete RFC 4051. Just to illustrate, I did not review them all myself. OK. I will move the Errata to the Informational references. The Abstract does not english. How about the following change: OLD This document expands and updates the list of URIs specified in RFC 4051 and intended for use with XML Digital Signatures, Encryption, Canonicalization, and Key Management. These URIs identify algorithms and types of information. This document obsoletes RFC 4051. NEW This document obsoletes RFC 4051, expanding and updating the list of URIs intended for use with XML Digital Signatures, Encryption, Canonicalization, and Key Management. These URIs identify algorithms and types of information. I don't think it's a good idea to have the Acknowledgements precede even the Introduction as an exception while most other documents put it near the end. I disagree. I believe acknowledgments are very important and should be at the front. I commonly (but not always) put them there in my drafts. I am also not aware of any IETF rule prescribing where Acknowledgements go in Internet Drafts. It is true that the RFC Editor always move them to the end, but that's the way it goes. The XCANON reference does not work, xml-enc-c14n-20020718 is perhaps meant to be xml-exc-c14n-20020718 (enc vs exc). I've not checked other references. http://www.w3.org/TR/REC-xml-enc-c14n-20020718/ is still there from RFC 4051 which this document obsoletes. Reference should be http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/ The document makes reference to Canonical XML 1.0 without referencing, e.g. http://www.w3.org/TR/C14N-issues/ (and RFC 3076 does not seem to have any Errata filed to hint at the problems with it). I'm not sure that's a problem, but it might be better to mention the problems with Canonical XML 1.0 in some form. Well, I would have thought that the issues in C14N-issues would be resolved in Canonical XML 1.1 which is dated later. In any case, problems in Canonical XML 1.0 seem irrelevant to this document which is just about what URIs represent what algorithms or data items. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com regards, -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: Comments on draft-eastlake-additional-xmlsec-uris-07.txt
Hi Donald, At 18:48 06-02-2013, Donald Eastlake wrote: I'm not sure exactly what you mean here. The errata does appear in the references as [Errata191] - RFC Errata, Errata ID 191, RFC 4051, http://www.rfc- editor.org I have been told by an Area Director that this it the format that the RFC Editor likes. You can certainly find the Errata starting with that link and by just linking to the main ref-editor.org web page, it does not constrain the other structure of that web site. [Errata191] was a normative reference. Referencing errata in an intended Proposed Standard might be a trivial matter. There are side effects to that. That may only be apparent in the long term. I hope that the RFC Editor does not plan to turn Standard Track RFCs into living standards. OK. I will move the Errata to the Informational references. See above. I disagree. I believe acknowledgments are very important and should be at the front. I commonly (but not always) put them there in my drafts. I am also not aware of any IETF rule prescribing where Acknowledgements go in Internet Drafts. It is true that the RFC Editor always move them to the end, but that's the way it goes. I noticed that you are one of the rare authors who has the Acknowledgements at the beginning of their document. It was a practice followed in some of the three-digit RFCs. There isn't any requirement in the RFC Style Guide which prohibits the Acknowledgements from being at the front of the document. I don't know whether it is relevant but John Klensin mentioned this a few days ago: One might even suggest that one of the reasons early ARPANET/ Internet developments worked better than the IETF process of today is that there was wide recognition that it was necessarily a collaborative effort with many people contributing ideas and no one wanting to seize credit. Section 5 mentions that This document requires no IANA actions. However, there is another paragraph in the IANA Considerations section which is not even actionable by IANA folks. I am not sure whether the text should go into that section. In Section 1: Note that raising XML Digital Signature to Draft Standard [RFC3275] in the IETF required removal of any algorithms for which there was not demonstrated interoperability from the Proposed Standard document. This required removal of the Minimal Canonicalization algorithm, in which there appears to be continued interest. The URI for Minimal Canonicalization was included in [RFC4051] and is included here. That was the historic rationale for the different levels in the Standards Track. Rumor has it that although the rationale was forgotten, whether intentionally or not, the MUST wars continued. Dave Crocker once raised the question of complexity of a specification. Advancement along the Standards could have been used to make a specification less complex by trimming stuff which has not been implemented (see quoted text above). In Section 2.1.1: The content of the DigestValue element shall be the base64 [RFC2045] encoding of this bit string viewed as a 16-octet octet stream. RFC 4648 could be reference instead of RFC 2045. Regards, -sm
Nomcom 2012: Feedback on TSV Nominees
Thanks to everyone who helped the IETF Nominating Committee (Nomcom) by responding to our call for Transport (TSV) Area Director nominations. Three individuals accepted nominations for the TSV area director position. The Nomcom is therefore seeking input from the community about whether these nominees are a good fit for the TSV Area Director position. The Nomcom is therefore seeking community feedback about the following individuals: -- Spencer Dawkins -- Mark Townsley -- Margaret Wasserman -- Ken Carlberg -- Linda Dunbar -- Tom Haynes The Nomcom is happy to accept input from the community either via email to nomco...@ietf.org or via our web tool: https://www.ietf.org/group/nomcom/2012/input/ Note that our webtool requires an ietf.org login, anyone can easily get an ietf.org account at: https://datatracker.ietf.org/accounts Note that the Nomcom is following the guidelines in RFC 5680 in making public the list of individuals who have agreed to be considered for the position of TSV Area Director. The Nomcom is operating on a very tight time schedule, and would appreciate input as soon as possible. To ensure your input is received in time to be useful to the Nomcom please send input on or before Monday, February 11. Thanks again for your help, - Matt Lepinski nomcom-ch...@ietf.org
Last Call: draft-arkko-iesg-crossarea-02.txt (Experiences from Cross-Area Work at the IETF) to Informational RFC
The IESG has received a request from an individual submitter to consider the following document: - 'Experiences from Cross-Area Work at the IETF' draft-arkko-iesg-crossarea-02.txt as 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 i...@ietf.org mailing lists by 2013-03-06. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This memo discusses the reasons for IETF work on topics that cross area boundaries. Such cross-area work presents challenges for the organization of the IETF as well as on how interested parties can participate the work. The memo also provides some suggestions on managing these challenges. The file can be obtained via http://datatracker.ietf.org/doc/draft-arkko-iesg-crossarea/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-arkko-iesg-crossarea/ballot/ No IPR declarations have been submitted directly on this I-D.
