Re: Montevideo statement

On Oct 8, 2013, at 11:44 PM, Andrew Sullivan wrote: > Dear colleagues, > > On Tue, Oct 08, 2013 at 10:55:08PM -0700, SM wrote: >> This is the second time that the IAB has issued a statement > > Speaking only (empahtically only) for myself, I quite strongly > disagree. The IAB has issued no st

Re: Montevideo statement

Dear colleagues, On Tue, Oct 08, 2013 at 10:55:08PM -0700, SM wrote: > This is the second time that the IAB has issued a statement Speaking only (empahtically only) for myself, I quite strongly disagree. The IAB has issued no statement in this case. The text as posted is quite clear: ---%<---c

Re: Montevideo statement

Hi Russ, At 15:51 07-10-2013, Stephane Bortzmeyer wrote: This wording is surprising. It looks like it is the revelations that undermined confidence, and not the NSA actions. I would prefer something like, to avoid shooting the messenger: They expressed strong concern over the undermining of the

Re: Last calling draft-resnick-on-consensus

On Mon, 7 Oct 2013, Jari Arkko wrote: You should see a last call announcement soon, and both me and Pete look forward to your feedback. As a semi-newbie (2 meetings, a few years worth of remote participation), I found this document useful. It clearified my understanding of "rough consensus".

Re: Last Call: (On Consensus and Humming in the IETF) to Informational RFC

On 2013-10-09 13:30, Melinda Shore wrote: On 10/8/13 9:20 PM, Loa Andersson wrote: FWIW - my personal way of thinking about consensus vs. rough consensus, please note that it my personal view not a definition. Consensus - An agreement by everyone in a group that a proposed soluti

Re: Last Call: (On Consensus and Humming in the IETF) to Informational RFC

On 10/8/13 9:20 PM, Loa Andersson wrote: > FWIW - my personal way of thinking about consensus vd. rough consensus, > please note that it my personal view not a definition. > > Consensus - An agreement by everyone in a group that a proposed > solution is the best of all of all possible

Re: Last Call: (On Consensus and Humming in the IETF) to Informational RFC

All, FWIW - my personal way of thinking about consensus vd. rough consensus, please note that it my personal view not a definition. Consensus - An agreement by everyone in a group that a proposed solution is the best of all of all possible solutions Rough consensus - An agreement by

Re: Last Call: (On Consensus and Humming in the IETF) to Informational RFC

On Oct 8, 2013, at 8:23 PM, Melinda Shore wrote: > I've done a lot of work on consensus over the years and I think > this is fundamentally correct, although I'd amend the last sentence > to something along the lines of "While we may not all agree, those > who disagree can live with it." That is

Re: Last Call: (On Consensus and Humming in the IETF) to Informational RFC

On 10/8/13 3:21 PM, Fred Baker (fred) wrote: > To my small and somewhat naive mind, the difference between rough > consensus on a topic and a vote on the same topic is something about > winners and losers. In a purely political process, when a set of > parties vote on something and the preponderanc

Re: Last calling draft-resnick-on-consensus

On 10/08/2013 07:56 AM, t.p. wrote: 3) References to working groups with 100 active participants sound like a chimera. I track quite a number of lists, and some have about five active participants. (Some Working Group Last Calls attract one or even zero responses; the reactions of chairs to thi

RE: Last Call: (Implications of Oversized IPv6 Header Chains) to Proposed Standard

I agree with Ole. Ron > -Original Message- > From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of > Ole Troan > Sent: Tuesday, October 08, 2013 12:17 PM > To: Templin, Fred L > Cc: i...@ietf.org; ietf@ietf.org; IETF-Announce > Subject: Re: Last Call: > (Implicat

Re: Last Call: (On Consensus and Humming in the IETF) to Informational RFC

On Oct 8, 2013, at 1:56 PM, S Moonesamy wrote: > I am not sure whether hums are for a starting point or not. It can be argued > in different ways, for example, see Section 4. Humming helps to get a sense > of the room without people making a decision under duress. Personally, I think focus

Re: Gen-ART LC Review of draft-ietf-l2vpn-pbb-vpls-interop-05

Ben, Thanks for your comments. I have incorporated all your comments in rev06 of this draft. On 9/23/13 1:29 PM, "Ben Campbell" wrote: >I am the assigned Gen-ART reviewer for this draft. For background on >Gen-ART, please see the FAQ at > >

Re: The RFC xx99 Series

Hello. I would like to express my concern about retiring the xx99 RFCs. I think they still fill a need, especially over longer periods of time, and should not be discontinued. It was stated that they are no longer needed because "up to date information" is available online, and the RFC search en

Re: Gen-ART LC Review of draft-ietf-l2vpn-pbb-vpls-interop-05

Hi Ali, Those changes would resolve my comments. Thanks! Ben. On Oct 8, 2013, at 5:13 PM, Ali Sajassi (sajassi) wrote: > > Ben, > > Thanks for your comments. I have incorporated all your comments in rev06 > of this draft. > > > On 9/23/13 1:29 PM, "Ben Campbell" wrote: > >> I am the as

Re: Last Call: (On Consensus and Humming in the IETF) to Informational RFC

At 09:48 07-10-2013, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'On Consensus and Humming in the IETF' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this acti

Re: Last Call: (Guidelines for Creating New DHCPv6 Options) to Best Current Practice

On Oct 8, 2013, at 4:30 PM, Cullen Jennings (fluffy) wrote: > Part of why you can't do this with DHCP is that clients are written so that > when an IP address fails to work for an application connection, the > application re does the DNS and gets the new address (assuming TTL had been > moved d

Gen-ART Telechat Review of draft-ietf-intarea-flow-label-balancing-02

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>. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-intarea-flow-

Gen-ART Telechat Review of draft-yusef-dispatch-ccmp-indication-06

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>. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-yusef-dispatch-ccm

Re: Last Call: (Guidelines for Creating New DHCPv6 Options) to Best Current Practice

(Dear OPs ADs, please read … ) I disagree with the advice in section 8. Cisco IP phones have been deployed with DHCP options that use FQDN and with options that use IP addresses. For this type of use case the FQDM turned out to be much better from an operational and administration point of v

Re: [Sdn] FW: Last Call: (Software-Defined Networking: A Perspective From Within A Service Provider) to Informational RFC

Adrian, Thanks for sharing this draft. This is a very good draft to summarize SDN for carrier networks. Two comments: - 100% Agree with the draft on the emphasis of PDP (Policy Decision Point) and PEP (Policy enforcement Point) components of SDN. why does the draft emphasize that "SDN appro

Re: The RFC xx99 Series

On 2013-10-08, at 11:38, Donald Eastlake wrote: > Or how about reserving "RFC 3399" for use as an example RFC number... Do we need a document to document that document for use in documents as documentation? Joe

Re: Last Call: (On Consensus and Humming in the IETF) to Informational RFC

On Oct 7, 2013, at 12:03 PM, Ted Hardie wrote: > Lastly, I think Pete has failed to capture that one reason for using humming > or hands is that it is easy for very active participants to dominate a > conversation > but much less easy for them to pretend to be a large group. Particularly in

Re: Last Call: (Implications of Oversized IPv6 Header Chains) to Proposed Standard

Hi, Fred, Thanks so much for your feedback! -- Please find my comments in-line... On 10/08/2013 03:33 PM, Templin, Fred L wrote: >> I would claim that additional encapsulation headers are already >> considered in the 1280 minimum MTU. >> as in: 1500 - 1280. > > It is kind of like that, but what

NOMCOM 2013 - UPDATED 2nd Call for Nominations - APP, OAM, RAI, TSV

UPDATE: nominations are too sparse in several of the IESG areas: APP, OAM, RAI, and TSV. If you know one or more of those areas, exercise your social network and submit nominations. We'll be very grateful! Is there someone you work with at IETF who has leadership potential and a growing track r

Re: The RFC xx99 Series

Or how about reserving "RFC 3399" for use as an example RFC number... Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com On Tue, Oct 8, 2013 at 2:32 PM, Eric Gray wrote: > Maybe we should reser

RE: Last Call: (Implications of Oversized IPv6 Header Chains) to Proposed Standard

Hi Ole, > -Original Message- > From: Ole Troan [mailto:otr...@employees.org] > Sent: Tuesday, October 08, 2013 9:17 AM > To: Templin, Fred L > Cc: ietf@ietf.org; IETF-Announce; i...@ietf.org > Subject: Re: Last Call: > (Implications of Oversized IPv6 Header Chains) to Proposed Standard >

RE: The RFC xx99 Series

Maybe we should reserve RFC 3399 for an April 1st RFC? -- E -Original Message- From: ietf-announce-boun...@ietf.org [mailto:ietf-announce-boun...@ietf.org] On Behalf Of RFC Series Editor Sent: Tuesday, October 08, 2013 1:51 PM To: IETF Announcement List Cc: r...@iab.org Subject: The RFC

Re: Last Call: (On Consensus and Humming in the IETF) to Informational RFC

Some comments in-line. On Tue, Oct 8, 2013 at 8:47 AM, Dave Crocker wrote: > On 10/8/2013 8:36 AM, Ted Hardie wrote: > >> And what are the RFC numbers for the comments? If none, as I suspect, >> then the comments aren't the same status as the documents--that's fine >> for RFC 791 and 2460, but

Re: Last Call: (Implications of Oversized IPv6 Header Chains) to Proposed Standard

Fred, > Hi, I would like to make a small amendment to what I said in my > previous message as follows: > > 4) Section 5, change the final paragraph to: > > "As a result of the above mentioned requirements, a packet's header > chain length MUST fit within the Path MTU associated with its >

Re: Last Call: (On Consensus and Humming in the IETF) to Informational RFC

On Oct 8, 2013, at 11:39 AM, Ted Hardie wrote: > To be clear here, I did not think Pete's document was going for BCP. Indeed, but you are speaking of it as if it were, which was my point.

Re: IETF 88 Preliminary Agenda

Hi Ralf, On 10/07/2013 09:23 PM, Ralf Skyper Kaiser wrote: > Hi, > > Is it still possible to submit a talk? I would like to speak at the IETF/88 > and a 15-30 minutes slot would be sufficient. > > The topic of my talk is "Transport Layer Security in a Post-Prism Era". We don't really schedule

Re: Last Call: (On Consensus and Humming in the IETF) to Informational RFC

On 10/7/13 10:48 AM, The IESG wrote: > > The IESG has received a request from an individual submitter to consider > the following document: > - 'On Consensus and Humming in the IETF' >as Informational RFC I would like to perform a thorough review and provide more detailed feedback, but time i

Re: Last Call: (On Consensus and Humming in the IETF) to Informational RFC

On 10/8/2013 8:36 AM, Ted Hardie wrote: And what are the RFC numbers for the comments? If none, as I suspect, then the comments aren't the same status as the documents--that's fine for RFC 791 and 2460, but it is not clear that Pete's document falls into the same class. I would argue it does no

Re: Last Call: (On Consensus and Humming in the IETF) to Informational RFC

On Mon, Oct 7, 2013 at 1:35 PM, Ted Lemon wrote: > On Oct 7, 2013, at 3:34 PM, Brian E Carpenter > wrote: > > So I'd like to dispute Ted's point that by publishing a version of > > resnick-on-consensus as an RFC, we will engrave its contents in stone. > > If that's the case, we have an even deep

Re: Last Call: (On Consensus and Humming in the IETF) to Informational RFC

On Mon, Oct 7, 2013 at 12:34 PM, Brian E Carpenter < brian.e.carpen...@gmail.com> wrote: > On 08/10/2013 08:03, Ted Hardie wrote: > ... > > > were. On the second point, the truth is that informational RFCs are > [not] > > treated as actual requests for comments much any more, but are taken as > >

Re: IETF 88 Preliminary Agenda

Hi, Is it still possible to submit a talk? I would like to speak at the IETF/88 and a 15-30 minutes slot would be sufficient. The topic of my talk is "Transport Layer Security in a Post-Prism Era". Best Regards, Ralf Kaiser On Fri, Oct 4, 2013 at 11:53 PM, IETF Agenda wrote: > The IETF 88

Re: Montevideo statement

On 8October2013Tuesday, at 6:19, Phillip Hallam-Baker wrote: > > > > On Tue, Oct 8, 2013 at 8:53 AM, manning bill wrote: > > > > > > I think the US executive branch would be better rid of the control before > > the vandals work out how to use it for mischief. But better would be to > > ensu

Re: year for highest number of IETF participants

All; Prior to this Vancouver meeting in which Remote Participants will have an opportunity to register, registrations did -not- include Remote Participants. Attendees are those who showed up. Registrations are typically a much higher number. Not all those who register attend. Ray IAD On Oct

Re: year for highest number of IETF participants

The registration number may include remote participants while attendee number shows how many actually went on-site. Cheers, Aaron On 08/10/13 14:06, Richard Barnes wrote: Indeed, the number Joe was counting was the number who filled out a registration form. Counting those who actually paid t

Re: Last calling draft-resnick-on-consensus

I think that this I-D is flawed and should not become an RFC. It has several implicit presumptions that I think wrong. 1) It does not state its target audience until, perhaps, the reference in the Conclusions, to WG Chairs. It makes no mention of the consensus calls made by ADs, such as at IETF

Re: [Diversity] year for highest number of IETF participants

Hi Adrian, True, that also puzzled me a bit since the numbers do not match, registration and attendee - the registration number is in general higher than that of attendees. Cheers, Aaron On 08/10/13 13:51, Adrian Farrel wrote: Curiously these numbers do not match those at https://www.ietf.o

Re: Montevideo statement

On Tue, Oct 8, 2013 at 9:19 AM, Michael Richardson wrote: > > Phillip Hallam-Baker wrote: > > I think the US executive branch would be better rid of the control > > before the > > vandals work out how to use it for mischief. But better would be to > > ensure that > > no such l

Re: Montevideo statement

On Tue, Oct 8, 2013 at 8:53 AM, manning bill wrote: > > > > > > I think the US executive branch would be better rid of the control > before the vandals work out how to use it for mischief. But better would be > to ensure that no such leverage exists. There is no reason for the apex of > the DNS t

Re: Montevideo statement

Phillip Hallam-Baker wrote: > I think the US executive branch would be better rid of the control > before the > vandals work out how to use it for mischief. But better would be to > ensure that > no such leverage exists. There is no reason for the apex of the DNS to > be a

Re: year for highest number of IETF participants

Indeed, the number Joe was counting was the number who filled out a registration form. Counting those who actually paid their registration yields closer numbers. rbarnes$ for n in $(jot 15 73); do att=$(curl -s "https://www.ietf.org/registration/ietf${n}/attendance.py"; | grep -o ">Yes<" | wc -l)

Re: Montevideo statement

> > > I think the US executive branch would be better rid of the control before the > vandals work out how to use it for mischief. But better would be to ensure > that no such leverage exists. There is no reason for the apex of the DNS to > be a single root, it could be signed by a quorum of s

RE: year for highest number of IETF participants

Curiously these numbers do not match those at https://www.ietf.org/meeting/past.html Registration, we may conclude, does not equate to attendance. Adrian > -Original Message- > From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Joe > Abley > Sent: 08 October 2013 02:

Re: Montevideo statement

Phillip, On Tue, 2013-10-08 at 08:24 -0400, Phillip Hallam-Baker wrote: > If nothing is done then sooner or later there will be some idiot on > his hind legs in the Senate talking for 21 hours demanding that Cuba > or Palestine be dropped out of the DNS root or be denied IPv6 > allocations or some

Re: Montevideo statement

On Mon, Oct 7, 2013 at 7:05 PM, Jari Arkko wrote: > > > > This wording is surprising. It looks like it is the revelations that > > undermined confidence, and not the NSA actions. I would prefer > > something like, to avoid shooting the messenger: > > Of course :-) We meant that the loss of privac

Call for participation: Transport Services

Dear all, Sorry if you receive multiple copies of this! I sent it to all the lists with potentially interested folks... (this should be okay to do according to RFC5434, which says "various mailing lists"). A community of interest is being formed to gauge whether there is sufficient interest t

Re: Review of: draft-resnick-on-consensus-05

On Oct 7, 2013, at 11:56 PM, Martin Rex wrote: > Dearlove, Christopher (UK) wrote: >> dcroc...@bbiw.net >>> >>> From what you've written, your basic point seems to be that 51% isn't >>> enough; it's worth making that explicit. >> >> To add to the confusion, and to emphasise the point about ma

RE: Review of: draft-resnick-on-consensus-05

I wasn't making any suggestion about what we should be doing. My sole point was that as the language differs, we should be aware of that and word accordingly, i.e. not use phrases like "simple majority" to mean 51%, as it may not. -- Christopher Dearlove Senior Principal Engineer, Communication

Re: IPR disclosure for draft-kaplan-insipid-session-id

Hi, these disclosures were already made long ago against the WG's drafts. So, the WG has been very much aware of them for a long time and they have been discussed several times in the face-to-face meetings. Some of the comments during the chartering of INSIPID actually related to the knowledge of

Re: Piling on [Gen-art] Gen-ART review of draft-kaplan-insipid-session-id-03.txt

Hi Hadriel, the additional IPR disclosure is already out. Could you please revise the draft per my email below so that I can IETF LC it again? Thanks, Gonzalo On 20/09/2013 10:52 AM, Gonzalo Camarillo wrote: > Hi Hadriel, > > to summarize the status of this IETF LC, we are still expecting (at

RE: Last Call: (Revision of the tcpControlBits IPFIX Information Element) to Informational RFC

Hi all, A small editorial nit: RFC 793, RFC3168 and RFC3540 (which is experimental, BTW) all classify bits 3,4,5 in octets 13 and 14 of the TCP header as "Reserved". In the information element according to this draft, the corresponding bits are named "Future Use", with the reference "per the d