Re: Community Input Sought on SOWs for RFC Production Center and RFC Publisher
The point w.r.t. MIB module checking was that during editing phase, even a small typo in a double quote or some such would render the MIB module invalid/non-compilable (i.e. invalid SYNTAX). So if RPC does not touch the text at all, then there is no need for them to check. But if they DO touch it (even for pagination or some such) I would recommend doing the check. For MIB modules that should be pretty easy, simple and not cause much extra work. Of course the MIB module needs to be checked (SYNTAX that is) BEFORE it gets submitted to AD/IESG even. Bert On 8/17/13 2:09 PM, Jeffrey Hutzelman wrote: While I have no objection in principle to the RPC doing this check, it seems likely that the burden of doing so would be significant and, at least for IETF-stream documents, not worthwhile for the relatively small gains realized. This sort of check should be done before a document is ever submitted to the IESG, let alone the RPC.
Re: Nomcom off in the wilderness: Transport AD
Dave, it seems to me that with your suggestion it feels as if you (or we the community) want to redo some of the nomcom work? I.e. you do not trust their evaluations? They also have received (I presume) lots of feedback on the candidates and probably did some interviews. We do not have that info. So tough to challenge them based on only nominees statements. Bert Wijnen On 3/6/13 2:57 PM, Dave Crocker wrote: On 3/6/2013 4:26 AM, Sam Hartman wrote: However, there is something you can do. Take a quick moment to look at the set of nominees and consider what you know about their qualifications. ... > I'd also appreciate private feedback on how I could improve my approach for raising this concern. I'm not at all sure that sending this message was the best choice, ... I don't have an opinion about the current candidates. This note concerns Sam's effort: I think it's thoughtful and reasonable, within the bounds of the situation, IETF rules, and IETF culture. And I have a further suggestion, which some other folk and I happened to have discussed privately some time ago and unrelated to the specific TSV situation... There's an option available that the candidates might want to consider, to facilitate the public review of candidate qualifications: Candidates fill out a questionnaire for Nomcom review. Roughly, it has two parts, with one that is available to Nomcom and the appropriate Confirming Body, and a second that is withheld from the Confirming Body. Candidates could choose to circulate the first part publicly. Nomcom is prohibited from making these documents public, but the candidates are not. The long-standing argument against publicly issuing this information is that it might be seen as politicking, and the IETF Nomcom process tries hard to avoid such opportunities. The language in the forms is necessarily self-promoting. After all, the candidate is trying to explain why they think they are appropriate for a job. However there is a difference between explaining why you think you are qualified, versus the hype of politicking. One would hope that IETF participants can tell that difference. And it could be helpful for the community to see how a candidate sees themselves. d/
Re: request to make the "tools version" of the agenda the default
+1 On 11/29/12 7:11 PM, Wes Hardaker wrote: So, the 'tools version' with all the wonderful spiffy links to helpful things (the materials, the etherpad, the ...) and the spiffy highlighting ability (Dark Red! I love dark red!) has been very stable and highly useful for quite a while now. But the default link on the web page still points to the less-useful HTML version (which has a link at the top to get to the tools version). I'd argue this is backwards at this point, and the tools version is so much more useful (and just as stable) as the plain-html version that it should be the default. Can we do that for March+? [I know, we just *ended* a face-to-face meeting so why am I bringing up face-to-face meeting topics so far before the next one? That's unheard of! Call me crazy...]
Re: Last Call: (LISP EID Block) to Informational RFC
Nice to try and keep it short. But I was hoping for some more detail and explanation. I have not followed the discussions (if any) in the WG so I may be missing the reasons why you need this much space. I would hope that the WG (if they have consensus (which may be something different than "the WG felt")) could elaborate or summarize the discussions that lead to the conclusion that this amount of space is needed and makes sense. Pointers to the WG mlist discussions where the pros and cons of various prefixes sizes are discussed or summarize would also be welcome. Bert On 11/15/12 3:46 PM, Luigi Iannone wrote: Hi Bert, On 15 Nov. 2012, at 11:55 , Bert Wijnen (IETF) wrote: [snip] So it is not asking just a /16 but also asking for reservation of a /12. Pretty big space. And in the list of reasons, I mainly read that it is "sufficiently large", but not much about why it needs to be this big. Why would a smaller allocation not be sufficient? Well, to keep it short, the WG felt that /16 is the "right size", and that if the growth of LISP would be so important as to need a bigger space would be nice to have it contiguous (so implementations can just change the prefix length). Luigi Bert
Re: Last Call: (LISP EID Block) to Informational RFC
On Tue, Nov 13, 2012 at 3:45 PM, The IESG wrote: > > The IESG has received a request from the Locator/ID Separation Protocol > WG (lisp) to consider the following document: > - 'LISP EID Block' >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 > ietf at ietf.org mailing lists by 2012-11-27. Exceptionally, comments may be > sent to iesg at ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > >This is a direction to IANA to allocate a /16 IPv6 prefix for use >with the Locator/ID Separation Protocol (LISP). The prefix will be >used for local intra-domain routing and global endpoint >identification, by sites deploying LISP as EID (Endpoint IDentifier) >addressing space. Mmm... In section 5 it states: The working group reached consensus on an initial allocation of a /16 prefix out of a /12 block which is asked to remain reserved for future use as EID space. The reason of such consensus is manifold: So it is not asking just a /16 but also asking for reservation of a /12. Pretty big space. And in the list of reasons, I mainly read that it is "sufficiently large", but not much about why it needs to be this big. Why would a smaller allocation not be sufficient? Bert
New on RIPE Labs: Global Effect of Hurricane Sandy as Seen in RIPE Atlas
Emile Aben, a colleague of mine did some more analysis. In this new RIPE Labs article he looks at some of the effects Hurricane Sandy had on the Internet data plane, as we can see them in traceroutes done by RIPE Atlas: https://labs.ripe.net/Members/emileaben/ripe-atlas-hurricane-sandy-global-effects I figured that some of you might find this interesting. Bert
Re: Recall petition for Mr. Marshall Eubanks
Thanks for extra info. You can add me to the list who sign the request for recall. Bert --On Saturday, 03 November, 2012 11:36 -0400 Russ Housley wrote: John: I assume at this point the IAOC would like to pursue the recall option? If not, please be very clear about it to the list as I haven't actually seen a request from the IAOC for that process to proceed as far as I can tell. Because I am personally very reluctant to see this handled by recall, I want to ask a slightly different question: Are the people who met with Marshall convinced that he understood that, if he did not resign, a recall was almost certain to be initiated as our next step. If the answer is "yes", he's made his choice and I am ok with signing the petition. If not, it is possible that more discussion would be in order after the petition process is complete. I hope that, when Lynn accepts the petitions, another effort (or several) will be made to et Marshall's attention -- it presumably is not too late for him to resign until after the relevant committee is appointed. At the end of our visit, I believe that Marshall understood that there were three possibilities: 1) Tell the community that he intends to resume participation; 2) Resign; 3) Do nothing, which would very likely result in a recall. Russ
Re: Doesn't the legal standard for maintaining documents also control this? - Re: IESG Statement on Removal of an Internet-Draft from the IETF Web Site -
tglassey wrote: > //Confidential Mailing - Please destroy this if you are not the intended > recipient. Oh.. better safe than sorry then poof
RIPE NCC ATLAS Measurements around Sandy
In case people are interested. Some of you might be interested to know that we have tried to see any impacts of Sandy via our ATLAS measurements. Latest update of the graphs: http://albatross.ripe.net/demo-area/sandy-2012/ Article that explains the graphs https://labs.ripe.net/Members/emileaben/ripe-atlas-superstorm-sandy Bert
Re: Last Call: Modern Global Standards Paradigm
I support that IETF and IAB chairs sign this document. Bert - Original Message - From: "IETF Chair" To: "IETF-Announce" Cc: "IAB" ; "IETF" Sent: Friday, August 10, 2012 5:19 PM Subject: Last Call: Modern Global Standards Paradigm The IETF Chair and the IAB Chair intend to sign the Affirmation of the Modern Global Standards Paradigm, which can be found here: http://www.ietf.org/proceedings/84/slides/slides-84-iesg-opsplenary-15.pdf An earlier version was discussed in plenary, and the IAB Chair called for comments on the IETF mail list. This version includes changes that address those comments. Th IETF 84 Administrative plenary minutes have been posted, so that discussion can be reviewed if desired. The minutes are here: http://www.ietf.org/proceedings/84/minutes/minutes-84-iesg-opsplenary On 8 August 2012, the IEEE Standards Association Board of Governors approved this version of the document. The approval process is underway at the W3C as well. The IETF Chair and the IAB Chair intend to sign the Affirmation in the next few weeks. Please send strong objections to the i...@iab.org and the ietf@ietf.org mailing lists by 2012-08-24. Thank you, Russ Housley IETF Chair
Re: Last Call: (Multiprotocol Label Switching Transport Profile (MPLS-TP)MIB-based Management Overview) to Informational RFC
My review of draft-ietf-mpls-tp-mib-management-overview-05.txt It was a quick review, so that you have some idea of what I looked at. For a real review, I think it would take a lot of time. But feel free to use my comments as you see fit. As long as people realize that it was a quick skim and not a detailed review Bert Original Message Subject: Re: [MIB-DOCTORS] FW: Last Call: (Multiprotocol Label Switching Transport Profile (MPLS-TP)MIB-based Management Overview) to Informational RFC Date: Wed, 30 Nov 2011 12:03:47 +0100 From: Bert Wijnen (IETF) To: Romascanu, Dan (Dan) CC: mib-doct...@ietf.org, ops-...@ietf.org I did a skim of the document. - It seems to give an in depth overview of the current MIB modules in MPLS related space and also it lists identified gaps if those MIB modules need to support MPLS-TP space. - it looks to be in reasonable (good enough I guess) shape for publication as Informational RFC modulo some remarks below. - I did not go and check all the details and related documents. So I cannot claim that I have verified all (in fact any) of the statements. - I wonder if the "may be extended" and "can be extended" in the various subsections in section 5 are intended to mean different things. I think not. To me it all sounds like "this could be done, but we doubt anyone will do it, or at least not in IETF". - Section 6 however DOES define what needs to be done in terms of new MIB modules, so that is promising. - I see in sect 6.1.2 that a MEP Identifier TC needs to be defined. Is this a similar identifier as the MEP Identifier defined in IEEE 802.1ag? Probably not, but someone should probably check at the time they start developing this MPLS-TP-TC MIB module. - sect 6.2.1 sems to want tio place a TC MIN module directly under "transmission". I am not sure that is the proper place. So I am not sure how useful my short review is, other than to say that a document like this (assuming the data is correct and complete) is helpful for people who need to implement Network Management systems for MPLS and MPLS-TP based systems. Bert On 11/28/11 4:27 PM, Romascanu, Dan (Dan) wrote: MIB Doctors and OPS-MIB directorate members, This I-D deserves your attention, please read and send comments to the last call. Regards, Dan -Original Message- From: ietf-announce-boun...@ietf.org [mailto:ietf-announce-boun...@ietf.org] On Behalf Of The IESG Sent: Monday, November 28, 2011 5:07 PM To: IETF-Announce Cc: m...@ietf.org Subject: Last Call: (Multiprotocol Label Switching Transport Profile (MPLS-TP)MIB-based Management Overview) to Informational RFC The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Multiprotocol Label Switching Transport Profile (MPLS-TP) MIB-based Management Overview' 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 2011-12-12. 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 A range of Management Information Base (MIB) modules has been developed to help model and manage the various aspects of Multiprotocol Label Switching (MPLS) networks. These MIB modules are defined in separate documents that focus on the specific areas of responsibility of the modules that they describe. The MPLS Transport Profile (MPLS-TP) is a profile of MPLS functionality specific to the construction of packet-switched transport networks. This document describes the MIB-based architecture for MPLS-TP, and indicates the interrelationships between different existing MIB modules that can be leveraged for MPLS-TP network management and identifies areas where additional MIB modules are required. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-mib-management-overvi ew/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-mib-management-overvi ew/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ MIB-DOCTORS mailing list mib-doct...@ietf.org https://www.ietf.org/mailman/listinfo/mib-doctors ___ MIB-DOCTORS mailing list mib-doct...@ietf.org https://www.ietf.org/mailman/listinfo/mib-doctors ___ MIB-DOCTORS mailing list mib-doct...@ietf.org https://www.ietf.org/mailman/listinfo/mib-doctors ___ Ie
Re: https
Yup, but why are we using https at all? Who decided, and please would they undecide? Unexpired certificates can be circumvented, but all too often, the https parts of the web site just do not work and, more importantly, I think it wrong to use industrial grade security where none is called for. I agree with Tom here. In my understanding, all IETF communications and (mailing list) discussions are open and public. So why do we need to protect/encrypt? I would say: protect what must be protected but don't protect what is not supposed to be protected. just encrypting everything seems incorrect to me. Bert Tom Petch ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Standards
I LOVE this one. Bert On 7/20/11 8:23 AM, Yoav Nir wrote: Hi Very appropriate for XKCD to post this just a few days before an IETF meeting. http://www.xkcd.com/927/ (For those who are not familiar with XKCD, don't miss the alt-text on the picture) Yoav ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Confidentiality notices on DNS messages
On Jul 12, 2011, at 11:28 PM, Barry Leiba wrote: > I am increasingly seeing IETF participants posting messages to IETF > mailing lists, sending messages to chairs and ADs, and so on, where > their messages include confidentiality/security/legal notices at the > bottom. The first ones have shown up in the DNS e.g the BSRPDNSC implementation[*] returns a disclaimer: dig 10.sin.5.+.rp.secret-wg.org TXT ;; Truncated, retrying in TCP mode. ; <<>> DiG 9.6.0-APPLE-P2 <<>> 10.sin.5.+.rp.secret-wg.org TXT ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14586 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;10.sin.5.+.rp.secret-wg.org. INTXT ;; ANSWER SECTION: 10.sin.5.+.rp.secret-wg.org. 10 IN TXT "4.45597888911063" 10.sin.5.+.rp.secret-wg.org. 10 IN TXT "This DNS message (including the RR(s) in the additional section) is confidential, proprietary, may be subject to copyright and legal privilege and no related rights are waived." "If you are not the intended recipient or its agent, any review, dissemination, distribution or copying of this DNS message or any of its content is strictly prohibited and may be unlawful." "All messages may be monitored as permitted by applicable law and regulations and our policies to protect our business." "DNS messages are not secure and you are deemed to have accepted any risk if you communicate with us using DNS." "If received in error, please notify us immediately and delete the DNS message (and any of its sections) from any computer or any storage medium without printing a copy." ;; Query time: 34 msec ;; SERVER: 213.154.224.155#53(213.154.224.155) ;; WHEN: Wed Jul 13 10:17:21 2011 ;; MSG SIZE rcvd: 851 -- Bert's secretary [*] BSRPDNSC: Bert's Secure Reverse Polish DNS Calculator http://bert.secret-wg.org/Tools/index.html#Tool_3 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: one data point regarding native IPv6 support
I have a "Business service" from my ISP too. They told me that somewhere in 2012 they would look into IPv6. So I have threatened to move to another provider. But we do not have much choice in NL at the moment I believe. Although I have to re-checked recently. Bert On 6/10/11 3:04 PM, Thomas Nadeau wrote: Sadly this is more common than it should be these days. I've been begging Fairpoint for IPv6 for the past 3 years, from which people in NH/VT/ME now have been subjected to as Verizon sold off FIOS/dsl in those areas to them a while back. I have "business" service from them with static IPs and the whole 9 yards, and they still insist that I am mad when I call to ask for IPv6 siting the same reasons you are being given. --Tom I just called my ISP to ask about availability of IPv6 at my home. Me: "I'm a current customer, and I'm just calling to ask if you support Internet Protocol Version 6." First person: "Yes, we do support Internet. We support DSL at 3 megabits and 6 megabits." Me: "I understand that, but I'm asking about Internet Protocol version 6, IPv6. The Internet has been using IP version 4 since the early 1980s, but that's running out. IPv6 is the new version." First person: "Let me transfer you to support." Second person: "Hi, this is support. How may I help you?" Me: "I'm a current customer, and I'm just calling to ask if you support Internet Protocol Version 6." Second person: "IP version what?" Me: "Internet protocol version 6". Second person: "I have no idea. Let me transfer you to someone else." (places me on hold for 15 minutes) Second person: "I'm sorry for the wait time. I've been trying to find the answer to your question, but nobody here seems to know anything about it. We're trying to get in touch with people who run the network to ask them. Can I get your number and call you back?" Granted, this is just one ISP. The other ISP that offers service in my area put me on hold for an hour and a half *before anyone ever talked to me* when I tried to get a quote from them, so I concluded that they wouldn't be a good choice. And these guys have been good about support in general. They seem to know their stuff, which is more than I can say for some ISPs I've dealt with in the past. I live in a well-settled urban area, three miles from the center of the city (and sadly, four miles from my CO, which means my DSL circuit gets around 380kbits/sec). It's not a backwater, there's plenty of lit fiber running through town. But when the support people for a fairly well-established telco haven't even heard of IPv6, it's hard to believe that it's going to be available anytime soon. Meanwhile, 6to4 continues to work just fine for me. So please explain again why it isn't premature to discourage a valuable transition mechanism? Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAOC: delegating ex-officio responsibility
On 3/30/11 1:21 PM, Olaf Kolkman wrote: Dear Colleagues, I have just chartered a very short draft that intends to update BCP101. It can be found at: http://tools.ietf.org/html/draft-kolkman-iasa-ex-officio-membership The draft is very short and contains only a few sentences of substance: The IETF chair, the IAB chair, and the ISOC President/CEO may delegate their responsibilities to other persons. The delegations by the IETF chair and the IAB chair need to be confirmed by the IESG and IAB respectively. The terms of delegation is for a longer term for instance aligned with the IESG and IAB appointment cycles (roughly anual). It reads as a generic "may delegate their responsibilities". So taking that paragraph out of context may confuse people. Why not make it explicit: The IETF chair, the IAB chair, and the ISOC President/CEO may delegate their IAOC and/or IETF Trust responsibilities to other persons. ... Bert ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Review of draft-ietf-netconf-4741bis-07
Revision 9 is out and tried to address IETF LC comments Here is the diff between the rev you reviewed and the latest one: http://tools.ietf.org/rfcdiff?url1=draft-ietf-netconf-4741bis-07&url2=draft-ietf-netconf-4741bis-09 Bert document shepherd On 2/8/11 3:05 AM, Tina Tsou wrote: I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. It is well written, so only some editorial comments are below. #1 " 2.2. Authentication, Integrity, and Confidentiality ... 2.3. Authentication ... " Perhaps the Titles of 2.2 and 2.3 can harmonize better to explain why there are two "authentications" here. #2 " 6.2. Subtree Filter Components A subtree filter is comprised of XML elements and their XML attributes. There are five types of components that may be present in a subtree filter: o Namespace Selection o Attribute Match Expressions o Containment Nodes o Selection Nodes o Content Match Nodes ... " If a figure could be provided to describe the relationship among these 5 components and when it becomes what, it would be very helpful for readers to understand more easily. #3 " 6.2.3. Containment Nodes Nodes that contain child elements within a subtree filter are called "containment nodes". I would say "Child Elements Nodes" or "Child Nodes" might be a little bit more of straight forward than "Containment Nodes". #4 " 7.2. ... Parameters: ... merge: The configuration data in the parameter is merged with the configuration at the corresponding level in the target datastore. This is the default behavior. ... " Has the parameter been introduced before? Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
opsdir review of draft-ietf-speermint-architecture-17.txt
I was appointed to review this document from an OPS-DIR point of vie, i,e, to check for operational or management aspects. This are is not my space of expertise, so don't rely too much on my report. I think that there might be some operational aspects in the sense that sometimes secure/encrypted connections are needed and other times it may be OK to use unencrypted connections if they are inside the same secure building. So is there not something for an operator to configure in such cases? typo: Section 4, 4th bullet, 2nd sub bullet: * LUF can communicator with SF and SBE s/cator/cate/ Section 5.1.1.2 2nd para: If an im: or pres: URI is chosen based on an "E2U+im" [RFC3861] or "E2U+pres" [RFC3953] enumserver, the SSP follows the procedures for resolving these URIs to URIs for specific protocols such a SIP or XMPP as described in the previous section. s/such a SIP/such as SIP/ Bert Wijnen ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Publishing list of non-paying IETF attendees, was Re: [IAOC] Badges and blue sheets
On Nov 14, 2010, at 10:55 PM, Ole Jacobsen wrote: > > Bert on the other hand has clearly been taking advantage of us for > years, we should put a stop to that :-) The Secret Working Group has ways to sneak me into your meetings, which includes bribes, corruption, intimidation, backdoors, and complementary funds of the I* chairs. Bert http://bert.secret-wg.org/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
Although I do sort of also agree with Scott, I think it is one step in the right direction. So please seen a sponsor and get it published. Bert On 10/26/10 4:48 AM, Scott O. Bradner wrote: I'd like to hear from the community about pushing forward with this proposal or dropping it I do not think this proposal fixes any known problems the major reason (imo) that technology is not advanced along the standards track is because there is no need to do so. someone labors for a while to get a proposed standard published and people start to use it (if they did not start at the Internet Draft stage) soon about anyone that has a need for the technology has implemented it and it is being used by customers all over the globe just what is the reason that someone would take time from working on new technology to do the work to advance the proposed standard? it is unlikely that all that many more people will implement or use the technology so what is the point? in addition, the IESG acts as if the proposed standard will be the last step in the publication process (or at least reviews IDs as if this were the case) so we have all the benefits of the cross area review (this making the proposed standards about as good as one could without requiring interoperable implementations at the first stage (i.e. bringing back running code)) so I say drop it and live with the fact that rfc 2026 does not paint an accurate picture of the current one step standard process Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: Policy Statement on the Day Pass Experiment
Inline - Original Message - From: "Robert Elz" To: "IETF" Cc: Sent: Friday, May 07, 2010 1:57 PM Subject: Re: Last Call: Policy Statement on the Day Pass Experiment Date:Thu, 06 May 2010 18:07:40 -0400 From:The IESG Message-ID: <4be33dac.80...@ietf.org> | The IESG is considering the following Statement on the Day Pass | Experiment. The IESG plans to make a decision in the next few weeks on | a policy statement, and the IESG actively solicits comments on this | action. I have two (different types of) comments to make.First, and most important by far, is WTF ??? I understand the need for IESG "Statements" from time to time, but the very worst thing to possibly to be making such statements about is the process by which the IESG (and more of course) is selected - if there was anything about which there's an obvious and clear conflict of interest, it is this. But be fair: they are doing an IETF Last Call BEFORE they decide on the statement. Is that not how you try to determine consensus within the whole IETF? Bert ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Appeal to the IESG concerning the approbation of the IDNA2008 document set.
+1 Bert Brian E Carpenter wrote: On 2010-03-11 13:09, David Kessens wrote: On Wed, Mar 10, 2010 at 03:42:12PM -0800, Dave CROCKER wrote: The prudent action is to return it to the appellant, stating that it cannot be processed until it has been made clear and concise. I fully support such an approach (and did propose the same strategy to the IESG while I was a member of the IESG myself). I agree. Our process may be complicated, but a deviation from due process that requires 145 pages of description is simply not possible. We have specific rules in RFC 2026 and RFC 2418 (and various updates) and it should be possible to describe specific alleged deviations from those rules in a page or two. If the appeal merely reflects the fact that the appellant disagrees with the WG consensus, that is not a ground for appeal. I do not believe the IESG is under any obligation to spend its precious time digesting such a mass of text to discern any actual grounds for appeal. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: secdir review of draft-ietf-netconf-partial-lock-09.txt
Stephen, I think it is your first bullet point. We have not standardize it yet. And so it is implementation dependent as to what authorization is used. Bert Stephen Hanna wrote: Tom, Thanks for responding to my comments. Allow me to respond. You wrote: As a participant in netconf, I see authorization as one of those topics which the Working Group sees as necessary but cannot be tackled just yet. As RFC4741 says, " This document does not specify an authorization scheme, as such a scheme should be tied to a meta-data model or a data model." and as yet, there is no data model; hence, no authorization, not yet, nor, IMHO, for some time to come. This is just the sort of background information that a WG participant would know but that a secdir reviewer would not. Please allow me to ask a clarifying question. You say that there is no authorization yet. I think that could mean several things: 1) Existing NETCONF implementations implement authorization, ensuring that each user gets an appropriate and perhaps different level of access to the database. However, there are no standards for the manner in which authorization is performed or configured. 2) Existing NETCONF implementations require authentication but generally just give complete read-write access to the database to all authenticated users. 3) Existing NETCONF implementations do not require authentication. Anyone with network access has complete, unfettered access to the database and can modify it at will. Could you tell me which of these meanings is most accurate? Of course, it could be a mix of these but I'd like to get your real-world assessment of the state of the NETCONF world. If the answer is 3), we have a serious problem! If the answer is 1) or 2), that's acceptable in my view. Now on to the language in the draft. My comment was relating to this quote from the Security Considerations: "Only an authenticated and authorized user can request a partial lock." I'm afraid that this statement is not justified if there is no normative text requiring implementations to comply. I suggest that normative text be added to at least require authentication. With such text, the statement above could be justified. Requiring that levels of authorization be implemented is less important in this application. And standardizing the manner in which authorization is performed or configured (which I think is your concern with respect to the lack of a data model) is really not important at all unless NETCONF customers or vendors decide that it is. Standardizing an authorization policy format is a tremendously challenging task for any protocol and often not necessary. I hope that this helps you address my comments in a reasonable and achievable manner. The intent of secdir comments is not to impose unreasonable requirements. It is to point out issues that might not be evident to someone who is not a security expert. Thanks, Steve -Original Message- From: Tom.Petch [mailto:sisyp...@dial.pipex.com] Sent: Thursday, August 13, 2009 4:00 AM To: Stephen Hanna; sec...@ietf.org; ietf@ietf.org; draft-ietf-netconf-partial-l...@tools.ietf.org Subject: Re: secdir review of draft-ietf-netconf-partial-lock-09.txt - Original Message - From: "Stephen Hanna" To: ; ; ; Sent: Monday, August 10, 2009 4:28 PM I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines optional partial-lock and partial-unlock operations to be added to the NETCONF protocol. These operations are used to lock only part of a configuration datastore, allowing multiple management sessions to modify the configuration of a device at a single time. The Security Considerations section of the document highlights the risk that a malicious party might employ partial locks to impede access to a device's configuration. Therefore, it states "Only an authenticated and authorized user can request a partial lock." Unfortunately, I cannot find any normative text (MUST) that supports this statement. The NETCONF spec (RFC 4741) says "NETCONF connections must be authenticated" but this is not clearly normative. Perhaps a NETCONF expert can point to some normative text requiring authentication and authorization for any party requesting a partial lock. If not, I suggest that such normative text be added to the partial-lock specification. As a participant in netconf, I see authorization as one of those topics which the Working Group sees as necessary but cannot be tackled just yet. As RFC4741 says, " This document does not specify an authorization
Last Call: draft-ietf-rserpool-mib (Reliable ServerPooling: Management Information Base using SMIv2) toExperimental RFC)
-layer protocol (IPv4 or IPv6) of an IP address of
an ENRP transport endpoint."
::= { enrpServerENRPAddrTableEntry 2 }
Then I wonder if it would not be better to SUBTYPE the TC
So something like
SYNTAX InetAddressType{ipv4(1), ipv6(2)}
The associated
enrpServerPeerL3Addr OBJECT-TYPE
SYNTAX InetAddress
would then become
enrpServerPeerL3Addr OBJECT-TYPE
SYNTAX InetAddress (SIZE(4|16))
all this assuming that you explicitly want to only support IPv4 and IPv6
and
not DNS and not Scoped IPv6 addresses
- According to RFC4181 this one
rserpoolMIBConformance OBJECT IDENTIFIER ::= { rserpoolMIB 4 }
should change to
rserpoolMIBConformance OBJECT IDENTIFIER ::= { rserpoolMIB 2 }
I do not see a reason why the recommended MIb structure in RFC4181 would
not be followed.
- This
DESCRIPTION "The group of ENRP servers"
::= { rserpoolMIBGroups 1 }
is of course not a good DESCRITPION clause.
It is I think "The group of objects to manage/monitor ENRP servers."
or some such.
Same for otehr groups
-
Abstract
RSerPool [RFC5351] is a framework to provide reliable server pooling.
This document defines a SMIv2 compliant Management Information Base
(MIB) providing access to managed objects in an RSerPool
implementation.
Normally, citations are not supposed to be in the abstract. But that is a
NIB,
The document however, does not define a MIB, but a MIB module.
I know some people think this is a nit too. The introduction has irt right.
Seuritty considerations is weak. It does not state anything about the
possible secuirty issues/concerns when peole get read and/or write
access to the various objects.
s /IPSec/IPsec/ as well
I think that RFC4001 is missing from the NORMATIVE references list
The REVISION clause should probably contain something like
REVISION "200901221012Z" -- January 22, 2009
DESCRIPTION
"This version of the MIB module published as RFC ."
Bert Wijnen
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-forces-mib (ForCES MIB) to Proposed Standard
I sort of wonder if the Counter32 is the proper datatype for some of the counters. They sound more like ZeroBasedCounter32 to me. Further I do not see any text regarding possible discontinuities. Bert Wijnen - Original Message - From: "The IESG" <[EMAIL PROTECTED]> To: "IETF-Announce" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, August 25, 2008 10:42 PM Subject: Last Call: draft-ietf-forces-mib (ForCES MIB) to Proposed Standard > The IESG has received a request from the Forwarding and Control Element > Separation WG (forces) to consider the following document: > > - 'ForCES MIB ' >as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2008-09-08. Exceptionally, > comments may be sent to [EMAIL PROTECTED] instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-forces-mib-07.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14188&rfc_flag=0 > > ___ > IETF-Announce mailing list > [EMAIL PROTECTED] > https://www.ietf.org/mailman/listinfo/ietf-announce > > ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
new text for ID_Checklist sect 3, item 6
The revision 1.8 of the ID-Checklist is at http://www.ietf.org/ID-Checklist.html Sect 3, item 6 in that revision states: 6. Addresses used in examples SHOULD use fully qualified domain names instead of literal IP addresses, and SHOULD use example fqdn's such as foo.example.com instead of real-world fqdn's. See [RFC2606] for example domain names that can be used. John Klensin has proposed new text, whcih was amended by Ted Hardie and the resulting text (if I understood it correctly) is: "6. Addresses used in I-Ds SHOULD use fully qualified domain names (FQDNs) instead of literal IP addresses. Working Groups or authors seeing exemptions from that rule MUST supply the rationale for IP address use with inline comments (e.g., "Editor's note:" or "Note in Draft:" that can be evaluated by the IESG and the community along with the rest of the document. Example domains in pseudo-code, actual code segments, sample data structures and templates, specifically including MIB definitions and examples that could reasonably be expected to be partially or entirely copied into code, MUST be drawn from the list reserved for documentary use in BCP32 (RFC 2606 or its successors). It is generally desirable for domain names used in other I-D discussion contexts to be drawn from BCP32 as well, if only as an act of politeness toward those who might be using the domains for other purposes at the time of publication or subsequently. Working groups or editors who are convinced that different names are required MUST be prepared to explain and justify their choices and SHOULD do so with explicit inline comments such as those described above." From the discussion on the list (that I have seen), people seem to be OK with that text. It is quite a bit longer, but so be it. Does anyone have objections to the above text as replacement for the current text? Bert Editor for ID_Checklist ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed update to ID-Checklist
I beleiev that the IESG approved the 1.8 version for which Russ called for review on the IETF list. Anyway, the 1,8 version (with change) is online as http://www.ietf.org/ID-Checklist.html Meanwhile I am working on revision 1.9 and I am making changes as I have been posting to the ietf list over the last 4-5 days. I am still discussion a few other changes (mainly with IESG) before this one will go online. Bert - Original Message - From: "Harald Alvestrand" <[EMAIL PROTECTED]> To: Sent: Wednesday, August 13, 2008 11:55 AM Subject: Re: Call for review of proposed update to ID-Checklist IETF Chair wrote: From the discussion just prior to the recent appeal by John Klensin, it was clear that the guidance regarding example domain names in IETF documents provided in the ID-Checklist needed to be updated. This point was emphasized further during the discussion of the Klensin appeal. Proposed text is now available. Many thanks to Bert Wijnen for continuing to edit the document. The IESG solicits comments on this proposed update. The IESG plans to make a decision on this proposed text on 2008-07-17. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-07-16. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The proposed text can be obtained via http://www.ietf.org/Draft-ID-Checklist.html 6 days later, the URL gives me an "object not found". ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed update to ID-Checklist
W.r.t. - Original Message - From: "Dave Crocker" <[EMAIL PROTECTED]> To: "Bert Wijnen (IETF)" <[EMAIL PROTECTED]> Cc: ; <[EMAIL PROTECTED]> Sent: Monday, August 11, 2008 6:01 PM Subject: Re: Call for review of proposed update to ID-Checklist ... snip a lot .. Specific IPR (e.g., patent claims & terms) must not be in an RFC The "must" is interesting. What BCP documents this (entirely reasonable, IMO) requirement? Does not point 4 4. Specific IPR (e.g., patent claims & terms) must not be in an RFC (or Internet-Draft). Any claims must go to the IETF IPR web page and notice that there is some IPR claim. The mandatory IPR Notice from [RFC3979] (Bradner, S., "Intellectual Property Rights in IETF Technology," March 2005.) section 5 points readers to the IETF IPR web page. clealry point you to the basis (RFC3979) ??? The point was/is that some people put one specific IPR claim in the RFC. And such is useless, after the RFC is Bert, once again, I'm not suggesting the guidance is "wrong", but that it is without substantiation. It asserts a *requirement* that it seems to have invented. RFC 3979 says what is to be in an RFC, not what isn't. The Checklist says what isn't. The proble we saw in the IESG (when we started ID_Checklist) was that we saw A LOT OF I-Ds that requested publication and that DID HAVE SPECIFIC IPR claims. So we wanted to make it clear to people that such is NOT TO BE DONE. Just saying that RFC3979 text was to be used seemed not to get through! And so on. Pls point out all the issues/concerns you have (if you want a personal email I did that: Each and every assertion that says or implies anything more than "it can be helpful to do this" needs to provide a narrow citation for its basis. I means "and so on". If there are more, pls point them out. Bert d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed update to ID-Checklist
inline - Original Message - From: "Dave Crocker" <[EMAIL PROTECTED]> To: "Bert Wijnen (IETF)" <[EMAIL PROTECTED]> Cc: "Brian E Carpenter" <[EMAIL PROTECTED]>; ; <[EMAIL PROTECTED]> Sent: Sunday, August 10, 2008 6:14 PM Subject: Re: Call for review of proposed update to ID-Checklist Bert, Bert Wijnen (IETF) wrote: As you all can see, the ID-Checklist in fact DOES refer to the rfc2223bis at many places. Yes, but... 1. draft-rfc-editor-rfc2223bis is expired. I know. and the RFC-Editor has givem me a pointer to http://www.rfc-editor.org/rfc-style-guide/rfc-style-manual-08.txt which replaces rfc2223bis and this will be in the next revision (1.9) as I had already stated in an earlier posting. 2. While the citations that are included mostly do include the specific section to look in, some do not. (See the first example, below.) Hence, some of the citations are too broad. 3. Much of the document's direction is offered without citation. From the July 4 <http://www.ietf.org/ID-Checklist.html>... 2.2. Required sections - all I-Ds ... List of authors/editors There should not be more than 5 authors/editors (see http://www.rfc-editor.org/policy.html) The Policy document is about 10 pages long. I thought the specific information would be in "Authors vs. Contributors" but it wasn't. One has to search awhile to find Item #1 under an interestingly named section "Author Overload", to find the basis for the "should" in the checklist. And note that the normative "should" language in the Checklist, here, might be considered stronger than what is actually said in the RFC Editor's policy document. (One can debate this, but then, that debate is exactly what we ought to have, based on hard data like this. My own opinion is that the "should" is appropriate here, in terms of actual practice, and it's long been what I advise folk writing drafts.) I can change the pointer to http://www.rfc-editor.org/policy.html#policy.authlist if that helps. Again, a lower case "should" is certainly not nromative in the sense you seem to interpret it. Let me also say that this point became part of the ID_Checklist after the RFC-Editor was exposed to I-Ds that had 15 or so people on the front page and then when the AUTH48 phase was entered it was enourmously time-comsuming and nearly impossible to reach (and get a response) from all the umpteen people on the front-page. 1. Introduction ... As a suggestion for productivity improvement, it is strongly RECOMMENDED to use XML2RFC The capitalization appears intended to offer essentially normative guidance but, of course, that's probably not what is meant. wow... some of you seem to jump to RED-Alert when you see a capitalized term. It is there as strong advise. I personally have no problem changing that to lower case. I am checking with IESG on that. 2.2. Required sections - all I-Ds The following are REQUIRED sections in all Internet-Drafts: What is the basis for asserting that this list is *required* (and, by the way, is "required" meant as a normative term; the caps suggest yes)? Again, please note that I'm not claiming the list is wrong, but that its provenance is absent. So your view that "Our processes are described in formally approved BCP documents" might be at risk. I can live with making it lowercase (I am checking with IESG). The first MUST in point 1 in sect 2.2 is certainly based on a real thing. But even if we make all the capitalized MUST/SHOULD/RECOMMENDED lower case, even then the ID_Checklist is very usefull. 3. Content issues ... B. no citations While I happen to think this is quite good advice, I have no idea a) where it comes from, or b) whether it is guidance or requirement. comes from RFC-Editor. See last para in http://www.rfc-editor.org/policy.html#policy.abstract I can add the pointer if that helps. The one before it, "Should be meaningful to someone not versed in the technology" also lacks basis. Further, as guidance, it's reasonable, but entirely lacking in substance to help an author know how to satisfy it. It came from rfc2223bis or at least how I (and the IESG at the time of first ID_Checklist revision) interpreted: The Abstract section should provide a concise and comprehensive overview of the purpose and contents of the entire document, to give a technically knowledgeable reader a general overview of the function of the document. In addition to its function in the RFC itself, the Abstract section text will appear in publication announcements and in the online index of RFCs. I think the intent is that the reader of an abstract of course should be somewhat technically knowledgebale, but that he/she should not have to be an expert i
Re: Call for review of proposed update to ID-Checklist
I personally very much like this statement from Brian Carpenter: I'd like to say that both as an author and as a reviewer, I have always found both the ID checklist and the IDnits checker to be of immense pragmatic value. Obviously, if the checklist or the checker complains about something that isn't obviously a bug, the author, shepherd, AD or reviewer will have to enter "think" mode or even "negotiate" mode. I agree that it's a good idea to be clear about that. Brian I am checking with the IESG if they also agree with that Bert Editor for the ID_Checklist ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
ID desires and TOOLS stuff [was: Re: Call for review of proposed update to ID-Checklist]
All, PLEASE change the subject line if you change the topic to be discussed. I do NOT think that the below has anything to do with my editing (or the Call for review) of the ID_Checklist. The below list seems like a new set of desires that some people have w.r.t. Internet Drafts (and resulting RFCs). The listed items may all be things for authors/editors to consider. They may also be things that some TOOL could possibly detect and warn about. But they are not (and in my view should not be) topics of the ID_Checklist. So I am not considering the below (and follow up discussions) as part of my current editing cycle of ID-Checklist. Bert Editor for ID_Checklist. - Original Message - From: "Julian Reschke" <[EMAIL PROTECTED]> To: Sent: Sunday, August 10, 2008 6:03 PM Subject: Re: Call for review of proposed update to ID-Checklist Hi, things I'd like to see done in IDs more consistently: In an Editorial Note on the front page: - state on which mailing list discussions should take place (include mailing list archive and subscription links) - point to issues lists when available References: - check that if the document obsoletes or updates another document, that one appear in the references section, and make sure that the document actually says what's going on with respect to the other documents (such as "Normative Changes from RFC ") - use symbolic references - when quoting RFCs, consider calling out a specific section in the referenced document (it's preferable that the author does it once, instead of the readers having to figure it out; also, it helps revising the document when the referenced document was revised) Code: - when using xml2rfc, add type parameters to artwork so that things like ABNF can be automatically extracted and checked Versioning: - (this probably is controversial :-) - keep an appendix that gives a short overview of what changed compared to previous drafts BR, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Do you all have a lif? [was: Re: Call for review of proposed update to ID-Checklist (resend)]
Sorry for the off-topic discussion, but Martin started it. (I dropped the IESG, they probably see ietf list as well.) Of course I do have a life. ANd a good one too! Some people work early on workday mornings, others work late at night, yet others work on a saturday when iot is raining but take off when the sun shines during the week. That is the benefit of Internet collaboration. People can work when it fits their own schedule. And it allows us to better weave our work/personal life in way that suits us. Enjoy the Sunday. It is still raining here, but now I am going to a birthday party. That also means I may sleep late tomorrow morning ;-) Bert - Original Message - From: "DOLLY, MARTIN C, ATTLABS" <[EMAIL PROTECTED]> To: "Bert Wijnen (IETF)" <[EMAIL PROTECTED]>; "Pete Resnick" <[EMAIL PROTECTED]>; "IETF Discussion" ; "IESG" <[EMAIL PROTECTED]> Sent: Sunday, August 10, 2008 4:28 AM Subject: RE: Call for review of proposed update to ID-Checklist (resend) Do you all have a life. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Fw: Call for review of proposed update to ID-Checklist (resend)
Oops, used wrong from address - Original Message - From: "Bert Wijnen" [EMAIL PROTECTED] To: "Pete Resnick" <[EMAIL PROTECTED]>; Cc: <[EMAIL PROTECTED]> Sent: Saturday, August 09, 2008 9:25 PM Subject: Re: Call for review of proposed update to ID-Checklist Pete, I am not sure how this helps. I thought that ID authors/editors DO know what MUST/SHOULD means. If not, then as far as I am concerned, we can change the capitalized words into lower case. The front of the document shows (into with notes) clearly waht the intent is. And is states that ADs will not accept a request for publication and will not put it on the IESG agenda. Is that not clear enough? See also my response to Klensin and Crocker about the intent of the document. That said, if Russ agrees, I can certainly add more boilerplate text as you suggest below. I doubt it will make the document any more useful. Bert Editor of ID_Checklist - Original Message - From: "Pete Resnick" <[EMAIL PROTECTED]> To: Cc: "IETF Chair" <[EMAIL PROTECTED]>; ; "IETF Announcement list" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Tuesday, July 08, 2008 9:17 PM Subject: Re: Call for review of proposed update to ID-Checklist Re: Call for review of proposed update to ID-ChecklistOn 7/8/08 at 11:44 AM -0700, IETF Chair wrote: The IESG solicits comments on this proposed update. The IESG plans to make a decision on this proposed text on 2008-07-17. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-07-16. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Insert in the Introduction, before or at the beginning of "Notes:" - This memo uses the terms "MUST", "REQUIRED", "SHOULD", and "RECOMMENDED", similarly to the use of these terms in RFC 2119. In particular, when they appear in ALL CAPS in this memo: -"MUST" or "REQUIRED" means that if you do not do this in your I-D, the IESG will not accept the I-D for any review until the item is complete. - "SHOULD" or "RECOMMENDED" means that there may be valid reasons to ignore the item, but an explanation must be given, either in the text of the document or as part of the submission to the IESG, as to why the item is being ignored. Otherwise, the IESG may not accept the I-D for review. - This text both (a) puts draft authors on notice as to what the hard requirements are in order to avoid late surprises, and (b) puts reviewers of this memo on notice so that consensus can be reached on what are or are not real showstoppers for IESG review. pr -- Pete Resnick <http://www.qualcomm.com/~presnick/> Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Fw: Call for review of proposed update to ID-Checklist (resend)
Oops, used wrong from address - Original Message - From: "Bert Wijnen" <[EMAIL PROTECTED]> To: "Pete Resnick" <[EMAIL PROTECTED]>; Cc: <[EMAIL PROTECTED]> Sent: Saturday, August 09, 2008 9:29 PM Subject: Re: Call for review of proposed update to ID-Checklist Pete Again, this was included in the ID-Checklist, because many many documents did use ABNF without a citation/reference. As stated before: the ID-Checklist does not (intend) to introduce any new requirements that were/are not documented elsewhere in our approved procedures/documents. So in that light, the ID-Checklist might as well be abolished. Practice/experience has however shown that many authors/editors of I-Ds do not follow our procedures very well (not a big surprise, it is not easy to find them all) and so the ID-Checklist tries to help them have the pointers in one place. Bert Editor of the ID-Checklist - Original Message - From: "Pete Resnick" <[EMAIL PROTECTED]> To: Cc: "IETF Chair" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Tuesday, July 08, 2008 9:27 PM Subject: Re: Call for review of proposed update to ID-Checklist Re: Call for review of proposed update to ID-ChecklistThe document says: "If ABNF is used, you MUST include a normative reference to RFC 4234." To quote two fine radio personalities here in the states, this one seems "boogus". Yes, any I-D that uses ABNF must include a normative reference to RFC 4234, but for the IESG to not engage in review until it is in there is silly beyond belief. Make a note to the author that they need the reference and continue consideration. pr -- Pete Resnick <http://www.qualcomm.com/~presnick/> Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed update to ID-Checklist
As you all can see, the ID-Checklist in fact DOES refer to the rfc2223bis at many places. It has now been updated (in my copy) to point to the RFC-Editor-Style Manual. Specifically section 2 discusses this, and sect 2.1 starts out by stating: In principle, the RFC-Editor can take care of a few small formatting errors. And if there are only a few, then they will do so. However, if many errors exist, the document will be returned to the author(s)/editor(s)/WG for fixes. In any event, please realize that not following the formatting rules will most probably delay publication and does consume time that can be spend on other work. It could be made clearer that the ID-Checklist is specifically intended for final I-Ds that are submitted to an AD, i.e. a request for publication to the AD/IESG. The first Note in the Introduction section does say so. But to be more clear, I have changed the fuirst sentence of sect 1. from All Internet Drafts which are offered for publication as RFCs into All Internet Drafts which are offered to an AD or the IESG with a request for publication as RFC I hope that clarifies. Bert Editor for ID_checklist - Original Message - From: "Brian E Carpenter" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: ; <[EMAIL PROTECTED]> Sent: Wednesday, July 09, 2008 2:13 AM Subject: Re: Call for review of proposed update to ID-Checklist Re: Call for review of proposed update to ID-ChecklistOn 2008-07-09 07:08, Dave Crocker wrote: ... Small point of confusion: I thought the RFC document series was managed with some independence of the IETF. As such, I'm not clear how the IETF (nevermind the IESG) can set the rules for RFC format and style. I view the id-checklist as a gating factor for IESG review, not as instructions to the RFC Editor. Of course it should be consistent with the RFC Editor's practice, as a matter of common sense. The introduction should make this clear, perhaps. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed update to ID-Checklist
Ted, a glib response would be: We can ask the RC-Editor to fix everything that is broken But do we (IETF/ISOC) really want to spend a lot of real money on payed RFC-Editor to fix up things that authors/editors can easily do, specifically with a ID-Checklist in hand that points out the many simple "things-to-fix" that we often found in many submitted I-Ds? My take is that we should put that responsibility with the authors/editors and the WG chairs. That is what the document does, and that is also what a WG chair is asked to check when they fill out the questionaire in RFC4848 in section 3.1, The shepherd (often WG chair) is asked to confirm that he did check the document to meet the ID-Checklist (see question 1.g on page 6). And that SAVES a lot of time on already overloaded ADs/IESG and also SAVES real dollars in the RFC-Editor cycle. Bert Editor for ID_Checklist - Original Message - From: "Theodore Tso" <[EMAIL PROTECTED]> To: "Pete Resnick" <[EMAIL PROTECTED]> Cc: "IETF Chair" <[EMAIL PROTECTED]>; ; <[EMAIL PROTECTED]> Sent: Tuesday, July 08, 2008 11:35 PM Subject: Re: Call for review of proposed update to ID-Checklist Re: Call for review of proposed update to ID-ChecklistOn Tue, Jul 08, 2008 at 02:27:41PM -0500, Pete Resnick wrote: The document says: "If ABNF is used, you MUST include a normative reference to RFC 4234." To quote two fine radio personalities here in the states, this one seems "boogus". Yes, any I-D that uses ABNF must include a normative reference to RFC 4234, but for the IESG to not engage in review until it is in there is silly beyond belief. Make a note to the author that they need the reference and continue consideration. Stupid question isn't this specific thing something we should allow the secretariat to fix as part of the RFC publishing process, and in fact give them instructions to add the reference if they find it missing? They do things like fix/update references IIRC, and this is only a minor step beyond that, and should be well within their capabilities, I would think. Sure, we can ask document editors to add the reference to RFC 4234, and maybe we can even do things like include a reference to RFC 4234 in an RFC template file with a note to remove if the standard ends up not using ABNF, but there must be a class of things which could be streamlined to save time on both the document editors, reviewers, and AD's time. Regards, - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed update to ID-Checklist
John and Dave, I think that both of you (and some others) arwe looking at the ID_Checklist too much as if it is part of our (rigid) process. Our processes aredescribed in formally approved BCP documents. The ID-Checklist is intended (or at least that is how it started, and as far as I am concerned that is still the intention) to help in a few areas: - Make document authors/editors and WG chairs (and reviewers) aware of the many little things we found as ADs and IESG when reviewing documents that came out of WGs. Those mistakes always later caused confusion and delay in the further process. - Reduce the document-time of AD, IESG, IETF LC-reviewers, RFC-Editor by reducing extra steps to fix little and simple things. - All those simple things were (and still are) documented in other RFCs or in the RFC-Editor Style manual, and so it is/was not a new set of rules or requirements - Authors/Editors SHOULD know all these little things, but they often did/do not know exactly what they are or where to find them. The ID_Checklist is intended to help find these things. - By documenting these things, it became easier/quicker to point to them (both if found at AD or IESG review and earlier) - By documenting them, the WG-Chair (document shepherd) can do a lot of these checks, so that they can not slip through later in the process or delay the process afetr IESG approves. - I believe that the ID-Checklist also helped Henrik write the id-nits tool that will do a check for most of the checlist items that can (reasonably) be checked by software I remember that before we had the ID-Checklist, we often wasted a lot of time on this simple things (be it by taking a DISCUSS, by interacting with the authors, by adding RFC-Editor notes, By later checking if things were fixed, By later discussing aith editors/authos why such little fixes were made etc etc ect). So I believe it has served its purpose very well. And I also believe that the intended purpose is still served very well with the current version, albeit that some clarifications an dupdates to ptrs and citations/references are in order. Pls do not consider this ID-Checklist as part of our BCP approved process documents. That is not the intention of it and I think it would be bad to try and make it part of our set of BCPs that describe our (IETF) process. So I am not prepared yet to take on a massige reorg and as a result probably a long discussion and wordtsmitting effort. If Russ (or the IESG) tells me that they DO want a complete re-org I will re-consider. But that was/is not the task I was asked to do (I believe). I hope you understand Bert Editor of the ID_Checklist. - Original Message - From: "John C Klensin" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; "Bert Wijnen (IETF)" <[EMAIL PROTECTED]> Cc: "IETF Discussion" Sent: Saturday, August 09, 2008 8:30 PM Subject: Re: Call for review of proposed update to ID-Checklist Bert, I want to reinforce Dave's comments and perhaps carry them a bit further. If the ID-checklist were just the general guidance that I believe it started out to be, the distinctions I suggest below would probably be unnecessary. But we've seen recently that there are very few steps between having a list and having everything on that list become rigid, mechanically-applied, requirements. --On Saturday, 09 August, 2008 09:20 -0700 Dave Crocker <[EMAIL PROTECTED]> wrote: Bert, et al, Something that might help further discussions quite a bit is considering annotation and re-organization of the document, to clarify some basic distinctions. For example, labeling the bits that are based on IETF standards rules versus the bits that are based on IESG requirements? Equally, what pertains to documentation standards versus what pertains to technical/protocol issues? Many of the bits that "pertain to documentation requirements" are IESG interpretations of RFC Editor guidelines. The RFC Editor has traditionally been much more flexible about their rules than recent trends in the IESG have been. Even when the rules come from the IESG, it would be useful to better distinguish between firm requirements (e.g., the IPR boilerplate) and guidance (e.g., things to which one should either conform or expect to have to explain, convincingly, why not). The document has evolved into a possibly disorganized mixture of these and last month's discussions was challenged to separate issues, I think. This kind of change would not be modification of the Checklist semantics, but would add clarity to what is currently there. But it is precisely the semantics that I think are at issue. This is less what is in the checklist because I believe we could agree that everything there is at least good general guidance than about the apparent tendency for entries in the checklist to become rigid rules that will be enforced even if specific circumstances
Re: Call for review of proposed update to ID-Checklist
This suggests to allow more gTLDs for use as examples. It seems to me that that would mean an update to RFC2606, an I consider that out of scope for the ID-Checklist document. So I will ignore all discussion on this for the current updates. If an updated 2606 ever occurs, I will accept to update ID-Checklist accordingly. Bert Editor of ID-Checklist - Original Message - From: "Bill McQuillan" <[EMAIL PROTECTED]> To: "IETF Discussion" Sent: Wednesday, July 09, 2008 6:37 PM Subject: Re: Call for review of proposed update to ID-Checklist Re: Call for review of proposed update to ID-Checklist On Wed, 2008-07-09, Spencer Dawkins wrote: If an example describes a complex network topology, it could be appropriate to use a variety of names, IP addresses or prefixes that are easily disambiguated, so that the reader might follow the example more easily. I wonder if it would make it easier to use "example" DNS names if, in addition to the verbose and clumsy: "*.example", IMHO, we reserved gTLDs like "*.foo", "*.bar", "*.bat", "*.baz", as well as the one used quite frequently on this list lately: "*.tld", for use as example DNS names. Or do we assume that economic concerns would triumph here? -- Bill McQuillan <[EMAIL PROTECTED]> ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed update to ID-Checklist
I have started to updatre the document based on feedback. My approach is to clearly make those changes that are straight forward, simple end editorial. For other changes, I need to hear (I guess from Russ) that there is consensus to make such a change. It may take a little more time before I have checked and evaluated all comments. Inline - Original Message - From: "Frank Ellermann" <[EMAIL PROTECTED]> To: Sent: Wednesday, July 09, 2008 8:51 AM Subject: Re: Call for review of proposed update to ID-Checklist Re: Call for review of proposed update to ID-ChecklistIETF Chair wrote: http://www.ietf.org/Draft-ID-Checklist.html Nits: (1) Archive older versions in a plain text format as for I-Ds (for use with various IETF tools working on I-Ds) I can generate I-Ds if that helps. I can even submit those. Russ, do you want me to do that? (2) s/2434/5226/ (3) s/2780/2780 + 5237/ above 2 are done in my new copy (4) I-D.bellovin expired months ago with three DISCUSSes, please resolve that by time-out ABSTAINs (or similar) There is a new rev dated Aug 03 2008. That will now get picked up by the xml2rfc tool. I will not comment on the time-out on ABSTAINs, that is an IESG issue, not one that relates to teh ID-Checklist document. (5) s/4181/4181 + 4841/ (6) s/4234/5234/ The above 2 have been updated in new copy (7) Please add RFC 5137 (BCP 137) to section 4 as item 5 I do not feel confident to add that unless Russ tells me that this is consensus and should be added. (8) I-D.2223bis expired 3.5 years ago, and is flagged as DEAD since May 2008 I know. I have communicated with Russ and RFC-Editor about this. We will replace it with a reference to http://www.rfc-editor.org/rfc-style-guide/rfc-style-manual-08.txt Bert Editor of ID-Checklist Frank ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Call for review of proposed update to ID-Checklist
John Klensin writes: > IMO, the IESG should be spending energy evaluating only those > conditions that require judgment as to appropriateness, i.e., > the SHOULDs. > The ID-Checklist was (and I believe still IS) intended to do just that. When a document shepherd does answer the questions of RFC4848 in section 3.1, then the shepherd (often WG chair) is asked to confirm that he did check of the document to meet the ID-Checklist (see question 1.g on page 6). So it happens BEFORE one or many ADs go spend a lot of time on the document. And it was specifically intended to NOT cause surprised and to prepare the document in a good shape before being submitted for review by many people outside the WG. Bert > john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Call for review of proposed update to ID-Checklist
Mmm... as editor of the document, maybe I should explain how this document came into existence several years ago. It was back then that the IESG got many many documents that had a lot of these simple (and easy to fix) issues. Some look like showstoppers, others are not so much showstoppers, but they do take extra time (of many people) if they need to be fixed once the document goes into IETF Last Call. So in order to try and make doument authors/editors and also WG chairs aware of what the many little errors were that we as IESG often saw, we composed this document. Hope this helps, Bert Wijnen > -Oorspronkelijk bericht- > Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Pete > Resnick > Verzonden: dinsdag 8 juli 2008 21:28 > Aan: ietf@ietf.org > CC: IETF Chair; [EMAIL PROTECTED] > Onderwerp: Re: Call for review of proposed update to ID-Checklist > > > The document says: > > "If ABNF is used, you MUST include a normative reference to RFC 4234." > > To quote two fine radio personalities here in the states, this one > seems "boogus". Yes, any I-D that uses ABNF must include a > normative reference to RFC 4234, but for the IESG to not engage in > review until it is in there is silly beyond belief. Make a note to > the author that they need the reference and continue consideration. > > pr > -- > Pete Resnick <http://www.qualcomm.com/~presnick/> > Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: OPS-DIR review for: draft-ietf-mpls-ldp-interarea-03.txt
Thanks. Looks good to me. Bert Wijnen > -Oorspronkelijk bericht- > Van: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Verzonden: maandag 28 april 2008 14:07 > Aan: [EMAIL PROTECTED] > CC: ietf@ietf.org; [EMAIL PROTECTED]; [EMAIL PROTECTED] > Onderwerp: RE: OPS-DIR review for: draft-ietf-mpls-ldp-interarea-03.txt > > > Inline, > > Bruno > > > De : Bert Wijnen - IETF [mailto:[EMAIL PROTECTED] > > > > Inline > > > > Bert Wijnen > > > > > Van: [EMAIL PROTECTED] > > > > > > > > > Bert, > > > > > > Many thanks for your comments. > > > More inlined. > > > > > > Bruno > > > > > > > De : Bert Wijnen - IETF [mailto:[EMAIL PROTECTED] > > > > > > > > Forwarding to IETF wide list and authors/editors > > > > > > > > Bert Wijnen > > > > > > > > Van: Bert Wijnen - IETF [mailto:[EMAIL PROTECTED] > > > > > > > > > > > > I reveied this document for the OPS Directorate > > > > > > > > In general, I think the document is ready for publication. > > > > > > > > In sect 7.1 I read: > > > > > > > >For the successful establishment of end-to-end MPLS LSPs > whose FEC > > > >are aggregated in the RIB, this specification must be > implemented on > > > >all LSRs in all areas where IP aggregation is used. If > an LSR on the > > > >path does not support this procedure, then the LSP > initiated on the > > > >egress LSR stops at this non compliant LSR. There are no other > > > >adverse effects. > > > > > > > > I think/hope (but it would be good to see this confirmed) > that this does > > > > not mean that all LSRs in the set of IGPs that are involved > need to be > > > > upgraded with the new protocol at exactly the same time. > > > > > > > > The way I understand it, one can upgrade the LSRs at > different times, > > > > but should only activate this new mechnaism once all LSRs have > > > > ineeded been upgraded with the new capability. > > > > > > You're right: all LSRs do not need to be upgraded at the same time: > > > - deployment in each IGP (area) is independent > > > - LSRs can be upgraded at any time in any order, > > > - This new mechanism can be activated on the LSR at any time in > > > any order, (upgrade and activation can be done at same step if > > > it's considered easier) > > > - Then, if the FEC/LSP were used, we need a non disruptive deployment: > > > (As a reminder, the ABRs used to leak all specific prefixes > > > in the IGP area.) > > > The ABRs can advertise the (new) aggregate prefix at any > > > time and any order. > > > However, the specific prefixes in the IGP area should only > > > be withdrawn (by the ABRs) once all the LSR of this IGP area have > > > been upgraded. (Otherwise "If an LSR on the path does not support > > > this procedure, then the LSP initiated on the egress LSR stops at > > > this non compliant LSR.") > > > > > > Do you think this should be clarified in the document? > > > > > > > Up to you. > > Apparently I understood it correctly. > > The fact that is it not needed to upgrade all at the same time > > is the important point for me. If I had understood it incorrectly, > > I would have had a bigger concern. > > So would I. > > > Making it clearer is always good I think. Up to you. > > I've updated the section 7.1 "Deployment considerations" with the > following: > > "This extension can be deployed incrementally: > - It can be deployed on a per area or routing domain basis > and does not necessarily require an AS wide deployment. For > example, if all specific IP prefixes are leaked in the IGP > backbone area and only stub areas use IP aggregation, LSRs in the > backbone area don't need to be compliant with this document. > - Within each routing area, LSRs can be upgraded > independently, at any time, in any order and without service > disruption. During deployment, if those LSPs are used, one should > only make sure that ABRs keep advertising the specific IP > prefixes in the IGP until all LSR of this area are successfully > upgraded. Then, the ABRs can only advertise the aggregated prefix > and stop advertising the specific ones." > > Please feel free to amend/correct/comment if needed. > > > Bert > > > > > > > Nits: > > > > > > Thanks. > > > All corrections are done and will appear in the next revision. > > > > > Thanks, > > > > Bert > > ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: OPS-DIR review for: draft-ietf-mpls-ldp-interarea-03.txt
Inline Bert Wijnen > -Oorspronkelijk bericht- > Van: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Verzonden: maandag 28 april 2008 12:18 > Aan: [EMAIL PROTECTED] > CC: ietf@ietf.org; [EMAIL PROTECTED]; [EMAIL PROTECTED] > Onderwerp: RE: OPS-DIR review for: draft-ietf-mpls-ldp-interarea-03.txt > > > Bert, > > Many thanks for your comments. > More inlined. > > Bruno > > > -Message d'origine- > > De : Bert Wijnen - IETF [mailto:[EMAIL PROTECTED] > > Envoyé : dimanche 27 avril 2008 11:43 > > À : ietf@ietf.org; [EMAIL PROTECTED]; LE ROUX Jean-Louis > RD-SIRP-LAN; DECRAENE Bruno RD-CORE-ISS > > Objet : FW: OPS-DIR review for: draft-ietf-mpls-ldp-interarea-03.txt > > > > Forwarding to IETF wide list and authors/editors > > > > Bert Wijnen > > > > -Oorspronkelijk bericht- > > Van: Bert Wijnen - IETF [mailto:[EMAIL PROTECTED] > > Verzonden: donderdag 24 april 2008 13:55 > > Aan: [EMAIL PROTECTED] > > Onderwerp: OPS-DIR review for: draft-ietf-mpls-ldp-interarea-03.txt > > > > > > I reveied this document for the OPS Directorate > > > > In general, I think the document is ready for publication. > > > > In sect 7.1 I read: > > > >For the successful establishment of end-to-end MPLS LSPs whose FEC > >are aggregated in the RIB, this specification must be implemented on > >all LSRs in all areas where IP aggregation is used. If an LSR on the > >path does not support this procedure, then the LSP initiated on the > >egress LSR stops at this non compliant LSR. There are no other > >adverse effects. > > > > I think/hope (but it would be good to see this confirmed) that this does > > not mean that all LSRs in the set of IGPs that are involved need to be > > upgraded with the new protocol at exactly the same time. > > > > The way I understand it, one can upgrade the LSRs at different times, > > but should only activate this new mechnaism once all LSRs have > > ineeded been upgraded with the new capability. > > You're right: all LSRs do not need to be upgraded at the same time: > - deployment in each IGP (area) is independent > - LSRs can be upgraded at any time in any order, > - This new mechanism can be activated on the LSR at any time in > any order, (upgrade and activation can be done at same step if > it's considered easier) > - Then, if the FEC/LSP were used, we need a non disruptive deployment: > (As a reminder, the ABRs used to leak all specific prefixes > in the IGP area.) > The ABRs can advertise the (new) aggregate prefix at any > time and any order. > However, the specific prefixes in the IGP area should only > be withdrawn (by the ABRs) once all the LSR of this IGP area have > been upgraded. (Otherwise "If an LSR on the path does not support > this procedure, then the LSP initiated on the egress LSR stops at > this non compliant LSR.") > > Do you think this should be clarified in the document? > Up to you. Apparently I understood it correctly. The fact that is it not needed to upgrade all at the same time is the important point for me. If I had understood it incorrectly, I would have had a bigger concern. Making it clearer is always good I think. Up to you. Bert > > > Nits: > > Thanks. > All corrections are done and will appear in the next revision. > Thanks, Bert ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
FW: OPS-DIR review for: draft-ietf-mpls-ldp-interarea-03.txt
Forwarding to IETF wide list and authors/editors Bert Wijnen -Oorspronkelijk bericht- Van: Bert Wijnen - IETF [mailto:[EMAIL PROTECTED] Verzonden: donderdag 24 april 2008 13:55 Aan: [EMAIL PROTECTED] Onderwerp: OPS-DIR review for: draft-ietf-mpls-ldp-interarea-03.txt I reveied this document for the OPS Directorate In general, I think the document is ready for publication. In sect 7.1 I read: For the successful establishment of end-to-end MPLS LSPs whose FEC are aggregated in the RIB, this specification must be implemented on all LSRs in all areas where IP aggregation is used. If an LSR on the path does not support this procedure, then the LSP initiated on the egress LSR stops at this non compliant LSR. There are no other adverse effects. I think/hope (but it would be good to see this confirmed) that this does not mean that all LSRs in the set of IGPs that are involved need to be upgraded with the new protocol at exactly the same time. The way I understand it, one can upgrade the LSRs at different times, but should only activate this new mechnaism once all LSRs have ineeded been upgraded with the new capability. Nits: - There are several/many acronyms in this document that never get expanded. It is good pratice to always expand an acronym when it is used for the first time. - Abstract To facilitate the establishment of Label Switched Paths (LSP) that would span multiple IGP areas in a given Autonomous System (AS), this document proposes a new optional label mapping procedure for the Label Distribution Protocol (LDP). s/proposes/describes/ (at least once this comes out as RFC, right?) - need to add citation to RFC2119 in section 1. And add a normative reference for RFC2119. - 2nd para section 4: To set up the required MPLS LSPs between PEs in different IGP areas, services providers have currently three solutions: LDP with IGP route s/services/service/ I think. - consistency: I see Service providers service providers Service Providers I suggest to use consistent capitalization - 1st para sect 5: This document defines a new label mapping procedure for [LDP]. It is applicable to IPv4 and IPv6 prefix FEC elements (addresses families 1 and 2 as per [ASSIGNED_AF]). It MUST be possible to activate / ^M I believe it is "address families" (or maybe "addressing families") but not "addresses families". So I would: s/addresses/address/ - sect 5, I see longest match label mapping procedure longest match Label Mapping Procedure "Longest Match" label mapping procedure longest match procedure you might want to be a bit moire consistent - Section 5: - next-hop change when an existing prefix have new next hop following a routing change. s/have new/has a new/ ?? - When the next-hop of a RIB prefix change, the LSR must change change the first "change": s/change/changes/ or so I think. - 2nd para section 7.2 In case of failure of the egress LER node, given that the IGP aggregates IP route on ABRs, the routing convergence behavior is changed compared to [LDP]. As the IGP does not carry specifics prefixes outside of the egress area, the IGP will not propagate the s/specifics prefices/specific prefixes/ (or so I think) - Last para sect 7.2 For all others failures s/others/other/ Bert Wijnen -Oorspronkelijk bericht- Van: Seely, Ted A [CTO] [mailto:[EMAIL PROTECTED] Verzonden: donderdag 17 april 2008 13:42 Aan: Bert Wijnen Onderwerp: OPS DIR Review Request Hello Bert, As a member of the Operations Directorate you are being asked to review the following IESG work item for it¹s operational impact. IETF Last Call: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-interarea-03.txt BTW - This is a very short draft. If possible please provide comments and review to the Ops-dir mailing list ([EMAIL PROTECTED]), preferably before next Wednesday if possible. Thank you Bert, Ted ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: WG Review: NETCONF Data Modeling Language (netmod)
+1 Bert Wijnen -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Mehmet Ersue Verzonden: woensdag 23 april 2008 17:30 Aan: Andy Bierman; [EMAIL PROTECTED]; ietf@ietf.org Onderwerp: RE: WG Review: NETCONF Data Modeling Language (netmod) Another +1. I don't know what to add. It is not very common that a large group of 15 persons (covering authors from all solution proposals so far) volunteer and ask for being involved in the draft charter preparation. After having hundreds of mails in the RCDML maillist and having reached a consensus for the draft charter text we came out to the NGO maillist. There were no opponents on the NGO maillist. This is also the reason why the discussion has been brought to the IETF discussion list. As I can see we did not skip any important step of the process. In all the steps there was sufficient place for discussion. And we got one step further because there was always consensus and support in the step before. As a summary: I fully support the charter proposal and the creation of the NETMOD WG. Cheers, Mehmet > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of ext Andy Bierman > Sent: Wednesday, April 23, 2008 4:45 PM > To: Harald Alvestrand > Cc: ietf@ietf.org > Subject: Re: WG Review: NETCONF Data Modeling Language (netmod) > > Harald Alvestrand wrote: > > Eric Rescorla wrote: > >> At Tue, 22 Apr 2008 19:17:47 -0600, > >> Randy Presuhn wrote: > >> > >>> Our ADs worked very hard to prevent us from talking about > technology > >>> choices at the CANMOD BOF. Our original proposal for consensus > >>> hums included getting a of sense of preferences among the various > >>> proposals. We were told we could *not* ask these > questions, for fear > >>> of upsetting Eric Rescorla. > >>> > >> Well, it's certainly true that the terms--agreed to by the IESG and > >> the IAB--on which the BOF were held were that there not be a beauty > >> contest at the BOF but that there first be a showing that there was > >> consensus to do work in this area at all. I'm certainly > willing to cop > >> to being one of the people who argued for that, but I was far > >> from the only one. If you want to blame me for that, go ahead. > >> > >> In any case, now that consensus to do *something* has been > >> established it is the appropriate time to have discussion on > >> the technology. I certainly never imagined that just because > >> there weren't hums taken in PHL that that meant no hums would > >> ever be taken. > > It's been a month since PHL. > > > > The IETF's supposed to be able to work on mailing lists between > > meetings, including being able to work when no WG exists - which of > > course means working on mailing lists that are not WG lists. > > > > Agreed -- this also means that the 'technical approach' straw poll > that did not occur in the CANMOD BoF is not really that important, > since final consensus needs to be confirmed on a designated > mailing list. > > > I congratulate the participants who worked on the charter > on managing to > > have the discussion and come to consensus on an approach. I > think it's > > up to Eric to demonstrate to the IESG that there's support in the > > community for disagreeing with the consensus of the > discussing participants. > > +1 > > 15 person (large!) design team. 1000s of emails. Done in a month. > This is more effort than most WGs can muster. > > > > > Harald > > Andy > > ___ > IETF mailing list > IETF@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > -- Gesendet von Yahoo! Mail. Mehr Möglichkeiten, in Kontakt zu bleiben.___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: WG Review: NETCONF Data Modeling Language (netmod)
Well said Andy. And I support the charter as well! Bert Wijnen > -Oorspronkelijk bericht- > Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Andy > Bierman > Verzonden: dinsdag 22 april 2008 23:14 > Aan: Randy Presuhn > CC: ietf@ietf.org > Onderwerp: Re: WG Review: NETCONF Data Modeling Language (netmod) > > > Randy Presuhn wrote: > > Hi - > > > >> From: "Eric Rescorla" <[EMAIL PROTECTED]> > >> To: ; <[EMAIL PROTECTED]> > >> Sent: Tuesday, April 22, 2008 10:10 AM > >> Subject: Re: WG Review: NETCONF Data Modeling Language (netmod) > > ... > >> Accordingly, if this WG is to be formed, the entire section (and > >> corresponding milestones) which specifies the technology needs to be > >> removed. Rather, the first work item should be to select a technical > >> approach. > > ... > > > > I think the simplest answer would be to simply publish the work > that's already > > been done and not bother with the IETF. There is simply no > value in wasting > > electrons on battles like this. Sure, some opportunities for > technological > > refinement and building a stronger community consensus migh tbe > lost, but > > that might be a small price to pay in comparison to the time and energy > > required for all this pointless hoop-jumping. Particularly > since the proposed/ > > draft/standard distinction has become so meaningless, it makes more > > sense to just publish the spec and ignore the peanut gallery. > > > > This 'simple' approach doesn't move standardized network configuration > along at all, so it is not my first choice. > > IMO, there is strong community consensus for the charter as it > is currently written. There are several technical approaches, > such as 'continue to write data models in XSD' which are > technically viable, but have no community consensus at all. > > I don't think a formal WG process is needed to determine that > the strongest consensus exists for the approach currently outlined > in the charter. The 15 people on the design team represented > a wide cross section of those actually interested in this work. > I am among the 10 - 15 people who were not involved in the design team, > but agree with the charter. That seems like a lot of consensus > for this technical approach. > > > > > Randy > > Andy > > ___ > IETF mailing list > IETF@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: WG Review: NETCONF Data Modeling Language (netmod)
Eric, instead of discussing if there was consensus AT THE BOF (we all know that at this point in time we DO have consensus between all the interested WORKERS in this space, albeit that the current consensus was arrived at in further (smaller) meetings, in extensive DT work after the IETF and again after review on NGO list). I propose that you list (again) your (technical) objections to the the current proposal. If all you can tell us is that we need to spend just more cycles on re-hashing the pros and cons of many possible approaches, then I do not see the usefulness of that discussion and with become silent and leave your opion as one input to the IESG for their decision making process. Bert Wijnen > -Oorspronkelijk bericht- > Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Eric > Rescorla > Verzonden: dinsdag 22 april 2008 23:14 > Aan: David Partain > CC: [EMAIL PROTECTED]; ietf@ietf.org > Onderwerp: Re: WG Review: NETCONF Data Modeling Language (netmod) > > > At Tue, 22 Apr 2008 23:00:53 +0200, > David Partain wrote: > > > > Greetings, > > > > On Tuesday 22 April 2008 18.10.10 Eric Rescorla wrote: > > > I object to the formation of this WG with this charter. > > > > For those who haven't been involved in the discussions to date, > Eric has > > objected to this work from the very beginning, as far back as > the first > > attempt to get a BOF and has continued to object since that > time. As such, > > I'm not surprised that he objects now. > > Of course, since the issues I was concerned about from the very > beginning remain. > > > > > While there was a clear sense during the BOF that there was interest > > > in forming a WG, there was absolutely no consensus on technical > > > direction. > > > > Not surprisingly, I disagree. > > Well, it's not really like this is a matter of opinion, since > the minutes are pretty clear that no consensus calls on the > choice of technology were taken, only that some work > in this area should move forward: > > http://www.ietf.org/proceedings/08mar/minutes/canmod.txt > > > > The O&M community in the IETF has been talking about this > specific topic for a > > long time, both in official and unofficial settings. We've had > many hours of > > meetings where people from all various viewpoints have had > hashed out their > > differences. This all culminated during the last IETF in a > rather strong > > sense of consensus amongst those most interested in this work > that it's time > > to stop talking and move forward, and that YANG was the best > way to do that. > > No, not everyone agreed, but we DO have rough consensus in the > O&M community > > and with the APPS area people who were involved that this was a > reasonable > > approach forward. > > > > So, what about this consensus thing? > > > > Sometimes ADs have to make a call, and my take is that Dan & > Ron did so. They > > asked people representing ALL of the proposals to work on a > proposal for a > > charter. We spent a great many cycles doing exactly that. All of the > > proposals that you saw presented at the CANMOD BOF were very > active in the > > charter proposal discussions and the result is the consensus of > all of those > > people. No one got exactly what they wanted, but I think > everyone felt is > > was a reasonable way forward. So, we have consensus amongst > the various > > proposals' authors. > > The sum of all this verbiage is that, precisely as I said, there > wasn't consensus at the BOF, but that there was some set of rump > meetings where this compromise was hashed out. > > -Ekr > > > ___ > IETF mailing list > IETF@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: WG Review: NETCONF Data Modeling Language (netmod)
W.r.t. > All this is great stuff, but it all happened after the BOF, so > you can't reasonably claim that it represents BOF consensus. > And since BOFs are our primary mechanism for open, cross area > assessment for WG formation, I don't think it's accurate to suggest > that this is anywhere as near as open as actually having the > discussion in the BOF and gettting consensus, nor is it a substitute > for that. > I do not think that forming a WG MANDATES a BOF. Several WGs have been formed (in the past) without a BOF. So pls do not depict a story as if a BOF is the only way how we reach consensus in IETF on teh question of forming a WG or not. Bert ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: WG Review: NETCONF Data Modeling Language (netmod)
Eric REALLY... I heard during that BOF that there was consensus to start the work. I also saw that quite a few liked the YANG proposal, and several wanted to have mappings to either XSD or RELAX or DSDL. The smaller meetings that happened after the NOF, included people from all of the proposals that were on the table, including people who were in teh Design Team for the requirements. We had fruitfull discussions that converged onto a single approach. We then got all the people from the various proposls together on the rdcml mailing list (the one that was used by the requirements design team), and we had a 2 week long discussion with multiple hundereds of emails and opinions, and again, we converged to a common and acceptable draft WG charter. That draft WG charter was then put to the NGO mailing list were we had further discussion with various other people. Again we seem to have consensus. Several non-original-netconf people are on that mailing list, as a result of the BOF discussions we have had in the past thow IETF meetings. Then, Dan brought it to IESG, and the IESG agreed to send the WG proposal out for IETF Wide review. That is where we are now, and sure you can vent your opinion, but claiming (or accusing us) that there was no wide discussion or that there is no consensus at all and that there were/are just 4 different groups with conflicting proposals does not seem valid to me. Further, the change you propose to the WG charter, could be done,. and then in the first WG session we could declare victory for the milestone you want. I believe that virtually all of the interested people were involved in the discussion sofar. So I do not see why we would need long in a newly formed WG to come to the same conclusion again. But if we do what you propose, then we will consume again more cycles of IESG/IAB and the IETF at large, because they will have to look once more at the WG rechartering in 3 months time. Bert Wijnen > -Oorspronkelijk bericht- > Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Eric > Rescorla > Verzonden: dinsdag 22 april 2008 18:10 > Aan: ietf@ietf.org; [EMAIL PROTECTED] > Onderwerp: Re: WG Review: NETCONF Data Modeling Language (netmod) > > > I object to the formation of this WG with this charter. > > While there was a clear sense during the BOF that there was interest > in forming a WG, there was absolutely no consensus on technical > direction. Rather, a number of proposals were presented, but no > strawpoll, hum, or sense of the room was taken, nor, as far as I can > determine, has there been any such consensus call been taken on any > list I'm aware of. This wasn't an accident--the BOF was explicitly > intended only to determine whether some work in this area should > proceed, not to select a technical approach. > > I understand that an approach like this was proposed in the OPSAREA > meeting by Chris Newman and then that there was a breakout meeting > where it was discussed further. The minutes don't record any consensus > call on this combined direction (only strawpolls on the individual > proposals), and even if such a consensus call had been held, the > OPSAREA meeting would not be the appropriate place for it: this > discussion needs to happen in either the BOF (to allow cross-area > review) or in the designated WG, when it is formed. > > Accordingly, if this WG is to be formed, the entire section (and > corresponding milestones) which specifies the technology needs to be > removed. Rather, the first work item should be to select a technical > approach. > > -Ekr > > > NETCONF Data Modeling Language (netmod) > > > > Last modified: 2008-04-10 > > > > Current Status: Proposed Working Group > > > > Chair(s): > > > > TBD > > > > Operations and Management Area Director(s): > > Dan Romascanu > > Ronald Bonica rbonica at juniper.net > > > > Mailing Lists: > > > > General Discussion: ngo at ietf.org > > > > Description: > > > > The NETCONF Working Group has completed a base protocol to be > > used for configuration management. However, the NETCONF protocol > > does not include a standard content layer. The specifications do > > not include a modeling language or accompanying rules that can be > > used to model the management information that is to be configured > > using NETCONF. This has resulted in inconsistent syntax and > > interoperability problems. The purpose of NETMOD is to support > > the ongoing development of IETF and vendor-defined data models > > for NETCONF. > > > > NETMOD's requirements are drawn from the RCDML requirements draft > > (draft-presuhn-rcdml) and documents referenced therei
Re: Possible RFC 3683 PR-action
On Mar 25, 2008, at 4:57 PM, Michael Thomas wrote: How do I know that you're not a dog? or a puppet... A small fellow with a red nose, a yellow complexion, and a miserable hairdo was at some point even appointed to the IAB !?! http://www.ietf.org/mail-archive/web/ietf/current/msg41460.html :-) --- Bert http://bert.secret-wg.org/ PGP.sig Description: This is a digitally signed message part ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Letter of invitation (for Visa)
I am somewhat surprised about this: LETTERS OF INVITATION: After you complete the registration process, you will be given the option of requesting a Letter of Invitation for IETF 71 in Philadelphia and for IETF 73 in Minneapolis. You can request the Letter of Invitation as soon as you finish registration, or at a later time by following the link provided in the confirmation email. Why does anyone need to REGISTER first before getting an invitation letter which may help with getting a VISA ??? Bert Wijnen ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-iijima-netconf-soap-implementation (Experience of implementing NETCONF over SOAP) to Informational RFC
[ copy to NetConf mailing list is FYI. This document is not a NETCONF WG document, but it is of course related] I reviewed this document and wonder about the following. Specifically I reviewed the document on possible conflicts or contradictions with work that has been done (or is planned to be done) in the NETCONF WG. 0.I think it would be good to add some text to the document (either front page or as the first subsection in section 1) that makes it very clear that this document is not a product from the NETCONF WG but a report on experience by some individual developers/implementers. 1.Section 1.2 I really wonder if RFC2119 language is appririate in a document like this. This is a dopcument that reports on/documents the implementation experience of the authors. I do not see that RFC2119 language makes sense (or was intended) for such a document. As far as I can tell, the document is better if the normal lower case words are used instead of the capitilized words. 2.Sect 1.3. Motivation, states: This document describes why SOAP is practical as a transport protocol of NETCONF in developing a network management system. This document also describes the experience of implementing NETCONF over SOAP. I would prefer that statements like above are written as an opinion or a belief of the authors rather than as if it is a fact on which people in general have consensus. So instead of "why SOAP is practical" I prefer to see "why the authors believe SOAP is practical" or "why the authors find Soap to be practical" 3.Sect 3.1.2 speaks about using the Cookie field in an HTTP header to exchange/store/maintain (?) a session identifier. I worry that this conflicts with (or wonder how it relates to) the fact that RFC4743 (sect 3.3. page 9/10) shows that the session-id is returned inside the hello response from the netconf-managed device. Similar concerns w.r.t. sect 3.2.2 4.Section 3.2.1 refers to "http://schema.xmlsoap.org/soap/encoding"; but that page seems to not exist. Even schema.xmlsaop.org does not exist. Neither does xmlsoap.org. SO I have no idea what to check. 5.Maybe a nit, but anyway. In sect 4.1.1 (maybe in others too) yopu speak about "DOS prompt". I thought it is not really DOS anymore. It is just a "command prompt" is it not? 6.I think it would be good to add to sect 5 (Security COnsiderations) that the security considerations of RFC4741 and RFC4743 also are applicable and should be considered by any implementer or user. Bert Wijnen > -Oorspronkelijk bericht- > Van: The IESG [mailto:[EMAIL PROTECTED] > Verzonden: dinsdag 15 januari 2008 23:01 > Aan: IETF-Announce > Onderwerp: Last Call: draft-iijima-netconf-soap-implementation > (Experience of implementing NETCONF over SOAP) to Informational RFC > > > The IESG has received a request from an individual submitter to consider > the following document: > > - 'Experience of implementing NETCONF over SOAP ' > 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 2008-02-12. Exceptionally, > comments may be sent to [EMAIL PROTECTED] instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-iijima-netconf-soap-impl ementation-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=1541 5&rfc_flag=0 ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-ietf-netconf-notification (NETCONF Event Notifications) to Proposed Standard
Since Mehmet and I recently took over as WG chairs I am now the document shepherd. But the document writeup was already done/prepared by one of the earlier WG chairs. So I am submitting my review comments as IETF Last Call Comments. - sect 2.2.1 I asume that is of type dateTime!!?? Would be good to state so. - on page 14 I see: Should "netmod" be changed into "netconf" !!?? Actaully, I wonder if the line should be instead? Same question on page 15. Mmm... I see it in the Schema on page 17/18 as well. So maybe it is OK. Or is this an accidental inheritance from NETMOD efforts? Is there a good reason to make it netmod and not netconf? - Page 29/30 The above fictional notification definition could result in the following is a sample notification list, which is used in the examples in this section. On 2nd line s/is a// >> - IN IANA COnsiderations, I guess that instead of Following the format in RFC 3688, IANA has made the following registration. We should have stated: Following the format in RFC 3688, IANA is requested to make the following registration. Oh well... that is what we intended to write ;-) - I wonder how/why [XML Schema] Fallside, D. and P. Walmsley, "XML Schema Part 0: Primer Second Edition", W3C XML Schema, October 2004. would/could be a normative reference. It is a "primer", so some sort of education/tutorial on XML Schema, no? I doubt that that should be normative. But I think the issue is that the reference is not so well described. I think they mean to point to: http://www.w3.org/TR/xmlschema-0/ Which states: XML Schema Part 0: Primer Second Edition W3C Recommendation 28 October 2004 So then it is a W3C recomendation, and then it may make sense as normative ref. I think I would make the reference as follows: [XML Schema] Fallside, D. and P. Walmsley, "XML Schema Part 0: Primer Second Edition", W3C Recommendation, 28 October 2004 <http://www.w3.org/TR/xmlschema-0/> - I guess we should instruct the RFC-Editor to remove Appendix A (Change log) right before publication as RFC. Bert Wijnen > -Oorspronkelijk bericht- > Van: The IESG [mailto:[EMAIL PROTECTED] > Verzonden: dinsdag 15 januari 2008 22:59 > Aan: IETF-Announce > CC: [EMAIL PROTECTED] > Onderwerp: Last Call: draft-ietf-netconf-notification (NETCONF Event > Notifications) to Proposed Standard > > > The IESG has received a request from the Network Configuration WG > (netconf) to consider the following document: > > - 'NETCONF Event Notifications ' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2008-01-29. Exceptionally, > comments may be sent to [EMAIL PROTECTED] instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-netconf-notification-11.txt > > > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id > &dTag=14141&rfc_flag=0 > > > ___ > IETF-Announce mailing list > [EMAIL PROTECTED] > https://www1.ietf.org/mailman/listinfo/ietf-announce > ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Lets be careful with those XML submissions to the RFC Editor
W.r.t. > >Ensuring that the resulting text of the submitted XML source match > >identically the approved ID does not seem correct. > > It does to many people who responded on this thread. > Let me inform you all, then when we did the experiment a few years back, I was monitoring/steering that experiment. And I did ALWAYS check the XML file by generating an I-D out of it, comparing it with the I-D we were supposed to be submitting XML for, and whenever there was a mismatch, flags would get raised and diffs would be carefully checked. I agree, once the IESG approves a doc, any changes should be handled very carefully. What seems editorial to one person may not seem so to someone else. Bert ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-ietf-magma-mgmd-mib(MulticastGroup Membership Discovery MIB) to Proposed Standard
ks.
> >./MGMD-STD-MIB:751: [2] {size-illegal} illegal size restriction for
> >non-octet-string parent type `InetAddressType'
> >./MGMD-STD-MIB:756: [2] {sequence-type-mismatch} type of
> >`mgmdInverseHostCacheAddressType' in sequence and object type d
> >efinition do not match
> >./MGMD-STD-MIB:798: [2] {sequence-type-mismatch} type of
> >`mgmdRouterCacheAddressType' in sequence and object type
> defini tion do
> >not match
> >./MGMD-STD-MIB:835: [2] {size-illegal} illegal size restriction for
> >non-octet-string parent type `InetAddressType'
> >./MGMD-STD-MIB:842: [2] {sequence-type-mismatch} type of
> >`mgmdHostSrcListAddressType' in sequence and object type
> defini tion do
> >not match
> >./MGMD-STD-MIB:910: [2] {sequence-type-mismatch} type of
> >`mgmdRouterCacheAddressType' in sequence and object type
> defini tion do
> >not match
> >./MGMD-STD-MIB:796: [3] {sequence-no-column} SEQUENCE element #1
> >`mgmdRouterInterfaceIfIndex' is not a child node under
> >`mgmdRouterInverseCacheEntry'
> >
> >
> All of the following errors occur due to the use of
> previously defined objects in a reverse lookup table. In an
> earlier version of the MIB there were new objects defined for
> these tables with the same meaning, however it was pointed
> out by David McWalter on the list that a reverse lookup table
> should use the same objects as previously defined. This does
> appear to confuse smilint. I am not an expert by any means on
> this so would appreciate guidance on the correct approach. In
> the meantime this seemed acceptable given that the errors
> were all level 3 and above.
>
I did not claim that all warnings are prohibited.,
The following may in act be OK.
I'd have to check deeper.
> >./MGMD-STD-MIB:784: [5] {index-element-not-accessible}
> warning: exactly
> >one index element of row `mgmdRouterInverseCache Entry' must be
> >accessible
> >./MGMD-STD-MIB:909: [3] {sequence-no-column} SEQUENCE element #1
> >`mgmdRouterCacheAddressType' is not a child node under
> >`mgmdRouterSrcListEntry'
> >./MGMD-STD-MIB:909: [3] {sequence-no-column} SEQUENCE element #2
> >`mgmdRouterCacheAddress' is not a child node under `mgm
> >dRouterSrcListEntry'
> >./MGMD-STD-MIB:909: [3] {sequence-no-column} SEQUENCE element #3
> >`mgmdRouterCacheIfIndex' is not a child node under `mgm
> >dRouterSrcListEntry'
> >./MGMD-STD-MIB:102: [5] {inetaddress-inetaddresstype} warning:
> >`InetAddress' object should have an accompanied preceding
> >`InetAdressType' object
> >./MGMD-STD-MIB:258: [5] {inetaddress-inetaddresstype} warning:
> >`InetAddress' object should have an accompanied preceding
> >`InetAdressType' object
> >./MGMD-STD-MIB:496: [5] {inetaddress-inetaddresstype} warning:
> >`InetAddress' object should have an accompanied preceding
> >`InetAdressType' object
> >./MGMD-STD-MIB:524: [5] {inetaddress-inetaddresstype} warning:
> >`InetAddress' object should have an accompanied preceding
> >`InetAdressType' object
> >./MGMD-STD-MIB:599: [5] {inetaddress-inetaddresstype} warning:
> >`InetAddress' object should have an accompanied preceding
> >`InetAdressType' object
> >./MGMD-STD-MIB:620: [5] {inetaddress-inetaddresstype} warning:
> >`InetAddress' object should have an accompanied preceding
> >`InetAdressType' object
> >./MGMD-STD-MIB:758: [5] {inetaddress-inetaddresstype} warning:
> >`InetAddress' object should have an accompanied preceding
> >`InetAdressType' object
> >./MGMD-STD-MIB:844: [5] {inetaddress-inetaddresstype} warning:
> >`InetAddress' object should have an accompanied preceding
> >`InetAdressType' object
> >./MGMD-STD-MIB:862: [5] {inetaddress-inetaddresstype} warning:
> >`InetAddress' object should have an accompanied preceding
> >`InetAdressType' object
> >./MGMD-STD-MIB:917: [5] {inetaddress-inetaddresstype} warning:
> >`InetAddress' object should have an accompanied preceding
> > `InetAdressType' object
> >
> >
> Please advise on how you would like to see this MIB adjusted
> since all items flagged as errors appeared valid to me for
> the reasons provided.
>
They CLERLY are not all valid. Read the InetAddress and InetAddressType
DESCRIPTION clauses and SYNTAX in RFC4001 and you will see that what
you did is worng, I tried to explain that above as well.
Also the TimeTicks issue is NOT acceptable, see above.
Bert
> Many Thanks,
> Julian Chesterfield
>
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-ietf-magma-mgmd-mib(MulticastGroup Membership Discovery MIB) to Proposed Standard
y'
./MGMD-STD-MIB:909: [3] {sequence-no-column} SEQUENCE element #3
`mgmdRouterCacheIfIndex' is not a child node under `mgm
dRouterSrcListEntry'
./MGMD-STD-MIB:102: [5] {inetaddress-inetaddresstype} warning:
`InetAddress' object should have an accompanied preceding
`InetAdressType' object
./MGMD-STD-MIB:258: [5] {inetaddress-inetaddresstype} warning:
`InetAddress' object should have an accompanied preceding
`InetAdressType' object
./MGMD-STD-MIB:496: [5] {inetaddress-inetaddresstype} warning:
`InetAddress' object should have an accompanied preceding
`InetAdressType' object
./MGMD-STD-MIB:524: [5] {inetaddress-inetaddresstype} warning:
`InetAddress' object should have an accompanied preceding
`InetAdressType' object
./MGMD-STD-MIB:599: [5] {inetaddress-inetaddresstype} warning:
`InetAddress' object should have an accompanied preceding
`InetAdressType' object
./MGMD-STD-MIB:620: [5] {inetaddress-inetaddresstype} warning:
`InetAddress' object should have an accompanied preceding
`InetAdressType' object
./MGMD-STD-MIB:758: [5] {inetaddress-inetaddresstype} warning:
`InetAddress' object should have an accompanied preceding
`InetAdressType' object
./MGMD-STD-MIB:844: [5] {inetaddress-inetaddresstype} warning:
`InetAddress' object should have an accompanied preceding
`InetAdressType' object
./MGMD-STD-MIB:862: [5] {inetaddress-inetaddresstype} warning:
`InetAddress' object should have an accompanied preceding
`InetAdressType' object
./MGMD-STD-MIB:917: [5] {inetaddress-inetaddresstype} warning:
`InetAddress' object should have an accompanied preceding
`InetAdressType' object
Bert Wijnen
> -Original Message-
> From: The IESG [mailto:[EMAIL PROTECTED]
> Sent: Thursday, August 30, 2007 5:24 PM
> To: IETF-Announce
> Cc: [EMAIL PROTECTED]
> Subject: Last Call: draft-ietf-magma-mgmd-mib (Multicast Group
> Membership Discovery MIB) to Proposed Standard
>
> The IESG has received a request from the Multicast & Anycast Group
> Membership WG (magma) to consider the following document:
>
> - 'Multicast Group Membership Discovery MIB '
> 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-09-13. Exceptionally, comments
> may be sent to [EMAIL PROTECTED] instead. In either case, please retain
> the beginning of the Subject line to allow automated sorting.
>
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-magma-mgmd-mib-10.txt
>
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=vie
> w_id&dTag=
> 10603&rfc_flag=0
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-ietf-hubmib-efm-cu-mib (Ethernet in the First MileCopper (EFMCu) Interfaces MIB) to Proposed Standard
Yaakov, myself (as HUBMIB WG chair and proto-document-shepherd), the editor and our AD have had some private email exchanges to discuss how to best address the comment from Yaakov below. We have agreed to the following solution: - we do not change the 802.3ah terminology in the text. the main reason for this is to keep consistency with the other EFM related MIB RFCs we have published recently. - We have already explained (1st para on page 3) that IEEE Std 802.3ah-2004 has been integrated into IEEE Std 802.3-2005. - We understand that an abstract plays an important role for people who search for documents/specifications. So the proposal is to add a note to the abstract. Specific change proposed: OLD: Abstract This document defines Management Information Base (MIB) modules for use with network management protocols in TCP/IP based internets. This document describes extensions to the Ethernet-like Interfaces MIB and MAU MIB modules with a set of objects for managing Ethernet in the First Mile Copper (EFMCu) interfaces 10PASS-TS and 2BASE-TL, defined in IEEE Std 802.3ah-2004. In addition a set of objects is defined, describing cross-connect capability of a managed device with multi-layer (stacked) interfaces, extending the stack management NEW: Abstract This document defines Management Information Base (MIB) modules for use with network management protocols in TCP/IP based internets. This document describes extensions to the Ethernet-like Interfaces MIB and MAU MIB modules with a set of objects for managing Ethernet in the First Mile Copper (EFMCu) interfaces 10PASS-TS and 2BASE-TL, defined in IEEE Std 802.3ah-2004 (note: IEEE Std 802.3ah-2004 has been integrated into IEEE Std 802.3-2005). In addition a set of objects is defined, describing cross-connect capability of a managed device with multi-layer (stacked) interfaces, extending the stack management Our AD (Dan Romascanu) will include a note-to-RFC-editor to request that this change be made during the RFC-Editor Editing phase. I assume that everyone is OK with that. However, if anyone does see an issue with it, pls let us (and the IESG) know asap. Bert Wijnen Chair of the IETF HUBMIB WG > -Original Message- > From: Yaakov Stein [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 09, 2007 3:33 PM > To: ietf@ietf.org > Subject: Last Call: draft-ietf-hubmib-efm-cu-mib (Ethernet in > the First MileCopper (EFMCu) Interfaces MIB) to Proposed Standard > > Sorry for the nonsubstantive content, but ... > > The Abstract of this draft refers to IEEE Std 802.3ah-2004. > This was the output of the EFM task force, which completed > its work several years ago. > All content has been absorbed into the 2005 version of 802.3. > > In particular, generic issues on copper are in clause 61, > 10PASS-TS is covered in clause 62 and 2BASE-TL is addressed > in clause 63. > > Although the inclusion into the base standard is mentioned > later on in the document, the precise clauses are not, and > the 802.3ah nomenclature persists throughout the document. > > This behavior is similar to another forum insisting on > referencing an Internet Draft, even after an RFC has been issued. > > Y(J)S > > ___ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-harrington-text-mib-doc-template (A Template for Documents Containing a MIB Module) to BCP
I am basically OK with this document. Some comments you may consider though: - Should you add aa [TODO] to section 5.1 which states that the editor of the document should describe the Textual Conventions (if any) in the MIB module? - I wonder if guidance is needed that they can leave out sect 5.1 if there are no TCs at all. - in Sect 5.3, would it make sense to advise to also describe the tables (and their relationships to each other)? I think that such would be useful. - In sect 5.3, it might be good to suggest that the editor explains how congestion control is addressed for notifications (as per RFC2914) Bert Wijnen > -Original Message- > From: The IESG [mailto:[EMAIL PROTECTED] > Sent: woensdag 10 januari 2007 7:40 > To: IETF-Announce > Subject: Last Call: draft-harrington-text-mib-doc-template (A > Template for Documents Containing a MIB Module) to BCP > > The IESG has received a request from an individual submitter > to consider the following document: > > - 'A Template for Documents Containing a MIB Module ' > as a BCP > > The IESG plans to make a decision in the next few weeks, and > solicits final comments on this action. Please send > substantive comments to the ietf@ietf.org mailing lists by > 2007-02-07. 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. > > Note that the document includes a Normative Reference to RFC > 2629 which is Informational. This is a Downward Reference as > per RFC 3967. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-harrington-text-mib- > doc-template-02.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=vie > w_id&dTag=14807&rfc_flag=0 > > > ___ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce > ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-heard-rfc4181-update (RFC 4181 Update to Recognize the IETF Trust) to BCP
I have read this document and can support it as an update to 4181. Bert Wijnen > -Original Message- > From: The IESG [mailto:[EMAIL PROTECTED] > Sent: dinsdag 16 januari 2007 16:22 > To: IETF-Announce > Subject: Last Call: draft-heard-rfc4181-update (RFC 4181 > Update to Recognize the IETF Trust) to BCP > > The IESG has received a request from an individual submitter > to consider the following document: > > - 'RFC 4181 Update to Recognize the IETF Trust ' > as a BCP > > The IESG plans to make a decision in the next few weeks, and > solicits final comments on this action. Please send > substantive comments to the ietf@ietf.org mailing lists by > 2007-02-13. 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-heard-rfc4181-update-00.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=vie > w_id&dTag=15574&rfc_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: An absolutely fantastic wireless IETF
Agreed. I had a few troubles on Monday in (I think it was monet or one of those rooms upstairs), but other than that it worked great! Thanks to the NOC team and whoever else helped make it work! Bert > -Original Message- > From: Harald Alvestrand [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 23, 2006 21:58 > To: ietf@ietf.org > Subject: An absolutely fantastic wireless IETF > > > Just wanted to state what's obvious to all of us by now: > > This time the wireless WORKED, and Just Went On Working. > > That hasn't happened for a while. THANK YOU! > > Harald > > > ___ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Anatole in-room net confusion
WHen I checked in they told me I would have free inroom internet access. I used it saturday evening/sunday morning and by sunday eve, I did not yet see a charge on my account, so I guess it WAS/IS indeed free. Bert > -Original Message- > From: Sam Weiler [mailto:[EMAIL PROTECTED] > Sent: Monday, March 20, 2006 18:25 > To: ietf@ietf.org > Subject: Anatole in-room net confusion > > > The FAQ at www.ietf65.org says: > > Is there free wired Internet access in the hotel rooms? > > No. > > While http://www.ietf.org/meetings/hotels_65.html says: > > ** Attendees with reservations within the IETF room block will > receive complimentary high speed Internet, local and domestic > long distance calls from their guestrooms. > > And the nice front desk person I spoke with this morning indicated > there would be no charge for wired net. > > What gives? > > -- Sam > > ___ > 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: 'Transferring MIB Work from IETF Bridge WG to IEEE 802.1 WG' to Informational RFC
ETF Working Group > Charter/equivalent of the IETF Working Group Charters/ > 3. Section 2.2, first paragraph: s/to develop MIB modules in the PDF > format/to publish MIB modules only in the PDF format/ > 4. Section 2.2, second paragraph: s/IETF personnel/IETF participants/ > 5. Section 2.2. third paragraph: s/completion/approval/; > s/completed/approved/ > 6. The list in Section 3.2, third paragraph should be dashed > 7. Section 3.3, paragraph 5, line 2: s/variable/variables/ > 8. Section 3.3, paragraph 6: s/802 variables/IEEE 802.1 variables/ > 9. I believe that Sections 2.3 (OID Registration for new MIB modules) > and 3.4 (IANA OID Registration) can and should be merged. Some of the > text in 3.4 seems more a justification and could be eliminated > 10. In many places in the document, including the title the > name Bridge > WG is being used. Actually the official name of the WG was Bridge MIB > WG, while the acronym was bridge (not with capital letter). I > suggest a > global s/Bridge WG/Bridge MIB WG/ > 11. Section 6.1, first paragraph: s/IEEE 802 area/IEEE 802 > project/ and > s/802 developped MIB modules/IEEE 802 developped MIB modules/ > 12. Section 6.1, second paragraph: s/802 developped MIB modules/IEEE > 802 developped MIB modules/ and s/It is not formalized/This is not as > formalized/ > 13. Section 10, last paragraph s/Jorge/The IETF lawyer/ > Nope, instead: s/Jorge/The IETF legal counsel/ Bert > > > > > > -Original Message- > > From: The IESG [mailto:[EMAIL PROTECTED] > > Sent: Friday, March 03, 2006 11:16 PM > > To: IETF-Announce > > Subject: Last Call: 'Transferring MIB Work from IETF Bridge > > WG to IEEE 802.1 WG' to Informational RFC > > > > The IESG has received a request from an individual submitter > > to consider the following document: > > > > - 'Transferring MIB Work from IETF Bridge WG to IEEE 802.1 WG ' > > 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 any > > comments to the iesg@ietf.org or ietf@ietf.org mailing lists > > by 2006-03-17. > > > > The file can be obtained via > > http://www.ietf.org/internet-drafts/draft-harrington-8021-mib- > > transition-01.txt > > > >This document describes the plan to transition responsibility for > >bridging-related MIB modules from the IETF Bridge WG to the IEEE > >802.1 WG, which develops the bridging technology the MIB > > modules are > >designed to manage. > > > > This is not a WG document, but has been discussed quite > > extensively already. The document is intended as > > Informational RFC. Therefor a > > 2 week IETF Last Call is being used for IETF community-wide review. > > > > > > ___ > > 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 > ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin
I appreciate that Adrian and others do care about not being an elephant in a chinashop. But I see a very serious risk of going the otherway where we crawl around as a mouse in-between concrete monuments and are worried that we (as a mouse) would tilt a 1000 kilo monument. First of all, the PR action is not a blanket ban from all mailing lists. I agree it does allow all IETF related mailing list maintainers to ban JFC, but I trust our mailing list maintainers to not do that without good reason. The only help they get by this PR action is that they do not have to go through a admin process to in fact take action. They get the benefit of the doubt that as soon as JFC starts to send questionale postings (for the list admin to evaluate), that they can then block such postings. If anyone finds that a mailing list maintainer were to ban JFC (or anyone hit by a PR action) for no good reason at all (say even before JFC has made any postings), then I feel we should challenge such a list maitainer. But in case of doubt on appropriate behaviour or misconduct on a list, the list maintainer gets the benefit of the doubt to ban. That is all that this bigger hammer is about. This to prevent a DoS on continuous elaborate discussion if a specific person can or cannot be blocked from a list. I also am VERY MUCH against yet designing a 3rd hammer for sanctions. We are the Internet Engineering TF to engineer the Internet and its protocols. We are not an organisation that wants to be the perfect process-organisation and where we have more mercy/pitty with anyone than even mother Teresa had. So in my view we do NOT want to engineer/have sanctions at a fine granularity of 3, 20, 100, 1000 (where does it stop) different levels. Instead, let us do TECHNICAL WORK PLEASE! Or so is my view. Thanks, Bert > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of > Adrian Farrel > Sent: Sunday, January 22, 2006 14:21 > To: iesg@ietf.org > Cc: ietf@ietf.org > Subject: Re: IETF Last Call under RFC 3683 concerning JFC (Jefsey) > Morfin > > > I do not support the action against Jefsey Morfin, because the outcome > would facilitate a ban on all IETF lists without specific cause and > without recourse. I am not in a position to judge the > correctness of a ban > on the lists explicitly cited but I do not believe that we > have witnessed > behavior that is targeted against the IETF per se, and so a > blanket ban is > inappropriate. > > In my view a full 3683 action would be too harsh. > > I am not sympathetic to the argument that says we only have a > large hammer > so we MUST use it because we can't do nothing. > > If those who would exclude Jefsey from certain lists feel > that repeated 30 > day bans are too much work, I suggest they draft a new > process that would > allow them to create longer bans on specific lists. > > Adrian > - Original Message - > From: "Brian E Carpenter" <[EMAIL PROTECTED]> > To: "Sam Hartman" <[EMAIL PROTECTED]> > Cc: "John C Klensin" <[EMAIL PROTECTED]>; "Scott Hollenbeck" > <[EMAIL PROTECTED]>; ; > Sent: Sunday, January 22, 2006 10:30 AM > Subject: Re: Does the IESG have the authority to do less than 3683? > > > > fwiw, my feeling is that if we did bend the rules that way, > > we'd be at strong risk of an appeal. I think the rules are > > in a bit of a mess. > > > > Brian > > > > Sam Hartman wrote: > > >>>>>>"John" == John C Klensin <[EMAIL PROTECTED]> writes: > > > > > > > > > John> For whatever it is worth, I want to remind the > IESG that, > > > John> before there was RFC 3683, there was a notion, > not only of > > > John> 30 day suspensions, but of exponential (or other rapidly > > > John> increasing series) back-off. If someone is > being severely > > > John> disruptive on a particular list, it would seem > reasonable to > > > John> me for the relevant AD to authorize a 60 day > suspension if a > > > John> 30 day one is ineffective, a 120 day suspension > if that is > > > John> ineffective, and so on. The nature of that > arithmetic is > > > John> such that someone could, with sufficient > repeated disruptive > > > John> behavior, find themselves rather effectively > banned for the > > > John> effective duration of a WG. If the IESG believes that a > > > John> formal RFC3933 experiment is needed to do that, > then let's > > > John> write down and run that experiment. But, unt
RE: I-D ACTION:draft-palet-ietf-meeting-venue-selection-criteria- 04.txt
Well said Barry! Bert > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of > Barry Leiba > Sent: Friday, January 20, 2006 17:31 > To: ietf@ietf.org > Cc: [EMAIL PROTECTED] > Subject: Re: I-D > ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt > > > > So, could people please review it for errors and omissions? > > My biggest concern is in sections "2.3. Freedom of Participation" > and "2.5. Attendance Limitation and Visas", in that I'm not sure > how realistic they are. Without getting overly into politics (let's > please not), I think they reflect a somewhat naïve view of some of > the political realities. Specifically... > > Meetings should not be held in countries where some > attendees could > be disallowed entry or where freedom of speech is not > guaranteed for > all participants. > > The United States certainly cannot be assumed to allow ALL attendees > entry. It's well known that we have lists of people we won't allow > in, and lest we think that's limited to the sort of nasty folk who > wouldn't be attending the IETF anyway, I'll point out that a plane > carrying Yusuf Islam -- the singer formerly known as Cat Stevens -- > was landed in Maine so that the singer could be removed and sent home > before the plane continued to New York. Individuals do get on these > lists unreasonably, or by mistake. > > Ignoring the issue of individuals, whole groups may have difficulty. > The US has a list of "restricted countries", which includes Iran and > North Korea, and a longer list of countries to which exports > of software > or technology are controlled (this list includes Russia and China, > for example). There's certainly no guarantee at any time > that attendees > from these countries won't have a difficult time getting > visas, or might > not be able to get them at all. > > As to freedom of speech: We could argue about the reality of that > for a while, but even apart from that, our government has made it > clear that it considers those constitutional rights to apply to US > citizens only, and not to foreign nationals who may be visiting. > > OK, all that said, I don't think the US is a bad country in which to > have IETF meetings. Which is, really, my point: I think the text > needs to be changed to better express the intent, which is that we > want to avoid countries that are unduly restrictive, without trying > to limit things to utopian -- and non-existent -- lands of complete > freedom. > > -- > Barry Leiba ([EMAIL PROTECTED]) > http://www.research.ibm.com/people/l/leiba > http://www.research.ibm.com/spam > > ___ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin
Glad to hear it is not just me. Bert > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of > Stephane Bortzmeyer > Sent: Friday, January 20, 2006 13:41 > To: Margaret Wasserman > Cc: 'Harald Tveit Alvestrand'; 'Scott Hollenbeck'; 'Sam Hartman'; > ietf@ietf.org; iesg@ietf.org > Subject: Re: IETF Last Call under RFC 3683 concerning JFC (Jefsey) > Morfin > > > On Fri, Jan 20, 2006 at 07:03:52AM -0500, > Margaret Wasserman <[EMAIL PROTECTED]> wrote > a message of 155 lines which said: > > > I also have found that Jefsey's posts have a higher signal-to-noise > > ratio than many peoples' posts, but I am willing to chalk some of > > that up to the fact that he is a non-native English speaker who is > > trying to make himself understood, and so I try to be patient with > > that, too. > > I can testify that Jefsey Morfin's posts in french are as long, as > off-topic and as undecipherable than in english. > > ___ > 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: 'A Roadmap for TCP Specification Documents' to In formational RFC
Thanks Eric, and let me add and make clear that I (and as far as I know ALL ADs) appreciate these types of comment very much. Knowing that there are people who read the document, understand it and find it useful is good input into our IETF review and approval process. Much better than silence. Bert > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of > Gray, Eric > Sent: Thursday, January 19, 2006 02:07 > To: 'iesg@ietf.org' > Cc: ietf@ietf.org > Subject: RE: Last Call: 'A Roadmap for TCP Specification Documents' to > In formational RFC > > > If we can make positive comments, I think this is a really > useful document to have... > > -- > Eric > > --> -Original Message- > --> From: [EMAIL PROTECTED] > --> [mailto:[EMAIL PROTECTED] On Behalf Of The IESG > --> Sent: Wednesday, January 18, 2006 4:39 PM > --> To: IETF-Announce > --> Cc: [EMAIL PROTECTED] > --> Subject: Last Call: 'A Roadmap for TCP Specification > --> Documents' to Informational RFC > --> > --> The IESG has received a request from the TCP Maintenance > --> and Minor Extensions > --> WG to consider the following document: > --> > --> - 'A Roadmap for TCP Specification Documents ' > --> 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 any comments to the > --> iesg@ietf.org or ietf@ietf.org mailing lists by 2006-02-01. > --> > --> The file can be obtained via > --> http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-road > --> map-05.txt > --> > --> > --> ___ > --> IETF-Announce mailing list > --> IETF-Announce@ietf.org > --> https://www1.ietf.org/mailman/listinfo/ietf-announce > --> > > ___ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: XML2RFC submission (was Re: ASCII art)
> > - Making XML-RFC versions of existing or new RFCs available > > to the public. > > absolutely! > I see support of this a few times (and that includes me). I think that if you (we) all really mean this, then I think it would be good to see if you can get it accepted as an IETF (consensus) requirement in the TECHSPEC mailing list: [EMAIL PROTECTED] Otherwise, I suspect it will not happen for a long time! > The RFC Editors actually have source versions of most existing RFCs, > either as nroff or xml. They're just not easily accessible; > you have to ask to get a specific copy. I've always been surprised > that they haven't been accessible right next to the .txt files. > Let me repeat, that as far as I know, the RFC editor does NOT have .xml versions of the FINAL RFC. They always end up generating .nroff files and do some tailoring/editing to the .nroff before the final RFC gets produced (from .nroff). See also my earlier posting. I personally think that is unacceptable... but that is just that, my personal opinion. If we (IETF) want it changed, then we better express the need/requirement in the techspec activity as I said above. Bert > Tony Hansen > [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: XML2RFC submission (was Re: ASCII art)
W.r.t. > > - We can say that it's time to require XML2RFC for all drafts. > > there is a variant of this that i think i like: > > do not impose this switch onto those submitting, but change > the formatting language used by the rfc editor to be xml2rfc. > > so, submissions in xml2rfc are highly welcome, but pure text is still > welcome, with hand-conversion by the editor staff. I appreciate that we (IETF) try to not force everybody into using the same tool. It probably is a productivity booster for many authors if they can continue to work with the tools they normally use in daytime job or have become used/accustomed to over the years. At the other hand, I would want everybody to realize that if we say: ..., but pure text is still welcome, with hand-conversion by the editor staff. that that means a SERIOUS cost. You did all see the numbers at the last Plenary, where (iirc) the rough number for RFC-editor is 1 million dollars for the coming year. The more "hand-conversion" work we impose on the RFC-Editor, the more that it will cost us (IETF). So I feel that there is a justified "pressure" for authors to seriously consider to use the tools we (as IETF) choose to focus on. just my 2 cents. Bert ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: XML2RFC submission (was Re: ASCII art)
Dave Crocker wrote: > This looks like quite a good list. The only thing I would add is an > interactive submission tool that validates the xml2rfc document being > submitted. > > Rather than explicitly penalize the text submitters with an earlier date, > I'd suggest providing a bonus extension deadline for those submitting via > this interactive path, since it would require NO human intervention on the > I-D publishing side... after the tool gets built. > I don't want to end up in long discussions on IETF list. But one of the reasons for EARLY submission deadline is to ensure that the IETF participants actually get some time to READ/STUDY the documents that need f2f time in IETF WG meetings! Bert ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: RFCs should be distributed in XML
> > These days, when a draft moves into the RFC editor queue, the RFC > > editor sends a request to the author to send in the xml2rfc input > > files if they exist. > > Ironically, the *very next* message in my inbox after Bill's was just > such a request from the RFC Editor, for draft-ietf-ltru-initial-06. > But be carefull As far as I know (RFC-editor can and will (I suspect) correct me if I am wrong) the RFC-Editor will not generate the FINAL RFC from the xml source file. I am in fact not 100% sure how much of the editing they do to the xml source file. But at some point I believe they generate an nroff source file from the xml source file. And after that point they still make (at least sometimes) additional changes to the nroff file that do not get reflected in the xml source file. So (as far as I know), you can and will not get back an xml source file from RFC-editor that is 100% in sync with the final RFC. And such (in my view) is bad for future revisions (if any) cause the author (or next WG editor) will have to manually figure out what the changes were and manually retrofit them. Bert ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: On revising 3777 as in draft-klensin-recall-rev-00
Eric, This discussion is appropriate on this list, that is not my point. I would have stated "I think this is off topic for this list" if it were. I am just so frustrated that good technical people spend (I perceive it as waste, but that is subjective and not fair) their time on these sort of admin/bureaucratic/overhead/legal/organizational/etc topics while we have so many technical work to do. The example of recall is especially a case where we have not had any recall in the whole life-time of IETF. So why do we need to spend oodles of cycles on clarifying/more details/ long discussions/ theories/ etc etc on this topic? Do we have a real problem here that needs to be solved? I personally think NOT. Yet we have a long queue of documents that need technical review. I need to do that work. If people with time on their hands can help me (and otehr ADs and other WGs (think cross-area review), then PLEASE do offer your help!!! Sooner is better than later in fact Bert > -Original Message- > From: Gray, Eric [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 17, 2005 01:03 > To: 'Wijnen, Bert (Bert)' > Cc: ietf@ietf.org > Subject: RE: On revising 3777 as in draft-klensin-recall-rev-00 > > > Bert, > > Let me see if I understand you correctly. You think > this discussion is inappropriate for this mailing list? > > -- > Eric > > --> -Original Message- > --> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > --> On Behalf Of Wijnen, Bert (Bert) > --> Sent: Wednesday, November 16, 2005 6:28 PM > --> To: ietf@ietf.org > --> Subject: RE: On revising 3777 as in draft-klensin-recall-rev-00 > --> > --> Do we have no serious technical work to do in IETF except > --> discuss these types of topics? > --> > --> PLEASE > --> > --> I see all sort of good technical peopel spending cycles on this. > --> > --> Do you want to review some documents for me and report your > --> technical finding back to me and the community? > --> > --> Bert > --> > --> ___ > --> 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: On revising 3777 as in draft-klensin-recall-rev-00
Do we have no serious technical work to do in IETF except discuss these types of topics? PLEASE I see all sort of good technical peopel spending cycles on this. Do you want to review some documents for me and report your technical finding back to me and the community? Bert ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: RFCs should be distributed in XML (Was: Faux Pas -- web publi cation in proprietary formats at ietf.org
smb writes: > >I've been pondering change tracking, in the context of copy-editing, > >but I haven't come up with a complete thought yet. > > > > CVS? Should the Secretariat make CVS archives available to WG > document editors? I've written a book and many joint papers via CVS; > it works very well for line-oriented ASCII input, whether XML, LaTeX, > nroff, or what have you. > I think such a service would be a GREAT service for our WGs and document editors/authors. Has the tools team looked at it at all? Bert ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
New OPS-AD needed
The emails from Alex and Scott reminded me that I also want to publicly announce that I will not re-up, in other words that I will be stepping down in March. I have enjoyed doing the AD job a lot. I have to admit that there are also several less pleasant aspects in the AD job. But all in all I am glad I did get the opportunity to learn so much and to have been able to interact with so many people about all sorts of technical and organizational and process topics. But 8 years I think is enough, and I think it is time for new blood for the Netowrk Management side of the OPS Area. Thank you all for your trust and confidence in my being an AD. And pls help the nomcom find a good candidate or better candidates! Bert ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Pesci-discuss] Growing concerns about PESCI
speaking as an individual participant. W.r.t. > Is PESCI characterizing the current process or inventing a new > one? Is it about principles for the IETF or principles for > process change? My understanding is that the PESCI effort is to come up with a proposal for the IETF on "how to deal/handle process changes". In other words, today all of this is done via BCPs that go through IESG for approval. A problem is that the IESG becomes the bottleneck, but also that IESG may be reluctant to change when the change impacts the IESG functions/functioning itself. Another problem I see is that the IESG (who is supposed to steer and process the IETF technical (standardization) work) often gets interrupted to deal with process cgange proposals. So my hope would be that PESCI can propose a new "process for process and/or organizational change(s)" that will take the IESG out of the loop, but would have mechanisms for gauging IETF consensus on any future changes similar to what we have today. Once the PESCI effort comes up with such a proposal, we (IETF) can evaluate it and probably approve it as a BCP, just following our current process (i.e. a sponsoring AD and go through IESG etc). Once that new BCP gets approved, we can leave the IESG out of the critical path and new proposals for process or organization changes can then be handled via that new mechanism. So in that sense, I agree with you John that a lot of the discussion on the PESCI mailing list is so to speak "not-in-scope" for the task that the PESCI team was started (at least as I understood it). Bert ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [EMAIL PROTECTED]: Mismanagement of the DNSOP list]
Steve writes: > Actually, 3683 specifically requires community discussion of motions to > block someone's posting rights. It is, in so many words, done by a > Last Call. > Steve, I thought that RFC3683 is intended to apply "drastic measures" (see intro, page 4). RFC2418 allows a WG chair and the ADs to also take measures if someone is disrupting WG progress (sect 3.2). I certainly hope that we do not have to have the equivalent of an "IETF Last Call" everytime that a WG chair or AD finds that an individual is disrupting normal WG process. Bert ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Myths of the IESG: Reading documents is the problem
Brian responded on this thread: > > Having a non-cognizant AD press late-stage issues leads to the question > > of why they did not pay attention earlier? If the topic is important > > enough for them to delay the wg output now, why was it not important > > enough earlier? > > It seems to me that the *primary* responsibility for ensuring that > the WG considers everything it should consider, at an early enough > stage, lies with the WG Chair(s). > > Certainly, the AD has an oversight and mentoring role here, > especially for first-time WG Chairs, but your obvious question > should be directed first to the WG Chair(s) and only second to > the ADs. > > I don't mean the ADs have no duties in this area - but they > can't be everywhere at once and read every email. > And there you a hit a second MAIN LOAD on ADs. I (for one) get FAR too many (often long) emails that I need to read and evaluate and have an opinion on. This thread started on Aug 9th, and only now (saturday evening Aug 13th) am I reading this thread of some 24 (pretty long) emails. Bert > Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: 'Requirements for IETF Draft Submission Toolset' t o Informational RFC
> -Original Message- > From: Scott W Brim > Sent: Friday, April 08, 2005 14:27 > > On 4/7/2005 10:36, Brian E Carpenter allegedly wrote: > > Regardless of the interesting side-discussion about 'voting', > > what the toy shows after about a day is: > > > > prefer nroff: 8 > > prefer xml: 37 > > neither: 9 > > I wonder how many of those have actually written a draft using both? > I have! and I clearly prefer xml Bert ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Kudo's for the audio streaming
This time I had to skip physical attendance of IETF62 for personal/medical reasons. So I was pleased to see that ALL meeting sessions were being audiocast. I have followed several meetings. Some were better than others in that some chairs were good in telling people to use the microphones. Others were less good because people did NOT use the mircrophones all the time. Best is if people also state their name... bit even if they don't, one should at least speak into the mic so that the comments/questions/presentations can be clearly heard. I have also seriously participated in 3 meetings. For those I had asked the WG chairs in advance to try and make sure that the slides were available (either online or via email) and that someone would watch the jabber chat room to at least relay any comments/questions I might have. And that worked well. So Thank You to the people who did make it work. And for all WG chairs, pls try to understand what it means if you are a remote participant. Pls do encourage speakers to submit slides early so they can be made available to remote participants (a secondary advantage is that you then also have them to submit to the proceedings). Make sure people speak into the mic. Also, the better you have prepared an agenda (with possibly direct links to the presentations and documents), the better it helps remote folk to participate. And a jabber room to at least allow remote participants to send comments/questions that can/should be relayed by one of the people who are physically in the meeting. I have heard that a full scribe would still be usefull, but for those who can actually listen in into the audio, that seems less needed (at least in my experience). Thanks again, Bert ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Perhaps clarify: #825 - IASA responsibilities regarding IPR
Inline > -Original Message- > From: Margaret Wasserman [mailto:[EMAIL PROTECTED] > Sent: Tuesday, February 01, 2005 15:21 > To: Wijnen, Bert (Bert); Contreras, Jorge; Harald Tveit Alvestrand; > ietf@ietf.org > Subject: RE: Perhaps clarify: #825 - IASA responsibilities > regarding IPR > > > At 12:16 PM +0100 2/1/05, Wijnen, Bert (Bert) wrote: > > > > The IASA is responsible for managing all intellectual > > property rights (IPR), including but not limited to > > trademarks, and copyrights, that belong to the IETF. > > Is this really what we want to say? I believe so. The above is theadditional responsibility for IASA. The text you are stating below is already in the document (in some form) in other places. Bert > Or do we want to say something like: > > The IASA is responsible for managing all intellectual property rights > (IPR) related to IETF administrative support, including but not > limited to trademarks, copyrights, attendance lists, tools, etc.? > > We have an IPR WG and have undertaken a mammoth effort to define our > standards-related IPR and how that will be assigned and managed, and > I am not sure that we want to hand management of that IPR over to the > IASA/IAOC, do we? Given the number of the people in the community > that were involved/interested in that effort, I think that we may > continue to want direct community control over the standards-related > IPR. > > Margaret > > > ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Perhaps clarify: #825 - IASA responsibilities regarding IPR
Give the discussions after I posted this, I now have changed the text in my edit buffer as follows: The IASA is responsible for managing all intellectual property rights (IPR), including but not limited to trademarks, and copyrights, that belong to the IETF. The IASA is also be responsible for managing the ownership, registration and administration of relevant domain names. The IASA is responsible for undertaking any and all required actions on behalf of the IETF to obtain, protect and manage the rights that the IETF needs to carry out its work. Better? Bert > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of > Wijnen, Bert (Bert) > Sent: Monday, January 31, 2005 23:56 > To: Contreras, Jorge; Harald Tveit Alvestrand; ietf@ietf.org > Subject: RE: Perhaps clarify: #825 - IASA responsibilities > regarding IPR > > > Thanks. SO this is what I now have in my edit buffer: > > > The IASA is responsible for managing all IPR, > including but not limited to trademarks, domain names, > and copyrights, that belong to the IETF. > It is responsible for undertaking any and all required > actions on behalf of the IETF to obtain, protect and > manage the rights that the IETF needs to carry out > its work. > > > Bert > > > -Original Message- > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of > > Contreras, Jorge > > Sent: Monday, January 31, 2005 19:01 > > To: Harald Tveit Alvestrand; ietf@ietf.org > > Subject: RE: Perhaps clarify: #825 - IASA responsibilities > > regarding IPR > > > > > > >I suggest we change the text in section 3 from: > > > > > The IASA is responsible for undertaking any and all > > required actions > > > that involve trademarks on behalf of the IETF. > > > > > >to: > > > > > > The IASA is responsible for managing all IPR, including but not > > > limited to trademarks, domain names, and copyrights, > that belongs > > > to the IETF. It is responsible for undertaking any and > > > all required actions on behalf of the IETF to obtain, > protect and > > > manage the rights that the IETF needs to carry out its work. > > > > >I'm sure Jorge could phrase it better. but I think the meaning > > >is clear. > > > > That looks good. In line 2, "belongs" should be "belong", > > but otherwise I don't have any other improvements. > > > > > > > > > > ___ > > Ietf mailing list > > Ietf@ietf.org > > https://www1.ietf.org/mailman/listinfo/ietf > > > > ___ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Suggested resolution - #826: Section 4 - Removal of the IAOC Chair
Harald responded: > > --On mandag, januar 31, 2005 23:56:27 +0100 "Wijnen, Bert (Bert)" > <[EMAIL PROTECTED]> wrote: > > > So (assuming 5/8 for now), the text would look like: > > > >The Chair serves at the pleasure of the IAOC, and may be removed from > >that position at any time by a vote of 5/8 of the voting IAOC members. > > > > That is what I now have in my editing buffer. > > I think at least 2 people preferred to say "2/3 of the voting IAOC members, > not counting the IAOC chair", which would have the same effect on numbers. > I could live with that. > I can live with that too. SO that is what is now in my editing buffer. Bert p.s. I intend to submit a new rev in a couple of hours! ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Monday consensus text: #725 Appealing decisions
>From Haralds latest text (below), the 2nd para reads: > In the case where someone questions whether a decision or action of the > IAD or the IAOC has been undertaken in accordance with IETF BCPs or > IASA operational guidelines (including the question of whether > appropriate guidelines have been created or maintained), he or she may > ask the IAOC for a formal review of the decision or action. > Rob and certainly I (when editing this) had to read this 2 or 3 times. We think that the following (in our view) purely editorial change would make it more readable: If a member of the IETF community questions whether a decision or action of the IAD or the IAOC has been undertaken in accordance with IETF BCPs or IASA operational guidelines, or questions whether the IASA has created and maintained appropriate guidelines, he or she may ask the IAOC for a formal review of the decision or action. OK? Bert p.s. John, In my editing buffer I have also fixed the last para to make it "IAB and ISOC BoT" instead of "IESG and ISOC" -- latest tex from Harald from Monday): > Still - I think this is a text that is possible to live with. > > 3.5 Review and Appeal of IAD and IAOC Decision > > The IAOC is directly accountable to the IETF community for the > performance of the IASA. In order to achieve this, the IAOC and IAD > will ensure that guidelines are developed for regular operational > decision making. Where appropriate, these guidelines should be > developed with public input. In all cases, they must be made public. > > In the case where someone questions whether a decision or action of the > IAD or the IAOC has been undertaken in accordance with IETF BCPs or > IASA operational guidelines (including the question of whether > appropriate guidelines have been created or maintained), he or she may > ask the IAOC for a formal review of the decision or action. > > The request for review is addressed to the IAOC chair and should include > a description of the decision or action to be reviewed, an explanation > of how, in the requestor's opinion, the decision or action violates the > BCPs or operational guidelines, and a suggestion for how the situation > could be rectified. All requests for review > will be publicly posted, and the IAOC is expected to respond to these > requests within a reasonable period, typically within 90 days. It is up > to the IAOC to determine what type of review and response is required, > based on the nature of the review request. > Based on the results of the review, the IAOC may choose to overturn > their own decision, change their operational guidelines to prevent > further misunderstandings, take other action as appropriate, or just > publish the review result and take no other action. > > If a member of the community is not satisfied with the IAOC's response > to his or her review request, he or she may escalate the issue by > appealing the decision or action to the IAB, using the appeals > procedures outlined > in RFC 2026 [RFC2026]. If he or she is not satisfied with the IAB > response, he or she can escalate the issue to the ISOC > Board of Trustees, as described in RFC 2026. > > The reviewing body (IAB or ISOC BoT) will review the decision of the > IAD or IAOC to determine whether it was made in accordance with existing > BCPs and operational guidelines. As a result of this review, the > reviewing body may recommend to the community that the BCPs > governing IAOC actions should be changed. > It may also advise the IAOC to modify existing operational guidelines > to avoid similar issues in the future and/or may advise the IAOC to > re-consider their decision or action. > It may also recommend that no action be taken based on the review. > > In exceptional cases, when no other recourse seems reasonable, the > reviewing body may overturn or reverse a non-binding decision or > action of the IAOC. This should be done after careful consideration > and consultation with the IAOC regarding the ramifications of this > action. In no circumstances may the IESG or IAB overturn a decision of > the IAOC that involves a binding contract or overturn a personnel- > related action (such as hiring, firing, promotion, demotion, > performance reviews, salary adjustments, etc.). > > Comments? > > Harald > > > ___ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Perhaps clarify: #825 - IASA responsibilities regarding IPR
Thanks. SO this is what I now have in my edit buffer: The IASA is responsible for managing all IPR, including but not limited to trademarks, domain names, and copyrights, that belong to the IETF. It is responsible for undertaking any and all required actions on behalf of the IETF to obtain, protect and manage the rights that the IETF needs to carry out its work. Bert > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of > Contreras, Jorge > Sent: Monday, January 31, 2005 19:01 > To: Harald Tveit Alvestrand; ietf@ietf.org > Subject: RE: Perhaps clarify: #825 - IASA responsibilities > regarding IPR > > > >I suggest we change the text in section 3 from: > > > The IASA is responsible for undertaking any and all > required actions > > that involve trademarks on behalf of the IETF. > > > >to: > > > > The IASA is responsible for managing all IPR, including but not > > limited to trademarks, domain names, and copyrights, that belongs > > to the IETF. It is responsible for undertaking any and > > all required actions on behalf of the IETF to obtain, protect and > > manage the rights that the IETF needs to carry out its work. > > >I'm sure Jorge could phrase it better. but I think the meaning > >is clear. > > That looks good. In line 2, "belongs" should be "belong", > but otherwise I don't have any other improvements. > > > > > ___ > 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: Suggested resolution - #826: Section 4 - Removal of the IAOC Chair
So (assuming 5/8 for now), the text would look like: The Chair serves at the pleasure of the IAOC, and may be removed from that position at any time by a vote of 5/8 of the voting IAOC members. That is what I now have in my editing buffer. OK? Bert > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Harald > Tveit Alvestrand > Sent: Sunday, January 30, 2005 21:43 > To: Kai Henningsen; ietf@ietf.org > Subject: Re: Suggested resolution - #826: Section 4 - Removal of the > IAOC Chair > > > > > --On lørdag, januar 29, 2005 11:47:00 +0200 Kai Henningsen > <[EMAIL PROTECTED]> wrote: > > >> It was the fraction "2/3" that Russ objected to in the first place, > >> pointing out that this means 6 out of 8 if everyone's > present - which he > >> thought was too much of a required majority. > > > > Which just points to a lower fraction, not to absolute numbers. > > I understand that you and Scott both think the same thing - > although I > don't understand why, I'll ask the question in a different > way - is using > the term "5/8 of the voting members" an acceptable phrase? > As long as we have 8 voting members, that translates to 5 members. > > For those who want to see what they are discussing under different > scenarios, here is the number of people needed to remove the > chair with > varying fractions and varying number of members of the IAOC: > > Number Out of 8 Out of 7 Out of 6 Out of 5 > 3/46 654 > 2/36 544 > 5/85 544 > > Harald > ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Comment on draft-ietf-iasa-bcp-05
The current text I now have for this in my edit buffer os as follows: The IAOC members shall not receive any compensation from the IASA, ISOC or IETF for their services as members of the IAOC. OK? Bert > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of > Russ Housley > Sent: Sunday, January 30, 2005 17:52 > To: ietf@ietf.org > Subject: Comment on draft-ietf-iasa-bcp-05 > > > I have a minor issue. Section 4 says: > > The IAOC members shall not receive any compensation for their > services as members of the IAOC. > > Clearly, some people are allowed to work on IETF stuff during > hour paid for > by their employers. Thus, they are compensated. We need to > be more clear > here., perhaps: " ... shall not receive any compensation from > IASA or the > IETF ..." > > Russ > > > ___ > 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: BCP sec 4 - end of term
Scott writes:
> not a showstopper but it woudl eb good to be clear
>
> the text curently says:
>Subject to paragraph 2 of Section 4.1, appointed members of the IAOC
>serve two year terms. IAOC terms normally end at the first IETF
>meeting of a year, just as as IAB and IESG terms do.
>
> I suggest changing this to say
>Subject to paragraph 2 of Section 4.1, appointed members of the IAOC
>serve two year terms. IAOC terms normally end at the end of the
>first IETF meeting of a year.
>
> its good to be specific as to when during the meeting
>
Makes sense to me, so I have the change made in my edit buffer for rev 06.
That text now looks as follows:
Subject to paragraph 2 of ,
appointed members of the IAOC serve two year terms.
IAOC terms normally end at the end of the first IETF
meeting of a year.
Bert
> Scott
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
RE: Resolution? #787 terminology and issue 794 - naming of accou nts
> Lynn St.Amour wrote:
> At 1:25 PM +0100 1/26/05, Wijnen, Bert (Bert) wrote:
> >Having seen some more reactions... I think we can solve
> >the "general Ledger Accounts" issue with a very simple
> >addition as follows:
> >
> >
> >
> > As discussed with ISOC, funds managed by IASA shall
> > be accounted for in a separate set of general ledger
> > accounts within the Cost Center IASA.
> > In the remainder of this document, these general ledger
> > accounts are termed "IASA accounts".
> > A periodic summary of the IASA accounts shall be
> > reported
> > in the form of standard financial statements that
> > reflect
> > the income, expenses, assets, and liabilities of the
> > IASA
> > cost center.
> >
> >
>
> Bert, one nit -- the last sentence should be changed as follows:
>
> s/and liabilities of the IASA cost center./and liabilities of IASA./
>
> Cost center terminology refers to the P&L but as we're including
> assets and liabilities it doesn't really belong here.
>
I am OK with the change.
I have had a few private notes saying that Lynn's change is fine as
is the current text. So it seems we might as well make the change.
Note that we had already removed the "As discussed with ISOC" piece in
rev 05.
I now have in my edit buffer for rev 06:
Funds managed by the IASA shall be accounted for
in a separate set of general ledger accounts
within the IASA Cost Center.
In the remainder of this document, these general
ledger accounts are termed "IASA accounts".
A periodic summary of the IASA accounts
shall be reported in the form of standard
financial statements that reflect the income,
expenses, assets, and liabilities of the IASA.
I am going to assume this is OK with everyone unless I
hear/see objections
Bert
> Thanks, Lynn
>
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
RE: Progressing Re: Progress report......
Scott writes > > > All we need to do is that as soon as we have IASA in place (we > > still need to approve the BCP first) that IASA then starts > > to prepare for RFPs and such and then the process can start. > > the "prepare for RFPs" seems futile (or at least *very* premature) > if NeuStar is to get a N-year agreement/contract > Gets an "N-year" contract with whom? We are not part of the deal between CNRI/Neustar, are we? Not according to what I understood of the posting! Bert > I agree with John that we need to figure out if the BCP as-is > is all that useful in the face of what appears to be a done deal > > Scott > ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Mud. Clear as. Re: Rough consensus? #425 3.5
I like this text. In any event, it seems much closer to what the community seems to want than what we have in the revision 04 document. So I have included the text suggested by Leslie, with the understanding that I have not yet seen Harald declare consensus (seems early for that anyways). In the rev 05 doc (that I just submitted to the repository) I have marked the text as "strawman text"... so I hope that that is acceptable for now. Bert > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of > Leslie Daigle > Sent: Wednesday, January 26, 2005 03:16 > To: ietf@ietf.org > Subject: Mud. Clear as. Re: Rough consensus? #425 3.5 > > > > With apologies for having posted & disappeared (ISP & other > unexpected connectivity challenges), I'd like to try another > cut at what I was getting at, based on the discussion since. > > On Friday, I tried a minimal edit on words that had flown > around the list and seemed to have some consensus. Here's > more of an extensive rewrite. > > Apart from the distinction I had tried to make about > > . business decisions (implementation) versus > . performance > > I heard these requirements expressed: > > . DoS concerns -- don't create a system that begs for > denial of IASA service through the appeal/review process > . second-guessing -- don't create an environment where > some or all of the community is second-guessing IAD/IAOC > at every move > . community involvement -- adequate and appropriate > community involvement in the IASA decision making process > > And I heard various theories about distinguishing between > > . before decisions are made > . during the decision-making process > . after decisions have been made > > particularly in terms of whether we are discussing > > . appeal (review of executed action by an univolved > body) > . review (further discussion of an action or proposal) > . recall of IAOC members > > > Separately from those considerations, there is the question of > implementation -- what people/body(ies) invoke an action, and > so on. > > So, generally speaking, I think the important things to capture > in the BCP are: > > . business decisions remain within the IASA > in terms of review mechanisms (i.e., contracts, etc) > > . the IASA should be explicitly pressed to publicize > and seek input on guidelines for making those decisions > > . public information should include objective measurements > of system performance (e.g., document processing > times) > > . there should be a crisp review process to address > the situation when (some subset of the IETF believes) > the IASA has not followed its guideliness in > carrying out an action -- and that includes the expectation > of having public guidelines. > > To the meeting location example -- that would mean (IMO) that > the IASA should have some public guidelines for how it picks > meeting sites, and if a site is picked that appears to be at > odds with those guidelines, then there is a process for reviewing > the IASA's actions in selecting that site. NB - that is different > than appealing the site itself. > > So, with all that in mind, I propose the following revised > text for the 2 sections I suggested on Friday: > > > > > 3.5 Business Decisions > > Decisions made by the IAD in the course of carrying out IASA business > activities are subject to review by the IAOC. > > The decisions of the IAOC must be publicly documented for each formal > action. > > 3.6 Responsiveness of IASA to the IETF > > > The IAOC is directly accountable to the IETF community for the > performance of the IASA. In order to achieve this, the > IAOC and IAD will ensure that guidelines are developed > for regular operation decision making. Where appropriate, these > guidelines should be developed with public input. In all > cases, they must be made public. > > Additionally, the IASA should ensure there are reported objective > performance metrics for all IETF process supporting activities. > > In the case where someone questions that an action of the IAD or the > IAOC has been undertaken in accordance with this document > or those operational guidelines (including the creation of an > appropriate set of such guidelines), he or she may ask for a formal > review of the action. > > The request for review is addressed to the person or body that took > the action. It is up to that body to dec
RE: Progressing Re: Progress report......
John writes: > > ... snip a lot .. > I'd rather either > > * Fix the BCP to accommodate this case, i.e., to give > the IAOC the authority to accept unsolicited, > sole-source proposals for outsourced operations if that > seems appropriate to them, even if those proposals do > not fufill some of the principles of the BCP itself or > > * Bury the BCP, at least in its present form, until we > are really ready to move forward with its provisions. > > The first of those options would, of course, respond to my > question about how the community authorizes this type of deal: > we examine the principles and give the IAOC the authority to do > it. > It seems to me that we (as IETF community) have no formal control at all over what CNRI/Fortec do. So why would we as a community have (or need) any say over what CNRI/Neustar do? All we need to do is that as soon as we have IASA in place (we still need to approve the BCP first) that IASA then starts to prepare for RFPs and such and then the process can start. During that process, we are still subject to whatever CNRI/Foretec/Neustar do, are we not? Bert > regards, > john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Issue 820: RE: Legal review results 1: Intellectual property (fwd )
I included an issue number.
The text had just made it to the list before your repost.
So I have added the suggested wording with Haralds adjustment
to the revision 05.
Bert
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
> Harald Tveit Alvestrand
> Sent: Wednesday, January 26, 2005 14:49
> To: ietf@ietf.org
> Subject: RE: Legal review results 1: Intellectual property (fwd)
>
>
> This doesn't seem to have made it to the list...
>
>
> -- Forwarded Message --
> Date: mandag, januar 24, 2005 15:53:48 -0500
> From: "Contreras, Jorge" <[EMAIL PROTECTED]>
> To: Brian E Carpenter <[EMAIL PROTECTED]>, Harald Tveit Alvestrand
> <[EMAIL PROTECTED]>
> Cc: ietf@ietf.org
> Subject: RE: Legal review results 1: Intellectual property
>
> > If we assume that the IETF will never be interested in
> preventing others
> > from using its software, we can remove the stuff that says
> ".. and ISOC
> > will not utilize or access. without the written consent
> of the IAD".
> > Jorge - see any problems with removing this?
>
> JLC> No problem.
>
> > We should perhaps ask Jorge to modify his words to ensure
> that they don't
> > preclude IASA from using or contributing to open source software
>
> JLC> I had tried to ensure this, but if there's something that seems
> to be a problem I'm all for fixing it!
>
> By the way, this language related primarily to IASA's rights
> in software developed for it by someone else, and didn't really
> have much to do with software developed by IASA itself. IASA/IETF
> is completely free to contribute to open source projects with software
> developed by IASA personnel, to the extent that there are any.
>
> -Original Message-
> From: Brian E Carpenter [mailto:[EMAIL PROTECTED]
> Sent: Monday, January 24, 2005 9:34 AM
> To: Harald Tveit Alvestrand
> Cc: ietf@ietf.org; Contreras, Jorge
> Subject: Re: Legal review results 1: Intellectual property
>
>
> Harald Tveit Alvestrand wrote:
> > (explicit CC to Jorge, since I'm interpreting his words)
> >
> > --On fredag, januar 21, 2005 10:49:21 -0500 Bruce Lilly
> > <[EMAIL PROTECTED]> wrote:
> >
> >> Verbosity aside, I don't believe that "sole control and
> custodianship"
> >> applies to open source software. I am not a lawyer, but
> the "Old text"
> >> seems not only more easily comprehended [I am reminded of Jonathan
> >> Swift's satirical look at lawyers in Gulliver's Travels,
> and dismayed
> >> that things haven't improved in 275 years] but seems to be
> considerably
> >> more favorable to open source software than the proposed
> "new text";
> >> the latter appears to be heavily biased towards commercial
> software.
> >
> >
> > On reading the text again, I think this text:
> >
> >> (B) If an IASA Contract provides for the creation, development or
> >> modification of any software (including, without limitation, any
> >> search tools, indexing tools and the like) ("Developed Software")
> >> then the IAD shall, whenever reasonable and practical, ensure
> >> that such contract either (a) grants ownership of such Developed
> >> Software to ISOC, or (b) grants ISOC a perpetual, irrevocable
> >> right, on behalf of IASA and IETF, to use, display, distribute,
> >> reproduce, modify and create derivatives of such Software
> >> (including, without limitation, pursuant to an open source style
> >> license). It is preferred that Developed Software be provided and
> >> licensed for IASA and IETF use in source code form.
> >> ISOC will permit IASA and its designee(s) to have sole control and
> >> custodianship of such Developed Software, and ISOC
> >> will not utilize or access such Developed Software in
> >> connection with any ISOC function other than IETF without
> >> the written consent of the IAD. The foregoing rights are
> not required
> >> in the case of off-the-shelf or other
> commercially-available software
> >> that is not developed at the expense of ISOC.
> >
> >
> > actually is OK for making software free - that would come under the
> > section that says:
> >
> >> or (b) grants ISOC a perpetual, irrevocable
> >> right, on behalf of IASA and IETF, to use, display, distribute,
> >> reproduce, modify and create derivatives of such Software
> >> (including, without limi
RE: Mud. Clear as. Re: Rough consensus? #425 3.5
Avri, the way I read Leslies text is that the IAD and IAOC darn better respond to normal queries and questions and that they also document the questions and answers in a public place. If they just frivorously ignore such questions, then it is clear that thye (IAD and IAOC) are NOT doing their job. And if anyone experiences such a thing, then they can raise it to public lists and I am sure we'll get enough community pressure to do something about it as a community (one way or another). just my 2 cents Bert > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of > [EMAIL PROTECTED] > Sent: Wednesday, January 26, 2005 14:03 > To: Harald Tveit Alvestrand > Cc: ietf@ietf.org > Subject: Re: Mud. Clear as. Re: Rough consensus? #425 3.5 > > > Hi Harald, > > On 26 jan 2005, at 02.23, Harald Tveit Alvestrand wrote: > > > Avri, > > > > --On tirsdag, januar 25, 2005 23:44:09 -0500 [EMAIL PROTECTED] wrote: > > > >> Hi Leslie, > >> > >> This formulation is still of the form that does not give the IETF > >> community a direct voice in the review and appeal > mechanisms for the > >> IAOC. > > > > I do not understand what you mean by "direct voice". Could > you explain? > > As I understand Leslie's formulation, the IAOC has no requirement to > process a review from a normal member of the IETF Community > unless that > request comes from the IAB or IESG. To my mind, this means that the > IAOC is answerable to the IAB or IESG and not directly answerable to > the IETF Community. > > When an individual IETF participant makes a review request, it may be > ignored. > If someone is unhappy at being ignored they may make a request to the > IAB or IESG for recognition. This request may be also ignored, with > the only recourse to that being an appeal of the IAB or IESG decision > to ignore their request. > > That is, it is only if someone interests the IAB or IESG in > their issue > that it forces a review. Also the only decision that can really be > appealed is the IAB or IESG handling of the request for a review not > the decision of the IAOC. I am defining that this as not > having direct > voice. > > > > > > If what you mean is that the community should have representatives > > involved in the consideration of the issues, and do not > think that the > > nomcom-selected members, the IESG-selected members and the > > IAB-selected members of the IAOC are appropriate community > > representation, I do not see any mechanism short of the way we > > constitute recall committees that will give you what you want. > > My issue is not with how the members are appointed to the IAOC. I am > fine with that. My issue is whether they are accountable to the > community or the community's representatives. As written they are > accountable only to the the community's representatives and are thus > one step removed from direct accountability to the community. > > > > > If you think that the community should have the right of complaint, > > then I think you need to accept some limitation by human > judgment on > > how much effort each complaint can cause. > > I have not seen any argument that convinces me that those > limits should > be any different then the limits to judgment that currently exist to > complaints, i.e. appeals, against the IAB or IESG. I am basically > using the 'running code' argument and asking that the appeal > process we > currently have be extended to this new IETF management group. > > > > If that judgment is to lie outside of the IAOC, it has to > be invoked > > for all complaints to the IAOC (making the system more > formalistic); > > if it is inside the IAOC, it seems reasonable to have some means of > > overriding it. > > > >> I, personally see not reason why the IAOC is not directly > addressable > >> by > >> the community and does not have a direct obligation to the IETF > >> community. While I am comfortable with the IESG and IAB being the > >> appeal > >> path for the IAOC, I am not comfortable with them being a > firewall for > >> the IAOC. > > > > I do have a problem with seeing the words that Leslie proposed as > > fitting your description. As described, it isn't a firewall > - it's an > > override of a safeguard. > > A firewall protects. As written the IESG or IAB protects the > IAOC from > the IETF community, which to some extent is being assumed to be a > sometimes malicious DOS'in
RE: Issue #788: Section 3 - Which functions should be done "in-ho use" , ...
Rob my co-editor even improved the text somehwat for better readability and clarity.So it now is: The IAOC determines what IETF administrative functions are to be performed, and how or where they should be performed (whether internally within the IASA or by outside organizations), so as to maintain an optimal balance of functional performance and cost of each such function. The IAOC should document all such decisions, and the justification for them, for review by the community. Each function should be reviewed on a regular basis, using the assumption that, absent such justification, the function is either unnecessary or, if necessary, it is overstaffed, rather than using an assumption that anything which has been done in the past is still necessary; each function should be adjusted as needed given the result of this review. The IAD is responsible for negotiating and maintaining contracts or equivalent instruments with outside organizations, as well as providing any coordination necessary to make sure the IETF administrative support functions are covered properly. All functions, whether contracted to outside organizations or performed internally within the IASA, must be clearly specified and documented with well-defined deliverables, service level agreements, and transparent accounting for the cost of such functions. Bert > -Original Message- > From: Brian E Carpenter [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 26, 2005 11:25 > To: Wijnen, Bert (Bert) > Cc: John C Klensin; Rob Austein; ietf@ietf.org > Subject: Re: Issue #788: Section 3 - Which functions should be done > "in-house" , ... > > > Wijnen, Bert (Bert) wrote: > > I now have this text: > > > > > >The IAOC is expected to determine what IETF > >administrative functions are to be > performed, and how or > >where they should be performed (e.g., > internally to the > >IASA or by outside organizations), so as to > maintain an > >optimal balance of functional performance and cost of > >each such function. > >The IAOC should document all such decisions, and the > >justification for them, for review by the > community. Each > >function should be reviewed on a regular > basis, using the > >assumption that the function is unnecessary > and that, if > >necessary, it is overstaffed, rather than an > assumption > >that anything that has been done is necessary, and > >adjusted as needed. > > > > > >The IAD is responsible for negotiating and > maintaining > >contracts (or equivalent instruments) with outside > >organizations as well as providing > >any coordination necessary to make sure the IETF > >administrative support functions are covered > properly. > >All functions (those contracted to outside > organizations > >as well as those performed internally in the IASA) > >must be clearly specified and documented with > >well-defined deliverables, service level agreements, > >and transparent accounting for the cost of > such functions. > > > > > > The first para is as proposed by John Klensin, the 2nd para has > > been adjusted to use same terminology as first para. > > > > It is in my edit buffer now. > > > > Is that acceptable to everyone? > > It is for me. > > Brian > ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
FW: Resolution? #787 terminology and issue 794 - naming of accou nts
Sorry, needed another sip of coffee to wake up. The final text I have is slightly different (thanks to my co-editor Rob for clarifying) than below, namely: 5.1 Cost Center Accounting Funds managed by the IASA shall be accounted for in a separate set of general ledger accounts within the IASA Cost Center. In the remainder of this document, these general ledger accounts are termed "IASA accounts". A periodic summary of the IASA accounts shall be reported in the form of standard financial statements that reflect the income, expenses, assets, and liabilities of the IASA cost center. The IAOC and ISOC shall agree upon and publish procedures for reporting and auditing of these accounts. Note that ISOC in consultation with the IAOC can decide to structure the IASA accounting differently in the future within the constraints outlined in Section 7. Bert -Original Message- From: Wijnen, Bert (Bert) Sent: Wednesday, January 26, 2005 13:25 To: Lynn St.Amour; Carl Malamud; Tom Petch; Margaret Wasserman Cc: Harald Tveit Alvestrand; Lynn DuVal; ietf@ietf.org Subject: RE: Resolution? #787 terminology and issue 794 - naming of accounts Having seen some more reactions... I think we can solve the "general Ledger Accounts" issue with a very simple addition as follows: Funds managed by IASA shall be accounted for in a separate set of general ledger accounts within the Cost Center IASA. In the remainder of this document, these general ledger accounts are termed "IASA accounts". A periodic summary of the IASA accounts shall be reported in the form of standard financial statements that reflect the income, expenses, assets, and liabilities of the IASA cost center. IAOC and ISOC shall agree upon and publish procedures for reporting and auditing of these accounts. Note that the ISOC in consultation with IAOC can determine to tructure the IASA accounting differently in the future within the constraints outlined in . It establishes the link between the ISOC terminology and at the same time it lest us (techies) not trip over the long term all the time. That is what I am putting into rev 05. OK? Bert ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Resolution? #787 terminology and issue 794 - naming of accou nts
Having seen some more reactions... I think we can solve the "general Ledger Accounts" issue with a very simple addition as follows: As discussed with ISOC, funds managed by IASA shall be accounted for in a separate set of general ledger accounts within the Cost Center IASA. In the remainder of this document, these general ledger accounts are termed "IASA accounts". A periodic summary of the IASA accounts shall be reported in the form of standard financial statements that reflect the income, expenses, assets, and liabilities of the IASA cost center. IAOC and ISOC shall agree upon and publish procedures for reporting and auditing of these accounts. Note that the ISOC in consultation with IAOC can determine to tructure the IASA accounting differently in the future within the constraints outlined in . It establishes the link between the ISOC terminology and at the same time it lest us (techies) not trip over the long term all the time. That is what I am putting into rev 05. OK? Bert ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Resolution? #787 terminology - in particular "ISOC Standards Pillar"
So... not 100% sure I captured the result ciorrectly. This is what we have in rev 04: Funds managed by IASA shall be accounted for in a separate set of accounts. Separate financial reports, including a balance sheet and a profit and loss statement for IASA alone, shall be produced as directed by IAOC. IAOC and ISOC shall agree upon and publish procedures for reporting and auditing of these accounts. This is what I have in my edit buffer for revision 05 As discussed with ISOC, funds managed by IASA shall be accounted for in a separate set of accounts within the Cost Center IASA. A periodic summary of the IASA accounts shall be reported in the form of standard financial statements that reflect the income, expenses, assets, and liabilities of the IASA cost center. IAOC and ISOC shall agree upon and publish procedures for reporting and auditing of these accounts. Note that the ISOC in consultation with IAOC can determine to structure the IASA accounting differently in the future within the constraints outlined in . Is that acceptable to everyone? I have left the change to "General Ledger Accounts" out for the time being, because I am not sure we have consensus on that yet (even though ISOC prefers that terminology). Bert > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of > Margaret Wasserman > Sent: Wednesday, January 26, 2005 01:47 > To: Lynn St.Amour; Carl Malamud; Tom Petch > Cc: Harald Tveit Alvestrand; Lynn DuVal; ietf@ietf.org > Subject: Re: Resolution? #787 terminology - in particular "ISOC > Standards Pillar" > > > > Lynn's suggested text is fine with me. > > Margaret > > At 4:53 PM -0500 1/25/05, Lynn St.Amour wrote: > >Margaret, > > > >I agree with your point below but I do feel it is helpful to state > >what ISOC's intended implementation is: a Cost Center within ISOC. > >This should not override the section (principle) you quote below. > >Perhaps we can add language at the beginning of this section to > >clarify all this (or move the paragraph you quote from section 7 to > >this section). We might also add some of the other language > >proposed (see immed. below) so that the overall intent is clear > >rather than focusing on the less important detail. > > > >"...periodic summary of the IASA accounts in the form of standard > >financial statements that reflect the income, expenses, assets, and > >liabilities of that cost center." > > > >Regards, > > > >Lynn > > > > > >At 9:20 AM -0500 1/21/05, Margaret Wasserman wrote: > > > > > > > >>There is a section of the BCP that says: > >> > >> Within the constraints outlined above, all other > details of how to > >> structure this activity within ISOC (whether as a cost > center, a > >> department, or a formal subsidiary) shall be > determined by ISOC in > >> consultation with the IAOC. > >> > >>It seems inconsistent with this section to mandate elsewhere that > >>the IASA will be organized as a cost center, that we will use "cost > >>center accounting", that the financial reports will include a P&L > >>for the cost center, that we will publish the general ledger > >>accounts, etc. These are details that, IMO, the IAOC and ISOC > >>should work out (and change as needed to meet the needs of IASA and > >>the IETF community) between themselves. > > > >___ > >Ietf mailing list > >Ietf@ietf.org > >https://www1.ietf.org/mailman/listinfo/ietf > > > ___ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Discussion: #822 legal review 3: Legal advice
I ahve made the change suggested by Harald. Bert > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of > Harald Tveit Alvestrand > Sent: Tuesday, January 25, 2005 10:23 > To: ietf@ietf.org > Subject: Discussion: #822 legal review 3: Legal advice > > > The discussion of legal advice (Jorge's third point) seems to > have revealed > that there are two issues here: > > - Should legal advice be sought? That's almost too obvious to > state, but > might be worth stating anyway.. I suggest that we add to > paragraph 4 of > section 3.1, "IAD responsibilities". This used to be: > >The IAD negotiates service contracts, with input, as appropriate, >from other bodies, and with review, as appropriate, by the > IAOC. The >IAOC should establish guidelines for what level of review > is expected >based on contract type, size, cost, or duration. ISOC executes >contracts on behalf of the IASA, after whatever review > ISOC requires >to ensure that the contracts meet ISOC's legal and financial >requirements. > > This could be changed to read: > >The IAD negotiates service contracts, with input, as appropriate, >from other bodies, including legal advice, and with review, as >appropriate, by the IAOC. The >IAOC should establish guidelines for what level of review > is expected >based on contract type, size, cost, or duration. ISOC executes >contracts on behalf of the IASA, after whatever review > ISOC requires >to ensure that the contracts meet ISOC's legal and financial >requirements. > > The other point raised is whether the legal advice for IASA > needs to be > independent from ISOC's legal advice. Consideration so far > seems to be that > "sometimes this would be good, sometimes this would be > indifferent or extra > overhead - hard to codify in this BCP". > > Should we leave that as "no change proposed"? > > Harald > > > > ___ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Legal review 2: Trademarks
> Brian E Carpenter writes: > > Harald Tveit Alvestrand wrote: > > Suggestion: Add to section 3, one paragraph before section 3.1: > > > > The IASA is responsible for undertaking any and all required actions > > that involve trademarks on behalf of the IETF. > > Works for me sfm too, and for now I have added that txt in my edit buffer Bert > Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Confidentiality obligations (Re: Legal review 4: Minor editor ial)
Changed In addition, key contract material and MOUs shall also be publicly available, subject to any reasonable confidentiality obligations approved by the IAD. into In addition, key contract material and MOUs shall also be publicly available, subject to any reasonable confidentiality obligations approved by the IAOC. That is what I understood from this discussion. Bert > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of > John C Klensin > Sent: Monday, January 24, 2005 15:17 > To: Harald Tveit Alvestrand; ietf@ietf.org > Subject: Re: Confidentiality obligations (Re: Legal review 4: Minor > editorial) > > > > > --On Monday, 24 January, 2005 08:23 +0100 Harald Tveit > Alvestrand <[EMAIL PROTECTED]> wrote: > > >>> 7 (Transparency): While I understand the desire for > >>> transparency, there may be some contracts that contain items > >>> that are justifiably > >>> treated as confidential (such as individual performance > >>> rewards, > >>> terms of settlement of litigation). To address this point, I > >>> might add the following words at the end of the penultimate > >>> sentence: > >>> ", subject to any reasonable confidentiality obligations > >>> approved > >>> by the IAD." > >> > >> Harald, given the general commitment in the community and > >> document to transparancy whenever possible, I wonder whether > >> the IAD should be empowered to do this or should, e.g., be > >> required to report the terms and nature of what > >> confidentiality obligations are being assumed to the IAOC so > >> that they can review it as appropriate. Note that I'm not > >> proposing disclosing the confidential information to them, > >> but it seems to me to be reasonable to tell them the nature > >> of what is being kept secret and why. > > > > hm. I could certainly argue that the IAOC should approve at > > least the criteria that the IAD uses to determine that some > > confidentiality is "OK", and could also argue that the IAOC, > > being IASA oversight, ought to be able to look at all the > > "confidential" parts of things if it needed to. > > > > We could move the approval up to the IAOC with no loss in > > confidentiality, and with some gain in > > transparency/accountability, I think. > > That would certainly be consistent with what I was suggesting. > > john > > > ___ > 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
