Overloaded TXT harmful (was Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard)
--On Monday, August 26, 2013 10:49 -0400 John R Levine jo...@taugh.com wrote: Sorry if that last one came across as dismissive. Until such time, I'd personally prefer to see some explicit notion that the odd history of the SPF TXT record should not be seen as a precedent and best practice, rather than hope that this is implicit. I'd have thought that the debate here and elsewhere already documented that. Since it's not specific to SPF, perhaps we could do a draft on overloaded TXT considered harmful to get it into the RFC record. With the help of a few others, I've got a I-D in the pipe whose function is to create an IANA registry of structured protocol uses for TXT RR data and how to recognize them. I hope it will be posted later this week. Its purpose is to lower the odds of overloaded sliding into different uses for forms that are not easily distinguished. Other than inspiration, its only relationship to the current SPF discussion is that some SPF-related information is a candidate for registration (whether as an active use or as a deprecated one). It already contains some text that warns that overloading TXT is a bad idea but that, because it happens and has happened, identifying those uses is appropriate. Once it is posted, I/we would appreciate any discussion that would lead to consensus about just how strong that warning should be and how it should be stated. best, john
Re: Rude responses
On Mon, Aug 26, 2013 at 5:36 PM, l.w...@surrey.ac.uk wrote: I experienced rude respondings in IETF list That would be when you tried to get April 1 RFCs discontinued. No, I experienced rude response from some participants including you, and regarding yours I received a private email from one director that he ask me not to reply to you because he wants to handle it with you privately. I request that the IETF Chair to stop you from sending me any further emails, because you are changing the subject to personal issues. AB From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Abdussalam Baryun [abdussalambar...@gmail.com] Sent: 25 August 2013 12:27 To: Pete Resnick Cc: dcroc...@bbiw.net; ietf@ietf.org Subject: Re: Rude responses (Was: Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard) I experienced rude respondings in IETF list and in one WG list, I don't beleive that it is culture of IETF participants, but it seems that some people should understand to be polite and reasonable in such organisation business. Finally, the rude responding is not controled by the chair of thoes lists, therefore, thoes lists can be rude lists from time to time. AB
Re: Rude responses (sergeant-at-arms?)
Isn't there supposed to be a sergeant-at-arms to handle inappropriate behaviour on this list? Though the last I recall that was Jordi, and that was probably ten years ago... Though it would be preferable if everyone were a bit more respectful of other posters, whether new or veteran. Tim
Re: Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
Reviewer: Abdussalam Baryun Date: 26.08.2013 As per the IESG request for review dated 19.08.2013 I support the draft, thanks, below are my comments, Overall The draft is about 3GPP Mobile Devices but the draft has no normative reference to such device. The title of the draft SHOULD mention that it is general profile or a proposal, where the abstract says *specifies an IPv6 profile* which means not general, so the title SHOULD say *An IPv6 profile*. Also the draft does not consider Mobile IP issues nor RFC5213 into requirements. From the doc the reviewer is not sure does the draft consider MANET issues or not needed for such devices or such connections? Abstract This document specifies an IPv6 profile for 3GPP mobile devices. AB suggest this document defines an IPv6 profile The document is missing an applicability statement section, which may be found in one paragraph in section 1.1, but the reviewer would like more details because the document is some how saying it is general requirements. AB On Mon, Aug 19, 2013 at 11:52 PM, The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices' draft-ietf-v6ops-mobile-device-profile-04.txt as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-09-02. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies an IPv6 profile for 3GPP mobile devices. It lists the set of features a 3GPP mobile device is to be compliant with to connect to an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network). This document defines a different profile than the one for general connection to IPv6 cellular networks defined in [I-D.ietf-v6ops-rfc3316bis]. In particular, this document identifies also features to deliver IPv4 connectivity service over an IPv6-only transport. Both hosts and devices with capability to share their WAN (Wide Area Network) connectivity are in scope. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile/ballot/ No IPR declarations have been submitted directly on this I-D.
Re: Rude responses
As Seargeant-at-arms, this is my first and last warning. If this goes on, I will ask the secretariat to avoid further postings. Regards, Jordi -Mensaje original- De: Abdussalam Baryun abdussalambar...@gmail.com Responder a: abdussalambar...@gmail.com Fecha: martes, 27 de agosto de 2013 05:50 Para: l.w...@surrey.ac.uk CC: ietf ietf@ietf.org Asunto: Re: Rude responses On Mon, Aug 26, 2013 at 5:36 PM, l.w...@surrey.ac.uk wrote: I experienced rude respondings in IETF list That would be when you tried to get April 1 RFCs discontinued. No, I experienced rude response from some participants including you, and regarding yours I received a private email from one director that he ask me not to reply to you because he wants to handle it with you privately. I request that the IETF Chair to stop you from sending me any further emails, because you are changing the subject to personal issues. AB From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Abdussalam Baryun [abdussalambar...@gmail.com] Sent: 25 August 2013 12:27 To: Pete Resnick Cc: dcroc...@bbiw.net; ietf@ietf.org Subject: Re: Rude responses (Was: Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard) I experienced rude respondings in IETF list and in one WG list, I don't beleive that it is culture of IETF participants, but it seems that some people should understand to be polite and reasonable in such organisation business. Finally, the rude responding is not controled by the chair of thoes lists, therefore, thoes lists can be rude lists from time to time. AB ** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
Re: Rude responses (sergeant-at-arms?)
I'm I was traveling and not having access to email Regards, Jordi -Mensaje original- De: Tim Chown t...@ecs.soton.ac.uk Responder a: t...@ecs.soton.ac.uk Fecha: martes, 27 de agosto de 2013 06:51 Para: ietf ietf@ietf.org Asunto: Re: Rude responses (sergeant-at-arms?) Isn't there supposed to be a sergeant-at-arms to handle inappropriate behaviour on this list? Though the last I recall that was Jordi, and that was probably ten years ago... Though it would be preferable if everyone were a bit more respectful of other posters, whether new or veteran. Tim ** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
SM, As far as the IPR, as the shepherd and DISPATCH WG co-chair, I posted a note to the DISPATCH WG mailing list before progressing this document to see if anyone had any concerns about the IPR disclosures, which had been discussed in the past and were updated when I asked the authors the requisite questions about IPR while doing the PROTO write-up. No concerns were raised with regards to the updated IPR disclosures (i.e., no one responded to that email). And, you can google draft montemurro ietf ipr archives to find past discussions such as this one: draft montemurro ietf ipr archives Regards, Mary. On Sun, Jul 21, 2013 at 11:38 AM, S Moonesamy sm+i...@elandsys.com wrote: At 00:03 21-07-2013, Andrew Allen wrote: The reason why the IMEI namespace is being registered as a GSMA namespace and not as part of the 3GPP namespace is that the GSMA has the responsibility for IMEI assignment and hence in maintaining uniqueness of the namespace. It has nothing to do with IPR which was extensively discussed on the dispatch list. I read the dispatch mailing list. I did not see the extensive discussion. I saw the following comment Surely that is just trying to turn the IETF into the policeman. The primary purpose of the IMEI is for preventing use of stolen mobile phones and enabling emergency calls to be made from mobiles that don't have a valid subscription. From what I read the main purpose of the IMEI is to be able to take measures against stolen phones and against equipment which the use cannot be accepted for technical or safety reasons. The secondary purpose is the tracing of malicious calls. There is an apps which sends the IMEI in a cryptographically-protected form over the network. For what it is worth, it's MD5. There has been some work in the IETF on emergency calls (see service URN). At 00:12 21-07-2013, Andrew Allen wrote: As John pointed out having the sub namespace reviewed by IETF provides the opportunity to add text to address privacy concerns with any inappropriate usage. I don't think that it is the role of the IETF to determine whether the usage of a sub-namespace is appropriate or not as it can cause namespace management issues. I tried the explain the subtlety between privacy concerns and privacy considerations. The IMEI can also be used as a customer identifier. Regards, S. Moonesamy
Re: Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
On 2013-08-26, at 22:28, S Moonesamy sm+i...@elandsys.com wrote: The permitted size of the UDP packet is NOT 512 octets. That is the permitted size of the DNS Message. DNS Message is not the same thing as a UDP packet. Per RFC1035 Section 2.3.4. Size limits UDP messages512 octets or less I'll suggest UDP message. The consistent word for this in 1035 is simply message. DNS Message is in more common use today, I would say. The text you quoted from 1035 is most usefully interpreted as a contraction of messages sent over UDP; UDP message really doesn't have a well-understood meaning, and is easily conflated with UDP datagram which does not have a size limitation of 512 bytes. Joe
Gen-ART review of draft-ietf-dime-overload-reqs-11
The -11 version of this draft addresses all of the nits and editorial comments noted in the Gen-ART review of the -10 version. It's ready for publication as an Informational RFC. Thanks, --David -Original Message- From: Ben Campbell [mailto:b...@nostrum.com] Sent: Thursday, August 22, 2013 4:50 PM To: Black, David Cc: Eric McMurry; General Area Review Team (gen-...@ietf.org); ietf@ietf.org; d...@ietf.org; bcla...@cisco.com Subject: Re: Gen-ART review of draft-ietf-dime-overload-reqs-10 Hi David, We agree on all your points, and will make the updates in the next version, pending shepherd instructions. Thanks! Ben. On Aug 22, 2013, at 2:50 PM, Black, David david.bl...@emc.com wrote: Hi Eric, This looks good - comments follow ... a) I assume that overload control development work will derive more specific security requirements - e.g., as REQ 27 is stated at a rather high level. The discussion in security considerations section seems reasonable. We agree with this. The thinking here was that we didn't want to specify this in a way that would be specific to a particular type of mechanism. It might not hurt to state that assumption, either as a note on Req 27 or in the sec considerations. That would be good to add as a note on REQ 27. The intent was very much as you say, where requirements on individual node capabilities are hoped to result in better overall system behaviors. There are also some requirements that are stated more at the system level (e.g. 7 and 17.) Also the text in section 2.2 that discusses Figure 5 talks about how insufficient server capacity at a cluster of servers behind a Diameter agent can be treated as if the agent itself was overloaded. On the other hand, any mechanism we design will have to focus on actions of individual nodes, so the numbered requirements tend to focus on that. I'm not sure where to change the balance here--do you have specific suggestions? I noted this as editorial rather than a minor issue, as I was mostly concerned that the actual design work will be informed by a sufficient architectural clue that the goal is better overall system behaviors, which your response indicates will definitely be the case ;-). Rather than edit individual requirements, how about adding the following sentence immediately following the introductory sentence in Section 7?: These requirements are stated primarily in terms of individual node behavior to inform the design of the improved mechanism; that design effort should keep in mind that the overall goal is improved overall system behavior across all the nodes involved, not just improved behavior from specific individual nodes. This inadequacy may, in turn, contribute to broader congestion collapse collapse is not the right word here - I suggest issues, impacts, effects or problems. We are fine with any of those alternatives. How about impacts. That's fine. FWIW, congestion collapse has a specific (rather severe) meaning over in the Transport Area, and that meaning was not intended here. 23.843 is the least stable reference. I don't have any issue with pointing that out. The part of it we are referencing is historical front matter though. I'd note the reference as work in progress, and put the statement about stable front matter (historical is a bad work to use here) in the body of the draft that cites the reference. I tried the web and downloaded versions of 2.12.17 and was not able to get the warnings you saw (about the references). What did it say? Sorry, I didn't mean to send you on a wild goose chase :-). The idnits confusion manifested right at the top of the output, where everyone ignores it ... Attempted to download rfc272 state... Failure fetching the file, proceeding without it. You didn't reference RFC 272, so that output's apparently courtesy of idnits misinterpreting this reference: 1195 [TS29.272] 1196 3GPP, Evolved Packet System (EPS); Mobility Management 1197 Entity (MME) and Serving GPRS Support Node (SGSN) related 1198 interfaces based on Diameter protocol, TS 29.272 11.4.0, 1199 September 2012. I was amused :-). Thanks, --David -Original Message- From: Eric McMurry [mailto:emcmu...@computer.org] Sent: Thursday, August 22, 2013 3:06 PM To: Black, David Cc: b...@nostrum.com; General Area Review Team (gen-...@ietf.org); ietf@ietf.org; d...@ietf.org; bcla...@cisco.com Subject: Re: Gen-ART review of draft-ietf-dime-overload-reqs-10 Hi David, Thank you for the review. Your time and comments are appreciated! comments/questions inline. Eric On Aug 17, 2013, at 9:18 , Black, David david.bl...@emc.com wrote: I am
Re: Rude responses (sergeant-at-arms?)
FWIW, if we are going to go down that road, it would be worth noting that there are various kinds of rudeness that can occur on IETF mailing lists. To my mind, the most harmful of these is not outright rudeness. Outright rudeness is to be avoided, certainly. But the most rude behavior that ever occurs on IETF mailing lists is not listening. Not trying to understand what the person who is speaking to you has said. Not trying to figure out if what they said meaningfully contradicts your own position, and not making a sincere effort to determine if they might be correct in contradicting your position. We have seen some incredible rudeness of this type in the recent spfbis discussion, with various supposedly smart people in our community utterly ignoring what their opponents are saying, and simply re-asserting their own position in a variety of ways. I would expect the sergeant-at-arms to be reining in that sort of rudeness before reining in the sort of supposed overt rudeness that we are discussing here. The endless litany of repeats of already-addressed discussion points raised on the spfbis mailing list has been incredibly harmful to discourse on the ietf mailing list. This exchange between l.wood and Abdussalam Baryun pales in comparison. Furthermore, I would also point out that criticism of someone's behavior is not rudeness, if that criticism is accurate. I don't think the IETF should be a context in which people ought to feel safe in behaving badly, as long as they behave badly in ways that are subtle enough not to be considered impolite. Nor should it be a context in which failure to behave according to some culturally-relative standard of politeness in itself invalidates an otherwise valid statement.
Re: Gen-ART review of draft-ietf-dime-overload-reqs-11
Thanks, David! On Aug 27, 2013, at 11:40 AM, Black, David david.bl...@emc.com wrote: The -11 version of this draft addresses all of the nits and editorial comments noted in the Gen-ART review of the -10 version. It's ready for publication as an Informational RFC. Thanks, --David -Original Message- From: Ben Campbell [mailto:b...@nostrum.com] Sent: Thursday, August 22, 2013 4:50 PM To: Black, David Cc: Eric McMurry; General Area Review Team (gen-...@ietf.org); ietf@ietf.org; d...@ietf.org; bcla...@cisco.com Subject: Re: Gen-ART review of draft-ietf-dime-overload-reqs-10 Hi David, We agree on all your points, and will make the updates in the next version, pending shepherd instructions. Thanks! Ben. On Aug 22, 2013, at 2:50 PM, Black, David david.bl...@emc.com wrote: Hi Eric, This looks good - comments follow ... a) I assume that overload control development work will derive more specific security requirements - e.g., as REQ 27 is stated at a rather high level. The discussion in security considerations section seems reasonable. We agree with this. The thinking here was that we didn't want to specify this in a way that would be specific to a particular type of mechanism. It might not hurt to state that assumption, either as a note on Req 27 or in the sec considerations. That would be good to add as a note on REQ 27. The intent was very much as you say, where requirements on individual node capabilities are hoped to result in better overall system behaviors. There are also some requirements that are stated more at the system level (e.g. 7 and 17.) Also the text in section 2.2 that discusses Figure 5 talks about how insufficient server capacity at a cluster of servers behind a Diameter agent can be treated as if the agent itself was overloaded. On the other hand, any mechanism we design will have to focus on actions of individual nodes, so the numbered requirements tend to focus on that. I'm not sure where to change the balance here--do you have specific suggestions? I noted this as editorial rather than a minor issue, as I was mostly concerned that the actual design work will be informed by a sufficient architectural clue that the goal is better overall system behaviors, which your response indicates will definitely be the case ;-). Rather than edit individual requirements, how about adding the following sentence immediately following the introductory sentence in Section 7?: These requirements are stated primarily in terms of individual node behavior to inform the design of the improved mechanism; that design effort should keep in mind that the overall goal is improved overall system behavior across all the nodes involved, not just improved behavior from specific individual nodes. This inadequacy may, in turn, contribute to broader congestion collapse collapse is not the right word here - I suggest issues, impacts, effects or problems. We are fine with any of those alternatives. How about impacts. That's fine. FWIW, congestion collapse has a specific (rather severe) meaning over in the Transport Area, and that meaning was not intended here. 23.843 is the least stable reference. I don't have any issue with pointing that out. The part of it we are referencing is historical front matter though. I'd note the reference as work in progress, and put the statement about stable front matter (historical is a bad work to use here) in the body of the draft that cites the reference. I tried the web and downloaded versions of 2.12.17 and was not able to get the warnings you saw (about the references). What did it say? Sorry, I didn't mean to send you on a wild goose chase :-). The idnits confusion manifested right at the top of the output, where everyone ignores it ... Attempted to download rfc272 state... Failure fetching the file, proceeding without it. You didn't reference RFC 272, so that output's apparently courtesy of idnits misinterpreting this reference: 1195 [TS29.272] 1196 3GPP, Evolved Packet System (EPS); Mobility Management 1197 Entity (MME) and Serving GPRS Support Node (SGSN) related 1198 interfaces based on Diameter protocol, TS 29.272 11.4.0, 1199 September 2012. I was amused :-). Thanks, --David -Original Message- From: Eric McMurry [mailto:emcmu...@computer.org] Sent: Thursday, August 22, 2013 3:06 PM To: Black, David Cc: b...@nostrum.com; General Area Review Team (gen-...@ietf.org); ietf@ietf.org; d...@ietf.org; bcla...@cisco.com Subject: Re: Gen-ART review of draft-ietf-dime-overload-reqs-10 Hi David, Thank you for the review. Your time and comments are appreciated! comments/questions inline. Eric On Aug 17, 2013, at 9:18 , Black, David david.bl...@emc.com wrote:
Re: Rude responses (sergeant-at-arms?)
On Tue, Aug 27, 2013 at 1:11 PM, Ted Lemon ted.le...@nominum.com wrote: But the most rude behavior that ever occurs on IETF mailing lists is not listening. Not trying to understand what the person who is speaking to you has said. Not trying to figure out if what they said meaningfully contradicts your own position, and not making a sincere effort to determine if they might be correct in contradicting your position. We have seen some incredible rudeness of this type in the recent spfbis discussion, with various supposedly smart people in our community utterly ignoring what their opponents are saying, and simply re-asserting their own position in a variety of ways. I would expect the sergeant-at-arms to be reining in that sort of rudeness before reining in the sort of supposed overt rudeness that we are discussing here. The endless litany of repeats of already-addressed discussion points raised on the spfbis mailing list has been incredibly harmful to discourse on the ietf mailing list. IMHO that's not a job for the sergeant at arms. The SAA is responsible for how things are said. The shepherd -- or supershepherd or whatever -- would be responsible for the substance.
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
Hi Mary, At 07:28 27-08-2013, Mary Barnes wrote: As far as the IPR, as the shepherd and DISPATCH WG co-chair, I posted a note to the DISPATCH WG mailing list before progressing this document to see if anyone had any concerns about the IPR disclosures, which had been discussed in the past and were updated when I asked the authors the requisite questions about IPR while doing the PROTO write-up. No concerns were raised with regards to the updated IPR disclosures (i.e., no one responded to that email). And, you can google draft montemurro ietf ipr archives to find past discussions such as this one: draft montemurro ietf ipr archives Thanks for the feedback. Somebody commented that: It has nothing to do with IPR which was extensively discussed on the dispatch list. I read the DISPATCH mailing list archives. I did not see that extensive discussion. My comment was about that. I do not have any problem with the document shepherd comments. Regards, S. Moonesamy
Re: Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
Hi Joe, At 08:59 27-08-2013, Joe Abley wrote: The consistent word for this in 1035 is simply message. DNS Message is in more common use today, I would say. The text you quoted from 1035 is most usefully interpreted as a contraction of messages sent over UDP; UDP message really doesn't have a well-understood meaning, and is easily conflated with UDP datagram which does not have a size limitation of 512 bytes. Thanks for explaining this. Please note that I personally agree with what you wrote. My understanding is that the text in Section 3.4 is trying to say DNS messages over UDP. There was some discussion about that (see http://www.ietf.org/mail-archive/web/spfbis/current/msg03088.html http://www.ietf.org/mail-archive/web/spfbis/current/msg03090.html http://www.ietf.org/mail-archive/web/spfbis/current/msg03109.html ). Regards, S. Moonesamy (as document shepherd)
Re: Rude responses (sergeant-at-arms?)
On 8/27/13 9:11 AM, Ted Lemon wrote: I would expect the sergeant-at-arms to be reining in that sort of rudeness before reining in the sort of supposed overt rudeness that we are discussing here. That suggestion makes me want to say something a little rude. Managing the discussion is the chair's job, not the sergeant- at-arms's. Melinda
Re: Rude responses (sergeant-at-arms?)
On Aug 27, 2013, at 1:20 PM, Scott Brim scott.b...@gmail.com wrote: IMHO that's not a job for the sergeant at arms. The SAA is responsible for how things are said. The shepherd -- or supershepherd or whatever -- would be responsible for the substance. I think it should be fairly obvious even to one not practiced in the art that a lot of the postings to the ietf mailing list recently have been simple repeats of points previously made, with no additional substance, which, well intentioned or not, purely have the effect of making it harder to evaluate consensus. But sure, the responsible AD could also intervene.
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
SM The past discussions on this took place a couple of years ago involving primarily Cullen Jennings, Dale Worley and myself. Andrew - Original Message - From: S Moonesamy [mailto:sm+i...@elandsys.com] Sent: Tuesday, August 27, 2013 10:20 AM Central Standard Time To: Mary Barnes mary.h.bar...@gmail.com Cc: John C Klensin j...@jck.com; tb...@textuality.com tb...@textuality.com; ietf@ietf.org ietf@ietf.org Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt Hi Mary, At 07:28 27-08-2013, Mary Barnes wrote: As far as the IPR, as the shepherd and DISPATCH WG co-chair, I posted a note to the DISPATCH WG mailing list before progressing this document to see if anyone had any concerns about the IPR disclosures, which had been discussed in the past and were updated when I asked the authors the requisite questions about IPR while doing the PROTO write-up. No concerns were raised with regards to the updated IPR disclosures (i.e., no one responded to that email). And, you can google draft montemurro ietf ipr archives to find past discussions such as this one: draft montemurro ietf ipr archives Thanks for the feedback. Somebody commented that: It has nothing to do with IPR which was extensively discussed on the dispatch list. I read the DISPATCH mailing list archives. I did not see that extensive discussion. My comment was about that. I do not have any problem with the document shepherd comments. Regards, S. Moonesamy - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: Rude responses (sergeant-at-arms?)
Ted Lemon ted.le...@nominum.com wrote: I think it should be fairly obvious even to one not practiced in the art that a lot of the postings to the ietf mailing list recently have been simple repeats of points previously made, with no additional substance, +1 Alas, that statement applies to both posts which raise issues and posts which refute issues. which, well intentioned or not, purely have the effect of making it harder to evaluate consensus. I feel sorry for Ted, who _does_ have to evaluate consensus here. For better or worse, current RFCs in standards track have boilerplate saying This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community... Unless and until this boilerplate changes, IESG members have an obligation to try to decide whether that statement is true. I'm _very_ glad I don't have that obligation! -- John Leslie j...@jlc.net
Re: Rude responses (sergeant-at-arms?)
At 10:11 27-08-2013, Ted Lemon wrote: But the most rude behavior that ever occurs on IETF mailing lists is not listening. Not trying to understand what the person who is speaking to you has said. Not trying to figure out if what they said meaningfully contradicts your own position, and not making a sincere effort to determine if they might be correct in contradicting your position. Yes. We have seen some incredible rudeness of this type in the recent spfbis discussion, with various supposedly smart people in our community utterly ignoring what their opponents are saying, and simply re-asserting their own position in a variety of ways. I'll add the message from Scott Brim below and comment. At 10:20 27-08-2013, Scott Brim wrote: IMHO that's not a job for the sergeant at arms. The SAA is responsible for how things are said. The shepherd -- or supershepherd or whatever -- would be responsible for the substance. The shepherd would have to request PR-action on the grounds that there has been a BCP violation. That would cause other process issues. The community will remain quiet and the shepherd will take the fall. At 12:08 27-08-2013, John Leslie wrote: I feel sorry for Ted, who _does_ have to evaluate consensus here. Me too. Regards, S. Moonesamy
Re: I-D Action: draft-sweet-uri-zoneid-00.txt
I am *not* an author of this draft, which Michael Sweet produced on his own. I have not read the draft and have no idea whether I agree with it. (I believe this was an honest mistake on his part but I don't want there to be any misunderstanding.) Regards Brian Carpenter On 28/08/2013 03:55, internet-dra...@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers Author(s) : Michael Sweet Brian Carpenter Stuart Cheshire Robert M. Hinden Filename: draft-sweet-uri-zoneid-00.txt Pages : 11 Date: 2013-08-27 Abstract: This document describes how the zone identifier of an IPv6 scoped address, defined as zone_id in the IPv6 Scoped Address Architecture (RFC 4007), can be represented in a literal IPv6 address and in a Uniform Resource Identifier that includes such a literal address. It updates the URI Generic Syntax specification (RFC 3986) accordingly. [ Editor's note: This draft adds the IPvFuture format used by CUPS since 2005, addresses some misconceptions of how zoneid's are not useful to HTTP servers, and is intended to replace RFC 6874. ] The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-sweet-uri-zoneid There's also a htmlized version available at: http://tools.ietf.org/html/draft-sweet-uri-zoneid-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ I-D-Announce mailing list i-d-annou...@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Re: Rude responses (sergeant-at-arms?)
On Aug 27, 2013, at 3:08 PM, John Leslie j...@jlc.net wrote: I feel sorry for Ted, who _does_ have to evaluate consensus here. Actually no, I don't—spfbis is apps area, not int area. Lucky me... :)
Re: Gen-ART review of draft-ietf-dime-overload-reqs-11
Great. Thanks! - Jouni On Aug 27, 2013, at 7:40 PM, Black, David david.bl...@emc.com wrote: The -11 version of this draft addresses all of the nits and editorial comments noted in the Gen-ART review of the -10 version. It's ready for publication as an Informational RFC. Thanks, --David -Original Message- From: Ben Campbell [mailto:b...@nostrum.com] Sent: Thursday, August 22, 2013 4:50 PM To: Black, David Cc: Eric McMurry; General Area Review Team (gen-...@ietf.org); ietf@ietf.org; d...@ietf.org; bcla...@cisco.com Subject: Re: Gen-ART review of draft-ietf-dime-overload-reqs-10 Hi David, We agree on all your points, and will make the updates in the next version, pending shepherd instructions. Thanks! Ben. On Aug 22, 2013, at 2:50 PM, Black, David david.bl...@emc.com wrote: Hi Eric, This looks good - comments follow ... a) I assume that overload control development work will derive more specific security requirements - e.g., as REQ 27 is stated at a rather high level. The discussion in security considerations section seems reasonable. We agree with this. The thinking here was that we didn't want to specify this in a way that would be specific to a particular type of mechanism. It might not hurt to state that assumption, either as a note on Req 27 or in the sec considerations. That would be good to add as a note on REQ 27. The intent was very much as you say, where requirements on individual node capabilities are hoped to result in better overall system behaviors. There are also some requirements that are stated more at the system level (e.g. 7 and 17.) Also the text in section 2.2 that discusses Figure 5 talks about how insufficient server capacity at a cluster of servers behind a Diameter agent can be treated as if the agent itself was overloaded. On the other hand, any mechanism we design will have to focus on actions of individual nodes, so the numbered requirements tend to focus on that. I'm not sure where to change the balance here--do you have specific suggestions? I noted this as editorial rather than a minor issue, as I was mostly concerned that the actual design work will be informed by a sufficient architectural clue that the goal is better overall system behaviors, which your response indicates will definitely be the case ;-). Rather than edit individual requirements, how about adding the following sentence immediately following the introductory sentence in Section 7?: These requirements are stated primarily in terms of individual node behavior to inform the design of the improved mechanism; that design effort should keep in mind that the overall goal is improved overall system behavior across all the nodes involved, not just improved behavior from specific individual nodes. This inadequacy may, in turn, contribute to broader congestion collapse collapse is not the right word here - I suggest issues, impacts, effects or problems. We are fine with any of those alternatives. How about impacts. That's fine. FWIW, congestion collapse has a specific (rather severe) meaning over in the Transport Area, and that meaning was not intended here. 23.843 is the least stable reference. I don't have any issue with pointing that out. The part of it we are referencing is historical front matter though. I'd note the reference as work in progress, and put the statement about stable front matter (historical is a bad work to use here) in the body of the draft that cites the reference. I tried the web and downloaded versions of 2.12.17 and was not able to get the warnings you saw (about the references). What did it say? Sorry, I didn't mean to send you on a wild goose chase :-). The idnits confusion manifested right at the top of the output, where everyone ignores it ... Attempted to download rfc272 state... Failure fetching the file, proceeding without it. You didn't reference RFC 272, so that output's apparently courtesy of idnits misinterpreting this reference: 1195 [TS29.272] 1196 3GPP, Evolved Packet System (EPS); Mobility Management 1197 Entity (MME) and Serving GPRS Support Node (SGSN) related 1198 interfaces based on Diameter protocol, TS 29.272 11.4.0, 1199 September 2012. I was amused :-). Thanks, --David -Original Message- From: Eric McMurry [mailto:emcmu...@computer.org] Sent: Thursday, August 22, 2013 3:06 PM To: Black, David Cc: b...@nostrum.com; General Area Review Team (gen-...@ietf.org); ietf@ietf.org; d...@ietf.org; bcla...@cisco.com Subject: Re: Gen-ART review of draft-ietf-dime-overload-reqs-10 Hi David, Thank you for the review. Your time and comments are appreciated! comments/questions inline. Eric On Aug 17, 2013, at 9:18 , Black, David david.bl...@emc.com
Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
I probably should have sent out this message over the weekend, but I was hoping I would complete a bigger message soon. Since I'm still working on that, a quick note to level set: I have been reading all of the Last Call responses as they have come in. I am in the process of reviewing the comments and making a summary of the issues and responses. I have asked SM as document shepherd to do the same. (Being far more diligent than I, SM has completed his review already and is waiting on me.) We will be comparing notes and posting a summary of the issues and how they were addressed, along with whether we think they are resolved. That will give folks who disagree with my assessment one last chance to say, Pete, you completely misunderstood what my objection / response was saying and you should re-evaluate your consensus determination on this issue. After that all shakes out, I'll make the final call on consensus. An important thing to note is that I am seeing scant little I would call a new argument since late last week, so I would suggest that you are probably not adding to my understanding of the consensus by continuing to post. I'd like to think that everyone would be able to notice that things have gotten repetitive, both the folks who are repeating things as well as the folks who think they have to keep answering, but there does seem to be a bit of getting the last word in going on. Doing so isn't likely to add to my understanding or sway my opinion of the consensus (since I'm making a list of independent issues and their answers, not counting posts), but it does make it take longer for me to get through my review. So I'd recommend posting judiciously, at least until you see my summary. Thanks, pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Technologies, Inc. - +1 (858)651-4478
Re: Rude responses (sergeant-at-arms?)
On 8/27/13 2:53 PM, Ted Lemon wrote: On Aug 27, 2013, at 3:08 PM, John Lesliej...@jlc.net wrote: I feel sorry for Ted, who _does_ have to evaluate consensus here. Actually no, I don't—spfbis is apps area, not int area. Lucky me... :) See the message I just posted. Yes, the additional repetitions make it take longer, but really it's not so hard to say, Yep, that's already on my list of issues and toss the repetitious message aside. On 8/27/13 12:20 PM, Scott Brim wrote: On 8/27/13 9:11 AM, Ted Lemon wrote: I would expect the sergeant-at-arms to be reining in that sort of rudeness before reining in the sort of supposed overt rudeness that we are discussing here. IMHO that's not a job for the sergeant at arms. The SAA is responsible for how things are said. The shepherd -- or supershepherd or whatever -- would be responsible for the substance. On 8/27/13 12:31 PM, Melinda Shore wrote: That suggestion makes me want to say something a little rude. Managing the discussion is the chair's job, not the sergeant- at-arms's. Yeah, again, that's me. Also see my recent message. That said, I do wish it didn't take intervention on my part. I wish people would realize they're being repetitive. I wish people would stop responding to the repetition. (Neither is going to change my opinion of the consensus.) But then again, I also wish I had a pony. pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Technologies, Inc. - +1 (858)651-4478
Re: charging remote participants
Hadriel said: I agree. My proposal for how/what/where to get more revenue (and not from remote participants) was only in case we actually need it to pay for enhancing remote participation. It's not clear we have such a need any time soon, but I was only trying to provide an alternative model to charging remote participants. [BA] It appears quite possible to significantly enhance remote participation in the IETF with minimal funding. The load pattern of the IETF (heavy during physical meetings, much lower in between), accommodates itself well to the use of cloud services. - making it possible for the IETF to avoid having to purchase hardware to handle the peak load, instead being able to scale up/down capacity as needed. From what I can tell, the breadth and depth of services obtainable for a few thousand $/year of expenditure is pretty impressive. As an example, the cost of putting up an audio conferencing service supporting Opus (usable by any WG that needed it for virtual or design team meetings) would only be a few hundred $/year, excluding the cost of PSTN connectivity. Even small scale video conferencing doesn't appear to be very expensive. If there are only a few video participants, it is possible to mix on the peer, and for centralized conferencing, a small instance virtual machine (e.g. one core, 1 GB RAM) appears capable of handling half a dozen participants using software such as jitsi-videobridge, without breaking a sweat. So, a thousand $/year might cover it (assuming that we aren't attempting to provide telepresence-quality video). Even if money were *really* tight, we could easily obtain donations to cover costs in that ballpark. IMHO, the hard problems relate to engineering, not finance. In particular, the challenge is to provide a system with low administrative overhead and good ease-of-use, integrated with IETF processes. To advance the state of the art, IAOC RPS committee (see http://iaoc.ietf.org/committees.html#rps) will continue to sponsor ongoing experiments at meetings, as well as pilot tests.
Re: I-D Action: draft-sweet-uri-zoneid-00.txt
On Aug 27, 2013, at 12:48 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: I am *not* an author of this draft, which Michael Sweet produced on his own. I have not read the draft and have no idea whether I agree with it. (I believe this was an honest mistake on his part but I don't want there to be any misunderstanding.) I am in the same situation and like Brian I do not know if I support this or not. Bob Regards Brian Carpenter On 28/08/2013 03:55, internet-dra...@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers Author(s) : Michael Sweet Brian Carpenter Stuart Cheshire Robert M. Hinden Filename: draft-sweet-uri-zoneid-00.txt Pages : 11 Date: 2013-08-27 Abstract: This document describes how the zone identifier of an IPv6 scoped address, defined as zone_id in the IPv6 Scoped Address Architecture (RFC 4007), can be represented in a literal IPv6 address and in a Uniform Resource Identifier that includes such a literal address. It updates the URI Generic Syntax specification (RFC 3986) accordingly. [ Editor's note: This draft adds the IPvFuture format used by CUPS since 2005, addresses some misconceptions of how zoneid's are not useful to HTTP servers, and is intended to replace RFC 6874. ] The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-sweet-uri-zoneid There's also a htmlized version available at: http://tools.ietf.org/html/draft-sweet-uri-zoneid-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ I-D-Announce mailing list i-d-annou...@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Re: Rude responses (sergeant-at-arms?)
Sometimes there is a need for sarcasm. I find it very rude when people begin by lecturing a Working Group on the 'fact' that nobody understands the subject matter. This is not the exhibition of modesty etc. that it pretends to be, it is actually a trap designed to gull the WG into agreeing that they know nothing about the problem whereupon the original proposer will gladly provide the poor naifs with their pearls of wisdom. The correct response in such situations is in my book, 'you may speak for yourself and your own level of expertise but do not accuse others of sharing your inabilities'. I also find it very rude when people try to cut short a discussion with recourse to bogus points of processor try to trump a discussion with recourse to an authority that I know from private conversations to hold the exact opposite opinion to the one being attributed to them. What I found incredibly rude was when an AD and Working Group chair actually hissed when I gave my company name at the mic. But what I found worst was the fact that nobody seemed to be taking any notice at all of the four women who raised diversity issues at the mic in Orlando until I got up to the mic and mansplained the issue for you all.
Re: Rude responses (sergeant-at-arms?)
Hi Phillip, At 15:53 27-08-2013, Phillip Hallam-Baker wrote: What I found incredibly rude was when an AD and Working Group chair actually hissed when I gave my company name at the mic. I submitted draft-moonesamy-ietf-conduct-3184bis During the discussions (see thread at http://www.ietf.org/mail-archive/web/diversity/current/msg00201.html )about the draft it was suggested there should be consequences of not following the code of conduct. What action would you suggest against: (i) the Area Director in a case such as the above? (ii) the Working Group chair in a case such as the above? Regards, S. Moonesamy
Last Call: draft-ietf-repute-model-08.txt (A Model for Reputation Reporting) to Proposed Standard
The IESG has received a request from the Reputation Services WG (repute) to consider the following document: - 'A Model for Reputation Reporting' draft-ietf-repute-model-08.txt as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2013-09-10. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. This is a new Last Call on this document. It was previously in Last Call for Informational, but after some Last Call comments, the WG decided that it would be more appropriate on the standards track. The due date has been extended accordingly. Abstract This document describes a general architecture for a reputation-based service and a model for requesting reputation-related data over the Internet, where reputation refers to predictions or expectations about an entity or an identifier such as a domain name. The document roughly follows the recommendations of RFC4101 for describing a protocol model. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-repute-model/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-repute-model/ballot/ No IPR declarations have been submitted directly on this I-D.
Protocol Action: 'WebFinger' to Proposed Standard (draft-ietf-appsawg-webfinger-18.txt)
The IESG has approved the following document: - 'WebFinger' (draft-ietf-appsawg-webfinger-18.txt) as Proposed Standard This document is the product of the Applications Area Working Group. The IESG contact persons are Barry Leiba and Pete Resnick. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/ Technical Summary This specification defines the WebFinger protocol, which can be used to discover information about people or other entities on the Internet using standard HTTP methods. WebFinger discovers information for a URI that might not be usable as a locator otherwise, such as account or email URIs. Review and Consensus The WebFinger draft has been discussed extensively within the APPSAwg during the last year, it become a wg item in August 2012. Actually at some point the mail traffic generated by the discussion was so high that it was agreed to move the discussion to a dedicated mailing list (webfin...@ietf.org). The only significant point difficult to agree on has been about whether WebFinger MUST support HTTPS only or instead it should be allowed for WebFinger fallback from HTTPS to HTTP. That was resolved with a consensus call that generated a strong rough consensus for HTTPS only. The draft has been also extensively reviewed during the APPSAwg Last Call. A lot of editorial issues, text clarifications have been raised; all of them are now addressed in the current version of the draft. During the wglc process it has been also agreed to define a new media type for WebFinger. There are several open source WebFinger implementations already updated to the last version of the draft, a not exhaustive list of them can be found here: http://www.packetizer.com/webfinger/software.html Personnel Salvatore Loreto is the document shepherd. Barry Leiba is the responsible Area Director.
Last Call: draft-cotton-rfc4020bis-01.txt (Early IANA Allocation of Standards Track Code Points) to Best Current Practice
The IESG has received a request from an individual submitter to consider the following document: - 'Early IANA Allocation of Standards Track Code Points' draft-cotton-rfc4020bis-01.txt as Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2013-09-24. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This memo describes the process for early allocation of code points by IANA from registries for which Specification Required, RFC Required, IETF Review, or Standards Action policies apply. This process can be used to alleviate the problem where code point allocation is needed to facilitate desired or required implementation and deployment experience prior to publication of an RFC that would normally trigger code point allocation. This document obsoletes RFC 4020. The file can be obtained via http://datatracker.ietf.org/doc/draft-cotton-rfc4020bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-cotton-rfc4020bis/ballot/ No IPR declarations have been submitted directly on this I-D.
