RE: Last Call: draft-trammell-ipfix-tcpcontrolbits-revision-04.txt (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 definition of the bits in the TCP header [RFC0793]. Strictly speaking, this terminology differs slightly to RFC 793 and the very well-known figure depicting the TCP header. For whatever it is worth, I suggest to better explain the different wording. For instance, instead of ... Each of the three future use bits (0x800, 0x400, and 0x200) should be exported as observed in the TCP headers of the packets of this Flow, as they may be used subsequent to a future update of [RFC0793]. ... an alternative wording better reflecting the exact header definition in RFC 793 could be: Each of the three future use bits (0x800, 0x400, and 0x200) should be exported as observed in the TCP headers of the packets of this Flow, which are reserved for future use in [RFC0793]. Best regards Michael -Original Message- From: ietf-announce-boun...@ietf.org [mailto:ietf-announce- boun...@ietf.org] On Behalf Of The IESG Sent: Tuesday, October 08, 2013 12:13 AM To: IETF-Announce Subject: Last Call: draft-trammell-ipfix-tcpcontrolbits-revision- 04.txt (Revision of the tcpControlBits IPFIX Information Element) to Informational RFC The IESG has received a request from an individual submitter to consider the following document: - 'Revision of the tcpControlBits IPFIX Information Element' draft-trammell-ipfix-tcpcontrolbits-revision-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-11-04. 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 revises the tcpControlBits IPFIX Information Element as originally defined in [RFC5102] to reflect changes to the TCP Flags header field since [RFC0793]. The file can be obtained via http://datatracker.ietf.org/doc/draft-trammell-ipfix-tcpcontrolbits- revision/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-trammell-ipfix-tcpcontrolbits- revision/ballot/ No IPR declarations have been submitted directly on this I-D.
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 least) an additional IPR disclosure on this draft (as announced on the INSIPID list). When that happens, I will IETF LC it again. In the mean time, we need to address the comments related to the IANA registration the draft requests. I have discussed with the expert reviewer (Adam) and adding something along these lines would help: This registration is intended to be temporary. The authors expect that a standards-track definition of Session-ID will be published at a future date. Assuming such a document is published, it will replace this registration with a reference to itself, at which point this document will no longer be referenced by IANA. You have also received a review from the OPS directorate and I do not think that has been addressed so far. So, while we are waiting for the IPR disclosure, please go ahead and revise the draft. Thanks, Gonzalo On 13/09/2013 6:40 PM, Gonzalo Salgueiro (gsalguei) wrote: Here's what I do feel strongly about: whatever the plan of record needs to be clearly recorded in a place that people will find it. If draft-kaplan registers Session-ID, we need two changes to the existing documents: First, draft-kaplan needs to be crystal clear about the plan of record its section 10 (e.g., This registration is intended to be temporary, and should be removed when [draft-ietf-insipid-...] is published.) Secondly, draft-ietf-insipid must clearly state that its IANA registration *removes* the old reference and *completely* replaces it with a pointer to the standards-track document. Fully agree. The situation that I want to ensure cannot happen is an IANA-registered SIP header field that points to two documents simultaneously, especially if the ABNF is not absolutely identical between the two documents. The reality is that the backwards compatibility between the INSIPID Sess-ID mechanism and the kaplan draft is still undetermined and we cannot yet make a definitive statement on how it will look. Assuming the Session-ID header field is (re-)used, the ABNF can't be identical because the session identifier used for INSIPID MUST address requirements that the kaplan id does not meet; so construction of the id will be different. At this point the most that can be said is that one won't break the other (through non-intersection like using different header field names, etc.) or through direct backwards compatibility (same header field name but the INSIPID with expanded ABNF that plays nice with the kaplan id). Cheers, Gonzalo /a
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 well-known existing IPR in that particular area. The disclosures were just not updated in time to reflect their applicability to this new draft. Now they have been updated and we will re-IETF LC the draft so that everybody is on the same page. Cheers, Gonzalo On 21/09/2013 7:29 AM, SM wrote: Hello, At 01:52 20-09-2013, Gonzalo Camarillo wrote: to summarize the status of this IETF LC, we are still expecting (at least) an additional IPR disclosure on this draft (as announced on the INSIPID list). When that happens, I will IETF LC it again. There was a discussion about IPR on this mailing list but nobody mentioned RFC 6701 or RFC 6702. It is a mystery why the IETF cannot remember the (Informational) RFCs it published one year ago. There was a Last Call for draft-kaplan-insipid-session-id-03 ( http://www.ietf.org/mail-archive/web/ietf-announce/current/msg11753.html ). The announcement did not mention any IPR disclosure. Does the above qualify as a late disclosure? In the mean time, we need to address the comments related to the IANA registration the draft requests. I have discussed with the expert reviewer (Adam) and adding something along these lines would help: This registration is intended to be temporary. The authors expect that a standards-track definition of Session-ID will be published at a future date. Assuming such a document is published, it will replace this registration with a reference to itself, at which point this document will no longer be referenced by IANA. draft-ietf-insipid-session-id-02 is a WG document intended as a Proposed Standard. The INSIPID charter mentions a milestone for February 2013. It would be good if the IESG takes into consideration the overhead of getting this temporary assignment published as an IETF RFC. The reason given for publication was that 3GPP has tight deadlines. It is understandable that there can be delays in reaching a milestone. What is the INSIPID WG estimate for that future date? Regards, -sm
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, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearl...@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England Wales No: 1996687 -Original Message- From: Martin Rex [mailto:m...@sap.com] Sent: 07 October 2013 21:56 To: Dearlove, Christopher (UK) Cc: dcroc...@bbiw.net; Pete Resnick; IETF Discussion Subject: Re: Review of: draft-resnick-on-consensus-05 --! WARNING ! -- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. 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 making clear, British and American English differ here. If three proposals (not the most common case, I agree, but it can happen) have 45%, 35% and 20% of the votes, the first of these has a majority, sometimes emphasised as simple majority, in British English. (We do not - to our loss - use the word plurality. Just 51% is given the strong term absolute majority.) I haven't checked the context here, but saying not just a simple majority might suggest to a British English user that 51% is enough. Voting as is done in elections for political parties is often going to produce a political result, a personal preference of a few rather than an engineering solution that adequately addresses the concerns of the community at large. What we could do in the IETF, is not just trying to pick the lesser evil, but rather use the _engineering_ skills to modify and/or merge proposals to increase the number of folks that support the result and reduce the amount of folks that object the result. With your example of three competing proposals: A, B and C, and by couting votes the WG chair determine support of 45%, 35% and 20% respectively, does this mean that A has signficant support? Not at all. It could be that the folks who voted for B and C did so because they are both strongly opposed to A. A WG chair who wants to be neutral on the decision should probably not just call: which of the three proposals do you prefer: A, B or C and perform political inferences on the result, but rather _ask_ the engineers direclty: if we were to select A, would you support it, are neutral, are opposed if you're either neutral or opposed to A, what change(s) to A would make you supportive for A? if we were to select B, would you support it, are neutral, are opposed if you're either neutral or opposed to A, what change(s) to A would make you supportive for B? if we were to select C, would you support it, are neutral, are opposed if you're either neutral or opposed to A, what change(s) to A would make you supportive for C? I've seen a few WG consensus calls which appeared somewhat skewed/biased to me towards exclusing specific outcomes. I do _not_ know whether this was causes by malicous intent or just accidental / not sufficiently well thought out. I'm OK with a leadership decision, but leadership decisions should not be exerted early in the process by preventing certain questions to get asked at all. How well the process works can be seen by how objections are resolved. Are objections handled by spin doctors, or by engineers that are open to improvements of their work. -Martin This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person.
Re: Review of: draft-resnick-on-consensus-05
On Oct 7, 2013, at 11:56 PM, Martin Rex m...@sap.com 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 making clear, British and American English differ here. If three proposals (not the most common case, I agree, but it can happen) have 45%, 35% and 20% of the votes, the first of these has a majority, sometimes emphasised as simple majority, in British English. (We do not - to our loss - use the word plurality. Just 51% is given the strong term absolute majority.) I haven't checked the context here, but saying not just a simple majority might suggest to a British English user that 51% is enough. Voting as is done in elections for political parties is often going to produce a political result, a personal preference of a few rather than an engineering solution that adequately addresses the concerns of the community at large. What we could do in the IETF, is not just trying to pick the lesser evil, but rather use the _engineering_ skills to modify and/or merge proposals to increase the number of folks that support the result and reduce the amount of folks that object the result. With your example of three competing proposals: A, B and C, and by couting votes the WG chair determine support of 45%, 35% and 20% respectively, does this mean that A has signficant support? Not at all. It could be that the folks who voted for B and C did so because they are both strongly opposed to A. A WG chair who wants to be neutral on the decision should probably not just call: which of the three proposals do you prefer: A, B or C and perform political inferences on the result, but rather _ask_ the engineers direclty: if we were to select A, would you support it, are neutral, are opposed if you're either neutral or opposed to A, what change(s) to A would make you supportive for A? if we were to select B, would you support it, are neutral, are opposed if you're either neutral or opposed to A, what change(s) to A would make you supportive for B? if we were to select C, would you support it, are neutral, are opposed if you're either neutral or opposed to A, what change(s) to A would make you supportive for C? I think in this case the WG chair should do something different. A better question would be: Which is worse? To decide on *any* of these 3 proposals, or to keep debating this for another few months? At that point you might get something like - Just choose any of them - 90% - No, we need to choose the right one - 10% But percentages don't really matter. You get the people who are in the 10% (1-3 in most working groups) and get them to the mic or mailing list and ask them what is so terrible about proposal A (or B or C, whichever one or two they really object to) that it's better to delay the process by some extra months. That gets the objections that are really worth discussing. If you can get those objections ironed out so that there's consensus (rough or not) for the assertion that Any of them is better than not proceeding, the selection can proceed by any method that seems fair: majority, coin toss, 3-way Rechambeau ([1]), shortest document. Yoav [1] http://tools.ietf.org/html/draft-harkins-rochambeau-02
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 to host a BOF at the London IETF, on the topic of Transport Services. The intention is to create a WG that would define the set of services that transport protocols offer to applications, such that applications could at some point in the future request a service, not a protocol. This could foster innovation (protocols could be tried out, with a fall-back, without requiring the application programmer to include such functionality); it could also give more freedom to whatever resides below the API to automatically make the best out of what it currently has available. If you're interested in this problem space, please visit the related webpage that I have set up: https://sites.google.com/site/transportprotocolservices/ There you'll find an initial stab at a charter and all information about the mailing list - please join us and participate in discussions! Thanks! Cheers, Michael
Re: Montevideo statement
On Mon, Oct 7, 2013 at 7:05 PM, Jari Arkko jari.ar...@piuha.net 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 privacy causes concern, not the revelations. No, it is the revelations that cause concern. Nobody is in the least concerned about the fact that the British government and royal family has been replaced by a group of reptilian dopplegangers apart from David Ike who is the only person who knows about it. It is the actions that justify the concern but without the revelations there is no concern. The problem with the language used as I see it is that it is unfortunately rather close to the language used by the establishment types who run round telling us all not to worry our heads about what they are doing and we must certainly not ever question their motives or intentions. The reason I keep reminding people about the previous uses of the syncretic power of GCHQ and the NSA is that they prove that we do need to keep questioning their motives. For years people were dismissed as paranoid leftist hippies for suggesting that the CIA installed a dictatorship in Greece. And now it is known that exactly that happened. In the same way, the idea that US government might attempt to use control over ICANN or IANA for leverage has to be taken seriously. The question is not whether Steve Crocker is comfortable with the situation, it is whether the governance infrastructure is strong enough to prevent abuse over centuries. The US government is currently shut down because some folk in Congress are trying to use the threat of a recession to deny access to health care to a fifth of the population. It is certainly not inconceivable that a future Congress would attempt to abuse control over ICANN is nonsense. It is a US registered corporation subject to US law. 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 equally stupid grandstanding demand designed to give him a platform on which to run for higher office. 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 signers (in addition to the key splitting which I am fully familiar with). And every government should be assigned a sovereign reserve of IPv6 addresses to prevent a scarcity being used as leverage. -- Website: http://hallambaker.com/
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 equally stupid grandstanding demand designed to give him a platform on which to run for higher office. This has already happened. Some US-Israeli lobby thing asked RIPE NCC in 2012 (IIRC) to stop economically support a by some nation states blockaded Iran via removing its routing registration information and IP assignments, etc. Not sure exactly how it went from there, but the request was essentially ignored AFAIK. The problem is not what happens when a lobbyist approaching on of these bodies directly is ignored, but when said lobbyists persuades a legal apparatus with standing, to make similarly ill-advised requests. Or to connect back to the Montevideo statement, how to manage a globally cohesive One Internet without exposing it to the threat of legal assault. I.e. how to put the Internet above the law of any one nation state, essentially. Today, a popular belief in Swedish IGF circles is the law applies equally to online as it does to offline -- but this doesn't really compile well for the Internet IMHO where we have 250 something different laws, as it is absolutely fragmenting the Internet judicially speaking to each nation state having some sort of power over its national Internet segment... IMHO, the Internet is a global communications fabric, transcending and superseding individual nation states. Forcefully and offensively removing someones access to it is a crime by any human standard. /M signature.asc Description: This is a digitally signed message part
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:38
To: Ted Lemon
Cc: divers...@ietf.org; IETF
Subject: Re: year for highest number of IETF participants
[krill:~]% for n in $(jot 15 73); do
curl -s https://www.ietf.org/registration/ietf${n}/attendance.py; | \
awk -v n=${n} '/ registrations:/ { sub(/ registrations:.*$/, );
sub(/^.*\/, );
print n, $0; }'
done
73
74 1332
75 1230
76 1249
77 1350
78 1304
79 1337
80 1317
81 1244
82 1051
83 1529
84 1356
85 1351
86 1223
87 1585
[krill:~]%
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 signers (in addition to the key splitting which I am fully familiar with). And every government should be assigned a sovereign reserve of IPv6 addresses to prevent a scarcity being used as leverage. -- Website: http://hallambaker.com/ Quorum signing with split keys was already built and tested in a root server operator testbed (the OTDR testbed) from 1998-2005. It was considered more fragile than the current system. /bill
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);
echo $n $att;
done
73 969
74 1170
75 1102
76 1129
77 1242
78 1159
79 1144
80 1231
81 1127
82 948
83 1395
84 1199
85 1157
86 1115
87 1435
On Tue, Oct 8, 2013 at 8:51 AM, Adrian Farrel adr...@olddog.co.uk wrote:
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:38
To: Ted Lemon
Cc: divers...@ietf.org; IETF
Subject: Re: year for highest number of IETF participants
[krill:~]% for n in $(jot 15 73); do
curl -s https://www.ietf.org/registration/ietf${n}/attendance.py; | \
awk -v n=${n} '/ registrations:/ { sub(/ registrations:.*$/, );
sub(/^.*\/, );
print n, $0; }'
done
73
74 1332
75 1230
76 1249
77 1350
78 1304
79 1337
80 1317
81 1244
82 1051
83 1529
84 1356
85 1351
86 1223
87 1585
[krill:~]%
Re: Montevideo statement
Phillip Hallam-Baker hal...@gmail.com 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 single root, it could be signed by a quorum of signers (in addition to the key k-of-n signing for the DNSSEC root was talked about by many, including Tatu Ylonen back in 1996... I have an alternate proposal: every country's ccTLD should sign the root, and/or the other TLDs. That actually hands control of the DNS root back to the legislatures in each country. True: some countries might have perverted notions of what belongs in the root, and we might get different views of the Internet. But, this happens already using a variety of wrong mechanisms that cause harm to the Internet. Better they do this using good crypto, than that they do this by trying to subvert the (US-controlled) crypto. -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works pgpPct2J5Wl83.pgp Description: PGP signature
Re: Montevideo statement
On Tue, Oct 8, 2013 at 8:53 AM, manning bill bmann...@isi.edu 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 single root, it could be signed by a quorum of signers (in addition to the key splitting which I am fully familiar with). And every government should be assigned a sovereign reserve of IPv6 addresses to prevent a scarcity being used as leverage. -- Website: http://hallambaker.com/ Quorum signing with split keys was already built and tested in a root server operator testbed (the OTDR testbed) from 1998-2005. It was considered more fragile than the current system. Considered more fragile by whom? By the members of the $250m/yr NSA mole program? Very few people in DNS land recognize the class of attack as being realistic. Even when they have prime ministers and members of the GRU visiting them to tell them how important the issue is to their country. We already have one example of lobbyists attempting this type of attack (see Martin's post). So it is far from unrealistic. At present ICANN's power over the DNS is entirely discretionary. Attempting to drop Palestine out of the routing tables would simply be the end of the ICANN root zone. ICANN could continue to manage .com but their influence over the rest of the system would end completely. But DNSSEC changes the balance of power. With the root signed and embedded infrastructure verifying DNSSEC trust chains, the cost of a switchover rises remarkably. And when I tried to mention the fact I tended to get nasty threats. The third question of power is 'how do we get rid of you'. The answer in the case of DNSSEC is that you can't. Fortunately the issue is quite easily fixed, just as the problem of using IPv6 or BGP allocations for leverage is fixable. Governments don't need to wait on ICANN or the IETF to develop a quorum signing model for the DNS apex, they could and should institute one themselves and tell their infrastructure providers to chain to the quorum roots rather than the monolithic apex root. -- Website: http://hallambaker.com/
Re: Montevideo statement
On Tue, Oct 8, 2013 at 9:19 AM, Michael Richardson mcr+i...@sandelman.cawrote: Phillip Hallam-Baker hal...@gmail.com 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 single root, it could be signed by a quorum of signers (in addition to the key k-of-n signing for the DNSSEC root was talked about by many, including Tatu Ylonen back in 1996... Most crypto hardware supports k-of-n keysplitting and most of the code out there makes use of it. And PKIX CAs use k-of-n keysplitting on a monolithic trust anchor rather than a composite trust anchor. So it is easy to see how a technical decision would go that way. But the idea of signing the root did not become a practical possibility until much later. I certainly gave the issue no thought when looking at signing .com. I certainly did not think that it was necessary to wait for the root to be signed to sign .com. I have an alternate proposal: every country's ccTLD should sign the root, and/or the other TLDs. That actually hands control of the DNS root back to the legislatures in each country. True: some countries might have perverted notions of what belongs in the root, and we might get different views of the Internet. But, this happens already using a variety of wrong mechanisms that cause harm to the Internet. I think that is a better approach actually. The CC TLDs are in effect members of a bridge CA and ICANN is merely the bridge administrator. There would have to be adequate controls to ensure that transfer of the root was practical of course. It is probably necessary for the CC TLDs to be able to sign more than one bridge. After all, Europe has just spent many billions replicating GPS. This would cost less. And anyone who is a relying party can choose to chain to a single trust anchor or use multiple anchors. So the quorate approach is still available for those who want it. If France, Cuba, the US and India all agree on the validity of the bridge root, then it is probably valid. Better they do this using good crypto, than that they do this by trying to subvert the (US-controlled) crypto. Its not all US controlled, you can use GOST... -- Website: http://hallambaker.com/
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.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:38
To: Ted Lemon
Cc: divers...@ietf.org; IETF
Subject: Re: year for highest number of IETF participants
[krill:~]% for n in $(jot 15 73); do
curl -s https://www.ietf.org/registration/ietf${n}/attendance.py; | \
awk -v n=${n} '/ registrations:/ { sub(/ registrations:.*$/, );
sub(/^.*\/, );
print n, $0; }'
done
73
74 1332
75 1230
76 1249
77 1350
78 1304
79 1337
80 1317
81 1244
82 1051
83 1529
84 1356
85 1351
86 1223
87 1585
[krill:~]%
___
diversity mailing list
divers...@ietf.org
https://www.ietf.org/mailman/listinfo/diversity
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 Last Call, which I think far more important. If a WG Chair calls it wrong, there are ADs and IESG who may put things right. When an AD does so, it may be time to abandon hope; and it is some, a few, of the consensus calls made by ADs at IETF Last Call that I have thought plain wrong, more so than those by WG Chairs. Are ADs assumed to be above and beyond the considerations in this I-D:-( 2) There is an extensive discussion on the show of hands and the hum. What technology allows you to conduct those on a mailing list? The fundamental rule of the IETF, for me, is that business is conducted on the mailing list. What happens at meetings some find useful, and it may be the quickest way to make progress on thorny issues, but the consensus call belongs on the mailing list. Unless this I-D is intending to subvert that. 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 this is interesting and varies widely). Even the busiest lists, v6ops and tcpm, for me, do not remotely approach 100 active participants. 4) Five people for and one hundred people against might still be rough consensus. Can you see the presumption in that? Read on and the following text makes it clear that five are 'right' and one hundred 'wrong', but you are presuming that for is the right answer. The right answer to a consensus call is a consensus,which can be against, as much as for, something that does not seem to be contemplated here. 5) Good WG chairs, and happily there are plenty of them, make their presumptions plain, as in asking for information about implementations at or around judging consensus. The views of someone who has independently produced rough code is then likely to outweigh those of a dozen people who have not, so three such expressing a view in one direction will prevail over several dozen who have not in the opposite direction. (This is all right as far as it goes, but I would like the views of users and operators to count for even more, since it is they who have the most to gain or lose; but sadly, their representation here is small and often not apparent). You quote Dave Clark's aphorism but then ignore half of it. 6) The document is strangely silent about what the vast mass of the IETF who are not WG Chairs might do to help reach a consensus, such as express an opinion, clearly, technically; else, perhaps, keep quiet. 7) As has been said before when documents like this are up for discussion, the IETF is an organisation of engineers and, for the most part, we do it rather well. Managing and leading loose and diverse groups of people is more psychology or sociology than technology, at which we are mostly amateurs. We then go beyond our capabilities and get it wrong. As here. Tom Petch - Original Message - From: Pete Resnick presn...@qti.qualcomm.com To: Mark Nottingham m...@mnot.net Cc: ietf@ietf.org Sent: Monday, October 07, 2013 6:45 AM Subject: Re: Last calling draft-resnick-on-consensus On 10/6/13 7:30 PM, Mark Nottingham wrote: This is a VERY useful document, and I look forward to compelling my WG participants to read it, with a pop quiz afterwards. I've been exceedingly satisfied to hear this sort of thing from you and the other folks who posted and talked to me about this. The only issue I see is its length; while dedicated IETFers won't have a problem reading such a lengthy document, the people who could benefit most - new, potential or casual participants - will give up early, I fear. Could we have someone take an editorial knife to it? Some of the descriptions of situations are quite long, and there's a fair amount of repetition in the document. Some of the paragraphs are quite long as well. I reckon 2-4 pages could be saved, making it appealing to a much wider audience. I would be really disappointed by this. Indeed, my primary target was not at all new or casual participants; it was really intended for the dedicated folks and the chairs. I hope this is the start of a serious discussion in the IETF, not a primer for how the IETF works at a high level. For newer folks, I'm fine with the idea that some of this can be either incorporated into the Tao or the newcomer's orientation, or separated into a smaller primer document. But I really believe the long form is needed for real discussions among folks in the community. Beyond that, the only suggestion I'd make is an alternate title -- Why We Hum. Or maybe The Things We Hum And Do Not Say (apologies
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 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);
echo $n $att;
done
73 969
74 1170
75 1102
76 1129
77 1242
78 1159
79 1144
80 1231
81 1127
82 948
83 1395
84 1199
85 1157
86 1115
87 1435
On Tue, Oct 8, 2013 at 8:51 AM, Adrian Farrel adr...@olddog.co.uk
wrote:
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:38
To: Ted Lemon
Cc: divers...@ietf.org; IETF
Subject: Re: year for highest number of IETF participants
[krill:~]% for n in $(jot 15 73); do
curl -s
https://www.ietf.org/registration/ietf${n}/attendance.py; | \
awk -v n=${n} '/ registrations:/ { sub(/ registrations:.*$/,
);
sub(/^.*\/, );
print n, $0; }'
done
73
74 1332
75 1230
76 1249
77 1350
78 1304
79 1337
80 1317
81 1244
82 1051
83 1529
84 1356
85 1351
86 1223
87 1585
[krill:~]%
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 8, 2013, at 9:06 AM, Richard Barnes r...@ipv.sx wrote:
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);
echo $n $att;
done
73 969
74 1170
75 1102
76 1129
77 1242
78 1159
79 1144
80 1231
81 1127
82 948
83 1395
84 1199
85 1157
86 1115
87 1435
On Tue, Oct 8, 2013 at 8:51 AM, Adrian Farrel adr...@olddog.co.uk wrote:
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:38
To: Ted Lemon
Cc: divers...@ietf.org; IETF
Subject: Re: year for highest number of IETF participants
[krill:~]% for n in $(jot 15 73); do
curl -s https://www.ietf.org/registration/ietf${n}/attendance.py; | \
awk -v n=${n} '/ registrations:/ { sub(/ registrations:.*$/, );
sub(/^.*\/, );
print n, $0; }'
done
73
74 1332
75 1230
76 1249
77 1350
78 1304
79 1337
80 1317
81 1244
82 1051
83 1529
84 1356
85 1351
86 1223
87 1585
[krill:~]%
Re: Montevideo statement
On 8October2013Tuesday, at 6:19, Phillip Hallam-Baker wrote: On Tue, Oct 8, 2013 at 8:53 AM, manning bill bmann...@isi.edu 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 single root, it could be signed by a quorum of signers (in addition to the key splitting which I am fully familiar with). And every government should be assigned a sovereign reserve of IPv6 addresses to prevent a scarcity being used as leverage. -- Website: http://hallambaker.com/ Quorum signing with split keys was already built and tested in a root server operator testbed (the OTDR testbed) from 1998-2005. It was considered more fragile than the current system. Considered more fragile by whom? By the members of the $250m/yr NSA mole program? Very few people in DNS land recognize the class of attack as being realistic. Even when they have prime ministers and members of the GRU visiting them to tell them how important the issue is to their country. We already have one example of lobbyists attempting this type of attack (see Martin's post). So it is far from unrealistic. At present ICANN's power over the DNS is entirely discretionary. Attempting to drop Palestine out of the routing tables would simply be the end of the ICANN root zone. ICANN could continue to manage .com but their influence over the rest of the system would end completely. But DNSSEC changes the balance of power. With the root signed and embedded infrastructure verifying DNSSEC trust chains, the cost of a switchover rises remarkably. And when I tried to mention the fact I tended to get nasty threats. The third question of power is 'how do we get rid of you'. The answer in the case of DNSSEC is that you can't. Fortunately the issue is quite easily fixed, just as the problem of using IPv6 or BGP allocations for leverage is fixable. Governments don't need to wait on ICANN or the IETF to develop a quorum signing model for the DNS apex, they could and should institute one themselves and tell their infrastructure providers to chain to the quorum roots rather than the monolithic apex root. Been there, done that, outgrew the teeshirt. Interestingly, the perceived value of a common, global namespace is _MUCH_ higher than the value of a controlled, boundary constrained namespace… At least by nearly every government to date. The fragile vectors could be classed in two buckets, Human Factors Timing. /bill
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 age...@ietf.org wrote: The IETF 88 Preliminary Agenda has been posted. The final agenda will be published on Friday, October 11th. https://datatracker.ietf.org/meeting/88/agenda.html https://datatracker.ietf.org/meeting/88/agenda.txt We are still having some difficulty integrating the new agenda tool into the datatracker and as a result some portions of the meeting agenda -- beverage and snack breaks, plenaries -- are not yet showing up on the html version. This will hopefully be resolved very soon. More information regarding IETF 88 in Vancouver, BC, Canada is located here: https://www.ietf.org/meeting/88/index.html IETF Secretariat
Re: Last Call: draft-resnick-on-consensus-05.txt (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 fixed; I've inserted the not that Ted certainly intended. Indeed, thanks for the correction. But I think he raises an important point. If the phrase Request For Comments no longer means what it says, we need another RFC, with a provisional title of Request For Comments Means What It Says. We still see comments on RFC 791 reasonably often, and I see comments on RFC 2460 practically every day. That's as it should be. 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 not. 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 deeper problem than misunderstandings of rough consensus. Archival may not mean engraved in stone, but it does impute status. If we want, as a community, to create an archival document on this topic, then we should take on the work. Pete's document is a good spark for the conversation that might kick off that work, but I personally don't think it is a good output document for that; if it is meant to be a spark, I don't see why moving it into an archival series is useful for us at this stage. regards, Ted otoh Ted's specific points on the draft are all valuable. Brian
Re: Last Call: draft-resnick-on-consensus-05.txt (On Consensus and Humming in the IETF) to Informational RFC
On Mon, Oct 7, 2013 at 1:35 PM, Ted Lemon ted.le...@nominum.com wrote: On Oct 7, 2013, at 3:34 PM, Brian E Carpenter brian.e.carpen...@gmail.com 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 deeper problem than misunderstandings of rough consensus. Right, I think what Ted is describing is a BCP, not an Informational RFC. To be clear here, I did not think Pete's document was going for BCP. I remain concerned that the publication of this document as an an AD-sponsored Informational RFC will impute status to it as a community conclusion, rather than the start of a conversation (or, rather, the continuation of one). Some of the comments of I've wanted something like this to hand to... are part of what cause me to believe that. And, to re-iterate, I do not think the document is ready, even if the IESG believes that a document of this type should be published; it needs a much clearer sense of audience as well as attention to the other points that have been raised. regards, Ted
Re: Last Call: draft-resnick-on-consensus-05.txt (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 not. Unfortunately the concern you are raising has often been applied to all sorts of IETF work. Many bits of IETF work are subject to on-going comments and often reach the practical status of de facto -- or, in the case of the errata mechanism, IETF de jure -- modifications to the published document. In fact, the line of argument you raise has frequently been lodged against the BCP construct. Yet we keep finding BCPs useful to create. 1. Does the IETF need a modern, thorough, community-approved statement of it's consensus model and the application of the model? That is, both theory and practice. So far, it looks as if the community certainly thinks we do, and strongly agree. In fact I think we suffer greatly by not having it. And as we've gone through multiple generations of participants, we've tended towards reliance on catch-phrases, without a shared understanding of their deeper meaning and specific practice. So folks invent their own meanings as best they can. Something like Pete's draft is needed to provide shared substance to what we mean when we talk about rough consensus. 2. Should the statement be an RFC or something more malleable (and therefore ephemeral)? Why would we not want something this essential to be available through our formal publishing and archiving mechanism? To the extent that later discussions prompt modifications, that's what the errata mechanism is for. And eventual revision to the RFC. Unless someone thinks that this core construct for the IETF is going to be subject to constant and fundamental modification??? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Last Call: draft-resnick-on-consensus-05.txt (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' draft-resnick-on-consensus-05.txt as Informational RFC I would like to perform a thorough review and provide more detailed feedback, but time is short right now. Here are a few questions in the meantime... The Abstract states: It is simply a collection of principles, hopefully around which the IETF can come to (at least rough) consensus. Does that mean you aim to make *this* I-D an IETF stream RFC that will itself have consensus, or do you instead aim to use this document to generate discussion that might result in consensus in the future (e.g., as a BCP)? If the latter, publishing in the Independent Stream seems sensible. If the former, then I think we need to have more discussion (along the lines of other Last Call feedback I've glanced at). The Introduction states: Our ideal is full consensus, but we don't require it: Full consensus would allow a single intransigent person who simply keeps saying No! to stop the process cold. By full consensus do you mean unanimity? And do you think that unanimity or full consensus is our ideal, although an ideal that's not always reachable in practice? Or is our ideal actually rough consensus (i.e., something like general agreement without unanimity)? If unanimity or full consensus is our ideal then we might expend more energy to win over instransigent persons or those who are in the rough than we would if rough consensus were our ideal. So I think it's important to be clear on what we're aiming for. Peter -- Peter Saint-Andre https://stpeter.im/
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 talks like that. However, I'd encourage you to write up your ideas in an internet-draft and post that before Oct 21st (which is the deadline for posting drafts before the meeting). And depending on the content, that could be usefully discussed on either the perp...@ietf.org or t...@ietf.org lists. Cheers, Stephen. PS: Any questions about details or similar, feel free to ask me off-list. Best Regards, Ralf Kaiser On Fri, Oct 4, 2013 at 11:53 PM, IETF Agenda age...@ietf.org wrote: The IETF 88 Preliminary Agenda has been posted. The final agenda will be published on Friday, October 11th. https://datatracker.ietf.org/meeting/88/agenda.html https://datatracker.ietf.org/meeting/88/agenda.txt We are still having some difficulty integrating the new agenda tool into the datatracker and as a result some portions of the meeting agenda -- beverage and snack breaks, plenaries -- are not yet showing up on the html version. This will hopefully be resolved very soon. More information regarding IETF 88 in Vancouver, BC, Canada is located here: https://www.ietf.org/meeting/88/index.html IETF Secretariat
Re: Last Call: draft-resnick-on-consensus-05.txt (On Consensus and Humming in the IETF) to Informational RFC
On Oct 8, 2013, at 11:39 AM, Ted Hardie ted.i...@gmail.com 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: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (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 destination. Hosts MAY discover the Path MTU, using procedures such as those defined in [RFC1981] and [RFC4821]. However, if a host does not discover the Path MTU, it MUST assume the IPv6 minumum MTU of 1280 bytes [RFC2460]. The host MUST then limit each packet's header chain length to the Path MTU minus 256 bytes in case additional encapsulation headers are inserted by tunnels on the path. I would claim that additional encapsulation headers are already considered in the 1280 minimum MTU. as in: 1500 - 1280. cheers, Ole signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Last Call: draft-resnick-on-consensus-05.txt (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 d...@dcrocker.net 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 it is not clear that Pete's document falls into the same class. I would argue it does not. Unfortunately the concern you are raising has often been applied to all sorts of IETF work. Many bits of IETF work are subject to on-going comments and often reach the practical status of de facto -- or, in the case of the errata mechanism, IETF de jure -- modifications to the published document. In fact, the line of argument you raise has frequently been lodged against the BCP construct. Yet we keep finding BCPs useful to create. 1. Does the IETF need a modern, thorough, community-approved statement of it's consensus model and the application of the model? That is, both theory and practice. So far, it looks as if the community certainly thinks we do, and strongly agree. In fact I think we suffer greatly by not having it. And as we've gone through multiple generations of participants, we've tended towards reliance on catch-phrases, without a shared understanding of their deeper meaning and specific practice. So folks invent their own meanings as best they can. Something like Pete's draft is needed to provide shared substance to what we mean when we talk about rough consensus. If the community believes that we need a community-approved statement of its decision-making model and how it is applied, then we should develop one in a community process. It may at that point be something that becomes a BCP. As an input draft to that discussion or community process, I think Pete's draft is very useful--it has sparked multiple rounds of discussion. But I don't think it is clear that this is its intended function (that unclear on the audience bit) and I think it might be read to be a proposed output document from that process. I don't think it is anywhere near ready to be considered as an output document, for reasons I already laid out. 2. Should the statement be an RFC or something more malleable (and therefore ephemeral)? Why would we not want something this essential to be available through our formal publishing and archiving mechanism? To the extent that later discussions prompt modifications, that's what the errata mechanism is for. And eventual revision to the RFC. Unless someone thinks that this core construct for the IETF is going to be subject to constant and fundamental modification??? Again, I think this is the question of the document's audience and function. If the aim is to use it to spark debate, than ephemeral is better than fixed. If it is meant to be a community statement of our process, in theory and practice, it should be fixed--but this document is not that community statement in its current form. regards, Ted d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
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 xx99 Series Greetings, The RFC Editor is proposing to retire the practice of publishing RFCs xx99, the Request for Comments Summary for RFC Numbers xx00-xx99. In December 1991, RFC 1099 was the first Request for Comments Summary RFC published. It provides a list of document titles, authors, date of publication, and abstracts for each of the RFCs published in the range 1000 - 1099. Since that time, through the time that RFC 3299 was published, a new summary RFC was published every 100 RFCs, and RFC numbers ending with 99 were reserved for these summary documents. RFC 3399 was never published (for various reasons), though RFCs 3499 and 3599 were. RFC 3599 was the last of these summary documents to be published in December 2003. These snapshots are no longer needed because up-to-date data is available online. RFC abstracts are available using the RFC search engine (http://www.rfc-editor.org/search/rfc_search.php) and they are included in rfc-index.xml. RFCs xx99 summaries were never requested by the Internet Community and are not currently filling a need; therefore, the RFC Editor is retiring the publication of the RFC summary documents. RFC numbers typically reserved for these documents (i.e., numbers ending with 99) may be assigned to future RFCs. If there are any concerns about this course of action, please comment by October 18, 2013, on the rfc-inter...@rfc-editor.org mailing list. Thank you, Heather Flanagan, RSE
RE: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (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: draft-ietf-6man-oversized-header-chain-08.txt (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 destination. Hosts MAY discover the Path MTU, using procedures such as those defined in [RFC1981] and [RFC4821]. However, if a host does not discover the Path MTU, it MUST assume the IPv6 minumum MTU of 1280 bytes [RFC2460]. The host MUST then limit each packet's header chain length to the Path MTU minus 256 bytes in case additional encapsulation headers are inserted by tunnels on the path. 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 I am concerned about is tunnels in the path that fragment either because they cannot meet the IPv6 minimum MTU without doing so, or because they are trying to allow a larger-sized MTU when the path doesn't support it due to the addition of the encapsulating headers. Take the simplest case when the host assumes a path MTU of 1280. If there is a tunnel in the path that crosses another 1280 link, then the tunnel has to fragment, and the header chain might not all fit within the first fragment if the host does not allow headspace room. If the host limits the size of its header chain to 1280 - 512 = 1024 bytes, then the entire chain should fit within the first fragment even if there are multiple nested tunnel ingresses on the path and each one of them fragments. That said, I am wondering how this document relates to the discussions we had earlier and the resulting draft from Mark Andrews on what to do when the header chain spans multiple fragments? Are we trying to keep the header chain all within the first fragment or not? Thanks - Fred fred.l.temp...@boeing.com cheers, Ole
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 eric.g...@ericsson.com wrote: 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 xx99 Series Greetings, The RFC Editor is proposing to retire the practice of publishing RFCs xx99, the Request for Comments Summary for RFC Numbers xx00-xx99. In December 1991, RFC 1099 was the first Request for Comments Summary RFC published. It provides a list of document titles, authors, date of publication, and abstracts for each of the RFCs published in the range 1000 - 1099. Since that time, through the time that RFC 3299 was published, a new summary RFC was published every 100 RFCs, and RFC numbers ending with 99 were reserved for these summary documents. RFC 3399 was never published (for various reasons), though RFCs 3499 and 3599 were. RFC 3599 was the last of these summary documents to be published in December 2003. These snapshots are no longer needed because up-to-date data is available online. RFC abstracts are available using the RFC search engine (http://www.rfc-editor.org/search/rfc_search.php) and they are included in rfc-index.xml. RFCs xx99 summaries were never requested by the Internet Community and are not currently filling a need; therefore, the RFC Editor is retiring the publication of the RFC summary documents. RFC numbers typically reserved for these documents (i.e., numbers ending with 99) may be assigned to future RFCs. If there are any concerns about this course of action, please comment by October 18, 2013, on the rfc-inter...@rfc-editor.org mailing list. Thank you, Heather Flanagan, RSE
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 record? Please read this Nomcom call for nominations and consider nominating her or him. Or several folks! Deadline for nominations is October 18. Nominate soon to give your nominee(s) plenty time to fill in the questionnaire. If you're nominated, even if you support the present incumbent, being reviewed by Nomcom is great IETF experience. The questionnaire offers a chance to think about IETF and about your area. Whether or not your candidacy progresses this time, you'll have gained some valuable insights, and you'll have contributed greatly. This process only works because many IETFers take part; please join in. Lots more, including which positions are open, how to make a nomination (including nomination of yourself), and how to send us your feedback on the desired expertise, follows. IETFers, let's hear from you! Make nominations, accept nominations! If you have any questions about the process, feel free to get in touch with me. Best regards, Allison for the Nomcom Allison Mankin Nomcom Chair 2013-14 - The Info You Need for Nominating - The 2013-14 Nominating Committee (Nomcom) is seeking nominations from now until October 18, 2013. The open positions being considered by this year's Nomcom can be found later in this section, and also on this year's Nomcom website: https://datatracker.ietf.org/nomcom/2013/ Information about the desired expertise for positions is here: https://datatracker.ietf.org/nomcom/2013/expertise Nominations may be made by selecting the Nominate link at the top of the Nomcom 2013 home page, or by visiting the following URL: https://datatracker.ietf.org/nomcom/2013/nominate/ Note that nominations made using the web tool require an ietf.org datatracker account. You can create a datatracker ietf.org account if you don't have one already by visiting the following URL: https://datatracker.ietf.org/accounts/create/ Nominations may also be made by email to nomcom13 at ietf.org. If you nominate by email, please include the word Nominate in the Subject and indicate in the email who is being nominated, their email address (to confirm acceptance of the nomination), and the position for which you are making the nomination. If you use email, please use a separate email for each person you nominate, and for each position (if you are nominating one person for multiple positions). Self-nomination is welcome! No need to be shy. Nomcom 2013-14 will follow the policy for Open Disclosure of Willing Nominees described in RFC 5680. As stated in RFC 5680: The list of nominees willing to be considered for positions under review in the current Nomcom cycle is not confidential. Willing nominees for each position will be listed in a publicly accessible way - anyone with a datatracker account may access the lists. In all other ways, the confidentiality requirements of RFC 3777/BCP10 remain in effect. All feedback and all Nomcom deliberations will remain confidential and will not be disclosed. In order to ensure time to collect sufficient community feedback about each of the willing nominees, nominations must be received by the Nomcom on or before October 18, 2013. Please submit your nominations as early as possible for the sake of your nominees, as we've set the questionnaire submission deadline for October 25, 2013. The list of people and posts whose terms end with the March 2014 IETF meeting, and thus the positions for which we are accepting nominations: IAOC Chris Griffiths IAB Bernard Aboba Marc Blanchet Ross Callon Eliot Lear Hannes Tschofenig IESG Barry Leiba (Applications) Brian Haberman (Internet) Benoit Claise (Operations and Management) Gonzalo Camarillo (RAI) Stewart Bryant (Routing) Sean Turner (Security) Martin Stiemerling (Transport) Please be resourceful in identifying possible candidates for these positions, as developing our talent is a very crucial requirement for the IETF. Also, please give serious consideration to accepting nominations you receive. The summaries of the desired expertise for the positions, developed by the respective bodies, are found at: https://datatracker.ietf.org/nomcom/2013/expertise/ In addition to nominations, the Nomcom seeks community input on the positions themselves. We need and welcome the community's views and input on the jobs within each organization. If you have ideas on the positions' responsibilities (more, less, different), please let us know. You can send us email about this to nomcom13 at ietf.org, and we will use this feedback actively. Thank you for your help in nominating a great pool of strong and interesting nominees!
Re: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (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 I am concerned about is tunnels in the path that fragment either because they cannot meet the IPv6 minimum MTU without doing so, or because they are trying to allow a larger-sized MTU when the path doesn't support it due to the addition of the encapsulating headers. Take the simplest case when the host assumes a path MTU of 1280. If there is a tunnel in the path that crosses another 1280 link, then the tunnel has to fragment, Well, at least in theory, the tunnel could do Path-MTU... In which case, if the underlying MTU is of, say, 1500 bytes, then you can probably go through several layers of encapsulation, without problem. Besides, while one would probably would nto phrase it like this, truth is that even 512 f headers would be pretty much non-sensical: Headers are overhead. So at the point in which you have 50$ of overhead in every single packet, it starts looking that the inforation is probably being conveyed in thr wrong place. That is, in the real world, you would not even get to 1K headers even ater several layers of encapsulation. That said, I am wondering how this document relates to the discussions we had earlier and the resulting draft from Mark Andrews on what to do when the header chain spans multiple fragments? Are we trying to keep the header chain all within the first fragment or not? Yes. Thanks, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Re: The RFC xx99 Series
On 2013-10-08, at 11:38, Donald Eastlake d3e...@gmail.com 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: [Sdn] FW: Last Call: draft-sin-sdnrg-sdn-approach-04.txt (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 approach should be global, network-wide? Here are a couple of examples that SDN is not global based: 1) The wireless' PCRF (Policy and Charging rules function) and PCEF (Policy Charging Enforcement Function) are good examples of SDN. However, PCRF and PCEF only control the access segments, not global network. 2) In data center, centralized controller(s), with the information passed from VM management system, can define (virtual) networks to interconnect Virtual machines. This network is local to Data Center, not necessarily global based. - We all understand the challenges of Full Automation. However, the SDN and Full automation are two separate angles to Carrier networks. I find the Section 4.1 Implications of full automation actually de-rails the focus of the draft on SDN. My two cents. Linda -Original Message- From: sdn-boun...@irtf.org [mailto:sdn-boun...@irtf.org] On Behalf Of Adrian Farrel Sent: Monday, October 07, 2013 1:49 PM To: s...@irtf.org Subject: [Sdn] FW: Last Call: draft-sin-sdnrg-sdn-approach-04.txt (Software-Defined Networking: A Perspective From Within A Service Provider) to Informational RFC Heads up! This document which was discussed from time-to-time in the SDNRG is going for IETF last call as an AD-sponsored independent submission. Review comments are welcome as always. Please follow the instructions in the email below. Thanks, Adrian -Original Message- From: ietf-announce-boun...@ietf.org [mailto:ietf-announce- boun...@ietf.org] On Behalf Of The IESG Sent: 07 October 2013 19:40 To: IETF-Announce Subject: Last Call: draft-sin-sdnrg-sdn-approach-04.txt (Software- Defined Networking: A Perspective From Within A Service Provider) to Informational RFC The IESG has received a request from an individual submitter to consider the following document: - 'Software-Defined Networking: A Perspective From Within A Service Provider' draft-sin-sdnrg-sdn-approach-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-11-04. 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 Software-Defined Networking (SDN) has been one of the major buzz words of the networking industry for the past couple of years. And yet, no clear definition of what SDN actually covers has been broadly admitted so far. This document aims at contributing to the clarification of the SDN landscape by providing a perspective on requirements, issues and other considerations about SDN, as seen from within a service provider environment. It is not meant to endlessly discuss what SDN truly means, but rather to suggest a functional taxonomy of the techniques that can be used under a SDN umbrella and to elaborate on the various pending issues the combined activation of such techniques inevitably raises. As such, a definition of SDN is only mentioned for the sake of clarification. The file can be obtained via http://datatracker.ietf.org/doc/draft-sin-sdnrg-sdn-approach/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-sin-sdnrg-sdn-approach/ballot/ No IPR declarations have been submitted directly on this I-D. ___ sdn mailing list s...@irtf.org https://www.irtf.org/mailman/listinfo/sdn
Re: Last Call: draft-ietf-dhc-option-guidelines-14.txt (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 view. IT departments are used to making sure that changes of IP addresses on servers are well coordinated with changes to the DNS - they are good at doing that and that and have good tools for it. Conversely, they are not used to coordinating server changes with DHCP changes and do not have good tools for that. 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 down during the move). Applications can not tell the OS to redo DHCP when they fail an application level connection. For nearly every case in the real world, the power and RTT and reliability issues are simply not relevant - regardless of which way you do it, the application is unlikely to work if DNS is down, the extra RTT make no speed difference the user can percieve and the power difference over a day of use of the application is so small it is not measurable. FQDN allow usage of things like DNS SRV for load balancing, happy eye balls for v6 transition, and make it easier to get things to geographically close servers. I don't think it should come a a shock to anyone that the level of indirection that FQDNs provides turns out to be a really useful tool. Lets use that indirection tool where appropriate. Related to this, the advice in section 12 seems a bit off to me. I understand the issues - but keep in mind that many modern applications (browsers and SIP phones for example) do the DNS inside the application instead of using the OS resolvers. Part of the reason for this is asynchronous resolution but part of it is also control of which interface is used for DNS and if multiple interfaces are used, being able to keep the applications traffic on the the appropriate interface for the DNS server that returned the address. So while I agree that Existing nodes cannot be assumed to systematically segregate configuration information on the basis of its source; Equally true is you can't assume the converse of that. So I think the statement that As a consequence, DNS resolution done by the DHCP server is more likely to behave predictably than DNS resolution done on a multi-interface or multi- homed client. Is just plain wrong. I think it would be more accurate to say in these cases the results are not always predictable. The issue is the DHCP server may get an DNS answer that contains and server that can not even be reached by the DHCP client. As a general rule of thumb, using FQDN in the configuration of a DHCP server is a really bad idea because IT admins assume that if they change the the DNS information, the clients will get the new information. But they don't. Cullen On Sep 19, 2013, at 3:54 PM, The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from the Dynamic Host Configuration WG (dhc) to consider the following document: - 'Guidelines for Creating New DHCPv6 Options' draft-ietf-dhc-option-guidelines-14.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 ietf@ietf.org mailing lists by 2013-10-03. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document provides guidance to prospective DHCPv6 Option developers to help them creating option formats that are easily adoptable by existing DHCPv6 software. This document updates RFC3315. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dhc-option-guidelines/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dhc-option-guidelines/ballot/ No IPR declarations have been submitted directly on this I-D.
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-ccmp-indication-06 Reviewer: Ben Campbell Review Date: 2013-10-08 IESG Telechat date: 2013-10-10 Summary: This draft is ready for publication as an informational RFC. This version addresses all the comments from my last call review of version 04. I do have a couple of new (or I missed the first time) editorial comments that might be worth addressing if there is a new version prior to approval. Major issues: None Minor issues: None Nits/editorial comments: -- General: idnits 2.12.18 reports some missing references--please check. -- Abstract and Intro Please expand UA and XCON on first mention (Both in Abstract and in Section 1).
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-label-balancing-02 Reviewer: Ben Campbell Review Date: 2013-10-08 IESG Telechat date: 2013-10-10 Summary: This version is ready for publication as an informational RFC. All of the comments from my previous last call review have been addressed either in this version or in email correspondence. Major issues: None Minor issues: None Nits/editorial comments: None
Re: Last Call: draft-ietf-dhc-option-guidelines-14.txt (Guidelines for Creating New DHCPv6 Options) to Best Current Practice
On Oct 8, 2013, at 4:30 PM, Cullen Jennings (fluffy) flu...@cisco.com 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 down during the move). Applications can not tell the OS to redo DHCP when they fail an application level connection. This use case is a good example of when to use an FQDN format for a DHCP option. However, it's not a great example of when to use a DHCP option—configuring SIP servers with DHCP is generally a bad idea, because if your device is connected to a new network, it will blindly take the SIP server IP address or FQDN information from the DHCP server and use it, and that SIP server might well perform an MitM attack or the like. So it's only in the very restricted use case of a Cisco IP phone permanently installed on a desktop and connected to a trusted network that (a) configuring SIP via DHCP makes sense, and (b) using the FQDN is a good idea. Of course it's possible that my limited understanding of how SIP works is preventing me from seeing why it's safe to configure SIP service using DHCP, but I'm assuming that that's not the case in this argument; please feel free to correct me. We've actually been having this same conversation on the iesg mailing list, and I asserted that SIP was something you ought not to configure with DHCP; your use case is the one case where it sort of makes sense. Can you think of similar use cases where it actually makes sense to configure these parameters via DHCP? Possibly the right solution is to update the document to talk about this sort of restricted use case as one where FQDNs actually do make sense. The document certainly doesn't say you _can't_ use FQDNs, but we see people wanting to use them a lot in cases where they really don't make sense, hence the advice. Historically I don't think we bothered to make this distinction when defining new DHCP options, but it seems like a useful distinction to make.
Re: Last Call: draft-resnick-on-consensus-05.txt (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' draft-resnick-on-consensus-05.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-11-04. Exceptionally, comments may be I found the review by Dave Crocker [1] interesting. Instead of reading the latest revision of the draft I wrote a draft [2]. I read what Pete Resnick said about consensus after that to compare notes. The intended status of draft-resnick-on-consensus-05 is Informational. What we have here is a document about consensus which will reflect the consensus of the IETF. Should the document reflect the consensus of the IETF or not? In Section 1: 'Our ideal is full consensus, but we don't require it: Full consensus would allow a single intransigent person who simply keeps saying No! to stop the process cold.' The above introduces the term full consensus. I took a quick look and I found at least one occurrence of the term in IETF discussions [3]. However, none of the IETF process documents use that term. If the chair of a working group determines that a technical issue brought forward by an objector has been truly considered by the working group, and the working group has made an informed decision that the objection has been answered or is not enough of a technical problem to prevent moving forward, the chair can declare that there is rough consensus to go forward, the objection notwithstanding. The word objector emphasizes that there is one person who dissents. My preference is to consider the objection and address it instead of viewing the issue as dissent from one person. This document attempts to explain some features of rough consensus, explain what is not rough consensus, and suggest ways that we might achieve rough consensus and judge it in the IETF. The title of the document is on consensus and humming in the IETF. According to the above sentence the document attempts to discuss about rough consensus. In my opinion there a nuance between consensus and rough consensus. As a quick reaction I would say that rough consensus provides a faster path to shape up a proposal. It helps to cut down on document delivery time to the IESG. The consensus part is sought by getting a broader perspective. Section 2 sounds like objection-based processing. A binary choice (re. technical question) can end up polarizing a discussion. The section provides a good discussion about lack of disagreement. One of the questions I wondered about is whether the person making the determination should use technical judgement or whether the person should only make a determination about the comments received. I mentioned in an unrelated discussion that if it is the consensus of the group that the sky is green, that's what goes in the document. The person making the determination can flag it as an issue as a matter of technical judgement. I'll highlight a point from Section 3: Remember, if the objector feels that the issue is so essential that it must be attended to, they always have the option to file an appeal. There are very few people who exercise that option. According to the title of Section 4 humming should be the start of a conversation, not the end. BCP 25 states that: Consensus can be determined by a show of hands, humming, or any other means on which the WG agrees (by rough consensus, of course). 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. It is a useful way to resolve a controversy. I would say that it ties in Section 5, i.e. consensus is the path, not the destination. A show of hands is a disguised way to vote [4]. Section 5 identifies a few issues with the way people talk about consensus. I understand what Pete Resnick wrote as he has explained that to me in an unrelated discussion. The text discusses about making the call. I don't know whether the reader will easily understand the meaning of that. Section 6 and Section 7 attempt to explain that a high percentage of votes in a direction does not necessarily mean that there is rough consensus for that. I agree with the conclusion in Section 8. Regards, S. Moonesamy 1. http://www.ietf.org/mail-archive/web/ietf/current/msg82843.html 2. http://tools.ietf.org/html/draft-moonesamy-consensus-00 3. http://www.ietf.org/mail-archive/web/isms/current/msg00943.html 4. http://www.ietf.org/mail-archive/web/ietf/current/msg25014.html
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) saja...@cisco.com 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 b...@nostrum.com 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. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-l2vpn-pbb-vpls-interop-05 Reviewer: Ben Campbell Review Date: 2013-09-23 IETF LC End Date: 2013-09-24 Summary: Ready for publication as an informational RFC. Major issues: None Minor issues: None Nits/editorial comments: -- Abstract: Please expand H-VPLS on first mention Done. -- section 1, 1st paragraph: Please expand VPLS on first mention. Done. -- section 4, 3rd to last paragraph: Different PBB access networks... The previous and subsequent paragraphs say PBBN access networks. Should this instance also say PBBN? Done. -- section 4.3: 2nd paragraph says this scenario is applicable to Loosely Coupled Service Domains and Different Service Domains. The 4th paragraph mentions Tightly Does that mean the scenario also applies to Tightly Coupled Service Domains? (i.e. should it be added to the 2nd paragraph, or removed from the 4th?) Removed Tightly Š from the 4th paragraph. Cheers, Ali
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 engine is mentioned. This makes RFC indexing dependent on the operation of external applications, such as RFC search, or Google, or whatever. While I am sure that the operators of the RFC search engine and of Google firmly plan on operating their service for the duration, the duration can end or be interrupted (as is being discovered by all the users of the NIST web document servers right now). Also, the RFC docs have been and will only continue to be important historical and foundational documents, and should have their own in-line canonical summary index in the same format, for inclusion into larger document collections, and into historical archives and printings. Does it cost IETF anything to keep creating the xx99's? They should not be discontinued. Thanks! On Tue, Oct 8, 2013 at 10:50 AM, RFC Series Editor r...@rfc-editor.org wrote: Greetings, The RFC Editor is proposing to retire the practice of publishing RFCs xx99, the Request for Comments Summary for RFC Numbers xx00-xx99. In December 1991, RFC 1099 was the first Request for Comments Summary RFC published. It provides a list of document titles, authors, date of publication, and abstracts for each of the RFCs published in the range 1000 - 1099. Since that time, through the time that RFC 3299 was published, a new summary RFC was published every 100 RFCs, and RFC numbers ending with 99 were reserved for these summary documents. RFC 3399 was never published (for various reasons), though RFCs 3499 and 3599 were. RFC 3599 was the last of these summary documents to be published in December 2003. These snapshots are no longer needed because up-to-date data is available online. RFC abstracts are available using the RFC search engine (http://www.rfc-editor.org/search/rfc_search.php) and they are included in rfc-index.xml. RFCs xx99 summaries were never requested by the Internet Community and are not currently filling a need; therefore, the RFC Editor is retiring the publication of the RFC summary documents. RFC numbers typically reserved for these documents (i.e., numbers ending with 99) may be assigned to future RFCs. If there are any concerns about this course of action, please comment by October 18, 2013, on the rfc-inter...@rfc-editor.org mailing list. Thank you, Heather Flanagan, RSE
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 b...@nostrum.com 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. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-l2vpn-pbb-vpls-interop-05 Reviewer: Ben Campbell Review Date: 2013-09-23 IETF LC End Date: 2013-09-24 Summary: Ready for publication as an informational RFC. Major issues: None Minor issues: None Nits/editorial comments: -- Abstract: Please expand H-VPLS on first mention Done. -- section 1, 1st paragraph: Please expand VPLS on first mention. Done. -- section 4, 3rd to last paragraph: Different PBB access networks... The previous and subsequent paragraphs say PBBN access networks. Should this instance also say PBBN? Done. -- section 4.3: 2nd paragraph says this scenario is applicable to Loosely Coupled Service Domains and Different Service Domains. The 4th paragraph mentions Tightly Does that mean the scenario also applies to Tightly Coupled Service Domains? (i.e. should it be added to the 2nd paragraph, or removed from the 4th?) Removed Tightly Š from the 4th paragraph. Cheers, Ali
Re: Last Call: draft-resnick-on-consensus-05.txt (On Consensus and Humming in the IETF) to Informational RFC
On Oct 8, 2013, at 1:56 PM, S Moonesamy sm+i...@elandsys.com 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 focusing on Jeff Case's hums is missing the point. The point is the meaning of the term rough consensus, and how that plays out in working group process. The manner of measurement is a secondary issue. 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 preponderance (by some definition of preponderance) say something, the views of the losing set of parties are deemed irrelevant. In IETF process, and hopefully in any technical process, there is understanding that the parties who disagree may have valid reasons to disagree, and a phase of negotiation. When we talk about rough consensus, I understand it to mean - and would like to believe that we all understand it this way - that we investigate the reasons for disagreement, perhaps discover that some of them are valid, and address those issues to the satisfaction of those who raised them. As a result, the ultimate solution, even though it may not be the specific solution we would all have designed or selected, is one that in fact addresses all known issues. While we may not all agree, we don't disagree. I think the document on the table tries to address that. There are points of phraseology that I might express differently, but it's close enough that I don't disagree. signature.asc Description: Message signed with OpenPGP using GPGMail
RE: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (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: draft-ietf-6man-oversized-header-chain-08.txt (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 destination. Hosts MAY discover the Path MTU, using procedures such as those defined in [RFC1981] and [RFC4821]. However, if a host does not discover the Path MTU, it MUST assume the IPv6 minumum MTU of 1280 bytes [RFC2460]. The host MUST then limit each packet's header chain length to the Path MTU minus 256 bytes in case additional encapsulation headers are inserted by tunnels on the path. I would claim that additional encapsulation headers are already considered in the 1280 minimum MTU. as in: 1500 - 1280. cheers, Ole
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 this is interesting and varies widely). Although I see Pete's draft more as conceptual than as a handbook for every possible situation, I do think that working groups with very few participants are a hard case that we need to think about. Peter
Re: Last Call: draft-resnick-on-consensus-05.txt (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 preponderance (by some definition of preponderance) say something, the views of the losing set of parties are deemed irrelevant. In IETF process, and hopefully in any technical process, there is understanding that the parties who disagree may have valid reasons to disagree, and a phase of negotiation. When we talk about rough consensus, I understand it to mean - and would like to believe that we all understand it this way - that we investigate the reasons for disagreement, perhaps discover that some of them are valid, and address those issues to the satisfaction of those who raised them. As a result, the ultimate solution, even though it may not be the specific solution we would all have designed or selected, is one that in fact addresses all known issues. While we may not all agree, we don't disagree. 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 to say, it's not a binary question, and sometimes things we disagree with just aren't showstoppers. (I'd like to see people take that position more often - for some reason a lot of people seem to take disagreement as a reason to block a decision even when it doesn't matter that much). Melinda
Re: Last Call: draft-resnick-on-consensus-05.txt (On Consensus and Humming in the IETF) to Informational RFC
On Oct 8, 2013, at 8:23 PM, Melinda Shore melinda.sh...@gmail.com 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 to say, it's not a binary question, and sometimes things we disagree with just aren't showstoppers. (I'd like to see people take that position more often - for some reason a lot of people seem to take disagreement as a reason to block a decision even when it doesn't matter that much). wfm signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Last Call: draft-resnick-on-consensus-05.txt (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 almost everyone that the proposed solution is good enough for everyone to live with. /Loa On 2013-10-09 11:23, Melinda Shore wrote: 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 preponderance (by some definition of preponderance) say something, the views of the losing set of parties are deemed irrelevant. In IETF process, and hopefully in any technical process, there is understanding that the parties who disagree may have valid reasons to disagree, and a phase of negotiation. When we talk about rough consensus, I understand it to mean - and would like to believe that we all understand it this way - that we investigate the reasons for disagreement, perhaps discover that some of them are valid, and address those issues to the satisfaction of those who raised them. As a result, the ultimate solution, even though it may not be the specific solution we would all have designed or selected, is one that in fact addresses all known issues. While we may not all agree, we don't disagree. 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 to say, it's not a binary question, and sometimes things we disagree with just aren't showstoppers. (I'd like to see people take that position more often - for some reason a lot of people seem to take disagreement as a reason to block a decision even when it doesn't matter that much). Melinda -- Loa Anderssonemail: l...@mail01.huawei.com Senior MPLS Expert l...@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64
Re: Last Call: draft-resnick-on-consensus-05.txt (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 solutions Rough consensus - An agreement by almost everyone that the proposed That's a lot like voting, I think. Melinda
Re: Last Call: draft-resnick-on-consensus-05.txt (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 solution is the best of all of all possible solutions Rough consensus - An agreement by almost everyone that the proposed solution is good enough for everyone to live with. That's a lot like voting, I think. Well - if you say so, but then we don't have even a rough consensus on what consensus and rough consensus means. Note I talked about what a group need to reach to be able to say that there is consensus or rough consensus. Not how it is measured, in IETF we trust the wg chairs to correctly judge if we have reached a rough consensus. /Loa Melinda -- Loa Anderssonemail: l...@mail01.huawei.com Senior MPLS Expert l...@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64
Last Call: draft-ietf-avtext-multiple-clock-rates-10.txt (Support for Multiple Clock Rates in an RTP Session) to Proposed Standard
The IESG has received a request from the Audio/Video Transport Extensions WG (avtext) to consider the following document: - 'Support for Multiple Clock Rates in an RTP Session' draft-ietf-avtext-multiple-clock-rates-10.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-10-22. 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 clarifies the RTP specification when different clock rates are used in an RTP session. It also provides guidance on how to interoperate with legacy RTP implementations that use multiple clock rates. It updates RFC 3550. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-avtext-multiple-clock-rates/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-avtext-multiple-clock-rates/ballot/ No IPR declarations have been submitted directly on this I-D.
The RFC xx99 Series
Greetings, The RFC Editor is proposing to retire the practice of publishing RFCs xx99, the Request for Comments Summary for RFC Numbers xx00-xx99. In December 1991, RFC 1099 was the first Request for Comments Summary RFC published. It provides a list of document titles, authors, date of publication, and abstracts for each of the RFCs published in the range 1000 - 1099. Since that time, through the time that RFC 3299 was published, a new summary RFC was published every 100 RFCs, and RFC numbers ending with 99 were reserved for these summary documents. RFC 3399 was never published (for various reasons), though RFCs 3499 and 3599 were. RFC 3599 was the last of these summary documents to be published in December 2003. These snapshots are no longer needed because up-to-date data is available online. RFC abstracts are available using the RFC search engine (http://www.rfc-editor.org/search/rfc_search.php) and they are included in rfc-index.xml. RFCs xx99 summaries were never requested by the Internet Community and are not currently filling a need; therefore, the RFC Editor is retiring the publication of the RFC summary documents. RFC numbers typically reserved for these documents (i.e., numbers ending with 99) may be assigned to future RFCs. If there are any concerns about this course of action, please comment by October 18, 2013, on the rfc-inter...@rfc-editor.org mailing list. Thank you, Heather Flanagan, RSE
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 record? Please read this Nomcom call for nominations and consider nominating her or him. Or several folks! Deadline for nominations is October 18. Nominate soon to give your nominee(s) plenty time to fill in the questionnaire. If you're nominated, even if you support the present incumbent, being reviewed by Nomcom is great IETF experience. The questionnaire offers a chance to think about IETF and about your area. Whether or not your candidacy progresses this time, you'll have gained some valuable insights, and you'll have contributed greatly. This process only works because many IETFers take part; please join in. Lots more, including which positions are open, how to make a nomination (including nomination of yourself), and how to send us your feedback on the desired expertise, follows. IETFers, let's hear from you! Make nominations, accept nominations! If you have any questions about the process, feel free to get in touch with me. Best regards, Allison for the Nomcom Allison Mankin Nomcom Chair 2013-14 - The Info You Need for Nominating - The 2013-14 Nominating Committee (Nomcom) is seeking nominations from now until October 18, 2013. The open positions being considered by this year's Nomcom can be found later in this section, and also on this year's Nomcom website: https://datatracker.ietf.org/nomcom/2013/ Information about the desired expertise for positions is here: https://datatracker.ietf.org/nomcom/2013/expertise Nominations may be made by selecting the Nominate link at the top of the Nomcom 2013 home page, or by visiting the following URL: https://datatracker.ietf.org/nomcom/2013/nominate/ Note that nominations made using the web tool require an ietf.org datatracker account. You can create a datatracker ietf.org account if you don't have one already by visiting the following URL: https://datatracker.ietf.org/accounts/create/ Nominations may also be made by email to nomcom13 at ietf.org. If you nominate by email, please include the word Nominate in the Subject and indicate in the email who is being nominated, their email address (to confirm acceptance of the nomination), and the position for which you are making the nomination. If you use email, please use a separate email for each person you nominate, and for each position (if you are nominating one person for multiple positions). Self-nomination is welcome! No need to be shy. Nomcom 2013-14 will follow the policy for Open Disclosure of Willing Nominees described in RFC 5680. As stated in RFC 5680: The list of nominees willing to be considered for positions under review in the current Nomcom cycle is not confidential. Willing nominees for each position will be listed in a publicly accessible way - anyone with a datatracker account may access the lists. In all other ways, the confidentiality requirements of RFC 3777/BCP10 remain in effect. All feedback and all Nomcom deliberations will remain confidential and will not be disclosed. In order to ensure time to collect sufficient community feedback about each of the willing nominees, nominations must be received by the Nomcom on or before October 18, 2013. Please submit your nominations as early as possible for the sake of your nominees, as we've set the questionnaire submission deadline for October 25, 2013. The list of people and posts whose terms end with the March 2014 IETF meeting, and thus the positions for which we are accepting nominations: IAOC Chris Griffiths IAB Bernard Aboba Marc Blanchet Ross Callon Eliot Lear Hannes Tschofenig IESG Barry Leiba (Applications) Brian Haberman (Internet) Benoit Claise (Operations and Management) Gonzalo Camarillo (RAI) Stewart Bryant (Routing) Sean Turner (Security) Martin Stiemerling (Transport) Please be resourceful in identifying possible candidates for these positions, as developing our talent is a very crucial requirement for the IETF. Also, please give serious consideration to accepting nominations you receive. The summaries of the desired expertise for the positions, developed by the respective bodies, are found at: https://datatracker.ietf.org/nomcom/2013/expertise/ In addition to nominations, the Nomcom seeks community input on the positions themselves. We need and welcome the community's views and input on the jobs within each organization. If you have ideas on the positions' responsibilities (more, less, different), please let us know. You can send us email about this to nomcom13 at ietf.org, and we will use this feedback actively. Thank you for your help in nominating a great pool of strong and interesting nominees!
WG Action: Formed IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)
A new IETF working group has been formed in the Internet Area. For additional information please contact the Area Directors or the WG Chairs. IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch) Current Status: Proposed WG Chairs: Pascal Thubert pthub...@cisco.com Thomas Watteyne watte...@eecs.berkeley.edu Assigned Area Director: Ted Lemon ted.le...@nominum.com Mailing list Address: 6ti...@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/6tisch Archive: http://www.ietf.org/mail-archive/web/6tisch Charter: 6TiSCH: IPv6 over the TSCH mode of IEEE 802.15.4e. Background/Introduction: Low-power and Lossy Networks (LLNs) interconnect a possibly large number of resource-constrained nodes to form a wireless mesh network. The 6LoWPAN, ROLL and CoRE IETF Working Groups have defined protocols at various layers of the protocol stack, including an IPv6 adaptation layer, a routing protocol and a web transfer protocol. This protocol stack has been used with IEEE802.15.4 low-power radios. The IEEE802.15.4e Timeslotted Channel Hopping (TSCH) is a recent amendment to the Medium Access Control (MAC) portion of the IEEE802.15.4 standard. TSCH is the emerging standard for industrial automation and process control LLNs, with a direct inheritance from WirelessHART and ISA100.11a. Defining IPv6 over TSCH, 6TiSCH is a key to enable the further adoption of IPv6 in industrial standards and the convergence of Operational Technology (OT) with Information Technology (IT). The nodes in a IEEE802.15.4e TSCH network communicate by following a Time Division Multiple Access (TDMA) schedule. A timeslot in this schedule provides a unit of bandwidth that is allocated for communication between neighbor nodes. The allocation can be programmed such that the predictable transmission pattern matches the traffic. This avoids idle listening, and extends battery lifetime for constrained nodes. Channel-hopping improves reliability in the presence of narrow- band interference and multi-path fading. These techniques enable a new range of use cases for LLNs, including: - Control loops in a wireless process control network, in which high reliability and a fully deterministic behavior are required. - Service Provider networks transporting data from different independent clients, and for which an operator needs flow isolation and traffic shaping. - Networks comprising energy harvesting nodes, which require an extremely low and predictable average power consumption. IEEE802.15.4e only defines the link-layer mechanisms. It does not define how the network communication schedule is built and matched to the traffic requirements of the network. Description of Working Group: - The Working Group will focus on enabling IPv6 over the TSCH mode of the IEEE802.15.4e standard. The extent of the problem space for the WG is one or more LLNs, eventually federated through a common backbone link via one or more LLN Border Routers (LBRs). The WG will rely on, and if necessary extend, existing mechanisms for authenticating LBRs. Initially, the WG will limit its scope to distributed routing over a static schedule. In that case, a node's schedule can be either preconfigured, or learnt by a node when joining the network, but it remains unchanged after the node has joined a network. The Routing Protocol for LLNs (RPL) is used on the resulting network. The WG will interface with other appropriate groups in the IETF Internet, Operations and Management, Routing and Security areas. Work Items: --- The group will: 1. Produce 6TiSCH architecture to describe the design of 6TiSCH networks. This document will highlight the different architectural blocks and signalling flows, including the operation of the network in the presence of multiple LBRs. Initially, the document will focus on distributed routing operation over a static TSCH schedule. 2. Produce an Information Model containing the management requirements of a 6TiSCH node. This includes describing how an entity can manage the TSCH schedule on a 6TiSCH node, and query timeslot information from that node. A data model mapping for an existing protocol (such as Concise Binary Object Representation (CBOR) over the Constrained Application Protocol (CoAP)) will be provided. 3. Produce Minimal 6TiSCH Configuration defining how to build a 6TiSCH network using the Routing Protocol for LLNs (RPL) and a static TSCH schedule. It is expected that RPL and the Objective Function 0 (OF0) will be reused as-is. The work will include a best practice configuration for RPL and OF0 operation over the static schedule. Based on that experience the group may produce a requirements draft for OF0 extensions, to be studied in ROLL. Non-milestone work items: - The Working Group may maintain a number of running, often-respun documents, that
Last Call: draft-ietf-mile-sci-09.txt (IODEF-extension for structured cybersecurity information) to Proposed Standard
The IESG has received a request from the Managed Incident Lightweight Exchange WG (mile) to consider the following document: - 'IODEF-extension for structured cybersecurity information' draft-ietf-mile-sci-09.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-10-22. 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 extends the Incident Object Description Exchange Format (IODEF) defined in RFC 5070 [RFC5070] to exchange enriched cybersecurity information among cybersecurity entities and facilitate their operations. It provides the capability of embedding structured information, such as identifier- and XML-based information. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mile-sci/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mile-sci/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1786/ http://datatracker.ietf.org/ipr/1787/
