Re: Uneccesary slowness.
Bill, the thing that can create unbounded delay on RFC publication is a normative reference to work in progress. But apart from that, it's dangerous to generalize. For many years, the RFC Editor has only had complete discretion for non-IETF documents (for which there is now a 4 week timeout on the IESG review, see RFC 3932). Brian Bill Manning wrote: perhaps but i think (based on personal experience w/ the discover draft first submitted in 1998 - still in process) that the reason for the increased slowness in getting documents through the RFC Editor is the extra-ordinary burden placed on the RFC editor staff to coordinate w/ and through the IETF's IAB/IESG functions and the creation of onerous objective checks that must be done before the RFC editor can proceed with document publication. Historically, the RFC editor had broad subjective power to publish or not - since the community then trusted the technical grounding of the RFC editor. The Editor has not changed - the community has lost trust in the RFC editor to do the proper/correct thing and tries to second-guess the RFC editor at every step of the way... which is the real reason for the extra-long time it takes to get a document published. IMHO, if the RFC editor was given the same latitude it had in 1997, publication would take weeks, not months or years. of course YMMV. --bill On May 15, 2005, at 4:55, Brian E Carpenter wrote: This would be a good topic for the newtrk WG, I think, since it is so specific. Brian James M. Polk wrote: At 08:22 PM 5/14/2005 -0400, Will McAfee wrote: I think the minimum time before a document can pass to another standards-track state is ridiculously long. If an rfc is huge, I can understand that. But to sweep that over all of them? A two-page proposed standard can take an absolutely ridiculous amount of time to pass through! each of the normative references need to be at that higher level too though... even for your 2 page PS-RFC I say we have variations based on how long the document is. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf cheers, James *** Truth is not to be argued... it is to be presented. Alas, few *truths* exist without the math. ...all else is a matter of perspective ___ 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: Complaining about ADs to Nomcom (Re: Voting (again))
You've seen Danny's message with the results of asking the question in a straightforward way - 20% of IESG nominees say they would not have volunteered. Unlike Dave, I am willing to believe them. fwiw I responded Yes to Danny's question, but not without careful thought and some hesitation. Brian Dave Crocker wrote: Seems fairly easy to judge the validity of that argument to me. ASk the nomcom to ask volunteers whether they would have volunteered if their name was gonig to be made public. Collect statistics. Sam, Sorry, no. As I posted earlier, that sort of methodology relies on what survey researchers call self-report. It is very good for assessing attitudes and very bad for assessing actual behavior. For example, what you are likely to get are responses that indicate whether the people would like to have nominations be public. It does not guarantee -- and well might not even correlate with -- whether they really would run or not run, depending on the public-ness of the nomination. It is one thing to ask simple questions about simple issues. As soon as we get into something more political the psychodynamics get messy. d/ --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
publishing names (Re: Complaining (Re: Voting (again))
there have been cases where names were published by the iab or iesg, e,g, in selecting for the iaoc and the isoc bot. while i know it is probably impossible to know how many people refused to be considered because of the publication (don't remember if there was a opt-out of publication opportunity - if so it would be interesting to know how many chose it), what i would be interested in knowing is whether the I* received many comments from a wide cross section of the ietf community on those occasions. thanks a. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: New root cause problems?
Last year, Tim Simcoe, now on the faculty at the Rotman School of Management at the University of Toronto, completed a study entitled: Delays and de Jure Standards: What Caused the Slowdown in Internet Standard Setting? For those interested, here are pointers to the work (which is continuing): http://groups.haas.berkeley.edu/bpp/phd/simcoe/profile.htm http://www.rotman.utoronto.ca/strategy/research/working%20papers/Simcoe%20-%20Delays.pdf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Uneccesary slowness.
The size of an RFC has nothing whatsoever to do with its impact. It takes time for people review, test, document problems, and propose alterations. That's the point of delay and a gradual process. Anyone can give you a one page document that will break just about everything. Because its only one page doesn't mean it should be less well tested and reviewed. Nor does it mean that its somehow easier to test and review. --Dean On Sat, 14 May 2005, Will McAfee wrote: I think the minimum time before a document can pass to another standards-track state is ridiculously long. If an rfc is huge, I can understand that. But to sweep that over all of them? A two-page proposed standard can take an absolutely ridiculous amount of time to pass through! I say we have variations based on how long the document is. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaining about ADs to Nomcom (Re: Voting (again))
You've seen Danny's message with the results of asking the question in a straightforward way - 20% of IESG nominees say they would not have volunteered. Unlike Dave, I am willing to believe them. Unfortunately Brian, this has nothing to do with my personal beliefs. It has to do with decades of hard-learned methodology realities, in the field of survey research. The convenience afforded by the concept of straight-forward does not exist in survey research. To the extent that you care to consider this issue as a matter of technical knowledge, rather than personal opinion, take a look at, for example, at http://www.sysurvey.com/tips/introduction_to_survey.htm. d/ --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Uneccesary slowness., etc.
Could these two comments of yours introduce some solutions? At 10:08 16/05/2005, Brian E Carpenter wrote: Bill, the thing that can create unbounded delay on RFC publication is a normative reference to work in progress. But apart from that, it's dangerous to generalize. For many years, the RFC Editor has only had complete discretion for non-IETF documents (for which there is now a 4 week timeout on the IESG review, see RFC 3932). Does that mean that specialised SDO/TFs, meeting the IETF general values and interests, could be a better vehicle to publish RFCs for information which could be market tested; and then reinjected in the standard track if positively accepted? This would be a way to help innovation without risking derailing the IETF. At 10:52 16/05/2005, Brian E Carpenter wrote: You've seen Danny's message with the results of asking the question in a straightforward way. - 20% of IESG nominees say they would not have volunteered. Unlike Dave, I am willing to believe them. fwiw I responded Yes to Danny's question, but not without careful thought and some hesitation. Did the ietf@ietf.org see it. Question is the motivations of the No and of hesitations. Could they be a good filter of the problem the IETF meets? It is interesting that the IETF at large does not applies to itself the excellent analysis carried on WG mistakes in RFC 3774 (one is missing however: the _organisation_ of consensus by exhaustion). In particular, the IETF has no precise yearly Charter and no Road Map. jfc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaining about ADs to Nomcom (Re: Voting (again))
Playing a bit of catch-up on this thread... Alia Atlas [EMAIL PROTECTED] writes: There is a difference between having participants who are interested in providing feedback ask for a copy of the list, with a promise of confidentiality, and give feedback - versus having that information publicly available. This sounds useful to me. I think this would be useful, though I'd add that the nomcom should have discretion to ignore such requests or only respond if they believe feedback from the requesting individual would actually be valueable. I wouldn't expect the nomcom to invoke such a privilege without good reason, but I'd feel better if they had the ability to vet requests to prevent denial of service and other abuses. And as later messages suggest, the above would be consistent with the current BCP, and I see nothing wrong with someone saying I know something about this area, and would like to provide input. If the nomcom is convinced this is the case, they can certainly provide a list of some sort. I'll also note that in the past, nomcoms used to send a list of names to a set of people and ask for feedback. But, it turned out that they didn't even get feedback from some of those people. Nowadays, folk are asked if they would provide feedback (and under confidentiality rules) and only after they respond are they sent a list. I think this is a better system and I suspect that it reduces the number of people who see a list, but then don't actually send feedback to the nomcom. Jari Arkko [EMAIL PROTECTED] writes: Like Hesham, I am also aware of this argument and do not necessarily agree with it. (In fact, one could make the point that not being able to tell you have volunteered sounds a bit wimpy compared to what kind of public visibility and pressures the folks need to deal with if they are actually selected, particularly to the IESG.) I see nothing wrong with telling folk that you have volunteered, if one is so inclined. What is not appropriate, however, is relaying to others information that can only have come out of the nomcom (e.g,. who you are commenting on, who you think the short list is, etc.) Brian E Carpenter [EMAIL PROTECTED] writes: fwiw I responded Yes to Danny's question, but not without careful thought and some hesitation. Danny asked a very specific question: Would you have accepted nomination if the list of willing nominees was made public: YES or NO? Note that this question was about _this_ particular nomcom cycle, _this_ particular set of open slots, and _this_ particular situation an individual finds themself in, etc. I suspect that anyone who says they would answer yes to this question no matter what, has not actually thought through the awkward situations that can arise (or themselves been caught up within one). One common concern (and I've seen this in real life) goes something like: would you accept a nomination for IESG position X, where - the incumbent happens to be employed by the same employer as you, or - where the incumbent and you are colleages and _have_ to be able to work together after the nomcom results are out, regardless of the outcome? A good number of folk (that would make good potential ADs) simply say no, the current incumbent is doing a fine job and I won't run against them. If one believes that the nomcom should be trying hard to find the best people for the job (including possibly arm-twisting reluctant persons), the above should give pause when it comes to publishing candidate lists. Thomas ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
More pretty graphs
Based on the positive feedback from my RFC-Editor graph, I've updated some work that I started some time ago - a set of graphs, two per working group. These graphs show inter-document dependencies(*) of all I-Ds that are working group documents, and one hop forwards and back - for example, if a foowg document depends on draft-fenner-great-stuff, then the individual draft shows up, but not *that* document's dependencies. The two graphs are wgname.pdf, which includes relationships that my script could determine are not normative, and wgname-norm.pdf which does not. Sometimes when the full graph is too much, the -norm graph is still readable. It's an interesting way to see what relationships exist, and what other groups / documents may be referencing a given WG's work. http://rtg.ietf.org/~fenner/ietf/deps/viz/ Each page includes a key for what the shapes and colors mean. Feedback is welcome. Bill (*) - Of course, these dependencies are gathered programmatically, using heuristics run over Internet Drafts, looking for filenames of other drafts. This means that some dependencies are not found - e.g., references like [Ken-Arch]Kent, S., and Seo, K., Security Architecture for the Internet Protocol, RFC ???, ??? 200?. that are meant to be to an I-D are never seen in my data. (I'm not picking on IPsec or this reference format - just noting the limitations of my heuristics) The type of reference is also picked up by heuristics, looking for sections titled, e.g., Normative References. I'm happy to look at the specifics of any document that the heuristics failed on. The actual data behind the graphs can be seen in my mysql database; https://rtg.ietf.org/phpmyadmin/ user ietf password ietf database draftdep table dep ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Uneccesary slowness.
--On Monday, May 16, 2005 10:08 +0200 Brian E Carpenter [EMAIL PROTECTED] wrote: Bill, the thing that can create unbounded delay on RFC publication is a normative reference to work in progress. But apart from that, it's dangerous to generalize. For many years, the RFC Editor has only had complete discretion for non-IETF documents (for which there is now a 4 week timeout on the IESG review, see RFC 3932). Brian, Part of what I find troubling about these discussions is the disconnect between theory --or maybe aspirations would be a better term-- and practice. Let's look at complete discretion for non-IETF documents as an example. In the years between the publication of 2026 (or earlier) and that of 3932, the rules were that the IESG's review applied only to conflicts with IETF work, serious risks to the Internet, etc. By agreement between the IESG and RFC Editor, that review was conducted against a two week timeout. That timeout was extended to four weeks when it became clear that the IESG was _never_ meeting the schedule and kept needing to ask for extensions. For many documents, the main consequence of the shift from a two-week timeout to a four-week timeout is that the IESG simply ignored the deadline rather than bothering to ask for extension. And the RFC Editor, presumably out of professional courtesy and respect for the smooth functioning of the IETF, never (at least as far as I know) turned down an extension request or enforced a timeout (i.e., got tired of waiting for the IESG and just went ahead and published). In theory, 3932 changed almost nothing. The IESG asserted that it was not going to do what it had been barred from doing all along, which was holding up individual submissions (non-IETF documents) until they were rewritten to match the tastes and preferences of any AD who cared. The principle that quality control for those documents was an RFC Editor responsibility was clarified.And the four-week timeout was formalized. In practice, it changed even less. Since 3932 was published, there have been at least severa instances of discuss positions in then IESG over substantive (not conflicts with IETF work) objections, and I'm aware of at least one or two over editorial matters. The four-week cutoff is still ignored, apparently routinely, and the RFC Editor apparently does not consider it wise to take a the IESG has not responded within four weeks, so they don't have an objection position. So, much as I remain optimistic that 3932 --which, IMO and given the language in 2026 never should have been necessary-- will eventually be taken seriously by all parties, the evidence is that hasn't happened yet. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaining about ADs to Nomcom (Re: Voting (again))
In the light of this and Dave's comments, and since I used to teach people how to design survey questions so that the questions were as non-reactive as possible and the answers could be interpreted. There is nothing inherently wrong with a self-report question. We ask them all the time and normally expect truthful answers. The tricky part is understanding which questions people may not want to answer truthfully, the reasons why, and, if the person who is reluctant to answer provides _some_ answer, how either that or a pattern of non-response is likely to bias the results. For example, if one asks a large sample of 10-year-olds how old they are, the answers will, predictably, be mostly truthful: there are few incentives to lie and mistakes will tend to be nearly randomly distributed (slightly fatter tail to the younger side because of forgetting birthdays). If one asks the same question of 60 year olds, the answer pattern would probably be different, and it is important, if one is trying to interpret validity, to understand those differences and their likely impact, rather than assuming either that all population groups are the same or that all self-report answers are invalid. Coming back to the question at hand, if the nomcom asks people whether they would have accepted nominations if their names would become public, why would someone lie? And, if they did, then which way would the report be biased. I would think that people who are inclined to give incorrect answers would be more inclined to answer no problem given the community's biases about openness and unwillingness to admit that they require secrecy. Maybe I'm wrong about that, but, if I'm not, the results Danny reported would, if anything, underestimate the number of people who would not be willing to be considered if their names were public. We now return you to the regularly-scheduled religious arguments on the subject. john --On Monday, May 16, 2005 10:52 +0200 Brian E Carpenter [EMAIL PROTECTED] wrote: You've seen Danny's message with the results of asking the question in a straightforward way - 20% of IESG nominees say they would not have volunteered. Unlike Dave, I am willing to believe them. fwiw I responded Yes to Danny's question, but not without careful thought and some hesitation. Brian Dave Crocker wrote: Seems fairly easy to judge the validity of that argument to me. ASk the nomcom to ask volunteers whether they would have volunteered if their name was gonig to be made public. Collect statistics. Sam, Sorry, no. As I posted earlier, that sort of methodology relies on what survey researchers call self-report. It is very good for assessing attitudes and very bad for assessing actual behavior. For example, what you are likely to get are responses that indicate whether the people would like to have nominations be public. It does not guarantee -- and well might not even correlate with -- whether they really would run or not run, depending on the public-ness of the nomination. It is one thing to ask simple questions about simple issues. As soon as we get into something more political the psychodynamics get messy. d/ --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: What's been done [Re: Voting (again)]
(catching up) From the ICAR review team page at http://www.machshav.com/~icar/reviews/people/ one can observe that only two review requests were ever submitted, and just one of these (a request submitted by me) resulted in a review (by Bernard). The other requested review, actually on Dave Crocker's list, is still pending. This is not quite true. There were a *few* others that I tried to get reviews for, but never got them into the system as pending. That is my mistake. But, the sample size is small. We found it quite hard to get documents people were interested in having reviewed. I don't think we can say all that much about the reviewers themselves. They were not exercised all that much. allman pgpu9gZOSOd2n.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaining about ADs to Nomcom (Re: Voting (again))
You've seen Danny's message with the results of asking the question in a straightforward way - 20% of IESG nominees say they would not have volunteered. It's not my intent to develop BCP text on ietf@ietf.org, but I do feel the need to say that we've had a previous suggestion that we could ask people if it's OK that their names be published and respect both yes and no answers. Could the 20 percent who wish to remain anonymous do so without the 80 percent also having to be anonymous to the community (modulo IESG and IAB members who are currently serving the community)? Spencer ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: More pretty graphs
Bill, thank you for developing this tool and for posting the note about it to [EMAIL PROTECTED] Spencer - Original Message - From: Bill Fenner [EMAIL PROTECTED] Based on the positive feedback from my RFC-Editor graph, I've updated some work that I started some time ago - a set of graphs, two per working group. These graphs show inter-document dependencies(*) of all I-Ds that are working group documents, and one hop forwards and back - for example, if a foowg document depends on draft-fenner-great-stuff, then the individual draft shows up, but not *that* document's dependencies. The two graphs are wgname.pdf, which includes relationships that my script could determine are not normative, and wgname-norm.pdf which does not. Sometimes when the full graph is too much, the -norm graph is still readable. It's an interesting way to see what relationships exist, and what other groups / documents may be referencing a given WG's work. http://rtg.ietf.org/~fenner/ietf/deps/viz/ Each page includes a key for what the shapes and colors mean. Feedback is welcome. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaining about ADs to Nomcom (Re: Voting (again))
Coming back to the question at hand, if the nomcom asks people whether they would have accepted nominations if their names would become public, why would someone lie? And, if they did, then which way would the report be biased. I would think that people who are inclined to give incorrect answers would be more inclined to answer no problem given the community's biases It is to a candidate's advantage to limit the amount of information provided to the nomcom, since the more obscure sources are more likely to have negative feedback about the candidate. In any event, this is less a question of lieing and more a question of preference. The question that was asked more than likely elicited a response to tell us if you strongly prefer to have nominations be kept secret. The interviewees had no cost in giving the answer. They are not held to their responses. Hence their answer is about preferences, not guarantees that they will not run. What is most fascinating about this sequence is the apparent belief that those participating in a political process do not try to game it. d/ d/ --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Last Call: 'Entity State MIB' to Proposed Standard
The IESG has received a request from the Entity MIB WG to consider the following document: - 'Entity State MIB ' draft-ietf-entmib-state-07.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-05-30. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-entmib-state-07.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'High Level Requirements for Tightly Coupled SIP Conferencing' to Informational RFC
The IESG has approved the following document: - 'High Level Requirements for Tightly Coupled SIP Conferencing ' draft-ietf-sipping-conferencing-requirements-01.txt as an Informational RFC This document is the product of the Session Initiation Proposal Investigation Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. The WG Chair shepherd for this document was Gonzalo Camarillo. Notes to the RFC Editor Add to the end of Section 1 a paragraph that that states The terms MAY, SHOULD and MUST are used as defined in [1]. Section 3.1 Expand AOR to Address of Record Section 3.1 and Section 3.4, change the phrase we feel to there is consensus that. Section 4 OLD: Normal SIP mechanisms including Digest authentication and certificates can be used. NEW: Normal SIP mechanisms including Digest authentication and certificates can be used [2]. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
BCP 104, RFC 4084 on Terminology for Describing Internet Connectivity
A new Request for Comments is now available in online RFC libraries. BCP 104 RFC 4084 Title: Terminology for Describing Internet Connectivity Author(s): J. Klensin Status: Best Current Practice Date: May 2005 Mailbox:[EMAIL PROTECTED] Pages: 11 Characters: 24522 SeeAlso:BCP 104 I-D Tag:draft-klensin-ip-service-terms-04.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc4084.txt As the Internet has evolved, many types of arrangements have been advertised and sold as Internet connectivity. Because these may differ significantly in the capabilities they offer, the range of options, and the lack of any standard terminology, the effort to distinguish between these services has caused considerable consumer confusion. This document provides a list of terms and definitions that may be helpful to providers, consumers, and, potentially, regulators in clarifying the type and character of services being offered. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ftp://ftp.isi.edu/in-notes/rfc4084.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'The TLS Protocol Version 1.1' to Proposed Standard
The IESG has received a request from the Transport Layer Security WG to consider the following document: - 'The TLS Protocol Version 1.1 ' draft-ietf-tls-rfc2246-bis-10.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-05-30. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc2246-bis-10.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'MPLS/BGP Layer 3 Virtual Private Network Management Information Base' to Proposed Standard
The IESG has approved the following document:
- 'MPLS/BGP Layer 3 Virtual Private Network Management Information Base '
draft-ietf-l3vpn-mpls-vpn-mib-07.txt as a Proposed Standard
This document is the product of the Layer 3 Virtual Private Networks Working
Group.
The IESG contact persons are Mark Townsley and Margaret Wasserman.
Technical Summary
This memo defines an portion of the Management Information Base (MIB) for use
with network management protocols in the Internet community. In particular, it
describes managed objects to configure and/or monitor Multi-protocol Label
Switching Layer-3 Virtual Private Networks on a Multi-Protocol Label Switching
(MPLS) Label Switching Router (LSR) supporting this feature.
Working Group Summary (From Ron Bonica)
Around this time last year (April 2004) there was significant contraversy
regarding one particular item in the VPN MIB. See the thread
draft-ietf-l3vpn-mpls-vpn-mib drop counter in the (l3vpn mailing list)
archive. This issue was resolved in early summer (2004) and there has been
general consensus since then.
Protocol Quality
This document was reviewed by (MIB Doctor) Bert Wijnen and Mark Townsley.
RFC Editor Note:
There are 3 items that the IESG requests the RFC Editor to correct before
publication of this document.
1. In section 18, please change:
'Each of the following IANA Considerations subsections requests'
to:
'The following subsection requests'
2. Note that the in the text below is not an the actual number, it is a
number that needs to be assigned by IANA. It would have been much better to
have or here, but that is not case this time.
MIB OID assignment of:
::= { mplsStdMIB } -- assigned by IANA, see section
18.1 for details
3. Please make the various references consistent with respect to hyphen usage
as in the example below:
The MODULE is named: MPLS-L3VPN-STD-MIB
And then in the one MODULE-COMPLIANCE he speaks of L3 MPLS VPN MIB
and in the 2nd MODULE-COMPLIANCE he speaks of L3-MPLS-VPN-STD-MIB
which is inconsistent and confusing.
___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Definition of Textual Conventions for Virtual Private Network (VPN) Management' to Proposed Standard
The IESG has approved the following document: - 'Definition of Textual Conventions for Virtual Private Network (VPN) Management ' draft-ietf-l3vpn-tc-mib-06.txt as a Proposed Standard This document is the product of the Layer 3 Virtual Private Networks Working Group. The IESG contact persons are Mark Townsley and Margaret Wasserman. Technical Summary This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines Textual Conventions used in VPNs and IETF VPN-related MIBs. Working Group Summary Chairs reported no controversy in WG at all. Protocol Quality This document has been reviewed by Bert Wijnen (MIB Doctor) and Mark Townsley. RFC Editor Note: 1. Please make the reference to RFC 2685 normative rather than informative. 2. There are no page numbers in the ToC 3. Please use the following text for Section 4, Security Considerations: This module does not define any management objects. Instead, it defines a set of textual conventions which may be used by other MIB modules to define management objects. Meaningful security considerations can only be written in the MIB modules that define management objects. This document has therefore no impact on the security of the Internet. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP)' to Proposed Standard
The IESG has approved the following document: - 'Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP) ' draft-mrose-rfc3288bis-02.txt as a Proposed Standard This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Scott Hollenbeck. Technical Summary This memo specifies a Simple Object Access Protocol (SOAP) binding to the Blocks Extensible Exchange Protocol core (BEEP). A SOAP binding describes how SOAP messages are transmitted in the network. The SOAP is an XML-based (extensible markup language) messaging protocol used to implement a wide variety of distributed messaging models. It defines a message format and describes a variety of message patterns, including, but not limited to, RPC, asynchronous event notification, unacknowledged messages, and forwarding via SOAP intermediaries. If approved, this document obsoletes RFC 3288. Working Group Summary This document is the work of individual submitters. It was subjected to a 4-week IETF last call. Last call comments were addressed prior to IESG review. Protocol Quality Scott Hollenbeck has reviewed this specification for the IESG. RFC Editor Note In section 6.1.1, please change IP address 10.0.0.2 to 192.0.2.0 to conform to the conventions described in RFC 3330. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Multicast Router Discovery' to Proposed Standard
The IESG has approved the following document: - 'Multicast Router Discovery ' draft-ietf-magma-mrdisc-07.txt as a Proposed Standard This document is the product of the Multicast Anycast Group Membership Working Group. The IESG contact persons are Margaret Wasserman and Mark Townsley. Technical Summary The concept of Internet Group Membership Protocol (IGMP) and Multicast Listener Discovery (MLD) snooping requires the ability to identify the location of multicast routers. Since snooping is not standardized, there are many mechanisms in use to identify the multicast routers. However, this can lead to interoperability issues between multicast routers and snooping switches from different vendors. This document introduces a general mechanism that allows for the discovery of multicast routers. This new mechanism, Multicast Router Discovery (MRD), introduces a standardized means of identifying multicast routers without a dependency on particular multicast routing protocols. Working Group Summary The working group strongly supports the advancement of the Multicast Router Discovery draft. Protocol Quality There were review comments for this document during WG discussion in both IDMP and MAGMA and clarification comments during WG last call. This document was reviewed for the IESG by Margaret Wasserman. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
