Re: [paws] WG Review: Protocol to Access White Space database (paws)
Peter Saint-Andre wrote: 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. Absolutely not. There are several counter examples in Apps, both past and present. (E.g. Lemonade WG was about optimized use of bandwidth for IMAP.) 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. Exactly. ___ 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 Tue, Apr 19, 2011 at 10:13:13PM -0400, Joel M. Halpern wrote: 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. On the other hand (to continue the analogy with the DNS despite Richard's shuddering), DNS Extensions is also sort of an awkward fit in the Internet area (perhaps partly because many applications ought to be able to use DNS data but aren't, and perhaps partly because it is in fact an application sitting atop all those other things worked on in the Internet area). encoding. (The arguments get complex, and it takes care to avoid religious assertions.) Indeed -- particularly when history becomes one of those topics of religious dispute. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Politics and technology, was Call for a Jasmine Revolution
On 12/Apr/11 18:31, Phillip Hallam-Baker wrote: Todd, This is totally confused and you are completely wrong. Under the Federal Election Campaign Act http://en.wikipedia.org/wiki/Federal_Election_Campaign_Act, an organization becomes a political committee by receiving contributions or making expenditures in excess of $1,000 for the purpose of influencing a federal election [Source Wikipedia] Since neither the IETF nor ISOC has any interest in influencing a federal election, nor does it engage in any activity intended to do so, it is not a political committee under the terms of the act. The way politics is currently being done is not necessarily adequate. Let me just note that the root problem is that we are sharing this planet among a few billions individuals. That is certainly a political problem. However, given that communication is potentially proportional to the square of the communicating parties, it is also a technical problem. I claim that it is not possible to neatly discern between political and technical issues, although only one of those two aspects appears to be dominant in many specific cases. To justify this claim, suffice it to say that the /amount/ of traffic has a paramount physical limit, time, whose use cannot be regulated by any single-sided approach --either political or technical, only. For an example: spam. Is it an only-technical problem to devise adequate means for politics? For the reciprocal question, whether politics should intrude into technology, the ISOC, talking about the IETF and similar bodies, recommends that politics do not assert any authority over those organizations by any mechanism [1]. So, how do we tackle spam and similar issues where neither aspect is prevalent? 1. ISOC's response to NTIA request for comments on IANA functions http://isoc.org/wp/newsletter/files/2011/03/Internet-Society-Response-Docket.pdf 30 March 2011 On Mon, Apr 11, 2011 at 4:56 PM, todd glassey tglas...@earthlink.net mailto:tglas...@earthlink.net wrote: On 3/23/2011 12:02 AM, Hannes Tschofenig wrote: On Mar 23, 2011, at 6:52 AM, SM wrote: The IETF can only address the technical problems. This is an argument I often hear. I do, however, believe that you cannot see technology in isolation. Yeah - sure you can... if you want to be totally about the original design and practice of the IETF and its vision. It was built to advance protocol standardization and not to decide what protocols it would allow on the Internet and which it wouldn't. But lately many have forgotten this and are using the IETF as a formal lobby for technological policy advancement and that's a no-no. Bluntly the IETF members are becoming more and more aggressively politically and this statement is based on IAB and other publication on what the IETF does and does not allow through its frameworks. In doing so their statements about allowing protocols or not allowing protocols to be standardized based on their stated perception of what damages the Internet or what they personally want to see as a free access to all information and ideas model, creates a real serious divergence from the Standards Practice this organization was set up as, and IMHO is one which is designed clearly to destroy global Intellectual Property law and practice. However, in many cases the technology, regulatory environment, business aspects, and the social context gets mixed together. No Hannes - it doesn't unless the Chair allows it to - meaning that the Chair in this instance has allowed political materials to be fielded (filed in this instance) into the IETF and trust me I am already filing a formal complaint with the Treasury about ISOC's becoming a formal PAC and its locking out protocol efforts based on its own desires therein... http://tools.ietf.org/html/draft-morris-policy-cons-00 I suggest that the Chair immediately post a formal statement that the IETF is a-political and will not do anything but standardize technology. Also that ONLY technology drafts can be accepted since the IETF is part of ISOC and not registered as a political PAC or Lobbying Agency which it clearly has become in direct violation of the NTIA MOU which gave it (ISOC and its ARIN) the real power. Todd Glassey Please have a look at: http://tools.ietf.org/html/draft-morris-policy-cons-00 Ciao Hannes Hannes - this is the issue with the IETF and the gross number of flaming idiots inside of it. The IETF is not a Social Reform Agency, nor is it a freaking political action group since its financial filings prevent this. Todd Glassey ___ Ietf mailing list Ietf@ietf.org
Review of: draft-iab-dns-applications-01
Review -- Title:Architectural Considerations on Application Features in the DNS By: Kolkman, Peterson, Tschofenig, Aboba I-D: draft-iab-dns-applications-01 Reviewer: D. Crocker dcroc...@bbiw.net Review Date: 20 April 2011 RFC 882: DNS Concepts and Facilities (1982) Need: The number of resources (for example mailboxes), the number of locations for resources, and the diversity of such an environment cause formidable problems when we wish to create consistent methods for referencing particular resources that are similar but scattered throughout the environment. ... The problem for computer mail is more severe. ... The basic need is for a consistent name space which will be used for referring to resources. Solution: The DOMAIN NAME SPACE, which is a specification for a tree structured name space. ... NAME SERVERS are server programs which hold information about the domain tree's structure and set information. ... RESOLVERS are programs that extract information from name servers in response to user requests. Draft Summary - The DNS provides critical infrastructure service to the public Internet. Proposed enhancements must have a first do no harm basis, with respect to existing operations. However, DNS capabilities and experiences already support addition of new data and new types of data, so that all enhancements are not equally suspect. The draft lays out its goals in terms of a a set of increasing functional demands being made, considered or possible by applications wishing to use the DNS: Proposals to piggyback more sophisticated application behavior on top of the DNS, however, have raised questions about the propriety of instantiating some features in that way, especially those with security sensitivities. This establishes the actual focus of the draft on fears of misuse, rather than on guidance for proper enhancement. It offers to explore architectural consequences of installing application features in the DNS and to offer guidance for such efforts. However it does not explain what it means by application features in the DNS, and it offers little discussion and less substance about architecture or guidance. The draft has four major sections. Motivations: This summarizes DNS background, goals and earlier enhancements. The section demonstrates a misunderstanding of the basis and history of the DNS, forming its premises from a simplistic and narrow assessment of popular DNS usage, rather than from the service's design, as captured in the above RFC 882 text. For example the draft treats some features as unexpected enhancements when they were part of the original vision. The draft also appears to be unaware that mnemonic host names were in use for more than 10 years before the DNS was defined and that the primary motivations for the DNS were administration and operations scaling, not merely the creation of symbolic names. The statement that the principal purpose of the DNS is to translate names to IP Addresses suggests that the in-addr.arpa use and any use of CNAME do not represent principal purposes. The original DNS design discussion is in terms that are more generic than this draft acknowledges. Hence the original use of resource rather than the draft's focus on host and address. Overview of DNS Applications Usages: This lays out three basic services, covering service lookup, transforming one name into another using NAPTR or DDDS, and storage of arbitrary content. The draft appears to misunderstand that DDDS is an independent layered service, which merely has a sub-component that is specified to map onto existing DNS services. Rather, the draft discusses it as if DDDS makes a change to the DNS. It makes no change and there is nothing obvious in the design or operation of the mapping component that will cause problems for the DNS. Challenges for the DNS: This lists service needs that might be problematic, covering compound queries and including requester-specific responses, as well as metadata about tree structure, and domain redirection. The first two have no apparent constituency in current DNS work and discussion of the latter provides no explanation of the substantive problems that supposedly would be caused. Principles and Guidance: This offers advice for the types of services that do and do not make sense to attempt via the DNS. It postulates use of HTTP as an alternative, but without any concrete design or operational experience. As always, untested and unimplemented, hypothetical alternatives fare better in an analysis against real-world ones, because they are not required to suffer real-world constraints and costs nor to demonstrate real-world operational superiority. In general, the document needs to be much
RE: [paws] WG Review: Protocol to Access White Space database (paws)
When I hear the term device identity spoofing, IEEE 802.1ar comes to mind (see http://standards.ieee.org/getieee802/download/802.1AR.-2009.pdf). In addition to the liaisons with IEEE 802.19, 802.22 and IEEE 802.11af, is there a liaison contemplated to IEEE 802.1 relating to device identity? From: scott.proba...@nokia.com To: stephen.farr...@cs.tcd.ie; ietf@ietf.org Subject: RE: [paws] WG Review: Protocol to Access White Space database (paws) Date: Wed, 20 Apr 2011 14:41:23 + CC: p...@ietf.org; i...@ietf.org Hi Stephen, All, I believe the current wording Robust security mechanisms are required to prevent: device identity spoofing, modification of device requests, modification of channel enablement information, ... is acceptable because mechanisms are required means they should be in the protocol, it does not mean they cannot be optional. PAWS should support Regulator requirements globally, and thus I believe there will be procedures or capabilities which are required to be in the protocol but will be optional during run time. Thus different or conflicting requirements from different regions of the world can be supported. (Several regulatory groups around the world are still developing their views and requirements). It's not the time to dig deep into proposed solutions, just my opinion is the current proposed wording is an acceptable definition to allow a Work Group to get started defining the details. Regards, Scott -Original Message- From: paws-boun...@ietf.org [mailto:paws-boun...@ietf.org] On Behalf Of ext Stephen Farrell Sent: Tuesday, April 19, 2011 4:28 PM To: IETF-Discussion Cc: p...@ietf.org; i...@ietf.org Subject: Re: [paws] 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 ___ paws mailing list p...@ietf.org https://www.ietf.org/mailman/listinfo/paws ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [paws] WG Review: Protocol to Access White Space database (paws)
Building from Bernard's note, it strikes me that if we are going to get into device identity, we probably need to be communicating with (liaise) 3GPP/3GPP2, because they have very strong views on that topic. (Whether one agrees or disagrees with their biases, talking to them seems important.) Yours, Joel On 4/20/2011 10:55 AM, Bernard Aboba wrote: When I hear the term device identity spoofing, IEEE 802.1ar comes to mind (see http://standards.ieee.org/getieee802/download/802.1AR.-2009.pdf). In addition to the liaisons with IEEE 802.19, 802.22 and IEEE 802.11af, is there a liaison contemplated to IEEE 802.1 relating to device identity? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [paws] WG Review: Protocol to Access White Space database (paws)
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 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. -
Re: [paws] WG Review: Protocol to Access White Space database (paws)
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 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
RE: [paws] WG Review: Protocol to Access White Space database (paws)
Hi Stephen, All, I believe the current wording Robust security mechanisms are required to prevent: device identity spoofing, modification of device requests, modification of channel enablement information, ... is acceptable because mechanisms are required means they should be in the protocol, it does not mean they cannot be optional. PAWS should support Regulator requirements globally, and thus I believe there will be procedures or capabilities which are required to be in the protocol but will be optional during run time. Thus different or conflicting requirements from different regions of the world can be supported. (Several regulatory groups around the world are still developing their views and requirements). It's not the time to dig deep into proposed solutions, just my opinion is the current proposed wording is an acceptable definition to allow a Work Group to get started defining the details. Regards, Scott -Original Message- From: paws-boun...@ietf.org [mailto:paws-boun...@ietf.org] On Behalf Of ext Stephen Farrell Sent: Tuesday, April 19, 2011 4:28 PM To: IETF-Discussion Cc: p...@ietf.org; i...@ietf.org Subject: Re: [paws] 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 ___ paws mailing list p...@ietf.org https://www.ietf.org/mailman/listinfo/paws ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAOC: delegating ex-officio responsibility
Hi Bob, At 14:04 19-04-2011, Bob Hinden wrote: 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. Yes, it may happen that some IAOC members may not have a lot of IETF experience. How do you ensure that the IAOC members have a lot of IETF experience? You can tweak the governance model. The IETF community also have to be convinced that it is the better model or else it will be changed. There are some safeguards in the IETF model that I won't get into. It's merely a matter of time for that to change. I'll list the names of the people who have participated on this thread: Dave Crocker Lucy Lynch John Klensin Russ Housley Jari Arkko Olaf Kolkman Brian Carpenter Henk Uijterwaal Leslie Daigle Ole Jacobsen Marshall Eubanks Joe Touch Joel Jaeggli Steve Crocker Michael Richardson Barry Leiba Spencer Dawkins Bert Wijnen The people listed below were part of NomCom: Gregory Cauchie Mehmet Ersue Dorothy Gellert Tony Hansen Suresh Krishnan Dirk Kroeselberg Jan Seedorf Pete St. Pierre Rolf Winter You may notice that there isn't any intersection with the previous list. 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. I did not comment on getting a quorum previously as it's only adding one more problem to the mix. The IAOC decides the details about its decision-making rules, including its rules for quorum, conflict of interest, and breaking of ties. I agree with you that the views of the I* Chairs are important. It also helps avoid back and forth discussion between I* bodies; e.g. is this an IESG decision or can the IAOC decide. I don't think that the IAB or the IESG can be absolved from the responsibility if the IAOC takes a negative turn as each of them chooses an IAOC member. If the ex-IAB Chair and the IESG Chair ask for a change to the model due to the workload, is it on a whim? This is where people walk away from a problem because they tried and got stone-walled. If the IETF believes that it is appropriate to mince everything they can get out of a person in the name of good governance, so be it. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAOC: delegating ex-officio responsibility
On 4/19/2011 12:53 PM, Bob Hinden wrote: 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. For clarification: 1. The IAB, IESG and ISOC each put two voting people onto the IAOC/Trust today. My proposal preserves that. 2. The intent behind moving the I* Chairs to non-voting status, like the IAD, is to ensure that they can continue to participate but remove from the the requirement for daily IAOC/Trust activities. The presumption is that they dive in for the big stuff, of the sort you cited, but do not have the burden of regular participation. For emphasis: As SM notes, my starting point is two of these folk saying they have to have a change. Looking at the list of their duties, no one should be surprised that they feel (and are) overloaded. So, they looked over their current duties and decided this is the one they'd like to change. I don't have -- and haven't heard anyone else suggest -- that some other change in their duties would be more appropriate. So I see the relevant question as how to make a change, not whether. d/ ps. As for the broader concern about having a sufficient base of experience on the IAOC/Trust, that applies for all appointments to all of our management groups. Worse, we have a continuing challenge to select for the right kinds of experience. For example, merely hanging around the IETF for a long time does not mean one knows how to manage an area or manage a budget. (I'm stating the obvious. The reason is that I don't see the current effort to change I* Chair participation in the IAOC/Trust as changing this issue.) -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAOC: delegating ex-officio responsibility
Dave CROCKER d...@dcrocker.net wrote: On 4/19/2011 12:53 PM, Bob Hinden wrote: [Dave CROCKER d...@dcrocker.net wrote:] 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 always respect Dave's suggestions. (Of course, I don't always agree with them... ;^) 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. I usually respect Bob's suggestions, but I don't always understand them. (In particular, he's lost me here.) It also significantly changes the governance model by changing the balance between between nomcom, iab, iesg, and ISOC appointed members. The change in balance seems rather minimal -- but that could certainly be fine-tuned. Also, adding six people (still counting the chairs) will make the IAOC much larger and unwieldy. That I understand. Perhaps we shouldn't be adding any... However, Russ Olaf seem to think there's work they have been expected to do. How will that work get done? Is the proposal first floated simply telling them the work is their responsibility -- and they need to find volunteers to do it? Us hoi-polloi aren't getting these details! For clarification: 1. The IAB, IESG and ISOC each put two voting people onto the IAOC/Trust today. My proposal preserves that. 2. The intent behind moving the I* Chairs to non-voting status, like the IAD, is to ensure that they can continue to participate but remove from the the requirement for daily IAOC/Trust activities. The presumption is that they dive in for the big stuff, of the sort you cited, but do not have the burden of regular participation. I have a slightly different view: that the IAOC is entitled to try to entice them into participation, but they would have the right to say No. For emphasis: As SM notes, my starting point is two of these folk saying they have to have a change. Looking at the list of their duties, no one should be surprised that they feel (and are) overloaded. So, they looked over their current duties and decided this is the one they'd like to change. I don't have -- and haven't heard anyone else suggest -- that some other change in their duties would be more appropriate. So I see the relevant question as how to make a change, not whether. I agree. Hopefully most of us can agree. Charging them to find someone to do the work feels wrong to me. Moving them to non-voting status feels right. Enabling them to participate in areas they feel critical feels right. Adding other individuals with voting status seems reasonable, but not-exactly-right. Perhaps the most important change would be simply not counting them for purposes of quorum... -- John Leslie j...@jlc.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Revising I-Ds became painful
Hi, It seems like I-D submission for a revised draft (after expiration) encounters so many new hurdles: 1. Version number. Submission page complains about the version number even though it is correct. This seems to be because the system keeps the expiration message in html format as the new version to be submitted. Is there a way to get around this? 2. RFC XML has changed. It seem like xml.resource.org has a new xml compiler. I had a lot of trouble in compiling my existing xml files. I am OK with improving RFC XML but why not keep upward compatibility? Regards, Behcet ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [paws] WG Review: Protocol to Access White Space database (paws)
- Original Message - From: Joel M. Halpern j...@joelhalpern.com To: Rex Buddenberg bud...@nps.navy.mil Cc: Paul Lambert p...@marvell.com; p...@ietf.org; i...@ietf.org; IETF discussion list ietf@ietf.org Sent: Wednesday, April 20, 2011 4:17 AM Subject: 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. Joel I see one small parallel with SNMP. All the recent work on SNMP has been on security, and while setting up a secure channel is easy, TLS or SSH, knowing that it goes where you want it to as opposed to via a MITM is more difficult, both when the device calls home to send an alert, or when home calls the device to solicit information. And the credentials used by the transport need binding securely to the identity at a higher layer. This was troublesome and I will be interested to see how this is solved. By comparison I expect that the application will fall out in the wash. Channel binding anyone? One for the security area? Tom Petch 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
Re: [paws] WG Review: Protocol to Access White Space database (paws)
GEOLOC has been a WG that is somewhat on the edge between Apps and RAI. Much of what geoloc was doing, particularly the location for emergency calling, had real time issues and the interested people largely lined up with the the other RAI groups even though geoloc has uses outside anything to do with SIP. PAWS on the other hand does not seem to have real time application issues so it seems like Apps is probably a more appropriate area for it. Cullen On Apr 19, 2011, at 11:50 AM, Joel M. Halpern wrote: 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
Re: IAOC: delegating ex-officio responsibility
On 2011-04-20 21:13, SM wrote: Hi Bob, At 14:04 19-04-2011, Bob Hinden wrote: 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. ... You may notice that there isn't any intersection with the previous list. I think you are overlooking that some of the people in the first list have been in liaison positions in NomCom; in terms of understanding NomCom's challenges, that is sufficient. In any case, the difficulty of finding available candidates is quite apparent. ... I agree with you that the views of the I* Chairs are important. In the case of the IETF Chair I believe the issue is that it's highly desirable, from a governance viewpoint, that the IETF Chair has *personal* responsibility in IAOC decisions, and therefore should be a voting member as a matter of principle. I don't believe that argument applies to the IAB Chair - we should IMHO have a collective goal to sharply reduce the IAB's involvement in administrative issues, so that it can do its architectural and liaison jobs properly. Delegating the IAB Chair role in the IAOC would be a step in that direction, along with appointing the permanent RFC Series Editor. We haven't discussed the third proposed delegation, that of the ISOC President's seat, very much. Assuming it was delegated to another officer of ISOC, that would seem reasonable too. But it shouldn't be delegated to just anybody, IMHO. Brian Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAOC: delegating ex-officio responsibility
Brian, If we are going to do this, then I tend to agree with your conclusions. I agree with you that the views of the I* Chairs are important. In the case of the IETF Chair I believe the issue is that it's highly desirable, from a governance viewpoint, that the IETF Chair has *personal* responsibility in IAOC decisions, and therefore should be a voting member as a matter of principle. My preference is that the IETF not delegate this responsibility. One additional reason for this is that the IETF chair is appointed by the nomcom (vs. the IAB who appoints their own chair). It is part of the job and an important part. I don't believe that argument applies to the IAB Chair - we should IMHO have a collective goal to sharply reduce the IAB's involvement in administrative issues, so that it can do its architectural and liaison jobs properly. Delegating the IAB Chair role in the IAOC would be a step in that direction, along with appointing the permanent RFC Series Editor. In the case of the IAB, I would prefer that the IAB selected it's representative to the IAOC and that they become the full IAOC voting member (and a member of the IETF trust). That is, it be completely delegated for a fixed term. The IAB could consider this person as a vice-chair or even a co-chair. The both represent other ways to reduce the load on the chair. We haven't discussed the third proposed delegation, that of the ISOC President's seat, very much. Assuming it was delegated to another officer of ISOC, that would seem reasonable too. But it shouldn't be delegated to just anybody, IMHO. Also agree. I think it should be limited to the CFO or COO. I think, as above with the IAB, it should be fully delegated. Bob ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Revising I-Ds became painful
On 4/21/2011 12:18 AM, Behcet Sarikaya wrote: Hi, It seems like I-D submission for a revised draft (after expiration) encounters so many new hurdles: 1. Version number. Submission page complains about the version number even though it is correct. This seems to be because the system keeps the expiration message in html format as the new version to be submitted. Is there a way to get around this? Don't let I-Ds expire? 2. RFC XML has changed. It seem like xml.resource.org has a new xml compiler. I had a lot of trouble in compiling my existing xml files. Hmm. I'm not experiencing any problems, either with the on-line or the host based tools. Are you sure that your XML was valid before? I am OK with improving RFC XML but why not keep upward compatibility? Regards, Behcet ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf attachment: gwz.vcf___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
CLUE WG Virtual Interim Meeting: May 12, 2011
The CLUE WG will hold an interim virtual meeting on: 2011-05-12, 15.00-17.00 GMT (starting at 8.00 Pacific, 10.00 Central, 11.00 Eastern). Agenda and details will be announced on the CLUE WG mailing list (http://www.ietf.org/mail-archive/web/clue/) as soon as available. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6111 on Additional Kerberos Naming Constraints
A new Request for Comments is now available in online RFC libraries. RFC 6111 Title: Additional Kerberos Naming Constraints Author: L. Zhu Status: Standards Track Stream: IETF Date: April 2011 Mailbox:l...@microsoft.com Pages: 6 Characters: 14113 Updates:RFC4120 I-D Tag:draft-ietf-krb-wg-naming-07.txt URL:http://www.rfc-editor.org/rfc/rfc6111.txt This document defines new naming constraints for well-known Kerberos principal names and well-known Kerberos realm names. [STANDARDS- TRACK] This document is a product of the Kerberos WG 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
RFC 6112 on Anonymity Support for Kerberos
A new Request for Comments is now available in online RFC libraries. RFC 6112 Title: Anonymity Support for Kerberos Author: L. Zhu, P. Leach, S. Hartman Status: Standards Track Stream: IETF Date: April 2011 Mailbox:larry@microsoft.com, pau...@microsoft.com, hartmans-i...@mit.edu Pages: 16 Characters: 37858 Updates:RFC4120, RFC4121, RFC4556 I-D Tag:draft-ietf-krb-wg-anon-12.txt URL:http://www.rfc-editor.org/rfc/rfc6112.txt This document defines extensions to the Kerberos protocol to allow a Kerberos client to securely communicate with a Kerberos application service without revealing its identity, or without revealing more than its Kerberos realm. It also defines extensions that allow a Kerberos client to obtain anonymous credentials without revealing its identity to the Kerberos Key Distribution Center (KDC). This document updates RFCs 4120, 4121, and 4556. [STANDARDS-TRACK] This document is a product of the Kerberos WG 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
RFC 6113 on A Generalized Framework for Kerberos Pre-Authentication
A new Request for Comments is now available in online RFC libraries. RFC 6113 Title: A Generalized Framework for Kerberos Pre-Authentication Author: S. Hartman, L. Zhu Status: Standards Track Stream: IETF Date: April 2011 Mailbox:hartmans-i...@mit.edu, larry@microsoft.com Pages: 48 Characters: 121122 Updates:RFC4120 I-D Tag:draft-ietf-krb-wg-preauth-framework-17.txt URL:http://www.rfc-editor.org/rfc/rfc6113.txt Kerberos is a protocol for verifying the identity of principals (e.g., a workstation user or a network server) on an open network. The Kerberos protocol provides a facility called pre-authentication. Pre-authentication mechanisms can use this facility to extend the Kerberos protocol and prove the identity of a principal. This document describes a more formal model for this facility. The model describes what state in the Kerberos request a pre-authentication mechanism is likely to change. It also describes how multiple pre-authentication mechanisms used in the same request will interact. This document also provides common tools needed by multiple pre-authentication mechanisms. One of these tools is a secure channel between the client and the key distribution center with a reply key strengthening mechanism; this secure channel can be used to protect the authentication exchange and thus eliminate offline dictionary attacks. With these tools, it is relatively straightforward to chain multiple authentication mechanisms, utilize a different key management system, or support a new key agreement algorithm. [STANDARDS-TRACK] This document is a product of the Kerberos WG 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
RFC 6169 on Security Concerns with IP Tunneling
A new Request for Comments is now available in online RFC libraries. RFC 6169 Title: Security Concerns with IP Tunneling Author: S. Krishnan, D. Thaler, J. Hoagland Status: Informational Stream: IETF Date: April 2011 Mailbox:suresh.krish...@ericsson.com, dtha...@microsoft.com, jim_hoagl...@symantec.com Pages: 20 Characters: 45018 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-v6ops-tunnel-security-concerns-04.txt URL:http://www.rfc-editor.org/rfc/rfc6169.txt A number of security concerns with IP tunnels are documented in this memo. The intended audience of this document includes network administrators and future protocol developers. The primary intent of this document is to raise the awareness level regarding the security issues with IP tunnels as deployed and propose strategies for the mitigation of those issues. [STANDARDS-TRACK] This document is a product of the IPv6 Operations Working Group of the IETF. 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 6197 on Location-to-Service Translation (LoST) Service List Boundary Extension
A new Request for Comments is now available in online RFC libraries. RFC 6197 Title: Location-to-Service Translation (LoST) Service List Boundary Extension Author: K. Wolf Status: Experimental Stream: IETF Date: April 2011 Mailbox:karlheinz.w...@nic.at Pages: 15 Characters: 27562 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-ecrit-lost-servicelistboundary-05.txt URL:http://www.rfc-editor.org/rfc/rfc6197.txt Location-to-Service Translation (LoST) maps service identifiers and location information to service contact URIs. If a LoST client wants to discover available services for a particular location, it will perform a listServicesByLocation query to the LoST server. However, the LoST server, in its response, does not provide context information; that is, it does not provide any additional information about the geographical region within which the returned list of services is considered valid. Therefore, this document defines a Service List Boundary that returns a local context along with the list of services returned, in order to assist the client in not missing a change in available services when moving. This document defines an Experimental Protocol for the Internet community. This document is a product of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. 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 6213 on IS-IS BFD-Enabled TLV
A new Request for Comments is now available in online RFC libraries. RFC 6213 Title: IS-IS BFD-Enabled TLV Author: C. Hopps, L. Ginsberg Status: Standards Track Stream: IETF Date: April 2011 Mailbox:cho...@cisco.com, ginsb...@cisco.com Pages: 7 Characters: 15527 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-isis-bfd-tlv-03.txt URL:http://www.rfc-editor.org/rfc/rfc6213.txt This document describes a type-length-value (TLV) for use in the IS-IS routing protocol that allows for the proper use of the Bidirectional Forwarding Detection (BFD) protocol. There exist certain scenarios in which IS-IS will not react appropriately to a BFD-detected forwarding plane failure without use of either this TLV or some other method. [STANDARDS-TRACK] This document is a product of the IS-IS for IP Internets 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
