Re: audio streaming archive...
VeriLAN is going to check this computer on Wednesday (it's currently located at a warehouse) to verify that all recordings were uploaded. We'll know more shortly. Alexa On Apr 18, 2011, at 12:03 AM, Joel Jaeggli wrote: On 4/14/11 8:22 PM, Scott Schmit wrote: On Wed, Apr 13, 2011 at 09:58:24PM -0700, Joel Jaeggli wrote: there was a naming convention issue on the channel5 recorder which I thought that we caught all of those by I could be wrong... The contractor has the channel8 recorder and should be able toretrive the file. Is there an ETA for the fix to that? you might want to talk to the secretariate or the contractor (whom I cced on the previous message) I don't have access to the equipment. I listened to both the .mp3 and .mp3.1 file for wed-am ch8, and neither sounds like the DANE session to me. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf --- Alexa Morris / Executive Director / IETF 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 Phone: +1.510.492.4089 / Fax: +1.510.492.4001 Email: amor...@amsl.com Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com http://www.amsl.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAOC: delegating ex-officio responsibility
--On Saturday, April 16, 2011 07:51 -0700 Lucy Lynch lly...@civil-tongue.net wrote: The implication is that the people sitting in the positions of IAB Chair and IETF Chair are essential to the good operation of the IAOC/Trust. Someone else from their groups or even someone else that they appoint from outside cannot perform the task of IAOC/Trust member adequately. I think this is the wrong question. I don't think this is about the people who sit on the IAOC or the Trust, it is about the roles. Their participation is part of the chain of accountability to the community. The IAOC was crafted to include both the IAB and IETF Chairs as well as the ISOC CEO in their respective roles and not as Fred, Harold, and Lynn (as members of the IETF community). Why? What are the specific contributions (insights and skills) that these roles regularly perform, in the conduct of the IAOC/Trust that cannot be performed adequately by others? see above. One more point here: as a former Chair of the IAOC (IAB appointed member from the community) I'm sympathetic the the overload arguments but I'll note that absent the IAB/IETF chairs the work of the IAOC chair and the weight put on that role may increase in unexpected ways. I agree with many of the points that Bob, Brian, Leslie, and Jari have made in earlier posts and think that we need to take a broader view of the problems we're trying to solve here. Role overload is an on-going problem but I'm not sure we solve this by moving the administrative accountability we gained through BCP 101 to additional volunteers. At the risk of agreeing violently with Dave, I think the series of comments above, and referenced above, are missing something. None of this familiy of delegation or someone else proposals requires that the IAB or IESG Chairs not serve on the IAOC. If they think that is sensible and they have the time, they are free to do that. We might even strongly encourage it. However, if those people conclude that limited available time is better spent in other ways or that, if they take the IAOC position, they would not be able to devote adequate attention to it, aren't we better off giving them the flexibility and discretion to make that decision? Similarly, if someone tells the appointing body I have the time and resources to take on the IAB Chair or IETF Chair position but only if that position does not include the responsibility of sitting on the IAOC isn't it better to give those bodies the option of considering that person rather than limiting the choices to those who can sign up for all of the job? At least from my perspective, broadening the flexibility available to already-appointed IAB and IETF Chairs and to the bodies that appoint them is the real issue here. _Requiring_ that they serve on the IAOC does not create more time or resources, it just limits the range of people who can take those positions or, more likely, raises the odds of getting someone onto the IAOC who won't be able to pay full (or even adequate) attention. So. in addition to the questions Dave posed, the question I would address to you and Bob is whether, given a hypothetical choice of someone sitting on the IAOC ex-officio but not being able to really pay attention because he or she concludes that there are more pressing priorities and having someone representing the IAB or IESG who really can pay attention, which one you would pick. In the worst case, if you prefer to have the Chairs nominally present but not paying complete attention, then keep insisting that they are the only ones who can possibly occupy the IAOC slot. As part of that, figure out how you are going to convince the Nomcom and the IAB that selecting people for the Chair roles should have will give IAOC first priority regardless of their judgment about the importance of other aspects of their roles as an absolute criterion and/or how you are going to convince the community to recall anyone in the Chair roles who does not give the IAOC that priority. best, john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Speechsc] Last Call: draft-ietf-speechsc-mrcpv2-24.txt (Media Resource Control Protocol Version 2 (MRCPv2)) to Proposed Standard
Hello, my small comment: The BARGE-IN-OCCURRED method is in few places wrote as BARGE-IN-OCCURED (note missing R). I wonder how this could go through all 24 MRCPv2 revisions Regards, Slawek Testowy 2011/3/16 The IESG iesg-secret...@ietf.org: The IESG has received a request from the Speech Services Control WG (speechsc) to consider the following document: - 'Media Resource Control Protocol Version 2 (MRCPv2)' draft-ietf-speechsc-mrcpv2-24.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-04-13. (This allows an additional two weeks for review since the document is large and the review period overlaps the Prague IETF meeting). 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. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-speechsc-mrcpv2/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-speechsc-mrcpv2/ No IPR declarations have been submitted directly on this I-D. ___ Speechsc mailing list speec...@ietf.org https://www.ietf.org/mailman/listinfo/speechsc Supplemental web site: lt;http://www.standardstrack.com/ietf/speechscgt; ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Speechsc] Last Call: draft-ietf-speechsc-mrcpv2-24.txt (Media Resource Control Protocol Version 2 (MRCPv2)) to Proposed Standard
Hi! Some other comments: 4.2. Managing Resource Control Channels When the client wants to add a media processing resource to the session, it issues a SIP re-INVITE transaction. Is it possible to allocate more than one resource of the same type during one SIP dialog? Example in 4.2 shows how to allocate synthesizer and recognizer, but does not specify if there may be e.g. more than one synthesizer. 6.2.9. Content-Encoding The content-encoding entity-header is used as a modifier to the media-type. When present, its value indicates what additional content encoding has been applied to the entity-body, and thus what decoding mechanisms must be applied in order to obtain the media-type referenced by the content-type header field. Content-encoding is primarily used to allow a document to be compressed without losing the identity of its underlying media type. Note that the SDP session can be used to determine accepted encodings (see Section 7). This header field MAY occur on all messages. Section 7 describes usage of OPTIONS method of SIP and Accept-Encoding header is returned by SIP response, not SDP answer, so I guess Note that the SDP session can be used should be changed to Note that the SIP session can be used. When a CONTROL request to jump backward is issued to a currently speaking synthesizer resource, and the target jump point is before the start of the current SPEAK request, the current SPEAK request MUST restart from the beginning of its speech data and the response to the CONTROL request MUST contain this header field with a value of true indicating a restart. Why sometimes requests are surrounded by quotation marks (like SPEAK) and sometimes not (like CONTROL request)? This happens through all the specification. This may be a minor nit, but makes the whole paper look like a draft :) 8.4.7. Prosody-Parameters The prosody parameter headers in the SET-PARAMS or SPEAK request only apply if the speech data is of type text/plain and does not use a speech markup format. Why is it so? Why it is not true for Voice-Parameters? Is it true for CONTROL (i.e. current SPEAK must be text/plain)? Specification does not say anything about it. 8.4.16. Load-Lexicon This header field is used to indicate whether a lexicon has to be loaded or unloaded. The default value for this header field is true. This header field MAY be specified in a DEFINE-LEXICON method. I propose rewording this paragraph to explicilty state that true means load lexicon and false means unload lexicon. Thanks. Slawek Testowy 2011/3/16 The IESG iesg-secret...@ietf.org: The IESG has received a request from the Speech Services Control WG (speechsc) to consider the following document: - 'Media Resource Control Protocol Version 2 (MRCPv2)' draft-ietf-speechsc-mrcpv2-24.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-04-13. (This allows an additional two weeks for review since the document is large and the review period overlaps the Prague IETF meeting). 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. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-speechsc-mrcpv2/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-speechsc-mrcpv2/ No IPR declarations have been submitted directly on this I-D. ___ Speechsc mailing list speec...@ietf.org https://www.ietf.org/mailman/listinfo/speechsc Supplemental web site: lt;http://www.standardstrack.com/ietf/speechscgt; ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-05
19.04.2011 1:21, Russ Housley wrote: Mykyta: 4. Downward References Permitted This section says nothing about references to documents with no status (pre-IETF RFCs). Maybe informative references to such RFCs should be allowed. And what about normative ones? Whether the RFC 3967 procedure will be used in such cases, or such references are disallowed in Standards Track docs? I think this should also be mentioned in your draft. What does this have to do with moving from two maturity levels? Mostly nothing, but if you consider that the whole Section 4 is appropriate for your document, what I propose is appropriate also. Mykyta Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-05
Mykyta: 4. Downward References Permitted This section says nothing about references to documents with no status (pre-IETF RFCs). Maybe informative references to such RFCs should be allowed. And what about normative ones? Whether the RFC 3967 procedure will be used in such cases, or such references are disallowed in Standards Track docs? I think this should also be mentioned in your draft. What does this have to do with moving from two maturity levels? Mostly nothing, but if you consider that the whole Section 4 is appropriate for your document, what I propose is appropriate also. I just reviewed RFC 3967. It does not seem to claim that references to those older documents requires special handling. I'd like to leave this topic to an update to RFC 3967 if such an update is needed at all. Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-05
On 4/19/11 9:57 AM, Russ Housley wrote: Mykyta: 4. Downward References Permitted This section says nothing about references to documents with no status (pre-IETF RFCs). Maybe informative references to such RFCs should be allowed. And what about normative ones? Whether the RFC 3967 procedure will be used in such cases, or such references are disallowed in Standards Track docs? I think this should also be mentioned in your draft. What does this have to do with moving from two maturity levels? Mostly nothing, but if you consider that the whole Section 4 is appropriate for your document, what I propose is appropriate also. I just reviewed RFC 3967. It does not seem to claim that references to those older documents requires special handling. I'd like to leave this topic to an update to RFC 3967 if such an update is needed at all. +1. Let's keep this I-D short and focused. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
IETF 84 Venue
The IAOC is pleased to announce Vancouver,BC, Canada as the site for IETF 84 from July 29 to August 3, 2012. This will be the IETF's fourth meeting in Vancouver, the others being 18, 64 and 70. Google will be the the Host for this meeting. Google most recently was the host for IETF 73 in Minneapolis. www.google.com Thanks again Google! We want to thank our benefactors. The IETF cannot support its technical standards efforts, including the Secretariat and RFC Editor, without the generous support of its hosts and sponsors. Contact Drew Dvorshak at dvors...@isoc.org if you are interested in being a Sponsor for IETF 84, or a Host for a different meeting. Hope to see you in Quebec City at IETF 81in 95 days! Ray Pelletier IETF Administrative Director ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAOC: delegating ex-officio responsibility
Bob, et al, On 4/18/2011 2:25 PM, Bob Hinden wrote: I didn't say no one else could do the job adequately. I said would have a negative impact on the operations of the IETF. Right. And my second sentence did go farther than I meant. However rejecting an effort to change the current arrangement -- especially when it is initiated by a principal -- means that alternatives are not acceptable, which translates roughly to saying the alternatives will not produce adequate performance. Otherwise it looks like a difference between 'adequate' and perhaps perfect? There is a core reality, here, that the I* Chairs are overburdened. This is obvious from looking at the list of their duties and underscored by the source of the current initiative. We can choose to defer doing anything, under the guise of taking a 'holistic' view or we can try to help with the specific burden that is the focus of the overburdened folk. On the average, we do better with incremental change and this is the one before us now. If I generalize this, I would say that 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. ... I think the I* chairs, in my view bring a broad view of the community and operational needs based on what's involved in doing their jobs than another person would not have. My own simplistic summary: For some topics it is extremely helpful to have the broader knowledge and insight that can be provided by an I* chair. For many topics, this is not needed, but for some it makes a significant difference. To that end, here's a very simple proposal that resolves the issue cleanly: 1. ISOC, IAB and IESG each appoint one person currently. Change this to be two each, the same as Nomcom. Each year, they would appoint one person. 2. Move the I* Chairs to be non-voting ex-officio participants, the same as the IETF Administrative Director. They are welcome to participate or be explicitly invited to all IAOC/Trust activities. This produces the continuity that is needed for the admin work, but also retains access to the expertise of the I* chairs. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [paws] WG Review: Protocol to Access White Space database (paws)
I think this working group is a good idea. My inclination would be to place it in the Applications area. It looks like a nice application protocol to me. There is a reasonable argument for placing it in RAI, as that is where the relevant GEOLOC work has been done up till now. Yours, Joel M. Halpern On 4/19/2011 12:56 PM, IESG Secretary wrote: A new IETF working group has been proposed. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (i...@ietf.org) by Tuesday, April 26, 2011. Protocol to Access White Space database (paws) Current Status: Proposed Working Group Last updated: 2011-04-14 Chairs: TBD Area Directors: TBD Area Advisor: TBD Mailing lists: Address: p...@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/paws Archive: http://www.ietf.org/mail-archive/web/paws/ Description of Working Group: Governments around the world continue to search for new pieces of radio spectrum which can be used by the expanding wireless communications industry to provide more services in the usable spectrum. The concept of allowing secondary transmissions (licensed or unlicensed) in frequencies allocated to a primary user is a technique to unlock existing spectrum for new use. An obvious requirement is that these secondary transmissions do not interfere with the primary use of the spectrum. Often, in a given physical location, the primary user(s) may not be using the entire band allocated to them. The available spectrum for a secondary use would then depend on the location of the secondary user. The primary user may have a schedule when it uses the spectrum, which may be available for secondary use outside that schedule. The fundamental issue is how to determine for a specific location and specific time, if any of the primary spectrum is available for secondary use. One simple mechanism is to use a geospatial database that records protected contours for primary users, and require the secondary users to check the database prior to selecting what part of the spectrum they use. Such databases could be available on the Internet for query by users. In a typical implementation of geolocation and database to access TV white space, a radio is configured with, or has the capability to determine its location in latitude and longitude. At power-on, before the device can transmit or use any of the spectrum set aside for secondary use, the device must identify the relevant database to query, contact the database, provide its geolocation and receive in return a list of unoccupied or white space spectrum (for example, in a TV White space implementation, the list of available channels at that location). The device can then select one of the channels from the list and begin to transmit and receive on the selected channel. The device must query the database subsequently on a periodic basis for a list of unoccupied channels based on certain conditions, e.g. a fixed amount of time has passed or the device has changed location beyond a specified threshold. The databases are expected to be reachable via the Internet and the devices querying these databases are expected to have some form of Internet connectivity, directly or indirectly. The databases may be country specific since the available spectrum and regulations may vary, but the fundamental operation of the protocol should be country independent, thus extensibility of data structures will be required. The solution will not be tied to any specific spectrum, country, or phy/mac/air interface but may incorporate relevant aspects of these as needed for proper operation. The proposed working group will : - standardize a protocol for querying the database, which includes a location sensitive database discovery mechanism and security for the protocol, and application services. - Standardize the data structure to be carried by the query protocol. The protocol must protect both the channel enablement process and the privacy of users. Robust security mechanisms are required to prevent: device identity spoofing, modification of device requests, modification of channel enablement information, impersonation of registered database services and unauthorized disclosure of a users location. Existing IETF location data structures and privacy mechanisms may be considered for use. The WG will also investigate the need for other mechanisms and related protocols to the White Space DB. The Working Group will set up and maintain appropriate contact and liaison with other relevant standards bodies and groups, including IEEE 802.11af and IEEE 802.22 to begin with. The working group may also consider input from regulatory entities that are involved in the specification of the rules for secondary use of spectrum in specific bands. Goals and Milestones Sep 2011 Submit 'Requirements and
Re: IAOC: delegating ex-officio responsibility
Hi Bob, At 14:25 18-04-2011, Bob Hinden wrote: I didn't say no one else could do the job adequately. I said would have a negative impact on the operations of the IETF. Some examples where an I* chair had a significant influence on a decision that IAOC made include: - The hiring of the Transitional RSE - Many of the Beijing meeting issues (prior and post signing the MOU) - Specific venue selections (in one case avoiding a less than ideal venue) - The need for transparency in certain IAOC actions (day passes, venue rotation) - Discussion of what policy decisions that the IAOC can make vs. the IESG vs. community - Discussion about when to get community feedback - Secretariat contract (RFP, bidders review, selection, etc.) - RFC Publisher and Publisher contracts (RFP, bidders review, selection, etc.) Some of these decision might have been different without one or more I* chairs being directly involved in the decision. Please review the minutes for more detail. From RFC 4071: The IAOC shall be accountable to the IETF community for the effectiveness, efficiency, and transparency of the IASA. In a personal note that Olaf posted ( http://www.ietf.org/mail-archive/web/ietf/current/msg66161.html ), it is mentioned that it takes 0.7 FTE. I do not believe that the decisions mentioned above are unimportant. However, you have to consider which decisions require your attention when you have a limited amount of time available. The current members of the IAOC, excluding ex officio, are: Eric Burger Dave Crocker Marshall Eubanks Bob Hinden Ray Pelletier (non-voting) None of them are new to the IETF. If it requires I* Chairs for the IAOC to be transparent, something is not right. I think the I* chairs, in my view bring a broad view of the community and operational needs based on what's involved in doing their jobs than another person would not have. If I understand your arguments, it is also about avoiding a disconnect between the administrative side of the IETF and the IAB/IESG. draft-kolkman-iasa-ex-officio-membership-00 argues for a change to reduce the workload and make the I* Chair positions more attractive. Would it help if the IAOC Chair has a liaison position on the IAB and IESG? The IAB and IESG Chairs can use their discretion to determine which IAOC meetings they should attend. The IAOC Chair gets a broader view. The above pushes the workload around instead of addressing the problem. If this trend continues, the best fit people will turn down I* positions. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAOC: delegating ex-officio responsibility
Dave, On Apr 19, 2011, at 10:33 AM, Dave CROCKER wrote: Bob, et al, On 4/18/2011 2:25 PM, Bob Hinden wrote: I didn't say no one else could do the job adequately. I said would have a negative impact on the operations of the IETF. Right. And my second sentence did go farther than I meant. However rejecting an effort to change the current arrangement -- especially when it is initiated by a principal -- means that alternatives are not acceptable, which translates roughly to saying the alternatives will not produce adequate performance. Otherwise it looks like a difference between 'adequate' and perhaps perfect? We don't get perfect :-) There is a core reality, here, that the I* Chairs are overburdened. This is obvious from looking at the list of their duties and underscored by the source of the current initiative. We can choose to defer doing anything, under the guise of taking a 'holistic' view or we can try to help with the specific burden that is the focus of the overburdened folk. On the average, we do better with incremental change and this is the one before us now. Then let's talk about the overall problem and not a point solution. If I generalize this, I would say that 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. ... I think the I* chairs, in my view bring a broad view of the community and operational needs based on what's involved in doing their jobs than another person would not have. My own simplistic summary: For some topics it is extremely helpful to have the broader knowledge and insight that can be provided by an I* chair. For many topics, this is not needed, but for some it makes a significant difference. I agree, and it is representative of the level of current participation of I* chairs. To that end, here's a very simple proposal that resolves the issue cleanly: 1. ISOC, IAB and IESG each appoint one person currently. Change this to be two each, the same as Nomcom. Each year, they would appoint one person. 2. Move the I* Chairs to be non-voting ex-officio participants, the same as the IETF Administrative Director. They are welcome to participate or be explicitly invited to all IAOC/Trust activities. This produces the continuity that is needed for the admin work, but also retains access to the expertise of the I* chairs. I don't agree. Appointing two people (or more?) doesn't solve the problem I am concerned about, it still doesn't bring the chairs perspective. It also significantly changes the governance model by changing the balance between between nomcom, iab, iesg, and ISOC appointed members. Also, adding six people (still counting the chairs) will make the IAOC much larger and unwieldy. Bob ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [paws] WG Review: Protocol to Access White Space database (paws)
On 4/19/11 1:47 PM, Paul Lambert wrote: How does the area that the group is assigned impact the choices of technology? I'm an advocate for an efficient solution set for PAWS ... it will be much like DNS for spectrum in the future and should be viewed as a core infrastructural component that needs careful design. There are good reasons that routing protocols don't use XML. Applications now days tend to go for the simple, quick to make a web application solutions using XML or the like ... My concern is that Applications imply that efficiency does not matter. A quick look at the specifications for the CORE WG in the Applications Area will show you that we're able to produce protocols that are quite slim on the wire. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAOC: delegating ex-officio responsibility
SM, Eric Burger Dave Crocker Marshall Eubanks Bob Hinden Ray Pelletier (non-voting) None of them are new to the IETF. If it requires I* Chairs for the IAOC to be transparent, something is not right. But that may not always be the case that all IAOC members have a lot of IETF experience. We need to have a governance model that works into the future. I think the I* chairs, in my view bring a broad view of the community and operational needs based on what's involved in doing their jobs than another person would not have. If I understand your arguments, it is also about avoiding a disconnect between the administrative side of the IETF and the IAB/IESG. Yes draft-kolkman-iasa-ex-officio-membership-00 argues for a change to reduce the workload and make the I* Chair positions more attractive. Would it help if the IAOC Chair has a liaison position on the IAB and IESG? The IAB and IESG Chairs can use their discretion to determine which IAOC meetings they should attend. The IAOC Chair gets a broader view. The above pushes the workload around instead of addressing the problem. If this trend continues, the best fit people will turn down I* positions. It would certainly give the IAOC chair a broader view, but still not the views of the I* chair. Also, if the I* chairs (3 of 9 voting members) regularly didn't attend, it would be much harder to get a quorum for a meeting and pass motions. Bob ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: Protocol to Access White Space database (paws)
I think this is a good and timely thing for the IETF to do. One part of this where I think it might be useful to get some broader input (which may have happened already, I'm not sure) is the following: On 19/04/11 17:56, IESG Secretary wrote: The protocol must protect both the channel enablement process and the privacy of users. That part is fine but it goes on to say: Robust security mechanisms are required to prevent: device identity spoofing, modification of device requests, modification of channel enablement information, ... I'm told (and believe) this in response to (at least) US FCC requirements that call for a device ID and sometimes serial number to be (securely, for some value of securely) sent with the query. Those appear to be real regulatory requirements in the US, presumably so the regulator can stomp on someone who messes about in the wrong spectrum at the wrong time. (The link below [1] may be to the right or wrong bit of those US regulations, I'm not at all sure, not being from there;-) So my questions: Are there may be similar (or conflicting!) requirements elsewhere? Does this bit of the charter text need changes to work well for other regions? Separately, I'm not sure how to square those kinds of regulatory requirements with protecting privacy where the device is carried by a person and has some FCC device ID (which lots do I guess) and the person might not want the database operator to know who's asking. But I think that's ok as something for the WG to figure out since the charter already calls for respecting privacy. I'm more concerned in case e.g. some other regional regulation called for this protocol to be completely anonymous or something, in which case the current charter text might be problematic. Cheers, Stephen. [1] http://ecfr.gpoaccess.gov/cgi/t/text/text-idx?c=ecfrsid=3e9c322addf1f7e897d8c84a6c7aca78rgn=div8view=textnode=47:1.0.1.1.14.8.243.9idno=47 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [paws] WG Review: Protocol to Access White Space database (paws)
Clearly, the discussion about whether the application protocol should be XML, plain ASCII/UTF8, binary, or some other encoding needs to take place. But that can take place wherever we place the working group. There is an argument, which you allude to, which would place this WG in the Internet Area as part of infrastructure. While that does not resonate with me, I do see that there is some merit in that perspective. I tend to think we need to focus on transactional application experience (the apps area) or where we have experience with protocols that need to communicate geolocation (RAI). I would hope, and expect, that the ADs for any area would be receptive to a proper evaluation of any candidate protocol and encoding. (The arguments get complex, and it takes care to avoid religious assertions.) Yours, Joel On 4/19/2011 3:47 PM, Paul Lambert wrote: How does the area that the group is assigned impact the choices of technology? I'm an advocate for an efficient solution set for PAWS ... it will be much like DNS for spectrum in the future and should be viewed as a core infrastructural component that needs careful design. There are good reasons that routing protocols don't use XML. Applications now days tend to go for the simple, quick to make a web application solutions using XML or the like ... My concern is that Applications imply that efficiency does not matter. Paul -Original Message- From: paws-boun...@ietf.org [mailto:paws-boun...@ietf.org] On Behalf Of Joel M. Halpern Sent: Tuesday, April 19, 2011 10:50 AM To: i...@ietf.org Cc: p...@ietf.org; IETF discussion list Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws) I think this working group is a good idea. My inclination would be to place it in the Applications area. It looks like a nice application protocol to me. There is a reasonable argument for placing it in RAI, as that is where the relevant GEOLOC work has been done up till now. Yours, Joel M. Halpern On 4/19/2011 12:56 PM, IESG Secretary wrote: A new IETF working group has been proposed. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (i...@ietf.org) by Tuesday, April 26, 2011. Protocol to Access White Space database (paws) Current Status: Proposed Working Group Last updated: 2011-04-14 Chairs: TBD Area Directors: TBD Area Advisor: TBD Mailing lists: Address: p...@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/paws Archive: http://www.ietf.org/mail-archive/web/paws/ Description of Working Group: Governments around the world continue to search for new pieces of radio spectrum which can be used by the expanding wireless communications industry to provide more services in the usable spectrum. The concept of allowing secondary transmissions (licensed or unlicensed) in frequencies allocated to a primary user is a technique to unlock existing spectrum for new use. An obvious requirement is that these secondary transmissions do not interfere with the primary use of the spectrum. Often, in a given physical location, the primary user(s) may not be using the entire band allocated to them. The available spectrum for a secondary use would then depend on the location of the secondary user. The primary user may have a schedule when it uses the spectrum, which may be available for secondary use outside that schedule. The fundamental issue is how to determine for a specific location and specific time, if any of the primary spectrum is available for secondary use. One simple mechanism is to use a geospatial database that records protected contours for primary users, and require the secondary users to check the database prior to selecting what part of the spectrum they use. Such databases could be available on the Internet for query by users. In a typical implementation of geolocation and database to access TV white space, a radio is configured with, or has the capability to determine its location in latitude and longitude. At power-on, before the device can transmit or use any of the spectrum set aside for secondary use, the device must identify the relevant database to query, contact the database, provide its geolocation and receive in return a list of unoccupied or white space spectrum (for example, in a TV White space implementation, the list of available channels at that location). The device can then select one of the channels from the list and begin to transmit and receive on the selected channel. The device must query the database subsequently on a periodic basis for a list of unoccupied channels based on certain conditions, e.g. a fixed amount of time has passed or the device has changed location beyond a specified threshold. The databases are expected to be reachable via the Internet and
Re: [paws] WG Review: Protocol to Access White Space database (paws)
Actually, as far as I can tell, there is very little parallel between the PAWS problem and SNMP. SNMP tends to be initiated by the manager, and used to extract information from the device in the network, or set information in teh device. This protocol is used by the client. It extracts basically stable information about what frequencies can be used in this geographic region at this time. There is no network management going on. the interaction does not look like SNMP. And the effect does not look like SNMP. While Radius or Diameter are closer, this protocol is not even a policy decision protocol. There is no policy. So no, I do not think this looks anything like network management. The protocols, the transaction drivers and behavior, the problem space, and the underlying data behavior are all very different from any of our NM work. Yours, Joel On 4/19/2011 5:21 PM, Rex Buddenberg wrote: On Tue, 2011-04-19 at 12:47 -0700, Paul Lambert wrote: How does the area that the group is assigned impact the choices of technology? I'm an advocate for an efficient solution set for PAWS ... it will be much like DNS for spectrum in the future and should be viewed as a core infrastructural component that needs careful design. There are good reasons that routing protocols don't use XML. While the DNS analogy works, I was thinking more a parallel -- or extension -- of SNMP. Still remain within 'applications', Joel? Applications now days tend to go for the simple, quick to make a web application solutions using XML or the like ... My concern is that Applications imply that efficiency does not matter. Paul -Original Message- From: paws-boun...@ietf.org [mailto:paws-boun...@ietf.org] On Behalf Of Joel M. Halpern Sent: Tuesday, April 19, 2011 10:50 AM To: i...@ietf.org Cc: p...@ietf.org; IETF discussion list Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws) I think this working group is a good idea. My inclination would be to place it in the Applications area. It looks like a nice application protocol to me. There is a reasonable argument for placing it in RAI, as that is where the relevant GEOLOC work has been done up till now. Yours, Joel M. Halpern On 4/19/2011 12:56 PM, IESG Secretary wrote: A new IETF working group has been proposed. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (i...@ietf.org) by Tuesday, April 26, 2011. Protocol to Access White Space database (paws) Current Status: Proposed Working Group Last updated: 2011-04-14 Chairs: TBD Area Directors: TBD Area Advisor: TBD Mailing lists: Address: p...@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/paws Archive: http://www.ietf.org/mail-archive/web/paws/ Description of Working Group: Governments around the world continue to search for new pieces of radio spectrum which can be used by the expanding wireless communications industry to provide more services in the usable spectrum. The concept of allowing secondary transmissions (licensed or unlicensed) in frequencies allocated to a primary user is a technique to unlock existing spectrum for new use. An obvious requirement is that these secondary transmissions do not interfere with the primary use of the spectrum. Often, in a given physical location, the primary user(s) may not be using the entire band allocated to them. The available spectrum for a secondary use would then depend on the location of the secondary user. The primary user may have a schedule when it uses the spectrum, which may be available for secondary use outside that schedule. The fundamental issue is how to determine for a specific location and specific time, if any of the primary spectrum is available for secondary use. One simple mechanism is to use a geospatial database that records protected contours for primary users, and require the secondary users to check the database prior to selecting what part of the spectrum they use. Such databases could be available on the Internet for query by users. In a typical implementation of geolocation and database to access TV white space, a radio is configured with, or has the capability to determine its location in latitude and longitude. At power-on, before the device can transmit or use any of the spectrum set aside for secondary use, the device must identify the relevant database to query, contact the database, provide its geolocation and receive in return a list of unoccupied or white space spectrum (for example, in a TV White space implementation, the list of available channels at that location). The device can then select one of the channels from the list and begin to transmit and receive on the selected channel. The device must query the database subsequently on a periodic basis for a list
WG Action: RECHARTER: Secure Inter-Domain Routing (sidr)
The Secure Inter-Domain Routing (sidr) working group in the Routing Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the working group Chairs. Secure Inter-Domain Routing (sidr) --- Current Status: Active Working Group Chairs: Sandra Murphy sandra.mur...@sparta.com Chris Morrow morr...@ops-netman.net Routing Area Directors: Stewart Bryant stbry...@cisco.com Adrian Farrel adrian.far...@huawei.com Routing Area Advisor: Stewart Bryant stbry...@cisco.com Mailing lists: Address: s...@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/sidr Archive: http://www.ietf.org/mail-archive/web/sidr Description of Working Group: The purpose of the SIDR working group is to reduce vulnerabilities in the inter-domain routing system. The two vulnerabilities that will be addressed are: * Is an Autonomous System (AS) authorized to originate an IP prefix * Is the AS-Path represented in the route the same as the path through which the NLRI traveled The SIDR working group will take practical deployability into consideration. Building upon the already completed and implemented framework: * Resource Public Key Infrastructure (RPKI) * Distribution of RPKI data to routing devices and its use in operational networks * Document the use of certification objects within the secure routing architecture This working group will specify security enhancements for inter-domain routing protocols. The SIDR working group is charged with the following goals and milestones: Goals and Milestones: ID Date Pub Date Mar 2011 Jan 2012 An overview of the RPKI and BGP Protocol changes required for origin and path validation Mar 2011 Jun 2012 A document describing threats to the routing system Mar 2011 Jun 2012 A requirements document that addresses these threats Mar 2011 Jan 2012 Document the BGP protocol enhancements that meet the security requirements Nov 2010 Jul 2011 draft-ietf-sidr-origin-ops Mar 2011 Jul 2012 Operational deployment guidance for network operators Jun 2011 Dec 2011 System and architecture design choices made in the protocol and RPKI Mar 2010 Mar 2012 draft-ietf-sidr-cps-irs Mar 2010 Mar 2012 draft-ietf-sidr-cps-isp Nov 2010 Jan 2012 draft-ietf-sidr-pfx-validate Jan 2010 Jun 2011 draft-ietf-sidr-publication Nov 2010 Jun 2011 draft-ietf-sidr-repos-struct Nov 2010 Jun 2011 draft-ietf-sidr-roa-format Feb 2011 Jun 2011 draft-ietf-sidr-rpki-rtr Nov 2010 Nov 2011 draft-ietf-sidr-ltamgmt Dec 2010 Oct 2011 draft-rgaglian-sidr-algorithm-agility May 2011 Dec 2011 draft-ietf-sidr-usecases Jan 2011 Oct 2011 draft-ietf-sidr-ghostbusters Jan 2010 Dec 2011 draft-ietf-sidr-keyroll Jan 2010 May 2011 draft-ietf-sidr-arch Jan 2010 May 2011 draft-ietf-sidr-cp Jan 2010 May 2011 draft-ietf-sidr-res-certs Jan 2010 Jun 2011 draft-ietf-sidr-roa-validation Jan 2010 Jun 2011 draft-ietf-sidr-signed-object Jan 2010 Jun 2011 draft-ietf-sidr-rpki-manifests Jan 2010 Jul 2011 draft-ietf-sidr-rpki-algs Jan 2010 Jul 2011 draft-ietf-sidr-rescerts-provisioning Jan 2010 Aug 2011 draft-ietf-sidr-ta ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
IETF 84 Venue
The IAOC is pleased to announce Vancouver,BC, Canada as the site for IETF 84 from July 29 to August 3, 2012. This will be the IETF's fourth meeting in Vancouver, the others being 18, 64 and 70. Google will be the the Host for this meeting. Google most recently was the host for IETF 73 in Minneapolis. www.google.com Thanks again Google! We want to thank our benefactors. The IETF cannot support its technical standards efforts, including the Secretariat and RFC Editor, without the generous support of its hosts and sponsors. Contact Drew Dvorshak at dvors...@isoc.org if you are interested in being a Sponsor for IETF 84, or a Host for a different meeting. Hope to see you in Quebec City at IETF 81in 95 days! Ray Pelletier IETF Administrative Director ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Review: Recharter of Softwires (softwire)
A modified charter has been submitted for the Softwires (softwire) working group in the Internet Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (i...@ietf.org) by Tuesday, April 26, 2011. Softwires (softwire) **DRAFT 2011-04-14** (v03) Current Status: Active Chairs: Alain Durand adur...@juniper.net Yong Cui cuiy...@tsinghua.edu.cn Internet Area Directors: Ralph Droms rdroms.i...@gmail.com Jari Arkko jari.ar...@piuha.net Internet Area Advisor: Ralph Droms rdroms.i...@gmail.com Mailing Lists: General Discussion: softwi...@ietf.org To Subscribe: softwires-requ...@ietf.org Archive: http://www.ietf.org/mail-archive/web/softwires/current/maillist.html Description of Working Group: The Softwires Working Group is specifying the standardization of discovery, control and encapsulation methods for connecting IPv4 networks across IPv6 networks and IPv6 networks across IPv4 networks in a way that will encourage multiple, inter-operable implementations. For various reasons, native IPv4 and/or IPv6 transport may not be available in all cases, and there is a need to tunnel IPv4 in IPv6 or IPv6 in IPv4 to cross a part of the network which is not IPv4 or IPv6 capable. The Softwire Problem Statement, RFC 4925, identifies two distinct topological scenarios that the WG will provide solutions for: Hubs and Spokes and Mesh. In the former case, hosts or stub networks are attached via individual, point-to-point, IPv4 over IPv6 or IPv6 over IPv4 softwires to a centralized Softwire Concentrator. In the latter case (Mesh), network islands of one Address Family (IPv4 or IPv6) are connected over a network of another Address Family via point to multi-point softwires among Address family Border Routers (AFBRs). The WG will reuse existing technologies as much as possible and only when necessary, create additional protocol building blocks. For generality, all base Softwires encapsulation mechanisms should support all combinations of IP versions over one other (IPv4 over IPv6, IPv6 over IPv4, IPv4 over IPv4, IPv6 over IPv6). IPv4 to IPv6 translation mechanisms (NAT-PT), new addressing schemes, and block address assignments are out of scope. DHCP options developed in this working group will be reviewed jointly with the DHC WG. RADIUS attributes developed in this working group will be reviewed jointly with the RADEXT WG. The MIB Doctors directorate will be asked to review any MIB modules developed in the SOFTWIRE working group. BGP and other routing and signaling protocols developed in this group will be reviewed jointly with the proper working groups and other workings that may take interest (e.g. IDR, L3VPN, PIM, LDP, SAAG, etc). The specific work areas for this working group are: 1. Developments for Mesh softwires topology; the Mesh topology work will be reviewed in the l3vpn and idr WGs - multicast - MIB module 2. Developments for 6rd: - multicast - operational specification - RADIUS option for 6rd server - MIB module 3. Developments for Dual-Stack Lite (DS-Lite): - multicast - operational specification - RADIUS option for AFTR - proxy extensions; GI-DS-Lite; DS-Lite with no NAT or NAT on the B4 element - MIB module 4. Developments for stateless legacy IPv4 carried over IPv6 - develop a solution motivation document to be published as an RFC - develop a protocol specification response to the solution motivation document; this work item will not be taken through WG last call until the solution motivation document has been published 5. Finalize discovery and configuration mechanisms for a gateway to use DS-Lite or 6rd; these discovery and configuration mechanisms must take into a account other operating environments such as dual-stack and tunneling mechanisms not defined by the softwire WG. Development of new mechanisms will involve the dhc and/or v6ops WGs as appropriate Other work items would require WG approval and rechartering. Goals and Milestones: Apr 2011 Submit DS-lite RADIUS option for Proposed Standard Apr 2011 Adopt DS-lite operational document as WG document Jul 2011 Submit 6rd RADIUS option for Proposed Standard Jul 2011 Submit GI DS-lite for Proposed Standard Jul 2011 Adopt B4NAT as WG document Aug 2011 Adopt 6rd operational document as WG document Aug 2011 Adopt Multicast extensions document as WG document Aug 2011 Submit DS-lite operational document for Informational Sep 2011 Submit B4NAT for Informational Nov 2011 Submit Multicast extensions document for Informational Nov 2011 Submit 6rd operational document for Informational Nov 2011 Adopt 6rd MIB module as WG document Nov 2011
WG Review: Real-Time Communication in WEB-browsers (rtcweb)
A new IETF working group has been proposed in the Real-Time Applications and Infrastructure Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (i...@ietf.org) by Tuesday, April 26, 2011. Real-Time Communication in WEB-browsers (rtcweb) Current Status: Proposed Working Group Last Updated: 2011-04-14 Chairs: TBD RAI Area Directors: Gonzalo Camarillo Robert Sparks RAI Area Advisor: Gonzalo Camarillo Mailing Lists: Address: rtc...@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/rtcweb Archive: http://www.ietf.org/mail-archive/web/rtcweb/ Description of Working Group: There are a number of proprietary implementations that provide direct interactive rich communication using audio, video, collaboration, games, etc. between two peers' web-browsers. These are not interoperable, as they require non-standard extensions or plugins to work. There is a desire to standardize the basis for such communication so that interoperable communication can be established between any compatible browsers. The goal is to enable innovation on top of a set of basic components. One core component is to enable real-time media like audio and video, a second is to enable data transfer directly between clients. This work will be done in collaboration with the W3C. The IETF WG will produce architecture and requirements for selection and profiling of the on the wire protocols. The architecture needs to be coordinated with W3C. The IETF WG work will identify state information and events that need to be exposed in the APIs as input to W3C. The W3C will be responsible for defining APIs to ensure that application developers can control the components. We will reach out to the developer community for consultation and early feedback on implementation. The security and privacy goals and requirements will be developed by the WG. The security model needs to be coordinated with the W3C. The work will also consider where support for extensibility is needed. RTP functionalities, media formats, security algorithms are example of things that commonly need extensions, additions or replacement, and thus some support for negotiation between clients is required. The WG will perform the following work: 1. Define the communication model in detail, including how session management is to occur within the model. 2. Define a security model that describes the security and privacy goals and specifies the security protocol mechanisms necessary to achieve those goals. 3. Define the solution - protocols and API requirements - for firewall and NAT traversal. 4. Define which media functions and extensions shall be supported in the client and their usage for real-time media, including media adaptation to ensure congestion safe usage. 5. Define what functionalities in the solution, such as media codecs, security algorithms, etc., can be extended and how the extensibility mechanisms works. 6. Define a set of media formats that must or should be supported by a client to improve interoperability. 7. Define how non media data is transported between clients in a secure and congestion safe way. 8. Provide W3C input for the APIs that comes from the communication model and the selected components and protocols that are part of the solution. 9. The group will consider options for interworking with legacy VoIP equipment. This work will be done primarily by using already defined protocols or functionalities. If there is identification of missing protocols or functionalities, such work can be requested to be done in another working group with a suitable charter or by requests for chartering it in this WG or another WG. The following topics will be out of scope for the initial phase of the WG: RTSP, RSVP, NSIS, Location services, Resource Priority, and IM Presence specific features. The products of the working group will support security and keying as required by BCP 61 and be defined for IPv4, IPv6, and dual stack deployments. The Working Group will consider the possibility of defining a browser component that implements an existing session negotiation and management protocol. The working group will follow BCP 79, and adhere to the spirit of BCP 79. The working group cannot explicitly rule out the possibility of adopting encumbered technologies; however, the working group will try to avoid encumbered technologies that require royalties or other encumbrances that would prevent such technologies from being easy to use in web browsers. Milestones: Aug 2011 Architecture, Security, Privacy and Threat Model sent to W3C Aug 2011 Use cases, Scenarios, and Requirements document (I-D) sent to W3C Sep 2011 Architecture
WG Review: Protocol to Access White Space database (paws)
A new IETF working group has been proposed. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (i...@ietf.org) by Tuesday, April 26, 2011. Protocol to Access White Space database (paws) Current Status: Proposed Working Group Last updated: 2011-04-14 Chairs: TBD Area Directors: TBD Area Advisor: TBD Mailing lists: Address: p...@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/paws Archive: http://www.ietf.org/mail-archive/web/paws/ Description of Working Group: Governments around the world continue to search for new pieces of radio spectrum which can be used by the expanding wireless communications industry to provide more services in the usable spectrum. The concept of allowing secondary transmissions (licensed or unlicensed) in frequencies allocated to a primary user is a technique to unlock existing spectrum for new use. An obvious requirement is that these secondary transmissions do not interfere with the primary use of the spectrum. Often, in a given physical location, the primary user(s) may not be using the entire band allocated to them. The available spectrum for a secondary use would then depend on the location of the secondary user. The primary user may have a schedule when it uses the spectrum, which may be available for secondary use outside that schedule. The fundamental issue is how to determine for a specific location and specific time, if any of the primary spectrum is available for secondary use. One simple mechanism is to use a geospatial database that records protected contours for primary users, and require the secondary users to check the database prior to selecting what part of the spectrum they use. Such databases could be available on the Internet for query by users. In a typical implementation of geolocation and database to access TV white space, a radio is configured with, or has the capability to determine its location in latitude and longitude. At power-on, before the device can transmit or use any of the spectrum set aside for secondary use, the device must identify the relevant database to query, contact the database, provide its geolocation and receive in return a list of unoccupied or white space spectrum (for example, in a TV White space implementation, the list of available channels at that location). The device can then select one of the channels from the list and begin to transmit and receive on the selected channel. The device must query the database subsequently on a periodic basis for a list of unoccupied channels based on certain conditions, e.g. a fixed amount of time has passed or the device has changed location beyond a specified threshold. The databases are expected to be reachable via the Internet and the devices querying these databases are expected to have some form of Internet connectivity, directly or indirectly. The databases may be country specific since the available spectrum and regulations may vary, but the fundamental operation of the protocol should be country independent, thus extensibility of data structures will be required. The solution will not be tied to any specific spectrum, country, or phy/mac/air interface but may incorporate relevant aspects of these as needed for proper operation. The proposed working group will : - standardize a protocol for querying the database, which includes a location sensitive database discovery mechanism and security for the protocol, and application services. - Standardize the data structure to be carried by the query protocol. The protocol must protect both the channel enablement process and the privacy of users. Robust security mechanisms are required to prevent: device identity spoofing, modification of device requests, modification of channel enablement information, impersonation of registered database services and unauthorized disclosure of a users location. Existing IETF location data structures and privacy mechanisms may be considered for use. The WG will also investigate the need for other mechanisms and related protocols to the White Space DB. The Working Group will set up and maintain appropriate contact and liaison with other relevant standards bodies and groups, including IEEE 802.11af and IEEE 802.22 to begin with. The working group may also consider input from regulatory entities that are involved in the specification of the rules for secondary use of spectrum in specific bands. Goals and Milestones Sep 2011 Submit 'Requirements and Framework' to the IESG for publication as Informational Apr 2012 Submit 'Protocol for Querying a Whitespace Database' to the IESG for publication as Proposed Standard Apr 2012 Submit 'Data Model for Whitespace query protocol' to the IESG for publication as Proposed Standard
North American Cable Industry to Host IETF 85
The IAOC is pleased to be able to announce sponsors for IETF 85 in Atlanta in November 4 - 9, 2012. That meeting will be hosted by the North American cable industry. The sponsoring companies are Comcast, Time Warner Cable, CableLabs, the National Cable Telecommunications Association, Brighthouse, Cablevision, Charter, and Cox. Comcast hosted IETF 71 in Philadelphia and has sponsored meeting breaks and ice cream socials at other meetings, such as recently in Prague. Thanks to the cable industry! Interested in hosting an IETF meeting? Contact Drew Dvorshak at dvors...@isoc.org. Ray Pelletier IETF Administrative Director ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: rfc5953 (Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)) to Draft Standard
The IESG has received a request from the isms WG (isms) to consider the following document: - 'Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP) ' RFC 5953 as a Draft 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-05-03. 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. This specification contains eight normative references to standards track documents of lower maturity: RFCs 1033, 3490, 3584, 4347, 4366, 5246, 5280, and 5952. The file can be obtained via http://datatracker.ietf.org/doc/rfc5953/ Implementation Report can be accessed at http://www.ietf.org/iesg/implementation.html IESG discussion can be tracked via http://datatracker.ietf.org/doc/rfc5953/ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: rfc5590 (Transport Subsystem for the Simple Network Management Protocol (SNMP)) to Draft Standard
The IESG has received a request from the isms WG (isms) to consider the following document: - 'Transport Subsystem for the Simple Network Management Protocol (SNMP) ' RFC 5590 as a Draft 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-05-03. 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. The file can be obtained via http://datatracker.ietf.org/doc/rfc5590/ The interoperability report obtained via http://www.ietf.org/iesg/implementation/report-rfc5343-5590-5591-5953.txt IESG discussion can be tracked via http://datatracker.ietf.org/doc/rfc5590/ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: rfc5591 (Transport Security Model for the Simple Network Management Protocol (SNMP)) to Draft Standard
The IESG has received a request from the isms WG (isms) to consider the following document: - 'Transport Security Model for the Simple Network Management Protocol (SNMP)' RFC 5591 as a Draft 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-05-03. 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. Note that an IETF Last Call to progress RFC 5590 to Draft Standard is also underway (which would have been a downref). The file can be obtained via http://datatracker.ietf.org/doc/rfc5591/ Implementation Report can be accessed at http://www.ietf.org/iesg/implementation.html IESG discussion can be tracked via http://datatracker.ietf.org/doc/rfc5591/ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: rfc5343 (Simple Network Management Protocol (SNMP) Context EngineID Discovery) to Draft Standard
The IESG has received a request from the opsawg WG (opsawg) to consider the following document: - 'Simple Network Management Protocol (SNMP) Context EngineID Discovery ' RFC 5343 as a Draft 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-05-03. 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. The file can be obtained via http://www.ietf.org/rfc/rfc5343.txt Implementation Report can be accessed at http://www.ietf.org/iesg/implementation.html IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=5343rfc_flag=1 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
