IESG appointment to the IETF Trust
According to recently approved procedures for populating the IETF Trust described in RFC 8714, the IESG is required to appoint one person to the IETF Trust for a two-year term to begin in March 2020. After careful consideration, the IESG has decided to reappoint Stephan Wenger to this position. The IESG would like to congratulate Stephan and thank him for volunteering for this task. We would also like to thank all the candidates who accepted nominations to this position, and everyone from the community who provided feedback to the IESG on these candidates. On behalf of the IESG, Suresh Krishnan Internet Area Director ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Call for feedback: IESG appointment to the IETF Trust
The IESG is responsible for appointing one person to the IETF Trust for a two-year term to begin in March 2020. A call for nominations was sent out and the following candidates have accepted a nomination: o Stephan Wenger, currently serving as the IESG appointee on a one year term o Hago Dafalla o Michael Richardson (We also had one more candidate, Glenn Deen, who had accepted a nomination but has since been selected as the Nomcom appointee for the IETF Trust) Please send feedback about these three candidates to suresh.krish...@gmail.com. This feedback will be held in confidence by the IESG. Please provide the feedback by February 6, 2020. We thank you in advance for your help. On behalf of the IESG, Suresh Krishnan Internet Area Director ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Reminder: Call for nominations: IESG appointment to the IETF Trust
The purpose of the IETF Trust is to acquire, hold, maintain, and license certain existing and future intellectual property and other property used in connection with the administration of the IETF <https://tools.ietf.org/html/rfc4371 <https://tools.ietf.org/html/rfc4371>>. More information about the IETF Trust can be found at <https://trustee.ietf.org/ <https://trustee.ietf.org/>>. According to recently approved procedures for populating the IETF Trust <https://tools.ietf.org/html/draft-ietf-iasa2-trust-update-03 <https://tools.ietf.org/html/draft-ietf-iasa2-trust-update-03>>, the IESG is required to appoint one person to the IETF Trust for a two-year term to begin in March 2020. DESIRABLE QUALIFICATIONS AND SELECTION CRITERIA The Trust is mostly a quiet organization, and being a trustee generally involves little work beyond quarterly online meetings. Trustees ideally should be: o Familiar with copyright and trademark law. o Familiar with the RFC publication process as described in RFC 6635 and related documents. o Familiar with the Trust's copyright licenses and with RFCs 5377 and 5378. o Willing to serve multiple terms as a trustee to provide continuity of oversight. NOMINATIONS AND ELIGIBILITY The IESG is making a public call for nominations. Self-nominations are permitted. All IETF participants, including working group chairs, IETF NomCom members, IAB members, IESG members, and candidates for the IETF LLC Board are eligible for nomination. Of course, IESG members who accept nomination will recuse themselves from selection discussions. Persons who are under consideration by the Nomcom in the 2019-2010 cycle for the open IETF Trust position are also welcome to apply. Please send nominations to iesg at ietf.org <http://ietf.org/>. Please include the following with each nomination: o Name o Contact information o Candidate background and qualifications SELECTION The IESG will publish the list of nominated persons prior to making a decision, allowing time for the community to provide any relevant comments to the IESG. The IESG will review the nomination material, any comments provided by the community, and make a selection. CARE OF PERSONAL INFORMATION The following procedures will be used in managing candidates' personal information: o The list of candidate names will be published at the close of the nominations period. A candidate that refuses the nomination will not be included on the list. o Except as noted above, all information provided to the IESG during this process will be kept as confidential to the IESG. TIMEFRAME The nominations period opened on December 5, 2019 and will close on January 5, 2020. The list of candidates will be posted shortly after the close of nominations, and the community will then have two weeks to provide comments on the candidates to the IESG. The IESG will consider the community feedback and make its decision. If the candidate pool overlaps with the NomCom's IETF Trust candidate pool, the IESG will wait to announce a selection until the Nomcom announces its selections for the IETF Trust, to avoid a race condition. On behalf of the IESG, Suresh Krishnan Internet Area Director ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Call for nominations: IESG appointment to the IETF Trust
The purpose of the IETF Trust is to acquire, hold, maintain, and license certain existing and future intellectual property and other property used in connection with the administration of the IETF <https://tools.ietf.org/html/rfc4371 <https://tools.ietf.org/html/rfc4371>>. More information about the IETF Trust can be found at <https://trustee.ietf.org/ <https://trustee.ietf.org/>>. According to recently approved procedures for populating the IETF Trust <https://tools.ietf.org/html/draft-ietf-iasa2-trust-update-03 <https://tools.ietf.org/html/draft-ietf-iasa2-trust-update-03>>, the IESG is required to appoint one person to the IETF Trust for a two-year term to begin in March 2020. DESIRABLE QUALIFICATIONS AND SELECTION CRITERIA The Trust is mostly a quiet organization, and being a trustee generally involves little work beyond quarterly online meetings. Trustees ideally should be: o Familiar with copyright and trademark law. o Familiar with the RFC publication process as described in RFC 6635 and related documents. o Familiar with the Trust's copyright licenses and with RFCs 5377 and 5378. o Willing to serve multiple terms as a trustee to provide continuity of oversight. NOMINATIONS AND ELIGIBILITY The IESG is making a public call for nominations. Self-nominations are permitted. All IETF participants, including working group chairs, IETF NomCom members, IAB members, IESG members, and candidates for the IETF LLC Board are eligible for nomination. Of course, IESG members who accept nomination will recuse themselves from selection discussions. Persons who are under consideration by the Nomcom in the 2019-2010 cycle for the open IETF Trust position are also welcome to apply. Please send nominations to iesg at ietf.org <http://ietf.org/>. Please include the following with each nomination: o Name o Contact information o Candidate background and qualifications SELECTION The IESG will publish the list of nominated persons prior to making a decision, allowing time for the community to provide any relevant comments to the IESG. The IESG will review the nomination material, any comments provided by the community, and make a selection. CARE OF PERSONAL INFORMATION The following procedures will be used in managing candidates' personal information: o The list of candidate names will be published at the close of the nominations period. A candidate that refuses the nomination will not be included on the list. o Except as noted above, all information provided to the IESG during this process will be kept as confidential to the IESG. TIMEFRAME The nominations period will open on December 5, 2019 and close on January 5, 2020. The list of candidates will be posted shortly after the close of nominations, and the community will then have two weeks to provide comments on the candidates to the IESG. The IESG will consider the community feedback and make its decision. If the candidate pool overlaps with the NomCom's IETF Trust candidate pool, the IESG will wait to announce a selection until the Nomcom announces its selections for the IETF Trust, to avoid a race condition. On behalf of the IESG, Suresh Krishnan Internet Area Director ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Re: IETF Diversity
Hi Phil, On 06/18/2013 02:08 PM, Phillip Hallam-Baker wrote: When I make a statement at the microphone and then have multiple people come to thank me afterwards for making that point I don't consider it pontificating. I do however consider your own response to be an example of the type of exclusionary behavior that I was talking about. Dismissing those concerns as 'pontificating' does not help matters. And you have no idea what actions I have taken to attempt to recruit people to get involved. The issue was raised in the IETF plenary I would have expected mention of a followup mailing list to be made here on the ietf discussion list. Apologies. The announcement of the diversity list was sent to the IETF announcement list and not the discussion list. The diversity list can be found here as Dave C. mentioned. https://www.ietf.org/mailman/listinfo/diversity Thanks Suresh
Diversity: Call for community input
Hi all, The diversity design team is working on mechanisms to increase the range of perspectives within the IETF, while maintaining high standards of quality. Our goal is to help improve the composition and dynamic of the IETF, by finding ways to incorporate a wide range of perspectives within the IETF, and specifically in the IETF management teams. One way of achieving this is to ensure that participants differ along many different personal, social, and professional attributes. The expectation is that the greater range of perspectives leads to considering issues more deeply and with more sensitivity. Community feedback is the most important input that helps us determine the aspects are currently working well in the IETF in this regard and those that are not. We cannot properly execute the task of proposing new mechanisms or modifying existing mechanisms to further these goals without **your** participation and feedback. We would like to help the IETF management make choices that maximize the IETF's ability to include and encourage all interested participants, and maximize their contributions to IETF work. On that basis, we are seeking input from people based on their personal experiences about * actions and activities that have worked well to improve the inclusiveness of the IETF process * actions and activitiets that have not worked well to improve the inclusiveness of the IETF process * actions and activities that have worked *against* inclusiveness of the IETF process If you have experience with other technology based organisations that have broad consultation practices, we would also like to hear about examples of actions taken that work well to include participation from diverse communities Please provide us your input by sending an email to the diversity design team at diversity...@ietf.org . You can provide **anonymous** feedback by contacting either of the design team leads Suresh Krishnan suresh.krish...@ericsson.com and Kathleen Moriarty kathleen.moria...@emc.com who will anonymize it for the rest of the members. Thanks Suresh Krishnan Kathleen Moriarty for the diversity design team Design team members === Narelle Clark Dave Crocker Aaron Yi Ding Lars Eggert SM Monique Morrow Hugo Salgado Arturo Servin Margaret Wasserman Scott Weeks
Re: Gen-ART review of draft-ietf-intarea-nat-reveal-analysis-05
Hi Peter, Thanks a lot for your review. I will ask the authors to address your comments in the next version of the draft. Regards Suresh On 03/09/2013 03:13 AM, Peter Yee wrote: I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq Document: draft-ietf-intarea-nat-reveal-analysis-05 Reviewer: Peter Yee Review Date: Mar-08-2013 IETF LC End Date: Mar-08-2013 IESG Telechat date: TBD Summary: This draft is on the right track but has open issues, described in the review. [Ready with issues.] This draft catalogs and analyzes various means of supplying a host identifier to a remote server when Carrier Grade NAT or similar host obscuring technology is in use. General: There were sentences in the draft that I could not parse even in the context of surrounding text. That's primarily why I'm marking this draft as Ready with issues. These sentences are supplied below. Mostly, the document has a fair number of nits. The general concept is fine. General: hyphenate uses of address sharing when it used as an adjective. For example, address-sharing device. General: expand acronyms on first use except if they are really well known in our community (e.g., TCP/IP) or where they appear in the abstract. Examples of acronyms in need of expansion are HIP, XFF, S. General: You will probably want to resolve Internet Draft references to something more permanent. General: The term broken should be replaced with something more specific or useful. I've made some suggestions below. Section 1, 2nd paragraph, last sentence: delete an before information. Section 1, 3rd paragraph: change are to include. Section 1, 3rd paragraph: change customers unsatisfaction to and customers' dissatisfaction. Section 2, 1st paragraph, 2nd sentence: delete an before extra. Change than to beyond. Section 2, 1st paragraph, 3rd sentence: replace this sentence with We call this information the HOST_ID. Section 2, 2nd paragraph: add a serial comma after subscriber. Serial comma use in the draft was inconsistent. Section 2, 3rd paragraph, 3rd sentence: I'm not sure why the HOST_ID and public IP address would be relatively unique. Assuming that HOST_IDs are unique amongst the hosts hidden behind the public IP address and the public IP address is unique, I would have thought that the combination was globally unique. My confusion may arise from the 4th sentence which is incomplete. Perhaps those two sentences could be rewritten for clarity. Section 2, 4th paragraph, 1st sentence: change put to conveyed. Section 2, 4th paragraph, 2nd sentence: change put to conveyed. Section 3, 2nd paragraph, 1st sentence: considering using identifiability instead of uniqueness. Section 3, 2nd paragraph, 2nd sentence: replace which with what. Section 3,1, 4th paragraph: add a comma after re-write. Change re-write to rewrite. Section 3.1, 5th paragraph: I don't quite follow what's being said here. Is the point that the address-sharing function should reveal the same HOST_ID for any given host regardless of what layer or mechanism that HOST_ID is being conveyed across? How does this relate to interference between HOST_IDs? Section 4.1.1, 1st paragraph, 1st sentence: delete an before information. Section 4.1.1, 1st paragraph, 3rd sentence: insert , there are after hence. Section 4.1.1, 4th paragraph, consider replacing with: Address-sharing devices using this solution would be required to indicate that out of band, possibly using a special DNS record. Section 4.1.2, 3rd paragraph, 2nd sentence: add a comma after scenario. Change broken to ill-advised. Section 4.2.1, 1st paragraph, 2nd sentence: add A at the beginning of the sentence. Section 4.2.1, 1st paragraph, 4th sentence: rewrite as This IP option allows the conveyance of an IPv4 address, an IPv6 prefix, a GRE key, an IPv6 Flow Label, etc. Section 4.2.1, 2nd paragraph: insert an before IP. Section 4.2.2, 1st paragraph, 1st sentence: change for to to. Section 4.2.2, 1st paragraph, 2nd sentence: use of the term filter in this sentence is not clear. Do you mean that that routes and middleboxes remove the IP options? Or that they remove packets with IP options? Or that they take other actions based on the presence of IP options? Please clarify. Section 4.2.2, 2nd paragraph: replace As a with In. Define host-hint somewhere. Is it meant to be equivalent to HOST_ID? Section 4.3.1, 3rd sentence: change their to its both places in the sentence. Insert or before subscriber. Section 4.3.2, 2nd paragraph, 2nd sentence: insert a before HOST_ID Section 4.3.2, 2nd paragraph, 3rd sentence: change in host to on the host. Insert the before address, and add a comma after function. Section 4.3.2, 1st bullet item: this is the IETF. We
Re: Barely literate minutes
On 11/29/2012 05:27 PM, Randy Bush wrote: As a document author, I've learned that I need to have a friend take good notes for me, because all of the great comments I get at the mike are lost otherwise. this gap makes me crazy, so much is often lost. but i do not think technology or process will close this hole. too much depends on fairly deep understanding of the subject. I can't take notes while I'm standing up, facilitating discussion. +1. i can't take notes while i am trying to understand and think about the important semantics of a discussion, period. but much of this may be a personal failing, poor typist, rotting mind, ... I have this same issue as well. If I need to participate in a few discussions in the wg I decline to take minutes there as I do not believe I could do a good job with the minutes. For the record, as a minute taker, it takes me approximately 2x meeting time to come up with the minutes (I go back to the audio to fill in gaps, send individual mails to commenters to better understand their comments etc.) in addition to *almost completely* missing participation in the meeting. Thanks Suresh
Re: NomCom: Call for Nominations - IAOC Mid-Term Vacancy
Hi Eric, On 11/20/2012 10:20 AM, Eric Gray wrote: I think this is a point of confusion, anyway. I thought the process was for the previous NomCom to be coopted to address any unexpected mid-term vacancies, rather than to add the burden to the current NomCom. The previous Nomcom stayed constituted until the Atlanta meeting. If the vacancy was announced before Atlanta, the previous Nomcom would have filled the position. Right now, there is only one constituted Nomcom and it has to fill the position. Thanks Suresh
Re: NomCom: Call for Nominations - IAOC Mid-Term Vacancy
Hi Eric, On 11/20/2012 10:20 AM, Eric Gray wrote: I think this is a point of confusion, anyway. I thought the process was for the previous NomCom to be coopted to address any unexpected mid-term vacancies, rather than to add the burden to the current NomCom. The previous Nomcom stayed constituted until the Atlanta meeting. If the vacancy was announced before Atlanta, the previous Nomcom would have filled the position. Right now, there is only one constituted Nomcom and it has to fill the position. Thanks Suresh
Re: Change in I-D announcement format
Hi Tom, On 10/24/2012 09:28 AM, t.p. wrote: And now there seems to be another unannounced change, in that in addition to the usual announcement format e-mails, there may also be, or may not be, the appearance seems random, of Not so random. I noticed that the New Version Notification mails are sent to you if you are a) A co-author/editor of a newly submitted draft b) A wg chair for a newly submitted version of a WG document c) Other situations that do not apply to me :-) Thanks Suresh Subject: New Version Notification - e-mails. This may or may not be an improvement, depending on how long it takes me to work out what is happening and whether or not I then like my conclusion. And whether or not what I rely on is still available. Tom Petch
Re: Last Call: draft-ietf-6man-lineid-05.txt (The Line Identification Destination Option) to Experimental RFC
Hi Med, On 06/06/2012 08:04 AM, mohamed.boucad...@orange.com wrote: Dear Suresh, all, Even if the document includes several warnings about the unreliability of an RS-based mechanism, I suggest to add a pointer to the following document: http://tools.ietf.org/html/draft-dec-6man-rs-access-harmful-00. Is there something in particular that you think is missing from the lineid draft? The current warning text in lineid (and the reclassification to experimental) was arrived at after consultations with the the 6man chairs and the author of draft-dec. Thanks Suresh
Re: NomCom 2011-2012 feedback
Hi John, Thanks for your comments. Please see my response inline. On 11-11-01 04:48 PM, John C Klensin wrote: --On Sunday, October 30, 2011 23:01 -0400 Suresh Krishnan suresh.krish...@ericsson.com wrote: I noticed that the term transparency of the process only appears in two of the three questionnaires. Is there a reason for the omission? The omission is intentional. The text in question (transparency of the process) is about the handling of appeals. Since the IAOC is not involved in the handling of appeals the text does not appear in the IAOC questionnaire, But, Suresh, one of the more critical issues faced by the IAOC is precisely about transparency of process, even if it is not about appeals. The IESG and IAB have gotten hugely better about transparency in recent years -- narrative minutes and much more tracking that is available to the community for the former and clear opportunities for community review and feedback on documents and other important actions for the latter. I think the Nomcom should understand how candidates feel about that sort of transparency, but I wouldn't expect anyone to tell you that more secrecy would be in order. I agree with you, but I was not talking about whether transparency of process would be good for the IAOC or not. I was answering the question on why the text about handling appeals (that includes the words in question) only occurs on the IAB and IESG questionnaires. That is why I requested SM to send this feedback to the nomcom so that the *voting members* can decide whether this is something they want to consider during their evaluations. The voting members do want to listen to what the community considers important and they can only do that if people provide their feedback. I request you to send a note to the nomco...@ietf.org list with your views so that all the voting members can be apprised. Thanks Suresh ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: NomCom 2011-2012 feedback
Hi SM, On 11-10-29 11:14 AM, SM wrote: Dear 2011-2012 nominating committee members, You requested feedback from the IETF community for positions on the IESG, IAB and IAOC. As none of the candidates shared their views about a simple question that was asked on the IETF mailing list, I gather that none of them are reading the mailing list. I am in two minds about whether to provide feedback or not. I'll share with you why the decision is not so easy. If you feel that the position of the nominees on a specific issue is important to know, please send us a note about the issue and why you think it is important. There is this thing called social networks. They provide an important service as they enable little girls to keep us abreast of their state of well-being. You can even click on an I Like button to provide input about hotness. It is easier to determine whether the candidates would make an informed decision if they share their views on an IETF mailing list. I noticed that the term transparency of the process only appears in two of the three questionnaires. Is there a reason for the omission? The omission is intentional. The text in question (transparency of the process) is about the handling of appeals. Since the IAOC is not involved in the handling of appeals the text does not appear in the IAOC questionnaire, Thanks Suresh ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: What? This thread is talking about *voting* now?
Hi SM, On 11-10-27 08:09 AM, SM wrote: This year's NomCom has members from: North America 5 Cisco.com2 Juniper.net 2 Avaya.com1 Europe 2 Nokia.com1 NLnetlabs.nl 1 Asia 3 Huawei.com 2 Chinamobile.com 1 The correct numbers are North America: 3 Europe: 4 Asia: 3 In the nomcom case, the members with the cisco.com addresses are from Europe. :-) Thanks Suresh ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Nomcom
Hi John, Just responding to one specific concern (No. 3) you raised. I do believe that the other 3 (Nos. 1, 2 and 4) require process changes that cannot take place during the current nomcom cycle. On 11-10-27 11:25 AM, John C Klensin wrote: ...snipped... (3) I don't believe it has happened this year, but trends in the community predict that, sooner or later, we will have someone volunteer for a large number of positions simply because he or she (or whomever they work for) wants them in the IETF leadership. Someone ought to be able to write one comment that says Goofy wants to be in the leadership to enhance his resume and told several of us that at a Bar BOF and should not be selected for _any_ position. If you don't believe me alone, check with X, Y, or Z. In the current model, that would require writing a separate review for each position. Lots of make-work; might not happen at all. But a Nomcom would really want that input I think. You can already do this today. Just enter your feedback about the nominee into *any* one of the positions and state that it is for all the positions. The tool does not handle this case, but the humans behind certainly do. Thanks Suresh ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-gundavelli-v6ops-pmipv6-address-reservations-00.txt (Reserved IPv6 Interface Identifier for Proxy Mobile IPv6) to Informational RFC
Hi Sri, On 11-09-21 08:44 PM, Sri Gundavelli wrote: Two MAG's in the same broadcast domain can be ruled out, as there is no mechanism for the nodes to decide on who should support the attached MN. More over, we still have the P2P link assumption and so multiple MAG's in the same broadcast domain is not possible. So, we are fine on this aspect. Stepping back a bit, IMO, 5453 issue is not applicable for the P2P link and given that its a managed mobility domain. So, I wonder, if the concern is valid in PMIPv6 context ? I don't think that the concern is applicable in the PMIPv6 P2P link context. That is why I was fine with either of the methods for getting the IID. Thanks Suresh ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-gundavelli-v6ops-pmipv6-address-reservations-00.txt (Reserved IPv6 Interface Identifier for Proxy Mobile IPv6) to Informational RFC
Hi Jari, On 11-09-19 02:35 AM, Jari Arkko wrote: Following up with a personal comment. The draft allocates an interface ID and an EUI-64 MAC identifier from the IANA block. These are two separate, unrelated allocations. The main criticism in RFC 5453 for making additional interface ID allocations is that old implementations do not know about them and may collide when making an allocation. I'm wondering if it would be better to allocate an interface ID that is based on the allocated EUI-64 identifier per RFC 2464? Then we would at least use the same format as other interface IDs and a collision would likely mean inappropriate use of the IANA EUI-64 identifiers. Note that privacy and cryptographic addresses set the u/l bit to zero, whereas EUI-64 interface IDs usually have it at one. Sri's draft is silent on what kind of number should be allocated for the interface ID, perhaps some guidance here would be useful. This sounds like a great idea. I am not sure that IANA has a reserved EUI-64 block like you suggested, but they certainly have a ethernet address block (MAC-48). We can instruct the IANA to assign a MAC address that maps straight into the IID. e.g. 00-00-5E-00-03-00 and the IID 0200:5eff:fe00:0300 Thanks Suresh ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-gundavelli-v6ops-pmipv6-address-reservations-00.txt (Reserved IPv6 Interface Identifier for Proxy Mobile IPv6) to Informational RFC
Hi Sri, On 11-09-19 01:29 PM, Sri Gundavelli wrote: Hi Jari: In case of PMIPv6, we need the interface ID allocation for PMIv6 domain-wide usage. We may not be able tie this to a specific EUI-64 identifier derived from a MAC identifier of any individual MAG hosting this configuration. But, if your recommendation is to tie the IPv6 interface identifier to the reserved link-layer identifier (the other IANA action), that should be fine. But, the reserved block that Suresh has in his spec is not tied to any EUI-64 block ? That implies, we need an interface ID allocation from a new block ? Or, recommend the node to generate the interface ID based on the reserved Mac address and not allocate from the block Suresh created ? There are two ways by which you can get a stable reserved IID. One by reserving an IID block using an IANA registry and the other by getting a stable MAC48 that can be used to create an IID. The only danger with getting a stable MAC48 is that if you happen to have 2 MAGs in the same broadcast domain, it will lead to issues. Thanks Suresh ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-gundavelli-v6ops-pmipv6-address-reservations-00.txt (Reserved IPv6 Interface Identifier for Proxy Mobile IPv6) to Informational RFC
Hi Alex, On 11-07-29 09:02 AM, Alexandru Petrescu wrote: I do think that pmipv6 has some issues about how it does mag-mn interface. One solution to one issue may be this reserved iid. Is this updating the stds track rfc5453 reserved iids? No. It does not. RFC5453 explicitly sets up an IANA registry for setting up such IDs. This draft just uses that IANA registry. Thanks Suresh ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Nomcom 2011-2012: Second Call for Volunteers
This is the Second call for Volunteers for the 2011-12 Nomcom. We are just about halfway through the volunteer period so if you are considering volunteering, please do so very soon. We have had a very good response to the initial call for volunteers and I am pleased to report that we have 50 volunteers thus far whose qualifications have been confirmed by the secretariat. I have notified each of these volunteers by email. However, we would like to have many more volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF population. You have until 11:59 pm EDT July 10, 2011 to volunteer for Nomcom but it would be much better if you can volunteer as early as possible. If you volunteered before 21:00 EDT on June 21 to serve as a voting member and have not received a confirmation email from me, please re-submit and bring to my attention right away! Details about the process for volunteering for the Nomcom and the list of open positions for which the nominating committee is responsible are summarized in the initial announcement: https://datatracker.ietf.org/ann/nomcom/2938/ The 50 volunteers who have thus far been qualified by the secretariat are: Alia Atlas , Juniper Networks Lixia Zhang , UCLA Wassim Haddad , Ericsson Glen Zorn , Network Zen Richard Barnes , BBN Technologies Stephen Kent , BBN Technologies Scott Mansfield , Ericsson Tina TSOU , FutureWei Technologies Fernando Gont , UTN/FRH Karen Seo , BBN Technologies Jie Dong , Huawei Technologies Mach Chen , Huawei Technologies Co. Sheng Jiang , Huawei Technologies Co. Ltd. Dimitri Papadimitriou , Alcatel-Lucent Thomas D. Nadeau , CA Technologies David Meyer , Cisco Systems/University of Oregon Wesley George , Time Warner Cable Cullen Jennings , Cisco Stephen Hanna , Juniper Networks Stephan Wenger , Bidyo Keyur Patel , Cisco Systems Michael Hamilton , BreakingPoint Systems Behcet Sarikaya , Huawei USA Mark Townsley , Cisco Systems Fred Baker , Cisco Systems Brian Trammell , ETH Zurich Sam Hartman , Painless Security Chris Griffiths , Comcast George Michaelson , APNIC Jiankang Yao , CNNIC Sohel Khan , Comcast Dacheng Zhang , Huawei Lianshu Zheng , Huawei Technologies Hui Deng , China Mobile Gang Chen , China Mobile Mirja Kuhlewind , University of Stuttgart John E Drake , Juniper Networks Matt Lepinski , BBN Technologies Subir Das , Telcordia Technologies Inc Yi Zhao , Huawei John Scudder , Juniper Networks Christer Holmberg , LM Ericsson Teemu Savolainen , Nokia Samita Chakrabarti , Ericsson Jaap Akkerhuis , NLnet labs Jason Weil , Time Warner Cable Randy Bush , Internet Initiative Japan Christian Schmidt , Nokia Siemens Networks Sean Shen , CNNIC Lou Berger , LabN Consulting The primary activity for this nomcom will begin during IETF-81 in Quebec City and should be completed by January 2012. The nomcom will be collecting requirements from the community, as well as talking to candidates and to community members about candidates. There will be regularly scheduled conference calls to ensure progress. Thus, being a nomcom member does require some time commitment. Please volunteer by sending an email to me before 11:59 pm EDT July 10, 2011 as follows: To: suresh.krish...@ericsson.com Subject: Nomcom 2011-12 Volunteer Please include the following information in the body of the mail: Full Name: // As you enter in the IETF Registration Form, // First/Given name followed by Last/Family Name Current Primary Affiliation: // typically what goes in the Company // field in the IETF Registration Form Email Address(es): // all email addresses used to Register for the // past 5 IETF meetings // Please designate a Preferred email address for // contact if there is more than one email address Telephone number: // With country code (for confirmation if selected) Please expect an email response from me within 3 business days stating whether or not you are qualified. If you do not receive a response in this timeframe, please re-send your email with the tag RESEND: added to the subject line. If you are not yet sure you would like to volunteer, please consider that Nomcom members play a very important role in shaping the leadership of the IETF. Ensuring the leadership of the IETF is fair and balanced and comprised of those who can lead the IETF in the right direction is an important responsibility that rests on the IETF participants at large. Volunteering for the Nomcom is a good way of contributing in that direction. I will be publishing a more detailed target timetable, as well as details of the randomness seeds to be used for the RFC 3797 selection process within the next few days. Thank you in advance for your participation. Suresh Krishnan Nomcom Chair 2011-2012 Email: nomcom-ch...@ietf.org, suresh.krish...@ericsson.com ___ IETF-Announce
Nomcom 2011-12: Call for Volunteers
Hi All, The Nomcom process for 2011-2012 has started. Please go through the message below and consider volunteering for the Nomcom. Thanks Suresh Original Message Subject: Nomcom 2011-12: Call for Volunteers Date: Fri, 10 Jun 2011 22:56:06 -0400 From: NomCom Chair nomcom-ch...@ietf.org To: IETF Announcement list ietf-annou...@ietf.org The IETF nominating committee process for 2011-12 has begun. The IETF nominating committee appoints folks to fill the open slots on the IAOC, the IAB, and the IESG. The 10 nominating committee members are selected randomly from a pool of volunteers. The more volunteers, the better the chance we have of choosing a random yet representative cross section of the IETF population. The details of the nomcom process can be found in RFC 3777. To be eligible, volunteers for the nomcom need to have attended 3 of the past 5 IETF meetings as of the time this announcement goes out (i.e. IETF76-IETF80). If you qualify, and are not seeking appointment to any of the open positions this nomcom will be filling, please consider volunteering. The list of people and posts whose terms end with the March 2012 IETF meeting, and thus the positions for which the nominating committee is responsible, are as follows: IAB === Bernard Aboba Hannes Tschofenig Andrei Robachevsky Olaf Kolkman Spencer Dawkins Ross Callon IAOC Marshall Eubanks IESG Peter Saint-Andre (Applications) Jari Arkko (Internet) Dan Romascanu (Operations Management) Gonzalo Camarillo (RAI) Stewart Bryant (Routing) Sean Turner (Security) David Harrington (Transport) The primary activity for this nomcom will begin during IETF-81 in Quebec City and should be completed by January 2012. The nomcom will be collecting requirements from the community, as well as talking to candidates and to community members about candidates. There will be regularly scheduled conference calls to ensure progress. Thus, being a nomcom member does require some time commitment. Please volunteer by sending an email to me before 11:59 pm EDT July 10, 2011 as follows: To: suresh.krish...@ericsson.com Subject: Nomcom 2011-12 Volunteer Please include the following information in the body of the mail: Full Name: // As you enter in the IETF Registration Form, // First/Given name followed by Last/Family Name Current Primary Affiliation: // typically what goes in the Company // field in the IETF Registration Form Email Address(es): // all email addresses used to Register for the // past 5 IETF meetings // Please designate a Preferred email address for // contact if there is more than one email address Telephone number: // With country code (for confirmation if selected) Please expect an email response from me within 3 business days stating whether or not you are qualified. If you do not receive a response in this timeframe, please re-send your email with the tag RESEND: added to the subject line. If you are not yet sure you would like to volunteer, please consider that nomcom members play a very important role in shaping the leadership of the IETF. Ensuring the leadership of the IETF is fair and balanced and comprised of those who can lead the IETF in the right direction is an important responsibility that rests on the IETF participants at large. Volunteering for the nomcom is a good way of contributing in that direction. I will be publishing a more detailed target timetable, as well as details of the randomness seeds to be used for the RFC 3797 selection process within the next few days. Thank you in advance for your participation. Suresh Krishnan Nomcom Chair 2011-2012 Email: nomcom-ch...@ietf.org, suresh.krish...@ericsson.com ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Review of draft-ietf-dna-simple
Hi Bernard, On 10-08-19 06:00 PM, Bernard Aboba wrote: In that scenario, it makes sense to me. However, if the RA advertises the same prefixes would there be a reason to mark all addresses as inoperable? The reason I changed it to do it this way was to simplify RA processing. Now, the RA gets processed based on standard RFC4861/RFC4862 processing. In the earlier versions of the draft I was comparing the prefixes in the RA to those in the SDAT and selectively marking the absent prefixes as inoperable. Ralph suggested this simplification and it made perfect sense to do so. Thanks Suresh ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART review of draft-krishnan-v6ops-teredo-update-06
Hi Jari, Thanks for your comments. On 10-05-31 06:08 AM, Jari Arkko wrote: Thanks for your review! I have added the following RFC Editor notes as fixes: Please add Updates: RFC 4380 to the header. Please change s/RA/Router Advertisement (RA)/ on first occurrence. Similarly for s/RS/Router Solicitation (RS)/ After we agree with David on how to update the Security Considerations, I can submit a new revision that includes these fixes as well. Thanks Suresh ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: secdir review of draft-ietf-csi-send-cert-03
Hi Richard, Removing the stuff we agreed upon. On 10-05-31 08:22 PM, Richard L. Barnes wrote: Hey Suresh, Most of these comments look OK to me. Couple of responses inline. --Richard Sec 6 Para 4 The requirement for RFC 3779 extension seems to contradict the use of ETAs as Trust Anchor Material, i.e., the last sentence of the first paragraph in this section. Good catch. I am not sure how to resolve this. One way would be to specify that the ETA EE certificates are exempt from requiring the RFC3779 extensions. Do you have any suggestions? I think the rest of the section is clear enough -- the TA material either has to be a self-signed certificate or it has to be an ETA. So maybe you could just delete the phrase and MUST always refer to a certificate that includes a RFC 3779 address extension? Hmm. The ETA certificate itself does not need to have the RFC3779 extension in it, but the relying party needs to fetch an RTA certificate which will contain a RFC3779 extension. As an aside, do you want to specify that in the first case (the non-ETA case), the self-signed TA cert MUST conform to the RPKI profile? Will do. Thanks Suresh ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART LC review of draft-ietf-csi-send-cert
Hi Roni, Thanks a lot for the review. Please find responses inline. Roni Even wrote: Comments: The first two comments are about changes from RFC 3971, if they are intentional it may be good to have a section on changes from RFC 3971 and list these specific changes with backward interoperability issues if there are. 1. In section 4 second paragraph “SEND certificates MUST include the IP Resources extension for IPv6 Address …” Section 6.3.1 of RFC 3971 says “Router Authorization Certificates are X.509v3 certificates, as defined in RFC 3280, and SHOULD contain at least one instance of the X.509 extension for IP addresses, as defined in RFC 3779.” So why is it a MUST here. The csi wg explicitly made a decision to go with basing the SEND certificate profile on RPKI certificates [draft-ietf-sidr-res-certs] instead of coming up with a fresh profile based on RFC3971. This discrepancy is a result of that decision. I am not sure if there are any backward compatibility issues since the SEND spec did not specify the procedures for validating certificates without a IP resources extension, 2. The same paragraph has “Certified IPv6 address space SHOULD be expressed using either addressPrefix or addressesOrRange elements.” . Section 6.3.1 in RFC 3971 says “The X.509 IP address extension MUST contain at least one addressesOrRanges element” as for the addressPrefix according to this section “The X.509 IP address extension MAY contain additional IPv6 subnet prefixes, expressed as either an addressPrefix or an addressRange.” This is unintentional. I don't think the statement in question adds any value and can be safely removed. Is this ok? 3. In section 7 there are TBA1, TBA2 and TBA3, who will assign values for these IDs. The IDs have been allocated by the pkix wg. I have replaced the TBA values with the actual allocated values. Nits: 1. Section 5 has “an end user could local SEND deployment “ it looks like there is a missing word in this sentence OK. Replaced with an end user could perform local SEND deployment 2. In section 5 expand ULA. OK. Thanks Suresh ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: secdir review of draft-ietf-csi-send-cert-03
Hi Richard, Thanks a lot for your extensive review. Please find responses inline. Richard Barnes wrote: I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines a certificate profile for use in the Secure Neighbor Discovery protocol for IPv6. Starting from the RPKI cert profile, it adds some refinements for SEND, e.g., EKUs that authorize the subject to act in certain roles within SEND (router, proxy, host). Overall, the document is reasonably well-written, but could benefit from more precision in its use of terminology. There are a few points (noted below) where certificate processing rules are unclear. With regard to the security considerations in particular, I would prefer if they stated the risks slightly more directly (text is suggested below), but in general, the authors address the major security concerns. Detailed comments follow. --Richard Sec 2 Para 1 Suggest changing authority over an to authorization to advertise an. OK. Sec 2 Para 2 Suggest rewording to avoid referring to SIDR WG (which is temporary). Suggested text: The Resource Public Key Infrastructure (RPKI) is the global PKI that attests to allocation of IP address space. Also, instead of SIDR certificate profile, use RPKI certificate profile. Sounds good. Sec 2 Para 3, General I'm confused by the several instances of the phrase address owner in the document (the phrase is not used in RFC 3971). Do you mean host? Since RFC3971 did not expect hosts to use certificates to defend their addresses (hosts traditionally use CGAs), this role was not defined. I proposed the following text to explain what the address owner role means The inclusion of the owner authorization value indicates that the certificate has been issued for allowing the node to use the address(es) or prefix(es) that are mentioned using the X.509 extensions for IP addresses and AS identifiers [RFC3779]. For an address in such certificate the host can assign the address, send/receive traffic from this address, and can respond to NSes about that address. For a prefix in such certificate the node can perform all the above mentioned operations for any address in that prefix. Also, when a prefix is present in the certificate with the owner authorization value, the node cannot advertise the prefix in an RA. This will replace paragraph 6 of section 7. Does this work? Sec 3 Para End Entity This definition is incorrect. Refer to RFC 4949. Can we use End Entity - an entity that is not a CA Sec 4 Para 1 The RPKI profile should be applied in *addition* to the RFC 3971 profile, right? Please clarify. Not really. The csi wg decided to base the new SEND certificate profile solely on the RPKI profile. Sec 4 Para 2 Why can there only be one RFC 3779 extensions? It doesn't seem like there's a risk in including IPv4 space (e.g., for a dual-stack router that was vouching for IPv4 space in some other application?), or multiple extensions for IPv6 space. I am not sure where this restriction is specified. Can you clarify? Sec 5 This section should note that another deployment model (arguably the most likely) is a combination of these two, in which most resources are certified under the global RPKI, while some (e.g., ULAs) are certified under local TAs. Sounds good. Will add the following text about a hybrid deployment model at the end of section 5. These two models are not mutually exclusive. It is entirely possible to have a hybrid model that incorporates features from both these models. In one such hybrid deployment model most IP address resources (e.g. global unicast addresses) would be certified under the global RPKI, while some others (e.g., ULAs) are certified under local TAs. Sec 6 Para 4 The requirement for RFC 3779 extension seems to contradict the use of ETAs as Trust Anchor Material, i.e., the last sentence of the first paragraph in this section. Good catch. I am not sure how to resolve this. One way would be to specify that the ETA EE certificates are exempt from requiring the RFC3779 extensions. Do you have any suggestions? Sec 7 Para The inclusion of ... et seq. It would be helpful for the document to specify how prefix matching should be done when validating these extensions. Which of the following should the RP use? -- Exact matching -- Subset matching (RA within cert) -- The weird subset/intersection algorithm that RFC 3971 defines What prefix should the RP be matching against from SEND, per EKU? E.g., for id-kp-sendRouter, the RFC 3779 extension in the cert should match against any RAs the router emits. It may be useful to refer to the
Re: [Gen-art] Gen-ART LC review of draft-ietf-csi-send-cert
Hi Roni, Thanks for the review. Please see responses inline. On 10-05-02 03:50 AM, Roni Even wrote: The first two comments are about changes from RFC 3971, if they are intentional it may be good to have a section on changes from RFC 3971 and list these specific changes with backward interoperability issues if there are. 1. In section 4 second paragraph “SEND certificates MUST include the IP Resources extension for IPv6 Address …” Section 6.3.1 of RFC 3971 says “Router Authorization Certificates are X.509v3 certificates, as defined in RFC 3280, and SHOULD contain at least one instance of the X.509 extension for IP addresses, as defined in RFC 3779.” So why is it a MUST here. 2. The same paragraph has “Certified IPv6 address space SHOULD be expressed using either addressPrefix or addressesOrRange elements.” . Section 6.3.1 in RFC 3971 says “The X.509 IP address extension MUST contain at least one addressesOrRanges element” as for the addressPrefix according to this section “The X.509 IP address extension MAY contain additional IPv6 subnet prefixes, expressed as either an addressPrefix or an addressRange.” We are basing ourselves on the work done at the sidr working group regarding resource certificates. The MUSTs and SHOULDs are derived from draft-ietf-sidr-res-certs rather than RFC3971. I will come up with a proposal on how to resolve this discrepancy. 3. In section 7 there are TBA1, TBA2 and TBA3, who will assign values for these IDs. The EKUs are assigned by the pkix working group. I will be adding the following text to the IANA considerations section. The EKUs are registered in an arc delegated by IANA to the PKIX Working Group. No further action by IANA is necessary for this document or any anticipated updates. Nits: 1. Section 5 has “an end user could local SEND deployment “ it looks like there is a missing word in this sentence 2. In section 5 expand ULA. Will fix these. Thanks Suresh ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-csi-send-cert (Certificate profile and certificate management for SEND) to Proposed Standard
Hi Sean, I will make the changes to the IANA considerations section like you suggested. I think it adds clarity about the required assignment. On 10-05-01 06:56 AM, Sean Turner wrote: Suresh, 4.c) Was there discussion about support for the anyExtendedKeyUsage OID from 4.2.1.12 of RFC 5280? No. I am not sure it would be useful as the SEND implementations really need to know the EKU to work properly. The packet processing is based on the value of the EKU. Hmmm if you're not going to support it, then you might want to put some text in about it not being allowed. 5280 allows applications to reject certificates that include this extension. OK. I will add the following text at the end of Section 7 Certificate-using applications MUST reject certificates that do not contain one of the three KeyPurposeIds defined above even if they include the anyExtendedKeyUsage OID defined in [RFC5280]. Does this work? Thanks Suresh ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-csi-send-cert (Certificate profile and certificate management for SEND) to Proposed Standard
Hi Sean,
Thanks for the comments. Please see responses inline.
On 10-04-30 03:16 PM, Sean Turner wrote:
The IESG wrote:
The IESG has received a request from the Cga Send maIntenance WG (csi)
to consider the following document:
- 'Certificate profile and certificate management for SEND '
draft-ietf-csi-send-cert-03.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 2010-05-14. 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.
1) I would like to see an ASN.1 module added to the document. That way
we can import the EKUs. Here's what I'm looking for (something similar
was done in draft-ietf-sip-eku):
-
SENDCertExtns { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-send-cert-extns(TBD) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- OID Arc
id-kp OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) 3 }
-- Extended Key Usage Values
id-kp-sendRouter OBJECT IDENTIFIER ::= { id-kp TBA1 }
id-kp-sendProxy OBJECT IDENTIFIER ::= { id-kp TBA2 }
id-kp-sendOwner OBJECT IDENTIFIER ::= { id-kp TBA3 }
END
-
Sounds good. Will do.
2) You also need to register the OIDs for the EKUs and the ASN.1 module.
I assume you're going to try to get them out of the PKIX arc?
Yes. We will use 23,34, 25 as the values for TBA1, TBA2 and TBA3 as
allocated by Russ and Steve.
3) Technically your IANA considerations is wrong because you need to get
OIDs. Might I suggest something like:
This document makes use of object identifiers to identify a Extended
Key Usages (EKUs) and the ASN.1 module found in Appendix *TBD*. The
EKUs and ASN.1 module OID are registered in an arc delegated by IANA
to the PKIX Working Group. No further action by IANA is necessary for
this document or any anticipated updates.
Given 2) is it OK to leave this section as it is?
4) In the last paragraph of Section 7 you describe what the
certificate-using application might require.
4.a) It says that including the EKU extension is a MAY, but the first
paragraph says it MUST be present in EE certificates for SEND.
Assuming the 1st paragraph is correct the 1st MAY needs to be a MUST in
the last paragraph.
4.b) Assuming the 1st paragraph in is correct and EKU MUST be present
then shouldn't value also be required? That is, make the second MAY a
MUST in the last paragraph.
Ack on both .a and .b. Will make this change.
4.c) Was there discussion about support for the anyExtendedKeyUsage OID
from 4.2.1.12 of RFC 5280?
No. I am not sure it would be useful as the SEND implementations really
need to know the EKU to work properly. The packet processing is based on
the value of the EKU.
4.d) You should look at draft-ietf-sip-eku for what they say about
processing their EKU. Those rules are helpful to implementers.
OK.
5) draft-ietf-sidr-res-certs-17 is expired.
We need to normatively reference this draft. So I guess we will get
stuck in the RFC-Ed Queue waiting for this.
Thanks
Suresh
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
xml2rfc 1.34 on Ubuntu
Hi Folks, If you are one of the persons who were frustrated waiting for the new 1.34 version of xml2rfc to get into the Ubuntu disribution channels, you can pick it up from the debian ftp registry at http://ftp.debian.org/debian/pool/non-free/x/xml2rfc/xml2rfc_1.34-1_all.deb Cheers Suresh ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: xml2rfc 1.34 on Ubuntu
Hi Melinda, On 10-02-04 11:25 AM, Melinda Shore wrote: Suresh Krishnan wrote: If you are one of the persons who were frustrated waiting for the new 1.34 version of xml2rfc to get into the Ubuntu disribution channels, I'm unclear on this - why wouldn't they pick it up from resource.org? Using the package manager instead of a tarball * Overwrites the previous version properly * Provides uninstall support * Allows automatic install of dependencies (e.g. tcl, sgml etc.) * Enables automatic updates (if available) Cheers Suresh ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Review of draft-ietf-dna-simple-09
Hi Bernard, Thanks for your comments. Please find responses inline. On 09-10-20 04:08 PM, Bernard Aboba wrote: Review of draft-ietf-dna-simple-09 I have reviewed draft-ietf-dna-simple. Overall, I believe this document still contains significant technical issues that need to be addressed before it would be suitable for publication as a Proposed Standard. In particular, the version of the document sent to IETF last call does not incorporate fixes to issues listed in the WG issue tracker as fixed. This raises the possibility that changes from WG last call were not properly applied or even that the wrong version of the document may have been sent to IETF last call. Given the potential problems, a careful check needs to be made of the changes between -08 and -09 to make sure that resolutions to WG last call and AD review comments were properly applied. Technical Abstract This document provides simple procedures for detecting network attachment in IPv6 hosts, and procedures for routers to support such services. [BA] My understanding was that the goal of Simple DNA was to avoid changes to routers. Given that, what router procedure need to be specified? This refers to the optional changes to routers for sending out fast unicast RAs in section 2.4. Section 2.4 2.4. DNA Roles Detecting Network Attachment is performed by hosts by sending IPv6 neighbor discovery and router discovery messages to routers after connecting to a network. It is desirable that routers adopt procedures which allow for fast unicast Router Advertisement (RA) messages. Routers that follow the standard neighbor discovery procedure described in [RFC4861] will delay the router advertisement by a random period between 0 and MAX_RA_DELAY_TIME (defined to be 500ms) as described in Section 6.2.6 of [RFC4861]. This delay can be significant and may result in service disruption. Please note that support for fast unicast RAs is not necessary since the simple dna procedure can continue to work using the NS/NA exchange, which will complete earlier than the RA arrives. The host detects that the link-layer may have changed, and then simultaneously probes the network with Router Solicitations (RSs) and Neighbor Solicitations (NSs). The host uses advertisements to determine if the routers it currently has configured are still available. Additionally, on links with no statelessly configured addresses, the host may make use of DHCPv6 procedures to identify an operable address. [BA] This paragraph does not describe the situations in which RA delays will be significant. Clarity would be enhanced by describing this. The description of the role of DHCPv6 in this section appears to conflict with the description in Section 4.6. Section 4.6 discusses use of Neighbor Discovery probing in parallel with DHCPv6 probing, implying that RS probing is not used. This section implies that DHCPv6 probing is only done after a combination of RS and NS probing does not result in a statelessly configured address. Perhaps the best way to explain the interaction is to think of simple DNA as independent of DHCPv6. That is, implementation of simple DNA does not change the DHCPv6 state machine or timers; implementations continue to send the same DHCPv6 packets in the same situations and with the same timing as they did without simple DNAv6. The only new wrinkle is the potential for conflicts between simple DNA and DHCPv6, in which case the information obtained via DHCPv6 wins. This is true regardless of whether an implementation waits for an RA before deciding whether to use DHCPv6, or whether it sends DHCPv6 packets regardless of the state of the 'M' and 'O' bits in the RA. My suggested text is as follows: 2.4. DNA Overview Detecting Network Attachment is performed by hosts after detecting a link-layer up indication. The host simultaneously sends multicast Router Solicitations (RSs) and unicast Neighbor Solicitations (NSs) in order to determine whether previously encountered routers are present on the link. Hosts implementing simple DNA may also send DHCPv6 packets, as described in Section 4.6. Since simple DNA does not modify the DHCPv6 protocol or state machine, the operation of DHCPv6 is unchanged. Routers that follow the standard neighbor discovery procedure described in [RFC4861] will delay the router advertisement by a random period between 0 and MAX_RA_DELAY_TIME (defined to be 500ms) as described in Section 6.2.6 of [RFC4861]. Hosts implementing simple DNA can detect the presence of a previously encountered router using unicast Neighbor Solicitations. As a result, where the host with a valid configuration is returning to a previously encountered link, delays in the sending of a Router Advertisement (RA) will not delay configuration as long as NS probing is successful. However in situations
Suggestion for draft-iab-ipv6-nat-00
Hi Dave and Lixia, I went through this document and it looks good. It provides a nice balanced viewpoint on the issues. One thing I would like to be added into the document is a cost-benefit analysis of doing ipv6 NAT for each of the problems in section 2. e.g. Avoid renumbering Benefit: Don't have to renumber since it is hard... Cost: Another box to manage, Application complexity, Traversal infrastructure, Power consumption... I am afraid that absent this analysis, we might be optimizing for the worst case scenario and end up with a permanent box on the path. Renumbering due to provider changes is a fairly rare phenomenon (for some definition of rare) and every operator needs to perform this analysis for themselves to see if NAT66 or some other solution would end up being the better solution for them. Thanks Suresh ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Repair of Public Mail List Archives Complete
Hi Tom, On 17/03/09 05:34 AM, Tom.Petch wrote: Alexa I noticed the lists were down and would normally have flagged it, as many another organisation knows. I did not do so partly because of the usual problem of where to flag it but more because what is the point? These are not so much archives as current affairs. I can look at what has been posted so far today, or yesterday or last week. But when I really need an archive, to see what was agreed in 2006, I have to get there day by day by painstaking day by tedious day at a time. I can see no other more direct way. Dont be so sad :-). Try the IETF mailing list search engine developed by Lars and Jari http://www.google.com/coop/cse?cx=006728497408158459967%3Aybxjdw-bjjw Cheers Suresh ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Guidelines for authors and reviewers
Hi Paul,
Paul Hoffman wrote:
Agree. And this topic (the recipient list of the review) is something
I think hard about before I send out any review.
That's good to hear, but I didn't see it reflected in the document;
maybe your co-authors had a different slant. Regardless, my preference
is to encourage group communication during reviews for anything other
than editorial nits and I was told to read this; I did; it was fine
reviews. Group communication, in both directions for a review, helps
everyone. It also helps prevent a WG hearing that I changed this thing
we had all agreed to because I was told to by { a security person | an
IAB member | an ex-AD | ... }. Those kinds of changes tend to make a
document weaker if they aren't agreed to and possibly modified by the WG
who worked on the document.
I will add the following text regarding this in a new section 4.2 before
the current section 4.2.
***START OF TEXT
4.2 Recipients of the review
The list of recipients of the review is tricky to get right. The main
idea is to make sure all the relevant people receive the review. The
recipient list is determined mainly by the following factors
* The timeframe of the review (early vs. late)
* The contents of the review (editorial vs. technical)
Early reviews are usually performed by active participants of a working
group. The preferred destination for these reviews is the working group
mailing list since it can be reasonably assumed that the persons
interested in the document are subscribed to the mailing list. This
applies for both technical and editorial issues. Alternately editorial
issues can be resolved using a private mail to the author(s).
Late reviews are usually performed by persons who are not active
participants of the working group and who usually review the draft from
a different point of view than the working group. If the contents of the
review are mainly editorial in nature, the reviews can be sent just to
the authors, the working group chair(s), the document shepherd(s). If
the review is of a more technical nature it is considered polite to
include the working group mailing list and/or the IETF discussion list.
As it is not reasonable to assume that the reviewer will subscribe to
the working group mailing list just for discussing this issue, the
working group chair(s) need to make sure that this review will get past
any moderation controls imposed on non-subscribers by the working group
mailing list.
END OF TEXT*
Would this resolve your concern?
Thanks
Suresh
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: Guidelines for authors and reviewers
Hi Ted, Ted Hardie wrote: At 10:55 AM -0700 6/3/08, Suresh Krishnan wrote: ***START OF TEXT 4.2 Recipients of the review The list of recipients of the review is tricky to get right. The main idea is to make sure all the relevant people receive the review. The recipient list is determined mainly by the following factors * The timeframe of the review (early vs. late) * The contents of the review (editorial vs. technical) Early reviews are usually performed by active participants of a working group. Suresh, Can you describe the difference between early reviews performed by active participants and just participation? In my mind, folks making suggestions and noting issues with a document during the working group phase are WG contributors, not reviewers. How do you see this? I see it just like you :-). The early reviewers are contributors and participants. The reason I made the distinction is because reviews are only one form of participation in the working group. There are other ways to participate in the working group * Editing documents * Keeping track of issues * Contributing text to sections etc. Thanks Suresh ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Guidelines for authors and reviewers
Hi Frank, Thanks for your comments. Please see responses inline. Frank Ellermann wrote: Suresh Krishnan wrote: We would really appreciate [...] In the spirit of your draft: s /one an author/once an author/ ;-) Will fix :-) As the draft says, the main thing is to get any reviews at all: A negative review means that somebody bothered to read it, and to note whatever attracted their attention. I'm not sure if that needs a separate review netiquette RFC, IMO it should be a part of the Tao, or the next Tao if it is not already clear. Paul Hoffman is working on the TAObis. Maybe he can chime in on this. Please use the term review team instead of directorate. OK. Will do. Thanks Suresh ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Guidelines for authors and reviewers
Hi Ted, Thanks for your comments. Please see responses inline. Ted Hardie wrote: I looked at it, and, while I laud any efforts to get folks to review things effectively, I have to say that I found this to be a pretty drafty draft. It does not reference the Tao, 2026, or any of the developed educational materials; its only listed reference, in fact, is 2119 and that does not seem to be referenced within the text. That means that this comes across as pretty context free. It needs anchoring to the rest of our processes. I do share your sentiment, but this is not what we set out to do originally. We set out to document the review process(es) and provide some guidelines to effectively use the received reviews. I think the right document to weave the stuff together would be the Tao. But I do agree that adding references to the Tao and 2026 make sense. The dangling reference to 2119 is an editorial oversight :-). One of the things that I believe that anchoring should provide is a pretty significant change of perspective. As this reads now, it implies a lot of power in the hands of reviews to elicit (or even require) change. It seems to want document authors to accede to requests for tutorial material as a matter of course and to significant technical changes I am sorry you feel that way. It was not the intent of the document. The document just states that a concern raised in the review deserves a response (not necessarily a change). One valid response is Mr. reviewer, what you raised is not a problem. This was a design decision taken by the WG and the discussion thread about this is at http://mlarchive.invalid/msgfoo.html;. with a modicum of fuss. That's not the right approach. The outcome of our document development should not be a negotiation between the authors and the assigned reviewers. It should be a conversation in the working group among those who will actually develop the implementations, those who will deploy it, and those who are affected by the system of which the documented technology is a part. Agree. And hence this text in section 3.5 After the author and reviewer agree that the issues have been fixed, for working group documents, substantial issues need to be confirmed on the mailing list. Once the document has entered IESG processing, new versions should not be posted unless the document shepherd or AD explicitly says so. Reviews that work to relate a particular document's technology to the larger whole of which it is a part (asking: how does this impact congestion control in the access network or core, use deployed security systems, relate to the identifier mechanisms common to URIs, etc.) are very valuable. But many reviews represent questions about decisions that come down to design choices that working groups should have the power to make without extensive second-guessing. Folks who want to have a say at the level can and should do so with the simple method of joining the working group list and commenting as part of the general development. That's not review (of someone else's work) it is participation (in joint work), and it is fundamentally more valuable. Agree in principle. But a late reviewer usually gets documents from multiple wgs and subscribing to the MLs just to raise one issue can get to be a tiring endeavor. Last year, I reviewed documents from 20 different WGs (apart from the ones I am usually involved in). I cannot handle mailing list traffic from 20 more mailing lists. If this were mandated, I would rather not review the document. I would also like to point out that most of the reviews received during IETF Last Call are of the nature you describe. Without the context of how participation works, your documents description of review comes off very badly indeed. I hope that future versions can correct that and place review within a broader, more productive context. I personally feel that the TAO (4677 and descendants) should be the document that sets the various pieces in context, but I am open to suggestions on how to go about fitting this document into a broader context. Thanks Suresh ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Guidelines for authors and reviewers
Hi Ted, Please find responses inline Ted Hardie wrote: At 2:42 PM -0700 5/30/08, Suresh Krishnan wrote: I do share your sentiment, but this is not what we set out to do originally. We set out to document the review process(es) and provide some guidelines to effectively use the received reviews. I think the right document to weave the stuff together would be the Tao. But I do agree that adding references to the Tao and 2026 make sense. The dangling reference to 2119 is an editorial oversight :-). If the Tao is the right document to do the weaving in, then the right thing to do may well be incorporate more discussion of the review process in the next version of the Tao. A stand-alone document which says to get this context go read this first might work, but it runs the usual risk. And statements like: reviews also play an important part in how IETF determines consensus. really need to be related to our process documents. Personally, I don't think that's actually either true or the point. Many solicited reviews are meant to discover technical show stoppers or areas where the impact of technology on other parts of 'net have not been taken into account. Determination of consensus is different, and it has a large amount to do with our participation model. Changes to the pool of folks from whom consensus is solicited should not be done lightly in informational documents. I think there is some context missing here. This is what we talk about in section 4.1. One of the things that I believe that anchoring should provide is a pretty significant change of perspective. As this reads now, it implies a lot of power in the hands of reviews to elicit (or even require) change. It seems to want document authors to accede to requests for tutorial material as a matter of course and to significant technical changes I am sorry you feel that way. It was not the intent of the document. The document just states that a concern raised in the review deserves a response (not necessarily a change). One valid response is Mr. reviewer, what you raised is not a problem. This was a design decision taken by the WG and the discussion thread about this is at http://mlarchive.invalid/msgfoo.html;. The tutorial material comment comes from this section: If the reviewer has not understood some part of the draft, a very common response is to explain the topic in email. However, often that explanation should really be in the draft itself, not just in emails to the authors, so that future readers will also understand the text. This is from my personal experience. I have been asked by reviewers (including IESG members) to add such text in the past. For the sake of clarity, I complied. I do not see the downside of this. The key missing piece here is that the effort to get outside reviewers means that they are missing context that those actually using the document will likely have. Asking that it be included as a matter of course on the query of a reviewer produces changes that then have to be reviewed and agreed to by the working group. That's a lot of work for a lot of people for things which may well be obvious to those within the group using a technology. If someone reads a document and the normative references, and does not understand something, it needs to be fixed. RFCs are not only for people who worked on creating the technology. The document's description of politeness in responses also sets timeframes that sound a lot like deadlines: two or three business days might be a reasonable amount of time to take for a response. It is possible that the authors may be unavailable to respond to a review within this timeline since they may be sick/on vacation/busy with dayjob etc. In this case, the document shepherd (if any) can respond to the review and follow up with the authors at a later time. The ability to force an interrupt on busy people (either authors or shepherds) is real power, and we need to be careful how we cast that. A comment on a document (and that is what reviews are) does deserve to be considered, but the extent to which a response is required and the timeframe for that response is much more fluid than this implies. Bundling all comments received during a Last Call, considering them as an author team, then issuing a new draft or set of RFC Editor notes (or, honestly, punting them all) may be the most effective thing to do. In that case, the only early response you'll get is message received. If you want that, permit me to suggest the handy MDN functionality likely available in your mail client. I can remove this from the document. This is the amount of time that I take on average to respond to a review. But, let's say somebody writes a draft for the first time ever in her life. She gets a review from you on her draft. She currently has no idea how much
Re: Guidelines for authors and reviewers
Hi Paul, Thanks for the comments. Please see responses inline. Paul Hoffman wrote: At 5:03 PM -0400 5/30/08, Suresh Krishnan wrote: I'm not sure if that needs a separate review netiquette RFC, IMO it should be a part of the Tao, or the next Tao if it is not already clear. Paul Hoffman is working on the TAObis. Maybe he can chime in on this. ching! The past few editions of the Tao do indeed talk about taking reviews with an open mind. The Tao doesn't talk much about *giving* reviews, mostly because the intended audience (IETF newcomers) are mostly interested in learning how to be in the normal IETF structures, like WGs. Having said that, I agree with some of what Ted Hardie said about the tone of the document. It sounds like there are instructions to document authors on how they are supposed to act when they get reviews. That's bordering on a revision to RFC 2026, which I don't think is what you intended. It is polite to and some document authors like to are quite different than are expected to and needs to. I agree that tone might be a bit strong but this can be easily fixed in the document. e.g. Replace The authors are expected to respond to the reviews within a reasonable amount of time. with It is considered polite to respond to the reviews within a reasonable amount of time. but it might be more tricky to define reasonable amount of time. Do you feel that it is out of the scope of this document to define this? If so, we can take it out of the document. But doing so diminishes the guiding value of the document. This document emphasizes reviews going to authors instead of reviews going to WGs or, in the case of individual submissions, reviews going to mailing lists. In the Tao, we emphasize the value of communications to groups so that the group can agree, amplify, show disinterest, or disagree. In the WGs I have co-chaired, the WG got good value out of some of the GenART and SecDir reviews in that it made the whole WG think about the topics brought up. This may be a fundamental difference in view between this document's authors and my preferences, but I think the discussion of where reviewers should be sending their reviews is an important one for the IETF community to have. Agree. And this topic (the recipient list of the review) is something I think hard about before I send out any review. Thanks Suresh ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Guidelines for authors and reviewers
Hi Folks, We have written a draft describing some guidelines for authors and reviewers of internet drafts. We would really appreciate it if you can spend some time to go over it and provide comments and/or suggestions for improvement. Thanks Suresh, Pasi and Eric Original Message Subject: I-D Action:draft-krishnan-review-process-00.txt Date: Wed, 28 May 2008 11:15:01 -0700 (PDT) From: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Guidelines to authors and reviewers regarding the IETF review process Author(s) : S. Krishnan, et al. Filename: draft-krishnan-review-process-00.txt Pages : 10 Date: 2008-05-28 This document describes the IETF review process and provides guidelines to draft authors and reviewers on how to effectively participate in it. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-krishnan-review-process-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART review of draft-ietf-geopriv-radius-lo-19.txt
I am the assigned Gen-ART reviewer for draft-ietf-geopriv-radius-lo-19.txt For background on Gen-ART, please see the FAQ at http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html. Please resolve these comments along with any other Last Call comments you may receive. Summary: This draft is almost ready to be published but I have a few comments. Minor = * Section 3.2 It is not clear to me why the NAS receives and echoes back the Basic-Location-Policy-Rules and Extended-Location-Policy-Rules Attributes from the Access-Challenge, especially since these are opaque to the NAS. * Section 4.2 - Does not define the values of the Code field. This is explained later in Section 4.3. It may be better to move the definition into this Section - This text does not read very well Index (16 bits): The 16-bit unsigned integer value allows this attribute to provide information relating to the information included in the Location-Data Attribute to which it refers (via the Index). I recommend rephrasing it to something like Index (16 bits): This is a 16-bit unsigned integer value that is used to identify the corresponding Location-Data Attribute(with the same index). * Section 4.7 The numerical values of the types of location are enclosed in single quotes like this. e.g. for CIVIC_LOCATION A numerical value of this token is '1'. This is confusing because earlier use of this quoted text (Operator namespace ID) '1' refers to the numeric value 0x31. I feel it is better to remove the quotes in this section. * IANA Considerations - Replace Operations Area Director with Operations Area Directors - The IANA guidance for section 8.6 is fuzzy. It is not at all clear from this section that the next value to allocate is 64,128... (This is clear to me from reading section 4.7). Wouldn't it be a better idea to redefine this field to be a set of 32 numbered bit flags and assign a meaning to each one of them? Editorial = * Replace reference to RFC3041 with one to RFC4941 that obsoletes RFC3041. * Cheers Suresh ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Issues with Letter of Invitation for IETF72
Hi Folks, I requested a letter of Invitation for the Dublin Meeting and I noticed the following issues. * I cannot register first and then come back for the letter of invitation. I get the following error You will need to register for the IETF meeting prior to requesting a letter of invitation. Once you have registered for the IETF meeting, you will be prompted to request the letter of invitiation. There should be a form here instead that should ask for my registration number. * There are two Questions about Nationality and Passport Issuer Country. The country I pick under Nationality shows up under the Address. In my case this is not correct. I do not know how these fields are being used, but the labels need to be clarified. Thanks Suresh ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Blue Sheet Change Proposal
Hadriel Kaplan wrote: I think he means if the sheet is truly used for proof of presence and IPR awareness then it's not good enough to allow name collisions. But I don't see how blue sheets would hold any strength anyway for that purpose, because 1) signing doesn't mean I was there the whole time, and (2) doesn't mean I had stopped reading emails and was paying attention. And in addition, somebody could be in the room AND be aware of IPR and NOT SIGN the blue sheet. There is nothing saying that people in the room have to sign a blue sheet. I, for one, have seen people pass around blue sheets without signing. Cheers Suresh ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RFCVision (Was Re: Finding information)
Hi Willie, I came up with a tool (rfcvision) couple of years ago for personal use that did something like this. You can check it out at http://www.sureshk.com/rfcvision It is not production quality but it should help you. Let me know if you have any comments/suggestions. Cheers Suresh Willie Gillespie wrote: As someone new to the IETF, how should I go about doing the following? I want to find some information about IMAP and its extensions. Let's say I found RFC 1730. How would I know that it had been obsoleted by RFC 2060 and then by RFC 3501? How do I find the extensions? I don't necessarily want to search through a list of 5000 entries to find what I want. That's where I think a naming scheme like IETF-IMAP would be handy. Then I could look at a list of IETF-IMAP and see IETF-IMAP-2003 would be newer than IETF-IMAP-1996. But that's beside the point. As of right now, how do I find this information? Is there a handy tool on tools.ietf.org that I should use? Thanks for your help. Willie ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Gen-ART review of draft-ietf-mip4-vpn-problem-solution-03.txt
I am the assigned Gen-ART reviewer for draft-ietf-mip4-vpn-problem-solution-03.txt For background on Gen-ART, please see the FAQ at http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html. Please resolve these comments along with any other Last Call comments you may receive. Summary: This draft is well written and easy to read, but I do have a couple of comments I would like addressed. Meta comments = * This is just my personal view but I am not sure if BCP is the right intended status for this document. It requires changes to the node implementations and requires behavioral changes on some nodes. Perhaps needs to be Standards track * T_MONITOR is a new configuration knob that is added to the MN (that possibly requires changes to implementation). This needs to be clearly stated prior to use. Also, it would be nice to mention the associated signaling traffic reduction vs detection latency reduction compromise, so that the admins can make an informed decision as to the value of this. Minor = Section 3.3 === Bullet 2: The following text is redundant since it is covered by bullet 3. If a previous registration reply from the x-HA has been received, the MN SHOULD de-register with the x-HA. It makes sense to remove this Section 3.4 === * It is not clear who this requirement is on? Therefore, it is required that x-HA and i-HA addresses MUST be different Can you please clarify who ensures this Section 3.6 === * It is not clear what inside means here since it refers to the x-HA The registration process can be improved in many ways. One simple way is to make the x-HA detect whether a registration request came from inside or outside. If it came from inside, the x-HA can simply drop the registration request. Editorial = * Push the basic topology figure to right after the first paragraph of section 2. The draft does not have an Intended Status. From the ID tracker, I figured out that it is BCP, but it is perhaps better to explicitly state it in the draft. Cheers Suresh ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Gen-ART review of draft-ietf-sipping-toip-08.txt
I am the assigned Gen-ART reviewer for draft-ietf-sipping-toip-08.txt For background on Gen-ART, please see the FAQ at http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html. Please resolve these comments along with any other Last Call comments you may receive. Summary: This draft is well written and is almost ready for publication, but I have a couple of comments. * The term modality is used in the document but it has not been defined. The meaning I perceive from this document does not match with the normal English usage of modality. I think the document uses this word to describe the way in which the TOIP device interacts with human. This needs to be clearly stated. * I do not have strong feelings regarding this, but I feel that using RFC2119 terminology in this document is inappropriate given that the document is aiming to be an Informational RFC. * Section 5.2.1: I think requirement R5 is redundant given requirement R6. Is there any use case that is covered by R5 and not by R6? * Section 5.2.2: Why is there a requirement for maximum delay per character? A character by itself is not useful. I would think setting the delay per word makes more sense, since this is the smallest comprehensible text unit. * Section 5.2.4: I am not clear what this requirement means. Can we add more specific text to this one. R31: Users MUST be presented with appropriate session progress information at all times. * Section 5.2.4: I think this requirement has enormous privacy implications. This needs to be explicitly stated. R35: It SHOULD be possible to save the text portion of a conversation. Cheers Suresh ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Gen-ART review of draft-ietf-avt-topologies-06.txt
I am the assigned Gen-ART reviewer for draft-ietf-avt-topologies-06.txt For background on Gen-ART, please see the FAQ at http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html. Please resolve these comments along with any other Last Call comments you may receive. Summary: This draft is very well written, an enjoyable read and is almost ready for publication except for a minor comment. Minor = ASM is a term commonly used in multicast to mean Any Source Multicast (as opposed to Source Specific Multicast). The glossary of this draft redefines this to be Asynchronous Multicast. Is this just a typo? Because from my reading of the draft all instances of this acronym actually use it in the context of Any Source Multicast. If it is just a typo it can be fixed with just an RFC-Editor note. Cheers Suresh ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Gen-ART review of draft-ietf-sip-answermode-06.txt
I am the assigned Gen-ART reviewer for draft-ietf-sip-answermode-06.txt For background on Gen-ART, please see the FAQ at http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html. Please resolve these comments along with any other Last Call comments you may receive. Summary: This draft is ready for publication and the issues I raised with the previous version (-04) of the draft have been resolved. Cheers Suresh ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF solution for pairing cellular hosts
Hi Pars, Pars Mutaf wrote: Model of operation 1. The querier user types the target user's human name (as if he were consulting a phonebook), or a pseudoynm. 2. The pairing request is forwarded to the target phone. How? How do you locate the target phone? Isn't this the problem we are trying to solve? Cheers Suresh ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 addresses really are scarce after all
Hi Phil, Hallam-Baker, Phillip wrote: I am pretty sure the EUI-64 requirement has been dropped. If not I can't see how the real world security practitioners are going to implement it. Stateless autoconf does not automatically imply EUI-64. There are other stateless autoconf methods that do not use bare EUI-64s. See below. The EUI-64 address reveals the hardware manufacturer and model of hardware that I am using. There are no circumstances in which I am going to allow an attacker to obtain that information without putting them to as much effort as I can. You can use a modified 64 bit identifier for privacy. These identifiers run a crypto hash over the EUI-64 and keep changing it periodically. Thus you can hide your hardware identity both over time and at a specific instance of time. http://tools.ietf.org/html/draft-ietf-ipv6-privacy-addrs-v2-05 (Soon to be RFC4941) Other mechanisms such as CGA, HBA (more to come ?) also work with 64 bit boundaries even if they are not EUI-64 based. Cheers Suresh ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Gen-ART review of draft-ietf-sip-answermode-04.txt
I am the assigned Gen-ART reviewer for draft-ietf-sip-answermode-04.txt For background on Gen-ART, please see the FAQ at http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html. Please resolve these comments along with any other Last Call comments you may receive. Summary: This draft is almost ready for publication, but I have a minor issue that needs to be resolved. Minor = * Section 4 The following text does not look right. I think the client and server roles have been reversed. The current text looks like this Each value of the Answer-Mode or Priv-Answer-Mode header field can include an optional parameter, require. If present, this parameter indicates that the UAS would prefer that the UAC reject the request if the UAC is unwilling (perhaps due to policy) to answer in the mode requested, rather than answering in another mode. I think each instance of UAC must be replaced with UAS, and UAS must be replaced with UAC. Cheers Suresh ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Funding (was Re: Charging I-Ds)
Hi Itojun, How would you write documents which warn against people doing funny things? I wrote a draft about the issues with hop-by-hop options in IPv6 and cautioning against their use. I see that there are still proposals coming out which depend on new hbh options? What should I do instead of writing a draft? Cheers Suresh Jun-ichiro itojun Hagino wrote: Charging for IDs will kill innovation. I use IDs to float ideas which may or may not bear fruition. I would not work on these if I had to pay. I also work on things at the IETF than my employer does not sponsor. These things will get thrown out as well. I assume i-d to be a proposal for a new protocol, which is implementable with a reasonable efforts and costs. i think your view and my view are opposite. i'd like to see the following: - submission of i-d requires an implementation - to become a RFC requires two independent interoperable implementation itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Funding (was Re: Charging I-Ds)
Charging for IDs will kill innovation. I use IDs to float ideas which
may or may not bear fruition. I would not work on these if I had to pay.
I also work on things at the IETF than my employer does not sponsor.
These things will get thrown out as well.
Since we have started slaughtering the sacred cows (free {ids,mailing
lists, rfcs ...}), I might as well suggest few more.
* Make remote participants share the costs. i.e. charge for live
audio/video feeds. I believe this is fairer than charging for ids, rfcs
or mailing lists. People who want to participate, but are unable to
travel can get these for a lower meeting fee (25% maybe).
* Get some kind of corporate sponsorships for supporting free documents
(kind of like IEEE get 802)
* Cut back on the food and beverages
I would be unhappy with some of these things, but at least they still
retain the openness of the IETF and are reasonably fair.
Cheers
Suresh
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Re: Annoying auto-reply messages
Hi John, John C Klensin wrote: (1) I haven't seen you sending out-of-office messages to the entire list. I don't like getting them to the author with individual postings (and it violates the standards too), but that is both more tolerable and a little more understandable. Is there a standard for this? I could not find one. I did write an April 1st RFC wannabe banning auto-replies to mailing lists, but I did not know an RFC existed. Cheers Suresh ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Nomcom 2007-8: Randomness Sources for review
Hi Lakshminath, In light of your clarifications, I have no further objections. Thanks Suresh Lakshminath Dondeti wrote: Following up on this thread, if there are any objections to the randomness sources at this time (after taking my clarifications into consideration), please do let me know. I need to finalize this before the deadline tomorrow to stick to the timeline. thanks, Lakshminath ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Nomcom 2007-8: Randomness Sources for review
Hi Lakshminath, I think these sources are reasonable. I just require some clarification about the lottery numbers. From your examples, it was not clear to me how the lottery numbers will be entered as inputs to the 3797 algorithm. The algorithm recommends that the numbers be sorted in some order. Your example for Euromillions was =We input 11 16 17 22 34 5 6 This is not sorted in any order. Do you consider the star numbers to be different sources? Is the input order specified like this * normal numbers in ascending order followed by the stars in ascending order It would be nice to clarify this while announcing the sources. Cheers Suresh ** NOTE:(Original mail sent only to [EMAIL PROTECTED] Responding to ietf@ietf.org since the ietf announce list is moderated.) ORIGINAL MAIL Folks, As per the announced timeline (https://datatracker.ietf.org/public/show_nomcom_message.cgi?id=1231), which is 3777-compliant, the method of random selection was to be announced on July 6, 2007. I am presenting it earlier for your review. In the past few cycles, nomcom chairs have used Wall Street's trading volumes as the sources of randomness to RFC 3797 random selection process. However, I don't currently subscribe to the Wall Street Journal :) and besides RFC 3797 suggests that stock prices and/or volumes are a poor source of unambiguous data anyway, so I chose the following randomness sources; please review them and let me know if there are objections. The following dates assume that I can actually publish the list of volunteers on July 6th 2007 (as of today that has a high likelihood). 1. EuroMillions Fri July 13, 2007 Results: http://www.national-lottery.co.uk/player/p/results/results.do All 7 numbers (5 numbers from 1 - 50 and 2 Lucky Stars from 1 - 9) Results available online around 10 PM UK time. e.g., Fri Jun, 22 07 results 11 16 17 22 34 05 06 We input 11 16 17 22 34 5 6 2. US National debt (Debt Held by the Public), published by the Treasury department as of July 12, 2007 (Published on July 13, 2007) The system is updated daily with the previous day's data. The update typically takes place around 3:00 pm EDT. That according to -Will Web Development Branch Bureau of the Public Debt http://www.treasurydirect.gov/NP/BPDLogin?application=np Last 8 digits, ignore the commas and periods from the Debt Held by the Public e.g., Fri June 22, 2007 4,950,586,161,721.14 We select 16172114 3. US National debt (Intragovernmental Holdings), published by the Treasury department as of July 12, 2007 (Published on July 13, 2007) http://www.treasurydirect.gov/NP/BPDLogin?application=np Last 8 digits, ignore the commas and periods from the Intragovernmental Holdings e.g., Fri June 22, 20073,852,643,882,285.79 We select 88228579 4. Lottery again, Megamillions http://www.megamillions.com/winningpicks/last_25.asp All 6 numbers (including the Mega Ball) from the drawing on July 13, 2007 (at 11:00 pm US Eastern time). e.g., Fri June 22, 2007 result 11, 14, 21, 24, 31, 23 We input 11 14 21 24 31 23 All the inputs are to RFC 3797 selection algorithm. There is source code in that RFC and an example. regards, Lakshminath Nomcom 2007-8 Chair ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-chakrabarti-ipv6-addrselect-api (IPv6 Socket API for Address Selection) to Informational RFC
Hi Vidya, (Cc:ing Julien as well) Narayanan, Vidya wrote: All, I'm passing along a comment from one of our developers. Sorry, I have not closely read the draft myself. But, if more clarification is needed, I'll be happy to get more information. In section 13, the draft describes a procedure applications should follow in case they require to use the address according to the selection preferences specified (they should not communicate with 'wrong' address and fail). The procedure requires the application to do a 'connect()' in step 3. The application may not even want to connect (may be a TCP application) in case it is not getting a non-preferred address. There should be a procedure described for such applications too. From what I understood from the draft, the API is used for specifying only preferences and not hard requirements. This text from Section 1 of the draft explains the reasoning. Specifying hard requirements for address selection would be problematic for several reasons. The major one is that in the vast majority of cases the application would like to be able to communicate even if an address with the 'optimal' attributes is not available. The authors can correct me, but I personally don't see how it is possible to check this deterministically without actually using connect() or sendto(). For argument's sake let's assume such a solution exists and the application verifies that a preferred address exists. What is to say this preferred address will not vanish before it is actually used (connect or sendto)? Cheers Suresh ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Gen-ART review of draft-ietf-imss-fc-fcs-mib-02.txt
I am the assigned Gen-ART reviewer for draft-ietf-imss-fc-fcs-mib-02.txt For background on Gen-ART, please see the FAQ at http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html. Please resolve these comments along with any other Last Call comments you may receive. Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. Comments: Minor: == * Section 1: Introduction I found this sentence strange. Is there any reason to keep it? This memo includes boilerplate which uses only one of the following terms, but is nevertheless required to mention all of the keywords in the following statement: The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. Editorial: == * No expiration date for draft on the first and last pages. According to http://www.ietf.org/ietf/1id-guidelines.txt === A document expiration date should appear on the first and last page of the Internet-Draft. The expiration date is 185 days following the submission of the document as an Internet-Draft. Use of the phrase expires in six months or expires in 185 days is not acceptable. * Intended Status of the document is not specified in the draft. (I found it is Proposed Standard using the ID Tracker) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Gen-ART review of draft-ietf-imss-fc-fcs-mib-02.txt
Hi Keith, Please find comments inline. Thanks Suresh Without this sentence, the boilerplate implies that all of the listed keywords are present in the document. Since the boilerplate cannot be changed, the sentence was included to avoid the erroneous implication. I do not know of any draft/RFC which uses all of these keywords, but I am fine with leaving the sentence in. Editorial: == * No expiration date for draft on the first and last pages. According to http://www.ietf.org/ietf/1id-guidelines.txt === A document expiration date should appear on the first and last page of the Internet-Draft. The expiration date is 185 days following the submission of the document as an Internet-Draft. Use of the phrase expires in six months or expires in 185 days is not acceptable. The footer (on every page) contains the expiry date. I was expecting a date and I found only the month in the footer. * Intended Status of the document is not specified in the draft. (I found it is Proposed Standard using the ID Tracker) The guidelines say: The Internet-Draft should neither state nor imply that it has any standards status; to do so conflicts with the role of the RFC Editor and the IESG. The title of the document should not imply a status. Avoid the use of the terms Standard, Proposed, Draft, Experimental, Historic, Required, Recommended, Elective, or Restricted in the title of the Internet-Draft. Indicating what status the document is aimed for is OK, but should be done with the words Intended status: status. Since the I-D neither states nor implies that it has any standards status, I believe it complies. The restrictions on normative references are different for standards track documents as compared to informational documents. That is why the Intended Status: in the draft makes it easier to check for possible downward references. It is fine to leave it out. That is why it is a nit :-). ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Gen-ART review of draft-ietf-l2tpext-failover-11.txt
I am the assigned Gen-ART reviewer for draft-ietf-l2tpext-failover-11.txt For background on Gen-ART, please see the FAQ at http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html. Please resolve these comments along with any other Last Call comments you may receive. Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. Comments: Minor: == * IANA considerations The IANA considerations section does not specify the namespace from which allocation is requested for the AVPs and the message types. Editorial: == * Section 4.2 Failover Session Response This sentence has a typo and does not read well It is not required to respond one FSQ message with just on FSR. I suggest removing it altogether so that the text will simply read An endpoint MAY choose to respond to an FSQ message with multiple FSR messages ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Gen-ART review of draft-daigle-unaptr-01.txt
I am the assigned Gen-ART reviewer for draft-daigle-unaptr-01.txt For background on Gen-ART, please see the FAQ at http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html. Please resolve these comments along with any other Last Call comments you may receive. Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. Comments: Editorial: == * Section 3 One of the lines is more than 72 characters long (The regexp line for NAPTR 200 10). Suggest removing some whitespace to make this fit * Section 5 IANA considerations, paragraph 4 This text needs to be changed since section 4.5 is not below. So either remove the word below or move the restrictions in place below this paragraph. There are no further restrictions placed on the tags other than that they must conform with the syntax defined below (Section 4.5). * Section 5 IANA considerations, paragraph 2 I believe the phrase As with S-NAPTR makes more sense than As for S-NAPTR but this is a matter of personal preference. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Gen-ART review of draft-ietf-radext-filter-06.txt
I am the assigned Gen-ART reviewer for draft-ietf-radext-filter-06.txt For background on Gen-ART, please see the FAQ at http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html. Please resolve these comments along with any other Last Call comments you may receive. Summary: This draft is basically ready for publication, but has minor issues that need to be clarified before publication. Comments: Substantial === * Section 6 A legacy NAS not compliant with this specification may silently discard the NAS-Filter-Rule attribute while permitting the user to access the network. This can lead to users improperly receiving unfiltered access to the network. As a result, the NAS-Filter-Rule attribute SHOULD only be sent to a NAS that is known to support it. I do not understand the rationale behind this. In this case, if the server sends the NAS-Filter-Rule (that is ignored by the NAS) it is no worse off than not sending it at all. In either case the user gets unfiltered access to the network. Is this recommendation really necessary? Minor = * Section 2 Given the absence in [RFC4005] of well-defined precedence rules for combining Filter-Id and NAS-Filter-Rule attributes into a single rule set, the behavior of NASes receiving both attributes is undefined, and therefore a RADIUS server implementation cannot assume a consistent behavior I do not understand why the lack of clarity in the Diameter spec precludes this document from coming up with its own precedence rules. e.g. The document may state If a Filter-Id attribute is present, a NAS implementing this specification MUST silently discard NAS-Filter-Rule attributes, if present. I do not have a strong opinion about this but I feel that the reasoning is not obvious. * Section 3 The following legend is unnecessary since it is not used in any message type 0-1 Zero or one instance of this attribute MAY be present in the packet. Editorial: == * The document contains no form feeds * Some pages are longer than 58 lines * Introduction paragraph 2 This sentence does not read well However, in situations where the server operator does not know which filters have been pre-populated, it useful to specify filter rules explicitly. Perhaps add a is/will be/may be... before the word useful. However, in situations where the server operator does not know which filters have been pre-populated, it is useful to specify filter rules explicitly. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Gen-ART review of draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt
I am the assigned Gen-ART reviewer for draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt. For background on Gen-ART, please see the FAQ at http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html. Please resolve these comments along with any other Last Call comments you may receive. Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. Comments: Substantial: * General comment about backward compatibility I think legacy transit nodes resetting the Call ID to zero on transmission is a major issue that needs to be addressed more visibly in the draft. * Section 6.1 The following sentence needs to be tightened. The text Note that a Call MAY NOT be imposed ... needs to be changed to Note that a Call MUST NOT be imposed ... since it is a prohibition to do so. Semi-substantial: = * Section 5.1 I did not understand what this sentence means. Does it mean the notify message does not have to follow the path of LSPs or it must not follow the path of LSPs? Adding some clarifying text on why it is so, may be a good idea. The Notify message is a targeted message and does not follow the path of LSPs through the network. * Section 6.5 Call Collision For the Call ID Contention error case, I do not see why we need to check the remote source address, instead of always returning an error. * Section 6.6.5 If a teardown request Notify message is received for an unknown Call ID, it is, nevertheless, responded to in the affirmative. Why not return a Call Management/Unknown Call ID error instead? * IANA considerations If there are existing implementations it would be nice to suggest values for the RSVP objects and error codes to the IANA Minor: == * The following text is repeated in both the abstract and the introduction. One of them can be removed. A Call does not provide the actual connectivity for transmitting user traffic, but only builds a relationship by which subsequent Connections may be made. In GMPLS such Connections are known as Label Switched Paths (LSPs). * Section 4.3.1 Suggest replacing In this case the ingress... with In the case where the ingress... since this case has not been defined. Editorial: == There is a reference to RFC2747 in the references section but it is not referenced anywhere in the draft. I would suggest removing the reference ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Lost Logitech headset
Hi Folks, I lost a silver logitech headset with mic sometime this morning. If anyone found it, I would really appreciate it if you can let me know.ThanksSuresh ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
