Re: [Payload] Last Call: draft-ietf-payload-rfc3189bis-02.txt (RTP Payload Format for DV (IEC 61834) Video)) to Proposed Standard
Hi, I have just read this document and have some minor comments, hope it is not late to be taken into account. 1. Section 1: [Qin]: It looks this version extends RFC3189 to support some new features. However I can not see any dependency to RFC3189 in the introduction section until I read the last section in this document, is it more straigtforward and clear to merge the section 7,8 to the introduction section and clarify how this document is different from RFC3189. 2. Section 3.1.1 3.1.1. Media Type Registration for DV Video Type name: video Subtype name: DV Required parameters: encode: type of DV format. Permissible values for encode are SD-VCR/525-60, SD-VCR/625-50, HD-VCR/1125-60, HD-VCR/1250-50, SDL-VCR/525-60, SDL-VCR/625-50, 314M-25/525-60, 314M-25/625-50, 314M-50/525-60, 314M-50/625-50, 370M/1080-60i, 370M/1080-50i, 370M/720-60p, 370M/720-50p, 306M/525-60 (for backward compatibility), and 306M/625-50 (for backward compatibility). [Qin]: In section 7, you claim you have removed SMPTE 306M, since it is covered by SMPTE 314M format. However in section 3.1.2, the value for SMPTE 306M is still kept in the encode list. So the question is where do you remove SMPTE 306M in this document? Why SMPTE 306M in the media type registration is still kept? Does this conflict with what you said in the section 7? The same comment applies in any place of this document where SMPTE 306M is still kept. 3. Section 3.1.1 Optional parameters: audio: whether the DV stream includes audio data or not. Permissible values for audio are bundled and none. Defaults to none. Encoding considerations: DV video can be transmitted with RTP as specified in RFC (This document). Other transport methods are not specified. Security considerations: See Section 4 of RFC (This document). Interoperability considerations: NONE [Qin]: Is it real that there is no interoperability consideration since Interoperability with Previous Implementations is discussed in the section 8 of this document? 4. Section 3.2.1 Note that the examples in RFC3189 (older version of this document) provides incorrect SDP a=fmtp attribute usage. [Qin]: I believe it is not appropriate to spell this note out when this document is published but you may put it as errata or in the section 7. 5. Section 3.2.1 The required parameter DV-video encoding specifies which type of DV format is used. The DV format name will be one of the following: SD-VCR/525-60 SD-VCR/625-50 HD-VCR/1125-60 HD-VCR/1250-50 SDL-VCR/525-60 SDL-VCR/625-50 314M-25/525-60 314M-25/625-50 314M-50/525-60 314M-50/625-50 370M/1080-60i 370M/1080-50i 370M/720-60p 370M/720-50p 306M/525-60 (for backward compatibility) 306M/625-50 (for backward compatibility) [Qin]: Why you need to repeat the same text in the section 3.1, why not just simply reference it described in the section 3.1. 6. Section 3.2.1 In order to show whether the audio data is bundled into the DV stream or not, a format specific parameter is defined as below: [Qin]: s/ a format specifc parameter/ a format of specific parameter 7. Section 3.2.1 The optional parameter audio bundled will be one of the following: [Qin] s/one of the following/one of the following value. One question is: How do you distinguish between required parameter or optional parameter in the a=fmtp line? 8. Section 3.2.2 3.2.2. Usage with the SDP Offer/Answer Model The following considerations apply when using SDP offer-answer procedures [RFC3264] to negotiate the use of DV payload in RTP: o The encode parameter can be used for sendrecv, sendonly and recvonly streams. Each encode type MUST use a separate payload type number. [Qin]: When you are talking about encode, you are using encoding type,DV-video encoding, type of DV format in the section 3.2, and using encode type in section 3.2.2, should they be the same thing? why not use the same terminology for consistency? 9. Section 3.2.2 In an offer for unbundled streams, in order to associate the related audio and video, the group attribute as defined in the Session Description Protocol (SDP) Grouping Framework [RFC5888] can be used. [Qin]: Does it worth a exmaple to expain how SDP Grouping Framework can be used to correlate audio with video data in the section 3.3.1? 10. Section 3.3.1 When this is done, SDP carries several m=?? lines, one for each media type of the session (see RFC 4566). [Qin]: What do you mean when this is done? It is not clear to me from the context. Regards! -Qin - Original Message - From: The IESG iesg-secret...@ietf.orgTo: IETF-Announce
Re: Trust membership [Re: IAOC: delegating ex-officio responsibility]
On 20/09/2011 00:30, Brian E Carpenter wrote: [...] the I* Chairs would remain as Trustees. Since that is (in my experience) a large part of an IAOC member's time commitment, the problem you're trying to solve would not be solved, IMHO, unless the Trust amended the Trust Agreement too. That's all I wanted to point out. My experience is different: the Trust is little work on average but there are huge spikes, in particular when legal provisions are being discussed. However, there are issues that are typically also discussed in the IESG or IAB, the I* chairs are already involved with their I* hat, and the additional workload to discuss it in the Trust is small. Henk -- -- Henk Uijterwaal Email: henk(at)uijterwaal.nl http://www.uijterwaal.nl Phone: +31.6.55861746 -- There appears to have been a collective retreat from reality that day. (John Glanfield, on an engineering project) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAOC: delegating ex-officio responsibility
Thanks Bob, I appreciate your thoughts on the matter! Dear Colleagues, Based on the discussion I've updated the draft: http://tools.ietf.org/html/draft-kolkman-iasa-ex-officio-membership Essentially I incorporated Dave Crocker's proposal to 1) replace the 'chairs' by voting members appointed by the respective bodies. 2) allow the chairs to participate in all meetings and provide (unsolicited) advice. There were many comments on your earlier draft and I don't see how these changes resolve all of issues raised. The new draft is different, but I think the main issues remain. Could you show how the issues raised are solved by the current draft? For example, there seemed to me to be a rough consensus in the discussion on the earlier draft that the IETF Chair should not be included in the proposal. Why did you not remove the IETF chair from the proposal? I did not see that rough consensus, but let us not argue that, I believe it is up for Jari to say were the consensus is. To the substance of that point: there is an argument to be made that if the IETF Chair has full voting power than the IAB chair should so to. I believe that it is beneficial for the organization if there is some symmetry there. For completeness, and in relation to that symmetry argument. Jari wrote in another mail: And if the chairs have to be voting members in IAOC, why aren't they voting members in IAB and IESG? The IETF Chair is voting (full) member of the IAB (see section 1.1 of RFC 2850) The IAB Chair is ex-officio member of the IESG (see RFC3710 section 2) but for Decision making the IAB chair is excluded from the consensus process (RFC3710 section 3.1 2nd paragraph). The obvious reason for that is that the IAB is in the appeal chain. I believe that allows chairs to exercise their responsibilities of keeping a coherent perspective of the organization an allow them to steer outcomes if needed, but doesn't require the day-to-day involvement that is required from a diligent voting member. As I said earlier, I continue to think this is a bad idea. We now have a system that works well. Certainly not perfect, but I am concerned your proposed changes will make it work worse. At some point I'd be perfectly happy to agree to disagree on the merit of the idea. But I want to understand the motivation and make sure there is nothing actionable on my side. In my time as IAOC chair, the I* chairs have been actively involved in the most significant decisions the IAOC makes, they tend to be less active in many of the day to day operational issues. For example, there are weekly calls in the months before an IETF meeting that the host, NOC team, IAD, host, and other people attend. I don't think an I* chair has been involved at this level. Also, the IAOC has several subcommittees (e.g., meetings, budget, specific RFPs, and Tools). I* chair attendance in these varies. The IETF chair is very active in the RFP subcommittee and Tools. The ISOC chair has reduced her attendance in the subcommittees. There is no requirement that members of committees are IAOC members, is there? I think the I* chairs bring a broad view of the community and operational needs based on what's involved in doing their jobs than other appointees would not have. In order for the I* chairs to be effective, they will need to be involved. If they are involved, then they might as well be voting members. With the changes you propose we could end up with an IAOC that none of the I* chairs participate. As you point out, they are all busy and will have a hard time to following the issues if their involvement is optional. This will result in an IAOC that is disconnected from the community. I do not buy that argument. If the I* chairs are vital for the connect with the community we have a different problem. It is important for the I* chairs to be connected with the community. It is important for the IAOC to be connected with the community. It is important for the I* chairs to be informed about what is happening in the IAOC It is important for the IAOC to be informed about what the I* chairs find important. I think it's very important for the I* chairs to share the responsibility for IAOC decisions by being voting members. Why? Same for the IETF Trust, your proposal would result in the I* chairs not being members of the IETF Trust (unless the Trust was changed, another issue in itself). The current structure with the I* chairs being voting members of the IAOC has worked well. The I* members are involved in the important decisions, share the responsibility for the decisions, and keep the IAOC/IASA connected to the community. I am sympathetic to the issue this draft is attempting to resolve, but I think there are better ways to reduce the load we put on the I* chairs, than what this draft proposes. It would help if you would
Re: Trust membership [Re: IAOC: delegating ex-officio responsibility]
--On Monday, September 19, 2011 17:58 -0500 Jorge Contreras cntre...@gmail.com wrote: ... Brian's interpretation is correct. If someone is an IAOC member, voting or not, then he/she is a Trustee with full fiduciary duties. To change this, the Trust Agreement would need to be amended. Once again, the provisions that make amending the Trust Agreement particularly problematic have expired. Let's figure out what the Right Thing is to do from the standpoint of the IETF and the community, then figure out what needs to be fixed up and and fix it. Making decisions on the basis of, e.g., not modifying the Trust Agreement, even when contrary decisions are in the best interests of the IETF and the broader community would violate the fundamental requirements that the IASA and, insofar as it is separate, the Trust, serve the best interests of the IETF and the Community. Regardless of what is said about fiduciary duties, I believe that if the Trust or its membership ever start to believe that the Trust has interests separate from the interests of the IETF (including that make the Internet work better goal) and an obligation to favor those Trust interests over the IETF one, then we would have a really serious problem in need of fixing. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Wikis for RFCs
On 9/19/11 10:14 AM, Alejandro Acosta wrote: I think that if some people support the idea, they can easily create a wiki somewhere (e.g., specsannotated.com) and get to work. On Sep 16, 2011, at 1:06 PM, Paul Hoffman wrote: Wikipedia is about the only example of working volunteer moderation, and even then, there are cabals that supported by the paid management. Few, if any, of the unmanaged wiki sites have long-lasting value. Is there any reason we can't create this on wikipedia itself, e.g.: http://en.wikipedia.org/wiki/RFC3514 We can make use of all the wikipedia governance mechanisms. It would be independent of the IETF, but it would be a well-known place to go for somewhat-moderated explication of the nuances of important RFC's. -- Nathaniel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Trust membership [Re: IAOC: delegating ex-officio responsibility]
Dear Brian, Olaf; On Mon, Sep 19, 2011 at 6:30 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: On 2011-09-19 20:05, Olaf Kolkman wrote: snip Also, the new section 2.3, which is incorrectly titled but presumably is intended to be IETF Trust membership seems to me to be inconsistent with the Trust Agreement. The Trust Agreement states that the Eligible Persons (to become Trustees) are each a then-current member of the IAOC, duly appointed and in good standing in accordance with the procedures of the IAOC established pursuant to IETF document BCP 101 [as amended]. That doesn't exclude the non-voting members of the IAOC, which is why the IAD is already a Trustee. To change this, the Trust would have to change the Trust Agreement. To be clear, I'm not saying this can't be done, but it can't be ignored either. Yes, it is incorrectly titled. As far as I understand the trust agreement the voting members and the IAD are members of the trust. If the 'chairs' are non-voting members of the IAOC then the idea is that they would not be trustees and a modification of the trust agreement is not needed. That can be clarified. If the chairs should be trustees (are you arguing that?) then I agree, a trust agreement modification is needed. The Trust Agreement and *only* the Trust Agreement defines who is a Trustee. At the moment it says that members of the IAOC under BCP 101 are Trustees, without any qualification such as voting. The Trust Agreement is at http://iaoc.ietf.org/docs/IETF-Trust-Agreement-Executed-12-15-05.pdf It says (Section 3.1) that Eligible persons are those IAOC members duly appointed and in good standing in accordance with the procedures of the IAOC established pursuant to IETF document BCP 101, RFC 4071 (April 2005), and any duly approved successor documents, updates, or amendments thereto. The draft says This document updates BCP101 http://tools.ietf.org/html/bcp101 ([RFC4071 http://tools.ietf.org/html/rfc4071] and [RFC4371 http://tools.ietf.org/html/rfc4371]). Assuming it goes forward, it would thus eventually become an update or amendment to BCP101, and so by just changing who the IAOC members are, and thus who the Trustees are, would NOT IMO require a change to the Trust Agreement. It would be automatic. All Trustees are currently voting trustees. I would note that the ISOC Board of Trustees has at least one non-voting Trustee, and the Trust Amendment could in theory be modified in a similar fashion. (Modifying the TA can now be done with a majority vote of the Trustees currently in office.) However, the Trust Agreement (TA) is a legal document. I would not underrate the difficulty (and legal expense) of modifying it, and of not introducing bugs while modifying it. Even though the Trustees _can_ now do this, I would not actually do it if avoidable, and I think that it is in this case. Note that the Trust Agreement says almost nothing about meetings. The Trust Administrative Procedures (TAP) could easily be modified to allow for permanent Ex-Officio liaisons, and the TAP is not a legal document of the same standing as the TA. So, what I would recommend is that - Olaf's draft create new IAOC members with full powers, as it currently does. These would, assuming the draft progresses, automatically become Trustees, without any modification of the Trust Agreement. - Olaf's wording be changed to make the IAB Chair, IETF Chair and ISOC CEO into ex-officio and non-voting Liaisons to the IAOC and the Trust. - The TAP then be modified to recognize the status of these new ex-officio and non-voting Liaisons. These Liaisons are not IAOC members, thus not Trustees. With this procedure, I see no reason to modify the Trust Agreement. Regards Marshall So if we make the I* Chairs non-voting members of the IAOC by formally updating BCP 101, the I* Chairs would remain as Trustees. Since that is (in my experience) a large part of an IAOC member's time commitment, the problem you're trying to solve would not be solved, IMHO, unless the Trust amended the Trust Agreement too. That's all I wanted to point out. 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
Fwd: [81all] Quick Meeting Survey
Hi, all, Please consider responding to the following survey, even if you did NOT attend*. Joe *- The following survey includes the opportunity to indicate did not attend, and to explain why. It was originally sent to the 81all list, which is a bit preaching to the choir (though it included those who pre-registered and didn't attend). This has been forwarded to the main list in the hopes that *everyone* who wants to will have an opportunity to respond - including those who didn't attend - and why. I hope such surveys are forwarded to this list as a general rule in the future, rather than only to the attendees list. Original Message Subject: [81all] Quick Meeting Survey Date: Tue, 20 Sep 2011 07:10:03 -0400 From: Ray Pelletier rpellet...@isoc.org To: 81...@ietf.org All This is a short and anonymous survey about your IETF meeting experience generally and specifically your experience at IETF 81 in Quebec City. It will be used to make improvements at future meetings where needed (and possible). Feedback on the survey itself is welcome. The results will be shown at the end. If you want to see the results click on the arrow to see each response, do not click on Done. https://www.surveymonkey.com/s/KSKH8NP Thanks Ray ___ 81all mailing list 81...@ietf.org https://www.ietf.org/mailman/listinfo/81all ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-gundavelli-v6ops-pmipv6-address-reservations-00.txt (Reserved IPv6 Interface Identifier for Proxy Mobile IPv6) to Informational RFC
Hi Jari: In case of PMIPv6, we need the interface ID allocation for PMIv6 domain-wide usage. We may not be able tie this to a specific EUI-64 identifier derived from a MAC identifier of any individual MAG hosting this configuration. But, if your recommendation is to tie the IPv6 interface identifier to the reserved link-layer identifier (the other IANA action), that should be fine. But, the reserved block that Suresh has in his spec is not tied to any EUI-64 block ? That implies, we need an interface ID allocation from a new block ? Or, recommend the node to generate the interface ID based on the reserved Mac address and not allocate from the block Suresh created ? Hope, I'm not missing the point. Regards Sri On 9/18/11 11:35 PM, Jari Arkko jari.ar...@piuha.net wrote: Following up with a personal comment. The draft allocates an interface ID and an EUI-64 MAC identifier from the IANA block. These are two separate, unrelated allocations. The main criticism in RFC 5453 for making additional interface ID allocations is that old implementations do not know about them and may collide when making an allocation. I'm wondering if it would be better to allocate an interface ID that is based on the allocated EUI-64 identifier per RFC 2464? Then we would at least use the same format as other interface IDs and a collision would likely mean inappropriate use of the IANA EUI-64 identifiers. Note that privacy and cryptographic addresses set the u/l bit to zero, whereas EUI-64 interface IDs usually have it at one. Sri's draft is silent on what kind of number should be allocated for the interface ID, perhaps some guidance here would be useful. Not that collisions are likely in 2^64 space anyway, maybe I'm worried about nothing. Jari IETF IPv6 working group mailing list i...@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fwd: [81all] Quick Meeting Survey
On 9/20/11 8:53 AM, Joe Touch wrote: Please consider responding to the following survey, even if you did NOT attend*. So, I'm looking at the results and see that -9 people skipped the birth year question. That seems kind of unlikely to me, although I suppose it's possible that some people were so enthusiastic they answered twice. Melinda ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fwd: [81all] Quick Meeting Survey
On 9/20/2011 10:09 AM, Melinda Shore wrote: On 9/20/11 8:53 AM, Joe Touch wrote: Please consider responding to the following survey, even if you did NOT attend*. So, I'm looking at the results and see that -9 people skipped the birth year question. That seems kind of unlikely to me, although I suppose it's possible that some people were so enthusiastic they answered twice. Hard to see how that adds up to a negative. I noticed that no people said they didn't come in the survey after I completed it, even though I responded otherwise. Hopefully the raw data are reported in addition to the (questionable) summaries ;-) Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fwd: [81all] Quick Meeting Survey
On Tue, Sep 20, 2011 at 1:09 PM, Melinda Shore melinda.sh...@gmail.comwrote: On 9/20/11 8:53 AM, Joe Touch wrote: Please consider responding to the following survey, even if you did NOT attend*. So, I'm looking at the results and see that -9 people skipped the birth year question. That seems kind of unlikely to me, although I suppose it's possible that some people were so enthusiastic they answered twice. Why ? Right now it says 14 skipped - 7% 182 answered - 83% I don't think having 7% non-response is that unusual, or that worrisome. By contrast, so far 19 have skipped Did you attend IETF 81 in Quebec City? which is an even easier question. Regards Marshall Melinda __**_ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/**listinfo/ietfhttps://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fwd: [81all] Quick Meeting Survey
On 9/20/11 9:20 AM, Marshall Eubanks wrote: I don't think having 7% non-response is that unusual, or that worrisome. I don't either. Here's what's unusual: answered question 176 skipped question-9 Probably not worrisome. If I had to guess I'd guess that there were some surveys in progress as the summary numbers were generated (and this is why the Goddess invented locking ... ) Melinda ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Wikis for RFCs
Hi Nathaniel, On Tue, Sep 20, 2011 at 11:12 AM, Nathaniel Borenstein n...@guppylake.comwrote: Is there any reason we can't create this on wikipedia itself, e.g.: http://en.wikipedia.org/wiki/RFC3514 The problem that I see in this case was mentioned previously by Keith and Hector, wikipedia docs may be modified by the community, the RFCs content itself should not be modified. It should be a kind of mix between blogs and wiki. We can make use of all the wikipedia governance mechanisms. It would be independent of the IETF, but it would be a well-known place to go for somewhat-moderated explication of the nuances of important RFC's. Right! -- Nathaniel Alejandro, ___ 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: Trust membership [Re: IAOC: delegating ex-officio responsibility]
On Sep 20, 2011, at 6:25 PM, Marshall Eubanks wrote: - Olaf's wording be changed to make the IAB Chair, IETF Chair and ISOC CEO into ex-officio and non-voting Liaisons to the IAOC and the Trust. - The TAP then be modified to recognize the status of these new ex-officio and non-voting Liaisons. These Liaisons are not IAOC members, thus not Trustees. I would not call them liaisons (as they do not liaise) but advisors. With this procedure, I see no reason to modify the Trust Agreement. The Trust would need to commit to allowing these advisors to join their meetings too. But that can be done in other ways than the Trust Agreement. (so yes, I agree with this line of thought) Obviously this all assumes there is a consensus for changing the I* chairs role --Olaf Olaf M. KolkmanNLnet Labs http://www.nlnetlabs.nl/ smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Trust membership [Re: IAOC: delegating ex-officio responsibility]
On Tue, Sep 20, 2011 at 1:44 PM, Olaf Kolkman o...@nlnetlabs.nl wrote: On Sep 20, 2011, at 6:25 PM, Marshall Eubanks wrote: - Olaf's wording be changed to make the IAB Chair, IETF Chair and ISOC CEO into ex-officio and non-voting Liaisons to the IAOC and the Trust. - The TAP then be modified to recognize the status of these new ex-officio and non-voting Liaisons. These Liaisons are not IAOC members, thus not Trustees. I would not call them liaisons (as they do not liaise) but advisors. WFM With this procedure, I see no reason to modify the Trust Agreement. The Trust would need to commit to allowing these advisors to join their meetings too. But that can be done in other ways than the Trust Agreement. (so yes, I agree with this line of thought) Obviously this all assumes there is a consensus for changing the I* chairs role Yes. And that should include prior agreement by the Trustees to make this change. (As with any last call, if the Trustees have objections, they should be dealt with before the RFC is published.) I would be glad to schedule such a discussion and vote at an appropriate time, assuming I am still Chair at that time. Regards Marshall --Olaf Olaf M. KolkmanNLnet Labs http://www.nlnetlabs.nl/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAOC: delegating ex-officio responsibility
Hi, I had the comments below on a previous incarnation of how to fix the IAOC because Chairs are overloaded. I have to say -- I don't think the substantive points are addressed in the new proposal, which leaves the Chairs as spectators to the IAOC process. I don't think you can disagree with me that, with no vote (recognized voice) in a committee's work, there's even less possibility to find the hours to keep up with the substance of discussions and thus be able to contribute meaningfully to a discussion when the time comes. Substantively -- this takes the Chairs off the IAOC, just as the original proposal did, and my comments/confusion/questions below are still current for me. Leslie. Original Message Subject: Re: I-D Action:draft-klensin-iaoc-member-00.txt Date: Tue, 01 Sep 2009 18:06:07 -0400 From: Leslie Daigle les...@thinkingcat.com To: IETF discussion list ietf@ietf.org CC: John C Klensin klen...@jck.com I'm having troubles reconciling a couple of things: 1/ Recent discussion (different draft) on the importance of the IAOC implementing IETF (and IAB) policy and admin requirements; not having the IAOC *setting* those requirements; 2/ Suggesting that the IAB IETF Chairs should not be on the IAOC. As it stands the IETF Chair is in a unique position to understand all the requirements of the IETF community and IETF administrative activities. There isn't someone else who can step in: all other IESG members are tasked, as a primary responsibility, with looking after their particular areas. The IAB Chair similarly sits at the confluence of all the issues hitting the IAB, and is specifically responsible for tracking them so that they get addressed by the IAB. While the IAB Chair can, in theory, delegate actions on particular topics, it at least used to be the case that some tasks are too tricky or unappealing to get other involvement(too admin, not enough architectural content). And, even with successful delegation of individual tasks, the IAB Chair retains the perspective across all the activities -- technical, IANA, RFC Editor, etc. I'm not going to disagree that the jobs are heavily loaded, and that it's a problem for the IETF that the organization relies heavily on finding a solid candidate for each of these complex positions. However, I think taking them off the IAOC is *not* the place to start. It makes more sense to me to sort out the organizational challenges (of the IESG/IETF, and of the IAB) that cause overloading of these positions, and *then* see what makes sense in terms of identifying IAOC participation. Pulling these positions off the IAOC would succeed in weakening the IAOC, even as it increases the stress levels in the positions as the respective Chairs try to figure out what is going on with the administrative support for the balls they are trying to keep moving. My $0.02cdn Leslie. On 9/19/11 4:05 AM, Olaf Kolkman wrote: Brian, So far you are the only person that has responded with substance. Other feedback was promised but never arrived. I hope to rev this document shortly so that we can finalize it before the Taiwan meeting. I wrote: Based on the discussion I've updated the draft: http://tools.ietf.org/html/draft-kolkman-iasa-ex-officio-membership Essentially I incorporated Dave Crocker's proposal to 1) replace the 'chairs' by voting members appointed by the respective bodies. 2) allow the chairs to participate in all meetings and provide (unsolicited) advice. I believe that allows chairs to exercise their responsibilities of keeping a coherent perspective of the organization an allow them to steer outcomes if needed, but doesn't require the day-to-day involvement that is required from a diligent voting member. You responded: And it therefore removes the two Chairs' shared responsibility for decisions of the IAOC and the IETF Trust. I am still far from convinced that this is a good thing. That is correct, under this proposal the chairs don't have voting responsibilities in the IAOC. And while I argue that the chairs can 'steer' as ex-officio I understand that is something you are either convinced off or not. Also, the new section 2.3, which is incorrectly titled but presumably is intended to be IETF Trust membership seems to me to be inconsistent with the Trust Agreement. The Trust Agreement states that the Eligible Persons (to become Trustees) are each a then-current member of the IAOC, duly appointed and in good standing in accordance with the procedures of the IAOC established pursuant to IETF document BCP 101 [as amended]. That doesn't exclude the non-voting members of the IAOC, which is why the IAD is already a Trustee. To change this, the Trust would have to change the Trust Agreement. To be clear, I'm not saying this can't be done, but it can't be ignored either. Yes, it is incorrectly titled. As far as I understand the trust agreement the voting members and the IAD are members of the
Re: Fwd: [81all] Quick Meeting Survey
On Tue, Sep 20, 2011 at 1:26 PM, Melinda Shore melinda.sh...@gmail.comwrote: On 9/20/11 9:20 AM, Marshall Eubanks wrote: I don't think having 7% non-response is that unusual, or that worrisome. I don't either. Here's what's unusual: answered question 176 skipped question-9 Probably not worrisome. If I had to guess I'd guess that there were some surveys in progress as the summary numbers were generated (and this is why the Goddess invented locking ... ) See http://help.surveymonkey.com/app/answers/detail/a_id/307/kw/negative%20skipped%20question/session/L3NpZC90UFAqcEFFaw%3D%3D Why are new responses shown as *skipped*in the results? Once a survey has reached 100 responses, our system updates your Analyze page's cache every 15 minutes with new responses. - When a new response is recorded during this interim period, its details will not show up immediately. - It will instead be tallied as having *skipped* the *questions* in your summary. These *skips* are a result of the system loading the saved page, but the new responses have not yet been placed into memory. They have been recorded and stored in the database, and they are not fully tabulated into the tally until after the cache update. Marshall Melinda ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAOC: delegating ex-officio responsibility
--On Tuesday, September 20, 2011 14:16 -0400 Leslie Daigle les...@thinkingcat.com wrote: Hi, I had the comments below on a previous incarnation of how to fix the IAOC because Chairs are overloaded. I have to say -- I don't think the substantive points are addressed in the new proposal, which leaves the Chairs as spectators to the IAOC process. I don't think you can disagree with me that, with no vote (recognized voice) in a committee's work, there's even less possibility to find the hours to keep up with the substance of discussions and thus be able to contribute meaningfully to a discussion when the time comes. As ex-officio non-voting members, with the main responsibility for representing IAB and IESG views and needs resting with someone else, that seems ok to me. At the same time, I think you underestimate the ability of the people involved to read in really quickly if that is necessary/ important. Substantively -- this takes the Chairs off the IAOC, just as the original proposal did, and my comments/confusion/questions below are still current for me. I think I responded to most of these in a different subthread earlier this week. The remarks below are just a quick summary. Original Message Subject: Re: I-D Action:draft-klensin-iaoc-member-00.txt Date: Tue, 01 Sep 2009 18:06:07 -0400 From: Leslie Daigle les...@thinkingcat.com To: IETF discussion list ietf@ietf.org CC: John C Klensin klen...@jck.com I'm having troubles reconciling a couple of things: 1/ Recent discussion (different draft) on the importance of the IAOC implementing IETF (and IAB) policy and admin requirements; not having the IAOC *setting* those requirements; 2/ Suggesting that the IAB IETF Chairs should not be on the IAOC. Leslie, You appear to be assuming that the proposal is somehow removing the IAB and IESG (and ISOC) representation/ presence on the IAOC and Trust. No one has suggested that. What has been suggested is that the determination of who is most able to effectively represent those bodies can sensibly be left up to them rather than assuming that the Chairs are somehow endowed with special knowledge and wisdom that no one else shares. I think it would be really stupid for the IESG, IAB, or ISOC leadership to put someone on the IAOC who wasn't thoroughly familiar with the thinking in those bodies about IASA issues and competent in the issues the IAOC and Trust address. I think we can trust those bodies to avoid being stupid (except possibly as a tradeoff against worse choices) and don't need to invent rules that ban stupidity. As it stands the IETF Chair is in a unique position to understand all the requirements of the IETF community and IETF administrative activities. There isn't someone else who can step in: all other IESG members are tasked, as a primary responsibility, with looking after their particular areas. Sometimes I feel as if the IETF Chair is tasked with doing a good Superman imitation -- understanding everything, knowing everything, leaping tall buildings... Despite my frequent role as a critic, I'm also impressed with how good a job recent incumbents have done at that. But I also think it is an unreasonable expectation along both the knowledge and time dimensions and that there are usually people on the IESG (and elsewhere) who can do parts of the job (including broad understanding and perspective) as well. I also note that nothing in any of these proposals prevents the IESG from appointing the Chair to the voting position on the IAOC if they conclude that is the best choice after all tradeoffs are considered and the Chair has the available cycles.The proposal increases flexibility; it need not actually change the membership of the IAOC even if some of us assume that it would. The IAB Chair similarly sits at the confluence of all the issues hitting the IAB, and is specifically responsible for tracking them so that they get addressed by the IAB. While the IAB Chair can, in theory, delegate actions on particular topics, it at least used to be the case that some tasks are too tricky or unappealing to get other involvement(too admin, not enough architectural content). And, even with successful delegation of individual tasks, the IAB Chair retains the perspective across all the activities -- technical, IANA, RFC Editor, etc. I can't speak for you, Olaf, or Bernard, but I just don't believe it. There are often people who have perspectives as good as the Chair. That is likely to get more differentiated over time as the Program model permits more tasks to be spread around, probably with the IAB Chair not intimately involved in some of them. Indeed, if any member of the IAB is guaranteed to have the perspective you are asking for, it would be the Exec Dir, not the Chair. ... Pulling these positions off the IAOC would succeed in weakening the IAOC, even as it increases the stress levels in the
Re: Wikis for RFCs
Is there any reason we can't create this on wikipedia itself, e.g.: http://en.wikipedia.org/wiki/RFC3514 Wikipedia is an encyclopedia, and all that is supposed to go on the main pages is encyclopedia type material, which this doesn't sound like. There's a talk page where you can have arguments, but that's not particularly well managed or archived. Setting up a mediawiki system is technically trivial, like 15 minutes' work. The hard part is managing it. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Trust membership [Re: IAOC: delegating ex-officio responsibility]
On 2011-09-21 05:44, Olaf Kolkman wrote: On Sep 20, 2011, at 6:25 PM, Marshall Eubanks wrote: - Olaf's wording be changed to make the IAB Chair, IETF Chair and ISOC CEO into ex-officio and non-voting Liaisons to the IAOC and the Trust. - The TAP then be modified to recognize the status of these new ex-officio and non-voting Liaisons. These Liaisons are not IAOC members, thus not Trustees. I would not call them liaisons (as they do not liaise) but advisors. With this procedure, I see no reason to modify the Trust Agreement. Agreed, and it would be cheaper to do it this way, but... The Trust would need to commit to allowing these advisors to join their meetings too. But that can be done in other ways than the Trust Agreement. (so yes, I agree with this line of thought) Obviously this all assumes there is a consensus for changing the I* chairs role ...exactly. I'm far from convinced about that. I think the real need is to figure out how to make the IAOC an Oversight committee rather than it getting involved in executive decisions, and to figure out how to make the IAB an Architecture board instead of getting involved in administrative matters. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Trust membership [Re: IAOC: delegating ex-officio responsibility]
Hi Brian, On 9/21/11 12:09 AM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: [snip] The Trust would need to commit to allowing these advisors to join their meetings too. But that can be done in other ways than the Trust Agreement. (so yes, I agree with this line of thought) Obviously this all assumes there is a consensus for changing the I* chairs role ...exactly. I'm far from convinced about that. I think the real need is to figure out how to make the IAOC an Oversight committee rather than it getting involved in executive decisions, and to figure out how to make the IAB an Architecture board instead of getting involved in administrative matters. I totally agree. In addition, if the people that have been given at least theoretically highest positions in the IETF leadership would not like to take the responsibility of the trust, who then would? These people are trustees in my mind as the puck of responsibility ends at them. I repeat what I said earlier, I believe the problem is real and needs to be addressed. I think it is good, Olaf, you brought it up. However, I believe this is a matter of organizing *internally* in the IAOC rather than changing the rules. Perhaps they have to hire help, or get even more of it from the ISOC. Cheers, Jonne. 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: Fwd: [81all] Quick Meeting Survey
On Tue, 20 Sep 2011 09:09:52 -0800, Melinda Shore melinda.sh...@gmail.com said: MS So, I'm looking at the results and see that -9 people skipped MS the birth year question. It was worded poorly too. It should have read: Do you have a Gray Beard? A) Yes B) No -- Wes Hardaker SPARTA, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fwd: [81all] Quick Meeting Survey
On Tue, Sep 20, 2011 at 04:03:21PM -0700, Wes Hardaker wrote: Do you have a Gray Beard? [Ob.SpelThrd] That's spelled Grey Beard! A -- Andrew Sullivan a...@anvilwalrusden.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Grey Beards (was [81all] Quick Meeting Survey)
Folks, This reminds me that it has been a while since we took the last IETF grey beard photo. A few more of us have gone grey since then. Maybe we should plan on another photo to be taken after the next Administrative Plenary. Ron -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Andrew Sullivan Sent: Tuesday, September 20, 2011 8:14 PM To: ietf@ietf.org Subject: Re: Fwd: [81all] Quick Meeting Survey On Tue, Sep 20, 2011 at 04:03:21PM -0700, Wes Hardaker wrote: Do you have a Gray Beard? [Ob.SpelThrd] That's spelled Grey Beard! A -- Andrew Sullivan a...@anvilwalrusden.com ___ 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: Grey Beards (was [81all] Quick Meeting Survey)
On 9/20/11 6:26 PM, Ronald Bonica wrote: This reminds me that it has been a while since we took the last IETF grey beard photo. A few more of us have gone grey since then. Maybe we should plan on another photo to be taken after the next Administrative Plenary. Beardless, but back when I started participating in the IETF my hair was nearly black. Now I've gone completely grey. Not trying to imply causality, of course. Count me in. Melinda ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Trust membership [Re: IAOC: delegating ex-officio responsibility]
On Sep 20, 2011, at 11:09 PM, Brian E Carpenter wrote: ...exactly. I'm far from convinced about that. I think the real need is to figure out how to make the IAOC an Oversight committee rather than it getting involved in executive decisions, and to figure out how to make the IAB an Architecture board instead of getting involved in administrative matters. On the IAB: I do not agree that the focus needs to be on the A of architecture. There is not a lot that the IAB does that is not in its charter. I believe that the focus needs to be on the B of board. In other words, just as in the IAOC more oversight. During my tenure we took a number of steps to move the handy work into programs and initiatives in which the execution of projects could take place so that the IAB members themselves could oversee but that journey was far from complete. For the IAOC and IAB these will be difficult challenges that cannot be enforced externally but also need an evolutionary culture change . Not only in the I* bodies themselves but also how the NOMCOM. --Olaf Olaf M. KolkmanNLnet Labs http://www.nlnetlabs.nl/ smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-lisp-alt-09.txt (LISP Alternative Topology (LISP+ALT)) to Experimental RFC
The IESG has received a request from the Locator/ID Separation Protocol WG (lisp) to consider the following document: - 'LISP Alternative Topology (LISP+ALT)' draft-ietf-lisp-alt-09.txt as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2011-10-04. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a simple distributed index system to be used by a Locator/ID Separation Protocol (LISP) Ingress Tunnel Router (ITR) or Map Resolver (MR) to find the Egress Tunnel Router (ETR) which holds the mapping information for a particular Endpoint Identifier (EID). The MR can then query that ETR to obtain the actual mapping information, which consists of a list of Routing Locators (RLOCs) for the EID. Termed the Alternative Logical Topology (ALT), the index is built as an overlay network on the public Internet using the Border Gateway Protocol (BGP) and the Generic Routing Encapsulation (GRE). Using these proven protocols, the ALT can be built and deployed relatively quickly without any changes to the existing routing infrastructure. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-lisp-alt/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-lisp-alt/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-mmusic-ice-tcp-15.txt (TCP Candidates with Interactive Connectivity Establishment (ICE)) to Proposed Standard
The IESG has received a request from the Multiparty Multimedia Session Control WG (mmusic) to consider the following document: - 'TCP Candidates with Interactive Connectivity Establishment (ICE)' draft-ietf-mmusic-ice-tcp-15.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2011-10-04. 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 Interactive Connectivity Establishment (ICE) defines a mechanism for NAT traversal for multimedia communication protocols based on the offer/answer model of session negotiation. ICE works by providing a set of candidate transport addresses for each media stream, which are then validated with peer-to-peer connectivity checks based on Session Traversal Utilities for NAT (STUN). ICE provides a general framework for describing candidates, but only defines UDP-based transport protocols. This specification extends ICE to TCP-based media, including the ability to offer a mix of TCP and UDP-based candidates for a single stream. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mmusic-ice-tcp/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mmusic-ice-tcp/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/798/ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-avtext-mixer-to-client-audio-level-05.txt (A Real-Time Transport Protocol (RTP) Header Extension for Mixer-to- Client Audio Level Indication) to Proposed Standard
The IESG has received a request from the Audio/Video Transport Extensions WG (avtext) to consider the following document: - 'A Real-Time Transport Protocol (RTP) Header Extension for Mixer-to- Client Audio Level Indication' draft-ietf-avtext-mixer-to-client-audio-level-05.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2011-10-04. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a mechanism for RTP-level mixers in audio conferences to deliver information about the audio level of individual participants. Such audio level indicators are transported in the same RTP packets as the audio data they pertain to. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-avtext-mixer-to-client-audio-level/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-avtext-mixer-to-client-audio-level/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-avtext-client-to-mixer-audio-level-05.txt (A Real-Time Transport Protocol (RTP) Header Extension for Client-to- Mixer Audio Level Indication) to Proposed Standard
The IESG has received a request from the Audio/Video Transport Extensions WG (avtext) to consider the following document: - 'A Real-Time Transport Protocol (RTP) Header Extension for Client-to- Mixer Audio Level Indication' draft-ietf-avtext-client-to-mixer-audio-level-05.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2011-10-04. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a mechanism by which packets of Real-Time Transport Protocol (RTP) audio streams can indicate, in an RTP header extension, the audio level of the audio sample carried in the RTP packet. In large conferences, this can reduce the load on an audio mixer or other middlebox which wants to forward only a few of the loudest audio streams, without requiring it to decode and measure every stream that is received. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-avtext-client-to-mixer-audio-level/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-avtext-client-to-mixer-audio-level/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6369 on Forwarding and Control Element Separation (ForCES) Implementation Experience
A new Request for Comments is now available in online RFC libraries. RFC 6369 Title: Forwarding and Control Element Separation (ForCES) Implementation Experience Author: E. Haleplidis, O. Koufopavlou, S. Denazis Status: Informational Stream: IETF Date: September 2011 Mailbox:eha...@ece.upatras.gr, odyss...@ece.upatras.gr, sd...@upatras.gr Pages: 18 Characters: 34236 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-haleplidis-forces-implementation-experience-03.txt URL:http://www.rfc-editor.org/rfc/rfc6369.txt The Forwarding and Control Element Separation (ForCES) protocol defines a standard communication and control mechanism through which a Control Element (CE) can control the behavior of a Forwarding Element (FE). This document captures the experience of implementing the ForCES protocol and model. Its aim is to help others by providing examples and possible strategies for implementing the ForCES protocol. This document is not an Internet Standards Track specification; it is published for informational purposes. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6370 on MPLS Transport Profile (MPLS-TP) Identifiers
A new Request for Comments is now available in online RFC libraries. RFC 6370 Title: MPLS Transport Profile (MPLS-TP) Identifiers Author: M. Bocci, G. Swallow, E. Gray Status: Standards Track Stream: IETF Date: September 2011 Mailbox:matthew.bo...@alcatel-lucent.com, swal...@cisco.com, eric.g...@ericsson.com Pages: 17 Characters: 35294 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-mpls-tp-identifiers-07.txt URL:http://www.rfc-editor.org/rfc/rfc6370.txt This document specifies an initial set of identifiers to be used in the Transport Profile of Multiprotocol Label Switching (MPLS-TP). The MPLS-TP requirements (RFC 5654) require that the elements and objects in an MPLS-TP environment are able to be configured and managed without a control plane. In such an environment, many conventions for defining identifiers are possible. This document defines identifiers for MPLS-TP management and Operations, Administration, and Maintenance (OAM) functions compatible with IP/ MPLS conventions. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. [STANDARDS-TRACK] This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
